ИИ-агенты ломаются на пути в продакшен: четыре барьера, которые не видны на пилоте

---

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

Тему подняли четверо практиков: Виктор Овчинников, руководитель решения Digital Q.Integration компании «Диасофт», ИИ-архитектор Андрей Носов, тимлид и пентестер Сергей Зыбнев и директор по информационной безопасности «Вебмониторэкс» Лев Палей. Разговор шёл на канале Ai4Dev и касался конкретного разрыва: между успешным пилотом и рабочим продуктом лежит целый пласт инфраструктуры, который большинство компаний ещё не построили.

Почему ИИ-агенты ломаются при выходе из пилота?

• Данные устарели ещё до запроса. Аналитические хранилища в банках обновляются раз в сутки, а иногда раз в неделю. ИИ-агент отвечает быстро, но на вчерашнюю картину мира. Виктор Овчинников называет это «мгновенным ответом вчерашними данными».

• Фабрики данных нет. Андрей Носов объясняет: на этапе proof of concept (проверки концепции, когда берут одну задачу и готовый набор данных) всё работает, потому что среда собрана специально. В промышленной эксплуатации нужен непрерывный конвейер, «фабрика», которая снабжает модель свежей информацией и поддерживает её качество. У большинства предприятий такой фабрики просто нет.

• Legacy-системы (старые, давно работающие системы, которые не трогают, пока не сломались) не умеют отдавать данные сами. Многие банковские системы работают по pull-модели: ничего не отправляют, а только отвечают на прямой запрос. Поэтому перед любым поиском и анализом нужен отдельный интеграционный слой, программная прослойка, которая сама обращается к источникам, собирает ответы, приводит разные форматы к единой структуре и только потом передаёт данные ИИ-агенту.

• Системный промпт (системная инструкция для модели) не заменяет политику безопасности. Текстовое ограничение вроде «не бери чужое» для LLM (большой языковой модели, на которой работает агент) выглядит как обычный текстовый блок. Сергей Зыбнев описывает реальный российский проект: любой текст, попадавший в контекст агента, фактически считался доверенным. Модель не различает системную инструкцию, документ из базы знаний и пользовательский ввод.

• Без контроля прав агент становится угрозой. Если ИИ-агент сам решает, к каким данным у него есть доступ, клиент может запросить чужие сведения, а агент выполнит запрос или ошибётся и вернёт данные другого человека. Для банка это уже не плохой ответ модели, а утечка персональных данных.

Как подступиться к промышленному внедрению ИИ-агента?

1. Отделите права доступа от модели. Перед обращением к источнику и перед выдачей результата поставьте детерминированные (жёстко запрограммированные, а не зависящие от решения ИИ) проверки полномочий. Минимум: RBAC (управление доступом на основе ролей, когда каждому пользователю или агенту назначена роль с набором разрешений). Для более точного контроля: ABAC (управление доступом на основе атрибутов, где учитывается не только роль, но и контекст запроса). Сергей Зыбнев рекомендует давать агенту, который только собирает данные, права read-only (только чтение).

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

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

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

Есть ли в России готовые аналоги?

В обсуждении участвовали именно российские специалисты и российские корпоративные реалии. Проблемы, которые они описали, касаются не конкретной модели (GPT, YandexGPT, GigaChat), а архитектуры вокруг модели.

Из доступных в РФ больших языковых моделей, YandexGPT и GigaChat, обе можно встроить в корпоративный контур. Но ключевой вывод дискуссии: сама модель не решает описанных проблем. Без интеграционного слоя, политики прав и конвейера данных любой ИИ-агент, российский или зарубежный, останется стендовой демонстрацией.

Что с этого прямо сейчас, по ролям?

Автору на Дзене. Если вы пишете про ИИ-агентов, вот конкретный тезис для контента: агент без доступа к свежим данным бесполезен, а с доступом опасен. Этот парадокс объясняет, почему большинство корпоративных внедрений пока застряли на стадии пилота. Тема горячая и плохо раскрыта на русском языке.

Маркетологу. Прежде чем обещать клиенту «ИИ-агента, который сам продаёт», уточните: откуда агент возьмёт актуальные данные и кто отвечает за утечку. Без ответа на оба вопроса проект не выйдет из демо.

Предпринимателю в РФ. Если ваша CRM или учётная система обновляет аналитику раз в сутки, начните с конвейера данных, а не с выбора модели. Интеграционный слой, это инвестиция, которая окупится при любой смене LLM.

Частые вопросы

Можно ли обойтись без интеграционного слоя, если данных немного?

Если источник один и стабилен, можно обойтись обычными скриптами. ИИ-агент нужен там, где источников много и форматы постоянно меняются. Но даже при одном источнике политика прав доступа обязательна: без неё агент может вернуть данные не того пользователя.

Системный промпт разве не защищает от ошибок агента?

Нет. Сергей Зыбнев на примере реального российского проекта показал: для модели системная инструкция, документ из базы знаний и пользовательский ввод, это просто текстовые блоки в общем контексте. Модель не воспринимает их как изолированные зоны с разным уровнем доверия. Проверку прав нужно выносить за пределы LLM, в отдельный программный слой.

Это касается только банков или любого бизнеса?

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

Выстроить конвейер данных и политику прав до подключения ИИ-агента дольше и скучнее, чем показать демо на стенде, но именно это отделяет пилот от продукта, который действительно работает.