AI Compliance vs Security Gap
GDPR: Confirmed. SOC 2: Confirmed. Article 22 Right to Explanation: Model Cannot Provide It.
6 min read · 3 September 2026 · AI governance
A consumer lending fintech's primary credit decisioning AI was a gradient boosting ensemble model , a highly accurate but inherently opaque model type that produces decisions through complex interactions between hundreds of feature values across multiple boosting stages. The model had been selected for deployment because of its superior predictive performance, which translated directly to better credit risk discrimination and lower default rates. The vendor's compliance documentation was comprehensive: GDPR compliance certification, SOC 2 Type II report, ISO 27001 certification, and an internal AI ethics review. The compliance programme was genuine , the vendor had invested significantly in data privacy, security controls, and ethical review processes. What the compliance programme had not specifically addressed was the model's compliance with GDPR Article 22, which creates a right for individuals not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects, and a right to obtain meaningful information about the logic involved. The credit decisions made by the model were exactly the type of automated decisions Article 22 applies to. The model's internal logic , the feature importance weights across multiple gradient boosting trees, the interaction effects between features, the threshold values at each split , was not expressible in a form that a layperson could meaningfully understand as an explanation of their specific credit decision. The vendor had GDPR compliance. The vendor did not have Article 22 compliance for automated credit decisions. The two are not the same thing.
What is the AI Compliance vs Security Gap, Really?
The AI compliance versus security gap is the distinction between an AI system's compliance with general data protection and security regulations , GDPR for data handling, SOC 2 for security controls, ISO 27001 for information security management , and its compliance with the specific requirements that apply to AI systems making consequential automated decisions: explainability obligations, human oversight requirements, fairness assessment mandates, and AI-specific regulatory requirements. An AI system can be fully compliant with general data protection and security requirements while being non-compliant with the specific regulations that govern automated decision-making.
The Article 22 explainability problem is the most operationally significant AI-specific compliance gap. GDPR Article 22 creates a right for data subjects not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects , and a right to obtain meaningful information about the logic involved in such decisions. Many high-performance AI models , gradient boosting ensembles, deep neural networks, complex ensemble methods , produce decisions through interactions that are not naturally expressible in the form of a meaningful explanation that a layperson could understand. Deploying these models for credit, insurance, employment, or other decisions with significant individual effects creates Article 22 compliance obligations that the models may structurally be unable to satisfy.
The fairness compliance dimension is a second AI-specific regulatory gap. Regulators in financial services , the CFPB in the US, the FCA in the UK, regulators across the EU , have increasingly applied anti-discrimination requirements to AI credit and insurance decisioning. An AI model that produces disparate impact on protected classes , even if no protected class features are included in the model inputs , may be in violation of fair lending requirements. General GDPR and security compliance does not address fairness. Models that have not been specifically tested for disparate impact may be violating fair lending requirements while being fully compliant with data protection requirements.
The EU AI Act high-risk system requirements create the third compliance dimension. The EU AI Act's high-risk category includes AI systems used in credit scoring, as well as systems used in employment decisions, education, healthcare, and law enforcement. High-risk AI systems have mandatory requirements , fundamental rights impact assessments, technical documentation, logging of operation, transparency to affected persons, human oversight , that go substantially beyond the requirements of general data protection regulations. An AI system that is GDPR-compliant may simultaneously be non-compliant with the EU AI Act's high-risk system requirements.
Why this matters
The AI compliance versus security gap matters for TPRM because the enterprise that deploys a vendor's AI system in a regulated use case inherits the compliance obligations of that use case , regardless of whether the vendor's compliance documentation covers those obligations. The enterprise whose credit decisions are made by a vendor's AI system that cannot provide Article 22 explanations has Article 22 liability regardless of the vendor's GDPR certification.
Where most teams get this wrong
The most consistent failure is accepting general compliance certifications , GDPR, SOC 2, ISO 27001 , as evidence of AI-specific regulatory compliance. General certifications cover general requirements. AI-specific regulations impose specific obligations that general certifications do not address.
- General compliance accepted as AI-specific compliance
- Article 22 explainability not assessed for automated decision-making models
- Fairness testing not assessed for credit, insurance, employment models
- EU AI Act high-risk requirements not assessed for applicable systems
- Model explainability capability not matched to regulatory obligation
What good looks like
Mature AI compliance programmes assess each AI system against the specific regulations that apply to its use case , not just against general data protection and security standards , and validate that the model's explainability capability matches the legal explanation obligations that its use case creates.
- Use-case-specific compliance assessment , Article 22, fair lending, EU AI Act by use case
- Explainability capability matched to obligation , model type assessed against explanation requirements
- Fairness testing for protected class disparate impact
- EU AI Act high-risk assessment for applicable use cases
- Compliance gap documentation , where compliance obligations are not currently met
Tooling
Explainability , SHAP, LIME, IBM Watson OpenScale for GDPR-compliant explanations
Model explainability tools , SHAP (SHapley Additive exPlanations) and LIME (Local Interpretable Model-Agnostic Explanations) , generate feature-contribution explanations for individual decisions that can form the basis of Article 22 explanations. For TPRM practitioners, asking whether the vendor's automated decision-making model uses explainability tools that can generate legally adequate individual explanations provides a specific Article 22 compliance question.
Fairness Testing , AI Fairness 360 (IBM), Fairlearn (Microsoft) for disparate impact assessment
Fairness testing frameworks assess models for disparate impact on protected classes , a requirement for AI systems used in credit, insurance, employment, and other regulated decisions. For TPRM practitioners, asking whether the vendor's model has been assessed for disparate impact using a fairness testing framework provides a specific fair lending compliance question.
Governance challenges
The governance challenge with AI compliance gaps is the regulatory complexity across jurisdictions. Article 22 applies in the EU. Fair lending requirements apply in the US. The EU AI Act applies across EU member states with different implementation timelines. An AI product deployed across multiple jurisdictions may face different compliance obligations in each jurisdiction. The governance resolution is use-case-based compliance assessment , assessing each specific AI use case against all applicable regulations in all relevant jurisdictions.
- Conduct use-case-specific compliance assessment for each AI deployment
- Assess Article 22 explainability for automated decision-making
- Conduct fairness testing for credit, insurance, employment models
- Assess EU AI Act high-risk requirements for applicable systems
- Map compliance obligations by jurisdiction for cross-border deployments
If you are a small team
For every vendor AI system that makes or meaningfully influences decisions that have significant effects on individuals , credit, insurance, employment, healthcare, education , ask two compliance-specific questions. First: does this system generate Article 22-compliant individual explanations for each decision , and can you provide an example explanation in the format you would provide to an affected individual? Second: has this system been tested for disparate impact on protected classes , and can you provide the disparate impact assessment results? Those two questions reveal the AI-specific compliance gaps that general certifications do not address.
- Ask for Article 22 example individual explanation
- Ask for disparate impact assessment results
- Assess EU AI Act high-risk classification
- Map use-case-specific compliance obligations
What to require
Ask directly:
"For your credit decisioning AI , can you provide an example of the Article 22-compliant individual explanation you would provide to an applicant, and can you provide your most recent disparate impact assessment results for protected classes?"
Expect as evidence
- Article 22 individual explanation example
- Disparate impact assessment results
- EU AI Act high-risk assessment
- Explainability methodology documentation
A vendor who confirms GDPR compliance should be asked for the Article 22 explanation example. GDPR compliance covers data handling. Article 22 compliance covers automated decision-making. The same regulation, different obligations.
How to evidence it
- Article 22 compliance assessment records
- Disparate impact testing records
- EU AI Act compliance assessment
- Use-case-specific compliance documentation
Key Takeaway
GDPR compliance: confirmed. SOC 2: confirmed. Article 22 right to explanation for automated credit decisions: the gradient boosting ensemble cannot provide it. GDPR compliance and Article 22 compliance are both GDPR obligations. They address different things. Data handling compliance and automated decision-making compliance are both required. Certifying one does not certify the other. Use-case-specific compliance assessment , Article 22 for automated decision-making, fair lending for credit and insurance, EU AI Act high-risk requirements for applicable systems , is the additional layer that general compliance certifications do not provide. Ask for the Article 22 example explanation. Ask for the disparate impact results. General certifications are the floor. Use-case-specific compliance is the obligation.
Speak to It™
The term you nodded along to, explained in ninety seconds, so you can speak to it professionally. It is how most readers find these articles.
Join the Association