Когда AI agents пока не стоит использовать: стоп-условия и что делать вместо

Не разворачивайте AI agents, когда процесс неизвестен или нестабилен, данным на входе нельзя доверять, у необратимых действий нет владельца, успех нельзя записать как метрику или объём слишком мал, чтобы окупить build. Автоматизация путаницы умножает путаницу - со скоростью машины и по ценам API. Большинство «провалившихся AI-проектов» не были провалами модели; это были проекты, которые нужно было остановить на этом чеклисте. Честный вендор скажет вам «нет». Эта страница - чеклист, по которому мы это говорим. Публичные бенчмарки и coverage enterprise-пилотов также показывают, что успех agent-задач и влияние на P&L далеко не автоматические - см. короткий evidence-блок ниже - поэтому readiness gates важны до build.

Восемь стоп-условий

Любого одного из них достаточно для «пока нет»:

1. Никто не может нарисовать процесс. Если два человека, которые ведут workflow, описывают его по-разному, agent автоматизирует разногласие.
2. Процесс меняется каждый месяц. Agents кодируют процесс; движущаяся цель означает постоянный rework. Сначала стабилизируйте. Классический research по автоматизации уже давно помечает нестабильный процесс и допущения о суждении как паттерны провала - задолго до волны agents (HBR о четырёх паттернах провала автоматизации).
3. У успеха нет письменной метрики. «Сделайте умнее» - не acceptance test. Если вы не можете определить качество завершённой работы, вы не можете оценить agent - и вендор тоже. Как определить и провести этот тест, см. как оценивать AI agents перед go-live.
4. Входным данным нельзя доверять. Протухшие поля CRM, дубликаты записей, таблицы на «племенном» знании. Agent, действующий на плохих данных, производит уверенные, быстрые, неправильные действия.
5. У необратимых действий нет владельца. Если ни один именованный человек не будет утверждать отправки, платежи или изменения записей в gated-фазе, gate - это театр. Security-практика помечает неконтролируемое tool use и автономию как риск Excessive Agency в LLM-приложениях - gates не косметика.
6. Детерминированное правило уже решает задачу. Если логика - «когда X, делай Y» без всякого суждения, workflow-tool дешевле, быстрее и проще в отладке, чем agent.
7. Объём слишком мал. Задача, съедающая час-два в неделю, не окупит production build годами. Грубое правило: если workflow не потребляет ощутимых недельных часов и не несёт ощутимой цены ошибки, оставьте его ручным.
8. Никто внутри не будет владеть системой. После handoff кто-то на вашей стороне работает с review queue и смотрит метрики. Нет кандидата на эту роль - нет проекта.

Именованные антипаттерны (те же стопы, короткие ярлыки)

Это не второй чеклист. Это короткие имена того, как команды проваливают восемь стопов:

• Demo Theater - отполированный walkthrough без acceptance test, без production-пути и без владельца (стопы 3 и 8).
• Dirty-Data Autopilot - agent действует на CRM- или spreadsheet-хаосе «и чистит на ходу» (стоп 4).
• Unowned Irreversible - живые отправки, платежи или записи без именованного approver (стоп 5).
• Agent Costume - чистый if-then или один текстовый шаг, проданный как multi-step agent (стоп 6).
• Metric-Free Pilot - давление «сделать AI» без письменной планки качества завершённой работы (стоп 3; часто и стоп 1).

Если узнаёте один из них, остановите agent-путь и возьмите более дешёвую альтернативу из таблицы ниже.

Что использовать вместо

Сопоставьте симптом с более дешёвым правильным инструментом, а не с agent costume.

Средние строки важнее всего. Большая доля того, что питчится как agent-работа, - это детерминированная интеграция или один вызов модели в костюме agent; где проходит эта граница, смотрите Zapier/Make/n8n vs production agents.

AI agent vs automation

Детерминированная автоматизация - для делания: фиксированные правила, предсказуемые исходы, audit trails, которые можно прокрутить в голове. AI agent - для суждения поверх tools: multi-step выборы, грязные входы, пути, которые нельзя полностью перечислить заранее.

Используйте automation (или скрипт), когда предсказуемость и стоимость отладки важнее автономии. Используйте один вызов LLM, когда хватает одного языкового шага - драфт, классификация, extract - без tool-chaining и без необслуживаемых side effects. Поднимайтесь до production agent только когда multi-step суждение - реальное узкое место и восемь стопов чисты.

Если руководство на каждое workflow говорит «AI agents», спектр выше - защитимый перевод: большая часть работы всё ещё automation или один model call, а не full agency.

Лестница автоматизации

Поднимайтесь по одной ступени за раз и только когда текущая ступень насыщена:

1. Ручная работа с письменным SOP
2. Детерминированная автоматизация для шагов по правилам
3. Один вызов LLM там, где одному шагу нужны язык или суждение
4. Production agent, когда узкое место - multi-step суждение поверх tools

Manual SOP
    → Deterministic automation
        → Single LLM call
            → Production agent

