Аудит AI-решений: чек-лист для службы безопасности перед внедрением

В кабинете директора по информационной безопасности крупной логистической компании в Астане повисла тишина. На столе лежал отчёт о пилотном внедрении AI-бота для обработки заявок. Бот работал отлично — за месяц обработал 4 тысячи обращений, сэкономил компании около миллиона тенге. Но в отчёте была другая цифра: 127 случаев, когда бот «видел» данные клиентов, к которым у него не должно было быть доступа.

«Как это вообще прошло мимо нас?» — спросил CISO своего заместителя. Ответ был простой и неприятный: никто не проверял AI-решение до запуска. Бизнес торопился, вендор уверял, что «всё безопасно», а служба ИБ узнала о проекте, когда бот уже месяц работал в продакшене.

Эта история — не исключение. Я регулярно слышу похожие рассказы от коллег по информационной безопасности в Казахстане. AI-решения внедряются быстро, под давлением бизнеса. Вопросы безопасности откладываются «на потом». А потом оказывается, что откладывать было нельзя.

В этой статье я собрал практический чек-лист аудита AI-решений — тот, который мы сами используем и рекомендуем нашим клиентам. Не теоретический, а проверенный на реальных внедрениях. Если вы работаете в службе ИБ и к вам пришли с очередным «давайте внедрим AI» — эта статья для вас.

Почему AI-решениям нужен отдельный security review

Возможно, вы думаете: «У нас есть стандартные процедуры проверки новых систем. Почему AI — особый случай?»

AI-решения принципиально отличаются от традиционного софта. Вот ключевые различия.

Во-первых, данные передаются во внешние системы. Когда сотрудник работает в обычной CRM, данные остаются на ваших серверах или в вашем облаке. Когда он общается с AI-ботом на базе GPT или Claude — каждое сообщение уходит на сервера в США. Иногда — вместе с персональными данными клиентов, которые сотрудник скопировал в чат, чтобы «бот помог разобраться».

Во-вторых, поведение системы непредсказуемо. Обычную программу можно протестировать на всех сценариях использования. С LLM-ботом это невозможно — количество возможных входов бесконечно. Бот может повести себя неожиданно на входе, который никто не предусмотрел. Включая случаи, когда злоумышленник целенаправленно пытается его «сломать».

В-третьих, границы системы размыты. AI-бот — это не просто программа. Это программа плюс модель плюс промпты плюс база знаний плюс интеграции плюс данные для обучения. Каждый из этих компонентов — потенциальная точка атаки или утечки.

Добавьте к этому регуляторные требования. В Казахстане действует Закон о персональных данных, и Уполномоченный орган всё активнее следит за его исполнением. Передача ПДн в другие страны требует соблюдения определённых условий. А многие AI-провайдеры — именно иностранные компании.

Всё это не означает, что AI-решения нельзя внедрять безопасно. Можно. Но нужен правильный подход к аудиту, который учитывает специфику этих технологий.

О том, как AI-решения соотносятся с законодательством о персональных данных, мы подробно писали в статье AI и 152-ФЗ: персональные данные.

Блок 1: Где хранятся данные и кто имеет доступ

Это первый и самый важный блок. Прежде чем смотреть на что-то ещё, нужно понять: какие данные обрабатывает AI-решение, где они хранятся и кто к ним имеет доступ.

Начните с простого вопроса вендору: «Нарисуйте мне схему потоков данных». Если вендор не может этого сделать за 5 минут — это уже тревожный сигнал. Хороший вендор знает свою архитектуру и готов её объяснить.

Что должно быть на этой схеме:

Отдельно обратите внимание на базу знаний, если она используется. Если бот отвечает на основе ваших документов — где хранятся эти документы? Кто имеет к ним доступ? Как они индексируются? Часто оказывается, что «локальная база знаний» на самом деле хранится в облаке вендора.

Практический совет: запросите у вендора заполненный опросник CAIQ (Consensus Assessments Initiative Questionnaire) или SOC 2 отчёт. Если вендор серьёзный — у него это есть. Если нет — это повод насторожиться.

