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

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

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Ваши сотрудники прямо сейчас вставляют данные клиентов в нейросети. Не со зла — просто им так удобнее, а правил вы не давали.

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

Разбираю, что можно и нельзя отправлять в ИИ, и как объяснить это команде так, чтобы правило соблюдалось.

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

Это тема, которая всплывает в таких аудитах регулярно, потому что бизнес спешит автоматизировать процессы и не задаёт себе простой вопрос: куда уходят данные, которые в него заливают. Ревизия доступов на компанию среднего размера с несколькими юрлицами — это, по грубой оценке, 15–20 часов работы одного специалиста. Цена утечки, которую находит конкурент или регулятор раньше вас, не считается в часах.

Где именно ваш риск

Не в том, что «ИИ украдёт данные». В том, что ваш сотрудник вставит в публичный чат таблицу с клиентами, потому что так быстрее.

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

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

Как проверить свой процесс перед подключением ИИ

Четыре вопроса, на которые вам нужно ответить до того, как машина увидит первые данные.

Всё это можно повторить со своей командой за одну-две недели. Вот последовательность, которую я использую сам.

1. Инвентаризация. Составить список всех мест, откуда сотрудники берут данные для ИИ: CRM (Bitrix24, amoCRM), Google Таблицы, мессенджеры, файлы на сервере. Отдельно — список сервисов ИИ, к которым есть доступ, и через чьи учётные записи они подключены.
2. Классификация данных. Разметить, какие поля в этих источниках относятся к персональным данным: ФИО, телефон, адрес, паспорт, платёжные реквизиты, данные о здоровье и происхождении. Это делает юрист или ответственный за комплаенс, не разработчик «на глаз».
3. Фильтр перед моделью. Между источником данных и запросом к нейросети ставится промежуточный шаг — дешёвая модель или скрипт, который проверяет текст на наличие ПД и либо маскирует его, либо блокирует отправку. Это и есть техническая часть, разобранная в следующем разделе.
4. Согласия и договоры. Проверить, есть ли в договорах с клиентами формулировка о согласии на трансграничную передачу данных — если ИИ-сервис зарубежный. Без неё юридически рискует не разработчик, а компания-оператор ПД.
5. Контроль доступов. Развести права по принципу «один человек — одна таблица», токены и вебхуки хранить не в общих файлах, а в переменных окружения кода. Раз в квартал — повторный аудит, особенно после расширения команды.

ИИ-связка: фильтр перед отправкой

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

Конвейер простой: данные лежат в Google Таблице (или приходят вебхуком из Bitrix24) → перед тем как текст уходит в основную модель для анализа или генерации ответа, он проходит через дешёвую модель-классификатор → если найдены персональные данные, текст маскируется или блокируется → результат и лог решения пишутся в отдельный лист, ответственному падает уведомление в Telegram.

Схема конвейера текстом: Google Sheets / Bitrix24-вебхук → Apps Script (триггер по расписанию) → дешёвая модель-классификатор → маскирование/блокировка → лист «Проверено» + алерт в Telegram при high-риске → только после этого текст может уйти в основную (дорогую) модель для содержательной работы.

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

Структура входных данных, которые Apps Script отправляет в модель (пример строки из Google Таблицы с заявками клиентов):

{
  "doc_id": "row_57",
  "source": "google_sheets:zayavki",
  "text": "Иванов И.И., тел. +7900..., просит справку по адресу г. Москва, ул. ..., оплата картой 4276..."
}

Промпт для дешёвой модели-классификатора (system + user, отправляется через Apps Script UrlFetchApp на эндпоинт модели):

Ты — фильтр персональных данных. На вход получаешь JSON с полем text.
Определи, содержит ли текст персональные данные следующих категорий:
ФИО, телефон, адрес, паспортные данные, платёжные реквизиты,
данные о здоровье, расе, религии, этнической принадлежности.

