# Провал AI proof of concept начинается после демо

> AI proof of concept проваливается в продакшене, если доступ к данным, evals, лимиты затрат и ответственные появляются слишком поздно.

AI proof of concept обычно проваливается после того, как команда доказала способность модели выполнить интересную часть задачи. Демо отвечает на вопрос: «Может ли модель выдать убедительный результат на отобранных примерах?» В продакшене нужно понять, может ли компания законно предоставлять данные, обнаруживать плохие результаты, платить за каждую попытку, восстанавливаться после сбоев и закрепить ответственность за одним человеком. Это разные проверки.

Я не раз видел, как основатели праздновали эффектное пятничное демо, а потом целый квартал выясняли, что никто не отвечает за права доступа, порог приемки или ежемесячный счет. Виноватой назначают модель, потому что она у всех на виду. На деле проект останавливает отсутствие рабочей системы вокруг нее.

Нужны не более длинный эксперимент и не более впечатляющая модель. Считайте proof of concept первым узким срезом будущего продакшен-сервиса. Еще до разрешения расширить демо обеспечьте доступ к данным, похожий на боевой, измеримые правила приемки, явный потолок затрат и назначенного владельца результата.

## Демо доказывает возможность, а не работоспособность

Хорошее демо проверяет одну узкую техническую гипотезу, но не подтверждает, что процесс сможет безопасно и экономично работать каждый день. Проблемы начинаются, когда после аплодисментов команда незаметно подменяет утверждение. Фраза «модель сделала выжимку из двенадцати отобранных договоров» превращается в «мы доказали возможность автоматической проверки договоров». Второе утверждение пока не доказано.

Разница существенна, потому что при подготовке демонстрации острые углы специально убирают. Инженер чистит входные данные, повторяет запрос после тайм-аута, выбирает удачный пример и устно объясняет странный ответ. В продакшене пользователь принесет скан с пропущенными полями на незнакомом языке и не станет ждать ручного спасения. На демо разброс результатов сглаживает оператор, а в будущем с ним должен справляться сам сервис.

Запишите проверяемое утверждение до начала разработки. В хорошем утверждении есть набор входных данных, задача, порог качества и ограничение. Например: «Для англоязычных договоров с поставщиками, полученных за последние двенадцать месяцев, система извлекает пять утвержденных полей с согласованной точностью по каждому полю, возвращает результат не более чем за две минуты и тратит менее $0.40 на обработанный документ». Цифры должен диктовать бизнес, а не случайный результат модели.

Эта фраза не дает совершить три частые подмены. Связный ответ еще не означает правильный. Среднее качество не гарантирует безопасного качества для поля с тяжелыми последствиями ошибки. Дешевый вызов модели не означает дешевого завершенного процесса, если людям приходится проверять большинство ответов.

После завершения proof of concept я использую короткую карточку решения. Она намеренно проста:

```yaml
hypothesis: "extract approved fields from English supplier contracts"
input_population: "contracts received in the last 12 months"
acceptance:
  field_accuracy: ">= 0.97"
  p95_latency_seconds: "<= 120"
  cost_per_accepted_document_usd: "<= 0.40"
stop_conditions:
  - "restricted data reaches an unapproved processor"
  - "critical field accuracy falls below threshold"
owner: "Head of Procurement Operations"
decision: "hold"
```

Поле `decision` сохраняет значение `hold`, пока доказательства не заполнят каждую строку. Убедительная запись экрана не заменит эту карточку. Если команда не может сказать, что именно прошло проверку, у нее есть прототип, но еще нет кандидата в продакшен.

## Доступ к данным должен повторять боевой путь

Для проверки нужен минимальный репрезентативный набор данных, способный выявить проблемы боевого доступа, причем права должны напоминать продакшен. Синтетические примеры помогают инженеру начать работу, но скрывают условия, которые блокируют запуск: изоляцию клиентов, сроки хранения, региональные границы, удаленные записи, поврежденные файлы и поля, которые нельзя передавать поставщику модели.

