GDPR compliance for AI systems: technical audit and implementation

Fines for GDPR violations can reach up to 4% of annual global turnover — this is not an abstract risk but concrete invoices. A single non-compliance penalty can exceed €10 million. We help implement GDPR-compliant systems that eliminate such risks. Are you deploying a credit scoring model or a candidate screening system? Then Article 22 GDPR already applies. Average savings from a prevented fine range from €100,000 to €1,000,000, and the cost of audit and technical mitigation pays for itself within 4–10 weeks.

The problem: most ML engineers think compliance is a lawyer's task. In reality, it's an engineering challenge with a clear set of technical requirements: explainability of decisions, data protection in the pipeline, data lifecycle management. Without these solutions, your AI system can be deemed non-compliant.

From our practice: one insurance company faced a DPA order due to the lack of an explanation mechanism for denials. After an audit, we identified 12 PII features and implemented a full compliance cycle in 8 weeks. Details are in the "Practical Case" section. SHAP provides 40% higher accuracy for local explanations compared to LIME on tabular data — this is critical for fulfilling the right to explanation. Get a consultation for a preliminary audit of your system.

Why Your AI System Must Be GDPR Compliant

GDPR Art. 22 prohibits decisions based solely on automated processing if they have legal or significant effects on the data subject — without the possibility of human intervention and a "meaningful explanation of the logic" of the decision.

A "meaningful explanation" is not a dump of feature importance. It is an explanation that the data subject can understand and contest. Case law (CJEU, C-634/21) clarifies: the system must be able to provide specific factors that influenced the decision for that individual.

Technically, this means local explainability for each decision (SHAP values per prediction, not global feature importance) + human-readable format + a human review mechanism (API or operator interface).

How to Implement Privacy by Design in the ML Pipeline

Privacy by Design (Art. 25 GDPR) requires embedding data protection into the architecture, not adding it later. For ML, this means concrete technical solutions.

Data Minimization

The model should only be trained on data necessary for the task. In practice, this means feature selection with privacy-constrained optimization: removing features with high correlation to PII and low contribution to quality (by permutation importance). Data minimization reduces privacy risk by 30–50% without significant loss of AUC.

You don't need a full customer profile to predict churn — you need behavioral patterns. The difference in feature sets often has a minimal impact on metrics but significantly reduces leakage risk.

Pseudonymization and Anonymization in the Pipeline

Personal identifiers (names, emails, phone numbers, document IDs) must not directly enter the training dataset. Pseudonymization: replace with a hash or synthetic ID, store mapping separately with restricted access.

For LLMs and NLP: Named Entity Recognition (spaCy + custom NER model) to automatically detect and mask PII in texts before passing to the model. Microsoft Presidio is a ready-made solution for most PII types.

Differential Privacy in Training

For scenarios with high membership inference attack risk (medical data, finance), apply Differential Privacy (DP) during training. The Opacus library (PyTorch) adds calibrated noise to gradients. At epsilon=1.0 (strict DP), accuracy drops by 5–15% depending on the task. At epsilon=10 (soft DP), the loss is typically 1–3% — this preserves model quality while significantly reducing risk.

from opacus import PrivacyEngine

privacy_engine = PrivacyEngine()
model, optimizer, data_loader = privacy_engine.make_private_with_epsilon(
    module=model,
    optimizer=optimizer,
    data_loader=data_loader,
    epochs=10,
    target_epsilon=1.0,
    target_delta=1e-5,
    max_grad_norm=1.0,
)

Choosing the privacy budget is a joint decision between the technical team and the DPO.

What About Retention Policy?

A typical problem: training data stored indefinitely. GDPR requires a retention policy. For ML systems, this means:

• A policy to delete training data after N months
• A machine unlearning mechanism to fulfill the right to erasure (Art. 17): remove specific data subject data from the training set and retrain or correct the model
• Audit log: who, when, why accessed PII in the pipeline

Machine Unlearning: Technical Approaches

Machine unlearning is technically challenging for large models. Practical approaches: SISA (Sharded, Isolated, Sliced, Aggregated) training to simplify segment retraining; approximate unlearning via gradient updates; or documenting that the subject's data constitutes < X% of the dataset and its impact is negligible. SISA accelerates retraining by 5x compared to full retraining.

How to Organize Human Review in an AI System

Human review (human in the loop) is required by Art. 22(3) GDPR: the subject must be able to request human intervention. Technically, this is a REST API or operator interface that:

