Поэтому задача не в том, чтобы «обойти» запрет, а в том, чтобы либо вывести персональные данные за пределы регулирования (обезличить), либо разместить их обработку в разрешенной юрисдикции (российское облако / on-premise), либо получить надлежащее правовое основание (согласие или договор поручения).
Ниже — пять легальных путей, от самого дешевого и быстрого к самому дорогому и капиталоемкому.
1. Обезличивание до отправки в модель
Это самый доступный способ. Если из текста удалить или заменить плейсхолдерами поля, которые идентифицируют человека (ФИО, телефон, email, паспорт, ИНН физлица, номер счета), то в модель уходит текст, который персональными данными уже не является.
Ключевое условие: простая замена имен на идентификаторы вроде user_123 не всегда решает проблему. Если связь между токеном и человеком можно восстановить, данные все еще могут считаться персональными.
Правовое основание: пункт 9 части 1 статьи 6 152-ФЗ — обработка «в статистических или иных исследовательских целях… при условии обязательного обезличивания».
Как это выглядит на практике: шлюз приватности, который автоматически выполняет цепочку detect → pseudonymize → re-hydrate — находит персональные данные, заменяет их плейсхолдерами перед отправкой в модель и восстанавливает в ответе. После этого можно использовать даже зарубежные модели: трансграничная передача идет в обезличенном виде, и 152-ФЗ формально не нарушается.
Ограничение: метод работает, только если обезличивание необратимо в контексте получателя. Если у облачного провайдера есть доступ к дополнительной информации, позволяющей деобезличить данные, они могут быть признаны персональными.
2. Российское облако с аттестованным ЦОД
Если обезличивание невозможно или нежелательно, следующий шаг — размещение обработки в российском облаке, которое соответствует 152-ФЗ.
Что это дает: данные физически остаются на территории РФ, провайдер обеспечивает соответствие 152-ФЗ, VPN не требуется, ПДн остаются в российской юрисдикции.
Что нужно проверить у провайдера:
Аттестат соответствия требованиям 152-ФЗ. Например, Cloud.ru Evolution аттестован по УЗ-1 (первый уровень защищенности). МТС Web Services запустила сегмент виртуальной инфраструктуры с GPU, аттестованный по первому уровню защищенности.
Размещение в аттестованном ЦОД уровня Tier III — это не только отказоустойчивость (доступность 99,98%+), но и выполнение требований к физической защите и обработке ПДн.
Договор поручения на обработку персональных данных — без него использование облачного сервиса для ПДн юридически некорректно.
Вариант с арендой GPU: если нужна открытая модель, но покупать собственное оборудование невыгодно (дорого, дефицитно, быстро устаревает), можно арендовать GPU-мощности в российском ЦОД. Например, Cloud4Y предлагает LLM-платформу, позволяющую развернуть и дообучить открытую модель на GPU-инфраструктуре провайдера, не выпуская корпус данных за периметр и не покупая ускорители.
3. Гибридная схема: локальная модель + облако
Это архитектурный компромисс. Задачи делятся на два потока: чувствительные данные обрабатываются локальной моделью на устройстве или в контуре компании, а «тяжелые» задачи рассуждения, поиска и планирования уходят в облако.
Пример реализации: Perplexity в 2026 году выпустила функцию Hybrid Compute для Mac — она автоматически распределяет задачи между облачными моделями и локальными моделями на Apple silicon. Облако отвечает за рассуждения и веб-поиск, а локальная модель обрабатывает защищенные файлы и действия на устройстве, так что конфиденциальные данные не покидают устройство.
Для корпоративного контура аналогичный принцип можно реализовать так: локальная open-weight модель (DeepSeek, Qwen, Gemma) разворачивается на своем железе и обрабатывает все, что содержит ПДн или коммерческую тайну, а облачная модель подключается только для задач, где персональных данных нет.
Когда это оправдано: если объем чувствительных данных велик, но не настолько, чтобы полностью отказываться от облачных возможностей.
4. Полностью локальное развертывание (on-premise)
Это максимально защищенный, но и самый дорогой путь. Данные не покидают контур компании вообще.
Что это дает: полное соответствие 152-ФЗ, обработка персональных данных без выхода за периметр, совместимость с требованиями ФСТЭК России.
Что нужно: собственные серверы с GPU, развернутые открытые модели, политика доступа к данным, аттестация контура при необходимости.
Готовые решения: на рынке уже есть платформы для безопасного развертывания ИИ-агентов в корпоративном контуре on-premise, ориентированные на организации с высокими требованиями к контролю и защите данных. Например, «Рег.облако» предлагает приватного ИИ-ассистента по модели HaaS (Hardware as a Service) — изолированное on-premise-решение, архитектура которого позволяет провести аттестацию на соответствие ФЗ-152 и требованиям ФСТЭК.
Когда выбирать: если сегмент с персональными данными уже аттестован и любой новый исходящий поток требует согласования, а объем данных делает облако неприемлемым.
Получите дорожную карту по внедрению 1С разработанную для вашей компании бесплатно!
Получите дорожную карту по внедрению 1С разработанную для вашей компании бесплатно!
5. Согласие субъекта или договор поручения
Самый простой юридический путь, который часто недооценивают. Если вы получаете согласие субъекта персональных данных на обработку с использованием конкретного облачного сервиса, требование 152-ФЗ формально закрыто.
Что должно быть в согласии:
указание на то, что данные передаются в сторонний сервис (включая аудиоданные, если речь о распознавании речи);
цели обработки, состав данных, срок действия согласия;
свободное, конкретное, информированное и осознанное согласие.
Договор поручения — альтернативный или дополнительный инструмент. Его отсутствие с зарубежными поставщиками LLM — главная проблема, даже более серьезная, чем уведомление Роскомнадзора. С российскими облачными провайдерами такой договор заключается штатно.
Ограничение: согласие работает, если субъект может его дать осознанно и если обработка не выходит за рамки заявленных целей. Для массовой обработки данных сотрудников или клиентов этот путь часто неприменим.
Сводная таблица: какой путь выбрать
Ситуация | Рекомендуемый путь |
В промптах минимум ПДн, можно обезличить | Шлюз приватности + любая модель |
Нужна простая интеграция, ПДн есть, но объем небольшой | Российское облако с аттестатом 152-ФЗ |
Есть чувствительные данные и тяжелые задачи | Гибрид: локальная модель + облако |
Сегмент ПДн аттестован, исходящий поток требует согласования | On-premise, полностью локальный контур |
Можно получить согласие субъектов | Согласие + договор поручения |
Важное предостережение
Ни один из этих путей не является «обходом» в смысле нарушения закона. Все они — легальные способы организовать обработку так, чтобы требования 152-ФЗ соблюдались. Если же под «обходом» подразумевается передача персональных данных в зарубежное облако без обезличивания, без согласия и без договора поручения — это уже прямое нарушение, за которое предусмотрена ответственность, включая штрафы и блокировку ресурса.
Первый практический шаг — не выбор инструмента, а аудит того, какие именно поля в ваших промптах являются персональными данными. Чаще всего их немного: имя клиента и контакт в тикете, номер полиса, идентификатор пациента. Если эти поля убрать или заменить плейсхолдерами до отправки - в модель уходит текст, который ПДн уже не является, и архитектура может быть гораздо проще и дешевле, чем казалось.
Как показано в статье, легальных путей использования ИИ с персональными данными как минимум пять - от обезличивания до полностью локального контура. Мы поможем вам выбрать оптимальный вариант: проведем аудит данных, оценим объемы и чувствительность, предложим архитектуру и настроим решение под требования 152-ФЗ и ФСТЭК. Свяжитесь с нами по телефону +7(495) 989-22-16 или электронной почте sales@rg-spc.ru.
Реклама: ООО «РГ-Софт Проект Консалтинг», ИНН 7736229025, erid: 2W5zFGoa7tu
