Your fraud and credit AI is almost certainly in scope.
The EU AI Act classifies credit scoring, AML risk profiling, and most fraud detection AI as high-risk systems. High-risk means documented, monitored, and auditable — before you deploy, not after an incident. Strataforge Sentinel produces the technical documentation Articles 9–17 require, in 5–7 days, without system access.
August 2, 2026 — the original compliance date
High-risk AI system obligations under Articles 9–17 have been the target date for financial services firms since the Act entered into force on August 1, 2024. Most compliance teams are treating this as the operative deadline regardless of the Omnibus extension, since the extension has not yet been formally enacted into law.
ⓘ
Omnibus update (May 7, 2026): A provisional political agreement defers standalone Annex III high-risk obligations to December 2, 2027 — subject to formal adoption expected before August 2026. Prudent planning still treats August 2026 as binding. A delay that has not been formally adopted is not a delay you can rely on in front of a regulator.
Aug 2026
Active compliance target
Who is in scope
Which AI systems are high-risk?
The Act applies to providers and deployers of AI systems placed on the EU market or used by people in the EU — regardless of where the provider is headquartered.
Extraterritorial
Jurisdiction follows the user, not the company
Article 2 applies the EU AI Act to any provider whose AI system is used in the EU or whose output affects EU residents — regardless of where the company is registered. GCC fintechs, South Asian lenders, and US fraud-detection providers all carry obligations if their AI touches EU-resident data or decisions.
AI system type
Annex III status
Notes
Credit scoring / loan approval
⚠ High-risk
Explicitly listed. No exception applies.
Insurance underwriting / pricing
⚠ High-risk
Explicitly listed under Annex III(5)(c).
AML / transaction risk profiling
⚠ High-risk
Profiles individuals — falls under essential services access.
Fraud detection (narrow, purpose-specific)
✓ Exempt
Exception in Annex III(5)(b) — but only if purely fraud-detection.
Fraud detection (also profiles behaviour / risk)
⚠ Assess case-by-case
Exception lapses if system characterises individuals beyond fraud signal.
Internal AI tools (no customer-facing decision)
✓ Likely out of scope
Minimal risk if no impact on individuals' rights or access.
◈ The fraud exception is narrower than it looks
Annex III creates a carve-out for AI used specifically to detect financial fraud. But if your fraud model also generates behavioural risk scores, segments customers, or informs decisions about access to services — the exception lapses and high-risk obligations apply in full. Each system needs individual assessment. Sentinel's governance audit includes this classification.
What high-risk compliance requires
Articles 9–17: what you must document and prove.
Article 9
Risk management system
A documented, continuous process for identifying and mitigating risks — from development through decommissioning. Not a one-time assessment.
◈ Sentinel produces this
Article 10
Data governance
Training, validation, and testing datasets must be documented, relevant, representative, and free of bias. For credit models: documented data lineage and bias testing.
◈ Sentinel covers data section
Article 11
Technical documentation
Before deployment, providers must produce documentation sufficient for regulators to assess compliance — kept up to date throughout the system's operational life.
◈ Sentinel produces this
Article 12
Record-keeping and logging
High-risk systems must log activity automatically to enable post-hoc investigation. DORA overlap applies here for financial institutions.
◈ Sentinel audit trail
Article 13
Transparency
Deployers must be given sufficient information to understand what the system does, its limitations, and how to interpret its outputs. Explainability is a requirement, not a feature.
◈ Sentinel Explain layer
Article 14
Human oversight
High-risk systems must enable human oversight. Operators must be able to intervene, override, or halt. Fully automated decisions without a human checkpoint are not compliant.
◈ Covered in Sentinel Govern
Article 15
Accuracy and robustness
Systems must maintain appropriate accuracy throughout their lifecycle. Performance must be documented, monitored, and demonstrated — not assumed from training metrics alone.
◈ Sentinel Detect layer
Article 17
Quality management system
Providers must have a QMS covering risk management, testing, monitoring, corrective action, and documentation throughout the system's life.
◈ Sentinel Govern layer
Know your obligation tier
Are you a provider or a deployer?
⚠ Provider (heavier obligations)
→ You built, trained, or substantially modified the model
→ You placed the AI system on the market or into service
→ You own technical documentation, conformity assessment, EU database registration
→ If you retrain a third-party model, you may become the provider
◈ Deployer (still significant obligations)
→ You use a third-party AI system under your own authority
→ You must ensure human oversight is possible
→ You must monitor performance and retain logs
→ You must receive adequate technical documentation from your vendor
What non-compliance costs
Penalty structure exceeds GDPR.
€35M
or 7% global turnover — prohibited practices (whichever higher)
€15M
or 3% global turnover — high-risk non-compliance (whichever higher)
€7.5M
or 1% global turnover — incorrect information to authorities
⚠ Serious incident reporting
A "serious incident" includes systematic discriminatory credit decisions or AML failures causing regulatory breaches. Reporting timeline: 15 working days from awareness. This requires an audit trail that exists before the incident — not one assembled after the call from the regulator.
What Sentinel produces
The documentation you need. In 5–7 days.
Sentinel produces the technical documentation, monitoring evidence, and explainability outputs that Articles 9–17 require you to have — the things your compliance team, legal team, and regulator will ask for.
Art. 9
Risk management system documentation
Continuous risk identification and mitigation record — recall decay, feature drift signals, alert history, and corrective action log.
✓ Included
Art. 11
Technical documentation package
Model architecture, training configuration, feature set, threshold selection rationale, and production performance record — sufficient for regulatory review.
✓ Included
Art. 12
Automated audit trail
Production period logs with timestamped performance metrics, alert triggers, and threshold events — DORA-aligned and suitable for post-hoc regulatory investigation.
✓ Included
Art. 13
Explainability outputs
Feature attribution per decision, counterfactual explanations, and plain-language executive summary — transparency your deployers and regulators need.
✓ Included
Art. 15
Performance monitoring evidence
ROC-AUC, recall, precision, and PSI trends across production periods — documented, timestamped, benchmarked against validated baseline at deployment.
✓ Included
Art. 17
Quality management documentation
Threshold selection and optimisation record, retraining triggers, human oversight checkpoints, and corrective action framework.
✓ Included
◈ DORA overlap
For financial institutions, the EU AI Act sits alongside DORA (applies from January 2025). DORA requires ICT risk management, incident reporting, and third-party risk oversight. Sentinel's audit trail and monitoring documentation satisfies obligations under both frameworks — one engagement, two regulatory footprints covered.
Proven methodology
Two independent case studies. Real numbers.
The documentation Sentinel produces is grounded in a validated observability methodology — not a template. Two published case studies on public datasets demonstrate the monitoring approach that underlies every audit engagement.
The distinction between drift detection and output admissibility — what the EU AI Act actually needs from monitoring systems — is explored in depth in a working memo published by Strataforge3's founder.
What Third-Party AI Auditors Should Be Allowed to See — and Enforce
Working Memo · AI Governance
"Most 'monitoring' solutions in the market today are statistical drift detectors — they tell you that something changed, not whether the output itself was admissible. That distinction matters more than it might first appear."
Current AI governance is dominated by the evaluation paradigm: run a model before deployment, get a score, ship. This misses the more consequential gap — at the output layer, where a model's response actually becomes a decision that affects someone. The EU AI Act's Articles 9, 12, and 17 are closer to requiring "replayable admissibility receipts" than aggregate drift statistics, even though most compliance tooling is built around the latter.
The memo draws on two years of operating a production admissibility system — MaqasidAI/MACI — to argue for a specific, narrow expansion of what independent auditors should be able to observe and block. It also names the one piece the technical work alone can't answer: where legal authority for "halt" should sit, and why that is a governance research question, not a model architecture question.
Sentinel is a technical audit and observability service, not a legal or regulatory adviser. The documentation it produces supports your compliance function — it does not replace legal review, a conformity assessment, or EU database registration, all of which remain your responsibility. If you are uncertain whether your specific AI system falls under Annex III, consult a regulatory lawyer before relying on any technical output.
The documentation gap is fixable in 5–7 days.
Articles 9–17 technical documentation, monitoring evidence, and explainability outputs — without system access, without downtime, and without a six-month engagement.