Regulatory non-compliance

Regulatory Non-Compliance (Risk Taxonomy 2026)

Definition

Regulatory non-compliance is the risk that AI-supported or AI-generated activity breaches a substantive obligation imposed by a regulator with jurisdiction over the activity, the data, the audience, or the entity. These obligations are external and substantive: they apply regardless of how the organisation’s internal governance classifies or prioritises them.

Relevant regulators depend on the use case and jurisdiction, and can include:

• Data-protection authorities (e.g. GDPR / UK GDPR regulators)
• Financial-services supervisors
• Medical-device and health regulators
• Sectoral conduct regulators
• AI-specific authorities (e.g. under the EU AI Act and emerging analogues)
• Consumer-protection and competition authorities

A single AI capability can simultaneously fall under several of these regimes.

Why This Is a Distinct Risk Class

1. External standard
2. Sanctions scaled to entity
3. Asymmetric discovery
4. Cross-cutting nature

Canonical Coverage in a Defensible Programme

A robust programme maintains a documented, per-capability map of regulatory obligations. Canonical elements:

1. Per-capability regulatory inventory
   • Applicable regimes and classifications (e.g. EU AI Act risk class)
   • Relevant UK or other national regulator guidance
   • GDPR / UK GDPR lawful basis and key data-protection obligations
   • Sector-specific rules (e.g. financial conduct, health, employment)
   • Professional conduct rules where applicable (e.g. legal, medical, accounting bodies)
2. Per-regime control mapping
   • Data minimisation, purpose limitation, and DPIAs
   • Human oversight and transparency obligations
   • Model risk management and validation requirements
   • Documentation, logging, and auditability controls
3. Per-regime watch
   • Monitoring cadence (e.g. monthly, quarterly, per consultation)
   • Sources (regulator updates, industry bodies, legal counsel)
   • Escalation path to the AI Council on material change

The regulatory map itself is an artefact: without it, the function cannot demonstrate that it understands what “compliance” means for each capability.

Common Failure Modes

• Single-regime tunnel vision
• Jurisdictional drift
• Vendor-mediated breach
• Static documentation

Each of these failure modes should have named, testable controls under the Governance pillar.

Distinction from Adjacent Risks

• Professional conduct exposure
• Hallucination and Model drift
• Vendor lock-in

Framework Positioning

Treating regulatory non-compliance as a first-class, distinct risk category is essential for:

• Designing controls that align with external legal standards, not just internal risk appetite.
• Demonstrating DE-2 (methodology transparency) by showing how regulatory obligations are translated into controls.
• Demonstrating DE-3 (operational evidence) by maintaining auditable artefacts: per-capability regulatory inventories, per-regime control mappings, and per-regime watch records.

A programme that explicitly manages this class—rather than folding it into generic operational or technical risk—can more credibly evidence compliance to regulators, auditors, and boards.