Почему пилоты ИИ не масштабируются? У них нет системы управления

Собирательный кейс: демонстрация есть, системы нет

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

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

Формально пилот успешен. Но инженерно он не готов.

Это не история про плохую модель. Это история про отсутствие системы управления.

Главная ошибка: пилот принимают за организационную способность

Пилот отвечает на один вопрос: может ли идея сработать в ограниченных условиях.

Способность организации (organizational capability) отвечает на другой вопрос — может ли компания регулярно, безопасно и проверяемо использовать систему ИИ в реальном процессе.

Это разные объекты управления. Путаница между ними ломает масштабирование.

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

Стандарты дают детали, но не собирают систему за вас

За последние годы вокруг управления ИИ появилась нормальная инженерная база.

ISO/IEC 42001:2023 задаёт рамку системы управления ИИ (AI management system): контекст организации, лидерство, планирование, поддержку, операционное управление, оценку результативности и улучшение. Это не стандарт про одну модель, это управленческий контур для организаций, которые разрабатывают, поставляют или используют системы ИИ.

ISO/IEC 5338:2023 описывает процессы жизненного цикла системы ИИ (AI system life cycle). В нём видна связь с системной и программной инженерией: договорные процессы, организационные обеспечивающие процессы, процессы технического управления и технические процессы. В части ИИ отдельно заметны непрерывная проверка, эксплуатация, сопровождение и вывод из эксплуатации.

ISO/IEC 22989:2022 нужен как словарь. В нём система ИИ описана как инженерная система (engineered system), которая выдаёт контент, прогнозы, рекомендации или решения для заданных человеком целей.

ISO/IEC 23894:2023 даёт рамку управления рисками ИИ. Там риск рассматривается не как отдельная таблица в конце проекта, а как процесс с контекстом, оценкой, обработкой и мониторингом.

ISO/IEC 42005:2025 фокусируется на оценке воздействия системы ИИ (AI system impact assessment). Для предприятия это особенно полезно: надо описывать допустимое назначение, недопустимое применение, заинтересованные стороны, среду развёртывания, возможный вред и пользу.

Есть и внешний регуляторный фон:

• (EU AI Act)[https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai] строится на риск-ориентированном подходе (risk-based approach) и для систем ИИ высокого риска говорит об управлении рисками, документации, логировании, информации для внедряющей организации, надзоре человека, устойчивости, кибербезопасности и точности.

