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

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

Почему персональные данные в нейросетях стали рабочим риском

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

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

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

Персональные данные и конфиденциальная информация, это не одно и то же

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

Это важный нюанс, потому что многие успокаиваются фразой «там нет паспортов и телефонов». Но если в запрос ушли неопубликованные акции, внутренние комментарии руководителя или схема настройки рекламных кампаний, проблема никуда не девается. Для анализа причины отказа клиента нейросети обычно не нужны ни его контакты, ни ваша фактическая маржа по сделке.

Какие данные можно отправлять в ИИ-сервисы, а какие нельзя

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

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

Если сомневаетесь, считайте данные более чувствительными, чем кажется на первый взгляд. Город, редкая должность, сумма контракта и дата отгрузки по отдельности могут выглядеть безобидно. Вместе они часто указывают на конкретного человека или компанию гораздо точнее, чем одно поле «имя».

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

Где сотрудники чаще всего отправляют лишнее в нейросети

Продажи и клиентский сервис

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

Ещё один скрытый источник проблем, скриншоты CRM и мессенджеров. На скриншоте может быть имя клиента, номера внутренних заявок, сумма счёта, соседние вкладки, фото профиля и даже адрес в строке браузера. С точки зрения безопасности такой снимок обычно хуже, чем аккуратно очищенный текстовый фрагмент.

Маркетинг и аналитика

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

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

HR, бухгалтерия и управление

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

У руководителей частая ошибка другая, отправлять протоколы встреч, финансовые сводки и договоры без сокращения. Там могут быть и персональные данные сотрудников, и коммерчески чувствительная информация. Даже если задача кажется безобидной, например «сделай короткий итог совещания», отправлять нужно не весь документ, а подготовленную выдержку.

Техподдержка и разработка

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

Как обезличивать персональные данные перед запросом

Обезличивание работает только тогда, когда после очистки внешний сервис не может восстановить конкретного человека по набору признаков. Удалить одно ФИО недостаточно. Если в тексте остались телефон, редкая должность, точная дата сделки и номер договора, человек всё ещё читается.

Удобно применять простой пятишаговый фильтр перед каждым запросом.

• Удалите прямые идентификаторы: ФИО, телефон, почту, адрес, паспортные данные, ссылки на профили, реквизиты и подписи.
• Замените внутренние номера на условные метки, например «Клиент-12», «Сделка-3», «Менеджер-2».
• Округлите или обобщите детали, если они не нужны для ответа: «в начале мая» вместо точной даты, «бюджет 300-500 тыс. руб.» вместо суммы до рубля.
• Оставьте только фрагмент, который действительно нужен. Для ответа на претензию не требуется весь двухмесячный диалог.
• Проверьте вложения и имена файлов. Файл «Иванов_договор_12-03.pdf» уже сам по себе раскрывает лишнее.

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

Не забывайте про скрытые данные в файлах. Текстовый документ может содержать правки, комментарии и автора файла, таблица может хранить скрытые листы, а изображение иногда несёт метаданные о времени и устройстве съёмки. Перед отправкой лучше копировать в новый чистый документ только нужный фрагмент, а не пересылать исходник целиком.

Плохо: «Проанализируй переписку с Иваном Петровым, телефон 9ХХХХХХХХХ, заказ 58124, он требует вернуть 184 700 руб. по договору от 12 марта». Хорошо: «Проанализируй спор с клиентом из корпоративного сегмента по поставке оборудования. Причина конфликта, задержка запуска и разночтение в условиях возврата. Подготовь спокойный ответ без признания вины».

Мы в RDMN обычно советуем сделать для команды короткий шаблон запроса на одну страницу. Не «как красиво общаться с ИИ», а что именно удалить перед отправкой, какие формулировки использовать и какие вложения запрещены. Такой регламент экономит больше времени, чем потом разбирать случайные ошибки.

Когда отправка данных в ИИ-сервис вообще допустима

