Клиенты рассказывают чат-ботам гораздо больше, чем у них спрашивают. Вставляют номера заказов и адреса доставки, жалуются на курьера, называют лекарства, которые принимают, или причину, по которой не прошёл платёж. Как только чат-бот или ИИ-ассистент запускается, он становится одной из самых нагруженных систем с персональными данными — и по GDPR отвечаете за неё вы, а не поставщик модели.
Звучит тяжелее, чем есть на самом деле. GDPR-совместимый чат-бот — это несколько решений, принятых до запуска: кто что обрабатывает, на каком основании, где лежат данные, сколько хранятся логи и что делать, если что-то пошло не так. Если ответить на эти вопросы заранее, та же документация закроет вопросы DPO, отдела закупок крупных клиентов и требований прозрачности AI Act.
И важная деталь для русскоязычного бизнеса за пределами ЕС: GDPR применяется не по месту регистрации компании, а по тому, где находятся люди. Если ваш бот отвечает клиентам в Германии, на Кипре или в Латвии, GDPR распространяется на вас (ст. 3(2)).
Почему чат-бот — это проект по GDPR
Три свойства отличают разговорный ИИ от контактной формы:
- Свободный текст. Вы не контролируете, что напишет пользователь. Особые категории данных (здоровье, религия, происхождение — ст. 9 GDPR) появляются без запроса.
- Длинная цепочка обработчиков. Типичная схема: виджет чата, слой оркестрации, LLM API, векторная база, CRM или хелпдеск, логирование и аналитика. Каждое звено может хранить данные.
- Непрозрачное повторное использование. Некоторые ИИ-поставщики хранят промпты для выявления злоупотреблений или используют их для обучения на потребительских тарифах. Если это не проверить, данные клиентов окажутся там, о чём не сказано ни в одной политике конфиденциальности.
Европейские компании это понимают. Среди немецких фирм, уже использующих ИИ, 66% называют барьером требования защиты данных, а 45% — риск утечек (Bitkom). Бот, который может доказать, как обращается с данными, снимает эти возражения быстрее, чем чуть более умный бот, который этого сделать не может.
Шаг 1. Нарисуйте поток данных
До любого юридического анализа проследите путь одного сообщения:
- Виджет или канал — сайт, WhatsApp, Telegram, почта. С 15 января 2026 года WhatsApp Business API запрещает универсальных ИИ-ассистентов; боты компаний для собственных клиентов по-прежнему разрешены (TechCrunch).
- Оркестрация — платформа вроде Botpress или Intercom, n8n на собственном сервере или свой код.
- Модель — LLM API, регион обработки и то, хранятся ли промпты.
- Поиск (retrieval) — векторная база и проиндексированные в ней документы.
- Действия — CRM, система заказов, календарь записи.
- Логи и аналитика — транскрипты, трейсы, трекинг ошибок, дашборды.
Для каждого блока отметьте, какие персональные данные он получает, где размещён и сколько их хранит. Эта схема станет основой реестра операций обработки (ст. 30) и DPIA.
Шаг 2. Правовое основание под каждую цель
«Одного основания для чат-бота» не существует. Каждой цели нужно своё.
| Цель | Типичное основание (ст. 6 GDPR) | На что обратить внимание |
|---|---|---|
| Ответы на вопросы, оформление заказа или возврата | Договор или преддоговорные действия, ст. 6(1)(b) | Только данные, нужные для запроса |
| Статус заказа, запись, изменения в аккаунте | Договор, ст. 6(1)(b) | Сначала идентификация, потом информация |
| Анализ транскриптов для улучшения ответов | Законный интерес, ст. 6(1)(f) | Задокументировать баланс интересов; псевдонимизировать |
| Маркетинговые касания, подписка на рассылку в чате | Согласие, ст. 6(1)(a) | Отдельно, без предустановленных галочек, с доказательством |
| Вопросы о здоровье в боте клиники | Дополнительно условие ст. 9(2), обычно явное согласие | Возможно, вывести медицинские темы из сценария |
| Обучение модели поставщика на ваших диалогах | Избегать | Отключить в настройках и в договоре |
Самый чистый вариант — бот с ограниченной целью: он отвечает, записывает и передаёт человеку, и прямо говорит об этом в начале диалога.
Шаг 3. Договор обработки данных и цепочка субобработчиков
Каждый поставщик, обрабатывающий диалоги от вашего имени, — обработчик, и ст. 28 требует письменного договора (DPA). Хороший DPA с ИИ-поставщиком закрепляет:
- обработку только по вашим задокументированным инструкциям — с исключением обучения на ваших данных;
- конфиденциальность персонала и надлежащие меры безопасности (ст. 32);
- список субобработчиков и ваше право возразить против новых;
- помощь с запросами субъектов данных и с DPIA;
- удаление или возврат данных по окончании договора;
- уведомление об инцидентах без неоправданной задержки, чтобы вы уложились в собственные 72 часа;
- право аудита или признанные сертификаты.
Задайте каждому ИИ-поставщику пять одинаковых вопросов. Обучаетесь ли вы на наших данных? Сколько и зачем храните промпты и ответы? В каких регионах обрабатываются данные? Кто ваши субобработчики? Как быстро вы сообщите нам об инциденте? Ответы — в досье поставщика, и нередко именно они определяют выбор.
Шаг 4. Где хранятся данные и передача за пределы ЕЭЗ
Передача персональных данных за пределы Европейской экономической зоны требует основания по главе V GDPR. Для американских поставщиков это обычно сертификация по EU-US Data Privacy Framework или стандартные договорные условия с оценкой передачи. Американские платформы чатов и телефонии в Европе обычно используются именно так; это работает, но добавляет бумажной работы и политический риск, который многие покупатели закладывают в решение. В опросах, на которые ссылается Deloitte, 77% компаний учитывают страну происхождения ИИ-поставщика, а 66% беспокоит зависимость от иностранного ИИ (DEV Community).
| Вариант | Работа по передаче данных | Качество и стоимость | Кому подходит |
|---|---|---|---|
| API американской модели через DPF или SCC | Оценка передачи, проверка поставщика | Топовые модели, оплата за токены | Поддержка без чувствительных данных |
| Крупный поставщик с регионом обработки в ЕС | Меньше; закрепить регион в договоре | Топовые модели, иногда дороже | Большинство ботов поддержки МСБ |
| Open-weight-модель (например, Mistral) на хостинге в ЕС | Передачи за пределы ЕЭЗ нет | Чуть ниже качество, фиксированные расходы на инфраструктуру | Чувствительные данные, регулируемые отрасли |
| Модель on-premises | Нет | Максимум усилий | Строгие отраслевые правила, большие объёмы |
Слой оркестрации тоже важен. Community-версию n8n можно бесплатно развернуть на своём сервере в ЕС (n8n): данные процессов и учётные данные остаются в вашей инфраструктуре. Плюсы и минусы собственных моделей разобраны в статье частные и on-prem LLM для европейских компаний.
Шаг 5. Логи: храните нужное, удаляйте остальное
Логи нужны: чтобы разбирать неверные ответы, решать споры («ваш бот обещал мне возврат»), выявлять злоупотребления, а для систем высокого риска по AI Act — хранить автоматические журналы не менее шести месяцев. Но принцип ограничения хранения (ст. 5(1)(e)) исключает подход «хранить всё и всегда».
График хранения, который мы часто берём за отправную точку, — его нужно адаптировать под ваши цели и задокументировать:
| Данные | Рекомендуемый срок | Комментарий |
|---|---|---|
| Сырые транскрипты с персональными данными | 30–90 дней | Достаточно для контроля качества и претензий |
| Диалоги, переданные человеку | Как связанный тикет в CRM | По действующим правилам для клиентских карточек |
| Псевдонимизированные трейсы (промпт, модель, задержка, стоимость) | 6–12 месяцев | Для evals, контроля затрат и отладки |
| Агрегированная аналитика | Без ограничения | Персональных данных уже нет |
| Журналы безопасности и доступа | По политике безопасности | Защищать как продуктивные данные |
Две техники сильно уменьшают проблему. Маскирование до модели: почта, телефоны, IBAN и номера заказов заменяются до того, как промпт покинет вашу систему, и подставляются обратно только там, где они нужны для действия. Собственная наблюдаемость: инструменты трейсинга вроде Langfuse или Helicone, которые стали стандартом у сильных ИИ-команд (HouseofMVPs), можно запускать в своём окружении, чтобы трейсы не оседали у ещё одного поставщика.
Шаг 6. Прозрачность и права пользователей
Политика конфиденциальности должна описывать чат-бота (ст. 13 и 14): цели, основания, получателей, включая ИИ-поставщиков, передачу данных, сроки хранения и права. В начале чата достаточно короткой строки со ссылкой. Со 2 августа 2026 года AI Act отдельно требует сообщать пользователям, что они общаются с ИИ-системой, — одно предложение может решить обе задачи. Сторону AI Act мы разбираем в руководстве по EU AI Act для МСБ.
Запросы субъектов данных закладывайте с первого дня:
- Доступ (ст. 15) и удаление (ст. 17) — найдёте ли вы все диалоги одного человека в виджете, логах и CRM? Свяжите их с ID клиента.
- Возражение (ст. 21) — учитывайте его для обработки на основе законного интереса, например анализа качества.
- Автоматизированные решения (ст. 22) — если бот принимает решения с юридическими или сопоставимо значимыми последствиями, например отказывает в возврате или кредите, нужен пересмотр человеком и объяснение логики.
- Срок — один месяц на ответ (ст. 12(3)).
Шаг 7. Безопасность — часть соответствия
Ст. 32 требует уровня безопасности, соответствующего риску, а экосистема ИИ даёт достаточно предостерегающих примеров. Проверка 5 600 публично доступных приложений, собранных «вайбкодингом», нашла более 2 000 серьёзных уязвимостей, 400 открытых секретов и 175 утечек персональных данных (SoftwareSeni). Одно ИИ-приложение для чатов раскрыло 406 млн записей из-за правила Firebase, разрешавшего всё (Cloud Security Alliance).
Есть ещё prompt injection — инструкции, спрятанные в сообщениях или документах, которые заставляют модель выдать данные или злоупотребить инструментами. Даже OpenAI признаёт, что эту проблему, возможно, никогда не удастся решить полностью (Brandon Ta). Практический ответ — архитектура: давать боту минимально необходимые инструменты, проверять права доступа вне модели, не разрешать свободных запросов к базам и тестировать атаки до запуска. Подробнее — в статье prompt injection и безопасность агентов.
Если персональные данные всё же утекли, по ст. 33 у вас 72 часа на уведомление надзорного органа. Порядок действий нужно утвердить до запуска, а не после.
Когда нужна DPIA
Ст. 35 требует оценки воздействия на защиту данных, если обработка, вероятно, несёт высокий риск. Типичные триггеры для чат-ботов: новые технологии в большом масштабе, особые категории данных, систематический мониторинг, запись звонков и голосовая биометрия. На практике DPIA для бота поддержки — компактный документ, а не том: схема потока данных, правовые основания, риски (неверные ответы, утечки, инъекции, передача данных) и меры против каждого. Заодно это ровно тот документ, который крупные клиенты запрашивают при проверке подрядчика.
Пример: бот поддержки интернет-магазина
Интернет-магазин мебели с офисом в Риге продаёт в Латвию, Германию и Нидерланды и хочет бота для вопросов о товарах, отслеживания заказов и возвратов. Вот как ложатся решения:
- Рамки. На вопросы о товарах бот отвечает только по публичному каталогу — без персональных данных. Для статуса заказа и возврата клиент сначала подтверждает личность номером заказа и почтовым индексом.
- Основание. Договор (ст. 6(1)(b)) для заказов и возвратов; законный интерес для выборочного анализа транскриптов, оформленный коротким тестом баланса интересов.
- Поставщики. Оркестрация на собственном сервере в ЕС, LLM через регион обработки в ЕС, система магазина и хелпдеск с действующими DPA. Обучение на данных магазина исключено договором.
- Маскирование. Имена, адреса и телефоны заменяются до промпта; поиск заказа выполняет код, а не модель.
- Логи. Сырые транскрипты — 60 дней, псевдонимизированные трейсы — год, переданные человеку диалоги — вместе с тикетом.
- Прозрачность. Первое сообщение на языке версии магазина — латышском, немецком или нидерландском: «Я ИИ-ассистент магазина. Как мы обращаемся с вашими данными, описано в политике конфиденциальности. Напишите „оператор“, чтобы связаться с человеком», — со ссылкой на политику.
Ничего экзотического. Это проектная работа, сделанная один раз в начале, вместо того чтобы переделывать всё в спешке, когда придёт первый крупный клиент или первый запрос субъекта данных.
Типичные ошибки
- Потребительские аккаунты ИИ-сервисов для бизнес-бота. Потребительские условия часто разрешают обучение на вводимых данных и не предусматривают DPA.
- Нет обзора субобработчиков. В политике указан один поставщик, а на деле данные проходят через пятерых.
- «Храним все логи — мало ли что». Бессрочное хранение нарушает ограничение хранения и превращает любую утечку в крупную.
- Модель решает, кому что можно видеть. Права доступа — в коде, а не в промпте.
- Данные о здоровье как редкий случай. В клиниках, страховании и HR это основной случай: либо проектируйте под него, либо выводите из сценария.
- Нет пути к человеку. Без передачи живому сотруднику вас догонят ст. 22 и недовольные клиенты.
Вывод
GDPR-совместимый чат-бот — не особый продукт, а обычный, сделанный дисциплинированно: схема потоков данных, основание под каждую цель, DPA с каждым обработчиком, осознанный выбор места хранения, график хранения, маскирование до модели и план на случай утечки. Если принять эти решения в начале, они займут дни, а не месяцы, и сохранят вам свободу: данные, которые вы контролируете, можно и забрать с собой. Об этом — статья владейте своим ИИ: как избежать vendor lock-in.
Lotus Libre создаёт ИИ-агентов для поддержки и продаж и системы вокруг них — с хостингом в ЕС, маскированием, журналированием и документацией, готовой к DPA. Хотите, чтобы мы посмотрели на ваш действующий или планируемый бот? Запишитесь на бесплатный 15-минутный аудит.
Статья носит информационный характер и не является юридической консультацией. Для решений в вашей конкретной ситуации обратитесь к квалифицированному юристу или вашему специалисту по защите данных.