RODO 2.0 i AI: dlaczego standardowe duże modele językowe nie mogą spełnić wymogów ochrony danych

RODO 2.0 i AI: dlaczego standardowe duże modele językowe nie mogą spełnić wymogów ochrony danych

The Nightmare Scenario

Here is a scenario that keeps Chief Privacy Officers and Data Protection Officers awake at night. It is not a data breach. It is not a hack. It is a customer exercising their fundamental rights under European law.

A customer (let us call him Mr. Schmidt) sends an email to your company. He cites Article 17 of the General Data Protection Regulation: the "Right to Erasure," commonly known as the Right to be Forgotten. He is no longer a customer. He wants his personal data deleted from all your systems. He has the legal right to demand this, and you have 30 days to comply.

For your traditional IT systems, this is a solved problem. Your database administrator runs a script: DELETE FROM customers WHERE id = 'schmidt_42';. The rows disappear from PostgreSQL. The backups are purged according to your retention schedule. The log entries are anonymized. You send Mr. Schmidt a confirmation email documenting what was deleted. Compliance achieved. The process costs approximately EUR 50 in administrative overhead.

But there is a problem. Last quarter, your data science team used customer support logs (including thousands of emails and chat transcripts from Mr. Schmidt over his 8-year relationship with your company) to fine-tune your Customer Service AI. This Large Language Model has ingested Mr. Schmidt's complaints, his shipping addresses, his payment disputes, perhaps even medical information he mentioned in a product liability claim.

Mr. Schmidt's data does not exist in the AI as a row in a table. It has been dissolved. It has been tokenized, converted into high-dimensional embedding vectors, and diffused across billions of floating-point weights. It is not stored in any human-readable form. It exists as a probabilistic tendency for the model to generate certain token sequences when prompted in certain ways.

Nie można wykonać zapytania SQL na sieci neuronowej. Nie można wskazać, które konkretne neurony „przechowują" adres dostawy pana Schmidta. Jeśli zapyta się model: „Jaki jest adres klienta schmidt_42?", może go wygenerować z rozproszonych wspomnień. Albo może nie. Ale dane tam są, wtopione w matematyczną strukturę wag modelu.

Aby naprawdę „usunąć" dane pana Schmidta, należałoby zniszczyć cały model i wytrenować go od nowa, starannie pomijając wszystkie dane z nim związane. Jeśli taki model kosztował 5 milionów EUR i wymagał trzech miesięcy trenowania na klastrze procesorów graficznych H100, pojedynczy wniosek na podstawie RODO od jednego klienta staje się finansową katastrofą.

A klientów jest 2 miliony. Co się stanie, gdy jutro wpłynie kolejny wniosek o usunięcie danych? A pojutrze następny?

Realia prawne: art. 17 RODO w szczegółach

Artykuł 17 RODO nie pozostawia wątpliwości. Stanowi, że „osoba, której dane dotyczą, ma prawo uzyskać od administratora usunięcie dotyczących jej danych osobowych bez zbędnej zwłoki".

Rozporządzenie definiuje usunięcie jako uczynienie danych „niedostępnymi". Europejskie sądy i organy ochrony danych konsekwentnie interpretują to jako wymóg faktycznego usunięcia, a nie jedynie ukrycia czy dezaktywacji danych. Dane muszą zostać zniszczone w sposób uniemożliwiający ich odzyskanie.

W przypadku sieci neuronowych trenowanych na danych osobowych powstaje sytuacja bez wyjścia:

• Dane nie są „przechowywane" w żadnej możliwej do odzyskania formie. Zostały przekształcone we wzorce statystyczne rozproszone w miliardach parametrów.
• Nie istnieje operacja „usuń". Architektury sieci neuronowych nie oferują żadnego mechanizmu usuwania wpływu konkretnych przykładów treningowych.
• Ponowne trenowanie jest ekonomicznie nieopłacalne. W przypadku dużych modeli pełne ponowne trenowanie kosztuje miliony euro i trwa miesiące.
• Częściowe ponowne trenowanie nie działa. Techniki takie jak „machine unlearning" nie mogą w sposób możliwy do udowodnienia usunąć danych. Widmo danych pozostaje wykrywalne.