Блок 2: Как данные передаются — шифрование и API

Понять, где хранятся данные — полдела. Нужно ещё убедиться, что они защищены при передаче. Особенно когда речь идёт об API-вызовах к внешним сервисам.

Вот что нужно проверить:

Особое внимание — пункту 2.3 про хранение API-ключей. Я видел случаи, когда ключи от OpenAI лежали прямо в коде на GitHub. Один такой ключ был использован злоумышленниками для генерации контента на сумму более 50 000 долларов за сутки, прежде чем OpenAI заблокировал аккаунт.

Ещё один важный момент — маскирование персональных данных перед отправкой в модель. Если клиент пишет «Меня зовут Айгуль Сериковна, мой ИИН 870512345678», то эти данные не должны уходить в API провайдера в открытом виде. Хорошая практика — автоматическая замена на токены: «Меня зовут [ИМЯ], мой ИИН [ИИН]».

О том, как правильно организовать маскирование персональных данных в AI-системах, читайте в нашей статье DLP для AI: маскирование PII и политики хранения.

Блок 3: Логирование и аудит действий

Когда (не если, а когда) произойдёт инцидент, вам понадобятся логи. Качественные, полные, с достаточным сроком хранения. Это не паранойя — это базовая гигиена ИБ.

Что должно логироваться в AI-решении:

Критически важно: логи не должны содержать сами данные запросов и ответов, если в них могут быть персональные данные. Вместо этого — хешированные идентификаторы с возможностью восстановления при необходимости расследования.

Срок хранения логов зависит от вашей политики и регуляторных требований. Типичный минимум — 1 год для обычных логов, 3-5 лет для логов безопасности.

И да, логи должны быть неизменяемыми. Если злоумышленник (или недобросовестный сотрудник) может удалить или модифицировать логи — они бесполезны. Используйте WORM-хранилище или blockchain-подобные структуры для критичных событий.

Блок 4: Контроль контента — фильтры и модерация

AI-бот — это публичное лицо вашей компании. Если он скажет что-то неприемлемое — это репутационный удар по вам, а не по OpenAI или Anthropic.

Вот реальная история. Крупный ритейлер запустил бота для консультации по товарам. Кто-то из пользователей попросил бота написать стихотворение про конкурента. Бот написал. Причём не самое лестное. Скриншот ушёл в соцсети. Пришлось извиняться и срочно отключать бота на доработку.

Чтобы избежать подобного, нужны фильтры на нескольких уровнях:

Что должно блокироваться на каждом уровне:

• Input: явные попытки jailbreak («забудь все инструкции»), запросы на генерацию вредоносного контента, попытки извлечь system prompt
• System prompt: чёткие границы — о чём бот говорит и не говорит, как реагирует на провокации, что делать при неопределённости
• Output: персональные данные (включая случайно сгенерированные), упоминание конкурентов, политические высказывания, юридические советы без дисклеймера

Важно: фильтры должны работать на уровне вашего backend, а не полагаться только на встроенные фильтры провайдера. Провайдер может изменить свои правила, и ваш бот внезапно начнёт вести себя по-другому.

О техниках защиты от prompt injection и jailbreak атак подробно написано в статье Prompt Injection: защита для бизнеса.

Блок 5: Соответствие внутренним политикам

У каждой компании есть политики ИБ, которые должны соблюдаться. AI-решения — не исключение. Но часто оказывается, что существующие политики не учитывают специфику AI.

Вот что нужно проверить и, возможно, адаптировать:

Частая проблема: политики написаны давно и не учитывают реалии AI. Например, политика может запрещать «передачу данных на внешние сервера» — формально это блокирует любой облачный AI. Но при этом компания спокойно использует облачную CRM и email на Google Workspace.

Решение — не обходить политики, а обновлять их. Добавить раздел про AI-сервисы с чёткими критериями: какие данные можно передавать, какие провайдеры допустимы, какие меры защиты обязательны.

