Оценка на доставчици на Chatbot: Споразумение за обработка на данни (DPA), поддоставчици и трансфер на данни към трети страни

Доставчикът на Chatbot може да разполага с убедително демо, EU-регион за съхранение и готов договор за обработка на лични данни (AVV/DPA) – и въпреки това ключови въпроси да останат отворени. Причината е, че видимата част на Chatbot не е единствената, която обработва данни. Често в предоставянето на услугата участват API модели, хостинг, векторни бази данни, инструменти за анализ на грешки, поддръжка, имейл услуги и бекъпи. Ето защо за собствениците на уебсайтове от значение е доказуемата верига на обработка, а не просто маркетинговите обещания за защита на данните.

Този чек-лист помага за структурирана проверка на доставчика преди покупка и пускане в реална среда. Той служи за практическа ориентация и не представлява правен съвет. Ролите, правните основания, задълженията за информиране и механизмите за трансфер трябва да се проверят за конкретния случай; при повишен риск, специални категории данни или отворени договорни въпроси следва да се консултирате с длъжностно лице по защита на данните (DPO) или квалифициран правен съветник.

Първо разберете потока на данните, след това оценете договора

Централният въпрос не е само „Къде се намира сървърът?“, а: Какви лични данни, кога, до кое юридическо лице стигат, на какво основание и за какъв период? Посетителят може да въведе в чата имена, имейл адреси, клиентски номера или свободен текст. Допълнително се генерират IP адреси, времеви печати, информация за устройството, идентификатори на сесията, история на разговорите, оценки и технически логове. Дори от уж анонимен разговор може да се разкрие самоличност чрез комбиниране на няколко признака.

Затова, преди да прегледате договора, съставете проста карта на потока от данни. Тя трябва да включва поне уиджета в браузъра, платформата на Chatbot, базата със знания, доставчика на AI модела, услугите за анализ и грешки, достъпите за поддръжка, бекъпите и пътищата за изтриване. За всяка станция се записват операторът, държавата, целта, категориите данни, срокът на съхранение и възможният отдалечен достъп. Твърдение за „EU хостинг“ например не отговаря на въпроса дали екип по поддръжка извън Европейското икономическо пространство (ЕИП) има достъп до реалните логове.

Определяне на ролите при защита на данните според целта

Дали даден доставчик е обработващ лични данни или администратор за определени цели, се определя от действителната му дейност. Насоките 07/2020 на Европейския съвет по защита на данните (EDPB) разясняват това разграничение. Доставчикът може да обработва данни от разговори по документирано указание, но да претендира за друга роля за свои собствени цели като сигурност, фактуриране или подобряване на продукта. Уверете се, че всяка цел, съответната роля и правно основание са изрично посочени. Договорът за обработка (AVV/DPA) не покрива автоматично самостоятелните цели на доставчика.

Проверка на AVV/DPA: Задължителното съдържание трябва да съответства на реалната услуга

Член 28 от GDPR изисква администраторите да използват само обработващи данни, които предоставят достатъчно гаранции за прилагането на подходящи технически и организационни мерки. Договорът трябва да определя предмета и продължителността, естеството и целта, видовете данни, категориите субекти на данни, както и правата и задълженията на администратора. Към тях се добавят документирани указания, конфиденциалност, сигурност, съдействие при упражняване правата на субектите, изтриване или връщане на данни, както и информация и съдействие при одити.

Сравнете договора не само с примерен чек-лист, но и с вашата карта на потока от данни и действително избрания абонаментен план. Добрият договор ясно описва чат услугата, обучението или индексирането на базата със знания, логването, достъпа за поддръжка и опционалните функции. Неясни общи понятия като „подобряване на услугата“ трябва да бъдат разбити до конкретни данни, цели, опции за избор и роли.

• Указания: Ясно ли е посочено, че съдържанието и метаданните се обработват само за документираните цели на клиента? Коя конфигурация се счита за указание?
• Използване за модели: Използват ли се промптовете, отговорите или каченото съдържание за общо обучение на AI модели или подобряване на продукта? Ако не, това трябва да е договорно и технически доказуемо; ако да, ролята и правното основание трябва да се оценят отделно.
• Изтриване: Има ли конкретни срокове за историята на разговорите, логовете, векторните индекси, бекъпите и копията за поддръжка? Какво се случва след прекратяване на договора?
• Сигурност: Описани ли са контролът на достъпа, изолацията на данните (multi-tenancy), криптирането, логването, управлението на уязвимости и процесите при инциденти?
• Съдействие: Урежда ли договорът практически процедурите по експорт, коригиране, изтриване, справки, инциденти със сигурността и, ако е необходимо, оценки на въздействието върху защитата на данните (DPIA)?
• Доказателства: Налични ли са одитни доклади, сертификати или други надеждни доказателства и важат ли те точно за използваните услуги и локации?

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

