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

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

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

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

Технически это два дня работы, юридически же это потенциальный штраф до 4% от годового мирового оборота по GDPR (Article 83). И угроза вполне реальная: надзорные органы (Информационный уполномоченный IP-RS в Словении, 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).

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, скормить ему всю CRM на PostgreSQL, и готово.

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

• 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.
• Внутренняя KB SINTARIS: Taris § 9 Security & data boundary, Architecture patterns § 9 Local-first default.

Команда SINTARIS проводит AI-аудиты, AI-пилоты и внедрения платформы Taris для малого и среднего бизнеса в EU. Вводный звонок на 30 минут бесплатный.