Privacy & Security

Базы знаний на базе ИИ и конфиденциальность: 7 вопросов, которые должен задать каждый поставщик услуг перед записью разговоров с клиентами

ИИ, который записывает и индексирует разговоры с клиентами, — мощный инструмент, но только если вы точно знаете, кто дает согласие, где хранятся данные и как вы можете выйти из системы

The Wux Webtools Team The Wux Webtools Team 1 минуты чтения С поддержкой ИИ, проверено человеком
Moderne Europese datacenteromgeving met glazen serverruimte en laptop met toestemmingsdialoog, symboliseert transparantie en beveiliging bij AI-kennisbanken
Содержание
  1. Почему эта статья
  2. 1. Кто дает согласие на запись — и как вы это фиксируете?
  3. 2. Где данные физически хранятся и какое право применяется?
  4. 3. Какая модель обрабатывает расшифровки и используются ли они для обучения?
  5. 4. Как долго вы храните записи и embeddings, и кто может их удалить?
  6. 5. Какие журналы аудита доступны — сможет ли клиент позже увидеть, что произошло с «его» разговором?
  7. 6. Какова стратегия выхода? (Можете ли вы экспортировать свою базу знаний в открытом формате?)
  8. 7. Кто является процессором, кто — контролером, и зафиксировано ли это в соглашении об обработке данных?
  9. TL;DR чек-лист
  10. Что это означает для вашей организации

Почему эта статья

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

Эта статья — чек-лист из семи вопросов, на которые вам нужно уметь ответить до внедрения инструмента вроде Symphoria (партнера Wux Webtools и платформы, которой мы пользуемся сами) или альтернативы. Вопросы основаны на GDPR, Законе ЕС об ИИ, рекомендациях EDPB и повседневной практике нидерландских поставщиков услуг, которые хотят оставаться compliant, не превращая compliance в препятствие для работы.

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


1. Кто дает согласие на запись — и как вы это фиксируете?

GDPR требует законного основания для каждой обработки персональных данных (ст. 6). Для записей разговоров обычно требуется согласие (ст. 6(1)(a)) или законный интерес (ст. 6(1)(f)). Согласие должно быть предварительным, конкретным, информированным и добровольным (ст. 7). Это означает: никаких заранее отмеченных галочек, никаких скрытых пунктов в условиях и, конечно, никакого «мы записываем, если вы не возражаете».

Что вы хотите видеть: Четкий момент opt-in до того, как будет записан первый разговор. Это может быть чекбокс в онбординге проекта («Я соглашаюсь на запись встреч в целях проектной документации и поддержки ИИ»), устное подтверждение в начале звонка («Этот звонок записывается для нашей внутренней базы знаний — вы согласны?») или отдельное письмо с запросом согласия. Согласие должно логироваться: кто, когда, для какой цели и с какой формулировкой.

Как это решает Symphoria: Symphoria предлагает слой согласия для каждого проекта. Перед началом записи система явно запрашивает согласие у всех участников. Это согласие хранится с временной меткой и IP-адресом и может быть отозвано по проекту. Так проще соблюдать ст. 7(3) GDPR («отозвать согласие должно быть так же легко, как и дать его»).


2. Где данные физически хранятся и какое право применяется?

В принципе GDPR запрещает передачу персональных данных в страны за пределами ЕЭЗ без надлежащих гарантий (ст. 44–50). После решения Schrems II (2020) стандартных договорных положений (SCC) уже недостаточно, если принимающая сторона подпадает под действие законодательства о надзоре, такого как FISA 702 в США. Закон ЕС об ИИ (2024) добавляет еще один слой: системы ИИ высокого риска должны соответствовать требованиям прозрачности и аудита, которые трудно обеспечить, если данные хранятся за пределами ЕС.

