ИИ из пилота в прод: 10 развилок корпоративного внедрения

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

Конечно, это укрупнение (внутри каждой группы есть подгруппы), но в целом картина такая:

• Бизнес-подразделения — прагматики. Им нужен измеримый результат: больше заработать или меньше потратить. Важны сроки, ответственность и понятная экономика. Конкретные модели и технологии для них вторичны — пока результат предсказуем, управляем и укладывается в бюджет/ROI. Для бизнеса ИИ — это просто инструмент. Как новый станок или новая CRM. Он должен окупаться.

Пример: «Нужно, чтобы среднее время ответа клиенту снизилось с 5 минут до 30 секунд, а стоимость одного обращения упала на 20%»

• Команды инноваций и внедрения ИИ — энтузиасты. обычно первыми видят улучшения: собирают прототипы, проверяют гипотезы, показывают возможности, запускают пилоты. Без них большинство инициатив просто не стартует. Но их вклад часто воспринимают как «теорию», потому что у них другая метрика успеха: скорость экспериментов и качество демонстрации, а не окупаемость, сопровождение и риски в целевом контуре.

Пример: Команда за выходные собирает ассистента для HR, который идеально отвечает на вопросы. На демо все аплодируют. Но никто не спрашивает: «А что будет, если одновременно зайдут 500 сотрудников? А если спросят про увольнение — не нарушит ли это трудовой кодекс?»

• ИТ, ИБ, эксплуатация, финансы и юристы отвечают за последствия: безопасность, доступность, аудит, сопровождение и итоговую стоимость владения. Поэтому их позиция выглядит строже. Именно она определяет, можно ли запускаться в целевом контуре и масштабировать решение без роста рисков и затрат.

Пример: «Где будут храниться данные клиентов? Кто имеет доступ к логам? Что произойдёт, если модель ответит неверно и клиент подаст в суд? А сколько будет стоить, когда запросов станет в 100 раз больше?»

Часто бывает так, что в пилоте главный драйвер — это направление инноваций (быстро проверить гипотезу и показать ценность), а в проде включаются направления бизнеса и ответственности (эффект, SLA, безопасность, аудит, стоимость владения). Если заранее не договориться о метриках успеха, границах данных, целевом контуре, ролях и зоне ответственности, то ИИ-решение отлично работает на демо-данных и процессах, а в боевой среде начинает тормозить.

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

Это те же нефункциональные требования, которые мы привыкли формулировать для «обычного» программного обеспечения.

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

Отдельная тема — инфраструктура. Особенно при работе с большими моделями она может оказаться настолько дорогой, что «ломает» экономику проекта.

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

Тогда приходится возвращаться к архитектуре и переделывать её, что всегда значительно дороже и организационно сложнее.

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

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

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

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

Когда система становится частью реального процесса, появляются ограничения, которые нельзя решить в моменте.

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

Скорость

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

Нагрузка и пики

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

Требования безопасности

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

Экономика

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

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

— Мария, финансовый контролёр

Поддержка и ответственность

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

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

— Михаил, руководитель эксплуатации и сопровождения

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

О чём мы договариваемся в самом начале, до старта проекта

Эти несколько вопросов экономят недели разработки.

Кто будет пользоваться системой и в каких операциях?

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

Какова цена ошибки?

Если совсем просто, то есть всего два варианта.

1. Там, где ошибка обратима и почти ничего не стоит: черновики документов, подсказки, первичная классификация, извлечение полей, сравнение версий.
2. Там, где ошибка превращается в операционный инцидент: действия в корпоративных системах, официальные ответы клиентам, изменения цен и условий, операции с персональными данными.

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

Какой профиль нагрузки и где бывают пики?

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

Какие требования к времени до результата?

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

Требования безопасности

Во многих проектах ключевой вопрос — где физически работает система: строго внутри периметра, в частном облаке, или допустим внешний API. Рядом обычно появляются уточнения по данным: какие категории можно передавать, какие — нет; как устроено хранение запросов, ответов и служебных журналов.

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

— Игорь, инженер по ИБ

Откуда система берёт данные компании и как поддерживает актуальность?

Источники чаще всего одни и те же: документы и регламенты, справочники, статусы в CRM/ERP/ЭДО и другие системы, карточки контрагентов, договорные условия. Чтобы потом не спорить, мы заранее проговариваем частоту обновлений, «источник правды», поведение при конфликте данных и что происходит, если источник временно недоступен.

