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

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

Текстовые ограничения в системном промпте вроде «не брать чужое» не способны заменить полноценную политику безопасности. Следовательно, проверку прав необходимо выносить за рамки LLM, разделять данные по изолированным контурам и контролировать работу агента с той же строгостью, которая применяется к критически важным продакшен-сервисам.

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

Мы попробовали разобраться, что должно появиться между моделью и корпоративной системой, чтобы пилотный проект стал реальным продуктом. 

Агент знает только то, что ему положили

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

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

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

«ИИ - штука полезная, но сам по себе он не является ни данными, ни информацией. Это алгоритм, способ работать с информацией. На уровне proof of concept базовые методы можно показать почти всегда: входные данные подготовлены, а контролируемая среда собрана специально для демонстрации.

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

Так змея и кусает собственный хвост: пилот подтверждает возможности модели, но у компании еще нет инфраструктуры, способной поддерживать эти возможности в проде», - считает Андрей Носов.

Агент полез в legacy

«Представим крупный банк, который формирует персональные кредитные предложения. В онлайне сведения об одном клиенте могут быть распределены по сотням систем. Эти данные никак не подготовлены для ИИ и нередко находятся в разных контурах. Банки консервативны в хорошем смысле: если legacy-система работает, ее стараются не трогать.

Главная сложность скрывается в словах «данные приходят». Когда информация уже доставлена, ее можно нормализовать, преобразовать и передать дальше. Но многие старые автоматизированные банковские системы работают по pull-модели. Они сами ничего не отправляют и отвечают только на прямой запрос.

Поэтому до поиска и анализа нужен интеграционный слой. Он должен обратиться к источникам, собрать ответы, привести разные форматы к общей структуре и только после этого передать данные ИИ. Задача решаемая, но решается она не внутри модели», - объясняет Виктор Овчинников.

«Подключать агента к каждой legacy-системе нет смысла. Если источник стабилен и между обновлениями в нем почти не бывает несовместимых изменений, интеграцию можно сделать обычными скриптами. Так поступали десятилетиями: это дешево, быстро и надежно. Агент становится полезен там, где система активно меняется, а данные приходится получать из разных источников и нормализовать на ходу. Он может сам выполнить запрос, привести ответ к нужному виду и передать его дальше.

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

Если агент обращается к нескольким корпоративным системам только ради сбора данных, ему достаточно прав read-only. До обращения к источнику и перед выдачей результата нужны детерминированные проверки полномочий: как минимум RBAC (управление доступом на основе ролей), а для более точного контроля ABAC (управление доступом на основе атрибутов). Сама LLM не должна принимать решение о доступе. Иначе клиент может запросить чужие сведения, а агент либо выполнит запрос, либо ошибется и вернет данные другого человека. Для банка это уже не неудачный ответ модели, а утечка персональных данных», - говорит Сергей Зыбнев.

Общая витрина не означает общий доступ

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

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

Это именно архитектурная гипотеза, а не готовая схема. Она сразу оставляет два вопроса: как собрать витрину из существующих систем и как разграничить доступ к ней», - говорит Виктор Овчинников.

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

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

Ничего принципиально нового здесь изобретать не требуется. Разделение control plane и data plane давно применяется в сетевой безопасности. Управление и политики существуют отдельно от данных, а из менее защищенного сегмента нельзя произвольно перейти в более защищенный. Разрешенное взаимодействие проходит через контролируемую границу.

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

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

Модель атакуют словами. Обвязку ломают через зависимости

«Нельзя объединять все атаки на ИИ в один класс, — отмечает Сергей Зыбнев. — У классического машинного обучения, компьютерного зрения и LLM разные поверхности атаки. Языковые модели добавили то, чего раньше почти не было в прикладных системах: атаку можно провести естественным языком. WAF, антивирусы и EDR ищут другие признаки и не приспособлены к семантическим манипуляциям с контекстом. DLP может помочь на уровне текстовых и графических данных, но не закрывает логику самой LLM».

