UI in osebni podatki: kaj je dovoljeno in kaj prinese globo

TL;DR. Če vaš projekt z umetno inteligenco obdeluje osebne podatke ljudi v EU, zanj velja splošna uredba o varstvu podatkov (GDPR). Skladnosti v večini primerov ne zagotovite z „izbiro prave oblačne storitve“, temveč z arhitekturo celotne poti podatkov: kje je shranjen dokument, kje so vektorji, kam potuje poziv, kam gre zahteva do velikega jezikovnega modela (LLM) in kdo vidi dnevnike. V nadaljevanju je praktičen pregled vzorcev, ki prestanejo presojo, in tistih, ki je ne. Opira se na izkušnje ekipe SINTARIS pri uvajanju sistemov RAG v EU.

1. Problem: „Povežimo ChatGPT z našim CRM-jem“

To željo slišimo skoraj pri vsakem prvem projektu. Podjetje že ima CRM z imeni strank in telefonskimi številkami, včasih tudi z zdravstvenimi ali finančnimi podatki. Nekdo je videl predstavitev ChatGPT-ja in naloga se glasi: „Uredite tako, da bo prodajnik vprašal, sistem pa mu bo odgovoril.“

Tehnično je to dva dni dela. Pravno pa to pomeni tveganje globe do 4 % skupnega letnega prometa na svetovni ravni (83. člen GDPR). Grožnja ni teoretična: nadzorni organi, kot so Informacijski pooblaščenec (IP-RS) v Sloveniji, BfDI v Nemčiji in Garante v Italiji, že izrekajo globe zaradi „posredovanja osebnih podatkov tretjim osebam brez pravne podlage“.

S tem člankom želimo pokazati, da meja ne poteka tam, kjer jo običajno zarišemo („OpenAI = slabo, lokalni LLM = dobro“). Odloča to, kako natančno podatki tečejo skozi sistem, kdo je upravljavec in kdo obdelovalec ter kje morate imeti dokumentirano pravno podlago.

2. Za koga je to pomembno

• Mala in srednja podjetja s podatki strank: klinike, šole, odvetniške pisarne, agencije, prodaja B2B, vsaka spletna trgovina.
• Zagonska podjetja, ki so GPT „na hitro vgradila“ v svoj izdelek, pravni pregled pa odložila na pozneje.
• Vodje IT-oddelkov, ki jim vodstvo prinese zamisel o UI-asistentu in vpraša: „Kdaj ga uvedemo?“
• Samostojni svetovalci in strokovnjaki, ki svoje znanje prodajajo prek UI-bota z naročnino.

Če v vašem scenariju ni niti enega imena stranke, e-poštnega naslova, številke bančnega računa ali diagnoze, tega članka ne potrebujete. Če je v njem kar koli od tega, ga potrebujete.

3. Pogosta napaka

Vzorec, ki smo ga videli že več desetkrat:

1. Izvoz CRM-ja v CSV.
2. Uvoz v indeks RAG s standardnim delovnim tokom v n8n.
3. Nad tem klic modela gpt-4o prek API-ja OpenAI.
4. Prodajnik v Telegramu napiše: „O čem smo se prejšnji mesec pogovarjali z Novakom?“ in bot odgovori.
5. Vse deluje, predstavitev uspe, naročnik je zadovoljen.

Zakaj je to z vidika nadzornih organov nesprejemljivo:

• Posredovanje osebnih podatkov tretjim osebam brez pravne podlage. OpenAI postane obdelovalec, vendar brez pogodbe o obdelavi podatkov (DPA) in brez analize, kje fizično stojijo strežniki, kako dolgo se zahteve hranijo (privzeto se hranijo) in kdo ima dostop do njih.
• Namen obdelave ni opredeljen in dokumentiran. GDPR za vsako kategorijo podatkov zahteva izrecen in dokumentiran namen. „Da bo prodajniku lažje“ ni namen.
• Kršeno je načelo najmanjšega obsega podatkov. V indeks je šlo bistveno več podatkov, kot jih je treba za odgovore na določeno vrsto vprašanj.
• Ocena učinka v zvezi z varstvom podatkov (DPIA) ni bila izvedena, čeprav je pri „sistematični avtomatizirani obdelavi velikih količin osebnih podatkov“ obvezna (35. člen GDPR).

