Демонстрация модели доказывает только возможность получить ответ. Она не доказывает, что автоматизация безопасна, повторяема и полезна в реальном процессе.
До запуска нужно проверять всю цепочку: входные данные, модель, инструменты, бизнес-правила, участие человека и финальное действие. Результат считает код или подтверждает ответственный человек, а не та же модель, которая его создала.
Определите принятый бизнес-результат
Единицей может быть правильно направленная заявка, подтверждённая запись документа или черновик без существенной переписки. Красивый ответ сам по себе не является результатом.
Начните с карты процесса из дорожной карты внедрения AI. Зафиксируйте разрешённые действия, обязательные согласования и абсолютные запреты.
- обязательные поля и схема выхода
- порог качества и недопустимые ошибки
- лимит задержки и стоимости принятой операции
- условия эскалации и ручной проверки
Соберите эталонный набор
Эталонный набор — версионируемая коллекция входов с согласованными ожидаемыми результатами. Добавьте обычные и редкие случаи, неполные записи, противоречия, разные языки и вредоносные инструкции.
У каждого примера должны быть ID, ожидаемый результат, допустимые вариации и причина включения. После изменения системы сначала прогоняйте старый набор, затем добавляйте новые случаи.
Где возможно, считайте кодом
JSON, обязательные поля, идентификаторы, вычисления, ссылки и права проверяйте детерминированно. Смысл, тон и контекст оставляйте ответственному человеку.
Считайте долю принятия, существенных исправлений, ложных действий, эскалаций, задержку и стоимость. Делите статистику по языку, типу документа и уровню риска.
Проверяйте отказы и враждебные входы
Отключите внешний сервис, верните timeout, отправьте дубль, уберите поле и превысьте лимит. Система должна безопасно остановиться, сохранить следы и не повторить необратимое действие.
Файлы и страницы могут содержать косвенные инструкции. Применяйте меры из статьи о prompt injection: минимальные права, изоляцию инструментов, проверку выхода и согласование важных действий.
- prompt injection и конфликтующие команды
- повреждённые или слишком большие файлы
- частичный ответ API и rate limit
- повторы и изменение порядка событий
- доступ к чужим объектам
Используйте теневой режим
В теневом режиме AI видит реальный поток и выдаёт рекомендацию, но не совершает финальное действие. Сравнивайте его решение с текущим процессом и разбирайте расхождения.
К ограниченному пилоту переходите после покрытия обычных и исключительных ситуаций. Ограничьте команду, процесс, права и используйте обратимые результаты.
Заранее задайте go, pause и no-go
Пороговые значения запишите до результатов. Иначе команда подгонит определение успеха под слабый пилот.
Одного среднего качества недостаточно. Несанкционированное действие, повреждение записи или неспособность остановиться могут означать no-go независимо от общей точности.
- Пройти структурные тесты и проверку прав.
- Достичь порогов по каждой критичной категории.
- Пройти security- и failure-тесты.
- Доказать эскалацию и ручную остановку.
- Назначить владельцев мониторинга и инцидентов.
Сделайте evals постоянной функцией
Модели, промпты, инструменты и API меняются. Храните конфигурацию каждого прогона и повторяйте проверку после существенных изменений.
В чеклисте AI-governance разобраны владельцы изменений, доказательств и исключений. NIST объединяет работу в Govern, Map, Measure и Manage.
Ошибка, которую я поймал до публикации
В моём трёхъязычном конвейере сервер однажды сохранил символ замены в двух больших кириллических HTML-полях. Черновики выглядели нормально, но посимвольное сравнение обнаружило разрыв многобайтного UTF-8 символа.
Статьи остались черновиками. Я повторно передал полные тела с фиксированным Content-Length, снова получил записи и сравнил все 21 поле. Публикация продолжилась только при нулевом расхождении.
После этого HTTP-код успеха перестал быть критерием целостности: сохранённый объект и публичная страница должны совпасть с проверенным исходником.
Вопросы и ответы
Сколько тестов достаточно?
Универсального числа нет. Покройте критичные категории и продолжайте, пока новые случаи перестают находить важные классы ошибок.
Можно ли одной моделью оценивать другую?
Можно как вспомогательный сигнал. Критическое решение должны определять код, доверенный эталон или ответственный человек.
Что такое теневой режим?
AI обрабатывает реальные входы, но не совершает финальное действие. Это показывает производственные различия при ограниченном риске.
Когда повторять тесты?
После смены модели, промпта, инструментов, прав, источников, схем и бизнес-правил, а также регулярно после запуска.
Нужны ли реальные данные?
Используйте минимизированные и разрешённые данные. Начните с синтетических, затем подключайте контролируемый реальный поток.
Операционный лист контроля
До согласования занесите каждый контроль в таблицу: владелец, доказательство, порог и дата следующей проверки. Фраза «контролировать качество» не исполнима. Правило «операционный владелец каждый понедельник проверяет долю существенных исправлений и ставит процесс на паузу выше согласованного порога» можно проверить.
Свяжите контроль с последствием для бизнеса. Если ошибка схемы может повредить карточку клиента, опишите containment и reconciliation. Если всплеск стоимости объясняется сезонным объёмом, задайте контекст, защищающий от ложной эскалации.
Версионируйте промпты, схемы, политики, инструменты и внешние зависимости. Результат без конфигурации нельзя воспроизвести. У исключений должны быть причина, владелец и срок окончания, иначе временный обход станет невидимой постоянной политикой.
Отрепетируйте человеческий путь. Назначенный владелец должен найти доказательства, остановить или ограничить workflow, включить fallback и объяснить состояние без просьбы к самому AI диагностировать себя.