Как и почему умирает ИИ-внедрение: пять bottlenecks

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт. 

Больше двадцати лет моя команда занимается обменом данными между корпоративными системами, и про то, как именно этот слой убивает ИИ-проекты, я уже подробно разбирал в предыдущей статье на Хабре. 

Интеграция — это только одно из пяти узких мест, на которых ломается реальное ИИ-внедрение. Дальше идут атаки на агентов, регуляторика, разрыв стоимости разработки и сценарий, которого нет в голове у заказчика. Со мной в этом разборе еще трое: ИИ-архитектор Андрей Носов, Team Lead пентестер Сергей Зыбнев и директор по информационной безопасности компании Вебмониторэкс Лев Палей. 

Не модель, а фабрика данных, где буксует ИИ

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

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

Виктор Овчинников, руководитель решения Digital Q.Integration от Диасофт: «Сейчас ИИ — тренд, и в него идут практически поголовно. Обычно это выглядит так: реализуется пилот, команда показывает, что в принципе решение работает. Понимает, какие данные нужны под конкретную задачу, наполняет ими хранилище, модель что-то считает, прогнозирует, заказчику нравится. Проблема возникает, когда это решение пытаются тиражировать, чтобы оно работало на постоянной основе. Но ведь, для быстрой реакции данные должны попадать в модель моментально. А архитектура решений, с которыми я работаю, те же банковские ландшафты, на это изначально не была заточена. Есть аналитические задачи, под них данные в хранилища наполняются хорошо если раз в сутки, а то и раз в неделю. Дать оперативную обратную связь на данные, которые появятся к следующему дню, физически нереально. Например, звонит клиент, ему нужно сделать персонализированное предложение на основе того, что о нем уже известно. Но зачастую информация устаревшая, а пока агент или оператор обновит ее через сервисы, пройдет минут сорок. Клиент уже положил трубку. Нужно еще понимать, что данные по клиенту могут находиться в сотнях разных систем, никак не подготовленных под ИИ. Они могут лежать в совершенно разных контурах. Плюс банки — ребята консервативные, у них обычно легаси, которое работает и которое не трогают. Многие АБС, особенно унаследованные, работают по pull: сами никому никуда ничего не отдают, эти данные надо запросить. И вот именно здесь идет стопор, а не в моделях».

Сергей Зыбнев, Team Lead пентестер: «В целом это все решается. Если система legacy и в нее не вносится много изменений, то ее можно дешево автоматизировать скриптами — так делали десятилетиями, это быстро и надежно, breaking changes там скорее всего не появятся. Но если система новая и в ней постоянно меняется логика, то скриптами не отделаешься: данные сложно нормализовать заранее. Вот здесь хорошо работают LLM-агенты, которые сами могут сходить за данными, сами их нормализовать и сами отправить дальше. Только надо понимать, что у такого агента весь контекст по умолчанию считается доверенным вводом, и это отдельная боль с безопасностью, которую придется решать отдельно».

Андрей Носов: «Сегодня между тем, как пользователь хочет работать с данными, и тем, сколько инженерных костылей скрыто под капотом, сохраняется огромный разрыв. Если говорить о векторных хранилищах, то вектор — это, по сути, набор чисел и бинарных значений, и никто не хочет вручную заносить информацию в таком виде. Пользователь ожидает взаимодействия на естественном языке. Вся современная инженерия в значительной степени строится вокруг того, чтобы сократить расстояние между человеческим способом работы и машинной архитектурой. В апреле 2026 года особенно заметным стал тренд на отказ от векторов — это LM-вики Андрея Карпаты, PageIndex и схожие форматы. Пользователь просто заполняет markdown-файлы и связывает их между собой гипертекстом. Это пока не идеальный UX, но он уже гораздо ближе к человеческой логике. А значит, со временем сам разрыв между интерфейсом и внутренним устройством систем будет постепенно исчезать».

Виктор Овчинников:«Мы сейчас говорим немного о другом уровне задачи. Всё, что обсуждалось до этого, — это поиск и работа с данными, которые уже существуют внутри системы. Я же говорю об этапе раньше — о том, как эти данные вообще появляются. Ключевое слово здесь — „приходят“. Когда данные уже получены, с ними можно делать что угодно: нормализовать, обогащать, передавать дальше. Но проблема в том, что многие легаси-АБС не поддерживают push-модель и работают только по pull-запросам. То есть сначала их нужно заставить отдать данные. Этим, в частности, и занимается интеграционная платформа: она собирает информацию из разнородных источников, нормализует её и сводит в единый контур. И только после этого можно говорить о том, что у модели вообще появляется материал для работы».

