V odbornej diskusii o ochrane osobných údajov pri využívaní generatívnej AI sa čoraz častejšie objavuje tvrdenie, že na zabezpečenie súladu s právnymi predpismi je „nutné upraviť architektúru AI“. Tento argument znie presvedčivo – evokuje predstavu, že samotný model alebo jeho technická podstata predstavujú primárny problém, ktorý je potrebné technicky prebudovať. Realita je však podstatne zložitejšia.
Kde sa v AI v skutočnosti odohráva spracúvanie údajov
Väčšina organizácií dnes neprevádzkuje vlastné veľké jazykové modely (LLM). Organizácie využívajú generatívnu AI globálnych poskytovateľov v troch základných režimoch: vo verejnom (public) režime, v hybridnom modeli nasadenia (deployment) a v enterprise (self-hosted) režime založenom na osobitnom licenčnom a zmluvnom nastavení. V súčasnosti organizácie prevažne využívajú verejný (public) režim, v ktorom je model aj jeho výpočtová infraštruktúra plne pod kontrolou a prevádzkou poskytovateľa služby.
Architektúra samotného LLM je v takýchto prípadoch mimo technického dosahu zákazníka. To však neznamená, že je mimo jeho zodpovednosti ako prevádzkovateľa. Organizácia nesie zodpovednosť za výber poskytovateľa, za zmluvné rámcovanie spracúvania osobných údajov a za určenie rozsahu údajov vstupujúcich do systému, bez ohľadu na to, či má možnosť zasahovať do vnútornej štruktúry modelu.
Dodržiavanie zásad spracúvania osobných údajov a výkon práv dotknutých osôb podľa GDPR sa nezabezpečujú „vo vnútri modelu“, ale riadením dátových tokov, integračných vrstiev a prevádzkových nastavení na perifériách systému, v ktorom je model používaný.
Nasledujúci blokový diagram znázorňuje základnú logickú architektúru generatívnej AI so zameraním na vzťahy medzi komponentmi a najmä na miesta vzniku a ukladania dát.
Uvedená schéma je zámerne zjednodušená pre potreby tohto výkladu. V reálnej prevádzke je aplikačná architektúra generatívnej AI podstatne komplexnejšia a zahŕňa množstvo ďalších komponentov a procesov vrátane odvodených reprezentácií vstupov používateľa (napr. promptových štruktúr, vektorových reprezentácií – embeddingov, prevádzkových logov či mechanizmov spätnej väzby využívaných pri dolaďovaní modelov), ako aj orchestráciu požiadaviek, pamäťové a kontextové vrstvy, vyhľadávacie mechanizmy (napr. RAG), vektorové databázy, bezpečnostné a validačné filtre, autentizačné a autorizačné mechanizmy, monitoring, auditné záznamy a integračné API rozhrania.
Generatívna AI v praxi nepredstavuje len jednoduchú schému „model + vstup + výstup“, ale viacvrstvový systém so samostatnými bezpečnostnými, dátovými a riadiacimi komponentmi, ktoré spoločne určujú spôsob spracúvania údajov.
Vstup používateľa je spracovaný aplikačnou vrstvou a odoslaný modelu na inferenciu (t. j. na vykonanie modelu a generovanie výstupu na základe vstupu); ak to konkrétny režim služby umožňuje, môžu byť vstupné údaje alebo celá interakcia uchovávané a následne použité ako súčasť dát využívaných na dolaďovanie alebo ďalší tréning modelu.
Systém v rámci spracovania generuje odvodené vektorové reprezentácie vstupov (embeddingy) a ďalšie interné dátové štruktúry vrátane prevádzkových metadát, ako sú časové údaje, identifikátor požiadavky, objem spracovaných tokenov alebo stav spracovania.
Ak je v danom režime služby umožnený zber interakcií, tieto údaje môžu byť uchovávané a následne zaradené do mechanizmov spätnej väzby vrátane datasetov využívaných na zlepšovanie kvality modelu alebo jeho ďalšie dolaďovanie.
Tréningové dátové súbory sú spravidla uchovávané a spracúvané v oddelených prostrediach mimo produkčnej prevádzky; ich využitie vedie k aktualizácii modelových parametrov ako celku, nie k úprave jednotlivých záznamov.
Z hľadiska ochrany osobných údajov je rozhodujúci práve posledný bod. Ak sa vstupné údaje stanú súčasťou tréningových datasetov a následne sa premietnu do modelových parametrov, prestávajú byť pod priamou kontrolou používateľa. Ich individuálne odstránenie už nemožno redukovať na jednoduchý úkon vymazania konkrétneho záznamu, pretože údaje sa v rámci tréningového procesu transformujú do vektorových a následne parametrických reprezentácií modelu. Nejde už o identifikovateľný záznam obsahujúci potenciálne osobné údaje. Zo záznamu sa stáva matematická reprezentácia rozptýlená v modelových parametroch prostredníctvom aktualizácie váh neurónovej siete, ktorú nemožno izolovať bez zásahu do modelu ako celku.
Technická realizácia „zabudnutia“ konkrétnych informácií týkajúcich sa identifikovanej alebo identifikovateľnej fyzickej osoby je po ich zapracovaní do tréningu neuskutočniteľná. Keďže tieto informácie už neexistujú ako samostatné údaje, ale ako súčasť matematickej štruktúry modelu, ich „zabudnutie” by nebolo možné bez zásadného zásahu do modelu alebo jeho pretrénovania. Experimentálne metódy machine unlearning existujú zatiaľ iba teoreticky.
Treba však dodať, že v moderných enterprise režimoch prevádzkovania AI k takémuto využívaniu zákazníckych vstupov na tréning základných modelov nedochádza, prípadne je možné ho konfiguračne vylúčiť. Riziko sa potom v enterprise režime viaže najmä na prípady, keď je tréning alebo dolaďovanie zo vstupných dát explicitne povolené.
Z technického hľadiska platí jednoduché pravidlo: údaje, ktoré používateľ do systému vloží, podliehajú spracúvaniu v rámci architektúry systému navrhnutej poskytovateľom. Používateľ pritom nemá možnosť zasahovať do vnútornej štruktúry modelu ani do jeho tréningových mechanizmov.
Ako v praxi chrániť osobné údaje v AI
Ak akceptujeme, že architektúra samotného LLM je mimo dosahu používateľa, potom sa ťažisko ochrany osobných údajov presúva inam. Praktická otázka preto neznie, ako zmeniť model, ale ako identifikovať a riadiť konkrétne spracovateľské operácie v rámci jeho používania.
Ide najmä o:
vstupy používateľov,
logovanie a monitoring,
pamäťové mechanizmy a konverzačné úložiská,
retenčné politiky,
zmluvné nastavenie rolí,
prípadné sekundárne využitie dát na tréning alebo zlepšovanie služby.
Inými slovami: rozhodujúci je spôsob integrácie modelu do podnikovej architektúry a spôsob práce s dátami. Bez ohľadu na to, v akom režime je generatívna AI implementovaná (public, hybridný alebo enterprise).
Základný princíp: „nekŕmiť AI“
Z technického pohľadu najspoľahlivejším preventívnym opatrením, ako zabrániť neoprávnenému spracúvaniu osobných údajov, je to najjednoduchšie – neposkytovať systému údaje, ktoré tam nemajú byť.
Ak osobný údaj nevstúpi do systému, nebude:
zaznamenaný v logoch,
zahrnutý do odvodených vektorových reprezentácií v LLM,
uložený v pamäti, ani v úložisku konverzačnej histórie.
V takomto prípade sa nemôže stať predmetom budúceho neoprávneného spracúvania.
Treba však rozlišovať medzi údajmi, ktoré do systému vedome vkladá používateľ, a údajmi, ktoré môže model generovať na základe svojho predtrénovaného korpusu alebo odvodiť inferenciou.
Rovnako v architektúrach typu RAG (Retrieval-Augmented Generation) môže dochádzať k spracúvaniu údajov z interných úložísk, aj keď nie sú priamo súčasťou promptu. V takomto modeli systém pred generovaním odpovede vyhľadáva relevantné informácie v externých alebo interných dátových zdrojoch (napr. dokumentových úložiskách či databázach) a tieto údaje následne vkladá do kontextu modelu ako súčasť vstupu. Model tak môže spracúvať aj osobné údaje obsiahnuté v interných systémoch organizácie, hoci ich používateľ výslovne nezadal.
Prevencia vstupu dát je účinnejšia než následné pokusy o ich kontrolu alebo mazanie. Ide o princíp minimalizácie, nie o absolútne vylúčenie rizika.
V kontexte veľkých modelov sa výkon práva na výmaz môže stať technicky extrémne komplikovaným, najmä ak boli údaje použité pri tréningu. V dobe AI sa musíme definitívne prestať spoliehať na právo na zabudnutie.
A) Konfiguračné a zmluvné opatrenia
Pri využívaní verejných alebo enterprise SaaS riešení je potrebné využiť všetky dostupné konfiguračné možnosti a zmluvné nástroje, najmä:
vypnutie režimu „model improvement“,
deaktivovanie „data sharing“ nastavení,
vypnutie ukladania histórie konverzácií,
obmedzenie retenčnej doby,
explicitné zmluvné vylúčenie použitia zákazníckych dát na tréning alebo zlepšovanie modelu.
Všetky predchádzajúce opatrenia závisia od licenčnej politiky poskytovateľa modelu. Tieto opatrenia nemenia architektúru modelu, iba obmedzujú rozsah spracovania, ktoré poskytovateľ vykonáva.
B) Architektonické zmeny na strane zákazníka
Verejný SaaS model typicky nemení architektúru pre konkrétneho zákazníka. Zmena sa realizuje na strane používateľa, najmä:
vložením lokálnej kontrolnej vrstvy pred API (napr. DLP filter, validačné pravidlá),
oddelením dokumentových úložísk a vyhľadávacích mechanizmov od samotného modelu,
centralizovaným riadením prístupov a evidenciou používania,
obmedzením priamych prístupov používateľov k verejnému rozhraniu služby.
V prípade verejných alebo enterprise SaaS riešení teda nejde o úpravu architektúry samotného modelu, ale o úpravu architektúry podnikového informačného systému tak, aby sa minimalizovali rizikové vstupy a nekontrolované dátové toky.
C) Špecifiká architektúry RAG
Osobitnú pozornosť si vyžadujú architektúry typu RAG (Retrieval-Augmented Generation), pri ktorých model pred generovaním odpovede vyhľadáva relevantné informácie v externých alebo interných dátových zdrojoch a tieto údaje následne vkladá do kontextu ako súčasť vstupu. RAG nie je len funkčné rozšírenie modelu, ale rozšírenie architektúry spracúvania údajov.
V takomto prípade vzniká nový dátový tok medzi internými úložiskami organizácie a modelom, ktorý predstavuje samostatnú spracovateľskú operáciu.
Implementácia RAG preto vyžaduje osobitné technické a organizačné opatrenia, najmä:
selekciu a obmedzenie dokumentov určených na indexáciu,
zosúladenie digitálnych identít vyhľadávacích mechanizmov s existujúcimi prístupovými právami používateľov,
segmentáciu a retenčné pravidlá dátových zdrojov,
auditovateľnosť retrieval operácií,
kontrolné mechanizmy brániace generovaniu nadmerných alebo neoprávnených osobných údajov.
Čo na to regulácia?
Právo vždy bolo a bude do určitej miery „druhé v poradí“ voči spoločenským potrebám a realite. Nie preto, že by bolo menej dôležité, ale preto, že prirodzene reaguje ex post – na svoje materiálne pramene, na to, čo už v praxi vzniklo a čo spoločnosť potrebuje upraviť.
Práve preto nemôže byť nikdy úplne všeobjímajúce ani detailne vysvetľujúce všetky technické nuansy. A v oblastiach, ktoré sa vyvíjajú exponenciálne – ako IT, kybernetická bezpečnosť či AI – to ani nikdy nebude možné.
Právo iba reaguje – opisuje a kodifikuje to, čo už v spoločnosti vzniklo. Netvorí spoločenskú realitu, ale ju reflektuje.
Regulačný rámec Európskej únie teda túto otázku nerieši do detailu. Podľa materálu Orientations for ensuring data protection compliance when using Generative AI systems, od EDPS sa názor právnikov (v tomto prípade) od môjho až tak výrazne nelíši.
Výkon práv dotknutých osôb – vrátane práva na výmaz alebo opravu – je zabezpečiteľný. Tento predpoklad je normatívny. Vyjadruje stav, ktorý má byť dosiahnutý. Moje tvrdenia nespochybňujú existenciu ani platnosť tohto práva. Poukazujú však na rozdiel medzi formálnou vykonateľnosťou práva a jeho technickou realizovateľnosťou v architektúre veľkých generatívnych modelov.
Právo na výmaz vznikalo v prostredí klasických informačných systémov, kde osobné údaje existujú ako identifikovateľné záznamy v databázach. V takomto prostredí je možné konkrétny údaj lokalizovať, odstrániť a následne preukázať, že zásah bol vykonaný. Generatívny model však funguje odlišne. Neuchováva údaje ako samostatné záznamy, neobsahuje „riadky“ ani „dokumenty“ a nepracuje so štruktúrovanými entitami. Informácie sú absorbované do distribúcie váh a pravdepodobností v parametrovom priestore.
Po tréningu už neexistuje priamy mapovateľný vzťah medzi konkrétnym dátovým bodom a konkrétnou časťou modelu. Údaj sa nestáva lokalizovateľným objektom, ale súčasťou matematickej reprezentácie. Technická otázka preto neznie, či je výmaz právne požadovaný, ale či je determinovateľné, čo presne má byť z modelu odstránené.
Regulačný diskurz zároveň predpokladá existenciu postupov na výkon práv. V technologickej realite však neexistuje štandardizovaný a všeobecne aplikovateľný mechanizmus selektívneho odstránenia konkrétneho tréningového údaja z foundation modelu s miliardami parametrov. Koncept tzv. “machine unlearning” je predmetom výskumu, no nie je operačným štandardom komerčných LLM pipeline, nie je preukázateľne škálovateľný a neexistuje univerzálna metodika, ktorá by umožnila verifikovať, že model daný údaj skutočne „zabudol“.
Ak je jediným spoľahlivým riešením re-tréning modelu bez sporných dát, ide o zásah, ktorý je extrémne nákladný, časovo náročný a mimo kontroly bežného používateľa SaaS služby. Tento stav nie je otázkou regulačnej ochoty, ale architektúrneho limitu súčasných modelov.
Regulačné texty pracujú aj s hypotézou, že model nemusí byť zmenený, pokiaľ „neobsahuje“ konkrétny údaj alebo z neho nemožno údaje inferovať. Problém je, že inferenčná schopnosť modelu je probabilistická. Nie je binárna. Model môže určitú informáciu reprodukovať v špecifickom kontexte, pri určitom type promptu alebo kombinácii vstupov. Negatívny stav – teda že model už konkrétnu informáciu nedokáže reprodukovať – nie je objektívne preukázateľný bez rozsiahleho a prakticky neobmedzeného testovania.
Rovnako je potrebné rozlišovať medzi úrovňou datasetu a úrovňou modelu. Tréningový dataset možno upraviť, konkrétny záznam z neho odstrániť a budúci tréning môže prebehnúť bez daného údaja. To však neznamená, že už existujúci model bol efektívne „vyčistený“. Výmaz na úrovni datasetu nie je automaticky výmazom na úrovni modelu.
Z prevádzkového pohľadu je situácia ešte problematickejšia. Bežná organizácia, ktorá využíva GenAI ako službu, nekontroluje tréning základného modelu, nemá nástroje na parametrový zásah a nevie nezávisle overiť, že k selektívnemu „zabudnutiu“ skutočne došlo. Ak je výkon práva závislý od zásahu, ktorý je mimo jej kontroly, ekonomicky neprimeraný a technicky neistý, potom je jeho praktická realizácia v bežnom SaaS prostredí výrazne obmedzená.
Regulácia EÚ definuje cieľ – zabezpečiť výkon práv. Architektúra foundation modelov však môže vytvárať hranicu, ktorá tento cieľ robí dosiahnuteľným iba čiastočne. Moje použitie silnej formulácie o „neuskutočniteľnosti“ nie je odmietnutím právneho rámca. Je poukázaním na fakt, že po zapracovaní údajov do váhového priestoru modelu neexistuje jednoznačný, deterministický a overiteľný mechanizmus ich selektívneho odstránenia.
V tejto realite sa ako najspoľahlivejší nástroj ochrany práv javí nie ex post zásah, ale ex ante minimalizácia vstupu osobných údajov. Nejde o popretie práva na výmaz. Ide o konštatovanie, že v architektúre generatívnych modelov je prevencia systematicky účinnejšia než dodatočný zásah do už natrénovaného systému.
Záver
Ak chceme viesť odbornú a zodpovednú diskusiu, je potrebné oddeliť mýty od technickej reality. Predovšetkým je potrebné si uvedomiť, že ochrana osobných údajov v kontexte GenAI sa neodohráva „vo vnútri modelu“, ale v jeho integračnom, dátovom a prevádzkovom okolí. Kľúčovou otázkou preto nie je, či treba meniť architektúru umelej inteligencie ako takej, ale kde presne v reálnom technickom a organizačnom kontexte dochádza ku spracúvaniu osobných údajov.
Pri využívaní štandardných SaaS riešení globálnych poskytovateľov generatívnej AI zákazník architektúru základného modelu meniť nemôže. Diskusia o „nutnej zmene architektúry AI“ je v týchto prípadoch bezpredmetná. Organizácia však môže – a musí – upraviť vlastné procesy, integračné vrstvy, konfiguračné nastavenia a pravidlá práce s dátami. Ochrana osobných údajov tu nezačína rekonštrukciou modelu, ale rozhodnutím, aké údaje do systému vstúpia a akým spôsobom budú ďalej spracúvané.
Odlišná situácia nastáva pri self-hosted modeloch, vlastnom fine-tuningu, budovaní embedding pipeline alebo implementácii RAG architektúr. V takýchto scenároch organizácia zasahuje do architektúry AI systému ako celku a zodpovedá nielen za integračné vrstvy, ale aj za samotné modelové a dátové komponenty. Diskusia o úprave architektúry AI je preto relevantná práve tam, kde organizácia architektúru reálne navrhuje, konfiguruje alebo modifikuje.
Právo na výmaz v kontexte generatívnej AI zostáva normatívne platné. Otázkou však je jeho technická vykonateľnosť v parametrových modeloch veľkého rozsahu – a práve na tento rozdiel moje tvrdenia upozorňujú.
Pragmatický záver je zrejmý:ochrana osobných údajov pri používaní generatívnej AI nezačína rekonštrukciou modelu, ale rozhodnutím, aké údaje do systému vstúpia. V konečnom dôsledku ide o dátovú disciplínu, nie o zmenu architektúry LLM.
