Аудит 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.

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

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

На входе блокируйте явные попытки jailbreak («забудь все инструкции»), запросы на генерацию вредоносного контента, попытки извлечь system prompt. В system prompt задайте чёткие границы — о чём бот говорит и не говорит, как реагирует на провокации, что делать при неопределённости. На выходе фильтруйте персональные данные (включая случайно сгенерированные), упоминание конкурентов, политические высказывания, юридические советы без дисклеймера.

Кстати, фильтры должны работать на уровне вашего 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-решения — уже реальность для бизнеса в Казахстане. Те компании, которые научатся использовать их безопасно, получат конкурентное преимущество. Те, которые проигнорируют риски — будут разбираться с последствиями. Выбор за вами.

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

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

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