ИИ и персональные данные: как внедрять по 152-ФЗ и не нарваться

152-ФЗ не запрещает использовать ИИ в бизнесе. Он запрещает бесконтрольно передавать персональные данные третьим лицам без согласия и без учёта. Разница принципиальная: в 9 из 10 наших проектов модель вообще не должна видеть ФИО, телефон и паспорт — ей нужен смысл разговора, а не личность собеседника. Убираете идентификаторы на входе, оставляете первичную базу в российском контуре, оформляете три документа — и внедрение перестаёт быть юридическим риском. Ниже — что именно считается персональными данными в контексте ИИ, где проходит граница и как выглядит рабочая архитектура.

Что 152-ФЗ реально требует от компании, которая внедряет ИИ

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

Отсюда все практические требования. У обработки должно быть законное основание — согласие субъекта или исполнение договора. Цели должны быть заявлены заранее и совпадать с фактическими. Первичный сбор и хранение — на территории РФ. Передача обработчику оформляется поручением. Срок хранения ограничен и должен быть прописан.

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

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

Какие данные в ИИ-проектах на самом деле персональные

Персональные данные — любая информация, относящаяся к прямо или косвенно определённому человеку. Формулировка широкая намеренно. В ИИ-проектах она ловит вещи, которые команды обычно не считают чувствительными.

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

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

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

| | | |

|---|---|---|

| Данные | Статус по 152-ФЗ | Что делать перед подачей в модель |

| Запись звонка, аудио | ПДн, возможна биометрия | Хранить в РФ, в модель отдавать транскрипт без ФИО и номера |

| Транскрипт разговора | ПДн | Маскировать имена, телефоны, адреса, номера карт |

| Карточка клиента в CRM | ПДн | Передавать только нужные поля, идентификатор заменять на хеш |

| Данные о здоровье, долгах | Специальная категория | Отдельное письменное согласие, обработка только в РФ-контуре |

| Обезличенная агрегированная статистика | Не ПДн, если восстановление невозможно | Проверить, не вычисляется ли человек по комбинации признаков |

Где проходит граница: локализация и трансграничная передача

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

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

Но есть путь короче, и мы почти всегда идём им. Модели не нужны идентификаторы. Если перед вызовом внешнего API вы заменяете ФИО на «Клиент», телефон на плейсхолдер, а связку «плейсхолдер — реальное значение» держите в российской базе, то наружу уходит текст без персональных данных. Вопрос границы закрывается технически, а не бумажно.

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

Три документа, без которых нельзя запускать

Юридическая часть меньше, чем принято думать. Для типового внедрения нужны три вещи, и они делаются один раз.

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

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

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

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

• Политика обработки ПДн — обновить перечень целей под ИИ-сценарий
• Форма согласия — добавить передачу третьим лицам и автоматизированную обработку
• Поручение на обработку — с облаком, с подрядчиком, с каждым сервисом в цепочке
• Уведомление в РКН — при новых целях и категориях данных
• Приказ о перечне лиц с доступом и срок хранения по каждому массиву

Архитектура, которая не создаёт проблем

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

Сырые данные — записи, транскрипты, карточки — лежат в российском облаке и оттуда не уезжают. Доступ по ролям, а не «у всех логин от админки». Между базой и моделью стоит слой маскирования: отдельный сервис находит и заменяет ФИО, телефоны, адреса, номера документов и карт на плейсхолдеры. Обратная подстановка — уже после ответа модели, внутри периметра.

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

Срок хранения и автоудаление. Данные не должны лежать вечно «на всякий случай». Определяете срок под цель, ставите задание на удаление, и это работает само. Это самая частая дыра при аудите: политика говорит «90 дней», а в базе записи трёхлетней давности.

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

Пять ошибок, которые дороже всего обходятся

Ошибки повторяются от проекта к проекту, и почти все появляются на стадии «давайте быстро попробуем».

Самая дорогая — пилот на боевых данных без подготовки. Команда выгружает пять тысяч реальных диалогов в чужой сервис, чтобы «просто посмотреть, справится ли модель». Данные уже переданы. Обратно их не вернуть, а факт передачи зафиксирован в логах чужого сервиса.

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

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

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

Как это встроить в проект внедрения без задержки сроков

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

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

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

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

Отраслевая специфика: где требования жёстче

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

