GDPR and AI: Where Article 5, Article 22, and Article 32 Reach Production AI Deployments

GDPR applies to AI deployments wherever the AI system processes personal data of EU residents, regardless of where the processing happens or where the controller is established. The regime predates the EU AI Act by seven years and reaches a broader surface. Where the AI Act classifies systems by risk tier and imposes specific high-risk obligations, GDPR imposes lawfulness, purpose limitation, transparency, automated-decision controls, and security-of-processing obligations on the personal data the AI system handles. The articles overlap with the EU AI Act in ways that compound the obligation: the same audit record that satisfies AI Act Article 12 satisfies GDPR Article 32 if the record carries the right fields, and the same DPIA that the AI Act conformity assessment requires under Article 9 satisfies the GDPR Article 35 DPIA where the personal data scope overlaps.

I want to walk through the GDPR articles that reach production AI deployments, the specific obligations each creates, where most AI implementations fail the test, and the inspection-layer architecture that produces the evidence the data protection authority will accept.

The articles that apply to AI processing

Five GDPR articles do most of the work for AI deployments.

Article 5 imposes the seven processing principles: lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and accountability. Each principle attaches to every processing operation the AI system performs. The principles are not optional, and the controller carries the burden of demonstrating compliance.

Article 6 sets the lawful bases for processing. AI deployments rely on one of: consent, contract, legal obligation, vital interests, public task, or legitimate interests. Each basis has its own test the supervisor applies. Legitimate interests requires a balancing test that AI processing often fails because the AI processing operations are not what the data subject would reasonably expect.