4. Tehnični pristop: kje potegniti mejo

Misel, ki jo ponovimo pri vsaki presoji: meja osebnih podatkov v sistemu UI mora biti vidna na arhitekturni shemi. Če je na shemi ni videti, je tudi v sistemu ni.

Osnovni model, ki ga uporabljamo:

[Surovi podatki] → [Sloj anonimizacije] → [Indeksiranje RAG]
                                         ↓
                                [Samo anonimni vektorji]
                                         ↓
                                [Zahteva za LLM: brez imen]

Štirje pristopi, razvrščeni po stopnji zaščite podatkov:

4.1. Kdaj je ocena učinka (DPIA) obvezna

Po 35. členu GDPR je ocena učinka potrebna pri:

• sistematičnem ocenjevanju osebnih vidikov z avtomatizirano obdelavo,
• obsežni obdelavi posebnih vrst osebnih podatkov,
• sistematičnem obsežnem spremljanju javno dostopnih območij.

Za sisteme UI to pomeni: skoraj vedno, ko obdelujete podatke iz CRM-ja, zdravstvene podatke ali dnevnike komunikacije.

Ocena učinka za sistem RAG mora vsebovati vsaj:

1. Opis obdelave in njenih namenov.
2. Ocena sorazmernosti.
3. Prepoznavanje in ocena tveganj.
4. Ukrepi za obvladovanje tveganj (tehnični in organizacijski).
5. Dokaz, da je bilo pridobljeno mnenje pooblaščene osebe za varstvo podatkov.

5. Arhitekturni vzorci, ki prestanejo presojo

Vzorec 1: v celoti lokalna namestitev (priporočljivo za regulirane panoge)

Vse komponente tečejo na infrastrukturi stranke: Ollama za izvajanje LLM-ja, pgvector za vektorje, MinIO za dokumente. Noben podatek ne zapusti notranjega omrežja. Glavna težava z vidika GDPR je s tem praktično rešena, saj podatkov ne posredujemo tretjim osebam.

Vzorec 2: hibridna arhitektura (v oblak gre le neobčutljiv kontekst)

Oblačnemu LLM-ju pošiljamo samo anonimiziran kontekst ali kontekst brez osebnih podatkov. Deli baze z osebnimi podatki ostanejo lokalno. To omogoča usmerjevalni sloj, ki občutljiv kontekst obdela lokalno.

Vzorec 3: oblak s popolno dokumentacijo o skladnosti

Kadar lokalna namestitev ni mogoča, z vsakim ponudnikom oblaka podpišite DPA, za vsako kategorijo podatkov dokumentirajte pravno podlago, izvedite in dokumentirajte oceno učinka, pri prenosih v tretje države pa uporabite standardne pogodbene klavzule (SCC).

6. Primer iz prakse SINTARIS

Izdelka Maria (obveščanje o terminih v kliniki) in Clinic assistant ta pristop pokažeta v praksi. Naloga: pacient naj lahko prek Telegrama potrdi ali prestavi termin in prejme kopijo recepta. Običajna skušnjava je vzeti gpt-4o-mini in mu predati celoten CRM iz PostgreSQL, pa je zadeva urejena.

Tehnična izvedba:

• LLM uporabljamo samo za razvrščanje namena (confirm / reschedule / cancel / question / emergency).
• V poziv gredo vrsta sporočila (besedilo ali govor → prepis), ime pacienta (brez priimka) in kraj. Brez diagnoz, brez receptov, brez številk zavarovanja.
• Rezervacijo pa opravi deterministična koda, ki iz koledarja prebere proste termine in rezervacijo zapiše neposredno v CRM.
• Izdaja recepta je ločen potek: pacient se prijavi z enkratno kodo, dokument prejme po varnem kanalu, dogodek pa se zapiše v revizijsko sled.

