Практика внедрения
ИИ-пилот одобрен: чек-лист перехода к промышленной эксплуатации
Семь условий перехода от корпоративного ИИ-пилота к эксплуатации: владельцы, границы, доступы, контроль качества, бюджет LLM, поддержка и пересмотр.
Одобрение пилота ещё не делает ИИ-функцию промышленной. До расширения на новые команды зафиксируйте семь вещей: владельца процесса, границы функции, рабочие доступы, критерии постоянного контроля, бюджет LLM, эксплуатационную ответственность и дату пересмотра. Если хотя бы у критичного пункта нет владельца или подтверждения, расширение лучше не начинать.
Этот чек-лист заполняют для одной проверенной функции и одного контура. Он не заменяет архитектурную документацию, модель угроз, договор или регламент поддержки, а связывает их в понятное решение о готовности к эксплуатации.
Сначала отделите решение от готовности
Протокол после ИИ-пилота отвечает на вопрос, следует ли сценарий масштабировать, доработать или остановить. Положительное решение означает, что согласованные пороги пилота пройдены. Оно не подтверждает автоматически, что готовы промышленная инфраструктура, поддержка, управление изменениями и бюджет регулярного использования.
Переход в эксплуатацию можно начинать, когда команда способна ответить не только «функция показала пригодный результат», но и «мы знаем, кто отвечает за неё завтра, что произойдёт при изменении источника или модели и как функцию остановить без потери контроля».
Семь полей паспорта эксплуатационной готовности
Скопируйте таблицу в рабочий документ. В столбце «Подтверждение» указывайте ссылку на действующий регламент, заявку, журнал проверки или решение владельца, а не общую формулировку «согласовано».
| Поле | Что зафиксировать | Подтверждение готовности |
|---|---|---|
| 1. Владелец процесса | Кто отвечает за бизнес-результат, принимает изменения и может остановить функцию | ФИО или роль, зона ответственности, заместитель |
| 2. Границы функции | Какие операции, роли, входы и результаты входят в промышленный контур; что явно запрещено | Актуальный паспорт функции и перечень стоп-условий |
| 3. Доступы и подтверждения | Кто видит источники, вызывает функцию и подтверждает чувствительные действия | Матрица доступа, отрицательные тесты, порядок отзыва прав |
| 4. Контроль качества | Какие показатели проверяют постоянно, какой порог требует вмешательства | Метрика, порог, источник данных, частота и владелец проверки |
| 5. Бюджет LLM | Кто оплачивает и контролирует потребление, какой лимит и действие при превышении | Ключ заказчика или прокси Тау, лимит, уведомление и стоп-правило |
| 6. Эксплуатация и поддержка | Кто следит за доступностью, источниками, инцидентами и обращениями пользователей | Канал поддержки, сроки реакции, журнал изменений, схема эскалации |
| 7. Пересмотр | Когда и после каких событий решение проверяют заново | Дата, обязательные события пересмотра и состав участников |
1. Назначьте одного владельца результата
Комитет может согласовать запуск, но у процесса должен быть один владелец, который отвечает за пригодность результата и имеет право остановить функцию. ИТ отвечает за технический контур, ИБ — за требования безопасности, партнёр — за согласованный объём внедрения. Эти роли не заменяют владельца бизнес-процесса.
В рабочей карточке запишите роль владельца, заместителя, способ связи и перечень решений, которые он принимает без нового проектного комитета.
2. Заморозьте проверенные границы функции
Перенесите в промышленный контур ту версию функции, которую проверяли: тот же результат, разрешённые источники, роли, модель или класс моделей, правила подтверждения и условия остановки. Расширение на новую задачу или подразделение — отдельное изменение, а не техническая настройка уже принятого сценария.
Используйте паспорт ИИ-функции как базовую спецификацию. Рядом сохраните версии конфигурации и источников, которые соответствуют итоговой серии испытаний.
3. Повторите проверки доступа в рабочем контуре
Пилотные права и тестовые учётные записи редко совпадают с промышленными. До запуска проверьте положительные и отрицательные сценарии для реальных ролей: разрешённый пользователь получает нужный источник, запрещённый — не получает его, а чувствительное действие останавливается до подтверждения.
Готовую структуру ролей, источников и действий возьмите из матрицы доступа и подтверждений. Отдельно укажите, кто отзывает доступ при переводе или увольнении сотрудника и за какое время изменение должно вступить в силу.
4. Превратите приёмочные показатели в постоянный контроль
На пилоте показатели помогают принять решение. В эксплуатации они должны вовремя обнаруживать ухудшение. Для каждой критичной метрики укажите четыре элемента: источник данных, порог, частоту проверки и владельца реакции.
Например, долю результатов с существенными правками можно проверять еженедельно на подтверждённой выборке. Но сам порог команда устанавливает по требованиям процесса; универсального допустимого процента нет. Если меняется состав задач, способ измерения или проверяющий, новую серию нельзя безоговорочно сравнивать со старой.
Исходные определения и поля сохраните из рабочей таблицы приёмки.
5. Отделите бюджет платформы, внедрения и LLM
В Тау Хаб стоимость платформы и потребление LLM считаются раздельно; внедрение также оплачивается отдельно. LLM подключается по ключу заказчика либо через прокси Тау. В эксплуатационном паспорте укажите выбранную схему, владельца бюджета, лимит потребления, источник отчёта и действие при превышении.
Не переносите в бюджет сценарные 800 ₽ за час и гипотезу роста производительности на 25% как доказанный эффект. Их можно использовать только как допущения модели, пока фактическая серия не дала сопоставимых данных. Методика разделения затрат и эффекта приведена в статье об экономике пилота.
6. Закрепите поддержку и управление изменениями
До запуска определите:
- куда пользователь сообщает об ошибке или недоступности;
- кто классифицирует инцидент и имеет право приостановить функцию;
- кто обновляет источники и устраняет конфликт версий;
- какие изменения требуют повторной приёмки;
- где сохраняются версии конфигурации, решения и результаты проверки.
Повторная приёмка нужна как минимум после изменения границ функции, критичного источника, правил доступа, формата обязательного результата или способа подключения LLM. Для обновления базы знаний используйте владельцев и версии из реестра источников.
7. Назначьте дату и события пересмотра
Даже стабильная функция не должна считаться принятой навсегда. Укажите ближайшую календарную дату пересмотра и события, которые запускают внеплановую проверку: инцидент доступа, устойчивый выход за порог качества, заметное изменение потребления LLM, новая категория пользователей или изменение обязательного источника.
NIST AI Risk Management Framework рассматривает управление рисками ИИ как работу на протяжении всего жизненного цикла, а NIST AI RMF Playbook: Govern связывает её с документированными ролями, ответственностью и надзором. Страницы проверены 24 сентября 2026 года. Предложенный паспорт — практический шаблон Тау Хаб, а не обязательная форма NIST.
Иллюстративный пример передачи функции
Команда решила масштабировать подготовку проектов протоколов встреч. Пример ниже показывает заполнение формы и не является результатом клиента Тау Хаб.
| Поле | Решение |
|---|---|
| Владелец | Руководитель проектного офиса; он утверждает критерии пригодности и остановку функции |
| Границы | Проект протокола только по разрешённой расшифровке; отправка участникам выполняется человеком |
| Доступ | Руководители проектов видят комнаты своих проектов; роль без доступа не получает расшифровку |
| Контроль | Еженедельная выборка проверенных протоколов; критичная ошибка с решением или ответственным запускает разбор |
| LLM | Прокси Тау; месячный лимит и уведомление владельцу бюджета заданы отдельно |
| Поддержка | ИТ принимает инцидент, владелец процесса оценивает смысловую ошибку, ИБ разбирает нарушение доступа |
| Пересмотр | Через месяц после запуска и внепланово после изменения источника, модели или правил доступа |
Такой паспорт не обещает экономию времени. Он показывает, что у функции есть управляемые границы и ответственные. Экономический вывод делают отдельно по фактическим операциям и полной стоимости.
Когда запуск нужно отложить
Не расширяйте пилот, если выполняется хотя бы одно условие:
- нет владельца, который может остановить функцию;
- промышленная роль или источник не прошли отрицательный тест доступа;
- нельзя связать ухудшение качества с измеряемым порогом и владельцем реакции;
- регулярное потребление LLM не имеет бюджета или лимита;
- неизвестно, кто принимает инциденты и обновляет источники;
- изменения конфигурации не оставляют версии и не запускают повторную проверку.
Формулировка «разберёмся после запуска» означает, что проект пока остаётся пилотом.
Как провести встречу передачи в эксплуатацию
- Владелец процесса показывает протокол решения и границы проверенной функции.
- ИТ подтверждает промышленный контур, поддержку и журнал изменений.
- ИБ проверяет реальные роли, источники, отрицательные тесты и порядок отзыва доступа.
- Финансовый владелец подтверждает раздельные бюджеты платформы, внедрения и LLM.
- Участники назначают владельцев метрик, пороги вмешательства и события повторной приёмки.
- В итоговой карточке ставят статус по каждому из семи полей: готово, требуется действие или блокирует запуск.
Промышленный запуск готов, когда по каждому критичному полю есть не обещание, а владелец, проверяемое условие и подтверждение. Заполните карточку для одной функции, закройте блокирующие строки и только после этого расширяйте число пользователей или процессов в Тау Хаб.