Что стоит проверить перед внедрением ИИ-агента в корпоративную среду

В новостных лентах слово «инцидент» всё чаще стоит рядом со словом «агент». Так, например, все прекрасно помнят нашумевшую в апреле новость о том, как ИИ-агент в Cursor удалил производственную базу данных стартапа PocketOS вместе с резервными копиями. На все про все агенту потребовалось не более девяти секунд. 

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

И это не единственный случай. В начале года разработчик Алексей Григорьев рассказывал, как Claude Code при работе с Terraform удалил производственную инфраструктуру, базу данных за последние два с половиной года, а заодно и снимки для восстановления, чтобы уж наверняка. Данные удалось вернуть с помощью поддержки AWS, но случай был показательным.

Столь громких историй в России пока не было или они не публиковались. У нас тревожные новости приходят в основном из-за халатности или в какой-то степени необразованности пользователей, сливающих в LLM конфиденциальные данные. Но и такие случаи весьма неприятны по своим последствиям. 

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

От ассистента к агенту: кто нажимает на кнопку?

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

Ассистент отвечает на запрос: объясняет ошибку, предлагает код, составляет SQL-запрос или подсказывает, как настроить сервер. Даже если совет неверный, последствия обычно возникают только после того, как человек решит ему последовать.

Агент может пройти следующий шаг самостоятельно: открыть терминал, выполнить команду, изменить файл, обратиться к API, воспользоваться браузером, проверить результат и продолжить работу. Если первый способ не сработал, он может попробовать второй — а затем третий. Именно эта самостоятельность и делает его полезным. И именно она усложняет контроль. Здесь есть одна неточность! Обычно пользователь имеет дело с агентным приложением, а не с агентом напрямую, но для простоты зовет его агентом. Это упрощение использовали и для этой статьи. 

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

То есть внедрение агента — это в первую очередь расширение прав доступа. И проверять его нужно через границы, аудит действий и возможность отката.

Чек-лист: десять вопросов до пилота проекта

1. Где проходят границы действий агента?

Самый важный вопрос. У агента должен быть явный и технически обеспеченный предел: какие директории, хосты, сервисы и команды доступны, а какие — нет. Желательно, чтобы рабочие процессы выполнялись в изолированной среде (песочнице), а не в боевом контуре напрямую.

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

2. Где хранятся данные и кто на них имеет право?

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

Что проверить: политика обработки данных, юрисдикция хранения, договор с оператором.

3. Как агент работает с секретами?

Пароли, токены, ключи API, закрытые конфигурации — то, что агент видит в процессе работы. Вопрос не в том, «честный ли агент», а в том, как на уровне архитектуры введен запрет на непреднамеренную передачу.

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

4. Может ли человек вмешаться в процесс?

В корпоративной среде нужна модель «человек в контуре» (human-in-the-loop): наблюдаемость действий, возможность остановить выполнение, обязательное подтверждение для разрушительных и внешних действий.

Что проверить: режимы работы (например, Ask / Plan / Agent), механизм одобрения плана, возможность вмешаться на любом шаге.

5. Видно ли, что агент делает в каждый момент?

Агент не должен работать в режиме «чёрного ящика». Нужна наблюдаемость в идеале — в том же терминале или браузере, в котором работает команда.

Что проверить: журнал действий, отображение выполняемых шагов, воспроизводимость сессии.

6. Как агент проверяет собственный результат?

Зрелое решение отличается тем, что агент проверяет работу всеми доступными ему инструментами. Запускает тесты, открывает страницу, выполняет команды, анализирует вывод. 

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

7. Что агент делает при ошибках?

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

Что проверить: лимит попыток, стоп-критерии, качество сообщения о затруднении.

8. Насколько вы зависите от конкретной модели?

Агентное приложение — это связка среды исполнения и LLM модели. Стоит понять, привязаны ли вы к одной модели, можно ли заменить или добавить модель. Этот вопрос особенно актуален для организаций с требованиями к работе в российском контуре.

Что проверить: список поддерживаемых моделей, механизм конфигурации, условия лицензирования, возможность on-prem установки.

9. Интегрируется ли агент с вашими инструментами?

