Enhed 10 / 12

Kundedata og privatliv: KVKK, VUK fortrolighed og sikre værktøjer

Gevinster:

  • Evne til at klassificere skatteyder og økonomiske data inden for rammerne af KVKK og skatteproceslovens fortrolighedsforpligtelse og fastlægge beskyttelsesniveauet
  • Evne til at anvende anonymisering, maskering og sikre/institutionelle værktøjsudvælgelsestrin, før data gives til kunstig intelligens
  • Evne til at få en vane med at undgå uovervåget kørsel ved at kende de juridiske, kriminelle og professionelle konsekvenser af krænkelser af privatlivets fred.

En professionel ser skatteyderens mest intime oplysninger: omsætning, overskud, bankbevægelser, lønninger til medarbejdere, TR-id-numre, kontrakter, partnerskabsstrukturer. Disse oplysninger er beskyttet af to separate juridiske lag: KVKK (lov om beskyttelse af personoplysninger, loven om forbud mod uautoriseret behandling af personoplysninger) og skatteproceslovens fortrolighedspligt (den professionelles pligt til at holde de oplysninger fortrolige, han/hun får kendskab til på grund af sin pligt). I en tidsalder med kunstig intelligens står denne beskyttelse over for en ny trussel: at stikke følsomme data i et ukontrolleret værktøj. Princippet for denne enhed er enkelt: data er beskyttet, før de kommer ind i AI; Ingen følsomme data kommer ind i det uovervågede køretøj.

To-lags beskyttelse og hvorfor det skal tages alvorligt

  • KVKK-lag: Alle oplysninger (navn, TR ID, løn, kontakt) tilhørende rigtige personer er persondata. Uautoriseret behandling, overførsel og utilstrækkelig beskyttelse vil medføre administrative bøder og kompensation.
  • VUK-fortrolighedslag: En professionel kan ikke dele skatteyderens økonomiske hemmeligheder med tredjemand. Overtrædelse har både strafferetlige og faglige (disciplinære) konsekvenser.

En prøvesaldo eller løn, der er indsat i et offentligt tilgængeligt AI-værktøj, kan betragtes som "overført til en tredjepart". Det er ofte uklart, hvordan værktøjet gemmer data, og om det bruges i træning. Alene denne usikkerhed er risiko nok.

OBS: Tanken om, at "ingen vil se det alligevel" er ikke et juridisk forsvar. Når først data kommer ind i et ukontrolleret system, er det uden for din kontrol. Et brud på privatlivets fred er farligt, ikke på grund af muligheden for det, men fordi det er irreversibelt, når det først sker.

Før du giver data til AI: beskyttelsestrin

  1. Klassificer. Er de data, du har personlig, økonomisk hemmelig eller offentlig? Bestem beskyttelsesniveauet i overensstemmelse hermed.
  2. Spørgsmål nødvendighed. Er det virkelig nødvendigt at give denne data til modellen, eller kan opgaven udføres med anonyme/opsummerende data?
  3. Anonymisere/maske. Deres navne er K1, K2; virksomheder Ş1, Ş2; Udskift TR ID og kontonumre med en maske. Generaliser unikke detaljer, der giver indirekte diagnose.
  4. Vælg et sikkert køretøj. Hvis det er muligt, så brug et virksomheds-/godkendt værktøj, der garanterer dataopbevaring.
  5. Hold sporet. Registrer hvilke data du har givet til hvilket værktøj og med hvilken beskyttelse.

Datatype

eksempel

bevaringstilgang

identitetsdata

Navn, TR ID

Maske/anonymisere; aldrig give rå

økonomisk hemmelighed

Omsætning, overskud, bank

Opsummere/anonymisere; virksomhedskøretøj

relationsdata

partner, leverandør

Generaliser; fjerne unikke detaljer

offentlige

opgivet balance

kan behandles normalt

Hvordan foregår anonymisering i praksis?

Anonymisering gør identiteten umulig at skelne, samtidig med at dataene er nyttige. For eksempel vil du få analyseret en lønliste: du sætter et løbenummer i stedet for navn og TR ID, analysen af ​​lønfordelingen bliver ikke forstyrret, men ingen kan identificeres. Det kritiske punkt er den indirekte diagnose: Udtryk som "den eneste kvindelige daglige leder" eller "den eneste 92-årige i et selskab på 35 personer" giver personen væk, selvom man sletter navnet; Disse er også generaliserede.

tre minisager

Case 1 — Lønlækage. En praktikant uploader en lønliste på 3.500 personer (navn, ID-kort, løn) til et gratis webværktøj og siger "opsummer". Data risikerer at blive blandet ind i køretøjets depot; Både KVKK og VUK brud på fortroligheden. Hvis kunden finder ud af det, er det slut. Den rigtige måde var at bruge et virksomhedsgodkendt køretøj eller kun at give lønfordelingen ved at maskere dit navn/TR ID.

