ГК Softline: фреймворк не защитит ИИ-систему без оценки ее рисков
Руководств по безопасности искусственного интеллекта уже много. Они подробно описывают угрозы и меры защиты, но компании трудно применить такой документ целиком к работающей системе. Часть требований относится к технологиям, которых в ней нет. При этом риск, связанный с ее данными или архитектурой, может остаться без внимания. Для службы ИБ возникает практический вопрос: с чего начать проверку и что исправлять в первую очередь.
Универсальный фреймворк вынужден охватывать разные модели, способы разработки и сценарии использования. Это делает его полезным справочником, но не готовым планом работ для конкретной компании. Если переносить требования в проект без отбора, команда потратит время на меры, которые не относятся к системе, и может пропустить то, что влияет на ее безопасность сейчас.
Предположим, компания запустила корпоративный чат-бот для ответов на вопросы сотрудников. В отраслевом руководстве есть требования к обучающим данным, дообучению модели и управлению наборами данных. Они обоснованны, но модель в этом проекте взяли готовой: компания ее не дообучала и собственный набор данных для этого не создавала. Проверка этих процессов не ответит на главный вопрос: какие риски есть у уже работающего чат-бота.
Для него существеннее может оказаться содержимое корпоративной базы знаний. Если туда попадут вредоносные данные, они повлияют на информацию, с которой работает модель. Другой риск связан с архитектурой: если при проектировании не предусмотрели запись пользовательских запросов, разбирать произошедшее после инцидента будет сложнее. Универсальный документ не знает устройства именно этого чат-бота. Поэтому мы в Softline считаем фреймворк набором возможных мер, а отправной точкой для защиты — конкретный сценарий использования ИИ.
Сначала нужно понять, что система делает для бизнеса. Например, агент обрабатывает обращения клиентов и инициирует действия в системе управления взаимоотношениями с клиентами (CRM). Дальше важны конкретные вопросы: кто обращается к агенту, какие данные он получает, сторонняя модель используется или собственная, проводилось ли ее дообучение, с какими системами агент связан и какие действия может выполнять без участия человека.
На многие из этих вопросов быстрее ответят продуктовая команда и владелец процесса, а не служба ИБ в одиночку. Они знают, для чего создан агент и как он работает на практике. Служба ИБ на основе этих сведений определяет, через какие данные, доступы и интеграции возможно воздействие на систему. Так каталог угроз сокращается до сценариев, которые действительно относятся к проекту.
Затем нужно оценить последствия каждого сценария для бизнеса. Деления на «критично» и «некритично» недостаточно. Важно выяснить, может ли ошибка или атака привести к финансовым потерям, раскрытию данных, остановке операции, ущербу для репутации или последствиям со стороны регулятора. Угроза, которая выглядит серьезной в общем перечне, может почти не затрагивать конкретную систему. И наоборот: малозаметная архитектурная ошибка может повлиять на критичный процесс.
В ИБ-проектах Softline эту логику можно оформить как скоринговую модель. В нее входят факторы риска, шкала оценки последствий, перечень угроз и связанных с ними требований защиты. Например, модель может содержать порядка 30 признаков сценария использования ИИ, около 40 угроз и около 70 требований. Эти числа описывают вариант построения инструмента, а не универсальную норму для каждой компании.
Связь между частями модели последовательна. Ответы о системе позволяют выбрать относящиеся к ней угрозы. Для этих угроз определяются меры защиты. Затем меры сравниваются по влиянию на риск, стоимости внедрения и числу сценариев, которые они закрывают. В результате команда получает список работ для конкретной ИИ-системы, расположенный по приоритету, а не весь каталог требований сразу.
Такой разбор не заменяет полноценную проверку безопасности. Он помогает решить, с чего начать, когда система уже работает, а ресурсов на одновременное выполнение всех рекомендаций нет. Кроме того, у службы ИБ и продуктовой команды появляется общая основа для разговора: они обсуждают устройство системы, возможный инцидент и его последствия для процесса, а не абстрактный список угроз.
Когда ИИ-сценариев становятся десятки или сотни, разбирать каждый как отдельное исключение уже трудно. Тогда компании нужна общая система управления безопасностью ИИ. Ее задача — закрепить принципы, которые удалось проверить на конкретных проектах, и сделать их применимыми при разработке и эксплуатации следующих систем.
Такая система начинается с решений верхнего уровня: какие способы использования ИИ компания допускает и как оценивает связанные с ними риски. Далее требуется распределить ответственность между владельцем процесса, продуктовой командой, разработчиками, ИТ и ИБ. Ответственность должна относиться к действиям, а не только к должностям: кто описывает сценарий, кто согласует доступы, кто проверяет изменения и кто принимает решение при инциденте.
Правила должны работать на протяжении жизненного цикла системы. Изменение источников данных, интеграций или самостоятельности агента меняет и его риски, даже если название продукта осталось прежним. Нужны также типовые архитектурные решения, чтобы команды не проектировали защиту с нуля каждый раз. Один из возможных вариантов — направлять обращения к внешним языковым моделям через шлюз, который маскирует персональные данные и фиксирует запросы для последующего анализа. Подходит ли он конкретной системе, зависит от ее задач и устройства.
Для нас в Softline важно и то, кто будет применять эти правила. Разработчику, владельцу системы и конечному пользователю нужны разные знания об ИИ-рисках. Владелец должен понимать последствия действий агента для своего процесса, разработчик — ограничения выбранной архитектуры, пользователь — какие данные можно передавать инструменту. Такую систему управления нельзя создать одним приказом: ее приходится уточнять по мере разбора работающих проектов.
Специализированные средства защиты помогают выполнять отдельные задачи внутри этой системы. ИИ-шлюзы и межсетевые экраны для языковых моделей могут проверять запросы и ответы, выявлять конфиденциальные данные, обезличивать их, блокировать нежелательные обращения и фиксировать события для мониторинга. Они работают как промежуточный слой между пользователем и моделью. Но наличие шлюза само по себе не определяет, какие данные допустимы в конкретном бизнес-процессе и какие действия разрешены агенту.
Другой класс средств задает ограничения поведения модели. Такие механизмы, часто называемые guardrails, могут входить в состав шлюза или применяться отдельно. При их использовании важно понимать, как они принимают решение. Если ограничение проверяет другая языковая модель, этот защитный механизм тоже обрабатывает потенциально вредоносное содержимое. Его работу необходимо проверять, а не считать безошибочной только потому, что он предназначен для защиты.
Отдельного внимания требуют связи агента с внешними инструментами, в том числе через Model Context Protocol (MCP). По мере роста числа таких связей увеличивается число действий, которые может выполнить агент, и точек, где требуется контроль. Здесь недостаточно проверить текст ответа модели. Нужно знать, к какому инструменту она обращается, какие данные передает и какое действие запускает.
Проверка защиты должна включать попытки заставить систему нарушить заданные правила. Для языковой модели это могут быть вредоносные инструкции в обрабатываемом содержимом, попытки получить закрытую информацию или обойти ограничения с помощью специально построенного диалога. Такое тестирование, или red teaming, дополняет обычные проверки архитектуры и доступов: оно показывает, как система ведет себя при воздействии, а не только как должна работать по документации.
Мы в Softline видим управленческую задачу в правильном порядке действий. Сначала компания описывает конкретный ИИ-сценарий, его данные, доступы и последствия сбоя. Затем выбирает относящиеся к нему требования, внедряет меры защиты и проверяет их на практике. Опыт отдельных проектов постепенно становится общими правилами. Такой порядок позволяет службе ИБ принимать решения по реальным рискам и готовить компанию к инцидентам, не ожидая фреймворка, который заранее учтет устройство каждой ее системы.
