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