Стоимость плохого внедрения AI agent

Прямой ответ

Плохое внедрение AI agent стоит куда больше инвойса: настоящий счёт - это инциденты от действий без gates, недели очистки данных, security debt, второй вендор, которому платят за reverse-engineering первого, и команда, которая отказывается от следующей автоматизации. Цена проекта - обычно самая маленькая строка в этой бухгалтерии. Большинство этих costs восходят к одним и тем же отсутствующим артефактам: нет acceptance test, нет approval gates, нет logging, нет названного владельца.

Полная бухгалтерия costs

Стоимость инцидентов: громкие провалы

Write-доступ без gates - место, где живут видимые катастрофы. Классические формы: сообщение не по шаблону на весь список, суммы refund, которые ни один человек не утвердил бы, retry-цикл, создающий дубли заказов, спешная интеграция, сливающая токен в логи. Каждый выживаем поодиночке; дорогими их делают скорость и объём - agent повторяет один и тот же неверный вызов сотни раз до того, как придёт сообщение в пятницу вечером. Инженерные паттерны за этим классом провалов каталогизированы в статье production-режимы отказов agent.

Примитив профилактики скучен: human approval gates на каждом необратимом действии, пока override rate не докажет готовность agent, плюс caps и идемпотентность, чтобы баг стоил одно плохое действие, а не пятьсот.

Операционный долг: тихие провалы

Тише и часто крупнее: внедрение, которое «работает», деградируя всё вокруг себя.

• CRM pollution. Agent, пишущий слегка неверные записи в масштабе, отравляет сегментацию, прогнозирование и каждую автоматизацию ниже по течению. Очистка ручная и медленная.
• Шумные очереди. Agent, эскалирующий половину кейсов, создаёт новый inbox, который никто не укомплектовал. Команда теперь ведёт старый процесс плюс процесс review.
• Боты без владельца. Contractor ушёл, credentials живут в учётке бывшего сотрудника, и никто не знает, что сломается при выключении - поэтому оно продолжает работать, без присмотра.
• Тихий дрейф. Без evals обновление модели или правка prompt деградирует качество неделями, прежде чем кто-то заметит паттерн в жалобах.

Организационная цена: самый длинный хвост

Самый прочный ущерб - доверию. Сотрудники, убиравшие за плохим ботом, тихо обходят следующего. Менеджеры, защищавшие проект, тратят кредит доверия, который второй раз не потратят. Расцветает shadow IT: команды покупают непроверенные tools, потому что официальный путь провалился. Эта цена никогда не появляется в post-mortem, и именно поэтому вторые попытки тяжелее первых.

Анатомия плохого внедрения

Провальные проекты поразительно однообразны:

1. Discovery пропущено или бесплатно. Вендор котировал по brief из одной строки, поэтому scope был догадкой.
2. Нет письменного acceptance test. «Успех» остался предметом переговоров, поэтому demo объявили готовым продуктом.
3. Автономия по умолчанию. Gates считали трением, а не механизмом наращивания доверия.
4. Нет logging и evals. Никто не смог ответить «что оно сделало и почему» после первого инцидента.
5. Нет handoff. Документация, runbook и план по credentials были «фазой два», а фаза два не наступила.
6. Нет владельца. Система не принадлежала никому после оплаты последнего инвойса.

Ничто из этого не проблемы модели: плохие внедрения - это процессные провалы в костюме AI, и та же последовательность видна как warning signs ещё на стадии quote, до любых подписей.

Playbook восстановления

Плохое внедрение обычно восстановимо без полного переписывания. Порядок triage:

1. Сдержите. Закройте gates или поставьте на паузу каждое write-действие agent. Read-only agents редко требуют экстренной хирургии.
2. Проведите audit. Составьте карту того, что система реально делает: интеграции, credentials, записываемые данные, точки отказа. Ждите сюрпризов.
3. Измерьте. Соберите минимальный eval-сет из реальных кейсов, чтобы зафиксировать текущее качество до любых изменений.
4. Сначала чините самый рискованный путь. Secrets и денежные пути раньше косметики.
5. Переписывайте выборочно. Оставьте то, что проходит evals; пересоберите только критические пути, которые проваливаются. Полные переписывания - для неспасаемых фундаментов, а не для раненой гордости.
6. Установите ownership. Документация, runbook, kill switch и названный внутренний владелец - артефакты, отсутствие которых и создало беспорядок.

Чек-лист профилактики для контракта

Самое дешёвое восстановление - то, что вписано в исходное соглашение. Перед подписанием убедитесь, что quote включает:

• Платное discovery с картой workflow и списком рисков
• Письменный acceptance test с порогом прохождения, согласованным до сборки
• Правила gates с названными действиями, требующими human approval, и тем, кто утверждает
• Logging, который вы можете читать, и eval-сет, который остаётся у вас
• Оценку LLM costs на реальном объёме, на ваших собственных API keys
• Handoff-пакет: документация, runbook, план по credentials, обучение
• Окно поддержки и названный путь эскалации после go-live
• Явные exclusions, чтобы у споров о scope был референсный документ

Вендор, который сопротивляется трём и более пунктам, котирует дешёвую версию бухгалтерии выше.

Как помогает Northstar

Northstar работает с обоих концов: fixed pilots с gates, acceptance tests и handoff, чтобы эта бухгалтерия никогда не открылась, и спасение систем, уже попавших в беду, через vibe-code rescue. В любом случае первый шаг - audit.