Что обычно нужно для аудита и разбора ошибок?

Минимальный набор, который почти всегда оказывается полезным: какие источники использовались, какие проверки и правила сработали, какая версия модели/инструкций/поискового индекса была активна, кто подтверждал действие. И отдельно — ограничения на хранение (что нельзя сохранять в логах), сроки хранения и доступ к журналам.

Как будем устанавливать обновления?

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

Какие критерии успешности пилота?

Пилот не должен превращаться в бесконечное исследование в стиле «Не видать конца и края». Если заранее не задать критерии успешности пилота и условия остановки, команда быстро и воодушевлённо уходит в реализацию самых смелых идей, и только потом обнаруживает, что требуемые показатели качества, безопасности или стоимости просто недостижимы в текущих условиях проекта. Поэтому сразу согласуем цель, метрики и пороги, срок и бюджет этапа, критерии остановки и то, кто и когда принимает решение о следующем шаге (Go/No-Go).

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

Развилки внедрения: решения, которые определяют класс ИИ-системы

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

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

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

Смысл карты развилок — собрать ИИ-систему, которая реально «вписывается» в ограничения конкретной компании: периметр и ИБ, бюджет, доступность данных, наличию команды, ожидания по SLA и допустимый риск.

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

1. Контур исполнения: внутри периметра, внешний сервис или гибрид
2. Роль ИИ: помощник или система, которая выполняет действия
3. Роль сотрудника: точки подтверждения и пороги эскалации
4. Источник фактов: общие знания модели или корпоративный контекст
5. Работа с корпоративными данными: Prompting / RAG / Дообучение модели
6. Архитектура моделей: одна модель «на всё» или каскад моделей
7. Нагрузки и сбои: режимы при перегрузке и недоступности зависимостей
8. Наблюдаемость: минимальные логи или трассировка по шагам
9. Обоснование ответа: просто результат или результат со ссылками на источники
10. Управление изменениями: дисциплина промышленной эксплуатации

Развилка 1. Контур исполнения: внутри периметра, снаружи или гибрид

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

1.1. Внутри периметра

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

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

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

Контроль — это не только данные, но и доступность

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

И здесь контроль перестаёт быть только юридической категорией или частью информационной безопасности, и становится категорией эксплуатационной. Если раньше внешний провайдер отвечал за доступность API, скорость работы модели и частично за стабильность качества, то теперь это полностью зона ответственности компании.

Что ИТ-подразделение получает в нагрузку к модели, развёрнутой внутри контура

При размещении модели внутри периметра возникают две большие группы задач.

Первая — инфраструктура и надёжность. Вам нужно обеспечить инфраструктуру (GPU/CPU, сеть, хранилища с быстрым доступом), резервирование каналов и серверного оборудования, мониторинг всех компонентов и реакцию на инциденты. Сюда же относится планирование серверной ёмкости: как система выдержит пиковые нагрузки? Что произойдет, если две команды одновременно запустят тяжелые задачи? Как удерживать целевые SLO (целевой уровень качества обслуживания), если что-то пойдет не так? Получается, что вы создаете свого внутреннего провайдера, даже если формально называете это по-другому.

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

Об экономии и реальной стоимости

Self‑hosted часто обосновывают простой арифметикой: «платить провайдеру за каждый запрос дорого, проще купить железо». Иногда это так, но только если считать совокупную стоимость владения (TCO). Львиную долю затрат составляет ФОТ:

• инженеры для поддержки кластера;

• специалисты по безопасности и аудиту;

• процессы релизов и тестовые контуры;

• поддержка и разбор инцидентов.

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

Практика больших объёмов

На малых нагрузках и в пилотных проектах многие из этих проблем можно «пережить» вручную. Но на больших объёмах «просто поднять модель в контейнере» не всегда получается.

Возьмем примеры, где счёт идёт на десятки сотен запросов к LLM (большим языковым моделям). Там быстро выясняется, что основная сложность — не в самом факте запуска модели, а в том, чтобы поддерживать работу системы стабильной. Контролировать очереди и задержки, вовремя замечать деградации, безопасно обновлять софт, ловить регресс качества до того, как его увидят пользователи, и уметь быстро откатываться назад. Это требует совершенно другого порядка эксплуатации, чем «поставил и забыл».