С практической точки зрения безопасный сценарий начинается не с фразы «я быстро спрошу у нейросети», а с решения компании. У вас должен быть перечень задач, для которых ИИ реально нужен, и перечень данных, которые для этих задач допустимы. Всё остальное лучше считать запрещённым по умолчанию.

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

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

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

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

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

Как выбрать ИИ-сервис и настроить безопасный контур

Для бизнеса вопрос звучит не «какая нейросеть отвечает умнее», а «каким сервисом можно пользоваться без постоянного риска». Перед запуском стоит пройти короткую проверку поставщика и режима работы.

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

Хорошая практика, сначала сделать тестовый запуск на вымышленных или синтетических данных. За 1-2 недели можно понять, действительно ли нейросеть решает задачу, какие поля ей нужны, что мешает качеству ответа и где сотрудники пытаются отправлять лишнее. После такого теста правила становятся конкретными, а не формальными.

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

По рынку простой внутренний инструмент такого типа обычно занимает 2-6 недель. Бюджет в типичном проекте начинается примерно от 150-500 тыс. руб. если нужны роли, журнал действий и базовые интеграции. Сложные сценарии с CRM, телефонией и личными кабинетами оцениваются отдельно.

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

Типичные ошибки

• Считать, что риск связан только с фамилией и телефоном. На практике человека нередко выдают комбинации признаков: должность, дата сделки, город, сумма, номер заказа и редкая проблема.
• Ограничиваться замазыванием пары полей на скриншоте. Остальные данные часто остаются в соседних блоках интерфейса, в названии файла или в метаданных документа.
• Использовать личные аккаунты сотрудников. Когда человек увольняется, компания теряет контроль над историей запросов, файлами и доступами.
• Давать нейросервису слишком широкий доступ, например ко всей почте или всей CRM. Для одной узкой задачи такой доступ почти всегда избыточен.
• Надеяться на кнопку удаления чата. У разных сервисов могут оставаться резервные копии, журналы и служебные записи, а пользователь об этом не узнает из интерфейса.
• Не разделять правила по типам задач. Одно дело, придумать структуру статьи по публичным материалам. Совсем другое, анализировать претензии клиентов, резюме и протоколы встреч.
• Запускать ИИ-функции на сайте без проектирования маршрута данных. Потом выясняется, что чат собирает телефон, почту и текст обращения там, где можно было обойтись двумя нейтральными полями.

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

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

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

Можно ли отправить договор в нейросеть, чтобы она нашла риски?

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

Можно ли расшифровывать звонки клиентов через ИИ-сервис?

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

Если удалить диалог в интерфейсе, данные точно исчезнут?

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

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

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

Можно ли дать нейросети доступ к почте, календарю или CRM?

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

Безопасно ли пользоваться бесплатными версиями ИИ-сервисов?

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

Что делать: короткий план

1. Составьте список задач, где команда уже использует нейросети: звонки, переписки, договоры, резюме, аналитика, тексты.
2. Разделите данные на четыре уровня: запрещено, только после обезличивания, допустимо по утверждённому сценарию, обычно можно.
3. Запретите личные аккаунты и спонтанные загрузки файлов без правил.
4. Утвердите 1-2 сервиса для компании и проверьте их настройки хранения, обучения модели и удаления истории.
5. Подготовьте короткий регламент: что удалять из текста, как называть файлы, какие вложения запрещены, кто согласует спорные случаи.
6. Для повторяющихся задач сделайте промежуточный контур, хотя бы в виде внутренней формы, а для более зрелого процесса рассмотрите отдельное веб-приложение.
7. Проведите короткий инструктаж для отделов. Продажи, HR, маркетинг и поддержка ошибаются по-разному, им нужны разные примеры.
8. Раз в 1-2 месяца проверяйте несколько реальных запросов команды и смотрите, не возвращаются ли в них лишние данные.

Если вы только планируете запуск ИИ-функций на сайте, в личном кабинете или во внутреннем инструменте, безопасный маршрут данных лучше продумать до разработки. Тогда нейросеть действительно ускорит работу, а не добавит новый источник проблем.