ИИ-агенты для бизнеса: три сценария, которые работают

Короткий ответ: агент оправдан, когда задача требует нескольких разных шагов, порядок которых заранее неизвестен, а результат проверяется быстро. Если порядок известен — дешевле и надёжнее обычный конвейер. Если проверка дорогая — не стоит браться вовсе.

Три формы, которые встречаются чаще всего и действительно окупаются.

Сценарий 1. Разбор входящего потока

Приходят обращения, заявки, счета, резюме — разнородные и в свободной форме. Нужно вытащить поля, отнести к категории, при нехватке данных — не выдумать, а пометить.

Почему агент, а не одна модель. Потому что шагов несколько и они ветвятся: сначала понять тип документа, потом применить нужную схему, при неоднозначности — заглянуть в справочник.

Почему окупается. Проверка дешёвая: разобранные поля сверяются с исходником взглядом. Ошибка обратима — запись правится.

Что обязательно. Пустое значение вместо догадки. Каждое поле, которого может не быть, должно допускать null, иначе модель заполнит правдоподобным — формат ответа как интерфейс.

Сценарий 2. Ответ по своей базе

Вопрос от сотрудника или клиента, ответ — в ваших регламентах. Агент ищет, читает найденное, отвечает и приводит цитату-основание.

Почему агент. Один поиск редко достаточен: по первому запросу находится не то, приходится переформулировать и искать снова.

Почему окупается. Цитата делает проверку механической: она либо есть в исходнике, либо нет.

Что обязательно. Нарезка по структуре. Я измерял на своём корпусе: фиксированная нарезка разрывает 95% смысловых разделов, и никакой агент этого не исправит — числа здесь.

Сценарий 3. Рутина в чужих интерфейсах

Перенести данные между системами, у которых нет API. Заполнить форму в старой программе. Собрать отчёт из трёх окон.

Почему агент. Порядок действий меняется от случая к случаю: кнопка переехала, окно открылось не то.

Почему окупается. Работа скучная, объём большой, результат виден сразу.

Что обязательно. Потолок шагов и подтверждение необратимого. Здесь агент действует в чужом интерфейсе, где отменить нельзя — бюджет шагов и границы доверия.

Признак четвёртой задачи

Той, где агент не нужен, хотя очень хочется.

Ошибка обнаруживается не сразу. Расчёт, начисление, права доступа. Агент отработает, результат будет выглядеть правильным, а расхождение всплывёт в отчётности через месяц.

Проверка требует того же специалиста. Если принять результат может только человек, который сделал бы это сам за то же время, выигрыша нет независимо от качества модели.

Ответ уходит клиенту без человека. Дорогая ошибка плюс медленная обратная связь — худшее сочетание для первого контура.

Условие несогласия

Всё сказанное — про первое внедрение. Когда контур уже работает и есть журнал, набор примеров и понимание, где он ошибается, — можно брать задачи из «четвёртой» группы, потому что у вас появились средства их контролировать.

Порядок именно такой, а не обратный: сначала простое с дешёвой проверкой, потом сложное.

Чего я делать не стал бы

Не стал бы начинать с общения с клиентом. Это ровно четвёртая задача, и первый же неудачный ответ стоит дороже всей экономии.

Не стал бы давать агенту право на запись в первом контуре. Чтение и черновик покрывают большинство сценариев, а цена ошибки остаётся в токенах.

Не стал бы считать окупаемость по сэкономленным часам без учёта проверки и поддержки. Полная стоимость включает токены, ретраи, время проверяющего и работу при смене модели у провайдера.

Открытый вопрос

Все три сценария предполагают, что кто-то читает результат. Ровно эта роль и вырождается быстрее всего: через несколько месяцев проверяющий начинает принимать не глядя, потому что почти всегда правильно.

Способа удержать внимание на редком событии я не знаю. В других инженерных областях это решают учениями — подсовывают поломку и смотрят, заметят ли. Для контура с моделью такого приёма я не встречал и сам не пробовал.