Rezultat: stroški LLM znašajo približno 2 € na mesec (pri razvrščanju gre za kratke zahteve), klicev na recepcijo je za 40–50 % manj, pravna dokumentacija pa obsega eno stran, ker osebni podatki fizično ne zapustijo zaščitenega okolja.

Arhitekturne podrobnosti so opisane v bazi znanja: Clinic assistant § 9 „Security & data boundary“.

7. Kontrolni seznam (15 točk) pred začetkom projekta z UI, ki obdeluje osebne podatke

1. Pravna podlaga je opredeljena za vsako kategorijo podatkov (6. člen GDPR).
2. Ocena učinka (DPIA) je izvedena in dokumentirana, kjer je potrebna.
3. DPA je podpisana z vsakim zunanjim ponudnikom, ki ima dostop do podatkov.
4. Najmanjši obseg podatkov: samo to, kar je nujno za namen obdelave.
5. Lokacija hrambe: fizična lokacija strežnika je dokumentirana za vsako kategorijo podatkov.
6. Roki hrambe dnevnikov in vektorjev so določeni in tehnično uveljavljeni.
7. Razvrstitev podatkov: kateri podatki spadajo med posebne vrste po 9. členu GDPR?
8. Anonimizacija ali psevdonimizacija pred pošiljanjem v oblačni LLM.
9. Postopek za zahteve posameznikov (dostop, izbris, popravek) je vgrajen v kodo.
10. Revizijska sled: nespremenljiva in z določenim rokom hrambe.
11. Nadzor dostopa na ravni podatkovne baze (RLS, ne le na ravni aplikacije).
12. Šifriranje podatkov v mirovanju in med prenosom.
13. Ocena tveganj dobaviteljev za vsako storitev UI, ki jo sistem uporablja.
14. Postopek ob kršitvi varstva podatkov: kako kršitev zaznamo in prijavimo?
15. Vključena pooblaščena oseba za varstvo podatkov (kadar jo GDPR zahteva).

8. Tveganja

• Past „anonimizacija zadošča“. Slabo anonimizirane podatke (odstranjeno je le ime, ostane pa kombinacija naslova, poklica in starosti) je mogoče znova povezati z osebo. Preverite, kolikšno je pri vašem pristopu tveganje ponovne identifikacije.
• Vektorji kot osebni podatki. Vektorske vložitve (embeddings) je mogoče delno pretvoriti nazaj v besedilo (Morris et al., 2023). Vektorske baze zato obravnavajte kot zbirke osebnih podatkov.
• Hramba dnevnikov LLM. Preverite, kako vaš ponudnik oblačnega LLM-ja beleži zahteve. Mnogi pozive privzeto shranjujejo, in tudi to je posredovanje podatkov.
• Širjenje obsega. Projekti, ki se začnejo s „samo notranjimi dokumenti“, v šestih mesecih pogosto že vsebujejo podatke strank. Postopek upravljanja zato vzpostavite že na začetku.

9. Kaj storiti naprej

Če rešitev z UI že uporabljate in niste prepričani, ali je skladna s predpisi, je prvi korak analiza priložnosti za UI. Pregledamo arhitekturo, prepoznamo poti podatkov in pripravimo seznam ukrepov, razvrščenih po pomembnosti.

Če začenjate nov projekt, pri pilotu z UI (4–8 tednov) arhitekturo, skladno s predpisi, vgradimo že od začetka. Obseg in ceno določimo po uvodnem pogovoru (glejte pakete).

10. Viri

• Uredba (EU) 2016/679 (GDPR), zlasti 6., 9., 13., 35. in 83. člen.
• ENISA (2022). Data Protection Engineering: Recommendations for the Implementation of Technical Measures.
• Morris, J. X. et al. (2023). Text Embeddings Reveal (Almost) As Much As Text. arXiv:2310.06349.
• ICO (2023). Guidance on AI and Data Protection.
• Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv:2005.11401.

Ekipa SINTARIS izvaja analize priložnosti za UI, pilote z UI in uvedbe platforme Taris za mala in srednja podjetja v EU. Uvodni pogovor je brezplačen in traja 30 minut.