Внутренняя политика AI-агентов: что прописать, чтобы не разгребать потом

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

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

Чем агент отличается от чат-бота и почему это меняет правила

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

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

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

Разделы, без которых политика не работает

Документ на одну страницу «использовать AI разрешено с осторожностью» бесполезен — он ничего не запрещает и ни за что не отвечает. Рабочая политика закрывает как минимум шесть областей.

1. Что можно передавать модели, а что нельзя

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

• Публичные и обезличенные данные — можно передавать во внешние сервисы.
• Внутренние данные без персональных сведений — только в модели с корпоративным договором и запретом на обучение на ваших данных.
• Персональные данные клиентов и сотрудников, коммерческая тайна, исходный код — либо только в self-hosted или изолированном контуре, либо вообще запрет.

2. Кто и что может делать

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

3. Границы автономности

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

4. Логирование и аудит

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

5. Лимиты и контроль расходов

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

6. Ответственность

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

Три модели контроля: сравнение

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

Кому это пригодится, а кому пока рано

Писать политику стоит уже сейчас, если у вас:

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

Можно не спешить с формальным документом, если:

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

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

С чего начать за неделю

1. Составьте список: какие агенты и ассистенты уже используются в компании, кем и с каким доступом. Часто выясняется, что их больше, чем думало руководство.
2. Разметьте данные по чувствительности и решите, что вообще нельзя отдавать внешним моделям.
3. Для каждого агента определите границу автономности и порог, за которым нужен человек.
4. Включите логирование и лимиты расходов — технически, а не на бумаге.
5. Назначьте ответственного за каждый агент и опишите, что делать при инциденте.
6. Раздайте документ и соберите подтверждение, что сотрудники его прочитали.

Политику придётся пересматривать — модели, инструменты и цены меняются каждые несколько месяцев. Заложите дату регулярного пересмотра, иначе документ устареет быстрее, чем вы успеете его согласовать.

¹ Агент — программа на основе языковой модели, которая не только генерирует текст, но и самостоятельно вызывает внешние инструменты (API, поиск, код, файлы) для выполнения задачи, иногда в несколько шагов без участия человека между ними.