Команды часто говорят: «Данные у нас уже есть». Обычно это означает, что кто-то умеет их выгрузить. Доступ описывает техническую возможность, а авторизация дает разрешение на конкретную цель. Учетные данные от базы решают первый вопрос и ничего не говорят о втором. Если перепутать эти понятия, удачный эксперимент с моделью превратится в исключение из правил безопасности и комплаенса, которое никто не подпишет.

Нарисуйте боевой путь данных до выбора модели. Укажите источник, класс данных, разрешенные поля, преобразование, обработчик, срок хранения, хранилище результата и путь удаления. Ячейка со значением `TBD` означает, что проверка обнаружила работу, а не устранила ее.

Проверьте эту схему по пяти пунктам:

- В источнике укажите, какие записи и клиенты могут попасть в процесс, затем приложите утвержденный запрос или политику доступа.
- На этапе подготовки назовите поля, которые нужно удалить или замаскировать, и протестируйте преобразование на фиксированных примерах.
- При вызове модели запишите, какой обработчик и какой регион могут получить сокращенный набор данных.
- Для результата задайте круг читателей, место хранения и момент удаления.
- Для удаления проследите один запрос от исходной записи через кэши, сгенерированные результаты, журналы и копии для оценки.

Как можно раньше проведите proof of concept через настоящий сервисный контур. Не позволяйте ноутбуку шесть недель читать локальную выгрузку основателя. Оберните модель узким API или заданием, настройте аутентификацию, записывайте идентификаторы запросов и прогоняйте репрезентативные записи. В первую неделю это кажется замедлением, зато избавляет от гораздо более дорогого сюрприза после утверждения проекта.

Сходство с продакшеном не требует копировать в эксперимент всю клиентскую базу. Начните с выборки, ограниченной по объему и доступу. Включите обычные, неприятные и заведомо отклоняемые случаи. Поведение при отказе часто говорит о готовности больше, чем лучший ответ модели.

Задайте вопрос об удалении, пока набор невелик. Если завтра клиент попросит удалить исходную запись, сможете ли вы найти связанные промпты, кэшированный контент, эмбеддинги, сгенерированный результат, журналы и копии для оценки? Если для ответа придется искать в нескольких личных папках, архитектура уже накопила долг.

## Для evals нужны классы ошибок и бизнес-пороги

Eval должна показать, безопасно ли продвигать систему, что ухудшилось и какая ошибка требует действий. Один средний балл этого не покажет. Он смешивает безобидные различия формулировок с ошибками, которые стоят денег, нарушают правила или приводят человека к неверному решению.

Начните с классов ошибок, а не с любимой метрики. Для помощника службы поддержки это могут быть выдуманная политика, пропущенное намерение отменить услугу, раскрытые персональные данные, неверный язык, необоснованное обещание и просто неловкий текст. Первым пяти нужны отдельные пороги, потому что последствия у них различаются. В стиле допустим разброс, недопустимый для приватности.

Собирайте набор для оценки из заявленной совокупности входных данных. Включите обычный поток, известные пограничные случаи, враждебные или запутанные запросы и примеры из каждого сегмента, который меняет последствия для бизнеса. Держите закрытый регрессионный набор, под который разработчики не смогут подгонять систему, и пополняемый исследовательский набор для ошибок, найденных на тестах и в живой работе.

Каждый пример должен содержать ожидаемое поведение и причину его важности. Достаточно компактной записи:

```json
{"case_id":"cancel_017","input_ref":"fixture://cancel_017","expected":{"action":"escalate","must_not_include":["refund approved"]},"segment":"regulated_account","severity":"critical"}
```

Такая структура позволяет точной программной проверке обнаружить запрещенное обещание, а рецензенту отдельно оценить тон. Используйте код для точных полей, форматов, фраз из правил, расчетов и вызовов инструментов. Оценку другой моделью оставьте для случаев, где без смыслового суждения нельзя обойтись, и откалибруйте оценщика по решениям людей. Согласие оценщика с самим собой почти ничего не доказывает.

AI Risk Management Framework от NIST разделяет измерение и управление. Это полезная поправка для команд, которые превращают панель evals в готовое решение. Балл дает доказательство. Назначенный владелец все равно должен решить, допустим ли оставшийся риск для процесса и какой контроль его сдержит.