Какие роли появятся в штате

Даже если команда небольшая, выделяются несколько зон ответственности, которые нужно закрепить явно:

• Платформа и эксплуатация: доступность, мониторинг, инциденты, мощность (человек, который знает, как починить vLLM в три часа ночи).
• Качество и изменения: версии моделей и окружения, регресс-тесты, критерии допуска релиза (человек, который понимает, почему новая квантизация «хуже» предыдущей).
• ИБ и комплаенс: политики логирования, обработка чувствительных данных, аудит и допустимые интеграции.

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

Признаки, что ваша организация готова к self-hosted

Хороший критерий — наличие процесса изменений и измеримости.

• У вас есть контрольные сценарии, по которым вы проверяете качество работы модели «до и после»?
• Есть метрики задержек и ошибок с понятными порогами срабатывания?
• Есть механизм отката на предыдущую версию?
• Назначен ли ответственный за инциденты?

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

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

1.2. Во внешнем контуре

На старте внешний контур выигрывает у self-hosted по всем статьям, кроме безопасности. Вам не нужно думать о стойках с GPU, резервировании каналов и планировании серверной ёмкости. Масштабирование берёт на себя провайдер, а пробовать разные модели можно хоть каждый день, пока не найдётся самая подходящая рабочая конфигурация.

Но ровно до тех пор, пока проект не переходит в стадию промышленной эксплуатации.

Пять вопросов перед переходом в промышленную эксплуатацию

1. Какие данные вообще можно передавать провайдеру и в каком виде? Можно ли отправлять сырые тексты договоров, или их нужно предварительно обезличивать?
2. Что именно сохраняется на стороне провайдера? Промпты, ответы, извлечённые фрагменты, журналы событий — какие гарантии в договоре с провайдером и технические настройки подтверждают, что эти данные не используются не по назначению?
3. Где и сколько хранятся наши данные? В какой юрисдикции лежат логи, подпадают ли они под регуляторные требования?
4. Какие условия договора с провайдером нас защищают, а какие — нет? Кто отвечает за инцидент, если он произойдёт по вине провайдера?
5. Что происходит при инцидентах? Как мы узнаем о деградации сервиса — по метрикам или от разгневанных пользователей?

Тонкость, которую часто недооценивают: изменения моделей без вашего ведома

Если в self-hosted вы сами контролируете версии моделей и окружения, то с внешним API вы этот контроль теряете. Провайдер может обновить модель, ужесточить фильтры содержания, поменять параметры — и поведение вашей системы сразу изменится, без вашего ведома.

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

Эффект «догоняющей сложности»

Внешний контур коварен тем, что он расслабляет команду на старте, а потом неожиданно догоняет. Сначала кажется, что вы купили «модель как услугу». А в промышленной эксплуатации выясняется: вы всё равно строите полноценную систему вокруг модели.

Сравните: в self-hosted вы берёте на себя явную ответственность за платформу, людей и процессы. С внешним API возникает обманчивое чувство, что забот больше нет. Но они никуда не деваются — просто меняют форму. Вам всё ещё нужны:

• мониторинг качества и задержек;
• регрессионные тесты (чтобы ловить изменения провайдера);
• обработка ошибок и таймаутов;
• планы действий при деградации внешнего сервиса.

И да, про SLA провайдера. Его «99.9% доступности» — это не ваши SLO глазами пользователя. Если у провайдера «просела» конкретная модель или выросли задержки, на вашем сервисе это всё равно отразится. И объяснять это пользователям придётся вам, а не провайдеру. Провайдер может быть «в SLA», а ваш сервис — уже нет.

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

— Владимир Лещенко, директор центра компетенций по развитию искусственного интеллекта компании «Росатома» «Цифрум»

Когда внешний контур — это оптимальный вариант

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

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

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

Когда регуляторные требования дороже денег

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

1.3. Гибридный вариант

Часто оказывается самым практичным вариантом: часть сценариев и данных остаётся внутри, часть — допускает внешний контур.

На практике редко кто выбирает что-то одно. Чистый self-hosted даёт контроль, но нагружает эксплуатацией. Чистое внешнее API — быстро на старте, но делает вас зависимым от провайдера. Гибрид пытается взять лучшее от обоих подходов. Вопрос в том, как им управлять, чтобы не получить удвоенную сложность.

