ГК Softline: ИИ уже работает с данными. Кто отвечает за последствия?
Во многих компаниях ИИ-решения начинают работать раньше, чем служба информационной безопасности узнает об их существовании. За несколько месяцев команда может запустить инструмент, подтвердить его пользу для бизнеса и перейти к обработке рабочих данных. Когда система попадает в поле зрения ИБ, вопрос уже не сводится к разрешению на запуск. Нужно выяснить, как она устроена, к чему подключена и что произойдет, если ее работа нарушится.
Порог входа для таких проектов снизился. Чтобы собрать первый инструмент на базе доступной языковой модели, подразделению не всегда нужны отдельный ИТ-проект и длительные согласования. Небольшая команда может начать с локальной задачи: ускорить обработку обращений, работу с документами или другую рутинную операцию. Если результат устраивает пользователей, инструмент остается в работе и получает новые данные и функции.
Так в компании постепенно появляется несколько решений с разной архитектурой и разными владельцами. Одни обрабатывают клиентские данные, другие работают с финансовыми документами или внутренними регламентами. Параллельно сотрудники могут использовать публичные чат-боты для рабочих задач без какого-либо внедрения со стороны компании. У службы ИБ при этом может не быть ни полного перечня инструментов, ни сведений о том, какие данные через них проходят.
Мы в Softline считаем, что начинать с общего запрета в такой ситуации поздно. Запущенные системы уже встроены в работу подразделений, а бизнес видит результат. При этом проверять их все одновременно невозможно: сначала нужно понять, что именно используется и где последствия ошибки будут наиболее серьезными.
Самый очевидный риск связан с данными. Сотрудник может загрузить конфиденциальный документ в публичный чат-бот, не выяснив, как сервис обрабатывает и хранит переданную информацию. Дальнейшая судьба документа зависит от условий конкретного сервиса, но компания уже не управляет им так же, как данными в собственной системе. Поэтому важно знать не только перечень разрешенных инструментов, но и то, какие сведения сотрудники фактически им передают.
У агентских систем последствия могут быть шире. Агент отличается от чат-бота, который только отвечает на вопросы: он получает инструменты и может отправлять запросы, изменять записи или запускать операции. Если агенту предоставлен широкий доступ к внутренним системам, риск определяется уже не только содержанием ответа. Значение имеют действия, которые он способен выполнить, и бизнес-процессы, на которые они повлияют.
Сотрудник тоже пользуется доступами и инструментами, но нетипичная просьба может вызвать у него сомнения. Агент обрабатывает полученные инструкции в пределах заданной ему логики и доступных возможностей. Вредоносное указание, попавшее в обрабатываемый им контекст, может повлиять на его дальнейшие действия. Поэтому при оценке агента необходимо отдельно проверять, какие инструкции он получает, к каким системам обращается и где требуется решение человека.
Локальное размещение модели решает лишь часть проблемы. Оно позволяет не передавать данные в публичный сервис, но не устраняет промпт-инъекции, ошибки архитектуры, небезопасные компоненты и избыточные права доступа. Локальную систему также нужно проверять до начала работы с продуктивными данными. Само место размещения не показывает, насколько безопасно устроено решение.
Реакция в виде блокировки публичных моделей и внешних интерфейсов может дать время на разбор ситуации. Но она не отменит уже состоявшуюся передачу данных и не ответит на вопрос, какие системы работают внутри компании. Если согласование новых инструментов станет слишком долгим и непонятным, команды могут продолжить использовать их без участия ИБ. Контроль в таком случае станет еще сложнее.
В ИБ-проектах Softline мы рассматриваем инвентаризацию как первый шаг к управлению этими рисками. Нужно установить, какие ИИ-сценарии уже используются, кто владеет системами и кто получает результат их работы. Для каждой системы следует выяснить состав обрабатываемых данных, пользователей, интеграции и предоставленные права. Эта работа дает основу для дальнейших решений: что проверить в первую очередь, где ограничить доступы, а где изменить порядок работы.
Одного изучения документов недостаточно. Продуктовые и операционные команды знают, зачем они запустили инструмент, из каких частей он состоит и что произойдет, если его отключить. Разговор с ними помогает увидеть фактическую схему работы, а также определить владельца, который будет отвечать за изменения системы после проверки. Без этого даже подробно написанные правила могут не совпасть с тем, как ИИ используется на практике.
Следующий шаг — расставить приоритеты по последствиям. Обход правил информационного чат-бота на сайте и обход правил агента, имеющего доступ к финансовым операциям, требуют разного внимания. Для каждого сценария нужно определить, что система может сделать при ошибке или вредоносном воздействии, какие данные и процессы окажутся затронуты и как компания остановит нежелательные действия. Начинать следует с систем, где возможный ущерб для бизнеса выше.
Для нас в Softline важно, чтобы проверка не заканчивалась однократным согласованием. У ИИ-системы могут появиться новые пользователи, источники данных и инструменты. Вместе с ними меняются и последствия инцидента. Владелец системы и служба ИБ должны видеть такие изменения и заново оценивать доступы и допустимые действия агента.
Задача управления ИИ-рисками не состоит в обещании полностью исключить инциденты. Компания должна заранее знать, какие ИИ-системы участвуют в ее процессах, где проходят границы их самостоятельности и как действовать при нарушении этих границ. Тогда служба ИБ сможет работать с бизнесом до расширения опасного сценария, а при инциденте — опираться на известные доступы, владельцев и порядок действий, вместо того чтобы впервые восстанавливать устройство системы.