Четырёхступенчатая лестница автоматизации от manual SOP до production AI agent. Пропускайте ступени только если согласны платить за это обучение во время pilot.

Каждая ступень учит вас тому, что должна выдержать следующая: SOP вскрывает исключения, детерминированный слой обнажает проблемы данных, один вызов LLM проявляет ожидания к качеству. Команды, прыгающие с первой ступени на четвёртую, оплачивают пропущенное обучение во время pilot - по ставкам агентства.

Уровни автономии (почему full autonomy редко идёт первой)

Не каждая «AI»-система - agent, и не каждый agent должен работать с высокой автономией. Простая лестница контроля (в духе research-уровней agent control) выглядит так:

Full autonomy редко бывает правильным первым шагом для business workflows с необратимыми действиями. Position paper по автономии agents утверждает, что риски для людей растут, когда больше контроля уступается автономным системам, и возражает против разработки fully autonomous agents в самом сильном смысле (Mitchell et al., arXiv). В production-работе начинайте gated: только драфт, allowlist tools и human approval на необратимых шагах - см. human-in-the-loop AI agents (человек в контуре).

Что показывает research (короткий evidence)

Эти цифры - бенчмарки и pilot research, не outcomes клиентов Northstar и не доказательство, что ваш workflow провалится. Они поддерживают позу «пока нет», когда readiness слабая.

1. Web agents всё ещё отстают от людей на реалистичных web-задачах. В бенчмарке WebArena (paper-версия с GPT-4-class baselines) лучший GPT-4-based agent достигал около 14.41% end-to-end task success против около 78.24% у людей (arXiv:2307.13854; среда: webarena.dev). Это research-среда, не ваш CRM - но она показывает, что multi-step tool use не «решён» демо.
2. Office-task agents в опубликованном snapshot полностью закрывают меньшинство задач. Coverage Carnegie Mellon по TheAgentCompany сообщал, что лучший agent в том материале (Claude 3.5 Sonnet) полностью завершил около 24% задач в симулированной company-среде (partial credit поднимал scores дальше; модели и leaderboards двигаются) (CMU SCS news; paper: arXiv:2412.14161; проект: the-agent-company.com). Относитесь к этому как к датированному snapshot, а не к вечной таблице очков.
3. Большинство GenAI business pilots всё ещё с трудом показывают P&L impact. Coverage Fortune отчёта MIT NANDA State of AI in Business 2025 описывает около 5% GenAI-пилотов с быстрым ускорением выручки, при этом подавляющее большинство буксует и даёт мало или ноль измеримого P&L impact - часто формулируется как ~95% «failure» rate для enterprise GenAI solutions в языке того отчёта (Fortune; материалы отчёта часто зеркалятся, напр. State of AI in Business 2025 PDF). Читайте scope осторожно: GenAI pilots в широком смысле, не «AI agents проваливаются в 95% случаев».

Ничто из этого не заменяет ваш workflow-чеклист. Это оправдывает «не готовы», когда процесс, данные, метрики, ownership или объём проваливают стопы выше. Как production-системы ломаются, если gates игнорировать, дополнительное чтение: режимы сбоев production-агентов.

Как выглядит хорошо

• Карта workflow существует до того, как что-либо построено, включая исключения
• У необратимых действий есть именованные владельцы и approval gates
• Tools of record названы явно, чтобы у agent был один источник истины для действий
• Успех определён как качество завершённой работы с письменным acceptance test, а не многословность модели
• Объём и цена ошибки оправдывают build арифметикой, которую может проверить кто угодно

Как выглядит плохо

• Demo Theater без production-пути и acceptance test
• Автоматизации без владельца, действующие на живых данных, пока никто не смотрит на queue
• Выдуманные метрики вместо операционных фактов
• Agent, построенный ради слайда для борда, а не ради workflow
• Dirty-Data Autopilot: «Данные почистим позже», пока agent уже на них действует

Когда вернуться к вопросу

У «пока нет» есть срок годности. Прогоните чеклист заново, когда объём вырастает за несколько часов повторяющейся работы в день, когда процесс стабилен уже квартал, когда у источника данных появляются владелец и очистка или когда человек, ведущий workflow, становится бутылочным горлышком для выручки. Стоп-условия - это gates, а не приговоры; большинство workflows, которые проваливают чеклист сегодня, проходят его в течение года целенаправленной подготовки, а сама подготовка - SOP, чистые данные, детерминированные шаги - окупается, даже если agent так и не построен.

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

Northstar проводит discovery до build, и discovery иногда заканчивается словами «здесь пока не стройте agent» плюс более дешёвый путь, который подходит (SOP, детерминированная automation, один вызов LLM или человек плюс чеклист). Когда чеклист пройден, мы проектируем и внедряем production-систему с gates, evals и handoff. Смотрите решения, парный материал про production agents для бизнеса и human approval gates / HITL, когда в scope есть необратимые действия.

Если нужен readiness pass по одному workflow - и ясное «нет», когда стопы провалены - начните с решения.