Закон об ИИ вступил в силу — заказчик переписал ТЗ на середине проекта: как мы пересобрали создание ИИ-агента и почти ничего не потеряли

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

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

Что вообще изменилось на практике

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

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

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

Что мы поменяли в текущем проекте

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

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

Мы переехали на GigaChat Pro для тяжёлых задач и оставили локальную open-source-модель для более простых. День работы — переписать вызовы, ещё день — прогнать тесты, ещё пару дней — сравнить качество на боевых примерах. Разница, если честно, оказалась не такая драматичная, как боялись. GigaChat Pro на задачах разбора русскоязычных спецификаций отработал уверенно; там, где раньше нужно было докручивать промпт под особенности иностранной модели, тут местами стало проще.

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

Что осталось как было

Самое приятное — большая часть архитектуры пережила переезд без изменений. Наш собственный слой оркестрации, MCP-серверы к 1С и к внутренним каталогам, механика согласования шагов, аудит вызовов инструментов, разбор входящих на скиллы — это всё было завязано не на конкретную модель, а на интерфейс. Модель — это просто «мозг», который можно поменять. Всё, что вокруг, — наше и остаётся нашим.

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

Где реально пришлось попотеть

Не в коде. В документации.

Раньше у нас был README проекта, схема архитектуры и файл с промптами. Этого хватало. Теперь у каждого нашего ИИ-агента для бизнеса появился отдельный документ — что-то вроде технического паспорта. В нём: какая модель, какой версии, где физически развёрнута, какие данные обрабатывает, какие данные не обрабатывает никогда, как логируются запросы, сколько хранятся логи, кто имеет к ним доступ, что делать при инциденте, кто ответственный за модель со стороны заказчика.

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

Что это значит для новых проектов

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

Куда мы имеем право отправлять данные. Что вообще нельзя отправлять никуда, только внутри контура. Есть ли у заказчика уже развёрнутый GigaChat Pro или YandexGPT, или мы разворачиваем локальную open-source-модель. Как мы будем это доказывать проверке. Кто внутри компании заказчика — назначенный «владелец модели».

Это не бюрократия. Это то, что задаёт всю остальную архитектуру. Модель для российского контура и модель для внутреннего эксперимента команды разработчиков — это разные проекты. Требования к ним разные. Стоимость разная. Скорость выхода разная.

Иностранные модели — GPT, Claude, Gemini — по-прежнему интересны для нас как ориентир. Мы их разбираем в командных встречах, смотрим релизы, гоняем на нейтральных задачах, чтобы понимать, куда движется индустрия. Но когда речь про промышленное внедрение в российской компании с чувствительными данными, разговор идёт про GigaChat Pro, YandexGPT, T-lite, Cotype и локальные open-source-варианты. И это, по-моему, правильно.

Итог

Сентябрьский закон многим показался поводом занервничать. У нас он превратился в повод пересобрать процесс. Не потому что раньше мы делали плохо, а потому что теперь у нашей внутренней «гигиены» появился внешний свидетель, и это заставляет писать документы, которые ты и так знал, что надо писать.

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

Мы для себя вывели правило: если ИИ-агент нельзя объяснить проверяющему на одной странице, значит, его рано выпускать в бой. Раньше это было мнением. Теперь — норма.