Konsekwencje prawne są poważne. Naruszenia RODO mogą skutkować karami w wysokości do 20 milionów EUR lub 4% globalnego rocznego obrotu, w zależności od tego, która kwota jest wyższa. W przypadku dużego przedsiębiorstwa systematyczna niemożność wywiązania się z wniosków o usunięcie danych może oznaczać odpowiedzialność sięgającą miliardów.

Dlaczego „maszynowe oduczanie” to fałszywa obietnica

Środowisko akademickiej informatyki od jakiegoś czasu intensywnie pracuje nad dziedziną zwaną „maszynowym oduczaniem”. Celem jest opracowanie algorytmów, które potrafią chirurgicznie modyfikować wagi modelu, aby „zapomnieć” konkretne przykłady treningowe bez konieczności pełnego ponownego treningu.

Brzmi to obiecująco. W praktyce jest to problem nierozwiązany w przypadku dużych modeli i prawdopodobnie nierozwiązywalny ze względu na fundamentalne ograniczenia matematyczne.

Problem 1: katastroficzne zapominanie

Sieci neuronowe uczą się, dostosowując wagi w celu minimalizacji błędu predykcji na całym zbiorze treningowym. Wagi kodują nakładające się, rozproszone reprezentacje. Próba chirurgicznej modyfikacji wag w celu usunięcia jednej informacji zwykle uszkadza integralność strukturalną powiązanej wiedzy.

Naukowcy odkryli, że próby oduczania powodują „katastroficzne zapominanie”, w wyniku którego model traci możliwości daleko wykraczające poza docelowe dane. Model wytrenowany na danych obsługi klienta może „zapomnieć”, jak tworzyć poprawne gramatycznie zdania po procedurze oduczania ukierunkowanej na jednego klienta.

Problem 2: weryfikacja jest niemożliwa

Nawet po przeprowadzeniu procedury oduczania, jak udowodnić, że dane naprawdę zniknęły? Zaawansowane ataki, takie jak ataki wnioskowania o przynależności i ataki inwersji modelu, potrafią wykryć, czy konkretne dane były częścią zbioru treningowego. Badania wykazały, że obecne techniki oduczania nie przechodzą tych testów. Statystyczny ślad danych treningowych pozostaje wykrywalny.

Jeśli organ regulacyjny przeprowadzi audyt Twojego modelu i stwierdzi, że mimo procedury „oduczania” model nadal wykazuje wzorce charakterystyczne dla danych pana Schmidta, nie spełniasz wymogów. Ciężar dowodu spoczywa na Tobie, aby wykazać całkowite usunięcie danych, a przy obecnej technologii taki dowód nie może zostać przedstawiony.

Problem 3: precedens prawny

Europejskie organy ochrony danych nie wydały jeszcze formalnego orzeczenia w sprawie tego, czy maszynowe oduczanie spełnia wymogi RODO. Jednak trend w egzekwowaniu przepisów sugeruje, że będą wymagać wykazalnego i weryfikowalnego usunięcia danych. Stwierdzenie „uruchomiliśmy algorytm, który prawdopodobnie zmniejszył wpływ danych” raczej nie zadowoli organów regulacyjnych przyzwyczajonych do pewności instrukcji DELETE w bazach danych.

Rozwiązanie architektoniczne: rozdzielenie rozumowania i danych

W Dweve od początku zdawaliśmy sobie sprawę, że maszynowe oduczanie to pułapka. Problemu architektonicznego nie da się rozwiązać łatkami algorytmicznymi. Rozwiązaniem jest projektowanie systemów AI, w których problem ten w ogóle nie występuje.

Nasze podejście opiera się na fundamentalnej zasadzie architektonicznej: ścisłym rozdzieleniu zdolności rozumowania od danych osobowych. Model AI zawiera inteligencję (zdolność rozumowania, analizowania i generowania). Dane osobowe znajdują się w oddzielnych, zarządzalnych systemach przechowywania, gdzie mogą być właściwie zarządzane, poddawane audytowi i usuwane.

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.

