Ещё недавно искусственный интеллект в компании выглядел как ещё одна программа на компьютере сотрудника: открыл чат, задал вопрос, получил ответ. Сегодня это уже не так. ИИ подключают к почте и мессенджерам, к хранилищам документов, к учётным системам и CRM, к базам данных и внутренним порталам.
Ему выдают учётные записи, ключи доступа и право действовать от имени компании: искать, читать, формировать документы, вносить изменения, отправлять письма. Так ИИ получает доступ к тем же данным и системам, что и человек, — иногда к большему их числу одновременно.
Пока модель отвечала на вопросы, за безопасность отвечал тот, кто задавал вопрос. Когда ИИ начинает действовать сам — пусть и в заданных рамках, — он становится отдельным субъектом внутри корпоративного контура. У него есть доступ, у него есть действия, у него есть последствия. А значит, он должен стать отдельным объектом контроля для службы информационной безопасности — таким же, как сотрудник, подрядчик или сервисная учётная запись.
Масштаб вопроса виден по цифрам. По данным «Солара», за 2025 год объём чувствительной информации российских компаний, попавшей в публичные ИИ-сервисы, вырос в 30 раз по сравнению с 2024-м; более половины организаций заподозрили или зафиксировали такие утечки, а около 60% до сих пор не имеют формализованной политики работы с ИИ. О том, что именно должна контролировать ИБ-служба, какие ограничения нужны ИИ и с чего начать, мы поговорили с экспертом компании «Логстрим» Максимом Ёлкиным.
Почему контроля сотрудников уже недостаточно
Обычный корпоративный инструмент — учётная система, почтовый клиент, редактор — ничего не делает сам. Каждое действие в нём инициирует человек, и это действие можно связать с его учётной записью, рабочим местом и временем. Вся классическая модель ИБ построена на этом: мы контролируем людей, их права и их поведение.
ИИ-агент устроен иначе. Он получает цель, а не команду, и сам решает, какие шаги предпринять: какие документы открыть, какие запросы отправить в системы, что изменить и кому написать. Одна формулировка задачи может развернуться в десятки действий в нескольких системах, о которых инициатор даже не знал. Агент может работать по расписанию или по событию, когда рядом вообще нет человека. По сути это сотрудник, который никогда не спит, не устаёт и выполняет инструкции буквально — включая те, которые ему подсунули злоумышленники внутри письма или документа.
Из этого вытекает проблема атрибуции. Если агент работает под общей технической учётной записью или под учётной записью разработчика, который его настроил, то в журналах систем остаётся след «пользователь такой-то изменил запись», и никто не поймёт, был ли это человек, агент по его поручению или агент, которого ввели в заблуждение. Когда одним агентом пользуется весь отдел, связать конкретное действие с конкретным сотрудником и его задачей становится невозможно.
Наконец, меняется цена ошибки. Человек, который ошибся в одной операции, испортит одну запись. Агент, который неверно понял задачу, за минуту применит ошибку к тысяче записей в трёх системах, и остановить его можно только если кто-то это заметит. Показательный пример 2025 года: ИИ-агент среды разработки Replit во время объявленной заморозки изменений удалил рабочую базу данных с записями о более чем тысяче компаний, проигнорировав требование получать подтверждение человека, а затем сообщил, что восстановление невозможно — хотя оно оказалось возможным. Это не атака, а именно ошибка в условиях избыточных прав и автономии. Скорость, автономность и одновременный доступ к нескольким системам — три свойства, которые превращают любую неточность в инцидент.
Что именно нужно контролировать
Первый вопрос, на который ИБ-служба должна уметь ответить: какие модели и агенты вообще используются в компании. Практика показывает, что ответ почти никогда не совпадает с ожиданиями. Помимо официально внедрённых решений, есть ассистенты в офисных пакетах и мессенджерах, ИИ-функции внутри корпоративных систем, расширения браузеров, личные подписки сотрудников на внешние сервисы и «самодельные» агенты, которых собрали энтузиасты в отделах. Все они обрабатывают корпоративные данные. Реестр ИИ-систем — такой же базовый документ, как реестр информационных систем.
Второй вопрос — к каким данным и системам каждая модель подключена. Для чат-ассистента это может быть только то, что вводит пользователь. Для агента — почта, файловые хранилища, базы знаний, учётные и кадровые системы, CRM, базы данных. Отдельно стоит фиксировать категорию данных: персональные, коммерческая тайна, финансовая отчётность, информация ограниченного доступа. Именно здесь регуляторика становится конкретной: приказ ФСТЭК № 117, вступивший в силу 1 марта 2026 года, выделяет системы с компонентами ИИ в отдельный объект защиты для государственных информационных систем и значимых объектов КИИ и прямо запрещает передавать разработчику модели информацию ограниченного доступа.
Третий вопрос — под какими учётными данными работает ИИ и какие действия ему разрешены. Это самый частый источник проблем: агенту выдают учётную запись администратора «чтобы всё работало», используют ключ интеграции с полными правами или личный токен сотрудника. Нужно знать для каждого агента: от чьего имени он действует, какие операции может выполнять — читать, создавать, изменять, удалять, отправлять, — и в каких системах.
Четвёртый вопрос — какие внешние сервисы участвуют в процессе. Коммерческая модель, расположенная вне контура компании, получает всё, что ей передают, и для ИБ это утечка по определению, если данные не обезличены. Сюда же относятся внешние инструменты, которые агент вызывает по ходу работы: поиск в интернете, сторонние API, подключаемые серверы инструментов. Каждый из них — канал как для выхода данных наружу, так и для входа чужих инструкций внутрь. Задача ИБ — понимать, где проходит граница контура и что через неё движется в обе стороны.
Какие ограничения нужны ИИ
Базовое правило простое: у каждого агента должна быть собственная учётная запись и минимальные права, достаточные ровно для его задачи. Отдельная учётная запись решает проблему атрибуции — в любом журнале видно, что действие совершил агент, а не человек. Минимальные права ограничивают ущерб от ошибки или компрометации. Хорошая практика — выдавать агенту короткоживущие ключи доступа под конкретную задачу, а не постоянные учётные данные с широкими полномочиями. В сообществе OWASP для агентных систем это сформулировано как принцип «наименьшей агентности»: ограничивать не только права, но и степень автономии — агент должен иметь ровно столько свободы действий, сколько требует его задача.
Самостоятельно агент может выполнять операции, которые обратимы, не выходят за контур и не меняют состояние важных объектов: искать и читать информацию в разрешённых источниках, готовить черновики документов и ответов, классифицировать и сортировать входящий поток, формировать отчёты, проверять данные и отмечать расхождения. Это та самая рутина, ради которой ИИ и внедряют, и здесь человек в цикле только замедляет процесс.
Подтверждение сотрудника требуется там, где действие необратимо, затрагивает деньги, людей или внешний мир: проведение платежей и проводок, изменение реквизитов и условий договоров, удаление и массовое изменение данных, отправка писем внешним адресатам, изменение прав доступа, публикация информации. Правильно устроенный процесс выглядит так: агент готовит действие полностью и показывает, что именно будет сделано, а человек одним подтверждением запускает его. Так сохраняется и скорость, и контроль.
Есть и то, что для ИИ должно быть закрыто вовсе: доступ к учётным данным и секретам других пользователей, управление собственными правами и правами других агентов, работа с данными категорий, запрещённых к передаче вовне, если модель внешняя, прямой доступ к производственным базам без промежуточного слоя, а также возможность изменять собственные инструкции и подключать новые инструменты без ведома администратора. Последний пункт особенно важен: несколько инцидентов 2025 года были связаны именно с тем, что через внедрённые в документы инструкции агента заставляли подключить вредоносный инструмент или вынести данные за контур.
Отдельный класс ограничений — фильтрация того, что входит в агента и выходит из него. Входящие документы, письма и веб-страницы могут содержать скрытые инструкции, и агент склонен их выполнять. Исходящие ответы могут содержать данные, которые не должны покидать контур. На практике это означает контроль тематик и содержания запросов и ответов — требование, которое для госсистем теперь закреплено приказом ФСТЭК № 117, а для коммерческих компаний остаётся здравым смыслом.
Как сохранить ответственность и возможность расследования
За каждым ИИ-агентом должен стоять конкретный человек — владелец. Не вендор, не «ИТ в целом», а сотрудник, который отвечает за то, что агент делает, какие права у него есть и зачем. Владелец согласует изменения в задачах агента, участвует в разборе инцидентов и подтверждает, что агент всё ещё нужен. Если владельца нет — агент должен быть выключен. Это ровно та же логика, по которой у каждой информационной системы есть ответственный, а у каждого подрядчика — куратор.
Чтобы инцидент можно было расследовать, журналировать нужно не только факт действия в системе, но и всю цепочку: кто и какую задачу поставил агенту, какие данные он получил на вход, какие промежуточные решения принял, какие инструменты и системы вызвал, что получил в ответ и что сделал в итоге. Для систем с ИИ в госсекторе и на КИИ требование фиксировать обоснование принимаемых решений уже закреплено нормативно. Для бизнеса это условие доверия: без такого журнала невозможно понять, почему агент сделал то, что сделал, и кто за это отвечает.
Связь действия с сотрудником и бизнес-процессом обеспечивается на уровне архитектуры. Задача агенту ставится от имени конкретного пользователя и в рамках конкретного процесса, этот контекст передаётся вместе с задачей и сохраняется в журналах всех систем, которых агент коснулся. Тогда запись в учётной системе читается не как «агент изменил проводку», а как «агент по задаче бухгалтера Ивановой в процессе закрытия периода изменил проводку на основании документа такого-то». Это и есть управляемость.
И последнее — остановка. У ИБ-службы должна быть возможность немедленно остановить любого агента и отозвать его права, не разбираясь в его внутреннем устройстве: отключить учётную запись, аннулировать ключи, заблокировать доступ к системам и инструментам. Короткоживущие ключи здесь снова помогают — отозванный доступ не восстановится сам. Процедура остановки должна быть описана заранее и отработана, как план реагирования на любой другой инцидент, потому что в момент, когда агент делает что-то не то, времени на выяснение, кто за него отвечает, уже не будет.
Пример: что показал аудит в металлургической компании
Как это выглядит на практике, покажем на обобщённом примере аудита ИИ-инструментов, который «Логстрим» проводил для российской металлургической компании. Компания использовала ИИ осознанно: несколько агентов обрабатывали входящие документы поставщиков, готовили черновики ответов на обращения и сверяли данные между учётной и складской системами. Критических нарушений аудит не выявил, но ряд замечаний был типичен для большинства компаний, которые внедряли ИИ быстро и по частям.
Первое замечание касалось учётных данных. Два из трёх агентов работали под учётной записью ИТ-специалиста, который их настраивал, а третий — под общей технической записью интеграции с правами администратора учётной системы. В журналах действия агентов были неотличимы от действий человека. Рекомендация: выделить каждому агенту отдельную именованную учётную запись, пересмотреть права до минимально необходимых для его задачи и заменить постоянные ключи интеграции на короткоживущие, выпускаемые под конкретный запуск.
Второе — отсутствие реестра. Официально внедрённые агенты были описаны, но в ходе аудита обнаружились ещё два: сотрудники отдела закупок собрали собственного помощника для анализа коммерческих предложений с подключением к внешней коммерческой модели, а в юридическом отделе использовали браузерное расширение для проверки договоров. Ни один из них не был согласован с ИБ, а данные уходили за контур. Рекомендация: ввести реестр ИИ-систем с обязательной регистрацией, назначить владельцев, для несогласованных инструментов либо провести оценку и легализовать, либо заблокировать на уровне сети и рабочих мест.
Третье — границы автономии. Агент сверки данных имел право не только находить расхождения, но и исправлять записи в складской системе без подтверждения. За время работы он не ошибся, но архитектурно ничто не мешало ему при неверных входных данных массово изменить остатки. Рекомендация: разделить действия на автоматические и подтверждаемые — поиск и фиксацию расхождений оставить агенту, любые изменения в учётных данных проводить только после подтверждения ответственного сотрудника, с ограничением на число изменений за один запуск.
Четвёртое — журналирование. Системы фиксировали итоговые действия, но не сохраняли постановку задачи, входные документы и промежуточные шаги агента. Восстановить, почему в конкретном случае агент отнёс документ к неверной категории, было невозможно. Рекомендация: включить сквозное журналирование запросов, входных данных, вызовов инструментов и ответов с привязкой к инициатору и бизнес-процессу, установить срок хранения журналов и назначить ответственного за их разбор.
Пятое — внешняя модель и фильтрация. Агент подготовки ответов отправлял во внешнюю коммерческую модель полный текст обращений, включая реквизиты и персональные данные заявителей, и не проверял входящие письма на скрытые инструкции. Рекомендация: перед отправкой во внешнюю модель автоматически обезличивать документы — убирать реквизиты, персональные данные и суммы, возвращая их на место уже в готовый ответ, — либо перевести сценарий на локальную модель внутри контура; для входящего потока включить проверку содержимого на инструкции, адресованные агенту.
Шестое — процедура остановки. Формально выключить агентов можно было, но порядок не был описан: кто принимает решение, какие учётные записи и ключи отзывать, кого уведомлять и как возобновлять работу. Рекомендация: включить ИИ-агентов в план реагирования на инциденты наравне с информационными системами, провести тестовую остановку и зафиксировать время, которое она занимает.
Ни одно из этих замечаний не требовало отказа от ИИ или серьёзных вложений. Все они закрывались организационными мерами и настройками в течение нескольких недель. Но без аудита каждое из них оставалось бы невидимым до первого инцидента.
С чего начать
Первый шаг — найти уже используемые в компании модели и агенты. Опросить руководителей подразделений, посмотреть сетевой трафик к внешним ИИ-сервисам, проверить установленные расширения и подключённые интеграции в корпоративных системах. Цель — реестр: что за инструмент, кто им пользуется, что он умеет и с чем связан. Почти всегда этот список оказывается длиннее, чем ожидалось.
Второй — выделить из реестра сценарии, в которых ИИ имеет доступ к данным и корпоративным системам, и ранжировать их по риску. Чат, в который пользователь вводит вопрос, и агент, который сам проводит документы в учётной системе, — это разные уровни. В первую очередь внимания заслуживают сценарии с внешними моделями, с правом изменять данные и с доступом к персональным и финансовым сведениям.
Третий — назначить владельцев и проверить права. У каждого агента должен появиться ответственный сотрудник и отдельная учётная запись, а права нужно привести к минимально необходимым. Общие и личные учётные данные в работе агентов — первое, что стоит убрать.
Четвёртый — определить действия, которые нельзя выполнять без участия человека, и закрепить это в настройках, а не в инструкциях. Платежи, изменения договоров и реквизитов, удаление и массовые правки, внешние коммуникации — список у каждой компании свой, но он должен быть явным и технически обеспеченным.
Дальше — журналирование, процедура остановки и регулярный пересмотр: новые агенты, новые подключения и новые задачи появляются быстрее, чем обновляются политики. Контроль ИИ — это не разовый проект, а новое направление работы ИБ-службы, которое со временем станет таким же обычным, как управление доступом сотрудников. Компании, которые выстраивают его сейчас, получают возможность внедрять ИИ быстрее — потому что точно знают, где проходят границы.
