GDPR 2.0 ir DI: kodėl standartiniai didieji kalbos modeliai negali atitikti duomenų apsaugos teisės

GDPR 2.0 ir DI: kodėl standartiniai didieji kalbos modeliai negali atitikti duomenų apsaugos teisės

Košmaro scenarijus

Štai scenarijus, dėl kurio vyriausieji privatumo pareigūnai ir duomenų apsaugos pareigūnai nemiega naktimis. Tai ne duomenų saugumo pažeidimas. Tai ne įsilaužimas. Tai klientas, įgyvendinantis savo pagrindines teises pagal Europos Sąjungos teisę.

Klientas (pavadinkime jį ponu Šmitu) siunčia jūsų įmonei el. laišką. Jis remiasi Bendrojo duomenų apsaugos reglamento 17 straipsniu: „teise į ištrynimą", paprastai vadinama teise būti pamirštam. Jis nebėra jūsų klientas. Jis nori, kad jo asmens duomenys būtų ištrinti iš visų jūsų sistemų. Jis turi teisinę teisę to reikalauti, o jūs turite 30 dienų įvykdyti reikalavimą.

Jūsų tradicinėms IT sistemoms tai išspręsta problema. Jūsų duomenų bazės administratorius paleidžia scenarijų: DELETE FROM customers WHERE id = 'schmidt_42';. Eilutės išnyksta iš PostgreSQL. Atsarginės kopijos išvalomos pagal jūsų saugojimo grafiką. Žurnalo įrašai anonimizuojami. Jūs siunčiate ponui Šmidtui patvirtinimo el. laišką, kuriame dokumentuojama, kas buvo ištrinta. Atitiktis pasiekta. Procesas kainuoja maždaug 50 EUR administracinių išlaidų.

Tačiau yra problema. Praėjusį ketvirtį jūsų duomenų mokslo komanda panaudojo klientų aptarnavimo žurnalus (įskaitant tūkstančius el. laiškų ir pokalbių įrašų iš pono Šmito per jo 8 metų santykius su jūsų įmone), kad pritaikytų jūsų klientų aptarnavimo dirbtinį intelektą. Šis didelis kalbos modelis įsisavino pono Šmito skundus, jo pristatymo adresus, ginčus dėl mokėjimų, galbūt net medicininę informaciją, kurią jis paminėjo pretenzijoje dėl gamintojo atsakomybės.

Pono Šmito duomenys dirbtiniame intelekte neegzistuoja kaip lentelės eilutė. Jie buvo ištirpinti. Jie buvo suskaidyti į žetonus, paversti didelės dimensijos įterpimo vektoriais ir paskleisti per milijardus slankiojo kablelio svorių. Jie nėra saugomi jokia žmogui suprantama forma. Jie egzistuoja kaip tikimybinė modelio tendencija generuoti tam tikras žetonų sekas, kai jis skatinamas tam tikrais būdais.

You cannot run a SQL query on a neural network. You cannot identify which specific neurons "hold" Mr. Schmidt's shipping address. If you prompt the model with "What is the address for customer schmidt_42?", it might generate it from its dissolved memories. Or it might not. But the data is in there, baked into the mathematical structure of the model's weights.

To truly "delete" Mr. Schmidt's data, you would have to destroy the model entirely and retrain it from scratch, carefully excluding all data associated with him. If that model cost EUR 5 million and took three months to train on a cluster of H100 GPUs, a single GDPR request from a single customer has just become a financial catastrophe.

And you have 2 million customers. What happens when the next deletion request arrives tomorrow? And the next one the day after?

The Legal Reality: GDPR Article 17 in Detail

Article 17 of the GDPR is unambiguous. It states that "the data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay."

The regulation defines erasure as making the data "no longer available." European courts and data protection authorities have consistently interpreted this as requiring actual deletion, not merely hiding or deactivating the data. The data must be destroyed in a way that makes recovery impossible.

For neural networks trained on personal data, this creates an impossible situation:

• The data is not "stored" in any recoverable form. It has been transformed into statistical patterns distributed across billions of parameters.
• There is no "delete" operation. Neural network architectures provide no mechanism for removing the influence of specific training examples.
• Retraining is economically prohibitive. For large models, complete retraining costs millions of euros and takes months.
• Partial retraining does not work. Techniques like "machine unlearning" cannot provably remove data. The ghost of the data remains detectable.