W przypadku danych osobowych ten potok zapewnia, że każda informacja ma jasny rodowód, określony okres przechowywania oraz ścieżkę usunięcia. Gdy pan Schmidt zażąda usunięcia danych, możemy:

• Zidentyfikować każdy system, w którym znajdują się jego dane
• Wykonać usunięcie we wszystkich systemach
• Wygenerować raport zgodności pokazujący dokładnie, co zostało usunięte, kiedy i skąd
• Udowodnić, że w żadnych wagach modelu nie pozostały żadne dane szczątkowe (ponieważ nigdy ich tam nie było)

Prywatność różnicowa w uczeniu zagregowanym

Istnieją uzasadnione przypadki użycia, w których trzeba uczyć się wzorców z danych zawierających informacje osobowe. Szpital może chcieć wyszkolić AI do wykrywania wczesnych wskaźników raka na podstawie skanów pacjentów. Firma ubezpieczeniowa może potrzebować modelowania wzorców ryzyka na podstawie historii roszczeń. Bank może chcieć wykrywać wzorce oszustw na podstawie danych transakcyjnych.

W tych przypadkach Dweve wdraża prywatność różnicową (DP), złoty standard uczenia maszynowego chroniącego prywatność.

Prywatność różnicowa to matematyczne ramy zapewniające możliwe do udowodnienia gwarancje prywatności. Podczas procesu uczenia dodajemy skalibrowany szum statystyczny do obliczeń. Ograniczamy wpływ pojedynczego punktu danych, aby nie zdominował wyuczonych wzorców.

Efektem jest model, który uczy się wzorców na poziomie populacji („Pacjenci z cechami X, Y, Z mają podwyższone ryzyko wystąpienia stanu W") bez możliwości odtworzenia konkretnych danych jakiejkolwiek osoby („Pacjent Hans Mueller ma marker genetyczny Z").

Dzięki prywatności różnicowej możemy obliczyć matematyczny budżet prywatności zwany epsilon (ε). Ta wartość określa ilościowo maksymalny możliwy wyciek prywatności. Możemy udowodnić organom regulacyjnym: „Prawdopodobieństwo ponownej identyfikacji jakiejkolwiek osoby z tego modelu jest ograniczone przez ε, które znajduje się poniżej progu regulacyjnego." Prywatność przekształca się z niejasnej obietnicy w matematyczną gwarancję z formalnym dowodem.

To podejście spełnia zasadę RODO „prywatność w fazie projektowania i domyślna ochrona prywatności" (artykuł 25). Ochrona prywatności nie jest przemyśleniem po fakcie ani zaznaczeniem pola wyboru. Jest wbudowana w matematyczne fundamenty sposobu, w jaki system się uczy.

Przewaga konkurencyjna dzięki zgodności

Wiele firm, zwłaszcza tych z jurysdykcji o słabszej ochronie prywatności, postrzega RODO jako obciążenie. Traktują prywatność jako koszt, prawną przeszkodę, barierę dla innowacji.

My widzimy to inaczej. Zgodność z RODO, przeprowadzona właściwie, to przewaga konkurencyjna.

Zaufanie: Klienci coraz bardziej zwracają uwagę na to, jak przetwarzane są ich dane. Wykazane zaangażowanie w ochronę prywatności (nie tylko polityka prywatności ukryta w drobnym druku, ale rzeczywiste decyzje architektoniczne uniemożliwiające nadużycia) buduje zaufanie, które przekłada się na lojalność klientów i gotowość do dzielenia się danymi.

Ograniczenie ryzyka: Kary za naruszenie RODO są wysokie, ale szkody wizerunkowe wynikające z naruszeń prywatności mogą być gorsze. Firmy, które wbudowują prywatność w swoją architekturę, eliminują całe kategorie ryzyka.