Гибрид обычно строится так:

• внешний контур допускается только для полностью обезличенных данных и некритичных операций (например, анализ открытых источников);

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

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

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

Как организовать гибрид

Чтобы гибрид работал стабильно, нужны формализованные правила:

• какие классы данных куда допускаются;

• какие сценарии считаются критичными;

• как выполняется маскирование/обезличивание перед передачей во внешний контур;

• как ведётся аудит, чтобы решения были воспроизводимыми и проверяемыми.

Развилка 2. Роль ИИ в процессе: помощник или исполнитель действий

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

2.1. Режим помощника

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

2.2. Режим исполнителя

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

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

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

Развилка 3. Сотрудник: где нужна проверка?

Обычно заранее разводятся два режима участия сотрудника.

3.1. HITL (human-in-the-loop) – человек внутри контура управления

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

3.2. HOTL (human-on-the-loop) — человек над контуром выполнения

Система может выполнять шаги автоматически в заранее заданных границах, а сотрудник подключается по сигналам: при выходе за лимиты, конфликте данных, нестандартной ситуации, снижении уверенности и других.

В большинстве внедрений встречается комбинация: HITL — для высокорисковых и юридически значимых операций, HOTL — для массовых типовых операций в заранее определённом низкорисковом контуре.

Как только ИИ-система может инициировать действия, вопрос уже не в качестве текста. Вопрос — кто несёт ответственность и где зафиксировано, кто и что подтвердил.

— Алексей, операционный директор

Развилка 4. Управление: свобода или регламент?

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

Почему это важно

Сложные бизнес-задачи почти никогда не бывают «чистой LLM», «чистым ML» или «чистой бизнес-логикой». Обычно в одном решении одновременно нужны:

• работа с неопределённостью (ML/LLM);
• жёсткие ограничения и правила (политики, вычисления, комплаенс);
• контекст и связи (справочники, документы, базы знаний);
• поиск лучшего варианта (оптимизация);
• объяснимость и трассируемость (аудит, фиксируемые шаги, логирование).

4.1. Полагаемся на правила и процессы, а ИИ применяем только там, где нужно

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

Что это даёт в промышленной эксплуатации

• Контекст для модели формируется по правилам: какие источники разрешены, что фильтруется правами, какие лимиты на объём и состав контекста.
• Действия в системах выполняются только через разрешённые операции: проверка прав, ограничения, логирование, понятный механизм остановки.

Технически это обычно означает наличие оркестратора (workflow-слоя), который управляет шагами и состояниями, вызовами данных и моделей, подключением сотрудников (human-in-the-loop), обработкой ошибок и контролем контекста. Посмотреть, как работает оркестратор, можно здесь.

4.2. Полагаемся только на ИИ

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

Как выбирать

Практический критерий здесь один: что контролирует передачу контекста в LLM и запуск действий в корпоративных системах — явный процесс или ИИ-компонент.

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

В реальных внедрениях чаще всего используется явный workflow-контур:

1. Связать модель с внутренними данными
   Поиск по базе знаний и документам, retrieval-подходы — чтобы модель готовила ответы на основании актуальных источников данных и с учётом прав.
2. Задать поведение ИИ-системы
   Правила, бизнес-логика, workflow, контрольные проверки, human-in-the-loop в ключевых точках.
3. Встроить решение в существующие процессы
   Проектирование работы ИИ-системы: кто инициирует действие, кто подтверждает, где фиксируется результат, как обрабатываются исключения и что делать при недостатке данных.

Признаки, что мы отдали слишком много управления на сторону ИИ:

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

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

Как устроены ИИ-агенты, можно посмотреть у нас в блоге:

• https://blogs.epsilonmetrics.ru/ai-agenty-i-agentic-reasoning/
• https://blogs.epsilonmetrics.ru/ii-agenty-i-multiagentnye-sistemy/

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

Развилка 5. Откуда берём данные: достаточно общих знаний модели или нужен организационный контекст

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

5.1. Только знания модели, без внутреннего контекста

Если модель работает без доступа к корпоративным источникам, она лучше всего подходит для универсальных задач, где не требуется внутренняя фактура: подготовить черновик, сделать резюме и структуру, переформулировать текст, сравнить формулировки «как тексты», выполнить первичную классификацию по заданным категориям.

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

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

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

