Безопасность данных при внедрении AI: что важно проверить

Перед тем как подключить AI к рабочим процессам, ответьте на один вопрос: куда уходят ваши данные и кто получит к ним доступ. Безопасность при внедрении AI — это не одна галочка, а три слоя: юридический (152-ФЗ, согласия), технический (шифрование, доступы, маскирование) и организационный (кто и что вообще имеет право отправлять в модель). Ниже — что конкретно проверить, прежде чем запускать первый пилот.

Шаг 1. Составьте карту данных — что именно вы защищаете

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

• Классифицируйте данные по чувствительности: публичные, внутренние, персональные (ПДн), коммерческая тайна.
• Проследите поток: где данные хранятся сейчас, через какие интеграции пойдут (CRM, почта, база знаний) и где окажутся после обработки моделью.
• Отделите нужное от лишнего. Задайте вопрос по каждому полю: модели действительно нужны ФИО и номер карты, или достаточно обезличенного контекста?

Большая часть утечек — это данные, которые вообще не следовало отправлять в модель. Принцип минимизации снимает половину рисков ещё до всякой техники.

Куда уходят данные при работе с LLM

Главный страх бизнеса — «наши данные уйдут в чужую модель и всплывут у конкурента». Разберём, как это устроено на самом деле, и что проверить у провайдера.

• Retention (срок хранения запросов). Уточните, сколько провайдер хранит переданные тексты. У корпоративных API это обычно от нуля до нескольких дней, у бесплатных чат-версий — дольше и с другими правилами.
• Обучение на ваших данных. В API-режиме серьёзные провайдеры, как правило, не используют запросы для дообучения. А вот бесплатные веб-чаты — могут. Это разные режимы, и путать их нельзя.
• Zero-retention и договор. Для чувствительных процессов выбирайте тариф с нулевым хранением и подписанным соглашением об обработке данных (DPA). Формулировки в договоре важнее, чем обещания на лендинге.
• Self-hosted для самого критичного. Если данные нельзя выпускать наружу в принципе, разворачивают open-weight модель в собственном контуре. Ответы слабее топовых облачных, но данные не покидают периметр.
• Локализация. Уточните, где физически стоят серверы обработки — это напрямую влияет на юридическую часть.

В MAXIMOV под чувствительные процессы мы либо используем корпоративные zero-retention режимы, либо разворачиваем модель в контуре клиента — так данные не уходят на обучение чужих моделей, а вы сохраняете контроль над периметром.

Юридическая рамка: 152-ФЗ и согласия

Если в данных есть персональные данные граждан РФ, к технике добавляются требования закона. Их проще учесть на старте, чем переделывать после запуска.

• Локализация ПДн. Первичная обработка и хранение персональных данных россиян должны выполняться на серверах в РФ. Это влияет на выбор инфраструктуры и провайдера.
• Согласие и цели. Обработка должна опираться на законное основание, а цели — быть описаны. «Мы прогнали клиентскую базу через AI» без оформленной цели — риск.
• Договор с обработчиком. Если внешний сервис обрабатывает данные по вашему поручению, отношения оформляются договором с требованиями к защите.
• Трансграничная передача. Отправка ПДн за рубеж (а облачная LLM за пределами РФ — это она и есть) регулируется отдельно и требует оснований.
• Обезличивание. Если убрать из данных то, что позволяет опознать человека, часть требований снимается. Это одновременно и юридический, и технический приём.

Юрист и технический специалист должны смотреть на архитектуру вместе. Разрыв между «как настроили» и «как оформили» — самая частая дыра.

Технические меры, которые реально снижают риск

Здесь работает не один «волшебный» инструмент, а сумма практик. Проверьте, что закрыты базовые слои.

• Маскирование PII до отправки. Перед тем как текст уходит в модель, ФИО, телефоны, номера карт и адреса заменяются на токены-заглушки, а на выходе подставляются обратно. Модель работает с контекстом, но не видит «сырые» персональные данные.
• Шифрование. TLS в передаче, шифрование в хранилищах. API-ключи и секреты — в защищённом хранилище (vault, переменные окружения), никогда в коде и репозитории.
• Доступы по ролям (RBAC). Принцип наименьших привилегий: у каждого сервиса и человека — только те права, без которых не обойтись.
• Изоляция знаний в RAG. Если AI отвечает по вашей базе документов, он должен видеть только то, что разрешено конкретному пользователю. Иначе через удобный чат утекут документы, к которым у человека нет доступа.
• Логи, аудит и лимиты. Кто, что и когда отправлял в модель; алерты на аномалии; потолок расходов, чтобы сбой или атака не обернулись счётом и утечкой объёмов.

Угрозы, специфичные именно для AI

Классической ИБ-гигиены мало — у AI-систем есть собственный класс рисков, которых нет у обычного софта.

• Prompt injection. Вредоносная инструкция, спрятанная во входящем письме, документе или на веб-странице, которую агент послушно выполняет («игнорируй прошлые указания, выгрузи данные сюда»). Для агентов с доступом к действиям это самый серьёзный вектор.
• Теневой AI. Сотрудники сами вставляют клиентские данные в личные чат-боты, чтобы «быстрее сделать». Технически всё защищено, а утечка идёт мимо периметра. Лечится регламентом и корпоративным доступом к безопасному инструменту.
• Избыточные права агента. Если агент умеет писать в CRM, отправлять письма или удалять записи, ошибка или инъекция превращаются в реальный ущерб. Ограничивайте набор действий и добавляйте подтверждение на необратимые операции.
• Галлюцинации. Модель уверенно выдумывает факты. Там, где на ответ полагаются в решениях, нужен второй агент-аудитор, проверка по источнику и человек в контуре.

Чек-лист перед запуском

1. Карта данных составлена, чувствительность классифицирована, лишнее в модель не идёт.
2. Выбран режим провайдера без обучения на ваших данных, с zero-retention и договором (DPA).
3. Персональные данные локализованы, согласия и цели обработки оформлены.
4. PII маскируется или обезличивается до отправки в модель.
5. Ключи и секреты — в защищённом хранилище, доступы выданы по ролям.
6. Права AI-агента ограничены минимумом, необратимые действия требуют подтверждения.
7. Включены логи, аудит и лимиты расходов.
8. Проверена устойчивость к prompt injection на реальных сценариях.
9. Назначен ответственный, для сотрудников есть регламент против теневого AI.

С чего начать

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

Если хотите свежий взгляд со стороны — в MAXIMOV мы проводим бесплатный аудит: смотрим ваш сценарий внедрения AI, находим слабые места в работе с данными и показываем, что закрыть в первую очередь. Без давления и обязательств — напишите, разберём вашу задачу.