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

Что обычно называют «внедрили AI»

На практике «внедрили» чаще всего означает одно из трёх:

Купили подписку на ChatGPT для нескольких сотрудников, которые иногда туда что-то копируют

Наняли подрядчика, тот собрал чат-бота, показал демо, и на этом контакт с проектом закончился

Кто-то из команды сам поигрался с автоматизацией на выходных, показал начальнику, все впечатлились, и забыли

Ни один из трёх случаев не про автоматизацию процесса. Это про знакомство с инструментом. Разница между «поиграли с ChatGPT» и «автоматизировали процесс» примерно такая же, как между тест-драйвом и владением машиной: одно ни к чему не обязывает, другое требует техобслуживания.

Первая ошибка: начинают с чат-бота

Почти всегда первый AI-проект в компании - это чат-бот на сайт или в мессенджер. Логика понятная: заметно, эффектно, можно показать инвесторам или партнёрам.

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

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

Вторая ошибка: пилот без владельца в процессе

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

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

Это не про недоверие к подрядчику. Это про то, что бизнес-процесс живёт в голове владельца, а не в техническом задании. Без него подрядчик чинит не то и не там.

Третья ошибка: не с чем сравнивать

Спрашиваю у предпринимателей: «А что было до автоматизации, сколько времени уходило, сколько ошибок было?» Почти никогда нет ответа. Значит, и результат посчитать нечем, есть только ощущение «вроде стало лучше» или «да как-то не очень».

Без числа «до» любое число «после» ничего не доказывает. Через три месяца находится повод свернуть проект не потому, что он не работает, а потому что никто не может доказать, что он работает.

Что тогда работает

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

Скучно? Да. Именно поэтому 80 процентов про это не думают и уходят в чат-бота и демо-день.

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

Если у тебя есть свой опыт внедрения, совпадает с этим паттерном или нет? Мне правда интересно, где я ошибаюсь.

Источники

Наблюдения основаны на практике личных проектов автоматизации и разборе сегментов малого бизнеса (владельцы МСБ, онлайн-эксперты), а не на одном кейсе.

Больше практических разборов - в блоге Вайбкодим бабки и в Telegram-канале @ai_prs.

Разбираю AI-автоматизацию и цифровой офис без хайпа в «Вайбкодим бабки» - заглядывайте, если тема ваша.

Что вообще значит "дать агенту доступ к бизнесу"

Коротко: почти никогда это не значит "агент делает всё сам". Владельцы малого бизнеса путают два разных понятия - автоматизацию и автономность, и путаница дороже, чем кажется.

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

Разница на практике: агент, который парсит входящие заявки по шаблону - автоматизация, предсказуемая и безопасная. Агент, который сам решает, кому и что ответить, меняет цену или отправляет письмо клиенту без проверки - это уже автономность, и именно здесь нужна граница контроля, о которой дальше пойдёт речь.

Почему просто "спросить разрешения" не работает

Коротко: диалоговое окно "разрешить это действие?" звучит как решение, но по факту оно не защищает - люди устают его читать.

Anthropic, которая сама строит один из самых используемых агентных инструментов (Claude Code), прямо пишет об этом в инженерном блоге: "Our telemetry showed users approved roughly 93% of permission prompts". И тут же честно называют механизм: "The more approvals a user sees, the less attention they pay to each, becoming over time much less diligent in their supervision" - чем больше запросов на подтверждение видит человек, тем меньше внимания он каждому уделяет.

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

Вывод у Anthropic звучит так: "Design for containment at the environment layer first, then steer behavior at the model layer" - сначала физически ограничить среду, в которой действует агент, и только потом настраивать его поведение словами. Не полагаться на то, что агент "спросит, если что" - а сделать так, чтобы опасное действие было физически недоступно.

Где реально проходит граница: три уровня контроля

Коротко: рабочая граница контроля держится минимум на трёх уровнях с разной ценой ошибки - один переключатель "разрешено/запрещено" тут не справляется.

В системах, которые я строю сам, граница выглядит так:

1. **Агент делает сам, без вопроса** - то, что обратимо и не стоит денег: анализ, поиск, черновики, отчёты, запись в собственную рабочую область.

2. **Агент спрашивает разрешение через явное действие человека** (у меня это кнопка в Telegram) - то, что стоит денег или трогает внешний мир: публикация, деплой, изменение системных настроек, трата денег.

3. **Агенту нельзя никогда, даже с разрешением** - необратимые и разрушительные действия: безвозвратное удаление, доступ к чужим секретам и токенам, силовые операции с общим репозиторием кода.

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

OpenAI в SDK для агентов формализует похожую идею иначе, но по той же логике. У любого инструмента можно поставить флаг, что перед выполнением нужна пауза: "Human review pauses the run so a person or policy can approve or reject a sensitive action". Выполнение агента при этом не прерывается насовсем - оно сохраняется как состояние и может быть продолжено после решения человека. Оба крупных вендора агентных систем пришли к одному архитектурному выводу разными путями: пауза на дорогом действии должна быть встроена в систему с самого начала - иначе это просто костыль поверх готового решения.

Эта трёхуровневая классификация - как раз то, с чего начинается любое внедрение AI-агента в бизнес без своего программиста в штате: разбор рисков занимает больше времени, чем сама автоматизация, и без него граница контроля так и остаётся благим намерением. «Вайбкодим бабки» - про то, как эта классификация и сама архитектура собираются на практике, шаг за шагом.

Границу задают права доступа, не договорённости

Коротко: самый надёжный способ провести границу - физически лишить агента возможности выйти за рамки; просьба "будь осторожен" тут не работает.

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

