Использует ли ваш поставщик ваши данные? Новый вопрос для закупок

Раньше каждый RFP на инструменты для сбора обратной связи или CX-платформы задавал один и тот же вопрос в той или иной форме: «Защищены ли наши данные?» Поставщики отвечали значками SOC 2, галочками про шифрование данных при хранении и пунктом о GDPR, спрятанным где-то в приложении. Этого вопроса уже недостаточно, и если ваш чек-лист закупок до сих пор на нём останавливается, вы упускаете то, что на самом деле важно в 2025 году: не то, защищены ли ваши данные, а то, используются ли они — поставщиком, для целей, не имеющих ничего общего с вашим бизнесом.

Сегодня каждая CX- и support-платформа предлагает «инсайты на основе ИИ», автоматически сгенерированные сводки, предиктивные оценки или отраслевые бенчмарки. Где-то эту работу выполняет модель. Вопрос для закупок эпохи ИИ прост в формулировке, но на него на удивление сложно получить прямой ответ: на чём обучена эта модель и кто получает выгоду от этого обучения?

Почему этого вопроса не существовало пять лет назад

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

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

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

Три способа, которыми поставщики реально используют ваши данные

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

1. Обучение общих моделей на ваших данных

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

2. Построение межклиентского бенчмарка или графа идентификации

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

3. Хранение сырых данных сверх заявленной цели

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

Вопросы для закупок, которые реально работают

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

• «Обучаете ли вы какую-либо модель — для анализа тональности, классификации, скоринга или генерации — на данных нескольких клиентов, включая наши?» Требуйте ответ «да» или «нет», а не описание вашего «соглашения об обработке данных».
• «Если мы уйдём, что произойдёт с производными данными — оценками, эмбеддингами, профилями, — построенными на основе наших сырых ответов?» Удаление сырых данных при расторжении контракта — это стандарт. Удаление производных данных — нет, и большинство поставщиков не упоминают об этом, если их не спросить напрямую.
• «Можем ли мы увидеть и экспортировать точные поля, которые вы используете для расчёта [функции X]?» Если поставщик не может показать вам исходные данные для расчёта оценки оттока или скоринга лидов, вы не сможете её проверить, оспорить или воспроизвести где-либо ещё.
• «Рассчитывается ли ваш бенчмарк на основе данных, агрегированных по всем клиентам, или мы можем привязать его к собственной исторической базе?» У поставщика, чей бенчмаркинговый продукт целиком зависит от объединения клиентских данных, есть структурный стимул сохранять непрозрачность этого объединения — он не может порекомендовать вам использовать собственную базу, потому что это подорвёт его продукт.
• «Строите ли вы граф идентификации между клиентами, или каждое объединение данных выполняется по ID, который контролируем мы?» Один этот вопрос раскрывает об архитектуре поставщика больше, чем час демонстрации продукта от отдела продаж.

Практический пример: проверка поставщика перед подписанием

Допустим, вы руководитель операций в сфере электронной коммерции и оцениваете две платформы для объединённого процесса приёма возвратов (RMA) и опроса CSAT после решения вопроса. Обе хорошо показывают себя на демо. Обе заявляют об «анализе тональности на основе ИИ» для комментариев к возвратам. Вот конкретный пилотный тест, который отделяет реальные ответы от маркетинговых текстов:

1. Настройте тестовую форму RMA с повторяющимся разделом — несколько товаров на один возврат, каждый с текстовым описанием дефекта. Это реалистичный сценарий многопозиционного возврата, а не игрушечный пример.
2. Отправьте десять тестовых ответов с различимыми, узнаваемыми формулировками в текстовых полях (фразами, которые потом можно будет найти поиском).
3. Спросите поставщика в письменном виде: «Покажите, где хранится этот текст, какой срок хранения применяется, и подтвердите, передаётся ли обученная на нём модель другим клиентам».
4. Запросите экспорт данных, показывающий анализ тональности и извлечение сущностей для каждой позиции возврата отдельно — а не единый объединённый блок для всей заявки целиком.
5. Завершите пилот и запросите подтверждение удаления, включая любые производные оценки или эмбеддинги — а не только сырую заявку.

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

Читайте контракт, а не только демо

Демонстрации продаж показывают возможности. Контракты показывают намерения. Перед подписанием попросите юристов специально проверить следующее:

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

Чем здесь помогает SurveyAnalytica

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

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

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

Итог

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

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