SR 26-2 vs EU AI Act: Scoping AI Systems After the EU Digital Omnibus

What changed on the EU side

Many comparison materials still cite 2 August 2026 as the date high-risk obligations begin to apply. That date is superseded. The Commission states that delayed availability of standards put it in jeopardy, and the Digital Omnibus on AI, which entered into force on 27 July 2026, extends the timeline. As of November 2026, high-risk AI systems that are stand-alone have an application date of 2 December 2027. High-risk systems embedded in products have a date of 2 August 2028.

The underlying instrument is still Regulation (EU) 2024/1689. Its risk-tiered structure is unchanged. The Commission also notes that Annex III, the list of high-risk use cases, can be reviewed through delegated and implementing acts, so a classification made today may need to be revisited.

Two other dates came out of the Council and Parliament provisional agreement of 7 May 2026. National AI regulatory sandboxes are postponed to 2 August 2027, and the deadline for providers to implement transparency solutions for artificially generated content is 2 December 2026. The transparency date falls before the high-risk dates, so programs that produce or deploy generated content should plan for it separately.

How scope is determined under each regime

The two regimes ask different first questions. SR 26-2 is US supervisory model risk guidance, and whether a system is in scope turns on how that guidance defines a model. The EU AI Act asks which risk tier an AI system falls into. The table sets out the EU triggers and what each means for the inventory record.

• Primary scope question: SR 26-2: does the system meet the guidance's definition of a model. EU AI Act: which risk tier does the AI system fall into.
• High-risk trigger: EU AI Act: the use case, as listed in Annex III. Inventory implication: record the business use case, not only the technology.
• General-purpose AI trigger: EU AI Act: a presumption of high-impact capabilities above 10^25 FLOP of cumulative training compute. Commission guidance says models below that threshold may still pose systemic risks. Inventory implication: record the underlying model and its provider.
• Bank's role: EU AI Act: provider or deployer, determined per system. Inventory implication: record the role for each system, since it shapes which duties apply.
• Timing of obligations: EU AI Act: 2 December 2027 (stand-alone high-risk), 2 August 2028 (embedded in products). Inventory implication: record the Act version and date of each classification decision.
• Change over time: EU AI Act: Annex III can be revised by delegated act. Inventory implication: schedule reclassification reviews.

Where the regimes overlap in practice

The regimes are distinct, but production AI creates the same operational questions under both. Model risk management programs generally address inventory, validation, ongoing monitoring and documentation. For high-risk systems, Recital 66 of the EU AI Act lists requirement areas that cover similar ground: risk management, quality and relevance of data sets, technical documentation and record-keeping, transparency and information to deployers, human oversight, and robustness, accuracy and cybersecurity.

This overlap is thematic, and the two regimes should not be read as equivalent. The legal tests, the named obligations and the expected form of evidence differ. A bank that treats one as a subset of the other risks missing obligations in both directions. The more reliable approach is to maintain a separate determination for each regime and share the underlying facts: what the system does, which model it uses, who operates it, and what it was permitted to do in production.

A single inventory can serve both scoping questions if it is keyed to the use case, which is relevant to Annex III classification, and to the model, which is relevant to general-purpose AI status. Each regime's determination then becomes an attribute of the same record instead of a parallel program.

The runtime layer: what a bank can enforce and evidence

Validation and documentation describe how a system is expected to behave. Examiners and EU supervisory authorities will also want to see what a system did in production. That is where runtime enforcement applies. At the level of an individual AI interaction or tool call, a bank can enforce policy in the execution path. A request can be allowed, sensitive content can be redacted, a call can be blocked, and a consequential action can be escalated for human approval.

Two of the Recital 66 themes map directly to this layer. Human oversight is supported when escalation for approval is a policy outcome rather than an informal practice. Record-keeping is supported when each enforcement decision is captured at the point it is made, so the record is a by-product of enforcement and not a reconstruction afterward.

There are limits. Runtime enforcement covers individual interactions and tool calls. It does not replace validation, documentation or classification decisions, and it does not establish compliance with either regime on its own. The regimes' requirement themes do not define what evidence is sufficient, so the bank's second and third lines should confirm with counsel what they will present as evidence under each.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Policy is enforced at runtime, not reviewed after the fact, and the outcomes are allow, redact, block, rate limit or escalate for human approval. Enforcement generates continuous audit-ready evidence, mapped to the EU AI Act and NIST among other frameworks. It can be self-managed in the customer's cloud, with configurable retention and data residency.

In production, Trussed has run continuously in a regulated enterprise for more than 18 months, with 100+ models under one policy plane. Its customers are in insurance, pharma, healthcare and education. Trussed does not provide model lineage or model provenance, and it does not make a bank compliant with SR 26-2 or the EU AI Act. It supplies one input that risk teams can use under both: evidence of what AI was allowed to do and what it did.