Разбор Sarang Sanjay Kulkarni (Thoughtworks) про внедрение агентных систем в Bayer формулирует ту же мысль языком инженерной дисциплины: "explicit control over context, workflow state, recovery, reflection, and verification remains essential". Даже в проекте с серьёзным бюджетом контроль никуда не девается. Он превращается в постоянную инженерную работу вместо разовой галочки "человек проверяет".

Собственное исследование Anthropic про то, как агенты реально используются, показывает, что рынок уже интуитивно движется в эту сторону: у 80% вызовов инструментов агентом есть хоть какая-то защита (ограниченные права или требование подтверждения человека), у 73% сессий в той или иной форме есть человек в контуре, и лишь 0,8% действий агента необратимы, вроде отправки письма клиенту. То есть большинство пользователей уже интуитивно строят похожую многоуровневую защиту - вопрос в том, делают они это осознанно или на ощупь.

Есть и обратная сторона вопроса - кто вообще отвечает за агента. Разбор в The Hacker News про управление доступом агентов называет это прямо: "Organizational agents frequently have no clear owner, no single approver, and no defined lifecycle". И дальше без обиняков: "Every agent must have a defined owner responsible for its purpose, scope of access, and ongoing review... Without ownership, approval is meaningless and risk remains unmanaged." Без явного владельца сам факт "кто-то же утвердил доступ" ничего не значит - агент без хозяина не остановит никто.

Что будет, если довериться на автомате

Коротко: самый неочевидный риск - тихая деградация, которую никто не заметит, потому что формально всё "работает"; громких поломок тут не бывает.

У меня в системе как-то истёк токен авторизации, и это совпало с автообновлением клиента. Новая сессия молча стартовала на более слабой модели - явную настройку я не прописал, система взяла дефолт. Я не нарушил ни одного правила, не было ни одного явного сбоя. Единственным сигналом стало то, что я лично почувствовал: "что-то не так" - и это заняло десять дней.

Похожее описание того же ощущения я находил в собственном посте, когда одна из моделей внезапно "отупела" без предупреждения: "начал выполнять задачки - и как будто общался не с любимым Claude, а с GPT-3.5, который тупил... Был бы наивен и глуп как пятнадцатилетний ребёнок - совсем не понял бы, что произошло. Решил бы, что дело во мне, что отупел я и разучился нормально формулировать задачи."

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

Настоящая экономика: сколько на самом деле сберегает автономный агент

Коротко: обещанная "экономия часов" почти никогда не превращается в деньги сама по себе - это нужно делать отдельным сознательным шагом.

Датское исследование производительности 25 000 работников, которое разбирает Okane Land, даёт куда более скромную цифру, чем маркетинг: около 2,8% рабочего времени экономится в среднем, и лишь 3-7% этой экономии времени реально доходит до чьей-либо зарплаты. Формула оттуда же объясняет, почему так: "A 40% speedup on one task becomes a few percent of your week once you count everything AI does not touch." Проще говоря: ускорение одной задачи на 40% превращается в пару процентов недели, если посчитать всё, чего AI не касается.

Даже там, где в AI вкладывают десятки миллиардов, прогресс автономии оказывается медленнее, чем обещали. Марк Цукерберг на внутренней встрече в Meta 2 июля 2026 года прямо признал, что развитие AI-агентов "not accelerated in the way" руководство ожидало. Если у компании с таким бюджетом автономия буксует, ожидать от коробочного решения за разумные деньги мгновенного результата - оптимизм не по адресу.

Gartner идёт дальше и прогнозирует: более 40% агентных AI-проектов будут закрыты до конца 2027 года - из-за растущих издержек, неясной бизнес-ценности и недостаточного контроля рисков. Отдельно они вводят термин "agent washing" - переупаковку старых продуктов (чат-ботов, RPA) под модным словом "агент" без реальной агентности внутри. По их оценке из тысяч вендоров, называющих себя агентными, таких на самом деле около 130.

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

Показательный разворот: чему учит история Klarna

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

В 2024 году Klarna заявляла, что их AI выполняет объём работы 700 агентов поддержки. Уже в 2025 CEO Себастьян Симятковски публично признал: "As cost unfortunately seems to have been a too predominant evaluation factor when organising this, what you end up having is lower quality" - то есть слишком сильно оптимизировали по стоимости, а получили просадку качества. Компания снова начала нанимать живых людей. Его же цитата про доверие клиента звучит как прямая рекомендация для бизнеса, думающего про автоматизацию поддержки: "I just think it's so critical that you are clear to your customer that there will always be a human if you want."

Klarna показала: провал был не в технологии, а в ожиданиях клиента, которому важно достучаться до живого человека. Полная замена там, где клиент хочет знать, что может дозваться, - это вопрос того, каким бизнес хочет выглядеть снаружи.

Сознательно не включать - тоже часть архитектуры контроля

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

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

Это отдельная категория зрелости в обращении с автономией: не каждая рабочая возможность обязана быть включённой прямо сейчас. Вопрос "что случится, если это пойдёт не так" стоит задавать до того, как функция заработает.

Что реально остаётся человеку

Коротко: весь контроль здесь - две конкретные вещи: сформулировать задачу и проверить результат.

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

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

Если вы сейчас думаете про своего AI-агента без программиста в штате - вопрос "что случится, если он ошибётся, и кто это заметит первым" задайте себе до запуска. У вас уже есть ответ, или только предстоит его найти?

Если решите собрать похожую систему себе - «Вайбкодим бабки» ставит все шаги вместе: от классификации действий по риску до самой архитектуры. Коротко, по делу, с результатом, который остаётся у вас.

Ещё один практический разбор из той же папки рисков - почему пилоты AI-автоматизации чаще всего глохнут после старта.

Источники