Покрај SSN: Анонимизирање на интерните ID на вашата организација
Вашата GDPR алатка ги отстранува адресите за е-пошта. Ги отстранува телефонските броеви. Ги отстранува имињата. Ги поминувате извозите за поддршка низ неа. Потоа го споделувате излезот со вашиот аналитички тим.
Броевите на вашите клиентски сметки сè уште се во секој билет. Вашите ID на нарачки сè уште се таму. Вашите интерни кориснички ID сè уште се таму, исто така.
Овие ID изгледаат безопасно самостојно. Без табела за пребарување, тие не именуваат лице. Но вашиот аналитички тим ја има таа табела. Вашиот CRM ја има. Вашата база на податоци за поддршка ја има. Секој со пристап може да ја најде личноста за секунди.
Ова е неуспех на GDPR. Алатката не застана. Никогаш не й беше кажано да бара вашите ID.
Што стандардните PII алатки откриваат
Стандардните PII алатки ги покриваат универзалните формати. Тие фаќаат она што секоја организација го користи.
Стандардните алатки откриваат:
- Броеви за социјално осигурување (US SSN, UK NINO, формати на национален ID на ЕУ)
- Адреси за е-пошта
- Телефонски броеви
- Броеви на кредитни картички
- Имиња
- Броеви на пасош и возачка дозвола
Стандардните алатки не откриваат:
- ID на вработени во вашиот формат EMP-XXXXX
- Броеви на клиентски сметки во вашиот формат ACC-XXXXXXXX-XX
- ID на нарачки во вашиот формат ORD-XXXXXXX
- Интерни кориснички ID во UUID или прилагодени формати
- Референтни кодови специфични за партнерот
Стандардните алатки наоѓаат универзални шаблони. Вашите интерни ID не се универзални. Тие бараат прилагодено поставување за да бидат пронајдени.
Ризикот од повторна идентификација
Фирмата извезува билети за поддршка за преглед на квалитет. Стандарднето отстранување на PII ги отстранува имињата, е-поштите и телефонските броеви. Броевите на сметки во формат ACC-XXXXXXXX-XX не се допираат.
Извозот оди до аналитичкиот тим. Аналитичар ја спојува табелата на билети со базата на клиенти на бројот на сметка. Личноста се наоѓа веднаш. Не е потребен специјален трик. Тоа е рутинско SQL спојување.
Членот 4(5) на GDPR ја дефинира псевдонимизацијата како обработка каде податоците "повеќе не може да се припишат на конкретен субјект на податоци без употреба на дополнителни информации." Броевите на сметки не го поминуваат тој тест. Дополнителните информации - вашата база на клиенти - се токму таму во вашата организација.
"Анонимизираниот" извоз не беше анонимен.
Изградба на шаблони за прилагодени ентитети
Поставувањето на прилагоден ентитет е брзо. Тимовите за усогласеност можат да го направат без инженерска помош.
Чекор 1: Наведете ги вашите ID формати.
Запишете ги секого. На пример: сметка ACC-XXXXXXXX-XX, ID на нарачка ORD-XXXXXXX, ID на вработен EMP-XXXXX.
Чекор 2: Опишете го форматот на обичен јазик.
"Броевите на сметки почнуваат со ACC, потоа цртичка, потоа 8 цифри, потоа цртичка, потоа 2 главни букви."
Генерирањето на шаблон со помош на AI враќа: ACC-\d{8}-[A-Z]{2}
Чекор 3: Тестирајте на примерни податоци.
Прикачете 20 до 30 документи. Потврдете дека сите инстанци се пронајдени. Потврдете дека не се појавуваат лажни погодоци.
Чекор 4: Изберете метод.
За ID кои се користат како клучеви за спојување, каде анализата треба да ги поврзе записите:
- Псевдонимизирајте. Заменете ACC-00123456-AB со ACC-99876543-XY секој пат. Истиот влез секогаш дава ист излез. Спојувањата сè уште работат. Оригиналната вредност не може да се најде без клучот.
За ID кои не се потребни во анализата:
- Редактирајте. Заменете со [REDACTED]. Едноставно. Трајно.
Чекор 5: Зачувајте го како споделена претпоставена вредност.
Зачувајте го прилагодениот ентитет - или збир од нив - во споделена претпоставена вредност. Поставувањето се применува на секоја употреба: групни прикачувања, API повици, браузерски интерфејс. Новите членови на тимот ја добиваат целата конфигурација веднаш.
Студија на случај: 180.000 билети за поддршка
Фирма пронашла 180.000 билети за поддршка во нивниот аналитички магацин. Имињата и е-поштите беа отстранети. Броевите на сметки не беа. Секој билет сè уште содржеше активна вредност ACC-XXXXXXXX-XX.
Временска линија за решавање:
- Службеник за усогласеност го дефинира ACC шаблонот - 15 минути
- Го тестира на 30 примерни билети - 20 минути
- Потврдува точност - 10 минути
- Обработува 180.000 билети во ноќна серија
- Ги заменува табелите во магацинот со чистите верзии
Вкупно време за службеникот за усогласеност: 45 минути. Без поддршка за прилагоден ентитет, поправката би барала инженерски билет, преглед на кодот и распоредување. Тоа трае недели, не часови.
За подетален поглед на тоа како прилагодените ID создаваат ризик во AI алатките за поддршка, погледнете го водичот за GDPR и AI за поддршка.
Каде прилагодените ID се шират
Интерните ID се појавуваат на повеќе места отколку што очекуваат повеќето тимови.
Интерни документи:
- Белешки од состаноци со референци за сметка или ID на нарачка
- Е-пошта нишки за случаи на клиенти
- Презентации со податоци од студии на случај
Споделени со трети страни:
- Извештаи до регулаторите со референтни броеви на случаи
- Ревизорски датотеки со референци на клиенти
- Датотеки на продавачи кои носат ID на клиенти
Истражување и аналитика:
- Набори на податоци за патување на клиенти
- Извози за преглед на квалитет на поддршка
- Податоци за обука за интерни ML модели
Секој контекст го бара истото поставување на прилагоден ентитет за да произведе вистински анонимен излез.
Псевдонимизација наспроти анонимизација
GDPR повлекува јасна линија.
Псевдонимизацијата ги заменува ID со замени. Оригиналното лице може повторно да се најде ако некој ја има табелата за пребарување. Овие податоци сè уште се лични податоци. Го намалува ризикот. Не ги отстранува вашите GDPR обврски.
Анонимизацијата ја отстранува можноста за повторна идентификација. Анонимните податоци не се лични податоци. GDPR не се применува на нив.
Броевите на сметки и ID на нарачки се псевдонимни кога постојат табели за пребарување. Нивната замена со фиксни замени го намалува ризикот, но GDPR сè уште се применува. Нивната замена со случајни токени - и бришење на клучот - ја отстранува обврската на GDPR, но ги прекинува спојувањата базирани на анализа.
За споделување со трети страни кои немаат ваши табели за пребарување: псевдонимизацијата може да биде доволна. За интерна аналитика, потребна е целосна анонимизација или строги контроли за пристап. Водичот за правна усогласеност покрива како да се документира секој пристап за вашата ROPA.
Заклучок
Пропустот не е неуспех на алатката. Тоа е пропуст во поставувањето. Ниедна алатка не може да го знае форматот на вашиот број на сметка освен ако не й го кажете.
Поставувањето на прилагоден ентитет го затвора пропустот за часови. Тимовите за усогласеност ги дефинираат форматите, ги тестираат на примерни податоци и ги применуваат низ сите режими на употреба. Не е потребна инженерска помош.
180.000 нередактирани броеви на сметки не беа таму затоа што алатката не успеа. Беа таму затоа што на алатката никогаш не й беше кажано да ги бара.