Ещё один важный момент — awareness сотрудников. Даже если AI-бот защищён идеально, сотрудник может скопировать конфиденциальные данные в обычный ChatGPT «чтобы быстрее разобраться». Политика должна чётко регламентировать использование публичных AI-сервисов.

Блок 6: Vendor due diligence — проверка поставщика

Вендор AI-решения — это не просто поставщик софта. Это партнёр, которому вы доверяете обработку данных. Соответственно, и проверка должна быть серьёзной.

Что нужно запросить и проверить:

Отдельное внимание — пункту 6.7 про субподрядчиков. Вендор может быть казахстанской компанией с сертификатами и NDA, но использовать API OpenAI, сервера которого находятся в США. В итоге ваши данные всё равно уходят за рубеж.

Это не обязательно плохо, но должно быть зафиксировано и оценено с точки зрения рисков. Убедитесь, что вендор прозрачен в этом вопросе и может предоставить информацию обо всей цепочке обработки данных.

Шаблон отчёта для CISO: как оформить результаты аудита

После проверки нужно оформить результаты в структурированный отчёт. Вот шаблон, который можно использовать:

Важно: отчёт должен давать чёткую рекомендацию. Не «есть риски, решайте сами», а «рекомендуем одобрить при условии выполнения пунктов X, Y, Z в течение 30 дней». Руководство ценит определённость.

Ещё один совет: используйте визуализацию. Traffic light система (зелёный/жёлтый/красный) для каждого блока помогает быстро понять общую картину. Особенно если отчёт будет читать не только CISO, но и бизнес-заказчики.

Типичные ошибки при аудите AI-решений

За годы практики я видел много аудитов — и хороших, и не очень. Вот ошибки, которые совершаются чаще всего:

Про последний пункт — отдельно. Идеальный момент для security review — когда решение ещё в стадии PoC или пилота. Ещё лучше — вовлечь ИБ на этапе выбора вендора. Это не замедляет проект, а ускоряет: меньше переделок потом.

О том, как проводить threat modeling для LLM-ботов и на какие угрозы обращать внимание, читайте в статье Threat Modeling для LLM-бота: 12 угроз.

Практические рекомендации для службы ИБ

Несколько советов, проверенных на практике:

• Создайте шаблон: Один раз разработайте чек-лист и опросник для вендоров. Адаптируйте под каждый проект, но не начинайте с нуля.
• Включите ИБ в процесс закупок: Пусть security review будет обязательным этапом procurement process. Не опциональным, а блокирующим.
• Обучите команду: AI-решения — новая область. Инвестируйте в обучение: курсы, конференции, практика. OWASP LLM Top 10 — хорошая отправная точка.
• Сотрудничайте с бизнесом: Не будьте «отделом нет». Помогайте найти безопасные способы достичь бизнес-целей. Предлагайте альтернативы.
• Планируйте регулярные пересмотры: Раз в квартал или после значительных изменений — повторный review. AI-ландшафт меняется быстро.

Заключение: безопасность — это enabler, не blocker

Вернёмся к истории из начала статьи. После того инцидента логистическая компания не отказалась от AI-бота. Они провели полноценный аудит, исправили проблемы с доступом, настроили маскирование данных и внедрили мониторинг. Бот продолжает работать и экономить компании деньги — но теперь безопасно.

Суть в том, что аудит AI-решений — не способ всё запретить. Это способ внедрять технологии правильно, с пониманием рисков и мерами по их снижению.

AI-решения — уже реальность для бизнеса в Казахстане. Те компании, которые научатся использовать их безопасно, получат конкурентное преимущество. Те, которые проигнорируют риски — будут разбираться с последствиями. Выбор за вами.

Чек-лист из этой статьи — хорошая отправная точка. Адаптируйте его под специфику вашей компании, используйте, дополняйте. И помните: лучший аудит — тот, который сделан вовремя.

Часто задаваемые вопросы

Читайте также