GDPR-yhteensopiva ML-koulutusdata: 10 000 tietueen anonymisointi ilman koodausta
Jokainen GDPR:n piirissä olevia tietoja käsittelevä datatiimi on kirjoittanut jonkinlaisen version tästä skriptistä:
import re
def anonymize_email(text):
return re.sub(r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}', '[EMAIL]', text)
Tämä ei ole GDPR-vaatimustenmukaisuutta. Se on pelkkä sähköpostiosoitteiden korvaaminen. Tietojoukko sisältää edelleen nimiä, puhelinnumeroita, potilastunnuksia ja tusinan verran muita henkilötietoluokkia, jotka aiheuttavat vaatimustenmukaisuusongelmia.
Kuilu "anonymisoin sähköpostit" ja "tämä tietojoukko on GDPR-yhteensopiva ML-koulutukseen" välillä on suuri, merkittävä ja jatkuvasti aliarvioitu.
Miksi GDPR rajoittaa ML-koulutusdata käyttöä
GDPR:n käyttötarkoituksen rajoittamisperiaate (artikla 5(1)(b)) toteaa, että henkilötietoja voidaan kerätä määriteltyjä, nimenomaisia ja oikeutettuja tarkoituksia varten, eikä niitä saa käsitellä myöhemmin näiden tarkoitusten kanssa yhteensopimattomalla tavalla.
Tilausten täyttämiseksi kerättyä asiakastietoa ei ole kerätty suosittelumallin kouluttamista varten. Hoitoa varten kerättyä terveysdataa ei ole kerätty uudelleensairaalointia ennustavan mallin kouluttamista varten. Tuotepalautetta varten kerättyjä kyselyvastauksia ei ole kerätty sentimenttianalyysin kouluttamista varten.
Näiden tietojen käyttäminen ML-koulutukseen edellyttää joko:
- Nimenomainen suostumus jokaiselta rekisteröidyltä ML-koulutusta varten (operatiivisesti monimutkainen, usein mahdoton takautuvasti)
- Oikeutetun edun arviointi, joka osoittaa koulutuksen tarkoituksen olevan yhteensopiva alkuperäisen keräämisen kanssa (oikeudellisesti epävarma, valvontaviranomaisen harkittavissa)
- Anonymisointi — henkilötietojen poistaminen tai korvaaminen siten, että data ei ole enää GDPR:n mukaisia henkilötietoja
Asianmukainen anonymisointi on pienimmän vastarinnan polku ja suurin oikeudellinen varmuus. Haasteena on tehdä se oikein ja johdonmukaisesti.
Ongelma ad hoc -anonymisointiskripteissä
Datatiimit, jotka kirjoittavat kertaluonteisia Python-skriptejä jokaiselle uudelle tietojoukolle, luovat kasautuvia ongelmia:
Epätäydellinen kattavuus: Yhden tietojoukon skeemaa varten kirjoitettu skripti ohittaa PII-tiedot sarakkeissa, jotka on lisätty viimeisen skeemapäivityksen jälkeen. Kliiniset muistiinpanot -kenttä, joka lisättiin 6 kuukautta sitten: ei regex-kuviossa. Asiakkaan toinen nimi -kenttä: regex käsittelee vain ETUNIMI ja SUKUNIMI -kuvioita.
Epäjohdonmukaisuus tietojoukkojen välillä: Tietojoukko A anonymisoitiin script_v1.py:llä. Tietojoukko B anonymisoitiin script_v3.py:llä. Tietojoukko C anonymisoitiin tiimin jäsenen toimesta, joka ei tiennyt script_v3.py:stä. Yhdistetyssä koulutustietojoukossa on kolme eri anonymisointimenetelmää. Tietosuojavastaava ei voi sertifioida sitä.
Ei auditointijälkeä: Skripti ajettiin. Mitä se muutti? Mitkä yksiköt löydettiin? Mistä riveistä? Ilman käsittelymetadataa vaatimustenmukaisuuden dokumentointi on mahdotonta. Kun tietosuojavaltuutetun auditoija kysyy "miten tiedätte, että tämä koulutustietojoukko on anonymisoitu?", "ajoimme Python-skriptin" ei ole tyydyttävä vastaus.
Mallin ajautuminen: Regex-kuviot, jotka toimivat vuoden 2023 datalla, eivät tunnista vuoden 2024 dataan lisättyjä uusia tunnistusformaatteja. Skriptit eivät päivity itse.
Eräkäsittelymenetelmä
Terveysalan tekoälyyrityksen datatiimin on anonymisoitava 8 000 potilastietuetta, ennen kuin heidän Yhdysvaltain tiimi voi käyttää niitä EU-toimistosta (Schrems II:n rajat ylittävä siirtokielto pätee).
Perinteinen lähestymistapa: Datasuunnittelija kirjoittaa mukautetun Python-anonymisointiskriptin. Aika: 2–3 päivää kehitystä, 1–2 päivää testausta ja tarkistusta tietosuojavastaavan kanssa, 1 päivä iterointia. Yhteensä: 4–6 päivää. ML-projektin aikataulu viivästyy.
Eräkäsittelymenetelmä:
- Viedä 8 000 tietuetta CSV-muodossa (tavanomainen data science -formaatti)
- Ladata eräkäsittelyyn
- Konfiguroida yksikkötyypit: PERSON, EMAIL_ADDRESS, PHONE_NUMBER, US_SSN, MEDICAL_RECORD, DATE_OF_BIRTH, LOCATION
- Valita menetelmä: Korvaa (korvaa realistisilla synteettisillä tiedoilla datasarjan rakenteen säilyttämiseksi ML-koulutusta varten)
- Käsittely: 45 minuuttia 8 000 tietueelle
- Lataa anonymisoitu CSV
- Tietosuojavastaava tarkistaa käsittelymetadatan (löydetyt yksiköt tietuetta kohti, käytetyt menetelmät): 2 tuntia
- Tietosuojavastaava hyväksyy, tietojen jakaminen etenee
Kokonaisaika: 45 minuuttia käsittelyä + 2 tuntia tietosuojavastaavan tarkistusta vs. 4–6 päivää suunnittelua. ML-aikataulu pysyy oikeilla raiteilla.
Korvaa vs. Poista ML-koulutusdatassa
Anonymisointimenetelmän valinta vaikuttaa ML-hyödyllisyyteen:
Poista (musta palkki / paikkamerkin korvaus): Korvaa PII:n [REDACTED]-tokeneilla tai vastaavilla. Tuloksena oleva tietojoukko sisältää johdonmukaisia paikkamerkki-tokeneita siellä, missä PII oli. NLP-malleille, joita koulutetaan tunnistamaan PII, tämä luo merkityn tietojoukon. Muille tehtäville — sentimentti, luokittelu, suosittelu — [REDACTED]-token häiritsee luonnollisen kielen mallintamista.
Korvaa (realistinen synteettinen korvaus): Korvaa "Matti Virtanen" nimellä "Antti Korhonen" (realistinen mutta eri nimi). Sähköposti "mvirta@yritys.fi" muuttuu "akorhonen@syntheetti.fi":ksi. Tuloksena oleva tietojoukko ylläpitää luonnollisen kielen jakaumia — lauserakennetta, yksikön sijaintia, rinnakkaisesiintymiskuvioita — jotka ovat tärkeitä NLP-mallin kouluttamisessa.
ML-koulutusdatalle Korvaa on sopiva menetelmä. Malli ei opi ennustamaan tiettyjä vääriä arvoja, mutta se oppii rakenteellisista ja kontekstuaalisista kuvioista, kuinka nimet, sähköpostit ja muut yksiköt esiintyvät tekstissä.
Schrems II ja rajat ylittävät datavirrat
Schrems II -päätös (EU:n tuomioistuin, 2020) kumosi EU–Yhdysvallat Privacy Shield -sopimuksen, luoden epävarmuutta EU:sta Yhdysvaltain palvelimille siirrettäville tiedoille. Käytännön vaikutus tiedekeskeiseen työhön: EU-alkuperäistä koulutusdataa ei voida lähettää Yhdysvaltain ML-infrastruktuuriin (AWS US-East, GCP US-Central) ilman asianmukaisia siirtotakeita.
Asianmukaiset takeet sisältävät:
- Vakiosopimuslausekkeet (SCC) siirtovaikutusarvioinnilla
- Sitovat yrityssäännöt (BCR) konserniyhtiöiden välisille siirroille
- Poikkeus anonymisoituun dataan: Asianmukaisesti anonymisoitu data ei ole GDPR:n mukaisia henkilötietoja, eikä se ole siirtokieltojen alainen
Yhdysvaltain ML-infrastruktuuria EU-alkuperäisellä datalla käyttäville tiimeille asianmukainen anonymisointi poistaa Schrems II -ongelman kokonaan. Anonymisoitu tietojoukko ei ole enää henkilötietoja — sitä voidaan siirtää, tallentaa ja käsitellä missä tahansa infrastruktuurissa ilman siirtomekanismivaatimuksia.
Dokumentaatio tietosuojavastaavan hyväksyntää varten
Kun toimitat anonymisoitua koulutusdataa tietosuojavastaavalle hyväksyttäväksi, toimita:
-
Lähdetiedon kuvaus: Mikä oli alkuperäinen tietojoukko, mikä oli sen keräystarkoitus, mitä henkilötietoluokkia se sisälsi?
-
Anonymisointikonfiguraatio: Mitkä yksikkötyypit tunnistettiin ja korvattiin? Mitä menetelmää sovellettiin?
-
Käsittelymetadata: Tunnistettujen yksiköiden määrä tietuetta kohti, tunnistuksen luottamuspisteet, käsiteltyjen tietueiden kokonaismäärä
-
Jäljellä olevan riskin arviointi: Mikä on todennäköisyys, että jokin henkilö voidaan tunnistaa uudelleen anonymisoidusta tietojoukosta?
-
Aiottu käyttö: Mikä ML-malli koulutetaan? Mikä on koulutuksen tarkoitus?
Eräkäsittelyn käsittelymetadata tarjoaa kohdat 2–3 automaattisesti. Kohdat 1, 4 ja 5 vaativat datatutkijan panoksen.
Päätelmä
GDPR-yhteensopiva ML-koulutusdata on saavutettavissa ilman ad hoc -skriptejä, ilman monen päivän suunnitteluviiveitä ja ilman datasarjan hyödyllisyyden uhraamista mallin kouluttamiseksi. Korvaa-anonymisointimenetelmä säilyttää luonnollisen kielen ominaisuudet, jotka tekevät datasta hyödyllistä NLP-mallin kouluttamiseen, samalla kun se poistaa henkilötiedot, jotka luovat GDPR-vastuun.
45 minuutin eräkäsittely on ero aikataulua viivästyttävän vaatimustenmukaisuusarvioinnin ja suoraviivaisen tietosuojavastaavan hyväksynnän välillä.