Меня зовут Владимир, я занимаюсь техническим и продуктовым развитием облачных сервисов цифровой среды AI Factory в Cloud.ru и вижу ситуацию изнутри: демо почти всегда выглядит круто, а вот в проде все упирается в границы ответственности, данных и безопасности.
В этом разговоре часто теряется важная деталь: агент — это не просто более умная LLM. И уж точно не магический цифровой сотрудник, которому можно выдать задачу, доступы и ожидать стабильного результата.
Под рабочим процессом, или workflow, я дальше буду понимать систему, где шаги и ветвления заранее заданы кодом. Под агентом — систему, где модель сама выбирает следующий шаг, инструмент или передачу задачи в рамках заданных ограничений. Это принципиальная разница. Workflow предсказуемее, агент гибче, но дороже, медленнее и рискованнее в эксплуатации.
Даже команды, которые напрямую разрабатывают агентные решения, регулярно сталкиваются с задачами, где агент работает нестабильно или не дает нужного результата. Надежность такой системы определяется не только качеством модели, но и всей архитектурой вокруг нее: доступами, данными, инструментами, верификацией, логированием, откатом, human-in-the-loop и стоимостью ошибки.
Миф первый: агент может полностью заменить человека
Сейчас вокруг ИИ-агентов сформировался довольно агрессивный нарратив.
Еще немного — и они закроют большую часть задач, которые сегодня выполняют люди.
В соцсетях и блогах регулярно появляются советы в духе «замените этим агента аналитика/разработчика/юриста/ подставьте нужную профессию — и не заметите разницу».
Сомневаюсь.
ИИ-агенты действительно умеют многое: автоматизировать рутину, собирать информацию, помогать с типовыми сценариями. Но как только задача выходит за рамки шаблонов и требует глубокого профессионального опыта, автономность становится ограниченной.
Все упирается в то, что экспертная работа состоит из множества деталей.
Живой специалист не просто делает задачу, он опирается на три важных навыка:
У агента этих контуров по умолчанию нет. Их нужно проектировать отдельно.
Разберу несколько кейсов и объясню, что пошло не так и как это можно было решить.
Разработка
Что случилось. В июле 2025 года Джейсон Лемкин, основатель сообщества SaaStr, тестировал ИИ-агент платформы Replit. В ходе эксперимента агент удалил живую базу данных — 1206 руководителей и 1196 компаний — несмотря на активный режим «заморозки кода», который явно запрещал любые изменения в продакшене. Агент выполнял несанкционированные команды, не запрашивал одобрения у человека и нарушал прямые инструкции. После инцидента он признал произошедшее «катастрофическим провалом».
И это не единичный кейс — такое происходит регулярно. 25 апреля вышел пост главы PocketOS о том, что Cursor удалил продакшен-базу и резервные копии за 9 секунд.
Почему так произошло. У агента не было навыка проверки последствий. Опытный разработчик перед удалением данных проверяет среду, бэкап, права, blast radius и план отката? Агент этого не сделал, так как этого не было в runtime.
Как можно было решить. После инцидента CEO Амджад Масад анонсировал конкретные меры: автоматическое разделение баз данных разработки и продакшена, улучшенную систему отката и режим «только планирование» — агент предлагает действия, но не выполняет их без явного подтверждения пользователя.
Из этого кейса можно вычленить правила для работы с агентами, в зависимости от того, с какой стороны вы находитесь:
Если вы используете ИИ-агентов. Не давайте агенту прямой доступ к проду. Любая деструктивная операция должна требовать явного подтверждения с вашей стороны.
Если вы создаете агентов. Паттерн «человек в петле» на необратимых действиях — это не опциональная фича, а архитектурное требование. Если создавать агента в нашем сервисе AI Agents, то вы сможете проследить этот принцип на нескольких уровнях: управление доступом, подключение инструментов через MCP, мониторинг, трассировка и возможность разнести агента, RAG и модели по управляемым компонентам. Но даже комплексная платформа не отменяет проектирования прав и сценариев отказа.
Медицина
Что случилось. В 2025 году Med-Gemini, который анализирует КТ-снимки и медкарты, в рамках демонстрации поставил человеку выдуманный диагноз в несуществующем органе. А MedGemma галлюцинировала и давала разные ответы на один и тот же вопрос в зависимости от формулировки.
Параллельно косячат и сами врачи, которые работают с ИИ-помощниками (в том числе агентами): они стали на 6% реже самостоятельно обнаруживать опухоли, потому что все чаще доверяются ответам ИИ.
Почему так произошло. Агенту не хватает профессиональной ответственности и клинического суждения, которые есть у врача. Врач в ситуации неопределенности остановится и запросит дополнительные данные, направит к профильному специалисту или инициирует консилиум. Это связано не только с опытом, но и с системой ответственности за последствия решений.
Агент же не несет такой ответственности и потому чаще стремится дать завершенный, правдоподобный ответ даже при недостатке информации. Отчасти это отражает человеческие когнитивные привычки: склонность заполнять пробелы и избегать признания, что ты чего-то не знаешь.
Как можно было решить. Медицинский ИИ-агент должен работать строго в режиме второго мнения. Это уже не рекомендация, а регуляторное требование: с марта 2026 года ИИ-сервисы в клинической практике могут выступать только как второе мнение, а юридическая ответственность за диагноз лежит только на враче.
На уровне архитектуры это решается через несколько стандартных паттернов.
Классификатор релевантности: перед тем как агент выдает ответ, второй слой его проверяет. И если запрос не входит в зону компетенции агента, то он автоматически уходит к врачу.
LLM-as-judge: отдельная модель, которая проверяет ответ основного агента по заданным критериям и возвращает pass/fail еще до того, как ответ попал к пользователю. В чувствительных сферах это уже стандарт.
RAG только по верифицированным клиническим источникам.
Подтверждение врача (Human-in-the-Loop) перед любым значимым решением.
В чувствительных доменах вроде медицины агент не должен быть финальным источником истины. Его нормальная роль — ускорять врача, снижать когнитивную нагрузку и помогать не пропустить важные детали. Но ответственность за диагноз, назначение и клиническое решение должна оставаться у специалиста.
Тут может всплыть еще одна проблема — данные пациентов, которые агент отправляет во внешнюю БЯМ. Но ее можно решить через фильтр, который маскирует персональные данные и конфиденциальную информацию еще до отправки, чтобы они не утекли во внешний контур.
Юриспруденция
Что случилось. В апреле этого года федеральный суд штата Орегон оштрафовал двух адвокатов на $110 000 за использование вымышленных судебных решений, сгенерированных ИИ. В деле фигурировали 15 несуществующих прецедентов и 8 сфабрикованных цитат. Судья не только наложил рекордные для Орегона санкции, но и полностью прекратил дело с запретом на повторное обращение в суд.
Почему так произошло. У агента не всегда есть навык верификации источников, либо он может работать не идеально. Юрист проверяет и перепроверяет прецедент в первоисточнике — потому что несет личную профессиональную ответственность: в случае ошибки лишится и репутации, и денег. А вот агенту терять нечего, он просто код.
Такой сбой возникает не только из-за галлюцинаций, но и из-за отсутствия контура верификации: система не проверяет источники, не закрепляет найденные документы, не отличает подтвержденные ссылки от сгенерированных и не останавливает отправку материала без проверки человеком.
Как можно было решить
Практический паттерн:
поиск только по известным юридическим базам данных,
закрепление источников, на которые агент имеет право ссылаться,
запрет на свободную генерацию ссылок на судебные дела, нормы и цитаты,
обязательная проверка каждой ссылки и цитаты по первоисточнику,
отдельный статус для непроверенных утверждений,
подтверждение юристом перед любой внешней подачей документа.
Финальная ответственность за документ все равно остается за человеком. В разработке — то же самое, ответственный за ошибку тот, кто одобрил ПР.
При создании своего агента можно явно ограничить источники, к которым он обращается при генерации ответов. То есть физически запретить ему выходить за пределы проверенной базы знаний и убрать возможность фантазировать там, где это очень опасно и больно.
Миф второй: если агенту задали ограничения, он полностью безопасен
Этот миф особенно коварный, потому что кажется логичным: надо прописать правила, задать рамки — и агент будет действовать строго внутри них. Case closed.
Даже в обычных задачах случаются осечки. Агент может формально следовать правилам и все равно ошибаться, потому что правила не покрывают контекст, исключения и атаки через данные.
Кейс: модерация
Что случилось. В марте на Хабре вышла статья, где автор описывает кейс: публикацию заблокировали автоматические фильтры, решение долго нельзя было оспорить, а объяснить его никто не мог.
Это не уникальная история. ИИ модерирует контент в TikTok, и примерно 2,4% решений оказываются ошибочными. Вроде мало, но в масштабе видео-площадки — это все равно десятки миллионов неверных блокировок. За которыми люди, которые навсегда теряют доступ к аккаунту и/или монетизации.
Почему так произошло. Агент формально следовал правилам, но не понимал контекст, иронию, культурные коды. У него нет интуиции, чтобы понять, была ли шутка реально грубой, или она произнесена в контексте между друзьями. И наоборот — можно сказать ужасную вещь и без плохих слов. Ограничения в виде словарей и простых критериев дают много ложных срабатываний — и агент послушно масштабирует эту ошибку.
Дополнительный риск — когда решение агента сразу становится финальным: контент удаляется, аккаунт ограничивается, а пользователь не получает понятного объяснения и нормального канала апелляции.
Как это решить
Для владельцев площадок/пользователей:
не считать автоматическую модерацию финальной. Нужен понятный и быстрый процесс апелляции, где решение агента может пересмотреть человек;
открыто признавать, что ИИ‑модерация ошибается, и объяснять правила так, чтобы люди понимали, что именно нарушено.
Для тех, кто настраивает агентов:
строить гибридную схему: 70–90% контента агент фильтрует автоматически, но пограничные кейсы нужно сразу отправлять человеку;
логировать и анализировать ошибки по темам, формулировкам, типам фраз — и регулярно обновлять правила не только по словам, но и по паттернам контекста.
HR
Что случилось. В HR‑отрасли ИИ уже давно используют для автоскрининга резюме и оценки кандидатов. Но не всегда это хорошие кейсы: недавно карьерный консультант Алина Большева протестировала ИИ-скрининг в российской ATS и увидела большой косяк: система неверно считала стаж и отсеивала людей, которые на самом деле подходили под вакансию.
Почему так произошло. Агент действует внутри заданных ограничений — ищет ключевые слова, сверяет даты, проверяет соцсети. Но не справляется с нестандартными резюме, креативными форматами подачи и ошибками, допущенными по невнимательности кандидата.
Формально ограничения соблюдены. Но на деле агент отсекает людей, которых наоборот стоило рассмотреть внимательнее.
Как это решить
Для HR/бизнеса:
использовать ИИ‑агентов как фильтр, а не истину. Все, что выглядит нестандартно, должно не отсеиваться, а наоборот — подсвечиваться рекрутеру;
сохранять человеческое интервью как обязательный этап — особенно для позиций, где важны софты, а не только ключевые слова в резюме и подходящий стек.
Для тех, кто делает HR‑агентов:
вводить сценарий под якобы «сомнительные кейсы»: если данные не укладываются в шаблон, агент помечает резюме для ручного просмотра, а не отправляет в отказ;
проводить регулярный аудит на предвзятость: сравнивать выборки, смотреть, не зависят ли решения от пола, возраста, региона или типа образования, даже если эти поля формально не используются.
Безопасность
Что случилось. В марте 2026 года был инцидент с корпоративным агентом OpenClaw, который умел читать документы, ходить по вебу и вызывать инструменты от имени пользователя.
Оказалось, что его можно взломать через скрытые инструкции, зашитые прямо в документы и страницы. И когда агент читал такой документ, он воспринимал инструкции как легитимные команды: собирал API‑ключи и частные переписки, формировал URL с этой информацией и отправлял его во внешний мессенджер.
Всего обнаружили более 21 000 публично доступных уязвимых инстансов OpenClaw к январю 2026 года.
Почему так произошло. Prompt injection — это не баг интерфейса, а архитектурная проблема смешения данных и команд в одном контексте.
Ограничения типа «не раскрывай приватное» и сетевые фильтры здесь не всегда помогают. Потому что агент действует в рамках легитимных прав доступа, ведь он и должен читать документы, почту или базу кода. А еще он доверяет всему, что попадает в его контекст как «данные», и не отличает текст для анализа от текста, который на самом деле дает ему команду.
То есть у вас может быть идеальный RBAC, шифрование и все привычные меры безопасности — но если агенту позволено ходить по внутренним документам или почте, уязвимость есть.
Как это решить
Для пользователей и бизнеса:
не выдавать агентам доступ шире, чем реально нужно под задачу. Не вся корпоративная почта, а конкретные папки;
разделять зоны данных: нужны отдельные пространства, в которые агент не ходит вообще (финансы, юр.доки и т.д.). Да, даже если это неудобно.
Для тех, кто разрабатывает или собирает агентов:
считать любой текст из внешних источников потенциально опасным: и пользовательский ввод, и результаты веб‑поиска, и даже документы, подключенные через RAG;
применять sandbox для tool execution;
добавлять отдельный охранный слой: агент или фильтр, который анализирует контекст и ответы, а затем влияет на попытки выполнить подозрительные инструкции;
использовать scoped OAuth и минимальные права;
логировать действия агента на уровне инструментов: какие API он вызывал, какие файлы читал, куда отправлял запросы. И ставить алерты на аномалии: внезапная массовая выгрузка документов, странные внешние URL в ответах.
Миф третий: ИИ-агент сам по себе креативен и может создавать крутой контент
Картинка такая: у нас есть «умный» ИИ-агент, который все умеет — пишет статьи, придумывает идеи, генерирует обложки. Кажется, что именно агент обладает креативностью и может закрыть творческие задачи под ключ.
Правда в том, что агент сам по себе ничего не генерирует. Он планирует шаги, вызывает инструменты, склеивает результат.
А тексты и картинки рождаются внизу стека — генерируются моделью или отдельным инструментом, которые работают по своим законам. И все их ограничения автоматически становятся ограничениями агента.
За хорошим контентом стоит не скорость генерации, а три вещи, которые пока что умеет делать только человек:
Так что даже самый классный агент не может, например, в сторителлинг. Потому что под капотом у него ИИ, который не умеет по умолчанию выстраивать сложные истории с напряжением, уникальными деталями и живыми диалогами. Увы, он не Тарантино.
Но и из этого можно выжать пользу — если использовать агента как оркестратора, а не как «автора».
Вместо фантазийного запроса «агент, напиши за меня все» рабочий сценарий выглядит так ↓
Агент помогает собрать и структурировать референсы
Он может сам сходить в базу знаний/интернет, собрать примеры статей на тему, вытащить структуру, выделить типовые заходы. Это то, что агент умеет хорошо: искать, классифицировать, резюмировать.
Человек решает, какую историю рассказывать
На основе референсов вы выбираете, откуда заходить: через провал, через инсайд, через спор с распространенным мнением. Это то, чего агент не знает — у него нет вашего контекста, опыта и чуечки на хорошую историю.
Агент превращает ваш замысел в план
Тут как раз пригоден агентный сценарий: он может разбить задачу на шаги — угол → структура → черновик по частям». А дальше следить, чтобы вы не превращали текст в простыню без логики.
Генеративный слой пишет черновики, человек редактирует и добавляет живое
Агент вызывает LLM, чтобы набросать драфт каждого блока (так просто удобнее, чем писать сразу все). Вы добавляете реальные кейсы, детали, формулировки, меняете ритм — все то, что ИИ делает посредственно.
В конфиге такого агента это выглядит как инструкция — набором шагов с явными остановками на человеке:
собрать референсы и показать автору;
сгенерировать 3–5 вариантов захода, дождаться выбора;
сделать каркас статьи, дождаться правок;
генерировать текст только по одному блоку за раз, после каждого ждать фидбек.
Этот план корректно описывает то, что агенты сегодня уже умеют: планировать, запускать генерации, ждать подтверждения и т.д.
Миф четвертый: достаточно развернуть пару облачных сервисов, и мощностей любому агенту хватит
Одна инфраструктура сама по себе не спасет ни один агентный проект. Облака дают эластичность, GPU, managed-сервисы, модели и мониторинг.
Но это не превращает плохой агентный сценарий в хороший. Если агентная цепочка плохо спроектирована, она будет медленной, дорогой и хрупкой на любой инфраструктуре.
Проблема 1: контекст не бесконечен
Кажется: если ресурсов мало — добавим еще памяти, ядер, нод, и агент справится с любой задачей.
На деле все упирается в ограничения самой модели:
контекст ограничен, большие объемы данных все равно нужно резать и как-то отбирать;
длинные цепочки шагов копят ошибки, и ответ деградирует;
каждый лишний шаг = дополнительная задержка и деньги.
Как решать
Проектировать архитектуру под ограниченный контекст: использовать RAG, индексирование, сжатие, не пытаться скормить все и сразу.
Хранить источники и версии документов.
Разбивать задачу на этапы с явными границами: где агент точно работает, а где нужна ручная проверка.
Вводить лимиты: максимальное число шагов, ограничение глубины итераций, тайм‑ауты.
Проблема 2: мультиагентность быстро раздувает сложность
Идея: сделаем много агентов, каждый отвечает за свое — планировщик, исполнитель, проверяющий.
Реальность:
контекст между агентами передается с потерями;
ошибку одного агента начинают многократно пересказывать остальные;
количество запросов и вызовов растет лавинообразно, и это напрямую бьет по задержкам и счету за ресурсы.
Как решать
Начинать с одного агента. Добавлять новых агентов только там, где одноагентная конфигурация реально перестает справляться, и это видно по оценкам качества.
Минимальный набор для прода:
явный оркестратор,
понятный контракт между шагами,
лимит итераций,
журнал решений,
метрики качества и стоимости,
остановка цепочки при неопределенности.
Проблема 3: экономика агента часто недосчитана
Частая ошибка: стоимость агента — это не только токены основной модели. В реальном контуре есть RAG, эмбеддинги для поиска похожих фрагментов, переранжирование результатов, ретраи, хранение трассировок, оценка качества, мониторинг и так далее. Все это увеличивает расходы.
Как решать
Перед запуском важно считать:
стоимость одного успешного выполнения;
долю ретраев и неуспешных цепочек;
цену ошибки;
latency SLO;
бюджет на evals и наблюдаемость;
долю шагов, которые можно отдать более дешевой модели.
Здесь облако как раз помогает: можно масштабировать ресурсы, платить по модели pay-as-you-go, подключать управляемый RAG, сравнивать модели с помощью Foundation Models или развернуть собственный inference в том случае, если критичны задержка до первого токена и скорость дальнейшей генерации, смотреть трассировки и управлять потреблением.
Но проектировку экономики и границ задачи все равно никто не отменял.
Что в итоге
Главная ошибка в разговоре про ИИ-агентов — оценивать их по демо. Демо показывает, что агент может пройти идеальный сценарий один раз: найти данные, вызвать инструмент, собрать отчет, написать код или подготовить черновик.
Но в продакшене важно понимать, как часто агент выполняет задачу правильно, что происходит на пограничных сценариях, сколько стоит успешное выполнение и можно ли восстановить всю цепочку действий после сбоя.
Советую ответить на эти вопросы, если вы хотите создать или уже создаете собственные агентные системы.