Guardrail иногда называют WAF для языковой модели, но это лишь грубая аналогия. Внутри такого средства остаются правила и ML-компоненты, которым нужны собственные данные и проверки. Нужно следить, не деградирует ли защита, не пропускает ли новые атаки и не блокирует ли нормальные запросы. Если guardrail начинает отбрасывать легитимных клиентов, защитный механизм сам наносит ущерб продукту.

Статическими условиями эту задачу не решить. Текст можно обфусцировать, спрятать инструкцию в документе, подменить роль или постепенно изменить контекст. Все варианты заранее не перечислить. Новые приемы приходится находить уже в эксплуатации либо постоянно исследовать атаки и обновлять защиту.

Есть и вторая поверхность, которая вообще не связана с содержанием промпта. LiteLLM используется как маршрутизатор запросов к разным провайдерам моделей, поэтому его зависимости оказываются глубоко внутри инфраструктуры. Во время supply chain атаки в PyPI появились вредоносные выпуски пакета, собиравшие секреты и учетные данные. Команда проекта связала компрометацию с зависимостью сканера Trivy. Так и работает цепочка поставок: атакующему не нужно проникать в каждую компанию отдельно, достаточно отравить компонент, который многие установят при очередном обновлении», - объясняет Сергей Зыбнев.

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

Одновременно ухудшается качество. В перегруженном или искусственно зашумленном контексте модели сложнее удерживать важные связи, поэтому ответы становятся слабее. Пользователь не видит причину, он просто получает дорогой сервис, который отвечает хуже. Даже без кражи данных такая атака способна увеличить стоимость обслуживания и вызвать отток клиентов», - считает Андрей Носов.

«История LiteLLM хорошо показывает, что новая ИИ-обвязка наследует старые проблемы AppSec. Если команда не контролирует репозиторий и компонентную базу, подмена одного пакета приносит вредоносный код внутрь всей системы. Популярность open source проекта и доверие к его сообществу не заменяют контроль зависимостей.

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

Нет сценария - нет evals

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

«До проектирования архитектуры мы часто упираемся в сценарий использования. Заказчик приходит с пожеланием сделать что-нибудь с ИИ. Когда начинаешь выяснять, как это должно работать, он предлагает нарисовать процесс самостоятельно. Приносишь схему и слышишь, что имелось в виду не совсем это. Значительная часть работы уходит на восстановление задачи, которую заказчик пока чувствует, но еще не умеет описать.

Когда я руководил департаментом разработки роботов в Promobot, отдельная команда проектировала сценарии общения. Однажды мне принесли карту диалогов. В развернутом виде она занимала почти футбольное поле: ветки пересекались, возвращались друг к другу и снова расходились. Я попробовал пройти по стрелкам и в какой-то момент сам потерялся.

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

«Без описанного поведения невозможно грамотно тестировать систему. Evals проверяют воспроизводимость, точность и качество ответов. Safety отвечает за то, чтобы поведение модели оставалось безопасным для пользователя. Это не то же самое, что security: защищенность от взлома и безопасный результат работы являются разными характеристиками.

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

Если участники проекта не могут сформулировать, как система должна работать, у команды не будет ни проверочного набора, ни порогов качества, ни критерия приемки. Сначала появляется сценарий, и только после него evals», - объясняет Сергей Зыбнев.

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

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

Инфраструктурная карта при этом бывает не менее запутанной, чем схема диалогов. Недавно мы разбирали расположение систем и связи между ними. Получилось поле для мини-футбола из пересекающихся маршрутов. Целиком такую схему обычно не держит в голове никто: за каждый сегмент отвечают разные люди. Обследование нужно еще и для того, чтобы собрать их знания в одну проверяемую картину», - говорит Виктор Овчинников.

После такой карты цена демо перестает быть ориентиром для прода.

Дешево вызвать модель, дорого строить продукт

«Мы внедряли агентов на разных уровнях абстракции. Высокоуровневые и no-code инструменты позволяют быстро собрать демонстрацию и приблизить интерфейс к обычному пользователю. Но при расширении сценария и росте нагрузки команда довольно скоро упирается в ограничения платформы. Логику приходится переносить во вспомогательные сервисы, а агентную обвязку писать под проект.

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

