ИИ-агент в бэкофисе: документы и сверки без ручной рутины

Что реально делает агент в бэкофисе

В продажах и поддержке агент разговаривает — отвечает на вопрос, квалифицирует заявку, ведёт клиента по сценарию. В бэкофисе разговаривать не с кем: есть счёт, накладная, платёж, две карточки одного клиента в разных системах. Агент собирает документ по шаблону, подставляя данные из сделки в amoCRM или Bitrix24 — реквизиты, позиции, суммы — и отдаёт готовый файл или сразу отправляет его через API нужного сервиса. Он сверяет суммы: сравнивает то, что пришло на расчётный счёт, с тем, что должно было прийти по счёту в CRM, и если есть расхождение — даже в рублях, не в разы — помечает сделку и создаёт задачу менеджеру. Он синхронизирует карточку между CRM и учётной системой: когда в amoCRM меняется статус оплаты, агент вызывает эндпоинт 1С или другой учётной системы и обновляет там платёж, без ручного дублирования ввода.

Технически это те же вызовы API, что я настраиваю в интеграциях amoCRM с Bitrix24, только адресат — не менеджер и не клиент, а другой сервис. Разница в том, что здесь агенту не нужно понимать намерение собеседника — правила заданы заранее: если сумма в выписке равна сумме в счёте — закрыть, если нет — эскалировать. Эту логику я собираю как часть услуги настройки ИИ-агентов, потому что без связки с CRM и учётной системой агенту просто не с чем сверять.

Диалог тут ни при чём

Агент в продажах ошибается — переспрашивает, клиент поправляет, диалог продолжается. Бэкофисный агент работает без диалога, и это меняет требования к нему целиком. Он не может задать уточняющий вопрос бухгалтеру посреди ночи — он либо выполняет операцию по правилу, либо останавливается и передаёт её человеку. Поэтому вся логика пишется заранее и жёстко: какие поля обязательны, какое расхождение считается допустимым, что делать при отсутствии одного из документов. Здесь нет места модели, которая «в целом понимает контекст» — контекст должен быть формализован до того, как агент начнёт работать, иначе он либо закроет то, что закрывать нельзя, либо будет заваливать людей эскалациями по мелочам.

Ошибка в бэкофисе дороже, чем в чате поддержки. Неправильный ответ клиенту всплывает в переписке уже через минуту. Задвоенный платёж или неверно перенесённая сумма всплывает при сверке в конце месяца, когда исправлять уже сложнее и дороже — искать источник расхождения приходится в трёх системах сразу.

Каждая операция должна быть проверяема постфактум

Из-за цены ошибки я строю такого агента не как чёрный ящик, а как последовательность именованных операций, каждая из которых пишет лог: что на входе, какое правило сработало, что на выходе, в какую систему ушёл вызов и с каким ответом. Если через месяц бухгалтер спрашивает, почему платёж от 14 июля закрылся автоматически, а от 15-го — нет, у меня есть точный ответ по логу, а не «агент так решил». Это требование справедливо для любого агента, который трогает деньги или юридически значимые документы: должна быть возможность прогнать конкретную операцию назад и увидеть, на каком шаге и почему сработала логика.

Отдельный момент для тех, кто работает с российскими компаниями — сами данные и модель, которая их обрабатывает, должны оставаться в РФ по 152-ФЗ. Для сверки сумм и работы с документами это не абстрактное требование, а прямое следствие: счета и платёжные данные — персональные и коммерческие данные, которые нельзя гонять через зарубежный API без основания. Я собираю такие агенты на YandexGPT, GigaChat или self-hosted моделях именно поэтому, а не потому что зарубежные модели хуже справляются с задачей.

Почему это код и интеграция, а не подписка на конструктор

Складывать сверку сумм, перенос карточек между CRM и учётной системой и генерацию документов в no-code-конструкторе вроде тех, что собирают сценарии из готовых блоков, — путь к лимитам на количество операций, обрезанной логике условий и логам, которых там просто нет в нужном виде. Я делаю это кодом: конкретный эндпоинт, конкретное условие, конкретный лог — и контроль за тем, что происходит с данными на каждом шаге, у меня, а не у стороннего сервиса с собственными ограничениями API.

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