Article 9 sets the special-category restrictions. Health data, biometric data, genetic data, political opinions, religious beliefs, and sex-life data require an additional lawful basis from the Article 9(2) list. AI deployments that process special-category data through prompts (a healthcare AI scribe ingesting patient symptoms, an HR AI evaluating candidates' health-related disclosures) trigger Article 9 in addition to Article 6.

Article 22 limits automated individual decision-making that produces legal or similarly significant effects. The data subject has the right not to be subject to such a decision unless one of the Article 22(2) exceptions applies, in which case the controller has to provide meaningful information about the logic, the significance, and the envisaged consequences.

Article 32 requires appropriate technical and organizational measures for the security of processing. The article is the load-bearing one for the audit log obligation. The supervisor reading Article 32 asks the controller to demonstrate the security measures in evidence form. The audit record series is the evidence.

How AI processing fails the Article 5 principles in practice

Purpose limitation fails when the AI system reuses data the controller collected for a different purpose. A customer-support transcript collected to provide the support is reused to train an AI model without the original consent extending to training. The controller's defense rests on compatible-purpose analysis under Article 5(1)(b) and Article 6(4), and the analysis often does not survive the supervisor's review.

Data minimization fails when the AI system processes the full record where a redacted version would have sufficed. A customer-support AI agent that needs the issue category and the order identifier does not need the customer's full payment-card details, but the application sends the entire transcript including the payment details to the model because the application has no field-level redaction at the request boundary.

Storage limitation fails when the model provider's retention defaults exceed the controller's lawful basis. The OpenAI API retains request payloads for thirty days by default. The Anthropic API retains for the same window. A controller that has a thirty-day lawful basis on the source data and ships the data to a provider that retains for thirty days has a chained retention that exceeds the original window. The controller is responsible for the chained retention.

Accountability fails when the controller cannot produce the records that demonstrate compliance with the prior six principles. The records have to cover the natural person, the data class, the processing purpose, the lawful basis, the policy state at processing time, and the outcome. An application log that captures the API call without the identity context fails the accountability test.

Article 22 and automated AI decisions

Article 22 reads narrowly on its face. The data subject has the right not to be subject to a decision based solely on automated processing that produces legal effects concerning the data subject or similarly significantly affects the data subject. The article exempts decisions necessary for entering into or performing a contract, decisions authorized by Union or member state law, and decisions based on the data subject's explicit consent.

The Article 29 Working Party guidance (now the European Data Protection Board) reads "solely automated" expansively. A human in the loop that rubber-stamps the AI output is solely automated for Article 22 purposes if the human review is not a meaningful intervention. A loan-origination AI that produces a recommendation and a credit officer who approves recommendations at a 99.5% rate is solely automated. The supervisor applies the meaningful-intervention test, not a checkbox on whether a human was in the workflow.

The transparency obligation under Article 22(3) requires meaningful information about the logic, the significance, and the envisaged consequences of the automated decision. The article requires more than a generic "we use AI" disclosure. The data subject has to be able to understand the basis of the decision in a form that supports contestability.

The architecture that satisfies Article 22 is per-decision logging plus a contestability workflow. The per-decision log captures the model, the prompt, the policy state, the outcome, and the human review status. The contestability workflow lets the data subject request an explanation and exercise the right to obtain human intervention. The audit log feeds both.

Article 32 security of processing

Article 32 requires appropriate technical and organizational measures, having regard to current security practice, the nature of the processing, and the risk to data subjects. The supervisor evaluates the measures against the risk to data subjects, not against a fixed checklist.

For AI deployments, the appropriate measures include identity-aware policy enforcement at the model API call layer, prompt-level classification to enforce data minimization, response classification to catch sensitive-data exfiltration in the model output, per-decision audit records that demonstrate the controls fired, and a verification flow that lets the supervisor confirm the records are tamper-evident.

The supervisor reading Article 32 against an AI deployment asks: what does the controller do at the request boundary to enforce the data minimization principle? What does the controller do to prevent the model from emitting personal data in response? What records does the controller carry to demonstrate the controls fired in production?

An application-controlled log fails the supervisor's evidence test for the same reason it fails the EU AI Act Article 12 test. The application is the entity whose processing the log evidences. The supervisor wants a record from a control point the controller did not also operate.

The DPIA obligation under Article 35

Article 35 requires a Data Protection Impact Assessment for processing operations likely to result in a high risk to data subjects. AI processing of personal data is on the EDPB's standing list of operations that require a DPIA: large-scale processing of special-category data, systematic monitoring, processing using new technologies, and automated decision-making with legal or similarly significant effects all apply to most production AI deployments.

The DPIA has to describe the processing operations, assess the necessity and proportionality, assess the risks to data subjects, and identify the measures to address the risks. The Article 35(7) format requires concrete identification of measures, not a generic description.

The DPIA overlaps with the EU AI Act Article 9 conformity assessment for high-risk AI systems. The two artifacts can share content as long as each artifact addresses its own legal scope. The DPIA centers on the personal data and the data subject rights. The AI Act conformity assessment centers on the system's risk classification and the deployer obligations.

Cross-border transfers under Chapter V

GDPR Chapter V restricts transfers of personal data to third countries that do not provide an adequate level of protection. AI processing routinely triggers Chapter V because the model providers operate from the United States and process the personal data the controller submits in the prompt.

The Standard Contractual Clauses are the workhorse mechanism. The 2021 SCC update added the obligation for the controller to perform a transfer impact assessment (TIA) that evaluates the legal environment of the destination country against the protections the SCCs provide. The Schrems II judgment imposed the supplementary measures requirement where the destination country's surveillance regime exceeds what the SCCs anticipate.

For AI deployments, the appropriate supplementary measure includes the inspection-layer architecture that enforces data minimization at the request boundary before the prompt leaves the controller's perimeter. The controller can demonstrate to the supervisor that the personal data the model provider receives is the minimum necessary for the processing purpose, that the audit record captures the redaction outcome, and that the response classifier blocks the model from emitting personal data the model retained from a prior interaction.

DeepInspect

This is the gap DeepInspect closes for GDPR-applicable AI deployments. DeepInspect sits inline between the calling application and any HTTP LLM endpoint. For every request, DeepInspect classifies the prompt content for personal data and special-category data, applies the per-route and per-role policy bundle that enforces data minimization and purpose limitation, attaches the natural-person identifier to the record, evaluates the model and endpoint against the cross-border transfer rules, runs the response classifier for sensitive-data exfiltration, and commits the per-decision audit record from a credential the application cannot access.

The record series carries the evidence the supervisor expects for Article 5 accountability, Article 22 transparency and contestability, and Article 32 security of processing. The same record series carries the EU AI Act Article 12 traceability evidence, the DORA Article 19 incident reporting evidence, and the Fannie Mae LL-2026-04 disclosure-on-demand evidence where those regimes apply. The deployment integrates as a single HTTP hop with no application code change beyond the base URL.

If your AI deployment processes personal data of EU residents and you are looking for the evidence path under Article 32, let's talk.