Медицина и стоматология — врачебная тайна поверх 152-ФЗ. Сведения о диагнозе должны оставаться только в сервисах, для которых есть прямое основание. Голосовой ассистент, записывающий на приём, работает с именем и временем, но состояние пациента обсуждать не должен.

Юридическая практика и банкротство — адвокатская тайна и чувствительные обстоятельства клиента. В нашем банкротном проекте, где конверсия из заявки в договор выросла с 15% до 35%, а выручка — на 3 млн ₽ в месяц, вся работа с транскриптами велась внутри российского контура именно из-за состава данных.

Финансы и страхование — банковская тайна и требования отраслевых регуляторов поверх общего закона. HR и рекрутинг — данные кандидатов идут на другом основании, чем данные сотрудников, и хранить резюме бессрочно нельзя. Автоматический отсев кандидатов моделью — ровно тот случай, когда финальное решение должен принимать человек.

Онлайн-образование и услуги — самый мягкий профиль. В проекте с онлайн-школой, где ИИ закрывал 86% вопросов учеников, а продажи выросли в 2,5 раза, ассистент работал с учебным контентом и расписанием, а к платёжным данным доступа не имел вообще. Это и есть правильная граница: модель видит ровно столько, сколько нужно для задачи.

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

Можно ли по 152-ФЗ использовать зарубежные модели — GPT, Claude, Gemini?

Прямого запрета нет, но есть два условия. Первое: первичная база с персональными данными россиян должна физически находиться в РФ — это требование локализации. Второе: трансграничная передача в страну без адекватной защиты требует отдельного уведомления в Роскомнадзор и, как правило, отдельного письменного согласия субъекта. На практике проще не передавать: обезличивайте текст перед вызовом внешней модели, а связку идентификаторов храните у себя в российском контуре. Тогда наружу уходит текст без персональных данных, и вопрос трансграничной передачи снимается.

Что грозит, если внедрить ИИ и просто ничего не оформлять?

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

Нужно ли собирать новое согласие, если ИИ работает с данными, которые уже есть в CRM?

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

ИИ-скоринг лидов — это автоматизированное решение, которое нужно объяснять клиенту?

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

Обязательно ли хранить всё в российском облаке, если мы не обучаем модель?

Обучение здесь ни при чём. Требование локализации касается сбора и первичного хранения — база с персональными данными россиян должна быть в РФ независимо от того, что вы с ними потом делаете. Наша типовая схема: CRM, база транскриптов, хранилище связок и логи — в российском облаке; наружу — только обезличенные фрагменты для инференса, если внешняя модель вообще нужна.

Сколько времени и денег добавляет соответствие 152-ФЗ к проекту внедрения?

По нашим проектам — 1-2 недели работы, идущие параллельно с разработкой, и это в основном инженерная часть: слой маскирования, логирование, разграничение доступа, настройка сроков хранения. Юридический пакет — политика, согласия, поручение обработки, уведомление РКН — делается один раз и переиспользуется на следующих сценариях. Отдельной строкой в смете это обычно не выделяется, потому что заложено в архитектуру. Оценки по конкретному сценарию есть на странице с ценами.

---

152-ФЗ не запрещает ИИ. Он запрещает бесконтрольную передачу персональных данных без основания и без учёта. На старте нужны три вещи: понять, какие данные реально уходят в модель, отрезать лишнее на входе, оформить бумаги под то, что осталось. Дальше техника: российское облако для сырых данных, обезличивание перед вызовом модели, логи всех обращений, срок хранения.

По нашей практике эта часть занимает 1-2 недели и делается параллельно с самой разработкой, а не вместо неё. Дороже всего обходится обратный порядок: сначала запустили пилот на чужом API с реальными ФИО и телефонами, потом пришли к юристам и переделали архитектуру с нуля.

Если вы сейчас на стадии «хотим ИИ, но боимся 152-ФЗ» — самый дешёвый следующий шаг это не консультация юриста, а карта данных. Выпишите на одном листе, какие поля клиентов трогает будущий сценарий. В 8 случаях из 10 после этого упражнения становится видно, что модели нужны 2-3 поля из 20, и вся проблема схлопывается до обезличивания на входе.

Внутренние ссылки:

• внедрение ИИ в бизнес: этапы и что входит
• сколько стоит внедрение ИИ
• ИИ для отдела продаж
• ИИ для клиники
• речевая аналитика или прослушка руками