Пилот ИИ отлично работает на демо. Почему дальше он застревает

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

Команда крупной организации собирает пилот ИИ для обработки заявок. Модель классифицирует обращения, предлагает оператору ответ и иногда сама заполняет поля в 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 использует риск-ориентированный подход (risk-based approach). Для систем ИИ высокого риска он задаёт требования к управлению рисками, документации, логированию, информации для внедряющей организации, надзору человека, устойчивости, кибербезопасности и точности.

• NIST AI RMF в 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. Условие вывода из эксплуатации:

Половина полей осталась пустой? Шаблон тут ни при чём. Скорее всего, пилот пока держится на неявном знании команды.

Короткий инженерный спринт: девять шагов

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

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

Шаг 2. Заполните карточку пилота для пяти самых заметных инициатив. Текст полировать не надо, сейчас важнее найти пустоты.

Шаг 3. Назначьте владельцев. Не нашли владельца? Такой пилот рано считать кандидатом на масштабирование.

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

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

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

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

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

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

Пять фраз, после которых стоит насторожиться

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

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

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

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

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

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

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

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

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

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

Что здесь делает системный инженер

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

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

С чего начать

Для первого шага хватит трёх артефактов:

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

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

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

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

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