Команда хочет быстрее разбирать обращения или готовить персональные предложения и подключает AI-сервис к CRM. Для пилота кажется удобным передать полный профиль: заказы, контакты, переписку и заметки менеджера. Однако значительная часть этих данных может вообще не влиять на ответ модели.

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

Начните с задачи и минимального входа

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

OWASP относит раскрытие чувствительной информации к самостоятельным рискам приложений на языковых моделях. Ограничения нужно строить вокруг доступа и данных, а не полагаться на инструкцию модели «никому ничего не показывай».[1]

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

Нарисуйте весь маршрут, включая журналы

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

Вопрос поставщикуКакое подтверждение нужно
Что сохраняется после запроса?Перечень данных и сроков для выбранного продукта
Используются ли данные для обучения?Условия договора и фактическая настройка проекта
Где происходит обработка?Регионы, получатели и привлечённые исполнители
Как удалить сведения?Процедура и результат по всем предусмотренным копиям
Кто видит запросы?Роли, доступ поддержки и журналы действий
Как ограничить доступ модели?Проверяемые права на источники и инструменты

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

Псевдонимизация не решает всё

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

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

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

Условный пример: классификация обращений

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

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

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

Правовой вопрос начинается с фактической схемы

Для российского процесса нужно определить основания обработки, условия поручения, состав данных и применимость требований к месту обработки и передаче. Статья 6 152-ФЗ регулирует поручение обработки; статья 12 отдельно устанавливает порядок трансграничной передачи.[2][3]

CRM-команда должна передать ответственным схему получателей и стран, а не название AI-бренда. Настройка «не обучать на наших данных» не заменяет эту проверку. До решения используйте искусственные данные, достаточные для технического прототипа.

Защитите выход и подключённые действия

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

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

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

Источники

[1] OWASP. LLM02:2025 Sensitive Information Disclosure. OWASP Top 10 for Large Language Model Applications, 2025. Проверено 22.09.2026.

[2] Российская Федерация. Федеральный закон от 27.07.2006 № 152-ФЗ, статья 6. Действующая редакция; текст нормы в СПС «КонсультантПлюс». Проверено 22.09.2026.

[3] Российская Федерация. Федеральный закон от 27.07.2006 № 152-ФЗ, статья 12. Действующая редакция; текст нормы в СПС «КонсультантПлюс». Проверено 22.09.2026.