Серия:** Гайд для вайбкодеров: как запускать AI-продукты в РФ и не сломаться на персональных данных
Ключевые слова: OpenAI персональные данные, Claude персональные данные, Gemini персональные данные, зарубежные LLM 152-ФЗ, токенизация персональных данных, Privacy Proxy, LLM Gateway, AI-продукт персональные данные, обезличивание данных для AI.
Почему это вообще проблема
Многие AI-продукты сегодня строятся на зарубежных LLM: OpenAI, Claude, Gemini и других моделях.
Это понятно. Они сильные. Они хорошо пишут. Они помогают быстро собрать MVP. Их легко подключить через API.
Но есть важный момент: если в запрос к модели уходит имя, телефон, email, договор, паспорт, переписка клиента, данные сотрудника или файл с персональными данными, это уже не просто «технический запрос к AI».
Это может быть передача персональных данных во внешний сервис.
А если сервис находится за пределами России, появляется ещё один слой риска — трансграничная передача персональных данных.
Поэтому главный вопрос для вайбкодера звучит не так:
Можно ли использовать зарубежные LLM?
А вот так:
Как использовать зарубежные LLM так, чтобы не отправлять туда персональные данные?
Главный принцип
Запомни простую формулу:
LLM должна знать задачу, а не личность пользователя.
Модели чаще всего не нужны реальные имена, телефоны, email, адреса, номера договоров и паспортные данные.
Ей нужен смысл задачи.
Плохо:
Составь письмо Ивану Петрову. Его телефон +7 918..., email ivan@..., договор №123, апартамент №305.
Лучше:
Составь деловое письмо клиенту по вопросу договора. Тон: спокойный, уверенный. Нужно объяснить порядок возврата оплаты и предложить связаться с менеджером.
Во втором варианте модель понимает, что надо сделать, но не получает персональные данные.
Какие данные нельзя бездумно отправлять в LLM
Перед отправкой запроса в модель нужно проверять, нет ли внутри:
- ФИО;
- телефона;
- email;
- адреса;
- паспортных данных;
- ИНН;
- СНИЛС;
- банковских реквизитов;
- номера карты;
- Telegram ID;
- username;
- IP-адреса;
- геолокации;
- номера договора;
- номера заказа;
- номера бронирования;
- медицинской информации;
- данных детей;
- фото;
- голосовых сообщений;
- документов;
- переписки с клиентом;
- данных сотрудников;
- данных третьих лиц.
Особенно опасны не только очевидные данные вроде телефона или паспорта, но и уникальные детали.
Например:
«Собственник апартамента №305 в комплексе X, который был на встрече 5 июня, написал претензию...»
Даже без ФИО человека можно определить по совокупности признаков.
Ошибка многих вайбкодеров
Типичная архитектура MVP выглядит так:
Пользователь → форма / чат / бот → OpenAI / Claude / Gemini → ответ пользователю
Это быстро, но рискованно.
Проблема в том, что пользователь может сам вставить в сообщение всё что угодно:
- договор;
- клиентскую базу;
- таблицу с телефонами;
- паспортные данные;
- коммерческую переписку;
- медицинскую информацию;
- данные ребёнка;
- чужие персональные данные.
Поэтому между пользователем и LLM нужен дополнительный слой.
Правильная архитектура: Privacy Proxy
Более безопасная схема выглядит так:
Пользователь
↓
Backend в РФ
↓
Privacy Proxy / LLM Gateway
↓
Очистка, маскирование или токенизация данных
↓
Зарубежная LLM
↓
Ответ модели
↓
Обратная подстановка данных внутри РФ
↓
Пользователь
Privacy Proxy — это не отдельный модный сервис, а логический слой в твоём продукте.
Его задача — не дать персональным данным уйти во внешнюю модель.
Что должен делать Privacy Proxy
Минимальный набор функций:
| Функция | Что делает |
|---|---|
| PII detection | ищет персональные данные в тексте |
| Masking | скрывает данные: [PHONE], [EMAIL], [ADDRESS] |
| Tokenization | заменяет данные на токены: [PERSON_1], [PHONE_1] |
| Token Vault | хранит соответствие токенов реальным данным |
| Prompt Minimization | удаляет из запроса всё лишнее |
| Policy Filter | блокирует опасные запросы |
| Response Restore | подставляет данные обратно после ответа модели |
| Safe Logging | не пишет ПДн в логи |
Главная идея:
Во внешнюю LLM уходит очищенный запрос. Реальные данные остаются внутри твоей системы.
Пример токенизации
Пользователь пишет:
Составь письмо клиенту Ивану Петрову.
Его телефон: +7 918 555-22-11.
Email: ivan.petrov@mail.ru.
Он купил апартамент по договору МВ-124/25.
Перед отправкой в LLM текст должен превратиться в такой:
Составь письмо клиенту [PERSON_1].
Его телефон: [PHONE_1].
Email: [EMAIL_1].
Он купил объект по договору [CONTRACT_1].
А таблица соответствий хранится внутри твоей системы:
| Токен | Значение |
|---|---|
[PERSON_1] | Иван Петров |
[PHONE_1] | +7 918 555-22-11 |
[EMAIL_1] | ivan.petrov@mail.ru |
[CONTRACT_1] | МВ-124/25 |
Модель получает задачу, но не получает реальные данные.
После ответа модели backend может подставить нужные значения обратно уже внутри российской инфраструктуры.
Маскирование, токенизация и обезличивание: в чём разница
Маскирование
Это когда данные просто скрываются.
Было:
Телефон клиента: +7 918 555-22-11
Стало:
Телефон клиента: [PHONE]
Подходит, когда реальные данные не нужно возвращать обратно.
Токенизация
Это когда данные заменяются на специальные токены.
Было:
Иван Петров просит вернуть оплату.
Стало:
[PERSON_1] просит вернуть оплату.
Токенизация удобна, когда после ответа модели нужно вернуть реальные значения.
Например, AI пишет письмо, а продукт потом подставляет имя клиента обратно.
Обезличивание
Это более глубокая очистка, когда из текста убираются не только ФИО и телефон, но и детали, по которым можно определить человека.
Было:
Иван Петров из Сочи, собственник апартамента №305 в комплексе X, написал претензию после встречи 5 июня.
Стало:
Клиент из южного региона написал претензию по вопросу управления объектом размещения.
Обезличивание нужно, когда ты анализируешь массив данных: обращения клиентов, отзывы, жалобы, анкеты, интервью.
Важное предупреждение
Токенизация — это не магическая кнопка безопасности.
Если ты заменил имя на [PERSON_1], но оставил должность, компанию, редкий объект, дату события и номер апартамента, человека всё равно можно узнать.
Плохо:
[PERSON_1], CEO компании ADAMAND RESORT, отвечает собственнику апартамента №305 в Montville по встрече 5 июня.
Лучше:
Руководитель управляющей компании отвечает собственнику апартамента по вопросу тарифа. Тон: спокойный, уверенный, без оправданий.
Privacy Proxy должен убирать не только очевидные персональные данные, но и уникальные детали, которые могут раскрыть личность.
5 рабочих сценариев для AI-продукта
Сценарий 1. Простая генерация без ПДн
Например:
Сделай 10 идей для постов про применение AI в бизнесе.
Риск низкий. Можно отправлять в LLM.
Сценарий 2. Запрос с персональными данными
Например:
Напиши письмо клиенту Ивану Петрову, телефон +7..., договор №...
Что делать:
- найти ПДн;
- заменить на токены;
- отправить в LLM очищенный текст;
- после ответа подставить данные обратно.
Сценарий 3. Загруженный документ
Пользователь загружает PDF, договор, акт, таблицу или переписку.
Что делать:
- сначала обработать файл на backend;
- извлечь текст;
- найти персональные данные;
- удалить или токенизировать;
- отправлять в LLM только очищенную версию;
- исходный файл хранить в РФ;
- ограничить доступ к файлу.
Сценарий 4. Анализ клиентских обращений
Например:
Проанализируй 500 обращений клиентов и выдели главные проблемы.
Что делать:
- удалить ФИО, телефоны, email, номера договоров;
- убрать уникальные детали;
- оставить только суть обращений;
- отправлять обезличенный массив;
- не использовать реальные данные для обучения модели без отдельной оценки.
Сценарий 5. Чувствительные данные
Например:
- здоровье;
- дети;
- биометрия;
- паспорт;
- банковские данные;
- интимная жизнь;
- политические или религиозные взгляды.
Что делать:
- не отправлять в зарубежную LLM;
- использовать локальную модель;
- обрабатывать внутри защищённой инфраструктуры;
- отдельно оценивать юридические основания.
Что заложить в ТЗ разработчику
В ТЗ на AI-продукт стоит добавить отдельный блок:
Перед отправкой любого пользовательского текста, файла, сообщения или истории диалога во внешний LLM API система должна проверять данные на наличие персональных данных.
Обнаруженные персональные данные должны быть удалены, замаскированы или заменены токенами.
Таблица соответствия токенов и исходных значений должна храниться только на сервере оператора на территории РФ и не должна передаваться во внешний LLM API.
Если запрос невозможно очистить без потери смысла или в нём обнаружены чувствительные данные, система должна заблокировать отправку во внешнюю LLM и предложить безопасный сценарий обработки.
Минимальный технический стек
Для MVP можно заложить такую схему:
1. Backend в РФ
2. База данных в РФ
3. PII Detector
4. Prompt Sanitizer
5. Token Vault
6. LLM API Adapter
7. Response De-tokenizer
8. Safe Logs
9. User Consent Layer
10. Admin Audit Log
Не обязательно делать всё идеально на первом дне. Но важно, чтобы архитектура не была построена по принципу:
Всё, что написал пользователь, сразу отправляем в модель.
Это плохая база для продукта, который планирует расти.
Что писать пользователю
В интерфейсе AI-продукта стоит прямо предупредить:
Не передавайте в чат паспортные данные, банковские реквизиты, медицинскую информацию, данные детей и другую чувствительную информацию, если это не требуется для работы сервиса.
Если продукт использует внешние AI-сервисы, можно добавить:
Сервис может использовать AI-модели для обработки запросов. Перед отправкой данных во внешние AI-сервисы мы применяем меры минимизации, маскирования или токенизации, чтобы не передавать персональные данные без необходимости.
Главное: такой текст должен соответствовать реальной архитектуре. Нельзя написать «мы обезличиваем данные», если на самом деле всё напрямую летит в API.
Что указать в политике обработки персональных данных
В политике стоит описать:
- что продукт использует AI-технологии;
- какие категории данных могут обрабатываться;
- для каких целей используется AI;
- передаются ли данные внешним сервисам;
- применяются ли меры минимизации, маскирования, токенизации;
- где хранится основная база пользователей;
- как пользователь может удалить свои данные;
- куда обратиться по вопросам обработки ПДн.
Не нужно превращать политику в техническую документацию. Но пользователь должен понимать общую логику: что происходит с его данными и почему.
Простая таблица решений
| Ситуация | Что делать |
|---|---|
| Запрос без ПДн | можно отправлять в LLM |
| Есть ФИО, email, телефон | токенизировать |
| Есть договор или номер заказа | токенизировать или удалить |
| Есть паспорт, карта, здоровье, дети | не отправлять во внешнюю LLM |
| Нужно сделать письмо клиенту | токенизация + обратная подстановка |
| Нужно сделать аналитику обращений | обезличивание |
| Пользователь загрузил файл | очистка на backend перед отправкой |
| Нужно хранить историю чата | хранить в РФ, в LLM отправлять минимум |
| Нужно обучать модель | не использовать реальные ПДн без отдельной оценки |
Частые ошибки
Ошибка 1. Отправлять весь пользовательский ввод напрямую в LLM
Даже если пользователь сам вставил данные, продукт всё равно должен думать о рисках.
Ошибка 2. Логировать исходные промты
Иногда ПДн не только уходят в модель, но ещё и остаются в логах, error tracking, аналитике и debug-сообщениях.
Ошибка 3. Хранить историю чата за рубежом
Если история содержит данные российских пользователей, лучше хранить её в российской базе.
Ошибка 4. Считать, что API-провайдер «сам всё защитит»
Даже если провайдер обещает не обучать модель на API-запросах, это не отменяет обязанности оператора правильно обрабатывать персональные данные.
Ошибка 5. Не разделять consumer-аккаунты и business/API-режимы
У разных сервисов могут быть разные правила для обычного пользовательского аккаунта и API/business-продукта. Перед запуском нужно читать условия конкретного сервиса.
Главный вывод
Использовать зарубежные LLM в AI-продуктах можно только аккуратно.
Задача не в том, чтобы отказаться от сильных моделей. Задача в том, чтобы не отправлять им лишнее.
Правильная архитектура выглядит так:
Пользователь → backend в РФ → Privacy Proxy → очищенный запрос → LLM → ответ → восстановление данных → пользователь
И главный принцип остаётся прежним:
Модель должна знать задачу, а не человека.
Если с самого начала заложить Privacy Proxy, токенизацию, безопасные логи и хранение данных в РФ, AI-продукт будет не только быстрее запускаться, но и взрослее выглядеть для пользователей, партнёров и проверяющих органов.
Читайте также в серии:
- Персональные данные в РФ для вайбкодеров: что нужно знать перед запуском AI-продукта
- Политика, согласие и оферта: какие документы нужны для MVP
- Лендинг и форма заявки: чек-лист по персональным данным
- Telegram-бот и персональные данные: что учесть перед запуском
- Где хранить данные: Supabase, Firebase, Notion, Airtable и Google Sheets
- Cookies, аналитика и пиксели: что важно знать владельцу сайта
- Privacy by Design для SaaS и AI-продукта