• (NIST AI RMF)[https://www.nist.gov/itl/ai-risk-management-framework] в 2026 году продолжает развиваться, включая профиль для доверенного ИИ в критической инфраструктуре.

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

Пять различий, без которых тяжело обсуждать ИИ проекты

Первое различие — модель и система ИИ.

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

Второе — пилот и эксплуатируемая система.

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

Третье — политика и процесс.

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

Четвёртое — назначенная роль и выполненная работа.

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

Пятое — человек в контуре и реальный контроль.

Если человек только нажимает “одобрить” без полномочий, времени, критериев и возможности остановить процесс, это не контроль. Это декорация.

Минимальный контур управления пилотом ИИ

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

1. Реестр

Сначала надо знать, какие инициативы по ИИ уже есть.

Минимальные поля: название, владелец, процесс, пользователи, поставщик или внутренняя команда, статус, данные, критичность, ссылка на артефакты.

Без реестра организация часто не знает, где у неё уже работает ИИ. Особенно если команды используют внешние программные сервисы по подписке (SaaS), большие языковые модели (LLM) или внутренние автоматизации без единого учёта.

2. Карточка сценария применения

Сценарий применения ИИ надо описывать как управляемую единицу процесса.

Минимальная карточка:

Слабый сценарий обычно видно уже по этой карточке. Если команда не может сформулировать допустимое назначение и запреты, пилот еще рано запускать.

3. Карта владельцев

У системы ИИ не может быть только “владельца модели”.

Нужны минимум четыре роли:

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

4. Первичная оценка риска

Первичная оценка риска до пилота должна отвечать на простые вопросы:

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

• насколько легко заметить ошибку;

• можно ли откатить последствия;

• есть ли чувствительные данные;

• зависит ли система от внешнего поставщика;

• есть ли риск, что пользователи начнут применять систему шире заявленного сценария.

На этом шаге не нужна тяжёлая методология. Нужен ранний фильтр.

5. Первичная оценка воздействия

Оценка воздействия отличается от оценки риска.

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

Для пилота достаточно короткой проверки:

• кто прямо затронут результатом работы системы;

• кто затронут косвенно;

• какое предсказуемое неверное применение возможно;

• какие ошибки будут дорогими;

• какие ограничения надо поставить до эксперимента;

• какие признаки заставят остановить пилот.

Эта логика хорошо ложится на ISO/IEC 42005:2025: допустимое назначение, недопустимое применение, заинтересованные стороны, среда развёртывания, вред и польза.

6. План жизненного цикла

Система ИИ должна иметь жизненный цикл до первого запуска.

Минимальные состояния:

1. Идея.

2. Описание сценария применения.

3. Первичная оценка риска и воздействия.

4. Пилот.

5. Проверка готовности к промышленной эксплуатации.

6. Промышленная эксплуатация.

7. Мониторинг.

8. Изменение.

9. Вывод из эксплуатации.

Это не бюрократия. Это управляемые состояния.

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

7. Контрольная точка перед промышленной эксплуатацией

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

Перед запуском надо проверить:

• утверждено допустимое назначение;

• назначены роли;

• пройдена оценка риска и воздействия;

• определены критерии приёмки;

• есть резервный сценарий;

• есть мониторинг;

• есть маршрут обработки инцидента;

• понятно, какие логи и решения сохраняются;

• известны признаки для повторной оценки.

“Работает на демонстрации” не равно “готово к эксплуатации”.

8. Мониторинг и подтверждающие записи

После запуска надо измерять не только качество модели.

Минимальный набор:

Метрика должна иметь владельца и порог действия. Иначе она превращается в красивый график.

9. Управление изменениями

Для системы ИИ изменением может быть не только новая версия модели.

Список длиннее:

• переобучение модели;

• замена модели поставщика;

• новый набор данных;

• изменение системной инструкции модели (system prompt);

• новые разрешения на инструменты (tool permissions);

• изменение базы поиска по документам (retrieval);

• новая группа пользователей;

• перенос в другой бизнес-процесс;

• изменение регуляторного контекста.

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

Таблица: пилот против управляемой способности

Эта таблица полезнее большинства моделей зрелости. По ней сразу видно, где пилот ещё не стал системой.

Шаблон: карточка пилота ИИ

Ниже минимальный шаблон, который можно положить в Confluence, Notion, Jira или внутренний реестр.

Карточка пилота ИИ 1. Название: 2. Владелец бизнес-результата: 3. Владелец процесса: 4. Владелец системы ИИ: 5. Владелец риска и соответствия требованиям: 6. Рабочий процесс: 7. Допустимое назначение: 8. Вне рамки применения: 9. Пользователи: 10. Прямо затронутые стороны: 11. Другие заинтересованные стороны: 12. Входные данные: 13. Выход системы: 14. Роль человека: 15. Поддерживаемое решение: 16. Критерии успеха: 17. Сценарии отказа: 18. Предсказуемое неверное применение: 19. Первичная оценка риска: 20. Первичная оценка воздействия: 21. Ограничения пилота: 22. Какие записи сохранять: 23. Контрольная точка перед эксплуатацией: 24. Метрики мониторинга: 25. Признаки для повторной оценки: 26. Условие вывода из эксплуатации:

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

Что можно сделать за 9 шагов

Не надо сразу строить офис управления ИИ. Начните с короткого инженерного спринта.

Шаг 1. Соберите реестр инициатив по ИИ: внутренние пилоты, программные сервисы по подписке, инструменты на больших языковых моделях, автоматизации в подразделениях.

Шаг 2. Для пяти самых заметных инициатив заполните карточку пилота ИИ. Не полируйте текст. Цель: найти пустоты.

Шаг 3. Назначьте владельцев. Если владелец не находится, пилот нельзя считать кандидатом на масштабирование.

Шаг 4. Проведите первичную оценку риска и воздействия. Один час на инициативу достаточно для первого прохода.

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

Шаг 6. Опишите контрольную точку перед промышленной эксплуатацией для тех, кто идёт дальше.

Шаг 7. Определите подтверждающие записи: какие согласования, логи, решения, метрики и инциденты должны сохраняться.

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

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

Типовые ошибки

“У нас есть человек в контуре”.

Спросите, что этот человек может остановить. Если ничего, контроля нет.

“Поставщик за это отвечает”.

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

“Риск оценим перед запуском”.

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

“Это всего лишь внутренний ассистент”.

Внутренний ассистент может иметь доступ к документам, CRM, почте, коду, требованиям и техническим решениям. Вопрос не в слове “ассистент”, а в полномочиях, данных и последствиях ошибки.

“Модель обновилась, но процесс тот же”.

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

Где здесь системная инженерия

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

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

Именно на этих различениях обычно держится масштабирование.

Что взять в работу

Для первого шага достаточно трёх артефактов:

• реестр инициатив по ИИ;

• карточка пилота ИИ;

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

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

Я продолжу эту серию практическими разборами: как описывать сценарий применения, как ставить контрольную точку перед запуском и как не потерять управление после первого обновления модели. Короткие заметки и шаблоны по теме собираю в Telegram-канале AI for Systems Engineering.

Источник: habr.com