5.2. Подключаем данные компании: организационный контекст

Если система должна действовать на основании внутрикорпоративных или отраслевых данных, ей нужен организационный контекст: документы и регламенты, справочники, статусы и записи в CRM/ERP/ЭДО, карточки контрагентов, лимиты, история решений.

Для работы с текстовыми знаниями наиболее распространённый механизм — RAG (retrieval-augmented generation). В этом подходе модель получает не только вопрос пользователя, но и релевантные фрагменты из корпоративных источников во время выполнения. По сути, RAG — это инженерный контур: документы заранее приводятся к удобному формату, делятся на фрагменты, индексируются вместе с метаданными (например, тип документа, дата, подразделение, уровень доступа), а затем по запросу подбираются наиболее релевантные фрагменты и добавляются в контекст, чтобы ответ строился на внутренних источниках, а не «из головы».

Структурированный контекст обычно подключается иначе: через контролируемые запросы к системам (CRM/ERP/ЭДО) с проверкой прав, валидацией и логированием того, какие записи использованы и по какой причине. Это важно и для диагностики, и для аудита, и для объяснимости результата.

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

Развилка 6. Как работать с корпоративными данными: Prompting, RAG или Fine-tuning

Если система должна использовать данные компании, следующий шаг — понять, как именно это организовать. Есть три базовых способа «подключить» корпоративные данные к LLM (и на практике их почти всегда комбинируют):

1. Prompting (инструкции в запросе) — задаём модели контекст и правила: что учитывать, чего избегать, в каком формате отвечать, плюс несколько примеров.
2. RAG (Retrieval-Augmented Generation, генерация с поиском) — перед ответом ищем релевантные фрагменты в корпоративной базе знаний (документы, регламенты, внутренние системы) и добавляем найденное в контекст модели.
3. Fine-tuning (тонкая настройка / дообучение) — дообучаем модель на примерах, чтобы закрепить нужное поведение: формат, терминологию, классификацию, стиль ответа.

Дальше разберём, где достаточно «лёгких» настроек, а где нужен более промышленный подход. Спойлер: в большинстве корпоративных внедрений хватает связки RAG + workflow — далее рассмотрим, почему.

6.1. Prompting: быстро и просто, но быстро упирается в масштаб и контроль

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

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

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

1. Данные не помещаются в контекст. Да, современные модели могут обрабатывать огромные объёмы — до миллиона токенов. Но это не значит, что туда можно включить всю базу знаний компании (примеры можно посмотреть у нас в блоге). Представьте: вам нужно проанализировать годовой отчёт на 500 страницах, 5 регламентов и 100 диалогов с клиентами. Всё это физически не поместится в одно сообщение. Приходится выбирать фрагменты вручную, а значит, модель видит только то, что вы выбрали, а не то, что действительно нужно для ответа.

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

3. Чем больше документов и сценариев, тем сложнее каждый раз собирать «промпт-конструктор». Сегодня вы положили в запрос один набор инструкций, завтра — другой. Результат становится лотереей: качество ответа меняется от раза к разу, а время на подготовку запроса растёт.

4. Попробуйте задать один и тот же вопрос дважды, немного изменив формулировку или порядок примеров в промпте. Скорее всего, ответы будут различаться. Теперь представьте, что вы хотите построить на таких ответах аналитику, отчёты или диалоги с клиентами. Как проверять качество? Как сравнивать результаты вчера и сегодня? Воспроизводимость — это фундамент любой серьёзной системы, и промптинг его не даёт.

5. Внутренние документы компании нельзя просто подложить в промпт и отправить во внешний API. Для корпоративных данных требуются контроль доступа, логирование, аудит — кто, когда и что запрашивал. Это вопрос архитектуры и процессов.

Промптинг идеален, когда:

• нужны общие знания модели (без привязки к вашим внутренним данным);
• объём информации небольшой и стабильный;
• вы готовы мириться с подготовкой каждого запроса вручную.

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

Понимание этих ограничений не значит, что промптинг плох. Это значит, что у каждого инструмента есть своя задача. Для прототипов, разовых задач и исследований он идеально работает. Для систем, работающих с живыми корпоративными данными и поддерживающих бизнес-процессы, требуется следующий уровень — как минимум, RAG (генерации с дополнением контекста) и чётких рабочих процессов (workflow).

