The EU AI Act's first compliance deadline arrived on August 2, 2026. Wolters Kluwer surveys suggest that only 12% of financial institutions reported having a well-defined compliance strategy by that date.
The remaining 88% are now in various states of catch-up. Most are focused on documentation: model inventories, transparency statements, conformity assessments, technical documentation packages. That work is necessary.
What's missing from almost every compliance program: the adversarial testing that Article 9 actually requires — and that most compliance teams haven't mapped to their AI risk management work.
What Article 9 actually requires
Article 9 of the EU AI Act establishes a risk management system obligation for high-risk AI systems. Banking AI used in credit scoring, AML/fraud screening, and customer due diligence falls within the high-risk category under Annex III.
The Article 9 requirements relevant to adversarial testing:
Article 9(2): The risk management system "shall consist of a continuous iterative process run throughout the entire lifecycle of a high-risk AI system." Not a one-time pre-deployment exercise. A continuous process.
Article 9(4): The risk management measures shall consider "the relevant foreseeable misuse" of the high-risk AI system. "Foreseeable misuse" includes adversarial inputs — using the system in ways it wasn't intended to be used, including deliberately attempting to subvert its controls.
Article 9(6): The high-risk AI system "shall be tested to identify the most appropriate risk management measures." Testing is an explicit obligation, not a best practice.
Article 9(9): "High-risk AI systems which are intended to interact with natural persons shall be designed in such a way that they reliably process and respond to interactions including that with vulnerable persons." This implies robustness testing — the system must handle adversarial or unusual inputs reliably.
The technical documentation required under Article 11 must describe the risk management measures and the testing that validated them. If your risk management documentation doesn't include adversarial test results, you haven't completed the technical documentation that Article 11 requires.
What counts as Article 9-compliant testing for banking AI
Not all testing satisfies Article 9. The test needs to be directed at "foreseeable misuse" and the results need to be documented in a way that supports the technical documentation package.
Tests that count:
Adversarial input testing — structured attempts to cause the AI to produce output it shouldn't (prohibited financial advice, data leakage, fraud facilitation). This directly addresses "foreseeable misuse." Document: attack categories tested, number of test inputs per category, pass/fail criteria, actual attack success rate.
Agentic scope boundary testing — for any AI system that calls tools or takes actions, tests verifying that the system stays within its authorized scope under adversarial conditions. Document: authorized tool list, test inputs designed to induce out-of-scope actions, results.
Data integrity testing — for any AI using retrieval or knowledge base access, tests verifying that the system cannot be caused to produce prohibited output through knowledge base manipulation. Document: injection test methodology, test inputs, results.
Cross-customer data isolation testing — verification that the AI system cannot be caused to include data about individual A in a response about individual B. This addresses GDPR Article 5 compliance alongside EU AI Act obligations. Document: test methodology, sentinel token placement, results.
Tests that don't count (as standalone documentation):
- Accuracy benchmarks (FinanceBench, Finance Agent Benchmark) — these measure task performance, not adversarial robustness
- Standard functional testing — tests that the AI does its job correctly under normal conditions
- Vendor safety attestations — a third-party provider's claim that their model is safe doesn't constitute your organization's risk management testing
- Architecture documentation — describing your safety architecture doesn't validate that it works
Article 9(6)'s testing obligation means you need test results, not test descriptions. Documentation that describes your testing approach but doesn't include results from actual tests doesn't satisfy the obligation.
Mapping FinProof attack categories to Article 9 risk areas
The FinProof BFSI adversarial benchmark is structured to map directly to EU AI Act high-risk categories. Here's how the attack taxonomy maps to Article 9 risk areas:
B-01: Investment advice manipulation Risk area: Annex III point 2 (AI for access to financial services, credit scoring). Foreseeable misuse: using the AI to generate investment advice it's not authorized to provide. Article 9 documentation: ASR on B-01 category, plus system prompt controls preventing investment advice output.
B-02/B-09: AML/KYC bypass and sanctions evasion Risk area: Annex III point 6 (AI for law enforcement adjacent applications, fraud/AML). Foreseeable misuse: using the AI to understand how to evade monitoring. Article 9 documentation: ASR on B-02 and B-09, plus evidence that knowledge of AML thresholds is explicitly excluded from model output.
D-10: RAG poisoning Risk area: Article 9(9) robustness requirement. Foreseeable misuse: poisoning the knowledge base to manipulate AI output. Article 9 documentation: knowledge base integrity test results, data boundary testing (GDPR + AI Act intersection).
D-09: Tool poisoning/confused deputy Risk area: Article 9(4) — foreseeable misuse of an agentic system. Foreseeable misuse: inducing unauthorized tool calls. Article 9 documentation: tool scope boundary test results, audit log of all tool calls during testing.
The DORA intersection
The EU AI Act's requirements for banking AI don't exist in isolation. Under DORA (Digital Operational Resilience Act), financial institutions are also required to test their digital systems' resilience against adversarial threats.
DORA Article 25 requires "advanced testing" including "threat-led penetration testing" for critical systems. An AI system that is part of a bank's critical operational infrastructure may fall under both DORA's advanced testing requirement and the EU AI Act's Article 9 testing obligation.
The good news: these requirements are satisfied by overlapping test designs. Adversarial AI testing under FinProof addresses:
- EU AI Act Article 9(4): foreseeable misuse testing ✓
- EU AI Act Article 9(6): testing to identify appropriate risk management measures ✓
- DORA Article 25 (for AI-driven systems): adversarial testing of critical functions ✓
Running a single integrated adversarial testing exercise and mapping results to both frameworks is more efficient than running separate exercises for each regulatory obligation.
Building the Article 9 documentation package
A complete Article 9 risk management documentation package for a banking AI system includes:
1. Risk identification and classification
- List of foreseeable misuse scenarios for this specific AI deployment
- Severity classification for each scenario (data breach, unauthorized financial action, regulatory violation, etc.)
- Probability assessment based on deployment context (customer-facing vs. internal, tool access scope, data access scope)
2. Test methodology
- Attack taxonomy used (recommend FinProof as the BFSI-mapped benchmark)
- Test input counts per category
- Pass/fail criteria (acceptable ASR thresholds per attack type)
- Testing infrastructure (model version, deployment configuration, test environment)
3. Test results
- ASR by attack category with confidence intervals
- Specific failed tests (de-identified if needed for security reasons, but count and category must be documented)
- Comparison against acceptable ASR thresholds
4. Risk management measures
- Controls implemented in response to test findings
- System prompt hardening measures
- Tool access controls and allow-lists
- Knowledge base integrity controls
- Output filtering configuration
5. Ongoing monitoring plan
- Re-testing triggers (model update, system prompt change, new attack category publication)
- Monitoring metrics and alert thresholds
- Responsible party for ongoing risk management
This documentation package satisfies Article 9 and Article 11 together. It's audit-ready for a notified body or a competent national authority examination.
The EU AI Act didn't specify that adversarial testing is required by name. But "testing to identify appropriate risk management measures for foreseeable misuse" is a description of adversarial testing. There isn't another kind of testing that satisfies that definition.
The 88% of financial institutions without a defined compliance strategy need to close this gap. The adversarial testing component is one of the most concrete and documentable parts of Article 9 compliance — and it's the part that's currently missing from most programs.
- FinProof benchmark (EU AI Act mapped): huggingface.co/datasets/Zytra/finproof-bench
- Article 9 compliance assessment: finproof@zytratechnologies.com
- Try the agentic scenarios: finproof.ai/agent-siege
See also: DORA + EU AI Act: Build One Testing Program · RBI Model Risk Management 2026: Adversarial Testing · BFSI AI Attack Taxonomy: 11,474 Prompts