The legal consequences are severe. GDPR violations can result in fines up to EUR 20 million or 4% of global annual turnover, whichever is higher. For a large enterprise, a systematic inability to comply with deletion requests could result in billions in liability.

Why "Machine Unlearning" is a False Promise

The academic computer science community has been frantically working on a field called "machine unlearning." The goal is to develop algorithms that can surgically update model weights to "forget" specific training examples without requiring full retraining.

This sounds promising. In practice, it is an unsolved problem for large models, and likely unsolvable given fundamental mathematical constraints.

Problem 1: Catastrophic Forgetting

Neural networks learn by adjusting weights to minimize prediction error across the entire training dataset. The weights encode overlapping, distributed representations. Attempting to surgically modify weights to remove one piece of knowledge typically damages the structural integrity of related knowledge.

Researchers have found that unlearning attempts cause "catastrophic forgetting" where the model loses capabilities far beyond the targeted data. A model trained on customer service data might "forget" how to form grammatically correct sentences after an unlearning procedure targeting a single customer.

Problem 2: Verification is Impossible

Even after an unlearning procedure, how do you prove the data is truly gone? Sophisticated attacks like Membership Inference Attacks and Model Inversion Attacks can detect whether specific data was part of the training set. Research has shown that current unlearning techniques fail these tests. The statistical signature of the training data remains detectable.

If a regulator audits your model and finds that, despite your "unlearning" procedure, the model still exhibits patterns characteristic of Mr. Schmidt's data, you are non-compliant. The burden of proof is on you to demonstrate complete erasure, and with current technology, that proof cannot be provided.

Problem 3: Legal Precedent

European data protection authorities have not yet formally ruled on whether machine unlearning satisfies GDPR requirements. However, the trend of enforcement suggests they will demand demonstrable, verifiable deletion. "We ran an algorithm that probably reduced the data's influence" is unlikely to satisfy regulators accustomed to the certainty of database DELETE statements.

The Architectural Solution: Separation of Reasoning and Data

At Dweve, we recognized early that machine unlearning is a trap. You cannot solve an architectural problem with algorithmic patches. The solution is to design AI systems where the problem never exists in the first place.

Our approach is based on a fundamental architectural principle: strict separation of reasoning capabilities from personal data. The AI model contains intelligence (the ability to reason, analyze, and generate). Personal data lives in separate, governable storage systems where it can be properly managed, audited, and deleted.

Principle 1: Constraint-Based Models Without Personal Data

Dweve's foundation models are built using Binary Constraint Discovery, not traditional deep learning on personal data. We train our core models (the 1,937 algorithms in Dweve Core and the 456 constraint sets in Dweve Loom) on strictly non-personal sources:

• Scientific papers and technical documentation (public domain)
• Open-source code repositories (licensed)
• Synthetic reasoning tasks and logic puzzles
• Anonymized, aggregated statistical patterns
• Formal specifications and structured knowledge bases

We filter aggressively for Personal Identifiable Information (PII) before any training process begins. Our seven-stage epistemological pipeline in Dweve Spindle includes automated PII detection as part of the Candidate and Extracted stages. The 32-agent hierarchy includes specialized agents for identifying and removing personal data before it can enter the knowledge system.

The result is models that understand language, logic, reasoning, and domain knowledge without containing any specific individual's personal information. They understand the concept of a "customer complaint" without knowing who any specific customer is. They can analyze a shipping dispute without ever having seen Mr. Schmidt's address.

Principle 2: Runtime Context Injection

If the model does not contain personal data, how does it help Mr. Schmidt with his specific question about his specific order?

The answer is runtime context injection. When Mr. Schmidt asks "Where is my order?", our system:

1. Authenticates and authorizes the request - Verifies Mr. Schmidt's identity and his right to access this data.
2. Queries the secure data store - Retrieves Mr. Schmidt's relevant records from a traditional, GDPR-compliant database (his recent orders, shipping status, tracking numbers).
3. Injects context into the working memory - Places the retrieved data into the model's context window alongside his question.
4. Generates a response - The model uses its reasoning capabilities to analyze the provided context and generate a helpful response.
5. Clears the context - Immediately after response generation, the context window is flushed. The personal data existed in memory only for the milliseconds required to process the request.

The prompt effectively becomes: "Here is a customer record: [structured data from database]. The customer is asking: 'Where is my order?' Please provide a helpful response."

The model does not "remember" Mr. Schmidt between sessions. It does not accumulate knowledge about him. Every interaction is stateless. The personal data flows through the system like water through a pipe, touching the reasoning engine temporarily but never being absorbed into it.

