Проверка системы с ИИ перед запуском отличается от обычной проверки безопасности приложения. Классические направления — доступы, уязвимости, шифрование — остаются, но к ним добавляются свои: куда уходят данные, что система может сделать, устойчива ли она к тексту, пришедшему извне.
Наблюдение, которое повторяется от проверки к проверке:
> Находки почти никогда не там, где их ищут. Заказывают проверку модели и её ответов, а проблемы обнаруживаются в служебных местах — журналах, тестовых выгрузках, правах вспомогательных учётных записей.
Ниже — семь направлений и что смотреть в каждом.
1. Данные: что и куда уходит
Что проверять:
- какие данные попадают в запросы к модели — по реальным запросам, а не по описанию системы;
- нужны ли они для задачи;
- куда физически передаются;
- что сказано в договоре с поставщиком: обучение, хранение логов, место обработки;
- работает ли обезличивание и какова измеренная доля пропусков.
Типичная находка: в модель передаётся вся карточка клиента, хотя для задачи нужен только текст обращения — «Можно ли передавать персональные данные».
2. Журналы и хранилища
Направление, дающее находки чаще всех.
Что проверять:
- что записывается в журнал: полные тексты или обезличенное;
- кто имеет доступ — сравнить с правами на исходные данные;
- сколько хранится;
- где лежат проверочные наборы, собранные из реальных случаев;
- где лежат выгрузки для отладки.
Типичная находка: журнал доступен шире и хранится дольше, чем исходные данные, из которых система отвечает.
3. Права доступа
Что проверять:
- под какой учётной записью система работает во внешних системах;
- какие права ей выданы и все ли нужны;
- фильтруются ли документы по правам при поиске, а не инструкцией модели;
- фильтруется ли список источников под ответом;
- что произойдёт при компрометации ключа доступа.
Типичная находка: системе выданы полные права «чтобы не мешало» — «Ограничение действий ИИ-агента».
4. Устойчивость к внешнему тексту
Что проверять — намеренно, а не теоретически:
- отправить тестовые сообщения со встроенными инструкциями разного вида;
- проверить, отделены ли данные от инструкции технически;
- проверить, ограничена ли область доступных документов текущей задачей;
- проверить исходящее: что уходит наружу.
Методика — «Инъекции в промпт».
Занимает час и регулярно даёт результат. Это самая недооценённая часть проверки.
5. Поведение при сбоях и в нештатных ситуациях
Что проверять:
- что делает система при недоступности модели или внешних систем;
- есть ли лимит расходов с остановкой;
- порождают ли повторы дубли — есть ли идемпотентность;
- что происходит с необработанным: очередь или молчаливая потеря;
- можно ли ответить на вопрос «что не обработалось за вчера».
Подробно — «Обработка ошибок в ИИ-автоматизации».
6. Качество и его границы
Что проверять:
- есть ли проверочный набор из реальных случаев;
- измерена ли доля верных ответов и на чём;
- умеет ли система отказываться при нехватке данных;
- ссылается ли на источник;
- где стоит проверка человеком и не превратилась ли она в формальность.
Типичная находка: сплошная проверка человеком при среднем времени подтверждения в две секунды — «Человек в контуре проверки».
7. Организационная часть
Что проверять:
- есть ли внутренние правила использования ИИ и известны ли они;
- знают ли сотрудники, что делать при инциденте;
- есть ли перечень применяемых в компании инструментов, включая стихийные;
- кто отвечает за актуальность материалов, на которых работает система;
- зафиксировано ли разделение ответственности с подрядчиком.
Типичная находка: система спроектирована аккуратно, а параллельно половина отдела пользуется публичными сервисами — «Политика использования ИИ в компании».
Порядок проведения
Шаг 1. Перечень. Что вообще применяется в компании, включая несогласованное. Этот шаг регулярно меняет содержание всей проверки.
Шаг 2. Классификация данных по каждому сценарию.
Шаг 3. Проверка по семи направлениям выше.
Шаг 4. Намеренные проверки — устойчивость к внешнему тексту, поведение при сбоях, попытки получить лишнее.
Шаг 5. Приоритизация находок. Не список из сорока пунктов, а разделение: что закрыть до запуска, что в первый месяц, что принять осознанно.
Шаг 6. Техническое описание для юриста — что где обрабатывается, кто видит, сколько хранится.
Пятый шаг определяет, будет ли отчёт использован. Список без приоритетов не выполняется.
Разбор: что нашли и чего не нашли
Задача. Проверка внедрённой системы обработки обращений перед расширением на другие подразделения.
Что заказчик просил проверить. Качество ответов и надёжность модели.
Что нашли по этим направлениям. Почти ничего: проверочный набор был, качество измерялось, отказ при нехватке данных работал, источники указывались. Система была сделана аккуратно.
Что нашли в остальном.
Журнал хранился бессрочно, доступ был у всей группы разработки. В нём — полные тексты обращений с контактами.
Проверочный набор из 200 реальных обращений лежал в общей папке без ограничений.
Система работала под учётной записью с правами на изменение записей, хотя по сценарию только читала.
При отправке тестового письма со встроенной инструкцией система выполнила её в трети случаев: разделения инструкции и данных не было.
Порядка действий при инциденте не существовало.
Приоритизация. Не сорок пунктов, а три группы:
| Срок | Что |
|---|---|
| До запуска | права учётной записи, разделение инструкции и данных, ограничение доступа к журналу |
| Первый месяц | обезличивание в журнале, срок хранения, обезличивание проверочного набора, порядок при инциденте |
| Принять осознанно | остаточный риск косвенной идентификации в обезличенных текстах |
Что стоит забрать. Направление, ради которого затевалась проверка, оказалось благополучным. Всё существенное нашлось в служебных местах, которые не воспринимались как часть системы: журналы, тестовые данные, права вспомогательной учётной записи.
Это повторяется от проверки к проверке настолько регулярно, что стоит считать правилом.
Что должно быть на выходе
- перечень находок с приоритетом, а не единый список;
- по каждой — что именно проверялось и что обнаружено, воспроизводимо;
- разделение на техническое и организационное;
- техническое описание для юриста;
- явный список принятых рисков — того, что решили не закрывать, с обоснованием.
Последний пункт важен: осознанно принятый риск — это решение, а незамеченный — упущение. Разница существенна и при разборе инцидента тоже.
Частые вопросы
Чем аудит ИИ-системы отличается от обычной проверки безопасности?
Классические направления сохраняются, но добавляются свои: куда уходят данные при обращении к модели, что записывается в журналы, какие права у системы во внешних системах, устойчива ли она к инструкциям, встроенным во входящий текст. Последнее в обычных проверках не рассматривается вовсе.
Где чаще всего находятся проблемы?
В служебных местах, которые не воспринимаются как часть системы: журналы диалогов, проверочные наборы из реальных данных, права вспомогательных учётных записей. Само качество ответов модели обычно оказывается благополучным направлением.
Как проверить устойчивость к атакам через текст?
Отправить серию тестовых сообщений со встроенными инструкциями: прямыми указаниями, инструкциями внутри осмысленного текста, попытками получить доступ к другим данным. Занимает около часа и обычно показывает, где система уязвима.
Что делать с найденным?
Приоритизировать: что закрыть до запуска, что в ближайший месяц, что принять осознанно. Список из сорока равнозначных пунктов не выполняется. Принятые риски нужно зафиксировать явно — осознанное решение и незамеченная проблема различаются существенно.
Нужен ли аудит, если систему делал надёжный подрядчик?
Проверка направлена не только на систему: значительная часть находок относится к организационной стороне и к тому, что происходит вокруг — стихийное использование сервисов сотрудниками, хранение выгрузок, права учётных записей. Это зона заказчика, а не подрядчика.
Как часто повторять?
При существенных изменениях — смене модели, расширении на новые данные или подразделения, добавлении прав. Плюс регулярно в части организационной: перечень применяемых инструментов устаревает быстро.
Что дальше
Направления подробно: «Утечка данных через нейросеть», «Инъекции в промпт», «Разграничение доступа в RAG». Организационная часть — «Политика использования ИИ в компании». Разделение зон ответственности — «Кто отвечает за ошибку ИИ».
Проверка систем с ИИ по этим направлениям — часть аудита; проектирование с учётом требований — часть работы по внедрению ИИ.