Андрей Носов: «Если зайти на крупное производство и посмотреть, как устроено их хранилище данных, там окажется весь возможный зоопарк форматов: JSON, markdown, обычные файлы, PDF без распознанного текстового слоя, аудиозаписи и многое другое. Объединить всё это „на лету“ невозможно — данные всё равно приходится агрегировать. Вопрос лишь в том, насколько тяжёлой и сложной будет эта агрегация. На сегодняшний день самым удобным остается безвекторный подход: когда не требуется дополнительных преобразований, а данные сохраняются в формате, максимально близком к plain text. В текст в конечном счёте можно перевести всё — включая таблицы. Это сразу убирает один уровень накладных расходов и снижает количество потенциальных ошибок».

Дрифт, инъекции и supply chain: чем теперь ломают ИИ

Но, допустим, фабрика данных как-то собрана: разнородные источники сведены, push-pull проблема для легаси-АБС решена интеграционной платформой, форматы агрегируются на лету. Это, к сожалению, только начало списка. Параллельно с инфраструктурой поставки на компанию опускается совершенно новая поверхность атак, под которую классические WAF, EDR и антивирусы не предусматривались по построению.

И речь не про экзотику. У модели появилось штатное свойство дрифтовать, у LLM-агента контекст считается доверенным вводом по умолчанию, а в дереве зависимостей популярного движка вроде LiteLLM на днях оказывался инфостиллер. Сюда же подоспели OWASP Top 10 под LLM и под агентов, MITRE ATLAS и приказ ФСТЭК. 

Андрей Носов: «У любой модели есть фундаментальное свойство — она начинает дрифтовать с первого дня после выхода в продакшн. При этом на практике часто применяются механики, о которых публично почти не говорят, хотя именно они этот дрифт усиливают. Вариантов дрифта несколько. Например, дрифт контекста напрямую влияет на расход токенов и, соответственно, на бюджет. Систему можно незаметно для владельца „разогнать“ так, что стоимость одного обращения к модели вырастет в сотни или даже миллионы раз по сравнению с первоначальными расчетами. В итоге стоимость для пользователя постоянно увеличивается, и компания начинает задаваться вопросом, почему экономика проекта перестала сходиться, хотя на старте всё выглядело иначе. Дрифтовать могут и сами данные: если постоянно бомбардировать модель бессмысленными запросами, она постепенно начинает под них адаптироваться. То же самое происходит и с промптом — его можно искусственно раздувать или, наоборот, сужать. Причем сужение промпта не менее опасно: модель начинает „тупеть“, ответы становятся слабее, а вслед за этим начинается отток пользователей. Для пользователя часто достаточно одного откровенно плохого ответа, чтобы больше не возвращаться к системе».

Сергей Зыбнев: «Прежде всего важно разделять, о каких именно технологиях идет речь. Это может быть классическое машинное обучение, Data Science, CV — распознавание изображений и текста, — или LLM. Все эти системы принципиально различаются, и атаки на них тоже устроены по-разному. Сегодня LLM — пожалуй, самый сложный и уязвимый сегмент. У таких систем чрезвычайно широкая поверхность атак, прежде всего потому, что раньше в кибербезопасности просто не существовало атак естественным языком. Классические средства защиты — WAF, антивирусы, EDR — к этому почти не адаптированы. Единственный класс решений, который хотя бы частично способен сдерживать подобные угрозы, — это DLP-системы, поскольку они изначально обучались анализу текстов и изображений.

Полтора года назад был показательный случай. Один пользователь из любопытства зашел на сайт крупного зарубежного агрегатора авиабилетов, изучил их чат-бота, понял, что тот подключен к базе знаний, и попробовал вносить в нее изменения. Выяснилось, что сам текст подменить нельзя, но ссылки — можно. В результате уже через час бот вместо каталога авиабилетов отправлял пользователям ссылку на порносайт. Это видели все, кто с ним взаимодействовал. Компания долгое время даже не замечала проблему, потому что тогда почти никто всерьез не занимался safety-метриками, evals и безопасностью LLM-систем в целом. История висела достаточно долго, компания понесла серьезные репутационные потери и потом была вынуждена заниматься антикризисным PR. И, конечно, никому не хотелось бы однажды увидеть нечто подобное на главной странице собственного сайта».

