AI-агент с доступом к внешним системам: архитектура, безопасность, кейс

Почему AI-агент ломается на реальных интеграциях

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

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

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

Слабые места лежат на стыках с внешними системами, а не в самой модели. Ниже разбираем, как это закрывается.

Что даёт AI-агент с доступом к внешним системам

Управляемый доступ к внешним системам — это когда агент читает и изменяет данные там, где они живут: в учётной системе вроде Битрикс24, во внутренней базе заказов или в очереди обращений. Каждый вызов идёт по описанному контракту: что разрешено, что требует подтверждения человека, что запрещено совсем. Ниже — что именно меняется в измеримых величинах.

• Скорость обработки. Сбор контекста из двух-трёх систем и подготовка ответа идут одним проходом вместо ручной цепочки согласований. Время обработки одной заявки падает с десятков минут до единиц, и это видно не только по среднему, но и по хвосту распределения.
• Доля операций без человека. Типовые обращения агент закрывает сам, оператору остаются спорные и нетиповые. На пилотном контуре это 60–80% потока, а высвобожденные часы уходят на сложные случаи, а не на рутину.
• Изоляция сбоев. Внешние вызовы идут через отдельный слой с ограничением времени ожидания, повторами и пределом частоты. Медленный ответ одной системы не утягивает агента целиком: сценарий деградирует до ручного шага, остальные продолжают работу.
• Время простоя. Когда внешняя система недоступна, операции встают в очередь и доигрываются после восстановления — повтор не создаёт дубль. Простой считаем минутами, потерянных заявок нет.
• Нагрузка на поддержку. Статусы, типовые правки и сбор данных уходят к агенту. Доля ручных действий в потоке падает вместе с числом ошибок ввода и обращений «а где моя заявка».

Проверяем это на узком контуре: один процесс, реальные данные, метрики до и после доступа. Расширяем права агента только после того, как цифры подтвердятся.

Способы подключения к внешним системам: что выбрать

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

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

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

Этапы внедрения: от разбора задачи до передачи

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

1. Разбор задачи. Интервью с исполнителями и карта обращений: кто инициирует, по какому событию, какой результат считается закрытым. На выходе — перечень операций агента и отдельный список того, чего он не делает никогда.
2. Границы доступа. Определяем внешние системы и права: чтение или запись, отдельная сервисная учётная запись, запрет на массовые выгрузки. Необратимые действия оставляем за человеком, который подтверждает их вручную.
3. Схема и настройка интеграций. Описываем обмен с внешними системами: структуру запросов и ответов, обработку ошибок, повторные вызовы без создания дублей, журналирование каждого шага агента.
4. Проверка на стенде. Тестовый контур с копиями систем и обезличенными данными. Прогоняем не только удачные сценарии, но и отказы: недоступный сервис, пустой ответ, конфликт прав, превышение лимитов.
5. Замер результата. Считаем долю обращений, доведённых агентом до конца без участия человека, и время на типовую операцию до и после. Это база для решения о расширении прав.
6. Передача в эксплуатацию. Регламент обновлений, мониторинг и оповещения об отказах, инструкции для первой линии, обучение команды заказчика. Сопровождаем первый период, пока поведение агента не станет предсказуемым.

Что остаётся в вашей инфраструктуре после внедрения

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

• Схема взаимодействия — маршрут запроса от пользователя через агента до каждой внешней системы, места, где применяются ограничения, и точки, где запрос останавливается совсем. Новый инженер разбирается в потоке за день, а не за неделю.
• Матрица доступа — по каждому подключению: что агент выполняет сам, что делает только после подтверждения человека, что запрещено на уровне прав. Изменения вносятся через согласование, история правок сохраняется.
• Регламент отката — порядок отключения агента от внешней системы, отзыв выданных прав, возврат предыдущей конфигурации и время на каждую операцию. Прогоняется на стенде, а не существует только на бумаге.
• Документация — конфигурации, переменные окружения, владельцы подключений и контакты ответственных на стороне внешних систем. Хранится рядом с кодом, а не в отдельной папке.
• Журнал действий — что агент запросил, что изменил, с чьего подтверждения; сроки хранения настроены, выгрузка для разбора инцидента отработана.
• Инструменты наблюдаемости — метрики отказов, уведомления об аномальных действиях и панель наблюдения с разбивкой по системам и типам операций.
• Сценарии проверки — набор тестов на ключевые пути, включая недоступность внешней системы и отказ в правах.

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

Кейс: сняли ручные операции в поддержке и продажах

Одна из наших команд вела поддержку и продажи в общей очереди: около полутора тысяч обращений в месяц, три четверти — типовые. Оператор тратил на каждое 12–15 минут, и большая часть уходила на ручные операции: найти клиента, сверить статус заказа, перенести данные в шаблон.

До: очередь заявок и ручные операции

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

После: типовое — агенту, исключения — человеку

Агент подключён к системам по API: обращения приходят из Zendesk, статусы — из учётной системы и службы доставки, ответы собираются по базе знаний. На типовых сценариях он сам находит заказ, проверяет оплату и закрывает обращение — время обработки упало с 12–15 минут до 40–60 секунд.

Без оператора закрывается 68% обращений, пиковая очередь сократилась с 60 до 8–10 заявок, первый ответ занимает 3–4 минуты. Ручные операции на типовых сценариях ушли: сбор данных, подстановка в шаблон и перевод заявки между статусами больше не делаются вручную.

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

Чем автономный сценарий отличается от обычной автоматизации

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

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

Отсюда главное отличие — принятие решений. В автоматизации по правилам выбор делает инженер, заложивший ветку; в автономном сценарии выбирает модель, а мы задаём рамки: к каким системам есть доступ, что разрешено менять, что только читать.

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

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

Частые технические сомнения перед запуском

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

Что происходит, если внешняя система недоступна?

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

Можно ли проверить сценарий без риска для рабочего контура?

Собираем контур с копией структуры данных и заглушками внешних систем, прогоняем редкие ветки: отказ интеграции, лимит запросов, конфликт версий записи. Логи и трассировки каждого шага складываются в Grafana — разбор инцидента занимает минуты.

Как откатываются изменения?

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

Обсудим задачу: что прислать нам для оценки

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

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

Если часть данных закрыта, это не блокер: начинаем с описания процесса и перечня систем, остальное собираем на сессии.

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