ИИ-агент без доступа к данным – демо на синтетике. Ценность появляется, когда агент читает заявки из 1С, поднимает документ из СЭД, сверяет статус в CRM и пишет результат обратно. Каждый такой канал – это коннектор, и каждый коннектор расширяет поверхность атаки. В корпоративном и госсекторе вопрос ставится жёстко: дать агенту ровно столько прав, сколько нужно для задачи, и зафиксировать каждое его действие. Разберём, как соединить агента с системами и не разменять автоматизацию на утечку.

Коннекторы: чем подключать

Выбор слоя подключения определяет надёжность всей схемы. Три рабочих варианта.

  • REST/SOAP API систем. Предпочтительный путь: вызовы идут через документированные контракты, права режутся на стороне сервиса. Подходит для современных ERP, CRM, СЭД с открытым API.
  • Шина данных и брокеры (Kafka, RabbitMQ). Агент не дёргает системы напрямую, а работает с событиями. Развязка по времени снимает нагрузку и упрощает отказоустойчивость стека: если приёмник недоступен, сообщение ждёт в очереди, а не теряется.
  • Прямой доступ к БД и legacy. Крайняя мера для систем без API. Только чтение через выделенную реплику, никаких записей в обход бизнес-логики.

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

Безопасность: периметр вокруг агента

Языковая модель непредсказуема по своей природе, поэтому контроль строят не внутри неё, а вокруг.

  • Брокер вызовов. Агент не обращается к системам напрямую. Между ним и коннекторами стоит прокси, который проверяет каждый вызов по белому списку операций и параметров. Промпт-инъекция в этой схеме упирается в стену: модель может «захотеть» удалить документ, но операция delete просто не входит в разрешённый набор.
  • Изоляция по контурам. Чувствительные данные – ПДн, гостайна, банковская тайна – не должны утекать во внешние модели. Для таких сценариев агент работает на развёрнутой в контуре заказчика модели, а коннекторы к критичным системам живут в защищённом сегменте сети.
  • Полный аудит. Каждый запрос агента, каждый ответ системы, каждое решение – в неизменяемый лог. Без этого вы не пройдёте проверку и не разберёте инцидент.

Отдельно держите в уме требования 152-ФЗ и курс на импортозамещение. Если агент обрабатывает персональные данные, инфраструктура и модель должны оставаться внутри РФ – это не пожелание, а условие легальной эксплуатации.

Эксплуатация: что ломается на практике

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

Переезд систем – отдельный риск. Мы подробно разбирали его в материале про миграцию корпоративных коммуникаций: любой перенос рвёт интеграции, и агентские коннекторы тут не исключение.

Вывод

ИИ-агент в корпоративном контуре – это в первую очередь инженерия интеграции, а не магия модели. Надёжные коннекторы, брокер вызовов с белым списком, изоляция чувствительных данных и сквозной аудит превращают эксперимент в систему, которой можно доверять. Сложность здесь не в самой модели, а в интеграции агента с корпоративными системами с учётом ваших контуров и требований регулятора.