AI-агенту не нужно взламывать систему. Иногда ему уже все разрешили

Я готовила собственный цифровой контур к работе с AI-агентами — и начала не с модели, а с пересмотра данных, доступов и точек остановки.
Я готовила собственный цифровой контур к работе с AI-агентами — и начала не с модели, а с пересмотра данных, доступов и точек остановки.

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

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

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

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

Поэтому вместо «что умеет AI?» я перешла к вопросам:

что я действительно вижу, измеряю, какие действия разрешаю системе — и где решение должно вернуться ко мне?

Работу с цифровым контуром разделила на две связанные части:

наблюдаемость — понять, что происходит;

и контроль — определить, что системе разрешено.

Первое открытие: события еще не являются доказательствами

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

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

Пришлось разделить:

техническое событие → действие пользователя → коммерческий сигнал → бизнес-результат.

А затем задать для каждого показателя один вопрос:

Какое управленческое решение он поможет изменить?

Часть данных не выдержала такой проверки.

Избыточный поток событий я отключила, оставила достаточную аналитику и начала новый отсчет фактических показателей.

Я не отказалась от аналитики. Я отказалась от сбора данных без понятного назначения.

Ценность данных определилась не объемом, а решением, которое они помогают принять.

Второе открытие: защищать нужно не только модель

Затем я проследила путь данных и действий через весь процесс: сайт, формы, аналитику, автоматизации, документы и доступы.

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

Эти изменения еще не означают, что компания защищена от AI-агентов. Но они сократили отдельные риски и создали основу для следующего этапа проверки.

Мое главное изменение произошло в самом взгляде на безопасность:

важно не только то, какой ответ даст AI, но и то, что ему будет разрешено сделать с этим ответом.

В OWASP Top 10 for LLM Applications этот риск называется Excessive Agency: система получает избыточные функции, разрешения или автономию.

Именно здесь Human Gate перестает быть красивым принципом и становится частью архитектуры безопасности.

Пять вопросов перед подключением AI к процессу

Теперь я проверяю:

  1. Что система измеряет — и какое решение поддерживает этот показатель?
  2. Какие данные AI сможет увидеть?
  3. Что он сможет изменить, удалить, отправить или опубликовать?
  4. От чьего имени и с какими правами он будет действовать?
  5. Каковы последствия ошибки — и где действие обязательно остановится перед человеком?

Я начинала ревизию с желания подготовить компанию к AI-агентам. А пришла к более общему выводу:

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

А какое действие AI уже может выполнить в вашей компании самостоятельно — и кто способен его остановить?

2