Lepsze systemy: Ograniczenia architektoniczne umożliwiające prywatność (rozdzielenie odpowiedzialności, jawne przepływy danych, dzienniki audytu, zarządzanie cyklem życia) prowadzą również do lepiej zaprojektowanych systemów. Są łatwiejsze w utrzymaniu, debugowaniu i testowaniu. Prywatność i jakość wzajemnie się wzmacniają.

Gotowość na przyszłość: Przepisy dotyczące prywatności stają się coraz bardziej rygorystyczne. Akt w sprawie sztucznej inteligencji UE, który wchodzi w życie w 2026 roku, dodaje kolejne wymagania dla systemów AI przetwarzających dane osobowe. Firmy, które dziś budują architekturę zgodną z przepisami o prywatności, nie będą musiały modernizować swoich systemów w przyszłości.

Co to oznacza dla Twojej organizacji

Jeśli wdrażasz systemy AI, które przetwarzają dane osobowe, stoisz przed wyborem:

Opcja 1: Liczyć na najlepszy scenariusz. Wdrażaj standardowe duże modele językowe, trenuj je na danych klientów i licz na to, że organy regulacyjne nie zainteresują się Tobą. Licz na to, że algorytmy „machine unlearning" dojrzeją, zanim zostaniesz przyłapany. Licz na to, że kary pozostaną teoretyczne.

To podejście, które obecnie przyjmuje większość dostawców AI. To również podejście, które doprowadzi do ogromnych naruszeń zgodności, gdy egzekwowanie przepisów się nasili.

Opcja 2: Wbuduj zgodność w architekturę. Wdrażaj systemy AI zaprojektowane od podstaw tak, aby respektowały cykl życia danych, prowadziły dzienniki audytu i umożliwiały faktyczne usuwanie danych. Używaj modeli, które zawierają inteligencję bez zawierania danych osobowych. Wdrażaj prywatność różnicową w przypadku wszelkiego uczenia agregatowego, które musi dotykać danych osobowych.

To jest podejście Dweve. Wymaga więcej pracy na początku, ale eliminuje całe kategorie ryzyka prawnego, reputacyjnego i finansowego.

Droga naprzód

RODO zostało uchwalone w 2018 roku, zanim powstało obecne pokolenie dużych modeli językowych. Jego twórcy nie mogli przewidzieć szczególnego wyzwania, jakim są dane osobowe rozproszone w wagach sieci neuronowych.

Jednak zasady, które sformułowali, pozostają aktualne: osoby fizyczne mają podstawowe prawa do swoich danych osobowych, w tym prawo do ich usunięcia. Każdy system AI, który nie respektuje tych praw, jest z gruntu niezgodny z przepisami. Nie ma znaczenia, jak imponujące są możliwości ani jak cenne są wnioski. Jeśli nie można usunąć danych, łamie się prawo.

Firmy, które odniosą sukces w erze AI, to nie te, które gromadzą najwięcej danych lub trenują największe modele. To te, które budują najbardziej godne zaufania systemy. Systemy, które potrafią wyjaśnić swoje decyzje, szanują prawa użytkowników i potrafią udowodnić zgodność z przepisami poprzez architekturę, a nie obietnice.

Dweve buduje AI, które respektuje prawa do danych już na etapie projektowania. Nasza architektura Binary Constraint Discovery gwarantuje, że dane osobowe nigdy nie trafiają do wag modelu. Nasza platforma zarządzania wiedzą Spindle zapewnia pełne zarządzanie cyklem życia z kompletnymi dziennikami audytu. Nasze implementacje prywatności różnicowej umożliwiają uczenie zbiorcze z matematycznymi gwarancjami prywatności.

Jeśli Państwa organizacja mierzy się z przecięciem AI i regulacji dotyczących prywatności, jeśli potrzebują Państwo możliwości AI bez odpowiedzialności wynikającej z RODO, jeśli chcą Państwo budować zaufanie klientów poprzez możliwą do wykazania ochronę prywatności, powinniśmy porozmawiać.

Prawo do bycia zapomnianym nie jest opcjonalne. To prawo. A przy odpowiedniej architekturze jest osiągalne.