Бази знань на основі ШІ та конфіденційність: 7 запитань, які має поставити кожен постачальник послуг перед записом розмов із клієнтами

Чому ця стаття

База знань на основі ШІ, яка записує, транскрибує та робить розмови з клієнтами доступними для пошуку, дає постачальникам послуг значний приріст продуктивності. Раніше ми писали про те, як бази знань на основі ШІ для кожного проєкту нарешті стають розумними завдяки вашій компанії, але щойно ви починаєте фіксувати голос, відео або чат, розмова зміщується від "корисного інструмента" до "юридичної оцінки".

Ця стаття — чекліст із семи запитань, на які вам потрібно вміти відповісти перед упровадженням інструмента на кшталт Symphoria (партнера Wux Webtools і платформи, яку ми використовуємо самі) або альтернативи. Запитання ґрунтуються на GDPR, EU AI Act, рекомендаціях EDPB і щоденній практиці нідерландських постачальників послуг, які хочуть залишатися compliant, не перетворюючи відповідність вимогам на перешкоду для роботи.

Контекст такий: ви постачальник послуг — консалтингова компанія, розробник, маркетингова агенція, бухгалтер — і допомагаєте клієнтам із проєктами, які тривають місяцями та генерують десятки розмов. Ви хочете, щоб ШІ підсумовував ці розмови, виділяв завдання та відповідав на запитання на кшталт "що клієнт сказав минулого тижня про бюджет?". Це можливо. Але не без цих семи відповідей.

1. Хто надає згоду на запис — і як ви це фіксуєте?

GDPR вимагає законної підстави для кожної операції обробки персональних даних (ст. 6). Для записів розмов зазвичай потрібна згода (ст. 6(1)(a)) або законний інтерес (ст. 6(1)(f)). Згода має бути попередньою, конкретною, поінформованою і вільно наданою (ст. 7). Це означає: жодних заздалегідь позначених чекбоксів, жодних прихованих положень в умовах користування і, звісно, жодного "ми записуємо, якщо ви не заперечуєте".

Що ви хочете бачити: Чіткий момент opt-in перед тим, як буде записана перша розмова. Це може бути чекбокс під час onboarding проєкту ("Я погоджуюся на запис зустрічей з метою документування проєкту та підтримки ШІ"), усне підтвердження на початку дзвінка ("Цей дзвінок записується для нашої внутрішньої бази знань — ви погоджуєтеся?"), або окремий лист зі згодою. Згоду потрібно журналювати: хто, коли, з якою метою і з яким формулюванням.

Як Symphoria вирішує це: Symphoria пропонує рівень згоди для кожного проєкту. Перед початком запису система явно запитує згоду в усіх учасників. Ця згода зберігається з позначкою часу та IP-адресою і може бути відкликана для кожного проєкту. Це спрощує дотримання ст. 7(3) GDPR ("відкликати згоду має бути так само легко, як і надати її").

2. Де фізично зберігаються дані та яке право застосовується?

Загалом GDPR забороняє передачу персональних даних до країн за межами EEA без належних гарантій (ст. 44–50). Після рішення Schrems II (2020) Standard Contractual Clauses (SCCs) більше не є достатніми, якщо сторона-одержувач підпадає під дію законодавства про нагляд, такого як FISA 702 у США. EU AI Act (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 та індекси — а не лише аудіофайл. В ідеалі: audit log, який показує, коли щось було видалено і ким.

Як Symphoria вирішує це: Symphoria пропонує "retention policy" для кожного проєкту. Ви можете налаштувати автоматичне видалення записів через X місяців, включно з транскриптами та embeddings. Ручне видалення можливе через інтерфейс проєкту, і кожне видалення фіксується в audit trail.

5. Які audit logs доступні — чи зможе клієнт згодом побачити, що сталося з "його" розмовою?

Прозорість — ключовий принцип GDPR (ст. 5(1)(a)). Це означає, що ви маєте бути здатні пояснити, що зробили з чиїмись даними — навіть постфактум. Для бази знань на основі ШІ це означає, що ви маєте показати, які записи були зроблені, хто їх переглядав, які запити виконувалися і чи були дані експортовані або видалені. Без audit logs ви не зможете відповісти на ці запитання і ризикуєте штрафами у разі витоку даних або скарги.

Що ви хочете бачити: Audit log для кожного проєкту, який відстежує щонайменше: (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. Додатковий плюс: експорт автоматизований і може бути запланований (наприклад, щотижневе резервне копіювання до вашого власного 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 checklist

• Згода: Фіксуйте попередню, конкретну згоду — з позначкою часу та можливістю opt-out.
• Зберігання: Перевірте, чи дані зберігаються в межах ЄС і не підпадають під дію неєвропейського законодавства про нагляд.
• Навчання: Вимагайте явної гарантії, що транскрипти не використовуються для навчання моделі.
• Зберігання за строком: Встановіть строк зберігання і переконайтеся, що видалення також зачіпає embeddings.
• Аудит: Вимагайте журнали того, хто що переглядав, запитував і видаляв.
• Експорт: Перевірте, чи можете ви експортувати всі дані у відкритому форматі.
• DPA: Підпишіть договір про обробку даних до того, як почнете записувати.

Що це означає для вашої організації

Якщо ви можете відповісти на ці сім запитань, ви вже на правильному шляху. Але зауважте: відповідність вимогам — це не одноразовий чекліст. GDPR вимагає регулярно перевіряти, чи ви й надалі відповідаєте вимогам (ст. 24: "належні технічні та організаційні заходи"), а EU AI Act додає ще один рівень для систем високого ризику. Це означає: періодичні аудити, DPIA для нових сценаріїв використання і процес реагування на запити доступу та витоки даних.

Хочете побачити, як це працює на практиці? Прочитайте тиждень із базою знань на основі ШІ: як вона змінює роботу проєктного менеджера у постачальника послуг — наративний кейс, у якому ми показуємо, як саме ці запитання виникають у щоденній практиці.

Ключовий урок: база знань на основі ШІ стає приростом продуктивності лише тоді, коли ви зберігаєте довіру клієнтів. А цю довіру ви здобуваєте, ставлячи ці запитання — і маючи змогу на них відповісти — до того, як натиснете "record".