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