Верни строго JSON без пояснений:
{
  "doc_id": "<из входных данных>",
  "contains_pd": true/false,
  "categories": ["phone","address", ...],
  "risk_level": "low|medium|high",
  "masked_text": "<текст с заменой ПД на ***>",
  "action": "pass|mask|block_before_ai"
}

Правила:
- Если найдены паспортные данные, платёжные реквизиты или данные о здоровье/расе — risk_level = high, action = block_before_ai.
- Если найдены только ФИО/телефон — risk_level = medium, action = mask.
- Если ПД не найдены — risk_level = low, action = pass.

Пример ответа модели на строку выше:

{
  "doc_id": "row_57",
  "contains_pd": true,
  "categories": ["fio", "phone", "address", "payment"],
  "risk_level": "high",
  "masked_text": "*** тел. ***, просит справку по адресу ***, оплата картой ***",
  "action": "block_before_ai"
}

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

Как это выглядит в самом листе «Проверено», куда Apps Script пишет результат каждой проверки:

Обе цифры — оценка по потоку документов условной компании, расчёт — в разделе «Экономика».

Инженерная обвязка

• Где крутится. Google Apps Script с триггером по времени (каждые 10–15 минут) читает новые строки таблицы или принимает вебхук от Bitrix24/amoCRM.
• Как перезапускается. Триггер идемпотентен: если модель не ответила или вернула невалидный JSON, строка помечается статусом «retry» и берётся в следующий проход. Без ручного вмешательства.
• Как сообщает об ошибке. Ошибки API (таймаут, невалидный ответ) пишутся в отдельный лист «Errors» с timestamp и текстом ошибки; при risk_level = high и при трёх подряд ошибках — уведомление ответственному в Telegram-бота.
• Учёт расходов. Каждый вызов дешёвой модели логируется отдельной строкой — это тот же принцип, что и учёт SMS-верификаций: мелкие операционные расходы должны быть видимыми, а не растворяться в общих счетах за ИИ.

Персональные данные и ИИ: что требует 152-ФЗ

Без юридических формулировок: что именно вам нужно иметь, чтобы спать спокойно.

Коротко и по делу — без юридического языка, но с указанием, где вам стоит привлечь юриста.

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

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

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

Ваш ориентир: если по данным можно узнать конкретного человека — они не идут в публичный чат ни в каком виде.

Распечатайте его и повесьте рядом с командой. Это дешевле любого штрафа.

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

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

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

На диаграмме — распределение зафиксированных случаев по типам утечки в наших аудитах, не статистика по рынку.

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

Ваша машина — такой же пользователь, как человек, и учитывать её доступы нужно так же.

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

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

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

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

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

Экономика: что стоит фильтр и что он даёт

Сравнивайте не с нулём, а с размером штрафа за утечку: с 2026 года эта арифметика стала однозначной.

Настройка фильтра занимает 12–18 часов работы разработчика и юриста, эксплуатация — 350–1 150 ₽ в месяц, а экономия по сравнению с ручной проверкой того же потока документов — около 28 000 ₽ в месяц (оценка).

Возьмём условную сервисную компанию из легенды: отдел продаж 8 менеджеров, оборот ~9 млн ₽ в месяц, средний чек ~180 000 ₽ — это около 50 закрытых сделок в месяц. При таком масштабе поток входящих обращений с персональными данными (заявки, переписки, документы) — порядка 40 штук в день на весь отдел. Это и есть базовый поток, на который дальше считается экономика.

Внедрение: настройка Apps Script-фильтра с классификатором и подключением к таблице/вебхуку — 8–12 часов работы разработчика. Дополнительно нужен юрист на проверку договоров на согласия — 4–6 часов. Итого разовые затраты на запуск — 12–18 часов специалистов среднего уровня.

Эксплуатация фильтра считается по формуле «цена одного обращения к модели × число документов в день × 30 = расходы в месяц». При потоке 40 документов в день это 1 200 обращений в месяц. Цена короткого запроса к недорогой модели-классификатору — ориентировочно на два порядка меньше стоимости одной SMS-верификации, точная цифра зависит от длины текста и провайдера; совокупно это укладывается в 350–1 150 ₽ в месяц.