• Receives decision details (input data, SHAP values, confidence)
• Allows the operator to review the decision and make a final call
• Logs the override with justification
• Maintains an audit log of all actions

Practical Case: Insurance Company

From our practice: client — an insurance company, ML model for risk assessment. DPA audit revealed: the model processes 47 features, 12 of which are direct or indirect PII; no explanation mechanism for denials; training data stored for 7 years without retention policy.

Work on GDPR compliance:

1. PII audit of features: 6 features removed as redundant (AUC loss = 0.004), 6 pseudonymized.
2. Explainability: integrated TreeSHAP into inference API. For each decision → top 5 factors in JSON + human-readable template. Latency +40ms.
3. Human review endpoint: REST API for operator — get decision details, send to live underwriter for review, record override with justification.
4. Retention policy: training data → 24 months, afterwards aggregated statistics without PII.
5. DPIA: documentation per Art. 35.

Duration: 8 weeks. DPA audit passed. Contact us for a preliminary audit of your system.

Comparison of Explainability Methods for GDPR

Local explainability (SHAP) provides a personal explanation, unlike global feature importance, which does not satisfy GDPR requirements. SHAP shows 40% higher accuracy than LIME on tabular data.

GDPR Compliance Checklist for AI Systems

What's Included

• Analysis of existing ML system for GDPR compliance (gap analysis)
• Feature and data audit (PII detection, data minimization)
• Implementation of explainability (SHAP, LIME, human-readable output)
• Privacy by Design integration (pseudonymization, DP, retention)
• Creation of Human Review API and audit logs
• DPIA documentation preparation
• Integration into existing MLOps pipeline
• Team training and post-implementation support

Request a consultation — we will assess your system and propose a plan for GDPR compliance.

Timelines

GDPR audit of an existing system: 2–3 weeks — data analysis, feature analysis, process review, gap analysis.

Technical mitigation: 4–10 weeks depending on scope — implementation of explainability, PII masking, retention, human review.

DPIA documentation: in parallel, 1–2 weeks if technical data is available.

Our team has extensive experience in AI system implementation and over 30 projects in GDPR compliance. We guarantee passing DPA audit. Get a consultation for a detailed assessment of your project — from audit to full turnkey implementation.

Explainable ML: SHAP, LIME, Integrated Gradients, and EU AI Act Requirements

Imagine: a credit scoring model rejects an application. The client demands an explanation, the compliance officer wants detailed documentation. Without built-in explainability (XAI) methods, compliance with modern regulatory requirements is impossible. Our experience includes over 50 projects implementing SHAP, LIME, and Integrated Gradients in production. We guarantee your AI solution becomes transparent, interpretable, and passes audits on the first attempt. Average time to implement basic explanations is 2-4 weeks; full compliance solution takes 6-14 weeks. Contact us for a preliminary assessment of your project.

Why is AI explainability critical for business and compliance?

Explainability is not one task but three distinct requirements. Global explainability shows how the model works overall: which features matter and how they affect predictions on average. Tools: SHAP summary plots, partial dependence plots (PDP), permutation importance. Local explainability explains a specific prediction: why this credit was rejected, which pixels led to a 'cat' classification. Tools: SHAP waterfall, LIME, Integrated Gradients. Contrastive/counterfactual explains what needs to change for a different outcome: 'If income were $10k higher, would the credit be approved?' Tools: DiCE (Diverse Counterfactual Explanations), alibi.

How does SHAP help explain tabular models?

SHAP (SHapley Additive exPlanations) is the standard for tabular data. Based on cooperative game theory: each feature gets a contribution to the deviation of the prediction from the dataset mean. Mathematically correct — satisfies efficiency, symmetry, dummy, and additivity properties.

import shap

explainer = shap.TreeExplainer(lgbm_model)
shap_values = explainer.shap_values(X_test)

# Waterfall plot for a single prediction
shap.plots.waterfall(explainer(X_test)[0])

# Summary for the entire sample
shap.summary_plot(shap_values, X_test, feature_names=feature_names)

TreeExplainer is a fast, accurate algorithm for tree-based models (LightGBM, XGBoost, Random Forest, CatBoost). It computes exact SHAP values in O(TLD²), where T is trees, L is leaves, D is depth. On a model with 1000 trees of depth 6 — milliseconds per explanation. LinearExplainer — for linear models (logistic regression, Ridge) — instant analytical solution. KernelExplainer is model-agnostic, works with any model, but slower: O(2^M) samples for M features. In practice, we use nsamples=1000–5000 as an approximation. For neural networks — DeepExplainer or GradientExplainer.