Корпоративный агент должен работать там, где уже работает команда: файлы и папки, терминал, браузер, сеть, репозитории и т.п. Если для каждого действия нужно переключаться на «экспорт/импорт в чат», вместо агента вы получите дорогого консультанта. 

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

10. Что с юридической стороной и репутационными рисками?

Договор с разработчиком, обработка данных, ответственность за решения, принятые с участием ИИ, возможность доказать происхождение результата. 

Что проверить: договор, политика конфиденциальности, реестры/лицензии, если применимо, порядок работы с чувствительными данными.

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

Как все устроено на практике

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

Как определены границы

В Дуэйд рабочие процессы могут выполняться в изолированных песочницах, а потенциально разрушительные или внешние действия требуют подтверждения пользователя. При этом «песочница» сама по себе не является магической защитой и гарантом эффективной работы. Эффективность будет зависеть от выстроенной конфигурации, доступных ресурсов, а безопасность напрямую будет зависеть от того, какие действия разрешены за её пределами. То есть граница дозволенного заложена в архитектуру решения, для агента не предполагается наличие неограниченного доступа ко всей инфраструктуре. 

Человек в контуре

В Дуэйд работа организована как совместная сессия пользователя и ИИ. Пользователь видит работу агента в терминале и браузере, переключается между режимами «Агент, План, Спросить» и может вмешаться на любом этапе. Перед сложной задачей агент формирует план и todo-список. В нашей команде есть разработчики, которые вместе Дуэйдом именно над планом работают по несколько дней, выстраивая архитектуру решения и детализируя ответственные этапы. Сам код агент пишет быстро, проработка детального плана позволяет писать код без ошибок. Таким образом, в сценариях с повышенными требованиями к контролю закладывается еще одна «ступенька», где работы начинаются только после полного одобрения плана. Такой подход позволяет выбирать степень самостоятельности агента под конкретную задачу. 

Верификация

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

Дуэйд перед «отчетом» о выполнении задачи запускает тесты, открывает веб-страницы, «просматривает их глазками», выполняет команды и анализирует полученные данные. Перед тем как сообщить о завершении, агент проверяет результат доступными инструментами и отчитывается о тестировании. Это не означает, что Дуэйд не ошибается и всегда выдает только отличный результат. Не будем его идеализировать )) Да, тесты могут быть неполными, проверка может не охватывать все возможные сценарии. Но между «я написал код» и «я запустил код, проверил результат и могу рассказать, что именно проверял» есть принципиальная разница.

Секреты 

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

Ошибки

Ошибки — нормальная часть работы с агентом, здесь все как у людей. Он может неверно понять задачу, столкнуться с недоступным ресурсом или еще миллион причин почему что-то пошло не так.

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

Где работает система и какие модели использует

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

Дуэйд поддерживает установку на Windows, macOS и Debian/Ubuntu Linux. Для изоляции рабочих процессов можно использовать Docker с доступом по SSH, а для отдельных сценариев доступен локальный сервис с веб-интерфейсом. Это позволяет организовать работу в привычной для команды среде. Но, важно помнить, что само наличие настольного приложения ещё не определяет маршрут данных, он зависит от конфигурации, выбранной модели и способа её подключения. Почему-то даже в среде разработки не всегда отдают отчет в том, что место установки агента и место работы модели — это далеко не одно и то же. 

Если приложение работает на компьютере сотрудника, а запросы отправляются во внешний API, данные всё равно покидают локальную среду. Поэтому при выборе конфигурации нужно учитывать всю цепочку: от рабочего окружения и инструментов агента до модели, сетевых соединений и хранения результатов. Дуэйд работает или читай предоставляет возможность корпоративным клиентам организовать работу со своей LLM, в этом случае данные обрабатываются на серверах Думейт и не покидают РФ контур. Клиент может выбрать любую другую LLM и подключить её к агенту по API, в этом случае нужно смотреть на условия поставщика. Для совсем закрытого контура предусмотрен вариант установки on-prem, когда данные не покидают корпоративный контур. Это самый безопасный, но и самый дорогой вариант решения.

Но вернемся к главной идее этой статьи, а она в том, что любая автономность работы ИИ-агента должна быть в первую очередь управляемой

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

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