Пилот должен пережить плохой вход
Демо заканчивается на удачном примере. Процесс начинается на пустом поле, повторной заявке и вопросе «кто исправит результат?». Хороший пилот заранее содержит неприятные случаи и дату решения о масштабировании.
Первое, что я бы убрал: Считать пилот успешным после одной красивой демонстрации.
Что зафиксировать до демо
- Одна операция и один владелец.
- Baseline до запуска.
- Обычные, неполные и конфликтные входы.
- Журнал ошибок и дата решения о масштабе.
Как довести пилот до рабочего процесса
- Зафиксируй рабочую версию
Сохрани промпты, credentials, версии таблиц, допустимые статусы и пример входа/выхода в одном changelog.
Что увидишь: Понятно, какая версия сейчас используется.
Если не сработало: Перенеси настройки из личного аккаунта в общий рабочий доступ.
- Сделай журнал ошибок
Поля: run_id, input_type, expected, actual, reason, owner, fix, date. Не удаляй ошибочный запуск после исправления.
Сверь: Одинаковая ошибка группируется, а не появляется как десять разных проблем.
Если не сходится: Добавь обязательное поле reason перед закрытием инцидента.
- Проверь исключения
Добавь тесты на пустой вход, дубль, неверный формат, отсутствие права, таймаут и неполный ответ модели.
Что должно совпасть: Каждая ошибка имеет retry, stop или human handoff.
Если ответ другой: Не расширяй пилот, пока исключение просто исчезает из журнала.
- Масштабируй по одному измерению
Сначала увеличь объём или добавь один канал, но не делай оба изменения одновременно. Сравни качество и стоимость с базой.
Перед запуском: Можно понять, что изменило результат.
Если упёрлось: Вернись к последней стабильной версии.
Паспорт пилота
Запиши workflow_id, владелец, версия промпта, входные поля, разрешённые действия, лимит в день, baseline, критерий успеха, типы исключений и срок пересмотра. Версия должна быть видна в каждом запуске.
Собери журнал run_id, started_at, input_hash, status, error_type, retry_count, human_decision и final_result. Без этого команда спорит о впечатлениях, а не разбирает конкретный запуск.
- Пилот = ограниченный объём, один владелец и обратимое действие.
- Масштабирование начинается после выборки ошибок, а не после первой удачной недели.
Порог перехода в рабочий процесс
Перед расширением проверь три вещи: результат стабилен на новых данных, сбой попадает владельцу за понятное время, а сотрудник может отменить действие. Если любой пункт не выполнен, оставь пилот в shadow mode — пусть он предлагает, но не меняет рабочую систему.
Расширяю пилот на новых входах по одному
Раздели проверку на две выборки: обычные кейсы и крайние — пустое поле, дубль, просроченный документ, таймаут и конфликт данных. Для каждой записи сравни ожидаемый результат, фактический статус, число исправлений и время до решения человека. Не смешивай новый канал и новый тип данных в одном запуске.
Переходи из shadow mode в действие только после повторной проверки на новой выборке. Сохрани дату решения, версию промпта и список разрешённых операций. Если новый вход вызывает неизвестный статус, возвращай `needs_review`, а не расширяй права модели на ходу.
Что считать готовностью к масштабу
| Критерий | Вопрос | Хороший признак |
|---|---|---|
| Вход | Что подготовить для масштабируемый AI-пилот? | Запиши границы пилота: один канал, один тип входа, допустимые действия, владелец, набор тестов и критерии остановки. |
| Действие | Что система может сделать сама? | Только заранее перечисленные действия, без доступа ко всему аккаунту |
| Проверка | Как понять, что результат можно принять? | Передай инструкцию человеку, который не участвовал в сборке, и попроси обработать десять реальных случаев. |
| Сбой | Куда уходит непонятный случай? | Заморозь расширение, собери ошибки в журнал и исправь одну причину до добавления новых каналов. |
Как понять, что пилот не зря
Пилот даёт ответ: можно ли переносить сценарий в работу, какие исключения остаются у человека и сколько стоит поддержка после запуска.
Почему удачное демо ничего не гарантирует
Расширять пилот до появления журнала ошибок.
Хранить критические настройки в личном аккаунте.
Считать ручные обходы частью нормального процесса.
Добавлять пять новых интеграций сразу.
Когда пилот пора закрыть
Если после теста нет владельца, метрики и понятного действия при сбое, пилот лучше остановить. Ещё один сервис проблему не решит.
Что проверять перед масштабированием
Кому подходит масштабируемый AI-пилот?
Перед масштабированием преврати пилот в повторяемый процесс с логами и владельцем — иначе он держится на одном человеке, ручных обходах и демо-данных.
С чего начать, если всё пока вручную?
Для первого шага запиши границы пилота: один канал, один тип входа, допустимые действия, владелец, набор тестов и критерии остановки.
Как проверить, что настройка не навредит?
Проверка здесь такая: передай инструкцию человеку, который не участвовал в сборке, и попроси обработать десять реальных случаев.
Что делать при непонятном результате?
При таком результате заморозь расширение, собери ошибки в журнал и исправь одну причину до добавления новых каналов.