Principle 3: Governable Knowledge Lifecycle

Dweve Spindle provides enterprise-grade knowledge governance with full lifecycle management. Every piece of information entering the system is tracked through our seven-stage epistemological pipeline:

1. Candidate: Raw information identified and tagged with source, timestamp, and data classification.
2. Extracted: Structured information extracted with PII detection.
3. Analyzed: Decomposed into atomic facts with sensitivity classification.
4. Connected: Linked to knowledge graph with relationship mapping.
5. Verified: Multi-source validation and accuracy confirmation.
6. Certified: Quality assurance with confidence scoring.
7. Canonical: Authoritative status with full audit trail.

Asmens duomenų atveju ši sistema užtikrina, kad kiekviena informacijos dalis turėtų aiškią kilmę, apibrėžtą saugojimo laikotarpį ir ištrynimo kelią. Kai ponas Schmidtas prašo ištrinti duomenis, galime:

• Nustatyti kiekvieną sistemą, kurioje yra jo duomenys
• Atlikti ištrynimą visose sistemose
• Sugeneruoti atitikties ataskaitą, kurioje tiksliai matyti, kas buvo ištrinta, kada ir iš kur
• Įrodyti, kad modelio svoriuose neliko jokių likutinių duomenų (nes jų ten niekada ir nebuvo)

Diferencinis privatumas apibendrintam mokymuisi

Yra teisėtų naudojimo atvejų, kai reikia mokytis iš duomenų, kuriuose yra asmeninės informacijos. Ligoninė gali norėti išmokyti dirbtinį intelektą aptikti ankstyvuosius vėžio požymius iš pacientų tyrimų. Draudimo bendrovė gali turėti poreikį modeliuoti rizikos modelius pagal žalų istoriją. Bankas gali norėti aptikti sukčiavimo modelius iš operacijų duomenų.

Šiems atvejams Dweve įdiegia diferencinį privatumą (DP), auksinį privatumą užtikrinančio mašininio mokymosi standartą.

Diferencinis privatumas yra matematinė sistema, suteikianti įrodomas privatumo garantijas. Mokymosi proceso metu į skaičiavimus įtraukiame kalibruotą statistinį triukšmą. Apribojame bet kurio atskiro duomenų taško įtaką, kad jis negalėtų dominuoti išmoktuose modeliuose.

Rezultatas yra modelis, kuris mokosi populiacijos lygio modelių („Pacientai, turintys X, Y, Z požymius, turi padidintą W būklės riziką") be galimybės atkurti konkretaus asmens duomenis („Pacientas Hans Mueller turi genetinį žymenį Z").

Taikydami diferencinį privatumą galime apskaičiuoti matematinį privatumo biudžetą, vadinamą epsilonu (ε). Ši reikšmė įvertina didžiausią galimą privatumo nutekėjimą. Reguliuotojams galime įrodyti: „Tikimybė, kad iš šio modelio bus galima identifikuoti bet kurį asmenį, yra ribojama ε, kuris yra mažesnis už reguliavimo slenkstį." Privatumas iš neaiškaus pažado virsta matematine garantija su formaliu įrodymu.

Šis metodas atitinka BDAR principą „privatumas pagal dizainą ir pagal nutylėjimą" (25 straipsnis). Privatumo apsauga nėra paskesnė mintis ar formalumas. Ji įdiegta į matematinių pagrindų, kaip sistema mokosi, esmę.

Atitikties pranašumas

Daugelis įmonių, ypač tų, kurios veikia jurisdikcijose su silpnesnėmis privatumo apsaugos priemonėmis, BDAR laiko našta. Jos į privatumą žiūri kaip į išlaidų centrą, teisinę kliūtį, inovacijų stabdį.

Mes žiūrime kitaip. Tinkamai įgyvendinta BDAR atitiktis yra konkurencinis pranašumas.

Pasitikėjimas: Klientams vis svarbiau, kaip tvarkomi jų duomenys. Įrodomas įsipareigojimas privatumui (ne tik privatumo politika, paslėpta smulkiu šriftu, bet ir realūs architektūriniai sprendimai, dėl kurių piktnaudžiavimas tampa neįmanomas) kuria pasitikėjimą, kuris virsta klientų lojalumu ir noru dalytis duomenimis.

Rizikos mažinimas: BDAR baudos yra didelės, tačiau reputacinė žala dėl privatumo pažeidimų gali būti dar didesnė. Įmonės, įdiegiančios privatumą į savo architektūrą, pašalina ištisas rizikos kategorijas.