Отсюда возникает неприятный разрыв ожиданий. На n8n можно быстро собрать недорогую схему и показать, что она работает. Через три-пять месяцев выясняется, что в таком виде ее трудно масштабировать и сопровождать. В отдельных оценках стоимость полноценной разработки оказывалась примерно в двадцать раз выше первоначального демо. Это не универсальный коэффициент, а разница между коротким рабочим сценарием и системой, с которой предстоит жить», - рассказывает Андрей Носов.

«Сам по себе workflow в n8n еще не равен промышленному агенту. Платформа позволяет собрать агентную схему, подключить модель и инструменты, но визуальный процесс не превращается автоматически в готовую обвязку с контролем доступа, состоянием, маршрутизацией и мониторингом.

Иногда эта обвязка компании вообще не нужна. Бизнес видит новую технологию и просит агента, хотя процесс детерминирован и закрывается скриптом или обычным workflow. В таком случае правильнее улучшить UX, спрятать техническую схему за понятным интерфейсом и не оплачивать автономность, которая не приносит дополнительной пользы.

Если агент все-таки нужен, экономику определяет не только выбор между облачной и локальной моделью. Облачные модели обычно дают больше готовых возможностей, но сразу возникает вопрос, куда уходят данные и что произойдет с пользовательским сценарием после маскирования. Можно заменить персональные данные перед запросом и получить на выходе таблицу из Иванов Ивановичей. Конфиденциальность сохранена, но для пользователя продукт выглядит сломанным. Локальная модель оставляет данные внутри контура, зато требует собственной инфраструктуры, настройки и сопровождения. По моему опыту, на старте такой вариант часто оказывается дороже, но это нужно проверять для конкретной нагрузки, а не превращать в общее правило.

Часть расходов можно контролировать маршрутизацией: простые запросы отправлять в более дешевую модель, сложные в более мощную. Однако роутер тоже нельзя настроить на глаз. Нужен проверочный набор из запросов, ожидаемых ответов и правильных маршрутов. Только тесты покажут, действительно ли такая схема экономит деньги, не ухудшая качество», - объясняет Сергей Зыбнев.

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

Кто будет чинить JSON после редтиминга

«Часть атак можно искать проактивно с помощью автоматизированного редтиминга. Инструмент запускается по расписанию, например раз в неделю, пробует известные техники взлома и показывает, какие ограничения удалось обойти. Так у команды регулярно появляются новые примеры для проверки guardrails.

Такой цикл можно частично автоматизировать: запускать тесты по расписанию, фиксировать успешные атаки и передавать их в контур обновления защитных инструкций. Идея в том, чтобы guardrails пополнялись не после случайного инцидента, а по результатам регулярных попыток взломать собственную систему», - объясняет Андрей Носов.

«Частый автоматизированный редтиминг не обязательно окажется дешевой заменой исследовательской команде. Инструмент нужно настраивать, направлять на актуальные сценарии, проверять его находки и оценивать побочные эффекты исправлений. Если делать это регулярно и качественно, стоимость самого решения и человеческой работы вокруг него может приблизиться к стоимости R&D-команды», - считает Лев Палей.

«Отчет сканера еще не является исправлением. Даже с привычными инструментами анализа защищенности далеко не каждая команда умеет работать так, чтобы получить понятный результат, а не JSON или HTML, который затем некому интерпретировать. Главный вопрос звучит просто: кто будет исправлять находку и кто проверит, что исправление не сломало что-нибудь еще?

Нельзя отдать разработчику отчет и предложить самостоятельно выяснить, что такое prompt injection и как ее закрывать. Это примерно то же самое, что попытаться одним поручением превратить системного администратора в DevSecOps-инженера. Для ИИ-систем появляется отдельная область компетенций на стыке разработки, безопасности и эксплуатации моделей. MLOps уже стал привычнее, а специалисты по LLMOps в России пока встречаются значительно реже.

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

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

До внедрения стоит проверить готовность конкретного ландшафта. Нужно зафиксировать текущее состояние архитектуры, найти разрывы и определить, какие условия должны быть выполнены до появления ИИ во внутреннем контуре. После такого анализа строится дорожная карта: что менять, в какой последовательности и ради какого результата», - заключает Виктор Овчинников.