6.2. RAG + workflow: факты и управляемость без обучения модели

RAG отвечает на вопрос: как «дать» модели актуальные внутренние данные компании, не меняя её веса. Система сама находит релевантные фрагменты в корпоративных источниках и добавляет их в контекст запроса.

Как работает RAG, можно посмотреть в нашем блоге:

• Эмбеддинги и семантический поиск
• Graph RAG: как RAG, только c графом знаний
• Мультимодальная RAG и VLM
• Практический гайд: RAG на Llama 2 и FAISS
• Внедрение LLM в компании с использованием RAG

Важно понимать ограничение: RAG всё равно ограничен окном контекста. Поэтому промышленный RAG — это не только поиск, а целый конвейер: (1) подготовка базы знаний → (2) поиск → (3) фильтрация по правам → (4) переранжирование (при необходимости) → (5) сборка контекста → (6) генерация → (7) проверка результата.

В корпоративных проектах RAG почти всегда дополняется оркестрацией (workflow) и правилами. Причина проста: одного поиска недостаточно, когда система встроена в процесс. Нужны:

• контроль доступа и «периметр контекста»: что можно искать, что можно вкладывать в prompt, что можно показывать пользователю;
• ссылки на источники и трассировка: из каких фрагментов сделан вывод;
• аудит и воспроизводимость: тот же запрос + те же версии корпуса/ранжирования → тот же результат;
• стоп-условия и понятное поведение при недостатке данных: “не знаю / нужно уточнение / эскалация на человека”, вместо фантазирования;
• валидация формата/ограничений и участие человека в ключевых точках процесса.

Именно поэтому связка «RAG + управляемый процесс» часто быстрее и надёжнее, чем дообучение модели (п. 6.3.).

6.3. Дообучение модели (Fine-tuning): самый интересный, но дорогой и ресурсоёмкий способ

Fine-tuning (включая SFT/LoRA) нужен, как правило, не для актуальности, а для поведения. То есть факты подаются корректно (например, через RAG/интеграции), но модель систематически «ломает» формат, «путает» классы, нестабильно извлекает поля, не соблюдает терминологию или игнорирует инструкции.

Почему fine-tuning дорогой на старте

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

• Стоимость — это не только обучение модели. В эксплуатации нужны версии данных и модели, воспроизводимые эксперименты, регрессионные проверки, мониторинг качества и механизм отката.

• Fine-tuning может быть технически недоступен или экономически невыгоден. Для некоторых коммерческих моделей он ограничен политиками провайдера или недоступен в нужном периметре. В on-prem вариантах может потребоваться GPU-инфраструктура и компетенции команды, которые не всегда оправданы по экономике.

• Fine-tuning не решает проблему актуальности знаний. Он закрепляет поведение, но не «подключает» новые документы и статусы. Если факты должны быть актуальными, контур данных (RAG/интеграции) всё равно обязателен, а fine-tuning становится надстройкой.

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

Практический вывод для корпоративного внедрения: любой fine-tune или смена модели — это изменение риск-профиля, поэтому это релиз, а не “маленькое улучшение”. Нужен регламент изменений:

• проверяем не только качество, но и корректность поведения: соблюдение запретов, границы доступа, правильная остановка на запрещённых действиях;

• добавляем поведенческие тесты, в том числе для агентных сценариев: работа с инструментами, правами, эскалациями и подтверждениями;

• делаем откат быстрым и штатным: версии модели/адаптера, канареечный запуск, возврат на предыдущую версию без остановки процесса;

• держим страховочную схему: каскад моделей или маршрутизацию, чтобы не переводить весь поток на новую/дообученную модель сразу.

Fine-tuning имеет смысл, если:

• проблема действительно в поведении, а не в недостатке фактов;

• есть достаточный объём размеченных данных и понятный контур оценки;

• у команды есть ресурсы и процессы для обучения и сопровождения;

• ожидаемый эффект нельзя дешевле и надёжнее получить правилами, workflow, валидацией формата, улучшением поиска/ранжирования или маршрутизацией на более сильную модель в сложных случаях.

