The High-Risk AI System Readiness Playbook
How to find, fix, and prove control over your highest-risk AI before the regulator — or your biggest customer — asks
Oct 11, 2026 · @disc
You have roughly 14 months until the EU AI Act’s Annex III high-risk obligations apply on 2 December 2027, and a credible readiness program for a single high-risk system takes 9 to 12 of them. That math leaves almost no slack.
In June I argued that the Digital Omnibus delay was a trap: regulatory relief is not risk relief. The delay is now law. What most organizations still lack is the playbook for spending the reprieve well — one that treats a high-risk AI system as a security and governance problem first and a paperwork problem second.
This post is that playbook. It covers how to confirm you are actually high-risk, what an assessor will ask to see, the threats that make these systems dangerous, the controls that mitigate them, and a 14-month roadmap. It draws on our work taking Virtual Data Room through ISO/IEC 42001 Stage 2 certification on the first attempt, plus the EU AI Act, NIST AI RMF, OWASP and MITRE ATLAS.
Who this is for: CISOs, CAIOs, GRC leads and product owners at B2B SaaS and financial services firms that build or deploy AI used in hiring, credit, insurance pricing, education, critical infrastructure or access to essential services — or that sell to firms that do.
Where the clock actually stands
The Omnibus moved dates, not definitions: a system that was high-risk before Regulation (EU) 2026/1744 is still high-risk today. The regulation was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026.
| Obligation | Applies from | Status |
| Prohibited practices, AI literacy | 2 Feb 2025 | In force |
| GPAI model obligations | 2 Aug 2025 | In force, not delayed |
| New Art. 5 prohibitions, watermarking | 2 Dec 2026 | ~7 weeks away |
| Annex III stand-alone high-risk systems | 2 Dec 2027 | Deferred from 2 Aug 2026 |
| Annex I high-risk AI in regulated products | 2 Aug 2028 | Deferred from 2 Aug 2027 |
Two details matter for planning. The delay was driven largely by slow progress on harmonised standards, so expect standards to land late and leave less time to align with them. And the Omnibus expanded the AI Office’s supervisory role over systems built on general-purpose models — the exact architecture most SaaS AI features now use.
The regulator is also not your first deadline. Enterprise procurement teams are already sending AI addenda that ask for Article 9–15 evidence. Your customer’s questionnaire will arrive long before a market surveillance authority does.
Step zero: confirm you are actually high-risk
Misclassification is the most expensive mistake in this regime, in both directions. Under-classify and you ship a non-conforming system; over-classify and you burn a year of engineering on obligations that never applied. Work through five gates, in order, and write down the answer to each.
- Is it an AI system at all? Rules engines and fixed scoring formulas usually are not. Models that infer outputs from inputs with some autonomy usually are.
- Is it prohibited? Check Article 5 first, including the two new prohibitions that apply from 2 December 2026. A prohibited practice cannot be “managed” as high-risk.
- Is it an Annex I safety component, or listed in Annex III? For SaaS and financial services, the Annex III areas that bite most are employment (screening, ranking, performance monitoring), creditworthiness and credit scoring, life and health insurance pricing, and education access or assessment.
- Does the Article 6(3) exception genuinely apply? An Annex III system escapes high-risk status only if it performs a narrow procedural or preparatory task, or only refines a completed human decision, without materially influencing the outcome. Any system that profiles natural persons is always high-risk. If you claim the exception, document the assessment before launch — authorities can ask for it.
- What is your role? Providers carry Articles 9–17 and conformity assessment; deployers carry Article 26. Watch Article 25: putting your name on a system, substantially modifying it, or repurposing a general-purpose model into an Annex III use makes you the provider.
That last gate catches most of our SaaS clients. Wrap a foundation model in a candidate-ranking feature and you are no longer “just using an LLM” — you are the provider of a high-risk system, and the model vendor’s documentation covers only a fraction of what you now owe.
What an assessor will ask to see
Every obligation resolves to an artifact you can hand over, and the artifact is what gets assessed. If you cannot point to it, the control does not exist.
| Article | Obligation | Evidence an assessor expects |
| Art. 9 | Continuous risk management | Living AI risk register; foreseeable-misuse analysis; residual-risk acceptance signed by an accountable owner; pre-release test results against predefined thresholds |
| Art. 10 | Data governance | Dataset datasheets; provenance and lineage records; representativeness and bias analysis; documented gaps |
| Art. 11 / Annex IV | Technical documentation | Versioned technical file: architecture, training method, metrics, change history, standards applied (retain 10 years) |
| Art. 12 | Automatic logging | Event logs that can reconstruct any decision; deployers retain at least 6 months |
| Art. 13 | Transparency to deployers | Instructions for use stating accuracy, known limits, performance by group, oversight measures |
| Art. 14 | Human oversight | Override and stop mechanisms; named, trained overseers; override and escalation records |
| Art. 15 | Accuracy, robustness, cybersecurity | Declared accuracy metrics; drift monitoring; adversarial and red-team test reports; fail-safe design |
| Art. 17 | Quality management system | Documented QMS covering design control, testing, data, change management, supplier security, accountability |
| Art. 43, 47–49 | Conformity, declaration, registration | Conformity assessment record; EU Declaration of Conformity; CE marking; EU database entry |
| Art. 72–73 | Post-market monitoring, incidents | Monitoring plan; serious-incident runbook with regulator notification paths |
| Art. 26 (deployers) | Use as instructed | Use-policy, input-data controls, monitoring and suspension procedure, worker notification, DPIA where required |
For most Annex III areas (2 through 8), conformity assessment is internal control under Annex VI — no notified body. That sounds easier. In practice it means nobody external will catch your gaps before a regulator, a plaintiff or a customer does.
Why high-risk AI fails: four threat families
Article 15 names the attacks explicitly — data poisoning, model poisoning, adversarial examples, confidentiality attacks and exploitation of model flaws. That list was written before agentic AI went mainstream. In the systems we assess today, the harms cluster into four families.
- Attacks on the model. Poisoned training or fine-tuning data, tampered weights or adapters, adversarial inputs, and extraction attacks such as membership inference and model inversion. Catalogued in MITRE ATLAS.
- Attacks through the interface. Direct and indirect prompt injection, jailbreaks, and sensitive data leaking through outputs or retrieval. In an LLM-backed scoring or screening flow, a single crafted résumé or loan document can carry instructions. See the OWASP Top 10 for LLM Applications.
- Attacks through agency and the supply chain. Over-permissioned tools, confused-deputy calls, poisoned MCP tool manifests, compromised model hubs and third-party APIs. An agent that can act inherits every permission you gave it, and every weakness in what it calls.
- Failures without an attacker. Data drift, feedback loops that amplify bias, silent accuracy decay, and automation bias in the humans meant to catch errors. These cause most real-world harm, and they are the hardest to see on a dashboard.
The regulation cares about outcomes for people — a wrongly rejected applicant, a mispriced policy — not about which family caused them. Your controls have to cover all four.
The mitigation playbook, risk by risk
Article 9(4) sets the order of preference: eliminate the risk by design first, mitigate what remains, and only then rely on information and warnings. Each row below follows that order.
| Risk | Design-level control | Operational control | Proof it works | Maps to |
| Biased or unrepresentative data | Exclude proxy features; set representativeness targets per protected group before training | Fairness metrics (e.g. selection-rate ratio, equalized odds) gated in CI | Bias test report per release; dataset datasheet | AI Act Art. 10; ISO 42001 A.7; NIST MEASURE 2.11 |
| Data and model poisoning | Signed datasets and model artifacts; provenance checks at ingestion | Hash verification on deploy; anomaly detection on fine-tuning data | AI bill of materials; signature verification logs | Art. 15; ATLAS AML.T0020; ISO 27001 A.8.28 |
| Prompt injection | Treat all retrieved and uploaded content as untrusted; separate instructions from data; constrain outputs to a schema | Input and output filtering; canary tokens; injection test suite in CI | Red-team report with pass rates per release | Art. 15; OWASP LLM01 |
| Excessive agency and tool misuse | Least-privilege, scoped tokens per tool; no autonomous final decisions on people | Human approval for consequential actions; egress allowlists; per-tool rate limits | Tool permission inventory; approval logs | OWASP LLM06; OWASP Agentic Top 10 |
| MCP and AI supply chain | Pinned, integrity-checked tool manifests; OAuth 2.1 with PKCE and audience-bound tokens | Vendor AI due diligence; monitoring of model and API version changes | Supplier register; manifest integrity checks | Art. 17(1)(l); ISO 42001 A.10; ISO 27001 A.5.19–5.22 |
| Data leakage and model extraction | Data minimization; no sensitive data in prompts or training without a lawful basis; output redaction | Query rate limiting; membership-inference testing | DPIA; extraction test results | Art. 10(5), 15; GDPR Art. 35; OWASP LLM02 |
| Drift and silent accuracy decay | Declared accuracy thresholds with fail-safe fallback to human review | Production monitoring against the declared metrics; retraining triggers | Monitoring dashboard; post-market monitoring reports | Art. 15, 72; NIST MANAGE 4.1 |
| Feedback-loop bias | Isolate model outputs from future training labels | Periodic outcome audits by group | Outcome audit records | Art. 15(4); ISO 42001 A.6.2.6 |
| Automation bias | Interfaces that show confidence, reasons and uncertainty; friction before rubber-stamping | Overseer training; sampled second review of approvals | Override-rate and review-time metrics | Art. 14; NIST GOVERN 3.2 |
| Opaque incidents | Decision-level event logging from day one | Serious-incident runbook with 15-day regulator notification path | Tabletop exercise record | Art. 12, 73 |
The security controls in this table are not new. What is new is that Article 15 makes them a legal condition of placing the system on the market, and Article 11 requires you to prove each one in the technical file.
Human oversight that survives scrutiny
A “reviewed by” checkbox records what the overseer said, not what the overseer did. That gap is where most oversight programs fail an assessment. Article 14 requires people who can understand the system, recognize automation bias, and actually override or stop it.
Oversight you can defend has five properties:
- Authority. The overseer can reject, reverse or halt the output without escalation, and the stop mechanism is tested.
- Competence. The overseer is trained on the system’s limits and on automation bias, and the training is recorded.
- Capacity. Review volume per person is set so a real review is possible. Forty decisions an hour is not oversight.
- Information. The interface shows confidence, the main factors and the cases the model is known to handle badly.
- Evidence. Logs capture what the overseer saw, how long they spent, and whether they changed the outcome.
Then measure it. An override rate near zero for months is a warning sign, not a success metric: either the model is perfect or nobody is really looking. Sampled second reviews tell you which.
One control set, many frameworks
Build the high-risk program once, on an ISO/IEC 42001 AI management system, and let it answer the EU AI Act, NIST AI RMF and your customers’ questionnaires together. ISO 42001 is not a harmonised standard and does not grant presumption of conformity on its own. It does give you the management-system spine — policy, roles, risk process, internal audit, management review — that Article 17 expects a quality management system to have.
| AI Act requirement | ISO/IEC 42001 | NIST AI RMF | ISO/IEC 27001:2022 |
| Art. 9 risk management | Cl. 6.1, 8.2–8.3; AI risk treatment | MAP, MEASURE, MANAGE | Cl. 6.1, 8.2 |
| Art. 10 data governance | Annex A.7 | MAP 2.3, MEASURE 2.11 | A.5.12, A.8.11 |
| Art. 11 technical documentation | A.6.2.7 | GOVERN 1.4 | A.5.37 |
| Art. 12 logging | A.6.2.8 | MEASURE 2.4 | A.8.15 |
| Art. 13 transparency | A.8 | GOVERN 4.2, MAP 3.3 | — |
| Art. 14 human oversight | A.9 | GOVERN 3.2, MANAGE 2.4 | — |
| Art. 15 robustness and security | A.6.2.4, A.6.2.6 | MEASURE 2.5–2.7 | A.8.8, A.8.25–8.29 |
| Art. 17 QMS | Cl. 4–10 | GOVERN | Cl. 4–10 |
| Art. 27 FRIA / impact | A.5 AI system impact assessment | MAP 5.1 | — |
| Art. 72–73 monitoring, incidents | Cl. 9.1, 10.2 | MANAGE 4.1–4.3 | A.5.24–5.28 |
If you already run an ISO 27001 ISMS, much of the Article 15 and Article 17 evidence already exists. The work is extending scope to AI-specific risks and adding the AI impact assessment, data and oversight controls that 27001 never asked for. That is exactly the path we took at ShareVault.
Eight readiness failures we keep seeing
- Misclassification by optimism. Calling a screening tool “decision support” without documenting why Article 6(3) applies.
- Risk management as a one-time workshop. Article 9 requires a process that runs for the system’s whole life, fed by production data.
- No bias analysis on the actual population. Fairness tested on the training set, never on the people the system scores in production.
- Logs that cannot reconstruct a decision. Application logs exist; the inputs, model version and output for a specific applicant do not.
- Oversight theater. Humans in the loop with no time, no information and no authority to say no.
- Security scoped to the app, not the model. Pen tests that never touch prompt injection, poisoning or tool permissions.
- Vendor documentation mistaken for your own. The model provider’s system card does not cover your use case, your data or your users.
- No AI literacy record. Required since February 2025, and the easiest finding for an assessor to write up.
The bottom line
High-risk readiness is not a documentation sprint you run in autumn 2027. It is a security and governance program that has to be operating — producing logs, bias reports, override records and red-team results — long enough to prove it works. Start now and December 2027 is a formality. Start late and it is a fire drill with your largest customers watching.
At DISC InfoSec we have done this work as practitioners, not just advisors: we took Virtual Data Room through ISO/IEC 42001 Stage 2 certification on the first audit and wrote its MCP governance standard. We bring the same approach to B2B SaaS and financial services teams facing AI Act, customer or board deadlines.
Three ways to start this week:
- Run our free EU AI Act Risk Classifier to confirm where each of your AI systems lands.
- Book a High-Risk AI Readiness Assessment: a scoped gap analysis against Articles 9–15 and 17, with a prioritized 14-month plan.
- Talk to us about a vCAIO retainer to run the program through conformity.
“DiscInfoSec” Deura, CISSP, CISM, ISO/IEC 42001 and 27001 Lead Implementer – info@deurainfosec.com – (707) 998-5164 – Book a call
Sources
- EU Digital Omnibus on AI enters into force — National Law Review
- EU Digital Omnibus on AI enters into force — Mondaq
- EU AI Act Digital Omnibus: enterprise risk recalibration — Cloud Security Alliance
- Regulation (EU) 2024/1689 (AI Act), Articles 5, 6, 9–17, 25–27, 43–49, 72–73
- ISO/IEC 42001:2023; NIST AI RMF 1.0; OWASP Top 10 for LLM Applications 2025; MITRE ATLAS
- 14 Months to Comply. 12 Months of Work. The High-Risk AI Playbook Nobody Has Started
- Your biggest AI risk isn’t hackers. It’s your own data walking out the door
- The cheapest security control you’ll ever implement is the component you decided not to build
- AI Handoffs: How Uncertainty Propagates—and How to Fix It
- The Security Risks Hiding in AI Agent Memory
