Fortech 
Тендеры и лиды
Информация
В конце 2025 года один крупный западный ритейлер запустил ИИ-агента, который должен был автоматически обновлять цены на сайте. Агент работал исправно — пока не начал конкурировать сам с собой. В какой-то момент два экземпляра одного агента стали снижать цены, пытаясь обогнать друг друга, и к утру часть товаров продавалась почти в ноль. Поддержка узнала об этом от покупателей.
Это не страшилка из будущего. Это 2026 год, и такие истории происходят регулярно — просто не все попадают в прессу.
Агентный ИИ — сейчас самая горячая тема в разработке. Запросы на мультиагентные системы выросли за прошлый год на тысячи процентов. 57% организаций уже развёртывают многошаговые агентные рабочие процессы в продакшене. И одновременно в 2026 году с инцидентами безопасности, связанными с ИИ-агентами, столкнулись уже 42% организаций — против 31% годом ранее.
Связь между этими двумя цифрами прямая.
Ещё год назад большинство команд работали с ИИ как с умным помощником: ты пишешь запрос, он отвечает, ты решаешь что делать дальше. Человек был в контуре на каждом шаге.
Агент — это другое. Он получает цель, сам разбивает её на задачи, сам вызывает инструменты, сам интерпретирует результаты и сам решает, что делать дальше. Вы говорите «проверь все открытые PR и оставь ревью», а не «посмотри на этот PR и скажи, что думаешь».
Это меняет всё. Скорость растёт — но вместе с ней растёт и цена ошибки. Потому что агент может сделать много шагов, прежде чем человек заметит, что что-то пошло не так.
Ошибка первая: агенты без границ.
Самая распространённая ошибка — дать агенту доступ ко всему, что может понадобиться, «чтобы не ограничивать». Это логика человека, который боится, что агент не справится. Но агент с избыточными правами — это агент, который может натворить избыточно.
Часть агентов подключается к SaaS-сервисам через личные или групповые токены, нередко с избыточными правами на запись. Классика: агент для документации получает write-доступ к репозиторию «чтобы мог коммитить», а потом кто-то замечает, что он переписал конфигурационный файл, потому что решил, что «так лучше».
Правило простое: минимально необходимые права. Агент для ревью — только чтение. Агент для документации — запись только в /docs. Никаких admin-токенов.
Ошибка вторая: теневые агенты.
В крупных организациях доля неучтённых ИИ-агентов уже доходит до 27%, а там, где любят low-code — до 39%.
Разработчик подключил агента через личный API-ключ. Продуктовая команда настроила автоматизацию через no-code инструмент. Аналитик написал скрипт, который по расписанию дёргает Claude и что-то делает с данными. Никто из них не думает, что создаёт «агента» — но де-факто это он и есть.
Проблема не в том, что люди делают что-то плохое. Проблема в том, что никто не знает, сколько таких агентов работает, к чему они имеют доступ и что произойдёт, если один из них начнёт вести себя странно.
Ошибка третья: нет человека в контуре там, где он нужен.
Агенты хороши для задач с чёткими критериями успеха и обратимыми действиями. Написать черновик — окей. Запустить тесты — окей. Задеплоить в продакшен без ревью — нет.
Принцип, который работает: чем необратимее действие, тем обязательнее человек в контуре. Удалить строки в базе данных, отправить письмо клиенту, задеплоить хот-фикс — всё это требует подтверждения. Агент предлагает, человек решает.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13590 тендеров
проведено за восемь лет работы нашего сайта.
Governance — слово, от которого разработчики закатывают глаза. Звучит как бюрократия. На деле это просто ответы на несколько вопросов, которые нужно зафиксировать до того, как агент пошёл в прод.
Реестр агентов. Список всего, что работает в автономном режиме: название, назначение, доступы, владелец, дата последнего ревью. Таблица в Notion — уже лучше, чем ничего. Без реестра вы не знаете, что у вас есть.
Классификация по уровню риска. Не все агенты одинаково опасны. Агент, который генерирует черновики для ревью — низкий риск. Агент, который может менять конфигурации в продакшене — высокий. Для каждого уровня свои правила: какие права, нужен ли human-in-the-loop, как часто аудит.
Observability с первого дня. Нельзя улучшить то, что не измеряешь: внедряйте трейсинг для отслеживания запросов через систему агентов, структурное логирование для отладки, метрики задержки, успешности и использования токенов. Звучит как DevOps-банальность — и это правда банальность, но 90% команд её игнорируют при развёртывании агентов.
Автоматический стоп. У каждого агента должны быть пороги, при которых он останавливается и зовёт человека. Слишком много ошибок подряд. Нестандартный результат. Запрос к ресурсу, который не в списке разрешённых. Это не признак недоверия к агенту — это признак зрелой архитектуры.
Самая частая ошибка при внедрении агентов — начинать с амбициозного: «давайте агент сам будет раскатывать релизы». Нет. Начинайте со скучного.
Скучный первый агент — это что-то вроде: автоматически генерировать changelog из смёрженных PR раз в неделю и присылать в Slack. Или проверять, что все новые тест-файлы соответствуют принятому шаблону именования. Или суммировать комментарии к задаче перед планированием.
Почему так? Потому что скучные задачи — это задачи с понятным критерием успеха, низкой ценой ошибки и коротким циклом обратной связи. Вы быстро понимаете, работает ли агент как надо, и нарабатываете практику управления им, прежде чем доверить ему что-то важное.
По прогнозам, к 2026 году 40% корпоративных приложений будут включать специализированных ИИ-агентов — против менее чем 5% в 2025-м. Переход происходит прямо сейчас, и он будет только ускоряться.
Команды, которые выстроят культуру работы с агентами — с реестрами, правами, observability и разумными ограничениями — получат скорость без хаоса. Те, кто будет внедрять агентов по принципу «главное запустить», получат скорость с хаосом.
Разница между этими двумя сценариями — не в инструментах. В подходе.
