152-ФЗ и зарубежные API всплывают не в юридическом отделе, а на этапе запуска продукта. Разработчик подключил модель, запросы идут, ответы приходят, и всё выглядит рабочим. А потом выясняется, что через сервис проходят данные клиентов. Именно здесь у команды появляются вопросы, на которые нет короткого ответа.
Разберём простыми словами, что требует закон, где зарубежный сервис создаёт риск и что можно проверить прямо сейчас, без готового юридического заключения.
Почему вопрос возникает у всех
Подключая API, команда думает о коде. Проверяет лимиты, скорость ответа, стоимость токенов. Данные при этом уходят за границу без отдельного решения, просто потому что сервер вендора стоит не в России.
Проблема проявится позже. Когда клиент спросит, где хранятся его данные. Или когда бухгалтерия попросит документы по обработке. Или когда придёт запрос от проверяющих. К этому моменту архитектуру менять дорого и долго.
Что регулирует 152-ФЗ
Закон о персональных данных касается любой информации, по которой можно определить человека: имя, телефон, почта, адрес, документы, даже переписка. Если система обрабатывает такие данные, вы оператор, и требования закона на вас распространяются.
Главное, что нужно держать в голове:
- Согласие. Данные обрабатывают с согласия человека. Молчание согласием не считается.
- Цель. Под каждую обработку определяют цель, и использовать данные для другого нельзя.
- Уведомление. Оператор сообщает в Роскомнадзор о начале обработки, кроме отдельных исключений.
- Локализация. Записи о гражданах России нужно вести в базах на территории страны.
Это не формальность ради галочки. Требования проверяются, и их несоблюдение создаёт для бизнеса реальные риски.
Оператор и обработчик: кто за что отвечает
Оператор определяет, зачем и как обрабатывают данные. Обычно это ваш бизнес. Обработчик выполняет обработку по поручению оператора: облако, подрядчик, внешний сервис.
Ответственность перед человеком и проверяющими остаётся на операторе. Передать данные обработчику можно, но с договором и понятным перечнем действий. Если подрядчик работает с данными в своих интересах, это уже не обработка по поручению, и схема становится рискованной.
Отсюда простой вывод: до подключения определите, в какой роли выступаете вы и кто вторая сторона. От этого зависит и текст согласия, и комплект документов.
Причём здесь зарубежный API
Когда вы отправляете в зарубежный сервис текст с данными клиента, происходит трансграничная передача. Закон её не запрещает полностью, но требует отдельного основания и, как правило, уведомления.
Дальше начинается неопределённость. Вы не контролируете, где вендор хранит данные, сколько держит логи и кому их передаёт. На эти вопросы у зарубежного сервиса обычно нет ответа, который устроил бы российскую проверку. Плюс отдельная история с доступом: прямой путь к API из России нестабилен, и команды ставят обходные схемы. К юридическому риску добавляется технический.
Чек-лист перед подключением
Что проверить до того, как данные уйдут в API:
1. Какие именно данные проходят через сервис.
2. Есть ли согласие человека на их передачу.
3. Куда физически уезжают данные и где хранятся.
4. Кто отвечает за обработку — вы или подрядчик.
5. Как данные удаляются по требованию.
Локализация на практике
Локализация не про то, где лежит код. Она про базы, в которых хранятся записи о людях. Основной массив должен быть в России, и это касается не только крупных сервисов.
На практике выясняется, что команды ведут логи и историю обращений в зарубежном облаке. Формально это и есть то, что требует внимания. Простой пример: ассистент сохраняет диалоги с клиентами в базу за рубежом, чтобы потом дообучать модель. Здесь сразу два вопроса — согласие и локализация.
Что можно сделать уже сейчас
- Составьте список полей, которые реально уходят в API. Часто их меньше, чем кажется.
- Уберите из промптов лишнее: документы, телефоны, полные адреса и всё, без чего модель справится.
- Проверьте, где хранятся логи и сколько они живут.
- Подготовьте текст согласия под свою цель обработки.
- Уточните у поставщика, где находятся серверы и как устроено удаление данных.
Первые три пункта закрываются без денег и консультаций. Они же снимают большую часть риска.
Как это устроено у российского шлюза
Российский шлюз к китайским моделям работает как посредник между вашим кодом и вендором. Юридически вы имеете дело с российской компанией: договор, счёт, закрывающие. А передача запроса в модель идёт через инфраструктуру на территории страны.
Это не снимает с вас обязанностей оператора. Согласие, цель обработки и локализация остаются на вашей стороне. Но часть вопросов закрывается документами, а не объяснениями: понятно, кто отвечает за обработку и как её организовать.
Разница между поставщиками видна в деталях. Кто даёт договор, кто объясняет, где хранятся логи, у кого есть ответ про трансграничную передачу. Как сравнивать условия, разобрано в статье про провайдеров LLM API в России, а комплект документов для юрлица — в материале про оплату API юрлицом. Техническую сторону подключения описывает статья API китайских моделей в России.
152-ФЗ и зарубежные API — это не про запрет, а про порядок. Закон не мешает работать с моделями, но требует понимать, какие данные вы обрабатываете и где они лежат. Команды, которые разбираются с этим на старте, не переделывают архитектуру в спешке.
Начните с ревизии данных и промптов. Это занимает вечер и снимает половину вопросов до того, как появится первый клиент.
Платформа Китай-API готовится к запуску. Это один ключ к DeepSeek, Qwen, GLM, Kimi с оплатой в рублях и российскими документами. Оставить заявку на ранний доступ можно в Telegram-боте, мы сообщим, когда откроем доступ первым. Что уже известно о платформе, собрано на главной странице.