Geresnės sistemos: Architektūriniai apribojimai, įgalinantys privatumą (atsakomybių atskyrimas, aiškūs duomenų srautai, audito pėdsakai, gyvavimo ciklo valdymas), kartu lemia ir geriau suprojektuotas sistemas. Jos yra lengviau prižiūrimos, lengviau derinamos, lengviau testuojamos. Privatumas ir kokybė vienas kitą sustiprina.

Ateities užtikrinimas: Privatumo reglamentavimas tik griežtėja. ES dirbtinio intelekto aktas, įsigaliosiantis 2026 m., kelia papildomus reikalavimus DI sistemoms, tvarkančioms asmens duomenis. Įmonės, kurios šiandien kuria privatumą atitinkančią architektūrą, rytoj neprivalės perdaryti savo sistemų.

Ką tai reiškia jūsų organizacijai

Jei diegiate DI sistemas, kurios sąveikauja su asmens duomenimis, susiduriate su pasirinkimu:

1 variantas: Tikėtis geriausio. Diegti standartinius didžiuosius kalbos modelius, treniruoti juos su klientų duomenimis ir tikėtis, kad reguliuotojai neateis. Tikėtis, kad „mašininio ištrynimo“ algoritmai subręs, kol jūsų nepasivys. Tikėtis, kad baudos liks teorinės.

Tai požiūris, kurio šiandien laikosi dauguma DI pardavėjų. Tai taip pat požiūris, kuris lems didžiulius atitikties pažeidimus, kai vykdymo užtikrinimas sustiprės.

2 variantas: Įdiegti atitiktį į architektūrą. Diegti DI sistemas, nuo pat pradžių sukurtas taip, kad gerbtų duomenų gyvavimo ciklą, išlaikytų audito pėdsakus ir įgalintų tikrą ištrynimą. Naudoti modelius, kuriuose yra intelekto, bet nėra asmens duomenų. Taikyti diferencinį privatumą bet kokiam agreguotajam mokymuisi, kuris turi liestis su asmens duomenimis.

Tai „Dweve“ metodas. Iš pradžių reikalauja daugiau darbo, tačiau visiškai pašalina ištisas teisinės, reputacinės ir finansinės rizikos kategorijas.

Kelias į priekį

BDAR buvo priimtas 2018 m., dar iki dabartinės didžiųjų kalbos modelių kartos atsiradimo. Reglamento rengėjai negalėjo numatyti konkretaus iššūkio, kai asmens duomenys ištirpsta neuroninio tinklo svoriuose.

Tačiau jų suformuluoti principai išlieka galiojantys: asmenys turi pagrindines teises į savo asmens duomenis, įskaitant teisę reikalauti, kad jie būtų ištrinti. Bet kokia dirbtinio intelekto sistema, kuri negali gerbti šių teisių, iš esmės neatitinka reikalavimų. Nesvarbu, kokios įspūdingos galimybės ar kokios vertingos įžvalgos. Jei negalite ištrinti duomenų, pažeidžiate įstatymą.

Įmonės, kurios klestės dirbtinio intelekto eroje, nėra tos, kurios sukaupia daugiausia duomenų ar treniruoja didžiausius modelius. Tai tos, kurios kuria patikimiausias sistemas. Sistemas, kurios gali paaiškinti savo sprendimus, gerbia vartotojų teises ir gali įrodyti atitiktį architektūra, o ne pažadais.

„Dweve“ kuria dirbtinį intelektą, kuris gerbia duomenų teises pagal pačią savo konstrukciją. Mūsų „Binary Constraint Discovery“ architektūra užtikrina, kad asmens duomenys niekada nepatektų į modelio svorius. Mūsų „Spindle“ žinių valdymo platforma užtikrina visapusišką gyvavimo ciklo valdymą su išsamiais audito žurnalais. Mūsų diferencinio privatumo sprendimai įgalina apibendrintą mokymąsi su matematinėmis privatumo garantijomis.

Jei jūsų organizacija susiduria su dirbtinio intelekto ir privatumo reglamentavimo sankirta, jei jums reikia dirbtinio intelekto galimybių be BDAR keliamos atsakomybės, jei norite kurti klientų pasitikėjimą per įrodomą privatumo apsaugą, turėtume pasikalbėti.

Teisė būti pamirštam nėra pasirenkama. Tai įstatymas. O su tinkama architektūra tai yra pasiekiama.