Короткий ответ: текст запроса к языковой модели оседает не в одном месте, а минимум в четырёх, и три из этих мест находятся внутри вашего периметра. Журнал вашего приложения, отладочный журнал подрядчика, инфраструктура провайдера модели и хранилище базы знаний — каждый узел хранит копию с собственным сроком и собственным списком тех, кто может её прочитать. Вопрос «куда это уходит» обычно задают только про третий узел, а претензии проверяющего чаще всего приходят к первому.
Это не значит, что использовать языковые модели нельзя. Это значит, что приведение схемы к 152-ФЗ — работа на конкретный список узлов, а не общий разговор о безопасности. Список короткий, и его можно составить за один день: по каждому узлу нужно ответить, что там оседает, на какой срок, кто имеет доступ и каким документом это закрыто.
Ниже — разбор маршрута по узлам, определение того, что в диалоге считается персональными данными, три законные конфигурации с ценой каждой и минимум, который стоит зафиксировать во внутренней политике после 1 сентября 2026 года. Все расчёты — на сквозном модельном примере раздела: компания на 140 человек, внутренний ассистент по регламентам и условиям договоров, база из 380 документов, поток 6 000 обращений в месяц.
Маршрут одного запроса: четыре узла и четыре журнала
Проследим один вопрос сотрудника: «Клиент Петров по договору 4718 просит рассрочку, что отвечать». В этом предложении уже есть фамилия и номер договора, а после подстановки найденных фрагментов в запрос уйдёт ещё и текст условий. Вот что с этим текстом происходит дальше.
| Узел | Что оседает | Срок по умолчанию | Кто может прочитать |
|---|---|---|---|
| Ваше приложение или бот | Полный текст вопроса и ответа, автор, время, вложения | Бессрочно — журнал редко чистят | Администратор, инженеры сопровождения, все, у кого есть доступ к БД |
| Прослойка подрядчика | Тот же текст в отладочном журнале, часто на его инфраструктуре | Обычно не оговорён вообще | Инженеры подрядчика, включая тех, кто уже не на проекте |
| Провайдер модели | Запрос целиком: инструкция, найденные фрагменты, история, ответ | У российских провайдеров — по соглашению, типично 30 дней | Служба поддержки провайдера в рамках регламента |
| Хранилище базы знаний | Сами документы, их фрагменты и векторы, часто и кэш ответов | Пока живёт система | Администратор БД, подрядчик сопровождения |
Карта связей слева направо: «Сотрудник» → «Ваше приложение» → «Прослойка подрядчика» → «Провайдер модели», отдельной веткой снизу «Хранилище базы знаний» с двусторонней стрелкой к прослойке. Под каждым узлом маленький значок журнала с подписью срока: «бессрочно», «не оговорён», «около 30 дней», «пока живёт система». Первые два узла и хранилище обведены общей рамкой с подписью «ваш периметр и ваша ответственность», провайдер — отдельной рамкой «договор поручения». Внизу подпись: «резервные копии и кэш — два узла, о которых забывают». Чертёжный стиль, подписи по-русски.
Резервные копии и кэш ответов. Копии базы с диалогами живут по своему расписанию и переживают любое удаление в интерфейсе — если срок хранения диалогов установлен в 90 дней, а бэкапы хранятся год, реальный срок хранения равен году. Кэш ответов, который ставят ради экономии на токенах, хранит пары «вопрос — ответ» отдельно от основного журнала и обычно вообще не попадает в реестр обработки. Оба узла добавляются в схему одной строкой и закрываются тем же сроком, что и основной журнал.
Практический вывод из таблицы простой: разговор о приватности начинается не с выбора провайдера, а с двух настроек внутри вашего контура — срока хранения диалогов и списка тех, у кого есть доступ к журналу. Обе бесплатны и обе почти никогда не сделаны по умолчанию. Принцип, по которому раздаются доступы, разобран отдельно в материале про минимальные права доступа.
Что в диалоге считается персональными данными
Граница проходит не там, где её обычно рисуют. Персональные данные — это не только паспорт и телефон: это любая информация, относящаяся к определённому или определяемому лицу. Ключевое слово — «определяемому»: если по совокупности сведений человека можно вычислить, обезличивания не произошло.
- Очевидные случаи. Фамилия, телефон, адрес доставки, электронная почта, номер договора вместе с именем, данные документа. Здесь спора не бывает.
- Определяемые по совокупности. «Клиент из Приморского района, заказ на 340 тысяч, забирал 14 августа» — имени нет, но в вашей базе такой заказ один. Это персональные данные, и именно этот случай чаще всего пропускают.
- Записи разговоров и их расшифровки. Запись — персональные данные, даже если человек не назвался: она привязана к номеру, а номер к карточке. Тот же вопрос возникает при расшифровке и резюме звонков, и решается он на этапе постановки, а не после запуска.
- Данные сотрудников. Про них забывают чаще всего: внутренний ассистент, которому пишут «мне не начислили за переработку в июле», обрабатывает персональные данные работника ровно так же, как клиентский бот — данные клиента.
Замена «Петров Иван Иванович» на «П-в И. И.» обезличиванием не является: по инициалам и номеру договора в той же строке человек восстанавливается за минуту. Работает другое — псевдонимизация: имя, телефон и адрес заменяются на устойчивый идентификатор вида «клиент №4718», а таблица соответствия остаётся в вашей базе и наружу не уходит вообще. Разницу и её ограничения мы разбирали в материале про обезличенные данные для тестового контура.
Сравнение в две колонки на одном примере запроса. Левая «Маскировка на глаз»: строка «П-в И. И., договор 4718, Гагарина 20к1, рассрочка», ниже пометка «восстанавливается по базе заказов за минуту» и красный контур. Правая «Псевдонимизация»: строка «клиент №4718, договор №Д-2, город А, рассрочка», ниже блок «Таблица соответствия» с замком и подписью «остаётся в вашей базе, наружу не уходит». Под колонками общая подпись: «Наружу уходит только правая строка; ответ модели собирается обратно на вашей стороне». Чертёжный стиль.
Три законные конфигурации и цена каждой
Законных вариантов три, и они отличаются не степенью «защищённости вообще», а тем, какой узел маршрута вы убираете. Считаем все три на одном потоке — 6 000 обращений в месяц — чтобы цифры были сопоставимы. Постоянная часть сметы одинакова во всех вариантах: инфраструктура, сопровождение, выборочный контроль ответов и ведение базы знаний — 49 700 ₽ в месяц.
Что стоит за каждой строкой. Вариант А — российский облачный провайдер: Yandex AI Studio или GigaChat Enterprise в облачном исполнении. Данные размещаются в России, трансграничной передачи нет, договор поручения обработки заключается с юридическим лицом в российской юрисдикции. Разовые 40 000 ₽ — это не техника, а бумага: реестр обработки, договор поручения, обновление политики и согласий. Именно этот вариант закрывает большинство внутренних задач.
Вариант Б — тот же провайдер плюс шлюз, который перед отправкой заменяет имена, телефоны и адреса на псевдонимы, а в ответ подставляет их обратно. Он дороже на 8 000 ₽ в месяц: кто-то должен вести правила замены и разбирать случаи, когда шлюз не распознал имя. Смысл варианта в том, что за пределы вашего контура персональные данные не выходят вообще, и разговор со службой безопасности становится коротким.
Вариант В — модель на своём сервере в России. Убирается весь третий узел маршрута целиком. Цена этого — фиксированные 89 700 ₽ в месяц независимо от потока: амортизация железа, размещение, электричество, системный администратор и запасной контур. Состав конфигураций и подробную арифметику мы разбирали в материале про локальную модель под 152-ФЗ.
Три вертикальных составных столбца одинаковой шкалы с подписями «А. Российское облако», «Б. Облако плюс шлюз обезличивания», «В. Локальная модель». Каждый столбец разбит на сегменты: общий нижний «Постоянная часть — 49 700 ₽» во всех трёх, верхние сегменты — «Модель 16 920 ₽», «Модель 16 920 ₽ + шлюз 8 000 ₽», «Свой контур 89 700 ₽». Итоги над столбцами: 66 620 ₽, 74 620 ₽, 139 400 ₽. Справа выноска со стрелкой между А и В: «разница 72 780 ₽/мес, 873 360 ₽/год». Внизу сноска «6 000 обращений в месяц, сентябрь 2026». Ось Y — рубли в месяц.
Локальная модель: сильный аргумент и слабая экономика
Свой сервер — самый убедительный ответ на вопрос «а куда это уходит»: никуда, считает здесь. По 152-ФЗ это снимает тему трансграничной передачи полностью и обычно закрывает позицию службы безопасности за одну встречу. Проблема в том, что он почти всегда дороже.
Арифметика такая. Свой контур стоит фиксированные 89 700 ₽ в месяц при любом объёме. Облачная строка модели в нашем примере — 16 920 ₽, то есть в пять с лишним раз меньше. Порог, на котором они сравниваются, лежит в районе 80 000–90 000 ₽ ежемесячных расходов на облачную модель; в пересчёте на обращения это около 86 000 запросов в месяц — примерно 2 900 в день. Для компании на 50–200 человек такой поток даёт разве что клиентский контакт-центр или массовая обработка документов.
Локальную модель покупают под требование, а не ради экономии. Если требования нет, а объём ниже порога, свой сервер обойдётся вдвое дороже облака — и сказать это собственнику надо до закупки железа, а не после.
Требование, оправдывающее свой контур, обычно звучит одним из четырёх способов: специальные категории персональных данных в процессе, условие заказчика по размещению в договоре, госконтракт с требованием к инфраструктуре, письменная позиция службы безопасности. Всё остальное — предпочтения, и они стоят 873 360 ₽ в год. Признаки, при которых контур действительно обязателен, разобраны в материале про модель в своём контуре.
Зарубежные провайдеры: отдельный узел без договора
Про OpenAI и Anthropic спрашивают в каждом проекте, поэтому скажем прямо. По состоянию на сентябрь 2026 года прямая оплата их API из России невозможна: страна не входит в список поддерживаемых. Доступ идёт через рублёвых посредников и агрегаторы. Технически это работает, юридически — создаёт конструкцию, которую сложно защищать.
- 1В маршруте появляется пятый узел — посредник. Он видит текст запроса и ответа, ведёт собственный журнал и в схеме обработки данных обычно вообще не описан.
- 2Договор поручения обработки по ч. 3 ст. 6 152-ФЗ заключать не с кем: посредник не является оператором модели, а с оператором модели у вас нет отношений. Формально цепочка не замыкается.
- 3Передача данных за пределы России — трансграничная передача со своим набором обязанностей. Обосновать её ради удобства разработчика не получится.
- 4Условия посредника меняются в одностороннем порядке и без уведомления. Поток может остановиться в любой день, и это отдельный операционный риск, а не только юридический.
Практическая позиция, которую мы занимаем на проектах: зарубежные модели допустимы для задач, где персональных данных нет вообще — черновики текстов, разбор публичных документов, эксперименты на синтетических примерах. Как только в запрос попадает клиент или сотрудник, разговор переходит к вариантам А, Б и В из таблицы выше. Сравнение российских моделей на прикладных задачах мы делали отдельно, чтобы этот выбор не был вынужденным компромиссом.
Пять вопросов подрядчику и что считать плохим ответом
Проверить схему обработки данных можно на первом же созвоне, без аудита и без юриста. Ниже — пять вопросов, которые мы задаём сами, и признаки, по которым ответ считается неудовлетворительным. Плохой ответ здесь не повод отказываться от подрядчика: это повод дописать пункт в договор до подписания, а не после первой проверки.
- 1«Где физически хранится журнал диалогов и сколько времени?»
Хороший ответ содержит название площадки, страну и число дней. Настораживает ответ «на нашем сервере, сколько нужно»: он означает, что срок не задан, а значит, реальный срок хранения — бессрочно, включая резервные копии. Число дней должно попасть в договор и в настройку, а не только в разговор.
- 2«Кто из ваших инженеров видит содержимое запросов?»
Хороший ответ — конкретный список ролей и упоминание того, что доступ выдаётся под задачу и снимается после. Настораживает «доступ есть у команды»: команда меняется, а учётные записи остаются. Про то, как забытые записи превращаются в инцидент, мы писали в материале про учётные записи подрядчика.
- 3«Что именно уходит в модель — покажите один реальный запрос целиком»
Это самый полезный вопрос из пяти. В запросе видно всё: сколько фрагментов подставляется, попадают ли туда фамилии и телефоны, тянется ли история диалога. Настораживает ответ «это внутренняя кухня» — смотреть на собственные данные, уходящие наружу, вы вправе всегда.
- 4«С кем заключается договор поручения обработки?»
Хороший ответ называет юридическое лицо провайдера в российской юрисдикции. Настораживает конструкция, где подрядчик предлагает свой договор поручения, а сам ходит к зарубежной модели через посредника: цепочка в этом месте рвётся, и отвечать за разрыв будете вы как оператор.
- 5«Как переключить систему на другого провайдера и за сколько?»
Хороший ответ — дни и наличие слоя абстракции модели в архитектуре. Настораживает «зачем вам это»: без такого слоя смена провайдера по требованию службы безопасности или после изменения тарифов превращается в новый проект. Заложить абстракцию на старте стоит недели работы, переделывать потом — заметно дороже.
Ответы стоит получить письменно и приложить к договору — не ради формальности, а потому что через год состав команды подрядчика будет другим. Какие ещё пункты имеет смысл зафиксировать до начала работ, разобрано в материале про договор на разработку.
Что зафиксировать после 1 сентября 2026 года
С 1 сентября 2026 года действуют требования к обработке персональных данных в ИИ-системах и к маркировке ИИ-контента. Полный разбор изменений — в материале про то, что меняется в работе с ИИ с сентября. Практический минимум для компании 20–300 человек — внутренняя политика на две-три страницы, и вот её шесть обязательных пунктов.
- 1Реестр узлов и систем
Перечень всех мест, где ИИ обрабатывает данные компании: боты, помощники в CRM, встроенные функции сервисов, личные подписки сотрудников. Последний пункт обычно даёт половину списка и половину сюрпризов.
- 2Три категории данных и правило для каждой
Что можно отправлять в модель свободно, что только после псевдонимизации и что нельзя ни при каких условиях. Формулировки должны быть такими, чтобы менеджер понял их без юриста; шаблон разбирали в материале про политику использования ИИ.
- 3Сроки хранения и автоудаление
Срок жизни диалогов задаётся числом и удаление выполняется автоматически, а не по напоминанию. Отдельной строкой — срок хранения резервных копий: он определяет реальный срок, а не тот, что написан в интерфейсе.
- 4Кто отвечает за проверку ответов
Названный поимённо человек и порядок выборочного контроля: сколько ответов в неделю просматривается и что делается с найденными ошибками. Без этого пункта политика остаётся декларацией.
- 5Маркировка материалов, подготовленных с участием ИИ
Где именно и как ставится пометка, кто следит за её наличием. Операционно это ближе к редакционному регламенту, чем к технике, и написать его проще до первой публикации.
- 6Порядок при инциденте
Уведомление в Роскомнадзор в течение 24 часов и результаты внутреннего расследования в течение 72 часов. В тексте должны стоять фамилия ответственного и способ связи с ним в выходной день.
Схема из шести пронумерованных блоков в две колонки: «1. Реестр узлов и систем», «2. Три категории данных», «3. Сроки хранения и автоудаление», «4. Ответственный за проверку ответов», «5. Маркировка ИИ-материалов», «6. Порядок при инциденте». В каждом блоке вторая строка мелким шрифтом — артефакт: «таблица систем», «памятка на страницу», «настройка автоудаления», «фамилия и регламент», «редакционное правило», «24 часа и 72 часа». Внизу общая полоса с подписью «Внутренняя политика, 2–3 страницы, действует с 1 сентября 2026 года». Чертёжный стиль, подписи по-русски.
Когда всё это избыточно
Полный набор мер нужен не всем, и надстраивать его «на всякий случай» — распространённый способ потратить полмиллиона впустую. Четыре ситуации, в которых мы отговариваем.
- В модель уходят только обезличенные тексты. Помощник по регламентам, который не видит ни одной фамилии, не создаёт обработки персональных данных. Достаточно варианта А и записи об этом в реестре — шлюз и сервер здесь лишние.
- Процесс ещё на пилоте и работает на синтетических данных. Строить контур до того, как понятно, дойдёт ли пилот до эксплуатации, — типичная ошибка порядка работ. Сначала проверяется польза, потом покупается железо.
- Объём меньше 3 000 обращений в месяц. На таком потоке облачная строка модели меньше 10 000 ₽, и любая инфраструктурная мера будет стоить дороже всего процесса. Дешевле ограничить доступ и сократить срок хранения.
- Данные и так уже у подрядчика по другому договору. Если ваша учётная система обслуживается внешней командой, вопрос доступа к данным решён давно и решается тем же договором поручения. Отдельный контур ради ИИ ничего к этому не добавит.
И обратная сторона: две меры стоит сделать всегда, независимо от конфигурации и объёма. Первая — задать срок хранения диалогов и включить автоудаление, включая резервные копии. Вторая — сократить список тех, у кого есть доступ к журналу, до тех, кому он нужен по работе. Обе бесплатны, обе занимают день и обе снимают больше вопросов на проверке, чем любая покупка.
