ИИ-агенты и хранение данных в России: где размещать серверы

Разработчик, который поднимает ИИ-агента для обработки клиентских обращений, обычно думает про модель, промпты и стоимость токенов. А потом обнаруживает, что каждый диалог с пользователем — это сбор персональных данных, и хранить их в облаке в Ирландии или Огайо российский закон не разрешает. Требование локализации ПДН действует с 2015 года, но с распространением агентов, которые логируют каждый запрос, оно снова стало горячей темой.

Что требует закон о локализации

Базовое правило зафиксировано в статье 18 части 5 Федерального закона № 152-ФЗ «О персональных данных»: при сборе персональных данных граждан России оператор обязан обеспечить их запись, систематизацию, накопление, хранение, уточнение и извлечение с использованием баз данных, находящихся на территории России.

Ключевое слово — «первичная» база. Практика Роскомнадзора и разъяснения Минцифры сводятся к тому, что первичный сбор и хранение ПДН должны идти в российской инфраструктуре. Трансграничная передача после этого возможна, но при соблюдении отдельных условий — уведомление регулятора, оценка уровня защиты в стране-получателе. Точный порядок и перечень исключений сверяйте с актуальной редакцией 152-ФЗ, потому что требования к трансграничной передаче менялись несколько раз, последний крупный блок поправок — в 2022–2023 годах.

Для ИИ-агента это означает простую вещь: если пользователь пишет боту «меня зовут Иван, мой заказ №12345, телефон такой-то», эта реплика — персональные данные. И база, куда она попадает первой, должна физически стоять в России.

Модель может считаться где угодно. Проблема не в вычислениях, а в том, где оседает переписка с пользователем — именно она превращает ИИ-агента в оператора персональных данных.

Где именно возникает риск в архитектуре агента

Типичный ИИ-агент состоит из нескольких слоёв, и персональные данные утекают за границу не там, где кажется. Разберём по узлам:

• Приём сообщений. Веб-виджет, мессенджер, телефония — здесь пользователь вводит данные. Точка сбора.
• Логи и история диалогов. Самое опасное место. Многие фреймворки по умолчанию пишут историю в managed-базу, которая физически может быть за рубежом.
• Векторное хранилище для RAG.¹ Если агент ищет ответ по базе знаний, туда часто попадают эмбеддинги пользовательских запросов вместе с исходным текстом.
• Вызов языковой модели. Отправка текста в зарубежный API — это уже трансграничная передача, а не хранение. Регулируется отдельно и требует оснований.
• Аналитика и мониторинг. Трекеры и системы наблюдаемости нередко хостятся за границей и собирают сырые запросы «для отладки».

На практике компании спотыкаются именно на логах и мониторинге: основную базу перенесли в Россию, а сервис наблюдаемости продолжает складывать полные тексты диалогов где-то в другом регионе.

Что с самой моделью

Здесь развилка. Если вы отправляете пользовательские сообщения в зарубежный облачный API, вы совершаете трансграничную передачу и должны иметь для этого правовые основания. Отсюда рост интереса к двум вариантам: российские модельные API и self-hosted развёртывание open-source моделей внутри собственного контура. Второй путь снимает вопрос передачи за границу полностью, но требует своих GPU-мощностей.

Варианты инфраструктуры

Три реалистичных сценария, где держать данные и вычисления для агента, ориентированного на российских пользователей.

Гибридный вариант — самый тонкий юридически. Обезличивание должно быть настоящим: убрать ФИО, телефоны, адреса, номера документов до отправки в модель. Полуобезличенные данные, из которых человека всё ещё можно вычислить, остаются персональными, и передача такого текста за границу — та же трансграничная передача.

Кому это пригодится и кому нет

Локализация обязательна и критична, если:

• вы делаете агента поддержки для банка, маркетплейса, клиники или другого сервиса, где пользователи оставляют реальные данные — имена, номера заказов, диагнозы, платёжную информацию;
• агент работает с обращениями граждан от лица компании-оператора ПДН, зарегистрированного в России;
• вы обрабатываете чувствительные категории данных — здоровье, биометрию — где требования жёстче, а штрафы выше.

Вопрос стоит менее остро, если:

• агент не собирает персональные данные вообще — например, отвечает на вопросы по публичной документации без авторизации и без ввода контактов;
• вы делаете внутренний инструмент для сотрудников, а данные и так внутри корпоративного контура в РФ;
• это исследовательский прототип на синтетических данных, который не работает с живыми пользователями.

Даже в «мягких» случаях стоит заранее спроектировать архитектуру так, чтобы при выходе в прод не пришлось переносить всё хранилище — миграция боевой базы диалогов болезненнее, чем закладка правильной схемы на старте.

Штрафы: цена вопроса выросла

В 2025 году ответственность за нарушения в области персональных данных была существенно ужесточена — введены оборотные штрафы за утечки и повышены санкции за нарушение порядка обработки, включая нарушение локализации. Конкретные суммы и составы смотрите в актуальной редакции КоАП РФ по статье 13.11: диапазоны зависят от того, юрлицо это или ИП, первое нарушение или повторное, и был ли факт утечки. Подставлять точную цифру здесь опасно — она менялась, и её нужно сверять по действующей редакции кодекса на дату вашей ситуации.

Практический вывод один: экономия на российской инфраструктуре легко перекрывается одним штрафом, а при утечке персональных данных — тем более.

¹ RAG (Retrieval-Augmented Generation) — подход, при котором языковая модель перед ответом ищет релевантные фрагменты в вашей базе знаний и подставляет их в контекст. Позволяет отвечать по актуальным документам без дообучения модели, но именно в хранилище для поиска часто оседают тексты пользовательских запросов.