Поддоставчици: Контрол върху имена, задачи и промени

Съгласно чл. 28, параграф 2 от GDPR, обработващият лични данни няма право да включва друг обработващ без предварителното конкретно или общо писмено разрешение на администратора. При общо писмено разрешение той трябва да информира за всякакви планирани промени за добавяне или замяна и да даде възможност за възражение. Въпросите и отговорите на Европейската комисия относно стандартните договорни клаузи ясно посочват, че само общи категории не са достатъчни: отделните поддоставчици трябва да бъдат посочени по име.

Изискайте актуален списък с юридическото име, държавата, конкретната услуга и засегнатите данни. Проверете също дали дадена компания е само договорен партньор или действително обработва данни в множество локации. Особено важни са доставчиците на AI модели и embeddings, cloud хостинг, бази данни, CDN, мониторинг, анализ на грешки, поддръжка, имейл и бекъп. За всеки запис трябва да е ясно дали данните се съхраняват, само се пренасят или могат да се преглеждат от персонал.

Процесът по промяна също трябва да бъде оценен: Как се уведомяват клиентите, какъв е срокът за предизвестие и какво се случва при основателно възражение? Имейл в деня на промяната без възможност за техническа или договорна реакция няма стойност. Изяснете дали е възможна алтернативна конфигурация, деактивиране на функцията или при необходимост организирано прекратяване на договора с експорт на данните. За следващите по веригата поддоставчици трябва да важат същите задължения; първият обработващ остава отговорен пред администратора за изпълнението на техните задължения.

Трансфер на данни към трети страни: Проверка на механизма и реалното му действие

Глава V от GDPR се прилага за предаване на лични данни към трети страни и за последващо предаване. Трансфер възниква не само при постоянно съхранение; административният достъп, достъпът за поддръжка или извличането на данни от услуга извън ЕИП също са от значение. Затова определете целева държава, получател и съответен механизъм за трансфер за всяка стрелка в картата на потока от данни.

1. Решение за адекватност: Проверете в постоянно обновявания списък на Европейската комисия дали решението, територията, секторът и конкретният получател са обхванати. При ограничени рамки самото наличие на филиал в дадена страна не е достатъчно.
2. Подходящи гаранции: При липса на подходящо решение за адекватност, в зависимост от ситуацията се прилагат инструменти по чл. 46 от GDPR. Често се използват Стандартните договорни клаузи (SCC) на Европейската комисия. Модулът, страните, приложенията, описанието на трансфера и техническите мерки трябва да съответстват на реалната верига.
3. Оценка на ефективността: Подписаният документ за SCC не приключва автоматично проверката. Финалните препоръки 01/2020 на EDPB описват процес, базиран на риска: познаване на трансферите, определяне на инструмента, оценка на правото и практиката в третата страна, при необходимост определяне на допълнителни мерки, изпълнение на формалните стъпки и редовна преоценка.

Допълнителните технически мерки трябва да съответстват на конкретния риск. Криптирането например е показателно само ако се вземат предвид управлението на ключовете, правата за достъп и целта на обработката. Доставчик на AI модел, който трябва да обработва обикновен текст и сам има достъп до ключовете, е съвсем различна ситуация от обикновено криптирано хранилище за бекъпи. Общи изявления като „AES-256“ или „съвместим с GDPR“ не заместват тази преценка. Изключенията по чл. 49 от GDPR също не са стандартен начин за регулярна обработка при SaaS услуги.

Практически пример: EU регион с глобална верига от услуги

Да предположим, че Chatbot съхранява основната си база данни във Франкфурт. Отговорите обаче се генерират чрез API за AI модел на американска компания, докладите за грешки се изпращат към друга услуга, а глобален екип за поддръжка може да отваря протоколите от разговори при възникване на проблем. В такъв случай „съхранение на данните в ЕС“ описва само част от системата.