«Раньше обновления OWASP Top 10 выходили раз в год, и этого было достаточно. Сейчас ситуация изменилась: отдельно существует OWASP Top 10 for LLM Applications в редакции 2025 года, отдельно — OWASP Top 10 for Agentic Applications 2026 года. Параллельно развивается MITRE ATLAS — база, описывающая тактики атак на ИИ-системы. Иными словами, индустрия уже формализовала и каталог уязвимостей, и модели атак, и базовые стратегии защиты. К этому году рынок наконец перестал воспринимать атаки на ИИ как нечто экзотическое, и стандарты безопасности начали догонять реальность.

Проблема в другом: наличие стандартов еще не означает, что компании научились с ними работать. У большинства команд разработки до сих пор нет системного понимания того, что такое prompt injection, ролевые атаки через обфускацию или контекстный дрифт. И это становится очевидно практически при любом пентесте LLM-сервиса в продакшне».

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

Андрей Носов: «Когда речь о RAG, вся проблема именно в логической связанности. Как только мы начинаем чанки дробить и получать из них вектора, мы автоматически создаем разрыв логики. Векторные системы работают связанными, и в этом их структурное ограничение. Этим же отчасти объясняется, почему сейчас так сильно потянули векторлес-направление: оно частично снимает разрыв по построению. И, что не менее важно, оно отвечает на запрос разработчиков, у которых поверхность атак на векторных чанках получалась шире, чем хотелось бы».

Сергей Зыбнев: «В этом году я участвовал в проекте, где пытался ломать LLM-агента в одной российской системе. Там была очень показательная проблема: всё, что попадает в контекст агента, по умолчанию воспринимается как доверенный ввод. Для модели контекст — это просто набор слов и чисел без чёткого разделения на системный промпт, пользовательский запрос или служебные данные. Всё лежит в одном текстовом пространстве. Чем больше объём контекста, тем тяжелее агенту с ним работать. Это как разница между тем, чтобы запомнить четверостишие и поэму на сто строк. Для модели действует тот же принцип: оперировать мегабайтами данных значительно сложнее, чем килобайтами. Поэтому агенту критически нужна память — собственная база знаний или RAG-механизм. Но этого недостаточно. Обязательны и RBAC, и ABAC — разграничение прав доступа по ролям и атрибутам. Иначе очень быстро возникает сценарий, при котором пользователь запрашивает чужие данные и получает их — либо модель сама начинает галлюцинировать и отправляет информацию не тому адресату. Для банковской системы это уже не просто техническая ошибка, а полноценная утечка персональных данных со всеми последствиями: нарушением 152-ФЗ и требований ФСТЭК», — указывает он.

«В этом году произошла затяжная supply chain-атака, которая затронула огромное количество репозиториев. Насколько помню, за ней стояла группировка TeamPCP: они выстроили цепочку компрометации через npm- и Python-пакеты, используемые во множестве популярных проектов. В эту цепочку, например, попал LiteLLM — один из крупнейших движков для роутинга запросов между разными AI-провайдерами. Через заражённые пакеты распространялся инфостиллер, собиравший данные с серверов, куда выкатывались обновления. По той же схеме зацепило и Trivy — один из самых популярных бесплатных инструментов для DevSecOps и анализа безопасности.

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

Лев Палей, директор по информационной безопасности компании Вебмониторэкс: «История с LiteLLM показательна, но сама проблема возникла далеко не вчера. Если вспомнить первые крупные инциденты с open source-компонентами, механизм был тем же самым. Это классическая история про отсутствие AppSec на старте: не контролируешь репозиторий — получаешь подмененный пакет; не следишь за компонентной базой — получаешь закладку. Для open source-среды подобные риски в определенной степени встроены в саму модель разработки, потому что система держится на доверии к коммитерам и репутации участников сообщества. Проблема в том, что сейчас эта старая болезнь просто переехала в инфраструктуру вокруг LLM. Вся современная AI-экосистема построена на гигантских деревьях зависимостей из npm и PyPI. При этом инструменты AI/LLM-безопасности пока решают проблему практически теми же методами, что и классическая разработка десять лет назад: через SBOM, контроль зависимостей, верификацию пакетов и цифровые подписи».