Задайте пороги до финального прогона. Если команда выбирает проходной балл после результата в 89 процентов, она обязательно найдет деловую причину принять 88 процентов. Пороги должны исходить из цены ложного принятия, ложного отклонения и ручной проверки. Некоторым процессам нужна возможность воздержаться от ответа: система должна сказать «Я не могу решить» и передать случай человеку вместо лучшей догадки.

В отчете о выпуске показывайте результаты по классам ошибок и значимым сегментам, а не только общую цифру. Система может стать лучше в среднем и одновременно ухудшиться для небольшой группы клиентов или редкого, но дорогого случая. Для продвижения нужны доказательства, что опасный срез остался в своем лимите.

Относитесь к разметке как к продакшен-активу. Два рецензента могут разойтись, потому что правило расплывчато, в примере не хватает контекста или один человек ошибся. Записывайте разногласия и решайте вопрос с правилом до того, как объявить пример эталоном. Иначе eval вознаградит трактовку, которая первой попала в файл.

Следите за утечкой ответов и изменением распределения. Если разработчики видят все ответы закрытого набора, они начнут подстраиваться под тест даже без такого намерения. Если живые запросы переходят на новые языки, типы документов или клиентские сегменты, старый набор перестает описывать утвержденную совокупность. Добавляйте примеры через рецензируемую процедуру, версионируйте набор и сохраняйте прежние версии, чтобы изменение балла можно было объяснить.

## Потолок затрат должен быть частью проекта

До роста нагрузки задайте максимальную стоимость принятого бизнес-результата и лимит месячного риска. Цена токена модели входит в расчет, но не равна стоимости сервиса. Полный счет включает поиск, переранжирование, повторные вызовы, работу инструментов, повторы после ошибок, оценку, хранение, наблюдаемость и ручную проверку.

Команды постоянно считают стоимость по счастливому пути. Запрос использует один промпт, один ответ и самый дешевый опубликованный тариф. В живом потоке появляются длинные документы, дублированный контекст, тайм-ауты, неверный структурированный вывод, резервные модели и пользователи, которые нажимают повтор. Процесс стоимостью $0.08 на демо может выйти за бизнес-лимит без единого изменения тарифа поставщика.

Измеряйте стоимость принятого результата. Если десять попыток стоят $1.00, а валидацию проходят только шесть, затраты на модель составляют около $0.17 на принятый результат еще до проверки и инфраструктуры. Если рецензент тратит по четыре минуты на каждый ответ, труд может стоить дороже модели. Поэтому в инвестиционном обосновании нельзя принимать фразу «AI дешевле» на веру.

Поместите бюджетный контур в конфигурацию, чтобы сервис мог соблюдать его:

```yaml
cost_policy:
  max_usd_per_request: 0.25
  max_usd_per_accepted_result: 0.40
  monthly_budget_usd: 12000
  alert_at_percent: 70
  degrade_at_percent: 90
  action_at_limit: "queue_for_review"
```

Конкретные значения различаются, но действия нужно решить заранее. На пороге предупреждения владелец начинает расследование. На пороге упрощения сервис может сократить контекст, взять проверенную более дешевую модель для случаев с низким риском или уменьшить число необязательных повторов. На жестком лимите он ставит работу в очередь, а не продолжает незаметно тратить сверх бюджета.

Контроль затрат должен сохранять порог eval. Перевод всех запросов на меньшую модель может исправить счет ценой сломанного продукта. Тестируйте каждый режим упрощения как отдельную конфигурацию и публикуйте его качество, задержку и стоимость. Финансам нужен прогноз, а операционной команде нужно предсказуемое поведение, когда прогноз ошибается.

Считайте удельную экономику по сегментам. Один клиент с необычно большими файлами или один процесс с частыми повторами может покрывать свои расходы за счет остальных в средней цифре. Средние значения скрывают эту картину, пока счет не вынуждает начать неприятный разговор с клиентом.

