AI и персональные данные: что можно и что нельзя без штрафов

AI и персональные данные: что можно и что нельзя без штрафов

TL;DR. Если ваш AI-проект касается данных людей в EU — это GDPR. Если данных людей в России — это 152-ФЗ. Если и тех, и других — оба закона одновременно. В большинстве случаев это решается не «выбрать правильное облако», а архитектурой пайплайна: где документ, где векторы, где промпт, куда уходит запрос к LLM, кто видит логи. Ниже — практический разбор того, какие шаблоны проходят аудит, а какие нет, на основе того, как SINTARIS внедряет RAG-системы в EU и СНГ.

1. Конфликт: «давайте подключим ChatGPT к нашей CRM»

Запрос приходит почти в каждом первом проекте. Внутри компании уже сидит CRM с фамилиями клиентов, телефонами, иногда — медицинскими или финансовыми деталями. Кто-то увидел демо ChatGPT, и появляется задача «сделайте, чтобы менеджер мог спросить — а оно ответило».

Технически это два дня работы. Юридически — это потенциальный штраф до 4% от мирового оборота по GDPR (Article 83) и/или до 18 миллионов рублей по обновлённому 152-ФЗ (статья 13.11 КоАП РФ в редакции 2024 года). И речь не о теоретической угрозе — Roskomnadzor и европейские DPA (BfDI в Германии, Garante в Италии) уже выписывают такие штрафы за «отправили персональные данные стороннему вендору без правового основания».

Цель этой статьи — показать, что граница не там, где её обычно рисуют («OpenAI = плохо, локальная LLM = хорошо»). Граница — в том, как именно данные движутся через систему, какие из них становятся вашим обработчиком, какие — субпроцессором, и где у вас должно быть зафиксированное правовое основание.

2. Кому это касается

• Малому и среднему бизнесу, где есть клиентские данные: клиники, школы, юристы, агентства, B2B-продажи, любые e-commerce.
• Стартапам, которые «прикрутили GPT» к продукту, а юридический ревью отложили на потом.
• Руководителям ИТ-отделов, которым «бизнес» приносит идею AI-ассистента и спрашивает: «когда внедрим?».
• Соло-консультантам и экспертам, монетизирующим свою экспертизу через AI-бота с подпиской.

Если в вашем сценарии нет ни одного имени клиента, ни одного email-а, ни одного номера счёта или диагноза — эта статья вам не нужна. Если есть хоть что-то из перечисленного — нужна.

3. Распространённый неправильный подход

Шаблон, который мы видели десятки раз:

1. Берём CRM-экспорт в CSV.
2. Закидываем в RAG-индекс через стандартный n8n-workflow.
3. Подключаем сверху вызов gpt-4o через OpenAI API.
4. Менеджер пишет в Telegram: «Что мы обсуждали с Ивановым в прошлом месяце?» — бот отвечает.
5. Всё работает, демо удалось, заказчик доволен.

Почему это неприемлемо с точки зрения регуляторов:

• Передача персональных данных третьему лицу без правового основания. OpenAI становится субпроцессором, но без DPA (Data Processing Agreement) и без анализа: где физически находятся серверы, как долго хранятся запросы (по умолчанию — да, хранятся), кто к ним имеет доступ.
• Цель обработки не определена и не зафиксирована. GDPR требует, чтобы для каждой категории данных была явная и зафиксированная цель. «Удобнее менеджеру» — не цель.
• Принцип минимизации нарушен. В индекс ушло гораздо больше, чем нужно для ответа на конкретный класс вопросов.
• DPIA (Data Protection Impact Assessment) не проводилась, хотя для «систематической автоматической обработки больших объёмов персональных данных» — обязательна (GDPR Article 35).

В России: статья 9 152-ФЗ требует согласия в письменной форме для обработки специальных категорий (здоровье, политические взгляды и т.п.). Никакого согласия на «передачу истории общения с менеджером в OpenAI» клиент не давал.

4. Инженерный подход: где провести границу

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

Базовая модель, которую мы применяем:

flowchart LR
  subgraph Внутренний периметр заказчика
    CRM[(CRM с PII)]
    KB[(База знаний RAG)]
    LLM_LOCAL[Локальная LLM<br/>Ollama / llama.cpp]
    APP[Приложение / Бот]
  end
  subgraph Внешние сервисы
    LLM_CLOUD[Cloud LLM<br/>OpenAI / Anthropic]
  end

  CRM -- санитизация --> KB
  APP -- вопрос пользователя --> KB
  KB -- топ-K чанков<br/>БЕЗ имён --> LLM_LOCAL
  KB -. опционально, без PII .-> LLM_CLOUD

Два правила:

1. PII не пересекает периметр. Документы в RAG-индексе — это либо обезличенные тексты, либо тексты с метками (<CLIENT_ID:42> вместо «Иванов Иван»). Пересборка имени происходит на стороне приложения после ответа LLM, через look-up в защищённой таблице.
2. Облачная LLM — опциональна и аудируема. Если она вообще нужна, к ней уходит только обезличенный фрагмент, и каждый такой вызов логируется. Если регулятор приходит — у вас есть журнал.

Шаги, чтобы это построить:

• Классификация документов перед ингестом: помечаем поля как PII / sensitive / public. Делается один раз скриптом на регулярных выражениях + ручной review.
• Маскирование имён, email-ов, телефонов, дат рождения, номеров полисов — на этапе чанкирования. Реальные значения остаются в crm.contacts(id, value).
• Локальная LLM по умолчанию. Для большинства SMB-сценариев llama3.1:8b-instruct через Ollama выдаёт качество, которого достаточно. Для нагрузок повыше — qwen2.5:14b.
• Диспетчер моделей с правилами. Полит if has_pii then refuse_cloud_provider. Это не «надёжность через дисциплину», это конфиг файла, проверяемый автотестами.

5. Диаграмма + таблица: что куда уходит

Сводная таблица того, какие данные допустимо отправлять каким моделям при разных правовых основаниях:

Это упрощение. Реальная матрица для конкретного проекта строится в рамках DPIA, но эта таблица — хорошая стартовая точка.

6. Sintaris mini-case

Продукты Maria — clinic appointment notifier и Clinic assistant — пример этого подхода на практике. Задача: пациент должен через Telegram уточнить часы работы, перенести запись, получить копию рецепта. Стандартный соблазн — взять gpt-4o-mini, скормить ему всю PostgreSQL CRM, готово.

Техническая реализация:

• LLM в системе используется только для классификации интента (confirm / reschedule / cancel / question / emergency).
• В промпт уходит: тип сообщения (текст / голос → транскрипт) + первое имя пациента (а не полное ФИО) + город. Никаких диагнозов, никаких рецептов, никаких номеров полисов.
• Само бронирование — детерминированный код, который читает свободные слоты из календаря и пишет в CRM напрямую.
• Передача рецепта — отдельный воркфлоу: пациент авторизуется через одноразовый код, документ отдаётся через защищённый канал, событие пишется в аудит-лог.

Результат: стоимость LLM — около 2 евро в месяц (классификация — это короткие запросы), число звонков в регистратуру упало на 40–50%, и юридическая часть — на одной странице, потому что персональные данные физически не выходят за периметр.

Подробности архитектуры — в KB-главе Clinic assistant § 9 «Security & data boundary».

7. Чек-лист (15 пунктов) перед запуском AI-пилота с персональными данными

1. Определена и записана цель обработки для каждой категории данных.
2. Выбрано и задокументировано правовое основание (согласие / договор / законный интерес / иное).
3. Проведена DPIA, если объём систематический.
4. Заключён DPA с каждым субпроцессором (включая LLM-провайдеров, если используются).
5. Подписаны SCC / standard contractual clauses при трансфере вне EEA.
6. Реестр обработки (Article 30 GDPR) обновлён.
7. PII не попадает в эмбеддинги напрямую — маскирование на стадии ингеста.
8. Документы в индексе классифицированы по чувствительности.
9. Диспетчер моделей имеет правило «sensitive → local-only», проверяемое автотестом.
10. Логи запросов к LLM не содержат PII (или хранятся отдельно и недолго).
11. Audit log действий пользователя и системы — есть и хранится не меньше требуемого срока.
12. Механизм DSAR (право доступа) — отрабатывается на тестовом запросе раз в квартал.
13. Механизм удаления (right to erasure) — каскадно удаляет из индекса, эмбеддингов, истории.
14. Согласие пользователя — фиксируется с timestamp + версия policy + IP.
15. Privacy Policy опубликована, актуальна, переведена на все языки сайта.

8. Риски

• Регуляторный. Штраф + предписание остановить обработку. Реалистичный диапазон для EU SMB: 5–50 тыс. евро на первом инциденте, кратно выше при повторе.
• Репутационный. «Слив данных через AI» — заголовок, который не хочется на себе видеть.
• Технический. Vendor lock-in: миграция между LLM-провайдерами без архитектуры диспетчера — болезненная.
• Командный. Без выписанной политики разработчики «срежут угол» — отправят PII в облако «для тестов» и забудут.

9. Что делать дальше

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

Если хочется чужими руками — у SINTARIS есть продуктизированный AI Audit, внутри которого DPIA-light + архитектурный план приватности входит по умолчанию. Это не реклама ради рекламы — это просто пакет, который мы делаем достаточно часто, чтобы он стоил фиксированных денег.

10. Источники

• Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv:2005.11401.
• Cormack, G., Clarke, C., Buettcher, S. (2009). Reciprocal Rank Fusion outperforms Condorcet and individual rank learning methods. SIGIR '09.
• Регламент (ЕС) 2016/679 (GDPR), статьи 5, 6, 30, 35, 83.
• Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» (в редакции 2024 г.).
• Roskomnadzor — методические рекомендации по обработке ПДн (открытые материалы 2023–2025).
• BfDI (Germany), Garante (Italy) — обзоры решений по AI-инцидентам, 2023–2025.
• Внутренняя KB SINTARIS: Taris § 9 Security & data boundary, Architecture patterns § 9 Local-first default.

Sintaris делает аудиты процессов и AI-пилоты для бизнеса в EU и СНГ. Скидка −25% на пакеты «Audit» и «Pilot» для словенских компаний — с 1 по 30 июня 2026 года.