Что вы хотите видеть: Четкое заявление о том, где данные физически хранятся (какой дата-центр, какая страна), какие субпроцессоры имеют доступ и подпадают ли эти стороны под действие неевропейского законодательства о надзоре. В идеале: хранение в пределах ЕС у провайдера, у которого нет материнской компании в США или который явно предлагает режим «только ЕС».

Как это решает Symphoria: Symphoria полностью работает на европейской инфраструктуре (AWS eu-west-1, Frankfurt) и не использует субпроцессоров из США для хранения или обработки расшифровок. Это упрощает соблюдение Schrems II без сложных оценок воздействия.


3. Какая модель обрабатывает расшифровки и используются ли они для обучения?

Большинство баз знаний на базе ИИ используют внешний LLM (OpenAI, Anthropic, Google) для обработки расшифровок. Это поднимает два вопроса: (1) используются ли расшифровки для обучения модели? и (2) кто имеет доступ к промптам и ответам? Условия API OpenAI с марта 2023 года указывают, что данные, отправленные через API, не используются для обучения — если только вы явно не подключились к отдельной программе. Но такая гарантия действует не у всех провайдеров и точно не распространяется на бесплатный или «исследовательский» доступ.

Что вы хотите видеть: Явное заявление, что расшифровки не используются для обучения модели и что после обработки они больше не доступны провайдеру LLM. Это должно быть включено в соглашение об обработке данных, а не только в FAQ. Дополнительно: платформа использует модель, которую вы можете хостить самостоятельно (например, Llama, Mistral), или европейского провайдера со строгим запретом на обучение на ваших данных.

Как это решает Symphoria: Symphoria использует API OpenAI с Business Associate Agreement (BAA) и положением о запрете обучения. Расшифровки обрабатываются через API, но не хранятся OpenAI и не включаются в будущие версии моделей. Это прямо указано в списке субпроцессоров.


4. Как долго вы храните записи и embeddings, и кто может их удалить?

GDPR требует не хранить персональные данные дольше, чем необходимо для цели, ради которой они были собраны (ст. 5(1)(e): ограничение хранения). Для базы знаний на базе ИИ это означает, что вы должны уметь объяснить, почему запись шестимесячной давности все еще актуальна, и иметь процесс удаления старых данных. Это относится и к производным данным: embeddings (векторные представления текста) являются персональными данными, если их можно связать с конкретным человеком.

Что вы хотите видеть: Настраиваемый срок хранения для каждого проекта (например, «автоматически удалять записи через 12 месяцев»), кнопку, позволяющую менеджеру проекта вручную удалить запись, и гарантию, что удаление затрагивает также embeddings и индексы, а не только аудиофайл. В идеале: журнал аудита, показывающий, когда что-то было удалено и кем.

Как это решает Symphoria: Symphoria предлагает «политику хранения» для каждого проекта. Вы можете настроить автоматическое удаление записей через X месяцев, включая расшифровки и embeddings. Ручное удаление доступно через интерфейс проекта, а каждое удаление фиксируется в audit trail.


5. Какие журналы аудита доступны — сможет ли клиент позже увидеть, что произошло с «его» разговором?

Прозрачность — один из ключевых принципов GDPR (ст. 5(1)(a)). Это означает, что вы должны уметь объяснить, что сделали с чьими-то данными, даже постфактум. Для базы знаний на базе ИИ это означает, что вы должны уметь показать, какие записи были сделаны, кто их просматривал, какие запросы выполнялись и были ли данные экспортированы или удалены. Без журналов аудита вы не сможете ответить на эти вопросы и рискуете штрафами в случае утечки данных или жалобы.

Что вы хотите видеть: Журнал аудита по каждому проекту, который отслеживает как минимум: (1) кто начал запись, (2) кто просматривал расшифровку, (3) какие запросы выполнялись к базе знаний, (4) экспортировались ли данные и (5) удалялись ли данные. Этот журнал должен быть доступен для поиска и храниться не менее 12 месяцев (дольше, если вы работаете в регулируемом секторе).