Параллельные вызовы модели создают еще один потолок. Процесс может укладываться в цену одной задачи, но упираться в лимит запросов поставщика во время утреннего пика. Оплачиваемые сотрудники ждут, очередь проверки растет. Протестируйте всплеск, ограничьте число одновременных вызовов и включите время очереди в целевой уровень сервиса. Более дорогой тариф с высоким лимитом может быть разумным, но его место в прогнозе.

После каждого этапа выпуска сверяйте оценки со счетами и внутренними трудозатратами. Счетчики токенов могут не учитывать особенности тарификации поставщика, а рецензенты редко записывают все время на переключение. Еженедельный отчет должен показывать запрошенные, принятые и проваленные работы, минуты проверки и расходы. Так отходы становятся видны до неприятного итога за месяц.

## Надежность находится за пределами вызова модели

Продакшен-функции с AI нужна такая же обработка сбоев, как любой внешней зависимости, плюс контроль неверного и опасного вывода. Вызовы модели завершаются по тайм-ауту. Поставщики ограничивают частоту. Структурированные ответы не проходят проверку схемы. Поиск ничего не возвращает. Инструменты выполняют действие частично. Сервис должен знать, что делать в каждом случае, без инженера у консоли.

Начните с явного автомата состояний. `received` переходит в `processing`, затем в `accepted`, `rejected` или `review_required`. После тайм-аута допустим повтор в заданных границах; после ошибки схемы можно один раз попытаться исправить ответ; неудачное внешнее действие нельзя слепо повторять. Сохраняйте переход и идентификатор запроса, чтобы служба поддержки могла объяснить событие.

Идемпотентность особенно важна, когда модель запускает действия. Если пользователь повторит процесс с выставлением счета после тайм-аута, система не должна выдать второй кредит из-за опоздавшего первого ответа. Создайте токен идемпотентности до вызова модели и передайте его на границу действия. Модель может предложить действие, но проверять и выполнять его должен обычный код приложения.

Не прячьте неопределенность за повторами. Три выборки и голосование большинства способны улучшить некоторые задачи, но они утраивают стоимость вызовов и могут дать три уверенных варианта одной ошибки. Повтор подходит для транспортного сбоя и явно протестированного восстановления. Он плохо заменяет правило отказа от ответа.

Наблюдаемость должна связывать четыре записи: бизнес-запрос, версию модели и промпта, результат валидации или eval и конечный бизнес-результат. Для чувствительного контента записывайте ссылки, а не полные тексты промптов без ограничений. Система должна отвечать на конкретные вопросы: какая версия выдала ответ, какие проверки прошли, менял ли решение человек и завершилось ли обещанное действие.

До выпуска запишите условие отката. Рост критического класса ошибок, нарушение бюджета или увеличение очереди проверки могут запустить откат, даже когда общая доступность выглядит нормально. Откат может отключить действие агента, но оставить подсказки, вернуть прежнюю пару промпта и модели или направить все случаи в существующий ручной процесс.

## Ручная проверка требует настоящей очереди

Ручная проверка работает, только если команда определила проверяющих, доступные им доказательства, время ответа и поведение при переполнении очереди. Фраза «человек остается в контуре» часто означает, что проект переложил неразрешенный риск на неназванного сотрудника.

Рассчитайте пропускную способность из частоты поступления и времени обработки. Если система отправляет в очередь 300 случаев в день, а каждый занимает четыре минуты, она создала двадцать часов ежедневной работы. Proof of concept все еще может казаться эффективным, потому что на демо инженер проверил всего пять примеров.

Рецензенту нужны источник, предлагаемый ответ, применимое правило, сигналы уверенности или валидации и понятный набор действий. Не показывайте загадочный балл без объяснения. Избыток информации тоже вредит: длинное рассуждение модели может привязать рецензента к ее логике вместо исходных фактов.

Выбирайте для проверки принятые и отклоненные случаи. Проверка только ответов с низкой уверенностью измеряет работу фильтра отказа, но не найдет уверенные ошибки, которые прошли его. Используйте выборку по риску и возвращайте подтвержденные ошибки в исследовательский eval-набор. После согласования ожидаемого поведения переносите повторяющиеся ошибки в закрытый набор.