Tilfælde 2 — Indirekte diagnose. En konsulent giver modellen en liste, hvori han sletter navnene, men efterlader sætningen "virksomhedens eneste udenlandske leder." Denne udtalelse giver personen væk; Anonymisering mangler. Lektion: unikke detaljer, der giver indirekte diagnose, bør også generaliseres.

Tilfælde 3 — God håndtering. Før følsomme data tilføres modellen, gennemgår et kontor et standardanonymiseringstrin: ved hjælp af en skabelon konverterer det navne, id'er og mærkenavne til koder og får det derefter analyseret. Kvaliteten af ​​analysen falder ikke, ingen identitet er lækket. Privatliv og effektivitet er beskyttet sammen.

Svag prompt / Stærk prompt

Svag prompt:

Opsummer følgende lønsum: [Ahmet Yılmaz, TC 123..., løn 45.000; ...]

Rå personlige data kommer ukontrolleret ind i køretøjet; Det er en direkte krænkelse.

Kraftig prompt:

Jeg giver dig et datasæt. FØR behandlingen skal du anvende følgende anonymisering og også vise mig den anonymiserede version:- Gør personnavnene K1, K2... - Fjern TR ID og kontonumre helt.- Gør firma-/varemærkenavnene T1, K2.... Generaliser de unikke detaljer, der indirekte kunne identificere personen. Arbejd så kun på den anonyme version.[DATA (maskeret så meget som muligt): ...]

Bemærk: Det er sikrest slet ikke at indtaste rå personlige data; Hvis du kommer ind, skal du være maskeret og i et sikkert køretøj.

For hjælp til dataklassificering:

Klassificer hvert af følgende felter: er det personlige data, er det en økonomisk hemmelighed, er det offentlige? Skriv det anbefalede beskyttelsesniveau for hver. Felter: [feltnavne, prøve RETURN]

Sådan genererer du en anonymiseringsskabelon:

Lav en standard tjekliste for anonymisering, som jeg vil bruge i en løn-/prøvebalanceanalyse: hvilke felter skal maskeres, hvilke skal udelades, hvad skal jeg kigge efter for indirekte diagnose?

For køretøjssikkerhedsvurdering:

Hvilke spørgsmål skal jeg stille, når jeg vurderer, om et AI-værktøj er egnet til følsomme skatteyderdata (dataopbevaring, brug i uddannelse, virksomhedskontrakt, placering)? Opret en tjekliste.

Almindelige fejl

  • Indtastning af rå personlige data. Gå aldrig ind i køretøjet uden bekræftelse af navn/TR ID.
  • Springer indirekte diagnose over. Den unikke detalje giver identiteten væk, selvom navnet slettes.
  • Spørger ikke om køretøjets sikkerhed. Følsomme data gives ikke uden at vide, hvordan værktøjet gemmer dataene.
  • Ikke at stille spørgsmålstegn ved nødvendigheden. Hvis opgaven kan udføres med anonyme/opsummerende data, gives der slet ikke rådata.
  • Holder ikke styr. Hvis det ikke er registreret, hvilke data der er givet hvor, kan bruddet ikke spores.

Sammenfattende

Skatteyderdata er beskyttet i to lag af både KVKK- og VUK-fortrolighedsforpligtelser, og den største nye risiko i en tidsalder med kunstig intelligens er at klæbe følsomme data til et ukontrolleret værktøj. Før data indtastes i modellen, klassificeres de, der sættes spørgsmålstegn ved dets nødvendighed, identifikatorer som navn/TR ID maskeres, og detaljer, der giver indirekte diagnose, generaliseres; Hvis det er muligt, bruges kun et sikkert, dataopbevarings-garanteret virksomhedsværktøj. Et brud på privatlivets fred er en uoprettelig skade; De mest sikre data er data, der aldrig indtastes.

Ansøgningsopgave

Tag en typisk følsom fil (f.eks. løn eller prøvesaldo) i hånden. Klassificer først deres felter (personlig/økonomisk hemmelighed/offentlig). Anvend derefter en anonymiseringsskabelon: skriv hvilke områder du vil maskere, hvilke du vil fjerne, og hvad du vil kigge efter for indirekte identifikation. Til sidst skal du evaluere sikkerhedsegnetheden af ​​det kunstige intelligensværktøj, du bruger/vil bruge, med en tjekliste.

tjekliste

  • [ ] Jeg har klassificeret dataene som personlig/økonomisk hemmelighed/offentlig.
  • [ ] Jeg satte spørgsmålstegn ved, om det virkelig var nødvendigt at levere de rå data.
  • [ ] Jeg maskerede/fjernede navnet, TR ID og kontonumre.
  • [ ] Jeg har generaliseret unikke detaljer, der giver indirekte diagnose.
  • [ ] Jeg har kun brugt sikre/virksomhedsværktøjer med dataopbevaringsgarantier.
  • [ ] Jeg evaluerede datapolitikken (opbevaring, træning) af værktøjet.
  • [ ] Jeg registrerede, hvilke data jeg gav hvor som et spor.