На практике «золотая середина» выглядит так: RAG даёт факты, workflow даёт контроль, а fine-tuning применяется точечно — там, где проблема действительно в поведении и у команды есть данные и возможности поддерживать этот контур.

Развилка 7. Одна большая модель или каскад малых

В корпоративном ИИ идея «одна универсальная модель на всё» выглядит заманчиво: подключили к базе знаний — и система работает.

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

7.1. Одна большая модель «на всё» редко оптимальна по скорости и стоимости в эксплуатации

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

… Прежде всего, это собственно национальные языковые модели – как фундаментальные, так и малые – для конкретных отраслей.

В.В. Путин, Artificial Intelligence Journey 2025, 19 ноября 2025 года

Gartner также прогнозирует, что к 2027 году организации будут использовать малые, ориентированные на задачи модели как минимум в три раза чаще (по объёму использования), чем универсальные LLM.

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

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

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

Если не нужно, чтобы модель умела делать всё, то зачем за это платить? Логика простая: не платить за избыточную мощность. Мы поток типовых задач решаем малыми моделями, а «тяжёлую артиллерию» используем только для сложных и критичных запросов.

7.2. Каскад из нескольких специализированных моделей

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

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

Экономический эффект каскада обычно складывается из трёх вещей.

• Во-первых, это эффективность по данным: качество растёт не только из-за «обучения побольше», а за счёт композиции — правил, структурированного контекста (RAG/граф/справочники), проверок и ограничений. Это снижает зависимость от больших объёмов разметки и делает поведение более воспроизводимым.
• Во-вторых, это эффективность по вычислениям: дорогая модель не работает «на всём потоке», а включается только по необходимости; часть кейсов закрывается правилами и поиском; контекст формируется структурно, вместо попыток «всё выучить в веса». В результате проще контролировать стоимость и выдерживать целевые задержки.
• В-третьих, это time-to-value: система быстрее доходит до полезного результата, потому что собирается из готовых блоков (поиск + правила + базовая модель + усиленный уровень), а не требует сразу запускать полноценный контур дообучения.

Практически каскад часто выглядит как «базовый контур + эскалация»: условно 70–90% запросов закрываются на базовом уровне, а 10–30% маршрутизируются в усиленный. Конкретные доли зависят от домена и SLA, но сама логика остаётся: большая модель не исчезает — она становится инструментом для сложных и критичных случаев, а не «постоянным двигателем» всей системы.

Ключевой элемент каскада — маршрутизация. Она может выполняться по правилам (например, по типу запроса, наличию данных, риску, ограничениям по времени), может включать компактную модель-классификатор.

Важно учитывать и обратную сторону: каскад требует дисциплины. Без метрик (доля эскалаций, качество по уровням, задержки по этапам, стоимость на запрос, экономический эффект) и стоп-условий плохо спроектированная схема может увеличить суммарную задержку и усложнить сопровождение. Поэтому каскад обычно проектируют как управляемый процесс: с измерением, правилами деградации и понятными условиями, когда система «поднимается» на следующий уровень или переводит кейс в ручной режим.

Развилка 8. Пики и сбои: режимы работы при высокой нагрузке и при сбоях

Дальше возникает вопрос: как система ведёт себя не «в среднем», а под нагрузкой. В корпоративной среде нагрузка часто приходит волнами, а зависимости могут «мигать»: LLM, векторный поиск, OCR, корпоративные API, внешние сервисы.

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

• Жёсткое ограничение при перегрузке: лимиты на число запросов, ограничение параллелизма, отказ части “дорогих” операций.
• Очереди и приоритеты: разделение потоков (например, интерактивные запросы пользователей — отдельно, пакетная обработка — отдельно), квоты по подразделениям или ролям.
• Деградация качества: упрощённый путь обработки, более лёгкая модель, меньше контекста, отключение второстепенных шагов (переранжирование, расширенный OCR, дополнительные источники).
• Перевод в ручной контур: если критичный источник недоступен или резко вырос риск ошибки, система должна уметь корректно остановиться и передать кейс человеку.

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

Развилка 9. Объяснимость и контроль: что фиксируем?

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

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

9.1. Журнал исполнения: минимальный лог или трассировка по шагам

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

Обычно выбирают один из режимов глубины логирования или комбинируют их.

