Корпоративный AI-агент становится частью рабочей среды: он может читать документы, обращаться к приложениям, готовить ответы и запускать действия от имени пользователя.
Если злоумышленник или ошибочный процесс создаёт несанкционированного агента, команда получает скрытого исполнителя с доступом к данным и бизнес-процессам. Если передать модели слишком много прав или непроверенные данные, ускорение превращается в новый риск. Поэтому задача защиты — не запретить AI, а задать границы, журналирование и понятную ответственность.
Практическая задача
Практическая задача — контролировать создание, права и действия AI-агентов: кто может создать агента, какие приложения он видит, какие действия требуют подтверждения и где хранится журнал. На входе должны быть только нужные факты: журналы, схема доступа, список разрешённых действий, владелец системы и критерии остановки. На выходе — не приказ к выполнению, а проверяемая рекомендация.
Кейс
Кейс: сотрудник переходит по вредоносной ссылке, после чего в рабочей среде появляется агент с необычным набором разрешений. Система обнаруживает отклонение от шаблона, блокирует новые действия и создаёт задачу для расследования. Такой кейс показывает главный принцип: AI ускоряет подготовку решения, но каждое действие, которое меняет права, код, правила защиты или состояние среды, проходит через человека и техническую проверку.
Порядок внедрения
Первый шаг — описать границы сценария. Нужно указать, какие системы входят в область работы, какие данные можно использовать, какие инструменты доступны модели и кто утверждает результат. Без этого AI-помощник будет отвечать уверенно, но не обязательно безопасно.
Второй шаг — разделить действия на три группы. Низкий риск: сортировка событий, краткое описание, поиск связей. Средний риск: подготовка изменения, создание задачи, предложение правила. Высокий риск: изменение доступа, запуск команды, правка кода, блокировка учётной записи. Для высокой группы требуется отдельное подтверждение.
Третий шаг — вести журнал. В нём должны быть исходные данные, запрос к модели, ответ, использованные источники, решение человека и итог. Такой журнал нужен для разбора ошибок, обучения команды и доказуемости процесса перед внутренним аудитом.
Контроли безопасности
Нужны утверждение при создании агента, стандартные профили прав, запрет самоназначения доступа, отдельный журнал вызовов инструментов и регулярная сверка с владельцем процесса. Полезно использовать отдельные роли для чтения и изменения, временные разрешения, список разрешённых инструментов, запрет передачи секретов, маскирование чувствительных полей и автоматическую остановку при выходе за область задачи.
Отдельный контроль — проверка качества ответа. Модель должна явно разделять факты, предположения и вопросы к человеку. Если она не может назвать источник вывода или просит расширить доступ без причины, такой ответ нельзя использовать как основание для действия.
Практический пример
В отделе продаж AI-агенту разрешают готовить черновики писем и искать открытые материалы, но запрещают отправку сообщений, изменение CRM и экспорт списков клиентов без подтверждения. Команда заранее готовит шаблон запроса: цель, доступные журналы, запреты, допустимый формат ответа и список проверок. Это уменьшает случайность и помогает разным аналитикам получать сопоставимый результат.
После пилота результат сравнивается с обычным процессом. Измеряются время до первой гипотезы, число подтверждённых выводов, доля отклонённых рекомендаций, число ручных уточнений и влияние на скорость исправления. Если метрики не улучшаются, сценарий меняют или закрывают.
Типовые ошибки
Опасно давать агенту такие же права, как владельцу учётной записи, и не различать чтение, подготовку и выполнение действия. Ещё одна ошибка — оставлять в ответах модели общие советы без привязки к активам, владельцам и журналам. Без привязки к фактам такой совет нельзя превратить в безопасное действие.
Нельзя давать модели секреты, полные выгрузки персональных данных, закрытые ключи, токены и лишние журналы. Если для анализа нужны чувствительные сведения, лучше передавать обезличенные признаки, временные окна, хэши, идентификаторы событий и минимальные выдержки.
Что внедрить в первую очередь
Начать стоит с одного ограниченного сценария и одной команды. Выбрать повторяющуюся задачу, описать безопасный шаблон, назначить проверяющего, включить журналирование и запретить автоматические изменения. Через две недели собрать ошибки и уточнить правила.
Для защиты важна не только видимость агентов, но и управляемый жизненный цикл: создание, проверка, ограничение, отзыв прав и расследование. Такой подход даёт практическую пользу без лишней автономности: AI помогает быстрее увидеть связи и подготовить решение, а команда безопасности сохраняет контроль над данными, правами и последствиями.
Шаблон рабочего регламента
Для устойчивого процесса удобно оформить короткий регламент. В нём фиксируются цель сценария, владелец, допустимые источники данных, запрещённые сведения, уровень автономности, порядок подтверждения и срок пересмотра. Документ должен быть понятен не только службе безопасности, но и команде, которая каждый день будет пользоваться AI-помощником.
В регламенте отдельно указывается, что ответ модели не является самостоятельным основанием для изменения доступа, кода, сетевых правил или настроек защиты. Он считается черновиком решения: его можно использовать для ускорения анализа, но нельзя применять без проверки фактов и оценки побочных эффектов.
Роли и ответственность
Владелец системы отвечает за допустимость действия, аналитик или инженер — за проверку технических фактов, служба безопасности — за правила и контроль. Если эти роли не разделены, AI-процесс быстро становится непрозрачным: непонятно, кто разрешил действие, кто проверил вывод и кто должен исправлять ошибку.
Для спорных случаев нужен простой путь эскалации. Например, если модель предлагает расширить права, отключить правило защиты или изменить критичный участок кода, задача автоматически получает высокий уровень риска и отправляется на ручное согласование. Это снижает вероятность тихих изменений под видом обычной автоматизации.
Метрики качества
Оценивать нужно не только скорость. Важны доля подтверждённых выводов, число ложных рекомендаций, количество отклонённых действий, среднее время проверки человеком, повторяемость результата и число случаев, когда модель запросила лишний доступ. Эти показатели показывают, помогает ли AI команде или создаёт новый поток ручной работы.
Хорошая метрика — количество решений, которые можно воспроизвести по журналу. Если спустя неделю нельзя понять, почему модель дала рекомендацию и на каких данных она основана, процесс нельзя считать безопасным. Для рабочих сценариев нужна проверяемость, а не только удобный интерфейс.
Как начать без лишнего риска
Безопасный старт — это ограниченный пилот. Выбирается одна повторяющаяся задача, готовятся тестовые данные, назначается проверяющий и заранее описывается, какие действия запрещены. Первые результаты разбираются вручную: что модель сделала хорошо, где ошиблась, какие данные оказались лишними и какие ограничения нужно добавить.
После пилота можно расширять область постепенно: добавить новые источники журналов, ещё одну команду или дополнительные типы задач. Но каждое расширение должно проходить отдельную проверку рисков. Такой подход медленнее, чем полная автоматизация, зато он не ломает контроль и не превращает AI в неучтённого администратора.