Как это решает Symphoria: Symphoria логирует все действия на уровне проекта: записи, просмотры, запросы, экспорты и удаления. Эти логи доступны владельцу проекта и могут быть экспортированы в CSV. Это упрощает выполнение запроса на доступ (ст. 15 GDPR) или расследование инцидента.


6. Какова стратегия выхода? (Можете ли вы экспортировать свою базу знаний в открытом формате?)

Vendor lock-in — риск для любого SaaS-инструмента, но с базой знаний на базе ИИ он особенно болезнен: вы собрали месяцы разговоров, расшифровок и метаданных, и если не можете их экспортировать, вы теряете это знание. GDPR дает вам право на переносимость данных (ст. 20), но оно распространяется только на данные, которые вы предоставили сами, а не на производные данные, такие как embeddings или резюме. Тем не менее разумно требовать возможность экспортировать всё в формате, который можно импортировать к другому провайдеру.

Что вы хотите видеть: Кнопку экспорта, которая дает вам как минимум: (1) все аудио- или видеофайлы, (2) все расшифровки в plain text или JSON, (3) все метаданные (временные метки, участники, теги) и (4) в идеале также embeddings в открытом формате, таком как Parquet или JSONL. Дополнительно: экспорт автоматизирован и может выполняться по расписанию (например, еженедельный backup в ваш собственный S3 bucket).


7. Кто является процессором, кто — контролером, и зафиксировано ли это в соглашении об обработке данных?

GDPR различает контролера (сторону, которая определяет, зачем и как обрабатываются персональные данные) и процессора (сторону, которая обрабатывает данные от имени контролера). Как поставщик услуг вы обычно являетесь контролером, а база знаний на базе ИИ — процессором. Это означает, что вам нужно соглашение об обработке данных (ст. 28 GDPR), в котором точно установлено, что процессор может делать, как долго, с какими субпроцессорами и что происходит в случае утечки данных.

Что вы хотите видеть: Data Processing Agreement (DPA), соответствующее ст. 28(3) GDPR. Оно должно включать как минимум: (1) предмет и срок обработки, (2) характер и цель обработки, (3) тип персональных данных и категории субъектов данных, (4) права и обязанности контролера, (5) список субпроцессоров и (6) процедуру при утечках данных. Это соглашение должно быть подписано до начала записи.

Как это решает Symphoria: Symphoria предлагает стандартное DPA, соответствующее ст. 28 GDPR. Вы можете подписать его через интерфейс платформы, и оно автоматически обновляется при добавлении нового субпроцессора. Это упрощает соблюдение требований без необходимости каждый раз привлекать юридическую команду.


TL;DR чек-лист

  • Согласие: Фиксируйте предварительное, конкретное согласие — с временной меткой и возможностью отказаться.
  • Хранение: Проверьте, хранятся ли данные в пределах ЕС и не подпадают ли они под неевропейское законодательство о надзоре.
  • Обучение: Требуйте явную гарантию, что расшифровки не используются для обучения модели.
  • Срок хранения: Установите срок хранения и убедитесь, что удаление затрагивает также embeddings.
  • Аудит: Требуйте логи того, кто что просматривал, запрашивал и удалял.
  • Экспорт: Проверьте, можете ли вы экспортировать все данные в открытом формате.
  • DPA: Подпишите соглашение об обработке данных до начала записи.

Что это означает для вашей организации

Если вы можете ответить на эти семь вопросов, вы уже на правильном пути. Но учтите: compliance — это не разовый чек-лист. GDPR требует регулярно проверять, что вы по-прежнему соответствуете требованиям (ст. 24: «надлежащие технические и организационные меры»), а Закон ЕС об ИИ добавляет еще один слой для систем высокого риска. Это означает: периодические аудиты, DPIA для новых сценариев использования и процесс реагирования на запросы доступа и утечки данных.