• Минимальный операционный журнал
  Фиксируются метрики и технические параметры: статусы вызовов, коды ошибок, время выполнения, идентификаторы версий компонентов, корреляционные ID. При этом не сохраняются содержимое данных и контекст для модели.
• Выборочная трассировка по шагам и версиям
  Записывается последовательность действий, причины ветвлений, используемые источники и версии компонентов; контент сохраняется по минимуму или в маскированном виде. На практике это часто оптимальный баланс: достаточно информации для диагностики, но без избыточного накопления чувствительных данных.
• Полная трассировка (с контентом и контекстом для модели)
  Сохраняется и контент, и контекст: например, извлечённые фрагменты из базы знаний, промпт, ответ, промежуточные результаты, параметры поиска. Это требует строгих правил доступа и защиты.

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

Главное — чтобы выбранная схема позволяла быстро восстановить картину произошедшего и при этом не создавала лишних рисков из-за хранения чувствительной информации.

Почему пока нельзя полагаться на аудит самой модели

Когда мы говорим об аудите решений, принятых самой ИИ-системой (например, агентом, который совершал действия в корпоративных системах), есть большой соблазн положиться на «рассуждения» самой модели (Chain‑of‑Thought), которые она генерирует в процессе работы. Однако, как показывают исследования коллеги из OpenAI, такие рассуждения могут быть неполными, придуманными задним числом или даже намеренно скрывать информацию (Baker et al. (OpenAI, Mar 2025).

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

9.2. Обоснование: результат или результат с основаниями

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

В промышленной системе “основания” обычно включают три элемента.

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

Развилка 10. Нужен ли процесс управления изменениями

В продакшене меняются и живут несколько слоёв:

• данные и подготовка данных (качество, доступы, маскирование, lineage);
• интеграции и бизнес-правила (валидации, пороги, исключения, маршрутизация);
• контур контекста (поиск/RAG, графы, справочники, индексы и их обновления);
• наблюдаемость и безопасность (логирование, аудит, RBAC/ABAC, политики доступа);
• контроль качества (тесты, «стоп-сигналы», мониторинг метрик качества и стоимости).

Организации часто застревают между пилотом и промышленной эксплуатацией не потому, что «модель плохая», а потому что нет устойчивой инженерной и организационной системы доставки: данных, релизов, наблюдаемости, безопасности и ответственности. Именно этим занимается то, что обычно называют AI engineering / LLMOps: попытка собрать разрозненные практики DataOps, DevOps, ModelOps и новые контуры вокруг LLM-систем в единый повторяемый процесс, чтобы выпуск AI-функций стал предсказуемым и масштабируемым.

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

Поэтому почти всегда нужен процесс управляемых релизов: версионирование, проверки на регрессии, поэтапный выпуск (канареечные/пилотные группы), быстрый откат, а также заранее определённые «стоп-сигналы», которые блокируют развёртывание новой версии при деградации качества, роста стоимости или нарушений по безопасности.

Подробнее о том, как устроена типовая архитектура корпоративных ИИ-систем, можно посмотреть в нашем блоге https://blogs.epsilonmetrics.ru/arhitektura-korporativnogo-ii/.

Вместо заключения

Компании, которые доводят ИИ-пилоты до продакшена, меняют фокус: не «сделали демо», а «построили систему». Становится понятной логика работы: что делается данными и правилами, что — моделями, и как всё это оркестрируется и контролируется. Выстраивается порядок изменений: любые правки сначала проверяем, затем «прогоняем» на контрольном наборе примеров и смотрим, не ухудшилось ли качество по сравнению с предыдущей версией. И всё становится измеримым: качество, стоимость и задержки (время отклика) отслеживаются метриками.

Мне понравилась фраза в блоге Addy Osmani: «AI tools amplify your expertise». В контексте нашей статьи я понимаю эту фразу так: ИИ усиливает то, что у вас есть, причём усиление работает в обе стороны. Если есть грамотный, системный и последовательный подход к построению цифровых решений, то ИИ поможет усилить экспертизу компании, сэкономить на рутинных задачах, и давать стабильный результат. Если нет — ИИ так же быстро усилит проблемы: ошибки, необоснованный рост затрат и может даже замедлить работу компании.

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

Есть идея для автоматизации? Запишитесь к нам на демонстрацию, и мы покажем, как встроить ИИ в бизнес-процессы.