Сценарий повторяется в десятках организаций: команда собирает пилот, модель классифицирует заявки, руководитель доволен, демонстрация проходит убедительно. Затем начинается масштабирование — и аккуратная картинка рассыпается. Никто не зафиксировал, какие заявки система вправе обрабатывать. Владельца результата нет. Кто отвечает за ошибочную классификацию — команда по данным, владелец процесса, служба поддержки или ИТ — неясно. Модель обновили быстро, риски не пересмотрели. На бумаге пилот успешен, для промышленной эксплуатации он не готов.
Проблема не в качестве модели. Команда собрала технологический прототип, но не систему управления. Это принципиальное различие: пилот проверяет, сработает ли идея в ограниченных условиях, тогда как организационная способность (organizational capability) отвечает на другой вопрос — умеет ли компания регулярно, безопасно и проверяемо использовать ИИ в реальном процессе. Пилот можно вытянуть на энтузиазме нескольких людей. Постоянную работу так не удержать: люди меняются, данные плывут, поставщик обновляет модель, а устные договорённости никто уже не помнит.
| Что есть в пилоте | Что нужно для управляемой способности |
|---|---|
| Демонстрационный сценарий | Границы допустимого применения |
| Команда, которая «знает контекст» | Назначенные роли и зоны ответственности |
| Тестовый набор данных | Управляемые данные и требования к качеству |
| Метрика качества модели | Метрики процесса, риска и контроля |
| Устное понимание ограничений | Документированные ограничения и резервный сценарий |
| Разовый успех | Жизненный цикл: ввод, эксплуатация, изменение, вывод |
| Логи «где-то есть» | Подтверждающие записи для разбора инцидента и аудита |
Инженерная база для управления ИИ уже существует в виде международных стандартов. ISO/IEC 42001:2023 задаёт рамку системы управления ИИ: контекст организации, лидерство, планирование, операционное управление, оценку результативности и улучшение. ISO/IEC 5338:2023 отвечает за жизненный цикл системы ИИ — от договорных и технических процессов до вывода из эксплуатации. ISO/IEC 23894:2023 посвящён управлению рисками: их оценивают не один раз перед запуском, а непрерывно на протяжении всего проекта. Наконец, ISO/IEC 42005:2025 описывает оценку воздействия — допустимое назначение, заинтересованные стороны, возможный вред и пользу. Параллельно действует регуляторный фон: EU ИИ Act для систем высокого риска требует управления рисками, документации, логирования и реального надзора человека, а NIST ИИ RMF продолжает развиваться, включая профиль для доверенного ИИ в критической инфраструктуре. Стандарт нельзя установить как обновление и считать задачу закрытой — требования нужно переводить в роли, процессы и рабочие артефакты.
Практически это означает пять различий, которые стоит зафиксировать на каждом проекте. Первое: модель и система ИИ — не одно и то же. Модель классифицирует или генерирует текст, система ИИ включает данные, интерфейсы, правила применения, мониторинг, людей и порядок изменений. Если смотреть только на модель, причины будущих инцидентов останутся за кадром. Второе: пилот и эксплуатируемая система. Эксплуатируемой системе нужны владелец, бюджет, метрики, поддержка и понятный путь вывода из эксплуатации. Третье: политика и процесс. Написать «мы используем ИИ ответственно» легко, но процесс должен ответить конкретнее — кто, когда и на каком основании разрешает переход из пилота в промышленную эксплуатацию. Четвёртое: назначенная роль и выполненная работа. Строка в матрице ответственности ничего не доказывает без следов работы — оценок рисков, результатов проверок, инцидентов и корректирующих действий. Пятое: человек в контуре и реальный контроль. Кнопка «одобрить» не делает человека контролёром — ему нужны полномочия, время, критерии и возможность остановить процесс.
Минимальный контур управления не требует большого комитета. Достаточно нескольких объектов учёта. Реестр фиксирует все ИИ-инициативы в организации: без него легко пропустить уже работающие решения, особенно когда подразделения подключают LLM или собирают локальные автоматизации без единого учёта. Карточка сценария применения описывает допустимое назначение, запреты, рабочий процесс, роль человека, критерии успеха и первичную оценку риска. Слабый сценарий выдаёт себя уже при заполнении: если команда не может назвать допустимое назначение и запреты, с запуском пилота лучше повременить. Карта владельцев распределяет минимум четыре роли — владелец бизнес-результата, владелец процесса, владелец системы ИИ и владелец риска. В небольшой компании один человек может совмещать несколько ролей, но хуже, когда роли вообще не названы и ответственность переезжает к тому, кто оказался ближе к инциденту.