Процесът по Due Diligence разделя четири въпроса: Кое съдържание напуска ЕИП за генериране на модела? Съхраняват ли се промптовете там или се използват за други цели? Съдържат ли докладите за грешки пълен текст, идентификатори или само минимизирани технически данни? При какви условия поддръжката извън ЕИП има достъп? Едва след това могат да се оценят инструментът за трансфер, допълнителните мерки и остатъчният риск.

От техническа гледна точка собственикът на уебсайта често може да намали риска: изключване на излишни полета в логовете, редактиране на въведената информация преди външни извиквания, кратък срок на съхранение, отделяне на чувствителните зони от публичния бот, изолиране на източниците на знания по клиенти и изискване на одобрение за достъп на поддръжката. Как да разделите правилно публичен бот от клиентски портал описваме в статията Публичен AI Chatbot срещу Клиентски портал. За качени файлове чек-листът за проверка на файлове, защита на данните и прехвърляне към оператор допълва проверката на доставчика.

Вземане на решение със система „Светофар“ вместо по интуиция

Точка за проверка	Зелено	Жълто	Червено
Поток на данните	Пълен, актуален и обвързан с абонамента	Някои достъпи или локации са неизяснени	Само маркетингово твърдение за EU регион
DPA / AVV	Целите, данните, сроковете и съдействието са конкретизирани	Необходими са допълнения преди пускане	Липсва ясно обвързване с указания или изтриване
Поддоставчици	Поименен списък с държава и роля	Непрактичен процес по промените	Само общи категории или неизвестна верига
Трансфер извън ЕИП	Механизмът, обхватът и оценката са доказани	Мерките все още трябва да се потвърдят	„EU сървър“ се използва като обяснение за всички трансфери
Оперативна дейност	Отговорник (Owner), дата за преглед и exit план са тествани	Доказателства без определен график за преглед	Липсва мониторинг след подписване на договора

Жълтата точка не означава непременно отказ от доставчика. Тя обаче изисква отговорно лице, краен срок и критерий за приемане, който може да бъде проверен. Червената точка в ключова част от веригата на обработка трябва да блокира пускането в реална среда, докато договорът, конфигурацията или изборът на доставчик не бъдат коригирани. Документирайте и приетите остатъчни рискове, както и лицето, взело това решение.

Кратък чек-лист за пускане в реална среда за собственици на уебсайтове

• Картата на потока от данни и ролите за всяка цел са одобрени.
• Споразумението за обработка (DPA/AVV) и приложенията съответстват на плана, функциите, видовете данни и сроковете за съхранение.
• Всички поддоставчици са документирани поименно с държава, задача и начин за известяване при промяна.
• Всеки трансфер към трета страна има подходящ, актуален механизъм и, ако е необходимо, допълнителни мерки.
• Обучението на AI модели или друго използване на чат данните за собствени цели е изяснено и конфигурирано според договореното.
• Логването, достъпът за поддръжка, експортът на данни, изтриването и прекратяването на договора са тествани практически.
• Уведомлението за поверителност и чат интерфейсът разясняват обработката по разбираем начин; потребителите не се подтикват да въвеждат излишни чувствителни данни.
• Проверено е дали за конкретната употреба е необходима оценка на въздействието върху защитата на данните (DPIA).
• Има отговорник (Owner), който следи за промени при поддоставчиците, механизмите за трансфер, функциите и сертификатите за сигурност.

Допълнително си струва да прегледате основния преглед AI Chatbot и GDPR, както и ръководството за аналитика на Chatbot с минимизиране на данните. По този начин изборът на продукт, техническата настройка и текущата работа не се третират като отделни проекти.

Продължавайте проверките и след сключване на договора

Due Diligence не е еднократна папка с PDF файлове. Определете поне един периодичен ритъм за преглед и извънредни проверки при събития. Повод за това могат да бъдат нови поддоставчици, друг доставчик на AI модел, нови функционалности, променени локации за съхранение, инцидент със сигурността, изтичащи сертификати или промени в дадено решение за адекватност. Актуалният списък с поддоставчици и основните версии на договора трябва да се архивират с дата, за да се гарантира проследимост на промените.

Практическият критерий е прост: Може ли вашият екип да обясни за всеки реален поток на данните кой какво обработва, защо, къде се случва това, колко време се съхраняват данните, какви мерки за защита се прилагат и как работи прекратяването на услугата? Когато тези отговори са потвърдени с доказателства, общото твърдение за защита на данните се превръща в обосновано решение за покупка. Ако ключови елементи остават неизвестни, Chatbot не трябва да работи с реални данни на посетители.