AI-агент для бизнеса без программиста: где граница контроля
Я строю AI-агентов почти каждую неделю - для себя и не только. Вопрос, который слышу чаще всего, звучит не "какую модель выбрать", а короче: "а если он накосячит - я вообще узнаю?" Если вы разбираетесь, как внедрить AI-агента для бизнеса без программиста в штате, дальше - как на практике проводится граница между "агент решает сам" и "спрашивает разрешения", почему простое окно подтверждения не защищает, и что в AI-агентах реально окупается, а что - маркетинговое обещание. 15 минут чтения вместо недель проб и ошибок.
Разбираю 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-автоматизации чаще всего глохнут после старта.
Источники
- Anthropic, "How we contain Claude across products" (25 мая 2026) - https://www.anthropic.com/engineering/how-we-contain-claude
- Anthropic Research, "Measuring AI agent autonomy in practice" - https://www.anthropic.com/research/measuring-agent-autonomy
- OpenAI Agents SDK, "Guardrails and human review" - https://developers.openai.com/api/docs/guides/agents/guardrails-approvals
- Sarang Sanjay Kulkarni (Thoughtworks), "Building Reliable Agentic AI Systems", блог Martin Fowler (16 июня 2026) - https://martinfowler.com/articles/reliable-llm-bayer.html
- Mark Zuckerberg, town hall Meta, цит. по TechCrunch (2 июля 2026) - https://techcrunch.com/2026/07/02/mark-zuckerberg-tells-staff-that-ai-agents-havent-progressed-as-quickly-as-hed-hoped/
- Okane Land, "The real ROI of AI for knowledge work" - https://okaneland.com/study/ai-productivity-roi-at-work/
- Gartner, "Over 40% of agentic AI projects will be canceled by end of 2027" - https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
- The Hacker News, "Who Approved This Agent?" (январь 2026) - https://thehackernews.com/2026/01/who-approved-this-agent-rethinking.html
- Sebastian Siemiatkowski (CEO Klarna), интервью Bloomberg, цит. по Forbes (май 2025) - https://www.forbes.com/sites/quickerbettertech/2025/05/18/business-tech-news-klarna-reverses-on-ai-says-customers-like-talking-to-people/