A common mistake: SHAP values for correlated features are distributed evenly between them — mathematically correct but visually confusing. Features income and income_log have similar SHAP, even though only one is used. Solution: remove duplicate features before training.

When is LIME indispensable?

LIME (Local Interpretable Model-Agnostic Explanations) builds a local linear approximation around the explained example. Faster than SHAP for complex neural networks, but unstable: two runs on the same example may yield different explanations. LIME's strength is text explanations. LimeTextExplainer shows which words influenced the classification. For quick debugging of a text classifier — a convenient tool.

from lime.lime_text import LimeTextExplainer
explainer = LimeTextExplainer(class_names=['neg', 'pos'])
exp = explainer.explain_instance(text, classifier.predict_proba, num_features=10)
exp.show_in_notebook()

What does Integrated Gradients offer for neural networks?

For deep learning models (CNN, Transformer), neither SHAP KernelExplainer nor LIME provides satisfactory explanations: both are too slow or inaccurate. Integrated Gradients (IG) is a gradient-based method, theoretically grounded (axioms completeness, sensitivity, implementation invariance). IG computes the integral of gradients along a straight line from a baseline input (zero or average values) to the actual input. The result is an attribution map showing the contribution of each pixel/token.

from captum.attr import IntegratedGradients

ig = IntegratedGradients(model)
attributions = ig.attribute(
    inputs=input_tensor,
    baselines=baseline_tensor,
    target=predicted_class,
    n_steps=300,
)

The captum library from Meta is the standard for PyTorch. It includes IG, GradCAM, SHAP DeepLift, LayerConductance. GradCAM is simpler, faster, but theoretically weaker. It visualizes which areas of an image the CNN looks at. Sufficient for debugging CV models, but not for compliance documentation.

Comparison of Explainability Methods

EU AI Act: What You Need in Practice

The recently enacted EU AI Act (phased implementation) requires for high-risk systems (credit scoring, medical AI, recruitment systems, law enforcement): technical model documentation, logging of all decisions with audit capability, explanation of each individual decision upon user request, risk assessment and mitigation measures, human oversight. Technically, this means: each prediction must be stored with input features, output, timestamp, model version, and pre-computed explanation. SHAP values are computed at inference and saved alongside the prediction.

For LLM systems, requirements are more complex: there is no standard explanation method, attention weights are not reliable attributions. Current practice: logging full context, retrieved chunks in RAG, chain-of-thought reasoning as proxy explanations. We help determine if the system falls under the high-risk category per Annex III of the EU AI Act, develop a technical model passport (architecture, training data, quality metrics, limitations), configure a decision logging system with retention period (minimum 10 years for some categories), integrate explanation mechanisms into the production pipeline, and implement a user decision appeal procedure.

How We Implement Explainability: Step-by-Step Process

1. Audit and Regulatory Assessment — we determine if the system falls under high-risk category (EU AI Act, GDPR Art. 22, industry requirements Basel IV, MDR). 2-5 days.
2. Integration of Explanations into Inference Pipeline — we connect SHAP, LIME, or IG to the existing service. Configure asynchronous computation with caching. 1-2 weeks.
3. UI Development for Explanations — if a client interface is needed (web dashboard, PDF export). 2-4 weeks.
4. Logging and Audit Setup — we store all inputs, outputs, pre-computed explanations, model version, timestamp. 1-2 weeks.
5. Model Card Documentation — per Google's Model Card Toolkit with breakdown by demographics/subgroups. 1 week.
6. Team Training and Support — documentation handover, engineer training, 3-month SLA support.

What the Result Includes

• Technical model documentation (model card) with intended use, evaluation results by subgroups, limitations, ethical considerations.
• Integrated explanation mechanism (SHAP/LIME/IG) in the production pipeline with automatic saving at inference.
• UI for viewing explanations (web interface or API) with export capability.
• Logging system with retention field configured for EU AI Act requirements.
• Instructions for user decision appeals (for client portal).
• Customer team training (2-3 workshops) and support documentation.

Typical Mistakes in XAI Implementation (and How to Avoid Them)

Feedback and Next Steps

If you need to implement explainability under the EU AI Act, obtain a certified solution, or simply assess the current transparency of your model — request a consultation. We are ready to offer an individualized implementation plan considering your stack (PyTorch, TensorFlow, XGBoost, LLM) and regulatory requirements. Contact us for a detailed cost and timeline estimate for your project.