Политика использования ИИ в компании: какие правила задать AI-агентам

Представим простую ситуацию: AI-агент уже умеет создать возврат, изменить статус сделки и отправить письмо клиенту. Технически всё работает. Но первый вопрос, который я бы задал, звучит иначе: какое из этих действий система вообще имеет право выполнить сама и почему мы так решили?

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

NIST предлагает смотреть на управление AI через функции Govern, Map, Measure и Manage. Мне близка сама логика: сначала договориться об ответственности и контексте, затем измерять риск и только потом расширять применение. Для бизнеса это можно перевести в довольно приземлённую операционную модель.

Governance начинается не с запрета, а с права на действие

Я бы разделил два вопроса. Первый: может ли модель сформировать хороший вариант решения? Второй: имеет ли система право превратить этот вариант в изменение реального мира. Между ними и находится большая часть governance, которая действительно влияет на работу.

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

Поэтому я бы описывал не список «разрешённых AI-функций», а матрицу действий. Для каждого действия нужны объект, допустимые параметры, источник фактов, предел суммы или области изменения, условие подтверждения и понятный terminal state. Это скучнее обещания автономного агента. И полезнее.

• обратимое действие с низкой ценой ошибки — кандидат на автоматическое выполнение
• обратимое, но клиентски заметное действие — обычно требует дополнительных policy-проверок
• денежное, правовое или труднообратимое действие — сильный кандидат на human approval
• неизвестное или неописанное действие — должно завершаться отказом, а не импровизацией модели

Проверяемые источники: NIST — AI Risk Management Framework · NIST AI Resource Center — AI RMF Core: Govern, Map, Measure, Manage

Полномочия лучше давать уровнями, а не одним переключателем

Мне не очень нравится формулировка «агент автономный». Она скрывает слишком много деталей. Один и тот же агент может самостоятельно читать CRM, только предлагать изменение цены и без подтверждения создавать внутреннюю задачу. Автономность здесь не свойство всей системы, а свойство конкретного класса действий.

Я бы начал с нескольких уровней. На первом AI только объясняет или суммирует. Затем предлагает действие. Потом готовит команду, которую подтверждает человек. Дальше можно разрешить ограниченный набор обратимых действий внутри заранее заданных параметров. Полная свобода «реши сам, что делать» в бизнес-процессе почти никогда не является хорошей стартовой точкой.

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

Проверяемые источники: OWASP GenAI Security Project — Agentic AI — Threats and Mitigations · OWASP GenAI Security Project — OWASP Top 10 for Agentic Applications for 2026

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже

Human oversight — это роль в процессе, а не кнопка «подтвердить»

Человек в контуре легко превращается в декоративный элемент. Если сотруднику показывают сорок подтверждений в час без контекста, он довольно быстро начинает нажимать «одобрить» автоматически. Формально human-in-the-loop есть. По сути контроля уже нет.

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

Европейские правила вокруг AI отдельно подчёркивают AI literacy и human oversight в рискованных сценариях. Даже если конкретная компания не находится в соответствующей юрисдикции, практический вывод шире закона: человек, которому оставили последнее слово, должен понимать систему и последствия решения, иначе контроль остаётся формальностью.

Проверяемые источники: European Commission — AI Literacy — Questions & Answers

Журнал действий нужен не ради архива, а ради восстановления решения

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

Это не означает, что нужно хранить внутренние рассуждения модели или собирать всё подряд. Наоборот, лишние данные создают новые риски. Полезен минимальный audit trail, который связывает входное событие, решение policy, вызванный инструмент и конечный бизнес-статус.

Такой журнал меняет и разговор об ошибках. Вместо «AI опять что-то сделал» можно увидеть, что модель предложила корректное действие, но tool получил неверный параметр; или что policy разрешила операцию, хотя лимит был настроен слишком широко. Разные причины требуют разных исправлений.

Проверяемые источники: OWASP GenAI Security Project — Agentic AI — Threats and Mitigations

Kill switch полезен только вместе с понятным безопасным состоянием

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

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

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

Проверяемые источники: OWASP GenAI Security Project — Agentic AI — Threats and Mitigations · OWASP GenAI Security Project — OWASP Top 10 for Agentic Applications for 2026

Как понять, что автономность можно расширить

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

Перед расширением полномочий полезно проверить стабильность входных данных, долю и типы исключений, воспроизводимость audit trail, способность безопасно повторить или отменить действие и реальную нагрузку на людей, которые разбирают спорные случаи. Если один из этих элементов не работает, новая автономность обычно лишь переносит проблему дальше по процессу.

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

Проверяемые источники: NIST — AI Risk Management Framework · NIST AI Resource Center — AI RMF Core: Govern, Map, Measure, Manage

Вопросы, которые я бы уточнил до следующего шага

Нужен ли отдельный AI governance комитет небольшой компании?

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

Какие действия AI лучше всегда подтверждать человеку?

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

Достаточно ли логировать все tool calls агента?

Нет. Tool call сам по себе не объясняет бизнес-решение. Нужна связь с исходным событием, policy, параметрами действия и конечным состоянием внешней системы.

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

Рядом с этой темой я бы держал для «политика использования ИИ в компании»: Какие действия AI можно выполнять автоматически, а какие требуют подтверждения · Как вести журнал действий AI-агента · Что происходит с бизнес-процессом, когда AI недоступен.