Задайте поведение при переполнении. Возможные варианты зависят от бизнеса:

1. Приостановить прием и сообщить пользователям время возобновления.
2. Вернуться к существующему ручному процессу.
3. Ограничить функцию случаями с низким риском, которые проходят автоматически.
4. Увеличить штат рецензентов по заранее утвержденному плану.

Молчаливое старение очереди не дает пятого варианта. Оно превращает контроль качества в нарушение уровня сервиса и искусственно занижает цену результата, потому что незавершенная работа еще не попала в расчет.

Для данных проверки тоже нужны правила доступа и хранения. Исправления могут содержать чувствительный исходный текст, заметки сотрудников и решения по политике. Считайте инструмент проверки частью боевого пути данных, а не временным административным экраном, который не подчиняется остальным ограничениям.

## Решение о продвижении принимает один владелец

Один бизнес-владелец должен распоряжаться областью применения, приемкой, бюджетом и остановкой. Комитеты могут советовать, а инженеры могут эксплуатировать сервис, но коллективная ответственность обычно означает, что никто не решится остановить популярное демо.

Владельца нужно искать в функции, которая получает результат. За рабочий эффект помощника поддержки должен отвечать руководитель поддержки; CTO не должен владеть политикой возврата только потому, что в процессе есть модель. Инженеры отвечают за реализацию и инциденты. Безопасность и юристы отвечают за свои согласования. Финансы подтверждают бюджет. Ни одна из этих ролей не заменяет владельца результата.

Дайте ему одностраничный пакет для решения: гипотезу, результаты eval по классам ошибок, утверждение потока данных, бюджетный контур, емкость ручной проверки, триггеры отката и нерешенные исключения. Возможные решения: `promote`, `hold` или `stop`. Избегайте режима `pilot forever`, когда реальные пользователи уже зависят от сервиса с экспериментальными мерами контроля и временным бюджетом.

Ответственность продолжается после запуска. Владелец рассматривает изменения моделей, промптов, инструментов, источников данных и пользовательских групп, потому что каждое из них может отменить прежние доказательства. Обновление у поставщика нельзя считать обычным обслуживанием, если оно меняет поведение. Прогоните нужный регрессионный набор и запишите решение о новой конфигурации.

Поставщики не отвечают за ваш бизнес-результат. Разработчик модели может публиковать сведения о доступности и безопасности, но не решит, означает ли неверный ответ допустимую задержку поддержки или неприемлемое финансовое действие. Перевод поведения модели в последствия для бизнеса остается за вашей командой.

Ответственность без времени и полномочий существует только на бумаге. Если назначенный человек не может получить согласование данных, выделить рецензентов или остановить запуск, обещанный отделом продаж, организация назначила посыльного вместо владельца. Внесите эти права в карточку решения и разрешите конфликты с другими руководителями до приема живого потока.

Владельцу также нужен регулярный операционный разбор. Для внутреннего помощника с малой нагрузкой подойдет ежемесячный, а агент финансовых действий в начале запуска может требовать ежедневного внимания. Разбирайте классы ошибок, расходы, возраст очереди, переопределения, инциденты и изменения конфигурации. Отменяйте встречу после закрытия сервиса, а не после угасания интереса к запуску.

Когда я оцениваю AI-проект через oleg.is, имя владельца интересует меня раньше выбранной модели. Отсутствующее имя предсказывает разрыв между демо и продакшеном надежнее слабого промпта.

## Продвигайте систему через контролируемое расширение

Переходите от proof of concept к продакшену, увеличивая охват только после доказательств для следующей границы. Большой запуск смешивает риск модели, процесса, спроса и поддержки в одном событии. Контролируемый выпуск разделяет их и оставляет возможность остановиться.

Практическая последовательность состоит из четырех этапов. Сначала воспроизведите исторические случаи без влияния на пользователей и сравните предложенные ответы с известными результатами. Затем запустите теневой режим на живом потоке, сохранив власть прежнего процесса. После этого откройте функцию небольшой подходящей группе с проверкой и немедленным запасным путем. В конце расширяйте доступ по сегментам риска и следите за заранее объявленными порогами.