117-й приказ ФСТЭК, новая цена данных

Допустим, поверхность атак закрыта рудиментарно: DLP стоит, дрифт-мониторинг крутится, RBAC прописан, supply chain отслеживается через SBOM. Параллельно с этим на ИИ-внедренца закрывается еще одно окно, регуляторное. В этом году ФСТЭК выпустил 117-й приказ, который у многих команд изменил архитектуру буквально по абзацам.

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

Сергей Зыбнев, Team Lead пентестер: «117-й приказ ФСТЭК — один из ключевых документов последних месяцев для рынка ИИ. В нём достаточно подробно прописано, как допустимо обучать модели, какие данные можно использовать, а какие — нет. Для меня один из главных выводов в том, что обучать модели на персональных данных теперь прямо запрещено. Для многих компаний это стало болезненным изменением, потому что раньше в LLM-системы нередко без особой фильтрации загружали практически весь массив клиентских данных. Маскирование информации — задача дорогая и технически сложная, особенно если речь идет не о стандартных полях вроде ФИО или паспортных данных, а о менее структурированных идентификаторах: СНИЛС, ИНН и других сущностях с разной длиной и форматами записи. Конечно, прежний подход был удобнее. Но безопасность почти всегда требует компромисса между удобством и контролем. С появлением 117-го приказа баланс явно сместился в сторону безопасности, и для разработчиков это уже вполне ощутимая статья расходов».

Андрей Носов, ИИ-архитектор: «Со СНИЛСами и ИНН история действительно интересная, на ней и Presidio в лоб не справляется. Чтобы это правильно зашифровать, маскирование делается трехэтапное. Сначала аббревиатуры и буквенные сокращения расшифровываются, потом строятся мотивированные связки между сущностями — то есть какой идентификатор кому принадлежит в пределах документа, — и только после этого идет само маскирование. Если делать как обычно, в один проход по регуляркам, то на чуть более вольном документе все рассыпается: идентификатор повисает в воздухе, либо привязывается не к той персоне. 117-й приказ нам в этом смысле помог: он зафиксировал, что персональные данные дальше пускать никуда нельзя, и тем самым сделал нормальное маскирование обязательным звеном, а не «как-нибудь потом доделаем».

Сергей Зыбнев: «Здесь возникает довольно показательный парадокс. Формально проблему можно решить просто: подменять персональные данные в запросах. Условный Сергей Зыбнев во всех документах превращается в Иванова Ивана Ивановича — с точки зрения конфиденциальности всё корректно. Но если пользователю нужна реальная работа с персональными данными, такой подход быстро ломает сам продуктовый сценарий. В итоге человек получает таблицу, целиком состоящую из “Ивановых Иванов Ивановичей”, и для него система перестает быть полезной. 117-й приказ эту проблему не снимает — он лишь задает рамки безопасности. А сам конфликт между требованиями compliance и нормальным UX всё равно придётся решать архитектурно: через RBAC и ABAC-модели доступа, AI-Gateway и другие механизмы, которые давно стали стандартом в enterprise-разработке, но до AI-стека по-настоящему добрались только сейчас», — указывает он.

Виктор Овчинников: «Насколько я это понимаю — возможно, не идеально с технической точки зрения, потому что в этой части я разбираюсь хуже, — в основе должна лежать единая база нормализованных и безопасных данных. То есть среда, где информация уже собрана, структурирована и связана между собой: по продуктам, инструментам, процессам и различным контурам системы. Тогда модель работает не с разрозненными источниками, а с уже подготовленной витриной данных: строит гипотезы, формирует предложения, проверяет их и принимает решения на едином контексте. А вот наполнение этой витрины — задача интеграционных платформ и специализированных продуктов, которые умеют “пристегивать” общую структуру к конкретным легаси-системам и разным источникам данных. Иначе агенту приходится самостоятельно ходить за информацией в десятки систем, каждый раз проходя актуальную авторизацию. Это не только медленнее и дороже, но и существенно расширяет поверхность атак».