Теперь — сколько стоит делать ту же проверку руками, без фильтра. Если человек тратит на ручную проверку одного документа около 2 минут, то при потоке 40 документов в день это 80 минут, или 1,3 часа в день, а за 22 рабочих дня — около 29 часов в месяц. По ставке ~1 000 ₽/час менеджера это 29 000 ₽ в месяц — потери рабочего времени на рутину, которую при этом человек всё равно частично пропускает.

Разница между ~29 000 ₽ ручной проверки и 350–1 150 ₽ автоматического фильтра — это и есть заявленные 25–80 раз. Разовые затраты на внедрение (12–18 часов специалистов) окупаются меньше чем за месяц эксплуатации.

Эффект фильтра ПД мы считаем по двум составляющим: снятый юридический риск нарушения 152-ФЗ (в рублях напрямую не выражается) и экономия времени на ручной проверке документов, посчитанная выше. Ускорение продаж, конверсию сделок и прочие метрики отдела фильтр не трогает — это не его эффект, и смешивать его с другими ИИ-инициативами компании не стоит: если параллельно внедряются боты и распознавание документов, их экономику считайте отдельно — я разбирал это в статье о том, сколько реально стоит ИИ в месяц. Отдельная статья экономики — ревизия доступов на компанию с несколькими юрлицами: вручную, по грубой оценке, это несколько десятков часов — по 4 часа на юрлицо, если искать все таблицы, вебхуки и токены без структуры. С чек-листом из этой статьи то же самое укладывается в 15–20 часов — время короче примерно вдвое.

На диаграмме — сравнение времени на ревизию доступов при нескольких юрлицах: без чек-листа и с ним.

Время на ревизию доступов при нескольких юрлицах: без чек-листа и с чек-листом, часы специалиста.

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

С чего начать вам в понедельник

Регламент на одну страницу — и объявить его открыто.

• Выгрузить список всех ИИ-сервисов, к которым подключены сотрудники, и проверить, через чьи учётные записи — личные или служебные.
• Проверить все Google Таблицы и документы с доступом «по ссылке» — сменить на «только для приглашённых», удалить посторонние адреса.
• Найти все вебхуки и API-токены в коде и конфигурациях — перенести из открытых файлов в переменные окружения.
• Проверить договоры с клиентами на формулировку о согласии на трансграничную передачу данных, если используются зарубежные ИИ-сервисы.
• Поставить между источником данных и моделью промежуточный фильтр-классификатор ПД — хотя бы в виде скрипта на 20–30 строк, даже без дорогой модели на входе.
• Убедиться, что все юрлица компании зарегистрированы как операторы персональных данных в РКН.

Что сделать вам на этой неделе: напишите короткий регламент на одну страницу — что запрещено всегда, чем можно пользоваться, кто отвечает за результат. И объявите его открыто, а не рассылкой в никуда.

Полный разбор правовой стороны и рабочие формулировки — в бесплатном курсе для руководителей.

Ваш минимум на эту неделю: одна страница правил и открытое объявление команде. Всё остальное — фильтры, контуры, договоры об обработке — можно достроить потом, но без правил вся эта техника защищает вас только на бумаге.

У нас правило обезличивания появилось после того, как я сам чуть не отправил в чат таблицу с контактами клиентов — остановился на полсекунды. С тех пор мы не полагаемся на внимательность: данные обезличиваются до отправки, автоматически.

Частые вопросы

Можно ли отправлять данные клиентов в ChatGPT?

Нет, если это персональные данные без обезличивания и без согласия клиента на трансграничную передачу — обработка на зарубежных серверах требует юридического основания по 152-ФЗ.

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

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

Как ограничить доступ сотрудников к данным при работе с ИИ?

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

Это то же самое, что согласие на обработку персональных данных?

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

#ии и нейросети #контроль и надёжность #деньги