Хотите увидеть, как это работает на практике? Прочитайте материал о неделе с базой знаний на базе ИИ: как она меняет работу менеджера проектов у поставщика услуг — narrative case, где мы точно показываем, как эти вопросы возникают в повседневной практике.

Главный урок: база знаний на базе ИИ становится источником продуктивности только тогда, когда вы сохраняете доверие клиентов. А это доверие вы заслуживаете, задавая эти вопросы — и умея на них ответить — до того, как нажмете «запись».

Часто задаваемые вопросы

Нужно ли проводить DPIA перед использованием базы знаний на базе ИИ?
Это зависит от рисков. Если вы обрабатываете специальные категории персональных данных (ст. 9 GDPR: данные о здоровье, данные о правонарушениях и т. д.) или систематически отслеживаете поведение в крупном масштабе, DPIA обязательна (ст. 35 GDPR). Для большинства поставщиков услуг, которые записывают только деловые разговоры, DPIA не обязательна, но желательна — особенно если среди ваших клиентов есть организации из регулируемых секторов.
Кто несет ответственность в случае утечки данных: я или поставщик ИИ?
Как контролер вы всегда несете конечную ответственность (ст. 24 GDPR). Но если утечка была вызвана процессором (поставщиком ИИ), вы можете привлечь его к ответственности — при условии, что у вас есть хорошее соглашение об обработке данных, которое это регулирует. Именно поэтому DPA с четкой процедурой при утечке данных является обязательным.
Могу ли я делать записи без согласия, если это внутренние встречи?
Это зависит от законного основания. Для внутренних встреч иногда можно опираться на законный интерес (ст. 6(1)(f) GDPR), но тогда вы должны быть способны доказать, что этот интерес перевешивает приватность вовлеченных лиц. На практике безопаснее запрашивать согласие и внутри организации — особенно если записи индексируются ИИ.
Что если клиент отзовет согласие позже?
Тогда вы должны удалить запись, если у вас нет другого законного основания (например, договорной необходимости). GDPR требует, чтобы отозвать согласие было так же легко, как и дать его (ст. 7(3)). Это означает: кнопка на вашей платформе, позволяющая клиенту отозвать согласие, и процесс, который обеспечивает удаление записи в разумный срок (обычно 30 дней).
Могу ли я делиться расшифровками с третьими сторонами (например, фрилансерами, работающими над проектом)?
Только если это входит в цель, для которой было дано согласие, и если третья сторона также связана соглашением об обработке данных. Это означает: если вы привлекаете фрилансера, которому нужен доступ к базе знаний, этот фрилансер должен подписать NDA и положение о субпроцессоре.
А как насчет Закона ЕС об ИИ — относится ли база знаний на базе ИИ к «высокому риску»?
Скорее всего, нет. Закон ЕС об ИИ определяет ИИ высокого риска как системы, используемые в критически важных секторах (например, подбор персонала, кредитный скоринг, правоохранительная деятельность). База знаний на базе ИИ, используемая только для внутренней проектной документации, обычно не попадает в эту категорию. Но если вы используете ИИ для принятия решений о людях (например, performance reviews на основе записей), он может стать высокорисковым.

Источники и дальнейшее чтение

  1. Algemene Verordening Gegevensbescherming (AVG) — Volledige tekst
  2. EU AI Act — Verordening (EU) 2024/1689
  3. EDPB Guidelines 05/2020 on consent under Regulation 2016/679
  4. Autoriteit Persoonsgegevens — Toestemming vragen
  5. Schrems II: CJEU judgment C-311/18 (Data Protection Commissioner v Facebook Ireland and Maximillian Schrems)
  6. CNIL — Transferts de données hors UE
Об авторе
The Wux Webtools Team

Последнее обновление:

Продолжайте читать

AI & Content

Неделя с базой знаний на основе ИИ: как меняется работа проектного менеджера в компании — поставщике услуг

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

1 минуты чтения