Лев Палей, директор по информационной безопасности компании Вебмониторэкс: «Если честно, сама идея единой витрины данных довольно сильно противоречит тому, как на архитектуру смотрит информационная безопасность. В нормальной enterprise-среде данные разных классов и категорий должны храниться раздельно: с разными политиками маскирования, разными контурами доступа и разными сроками хранения. Но вопрос не только в хранении. Не менее важна модель доступа к этим данным. Сергей правильно говорил про RBAC, однако одной ролевой модели недостаточно. Нужна еще и грамотная маршрутизация потоков данных — чтобы информация попадала в нужный контур в корректном формате и с правильным уровнем доступа. А это уже отдельная архитектурная задача. Поэтому концепция единой витрины в её “чистом” виде, на мой взгляд, нежизнеспособна. Это не означает, что не нужны нормализованные данные. Это означает, что разные классы потребления должны получать данные в разном виде и через разные шлюзы доступа».

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

И самое интересное в том, что ничего принципиально нового здесь не придумали. Концепция Control Plane / Data Plane, которая сегодня лежит в основе защиты AICE-систем, практически один в один перенесена из классической сетевой архитектуры — той самой, на которой строилась базовая Cisco-сетевка ещё много лет назад. Логика осталась прежней: из менее защищенного сегмента в более защищенный напрямую попасть нельзя, а обратный поток в определенных сценариях допускается. По сути инструментарий почти не изменился. Есть протокол, есть политика доступа — и эта же модель теперь просто накладывается на трафик LLM-систем. И, что важно, она вполне работает».

Сергей Зыбнев: «Концепция, которой сегодня особенно не хватает AI-инфраструктуре, — это Zero Trust. В классической сетевой безопасности ее в России пытаются внедрить уже много лет, и только сейчас этот подход начинает по-настоящему приживаться. В мире ИИ находится еще в самом начале пути, потому что архитектурно мы до сих пор склонны доверять и контексту модели, и ее собственным ответам. Минимальный набор мер, который имеет смысл внедрять с самого старта, — это детерминированные проверки до вызова агента и после получения ответа. Причем именно на уровне кода и инфраструктуры, а не в формате просьбы к модели: “пожалуйста, не показывай чужие данные”. Кроме того, поверх классической RBAC-модели необходим ABAC — атрибутный контроль доступа, который понимает, какой тип данных может попасть в ответ для конкретной роли и конкретного сценария. С учетом требований 117-го приказа ФСТЭК всё это уже перестает быть рекомендацией из категории “было бы неплохо”. Это постепенно становится полноценным compliance-требованием, которое регуляторы и аудиторы будут проверять напрямую».

Сценарий, evals и safety: что мерить, чтобы агент не сошел с ума в проде

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

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

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

Сергей Зыбнев, Team Lead пентестер: «Как говорил Артемий Лебедев, заказчик сам не знает, какой дизайн он хочет. Эта формула универсальна: заказчик никогда точно не знает, чего хочет. Отсюда следующий по важности тезис. Чтобы грамотно тестировать LLM-систему, надо строить evals и safety, и это разные вещи. Evals — это про воспроизводимость, точность и качество ответов. Safety — про то, что модель отвечает пользователю безопасно. И safety не равно security: security защищает инфраструктуру и данные, а safety следит за тем, чтобы модель не выдала пользователю чего-то такого, что ему повредит. Все это надо уметь мерить, иначе система деградирует в проде, а вы об этом даже не узнаете. А мерить нечем, если мы не знаем метрик. А метрики берутся только из понимания того, как система должна себя вести. Этот замкнутый круг разрывается через сценарий».

Виктор Овчинников, руководитель решения Digital Q.Integration от Диасофт: «У нас под такие проекты всегда закладывается этап обследования. Задача обычно приходит расплывчатая: ее описывают пять человек, и каждый видит ее по-своему. Этап нужен, чтобы разобраться, что хочет каждый, собрать из этого внятное техническое задание и согласовать его со всеми участниками. Только после этого начинается проработка архитектуры и конкретного решения. Бизнес-аналитик в этой истории отвечает за то, что должно быть на входе, что на выходе, какой результат мы хотим получить и где эти данные можно взять. Системный аналитик отвечает за то, как это сделать: как связать сервисы, какие брокеры и шины использовать. Без обеих ролей внятного ТЗ не получится, а без внятного ТЗ у LLM-системы не появится и внятных метрик».

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