Для каждого этапа нужны условия входа и решение о выходе. Само время ничего не доказывает. Фраза «мы две недели работали в теневом режиме» говорит меньше, чем «мы обработали нужную выборку по всем заданным сегментам без критических утечек приватных данных, а нагрузка проверки осталась ниже доступной емкости». Используйте утвержденные владельцем показатели, а не дату в календаре.

Во время продвижения вносите небольшие изменения. Если команда одновременно меняет модель, промпт, поисковый индекс и интерфейс, сбой почти ничему не научит. Версионируйте всю конфигурацию и продвигайте один протестированный комплект. Если срочная замена поставщика вынуждает взять новую модель, повторите нужные evals до расширения охвата.

Первая продакшен-версия часто должна уметь меньше демо. Уберите рискованные действия, сузьте входную совокупность, ограничьте размер документа или потребуйте проверки для чувствительного сегмента. Ограничение области работает как контроль и не требует оправданий. Узкий сервис с измеренным результатом можно расширить, а широкий сервис с необъяснимыми ошибками быстро теряет доверие.

Отрепетируйте сбой до прихода первой группы. Принудительно вызовите тайм-аут поставщика, отклоните неверный ответ, исчерпайте бюджет и сымитируйте отсутствие рецензентов. Убедитесь, что предупреждения доходят до назначенного человека, а запасной процесс действительно завершается, а не просто описан в документе. План отката, который никто не выполнял, остается гипотезой.

Общение с клиентом тоже входит в этап выпуска. Пользователь должен понимать, когда результат создала модель, что нужно проверить, куда сообщить об ошибке и посмотрит ли случай человек. Не прячьте рабочие ограничения в странице с правилами. Дайте инструкцию в момент решения и опишите именно тот контроль, который существует.

Не объявляйте победу в день запуска. Proof of concept закрывается только после наблюдения за реальными результатами, сверки расходов, обработки отзывов рецензентов, проверки отката и подтверждения, что владелец может эксплуатировать сервис без инженера исходного прототипа. Если этот инженер по-прежнему держит все на личных знаниях и ручных исправлениях, продакшен еще не начался.

## Слабую проверку нужно остановить до дорогого пилота

Остановите proof of concept, если он не проходит бизнес-порог, зависит от недоступных прав на данные, требует неприемлемо дорогой проверки или не находит владельца, готового принять остаточный риск. Закрытие такого проекта говорит о здоровом управлении портфелем. Продление из-за впечатленного демонстрацией руководителя тратит новые деньги, но не меняет ограничение.

Популярный совет «просто дайте пользователям AI-демо» неполон. Скорость помогает, когда команда назвала решение, для которого собирает данные. Без условий приемки и остановки доступ пользователей создает истории, давление и случайную зависимость вместо доказательств.

Проведите короткую проверку перед демо. Владелец должен ответить на пять вопросов:

- Какая именно группа может пользоваться функцией и какие случаи она обязана отклонить?
- Какие ошибки блокируют продвижение даже при росте среднего балла?
- Какова максимальная стоимость принятого результата и месячный предел?
- Кто разбирает очередь и инциденты, когда объем превышает прогноз?
- Какой один человек может приостановить сервис?

Если в комнате нет ответов, отмените эффектную презентацию и потратьте время на рабочие решения. Это не бюрократия. Такой выбор дешевле, чем после интеграции выяснить, что единственный безопасный процесс требует больше рецензентов, чем работает в команде.

Основатели, которым нужен внешний процесс принятия решения, могут заказать Team & AI Audit: за фиксированные $5,000 он за пять рабочих дней разбирает процесс, команду, расходы и продакшен-контроли. Полезный результат не сводится к очередному демо. Вы получаете обоснованный выбор: что продвигать, перепроектировать или остановить.

AI proof of concept заслуживает боевой трафик, когда компания может объяснить путь данных, воспроизвести eval, обеспечить бюджетный предел, обработать исключения и назвать человека с правом сказать «нет». До этого демо доказывает только возможность, а с нее работа лишь начинается.