Проще говоря, go/no-go помогает не выпускать систему “на авось”. Команда заранее смотрит критерии готовности: тесты прошли, мониторинг включен, риски понятны, ответственные назначены, rollback готов, доступы ограничены, документация обновлена, а спорные пункты согласованы.
В AI-проектах go/no-go особенно важен, потому что модель может ошибаться непредсказуемо. Перед запуском проверяют evals, guardrails, human approval, качество RAG, логи tool calling, лимиты стоимости, безопасность данных, fallback to human и сценарии incident response.
Хорошее go/no-go решение не должно быть формальностью. Если критерий не выполнен, команда либо принимает no-go и переносит запуск, либо явно фиксирует риск, владельца, временное ограничение и план исправления.
Примеры
- Команда принимает no-go, потому что AI-агент поддержки не проходит тесты на персональные данные.
- Go-решение принято после того, как настроили мониторинг, rollback и approval для write-действий.
- Перед запуском RAG проверяют, что источники свежие, права доступа работают, а ответы содержат цитаты.
- Маркетинговую рассылку не запускают, пока human review не проверил тон, ссылки и сегменты аудитории.
- После инцидента новый релиз проходит go/no-go с дополнительным пунктом про runbook и алерты.
Где используется
- Production-запуск AI-агента или LLM-приложения
- Релиз новой версии, интеграции или workflow automation
- Проверка readiness перед рекламной кампанией или рассылкой
- Контроль рисков перед включением tool calling и write-доступа
- Согласование запуска между продуктом, разработкой, безопасностью и бизнесом
- Фиксация критериев качества, мониторинга, rollback и incident response
- Управление запуском пилота, MVP или enterprise AI-сценария
Связанные термины
Approval workflow
Audit log
Cost monitoring
Definition of Ready
Guardrails
Human approval
Incident response
Least privilege
Частые вопросы
Что входит в go/no-go checklist для AI-агента?
Evals, тесты основных сценариев, guardrails, права доступа, human approval, мониторинг, audit log, лимиты стоимости, fallback to human, rollback, runbook и ответственные за инциденты.
Кто принимает go/no-go решение?
Зависит от риска. Обычно участвуют владелец продукта, разработка, поддержка, безопасность, бизнес-заказчик и тот, кто будет отвечать за работу системы после запуска.
Чем go/no-go отличается от обычного approval?
Approval часто подтверждает одно действие. Go/no-go — решение по запуску целого релиза, процесса или системы с учетом готовности, рисков, критериев качества и плана отката.
Что делать при no-go?
Зафиксировать причину, владельца, критерий готовности, дату повторной проверки и временные ограничения. No-go полезен только тогда, когда понятно, что нужно исправить для следующей попытки.