Сергей Зыбнев: «Guardrail для LLM — это по сути тот же WAF, только применительно к языковой модели. Механизм похож: в основе те же if-чики, сверху та же ML-обвязка, которой нужны данные для обучения. И болезнь та же, что у WAF: чем больше данных в нее загружаешь, тем выше шанс дойти до точки, когда модель переобучилась и начинает блокировать слишком много. Представьте, что WAF блокирует ваших клиентов. Сто клиентов, каждый по 5 тысяч, в сумме 500 тысяч недополученной прибыли в день. Перемножьте на год. К LLM требования ровно такие же. Только есть неприятный момент: классическими if-чиками от prompt injection защититься невозможно. Когда LLM ломает LLM, заранее предсказать все разнообразие обфускаций, текстовых уловок, смен роли и контекстного дрифта нереально. Поймать такое можно только по факту в проде. Либо нужна очень большая red team, которая ловит атаки за вас и постоянно обогащает гардрейлы».

Андрей Носов: «Полноценную red team по деньгам потянет не каждый. Но есть инструментарий, который временно вас прикрывает: red-teaming-инструменты, проактивно атакующие вашу же систему. Условно, раз в неделю вы сами себя ломаете чем-нибудь вроде nuclei и тут же обогащаете промпты автоматически собранными гардрейлами. Это не заменит человеческой команды, но базовый слой закрывает. Дальше напрашивается следующее звено: что-то вроде DSPy, которое навешивается по периметру, и LLM на его основе сама себя выправляет. У этой связки даже название уже устоялось: MLSecOps и LLMSecOps».

Сергей Зыбнев: «Тезис хороший, но к нему есть еще более сильный контртезис. Сколько вы знаете команд разработки, которые на сегодня хотя бы научились пользоваться nuclei? Допустим, инструменты существуют, и даже есть те, которые работают без помощи ChatGPT. Из них уже меньший процент имеет интерпретируемый человеком результат, а не сухой JSON-вывод, с которым непонятно что делать. И главный вопрос: кто это все будет фиксить и не сломает ли фикс еще что-нибудь? Отдать разработчику HTML из такого инструмента со словами «погугли, что такое prompt injection» — это все равно что попытаться сделать из сисадмина DevSecOps за пятницу. MLSecOps в России более-менее распространен, LLMSecOps пока встречается крайне редко. Так что нанимать или обучать отдельного человека все равно придется, и в бюджете на ИИ-внедрение это отдельная строка, про которую часто забывают».

Лев Палей, директор по информационной безопасности компании Вебмониторэкс: «Если у меня и есть одна закрывающая мысль, то она про то, что почти все, чем нам сейчас приходится заниматься в ИИ-безопасности, в обычной информационной безопасности уже было решено. Control Plane / Data Plane придумали ребята с базовых цисковых сетей. SBOM и контроль зависимостей применяли в AppSec до того, как кто-то услышал слово LiteLLM. Раздельное хранение классов данных и ролевая модель доступа существуют со времен первых витрин. AI-Gateway это просто специализированный шлюз, который умеет говорить с LLM-трафиком на его языке. Хорошая новость: индустрия не голая, инструментарий по сути тот же. Плохая — этот инструментарий все-таки придется правильно положить, а не написать бумажку про политику и считать вопрос закрытым», — резюмирует он.

Виктор Овчинников, руководитель решения Digital Q.Integration от Диасофт: «Со своей стороны я бы выделил вот что. Внедрить ИИ ровно настолько реалистично, насколько у вас выстроена нижележащая работа с данными — без нее верхние слои просто ни на чем стоят. И это не про то, что ИИ невозможен или сложен, это про то, что компании, которые сейчас вкладываются в нормализацию, в связность сервисов, в нормальную интеграционную платформу с актуальными данными, через два-три года будут гораздо ближе к тому, чтобы реально получать с ИИ деньги, а не только показывать им презентации. Все, что обсуждалось выше: дрифт, гардрейлы, маскирование, роутинг моделей, evals и safety, — это надстройки. Фундамент это данные. И именно с него имеет смысл начинать».