директор и машина · право и риски · запись № 014 · 17 августа 2026 · Давид Герштейн

Персональные данные и нейросети: что можно отправлять в ИИ, а что нельзя

Аудит одной компании нашёл JavaScript-файл на публичном сервере с кошельками, данными менеджеров и информацией о клиентах. Файл индексировался поисковиками. Любой мог найти его через обычный поисковый запрос. Персональные данные и нейросети — тема, которая всплывает в подобных аудитах регулярно, потому что бизнес спешит автоматизировать процессы и забывает спросить: а куда уходят данные, которые мы туда заливаем.

Я видел это не один раз. Разница только в форме утечки — где-то файл в открытом доступе, где-то таблица с доступом «у кого есть ссылка», где-то вебхук без защиты. Суть одна: данные клиентов оказываются там, где их никто не должен видеть, и никто в компании этого не замечает, пока не проведёт аудит.

Персональные данные и нейросети: где именно риск

Когда сотрудник копирует переписку с клиентом в ChatGPT, чтобы «пусть ИИ ответит красивее» — данные уходят на серверы сервиса, который физически находится за пределами страны. Это не абстракция. В одном случае юрист специально проверял договоры клиентов: получение согласия на трансграничную передачу данных заняло 2–3 месяца, потому что документы обрабатывались на серверах в США. Без этого согласия компания нарушает закон, даже если ИИ используется из лучших побуждений.

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

152-ФЗ и ИИ: что требует закон

В одной компании из группы юрист провёл проверку: все юрлица группы зарегистрированы как операторы персональных данных в РКН. Это база, без которой любая автоматизация с персональными данными незаконна с самого начала. Но регистрация — только первый шаг. Дальше идёт вопрос трансграничной передачи: если данные обрабатываются на серверах за границей (а многие ИИ-сервисы работают именно так), нужно согласие клиента именно на такую передачу, а не общее согласие на обработку персональных данных.

Ситуация усложняется тем, что регулирование быстро меняется. На одной из встреч прозвучала цитата, которая многое объясняет: «В Европе есть законопроект о запрете работы с персональными данными через ИИ без спецразрешения надзорного органа. В Америке разглашение персональной информации с расовыми, этническими признаками — уголовная статья». Это не абстрактная угроза для международных корпораций — это применимо к любой компании, которая работает с иностранными клиентами или использует зарубежные ИИ-сервисы.

Что нельзя отправлять в нейросеть на практике

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

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

Отдельная история — таблицы с доступом «у кого есть ссылка». В одной компании собственница попросила провести аудит всех таблиц и удалить посторонние адреса из совместных документов. Оказалось, что множество таблиц с финансовой информацией и данными клиентов были открыты для всех, у кого есть ссылка — включая тех, кто уже не работает в компании. Это не проблема ИИ напрямую, но именно из таких таблиц данные чаще всего попадают в промпты — сотрудник копирует строку в чат с нейросетью, не задумываясь, что таблица вообще не должна была быть открытой.

Доступы сотрудников: где ломается контроль

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

С доступами к ИИ-инструментам та же логика, только риски выше. Если промпты и API-токены привязаны к личной учётке сотрудника, компания теряет контроль в момент его увольнения или конфликта. Хорошая практика, которую я видел в одной команде: чувствительные ссылки доступа хранятся только в коде, локальные файлы не передаются во внешние каналы, доступ ограничивается минимально необходимыми правами. Это не бюрократия ради бюрократии — это единственный способ не зависеть от одного человека и одной учётной записи.

Похожий принцип звучал в другой цитате: «Именно поэтому мы работаем в коде. Потому что единственный способ поставить работу, если вдруг случится какая-то блокировка — это работать в коде, чтобы все файлы были у тебя и ты не зависела от доступа к учётной записи». Применительно к ИИ это значит: не собирайте всю автоматизацию вокруг личного кабинета одного сотрудника в ChatGPT или другом сервисе.

Правило «один человек — одна таблица»

Этот же принцип разграничения прав работает и в ИИ: «один человек, одна таблица» — правило, предотвращающее конфликты между автоматическим и ручным редактированием. Когда несколько сотрудников и бот одновременно правят один документ, данные путаются, а отследить, кто и что туда вписал (и кто передал это в промпт нейросети), становится невозможно.