Budování GDPR-vyhovující AI pro zákaznickou podporu: Odstraňování PII A vlastních identifikátorů před odesláním dodavatelům AI
Váš tým zákaznické podpory používá asistenta AI k navrhování odpovědí, shrnutí historie lístků a navrhování řešení. AI je dobrá. Produktivita roste. Pak váš DPO přezkoumá implementaci.
Zjistí, že každý zákaznický lístek — s celými jmény, e-mailovými adresami, ID objednávek, čísly účtů a popisy problémů — je odesílán na servery US dodavatele AI ke zpracování. Anonymizační filtr odstraňuje e-mailové adresy. Ale nechává ID objednávek, čísla zákaznických účtů a interní kódy produktů nedotčena.
DPO identifikuje problém: to je přenos dat EU na US servery a částečná anonymizace, která nesplňuje standard pseudonymizace GDPR.
Standardní PII vs. Vlastní organizační identifikátory
Standardní PII nástroje jsou navrženy k detekci a odstraňování dobře definovaných kategorií osobních dat:
- Jména (PERSON)
- E-mailové adresy (EMAIL_ADDRESS)
- Telefonní čísla (PHONE_NUMBER)
- Adresy (LOCATION)
- Čísla SSN, pasů (US_SSN, PASSPORT)
Tyto identifikátory jsou detekovatelné prostřednictvím jazykových vzorů — NER pro jména, regulární výrazy pro e-maily a SSN.
Ale zákaznická data podpory obsahují druhou kategorii identifikátorů — specifické pro organizaci, generované interně — které standardní nástroje nedokáží detekovat:
- ID zákazníka:
CUST-8847291 - ID objednávky:
ORD-2024-119847 - ID lístku:
TKT-0047291 - ID produktu:
PRD-SKU-88471 - Číslo účtu:
ACC-EU-44291
Každý z těchto identifikátorů je pseudonymem v zákaznické podpůrné databázi — zkřížením s tabulkou zákazníků se ID zákazníka mapuje na jméno, e-mail a adresu konkrétní osoby. Tyto identifikátory samy o sobě jsou osobními daty pod GDPR, pokud umožňují identifikaci fyzické osoby kombinací s jinými dostupnými daty.
Konfigurace vlastních entit pro ID zákazníků
Řešením je konfigurace nástrojů PII k rozpoznání organizačních identifikačních vzorů jako vlastních typů entit:
Typ entity: CUSTOMER_ID
Vzor: CUST-[0-9]{7}
Příklady: CUST-8847291, CUST-0012847
Typ entity: ORDER_ID
Vzor: ORD-[0-9]{4}-[0-9]{6}
Příklady: ORD-2024-119847, ORD-2023-008147
Typ entity: TICKET_ID
Vzor: TKT-[0-9]{7}
Příklady: TKT-0047291, TKT-1188476
Typ entity: ACCOUNT_NUMBER
Vzor: ACC-[A-Z]{2}-[0-9]{5}
Příklady: ACC-EU-44291, ACC-US-88471
S těmito vlastními typy entit nakonfigurovanými: zákaznická zpráva „Zákazník CUST-8847291 uvádí, že objednávka ORD-2024-119847 nebyla doručena" se stane „Zákazník [CUSTOMER_ID] uvádí, že objednávka [ORDER_ID] nebyla doručena" — plně anonymizovaná pro AI zpracování při zachování kontextu problému.
Tokenové mapování pro zpětnou dohledatelnost
Pro pracovní postupy zákaznické podpory, kde potřebujete přičíst AI generovanou odpověď ke konkrétní zákaznické interakci, zachovejte tokenové mapování na vaší straně:
Mapa anonymizace:
[CUSTOMER_ID_001] → CUST-8847291
[ORDER_ID_001] → ORD-2024-119847
Odešlete anonymizovaný kontext AI: „[CUSTOMER_ID_001] uvádí, že [ORDER_ID_001] nebyla doručena. Zákazník požádal o náhradu."
AI navrhne odpověď: „Prošetřili jsme [ORDER_ID_001] a zjistili jsme..."
Znovu vložte token zpět do odpovědi: „Prošetřili jsme ORD-2024-119847 a zjistili jsme..." — se skutečnými hodnotami přidanými místně, nikdy AI serverem.
Zdroje: