Работа ИИ-системы с персональными данными подчиняется тем же правилам, что и любая другая обработка. Модель не является исключением, а обращение к облачному сервису — это передача данных другому лицу.
Формулировка, с которой стоит начинать любой проект: если в запрос к внешней модели попадает фамилия, телефон, адрес или номер документа — это обработка персональных данных с привлечением третьего лица, и она должна быть основана на законе. Рамка здесь общая для всех обработчиков — тот самый 152-ФЗ, — и ИИ не создаёт исключений, хотя добавляет несколько новых каналов, по которым данные уходят из периметра.
Когда ИИ-система попадает под режим
Режим обработки включается не фактом использования модели, а попаданием данных в конкретные точки системы. Таких точек обычно четыре: запрос пользователя (промпт), контекст RAG (в индекс попадают документы с данными), обучающая выборка при дообучении и журналы, куда записываются запросы и ответы.
Каждая точка — самостоятельный канал, и закрывать их надо по отдельности: обезличили промпт, но забыли лог — режим всё равно соблюдается не полностью.
Отдельно стоят специальные категории данных — здоровье, судимость, убеждения. Работа с ними через ИИ-систему требует отдельной проработки с юристом: по общему правилу режим для них жёстче, и типовые схемы «обезличили и отправили» здесь обычно недостаточны.
Что считается персональными данными
Не только очевидное. Персональными являются любые сведения, относящиеся к определённому или определяемому человеку. Второе слово ключевое: набор косвенных признаков, по которым человека можно вычислить, тоже подпадает под требования.
Практически это означает, что расшифровка звонка, переписка с клиентом, текст обращения и комментарий менеджера — данные, даже если фамилия в них не названа прямо.
Три вопроса до начала разработки
На каком основании обрабатываем. Согласие, договор, закон — основание должно быть названо и зафиксировано, а не подразумеваться.
Кому передаём. Облачная модель — это конкретное лицо, и его надо указывать в документах об обработке. Здесь же вопрос трансграничной передачи, если сервис зарубежный.
Что сказано в политике. Если политика обработки не упоминает передачу данных для автоматизированной обработки, а фактически она идёт, это расхождение между документами и практикой.
Локализация и место обработки
Вопрос «где физически обрабатывается и хранится» решается до выбора сервиса. При сборе персональных данных граждан России через интернет по общему правилу их первичное хранение фиксируется на территории РФ; что именно это означает для вашей схемы — облачный API, гибрид, локальный контур — требует оценки юриста.
Для зарубежного сервиса добавляется трансграничная передача со своими условиями. Часть провайдеров предлагает региональные эндпоинты и заверения о месте обработки — эти заверения фиксируются в договоре, а не в маркетинговых материалах.
Условия о неиспользовании ваших запросов для обучения провайдера и о сроках их хранения — отдельная тема, разобранная в статье про утечку данных через нейросеть.
Согласия и их границы
Согласие на обработку само по себе не покрывает все схемы. Если данные фактически передаются внешнему сервису или используются для дообучения модели, это должно быть видно из текста согласия; общая формулировка «обработка в моих интересах» такие действия по общему правилу не описывает.
Практическое следствие для ИИ-проектов: отзыв согласия затрагивает не только операционную базу, но и всё, что из неё успели накопить — журналы обращений, датасеты, сохранённые диалоги. Поэтому срок жизни этих артефактов задаётся заранее, а не выясняется при первом отзыве.
Журналирование обращений
Журнал — обязательный элемент ИИ-системы, работающей с данными: без него невозможен разбор инцидентов и доказательство того, кто и что передавал. Но журнал сам становится объектом с персональными данными, поэтому его проектируют вместе с системой, а не добавляют потом.
Минимальный состав записи: время, идентификатор пользователя, целевая система, факт передачи персональных данных и их категория — сами значения в журнал не пишут. Срок хранения журнала задаётся явно; доступ — по роли, а не «всем разработчикам». Подробнее о том, что мониторят в работающей системе, — в статье о мониторинге ИИ-систем.
Что снижает риск
Обезличивание перед передачей. Самая действенная мера: если во внешний сервис не уходит ничего, позволяющего определить человека, вопрос снимается по существу. Техники — в карточке «Обезличивание данных».
Локальная модель. Данные не покидают периметр — это довод, который часто перевешивает разницу в качестве моделей.
Ограничение того, что вообще попадает в запрос. Часто в модель передают документ целиком, хотя для задачи нужны два поля.
Ограничение срока хранения. Журналы обращений содержат те же данные, и про них забывают.
Порядок мер по эффекту на затраты: минимизация состава запроса почти бесплатна, обезличивание стоит разработки конвейера, локальная модель — инфраструктуры и сопровождения. Начинать стоит с первой: часто больше половины чувствительных полей в запрос попадает просто «по привычке».
Оговорка
Правовая рамка в этой области меняется. Требования к обработке, штрафы и правила трансграничной передачи пересматривались в последние годы неоднократно, и по состоянию на середину 2026 года часть норм применяется недавно. Перед запуском стоит сверяться с действующей редакцией, а не с описанием в статьях — включая эту карточку.
И отдельно: это справочное описание, а не юридическая консультация. Решения по конкретному проекту принимаются с юристом.
Что проверить в существующей системе
Если ИИ-решение уже работает, разбор стоит начать с четырёх вопросов, ответы на которые обычно неизвестны.
Что фактически уходит в запросе. Не что предполагалось передавать, а что передаётся: часто в модель отправляют документ целиком, хотя нужны два поля. Проверяется трассировкой реального трафика, а не чтением документации.
Где оседают запросы и ответы. Логи приложения, система мониторинга, отладочные файлы, история диалогов в интерфейсе.
Сколько это хранится и кто имеет доступ. Срок обычно не задан, доступ — у всех разработчиков.
Что написано в документах об обработке и совпадает ли это с фактической схемой.
Локальная модель как решение
Размещение модели внутри периметра снимает вопрос передачи третьему лицу, но не отменяет остальных требований: основание обработки, срок хранения, разграничение доступа и защита самой системы остаются.
Частая ошибка — считать, что локальный запуск закрывает тему целиком. Он закрывает один вопрос из нескольких; индекс с документами и журналы внутри периметра остаются объектами режима, и доступ к ним строится по общим правилам — см. «Разграничение доступа».
Частые вопросы
Можно ли отправлять данные клиентов в облачную нейросеть?
Это передача данных третьему лицу, и она требует основания, отражения в документах об обработке и, если сервис зарубежный, соблюдения правил трансграничной передачи. Проще и безопаснее обезличивать данные перед передачей или применять локальную модель.
Считается ли текст обращения персональными данными?
Как правило да, если по нему можно определить человека — прямо или по совокупности признаков. Отсутствие фамилии не делает текст обезличенным: телефон, адрес, детали заказа и обстоятельства вместе позволяют идентифицировать.
Достаточно ли согласия на обработку в общей форме?
Зависит от того, что в нём написано. Если фактически данные передаются во внешний сервис, а в документах это не отражено, расхождение между практикой и документами остаётся. Формулировки стоит проверять с юристом под конкретную схему обработки.
Меняет ли что-то то, что ИИ используется только внутренними сотрудниками?
Нет, режим обработки не зависит от того, кто вводит данные. Сотрудник, вставляющий таблицу с клиентами в облачный чат-бот, создаёт ту же передачу третьему лицу, что и клиентская интеграция. Внутренние инструменты закрывают корпоративной политикой использования ИИ, а не умолчанием.
Что делать с логами и датасетами, которые уже накопились?
Оценить их состав: есть ли там персональные данные, кто имеет доступ, есть ли основание хранения. Дальше фиксируется срок хранения и доступ по ролям; датасеты с данными, попавшими туда без достаточного основания, обезличивают или выводят из оборота. Ретроспективно это дешевле сделать самому, чем в рамках разбора инцидента.
Нужно ли отдельно оформлять отношения с провайдером модели?
По общему правилу да: передача данных внешнему сервису оформляется документально — как поручение обработки или в иной предусмотренной форме, с описанием состава данных, целей и сроков. Форму и объём документа определяет юрист; инженеру важно одно — договор должен покрывать фактическую схему: все точки, куда уходят данные, включая журналы и кэши провайдера.