How Diagrid Catalyst Helps You Meet EU AI Act Requirements

What is the EU AI Act?

The EU AI Act (Regulation 2024/1689) is the world's first comprehensive AI law, in force since August 2024 and phasing in through 2028. Like GDPR, its reach extends beyond Europe to any organization whose AI systems are placed on the EU market, or whose output is used inside the EU, wherever the company itself is based.

The Act regulates by risk tier:

• Unacceptable risk: A few practices banned outright, such as social scoring and certain biometric surveillance, prohibited since February 2025.
• High risk: Consequential uses like credit scoring, medical devices, recruitment, biometric identification, critical infrastructure, and law enforcement. This is where the substantive obligations live, and where this article is aimed.
• Limited / transparency risk: Chatbots and generative tools, which mainly must disclose that a person is interacting with AI and label AI-generated content.
• Minimal risk: Everything else, such as spam filters and recommendation engines, essentially unregulated.

So the first task isn't compliance, it's classification: inventory the AI systems you build, buy, or operate, and determine which tier each falls into. Many will be minimal or limited risk. But if any land in high-risk, a substantial set of requirements attaches. Risk management, record-keeping, transparency to deployers, human oversight, and post-market monitoring all apply, with penalties up to €15M or 3% of global annual turnover for falling short, and up to €35M or 7% for deploying a banned system.

Is your financial AI in scope? Financial services aren't high-risk as an industry, the Act classifies by use, not by sector. Under Annex III, point 5, two financial uses are named explicitly: evaluating the creditworthiness of individuals or setting their credit score (loan origination, automated underwriting, BNPL decisioning), and risk assessment and pricing for life and health insurance. If either touches EU individuals, it's in scope, even if your model runs from a data center outside the EU. Just as important is what's out: fraud detection is expressly carved out of the credit-scoring category, property, casualty, and auto insurance pricing fall outside the life/health provision, and AML and capital-adequacy models are governed by sector law rather than Annex III. One caveat that trips teams up: the "not high-risk" exception never applies if a system profiles individuals, a profiling system is always high-risk, however narrow the task looks. The practical upshot for a bank or lender: your credit-scoring engine is the textbook high-risk system, and the durable, verifiable, access-controlled execution is required.

The deadline moved, however the work didn't get easier

On June 29, 2026, the Council of the EU gave final approval to the Digital Omnibus, pushing the compliance deadline for high-risk AI systems under Annex III from August 2, 2026 to December 2, 2027. If you're building or deploying a high-risk AI system in the EU, you now have roughly 18 months instead of a few weeks.

Sixteen extra months is not a pause though. The hardest part of AI Act compliance was never the documentation template. It's building the operational infrastructure that makes the obligations real in production: a living risk management system, tamper-evident logging over the system's lifetime, transparency to deployers, or a human oversight that works under load. That work will take most of the time to achieve, even if you start today. Start it in late 2027 and you'll have weeks, not months.

Many organizations will reach for observability tooling first, and they should. But observability only gets you part of the way, and it stops precisely where the highest-risk obligations begin.

The compliance layer observability can't reach

A growing number of observability and tracing platforms position themselves around the EU AI Act, and it's worth being precise about what they do. LangSmith captures high-detail traces of agent execution for teams building on LangGraph. Langfuse offers the same tracing self-hosted, and leans on data sovereignty as its compliance angle. Arize and Fiddler bring enterprise-scale monitoring, drift detection, and guardrails, with Fiddler positioning itself as a governance and compliance control plane. Langtrace advertises EU AI Act support directly. Evaluation-first tools like Braintrust, Galileo, and Confident AI go after the quality side, scoring outputs for hallucination, bias, and safety.

All of this is necessary work, and it maps cleanly onto parts of the Act. Trace capture supports the record-keeping expected under Article 12; output evaluation supports the accuracy and bias requirements of Articles 10 and 15. If you're running a high-risk system, you want one of these tools.

But notice what they have in common. Every one of them sits at the same layer: they observe what your agent did and evaluate whether the output was good. That's a real capability, and it's also a ceiling. Two questions sit underneath that layer, and tracing can't answer either, regardless of which vendor you pick:

Can you prove it happened as recorded? A trace is a log your system wrote about itself. For a regulator or auditor asking whether a consequential decision was made the way your records claim, a log that your own system could have altered, dropped, or replayed is weak evidence. Article 12 asks for records sufficient to identify risk and support oversight over the system's entire lifetime. The stronger position isn't "we recorded it", it's "we can prove the record wasn't changed."

Was the agent allowed to do it in the first place? Tracing observes actions after the fact. It doesn't govern them. When an agent calls a tool, reads a data source, or invokes an MCP server, the compliance-relevant question is whether that agent was authorized to make that call, and whether you can enforce and prove that boundary. Observability has nothing to say here. It watches; it doesn't control.

These two gaps, proof and control, are the deep compliance layer, and no observability tool crosses into them. LangSmith, Langfuse, Arize, Fiddler, and the rest can tell you what happened and how good the output was; none of them make the record tamper-evident, and none of them govern what an agent is authorized to do at runtime. Langfuse's self-hosting gets you data residency, not authorization. This is the layer that matters most for exactly the high-risk categories the Act targets, and it's the layer Diagrid Catalyst was built for.

This comes down to the need to AI Agent identity.

Catalyst is an agentic durable execution platform, built on the CNCF-graduated Dapr runtime, that brings durable workflows, cryptographic identity, and policy-based access control to AI agents and MCP servers. It deploys into your own infrastructure, AWS, Azure, GCP, or on-premises, up to fully air-gapped, and works with the agent frameworks teams already use, including Dapr Agents, LangGraph, CrewAI, Strands, OpenAI Agents, Google ADK, Pydantic AI, and the Microsoft Agent Framework.

Let's now dive into how these three core capabilities map onto the Act's high-risk requirements.

Durable execution: human oversight and robustness

Article 14 requires that humans can understand, intervene on, override, and interrupt a high-risk system. Article 15 requires accuracy, robustness, and resilience against errors and faults.

Both requirements are architectural, not procedural. You can't bolt human oversight onto an agent that runs to completion in one uninterruptible pass, and you can't claim robustness for a workflow that loses its place when a node crashes mid-run.

Catalyst's durable execution engine solves this. Agents and workflows checkpoint their state as they run, so they pick up exactly where they left off after any failure, from a routine restart to a complete system outage, with exactly-once semantics that prevent an action from being silently dropped or executed twice. The hard part, failure detection, is done for you.

For human oversight, that means an agent can pause at a defined decision point, hold, for minutes, hours, or days, while a person reviews, and then resume from the exact same state once the human approves, rejects, or edits the decision. The oversight step becomes a first-class, durable part of the execution graph rather than a best-effort callback that a crash can lose. That's the difference between an oversight mechanism you can demonstrate to an auditor and one you can only hope fired.

For robustness under Article 15, Catalyst delivers crash recovery, automatic retries, and guaranteed progress for long-running processes, the reliability properties the Act expects of a system operating in a high-risk setting.

Verifiable execution: tamper-evident auditability

Article 12 requires automatic, lifetime record-keeping sufficient to identify risks and support post-market monitoring. Article 13 requires that a system's operation be traceable and interpretable enough for deployers to use it appropriately.

This is where the gap between a log and a proof matters most. Catalyst's verifiable execution cryptographically signs and attests workflow history, so the record of what an agent did is tamper-evident: any alteration after the fact is detectable. You're not asking an auditor to trust that your logging pipeline was faithful. You're handing them a record whose integrity can be independently verified.

Combined with durable execution, this produces an audit trail that is both complete, every step of a long-running, multi-stage agent process is captured, and provably unaltered. That's a materially stronger Article 12 statement than retained traces alone, and it's the kind of evidence that holds up when a decision is contested after the fact rather than merely inspected in the moment.

Where this is going: verifiable agent records are becoming a standard. The idea that agent action records should be tamper-evident rather than self-attested is not just Diagrid's position, it's where open standards are heading. The IETF's SCITT working group (Supply Chain Integrity, Transparency, and Trust) is standardizing cryptographically verifiable transparency logs, and a set of emerging profiles built on it, the Agent Action Capsule (AAC) and its companions, apply that model directly to autonomous agents. AAC records what an agent did, executed, blocked, denied, errored, or timed out, in a way that structurally prevents an attempt from being presented as a completion, while companion profiles record who authorized the action and the provenance of the belief it acted on. That three-part decomposition, what happened, whether it was allowed, and why it was believed, maps exactly onto the split this article draws between tracing and verifiable, access-controlled execution. Catalyst's signed workflow history is conceptually the same artifact these profiles describe, which points to a natural path as the specs mature: emitting standards-conformant capsules and anchoring workflow attestations to a transparency service. One caveat worth stating plainly: these are early Internet-Drafts, not ratified standards, and the EU AI Act does not require them. But the direction is telling. Independent standards bodies are converging on the same conclusion the Act's record-keeping provisions imply, that a log you can alter is not evidence, and that verifiable execution is where high-stakes AI is going.

Identity and access control: governance and authorization

Article 13 requires traceability. The Act's broader high-risk regime requires that you can govern what a system does, which data it touches and which actions it can take. This is the requirement observability tools structurally cannot address, because it's about control, not observation.

Catalyst issues cryptographic identities to agents, MCP servers, and tools, built on SPIFFE-based workload identity with mTLS between components. Every action is attributable to a verifiable identity rather than an anonymous process, which is what real traceability under Article 13 demands: not just "an action occurred," but "this specific, authenticated agent took this action."

On top of identity, Catalyst applies policy-based access control across the organization. You define which agents are permitted to reach which MCP servers, tools, and data sources, and Catalyst enforces those policies at runtime. For a high-risk system, that turns "which tools and data can this agent access?" from an open question into a governed, enforced, and auditable one. It's the authorization layer beneath your agents, the control plane the Act increasingly assumes exists.

Where Catalyst fits, and where it doesn't

Catalyst doesn't run your bias evaluations (Article 10) or replace behavioral scoring of model outputs, that's the work observability and evaluation tooling does well, and the two layers are complementary. What Catalyst provides is the execution, proof, and control foundation those higher layers assume but don't supply: the durable runtime that makes oversight reliable, the verifiable record that makes logging trustworthy, and the identity and access control that make agent behavior governable.

The same is true of the hyperscaler AI platforms. AWS, Microsoft, and Google Cloud all position themselves on the EU AI Act, and all three run a shared-responsibility model: they secure and certify the infrastructure and provide compliance building blocks, but the Act's obligations for your high-risk system remain yours as the deployer. Their tooling is genuinely useful, and it clusters at the evaluation, safety, and documentation layer. Microsoft Foundry offers Content Safety, generative-AI evaluations, the Responsible AI Dashboard, and Purview Compliance Manager templates; AWS pairs Bedrock Guardrails and SageMaker Clarify with CloudTrail logging; Google Cloud offers equivalent controls around Vertex AI. What none of them provide is the layer beneath: durable execution that makes human oversight reliable, cryptographically verifiable records rather than logs kept immutable by storage policy, and runtime authorization over which agent may call which tool or MCP server. That is the deployer's side of the shared-responsibility line, and it's where Catalyst fits.

Put simply: observability tells you what your agent did. Catalyst lets you prove it, control it, and recover from failure without losing either.

Diagrid Catalyst provides Agentic Durable Execution. Agentic durable execution automatically recovers from failures, carries autonomous AI agents and deterministic workflows to completion and provides cryptographic tamper-proof evidence of what happened. Catalyst can be combined with any agent platform to bring agentic durable execution to your agents to address the needs of the EU AI Act. That can be hyperscaler AI offerings such as AWS Bedrock, Microsoft Foundry or GCP Gemini Enterprise Agent Platform to agent platforms developed in house.

Where to start

December 2, 2027 is further away than August was, but the infrastructure work is the long pole. If you're running a high-risk AI system, three foundations are worth standing up now:

Durable execution for any long-running or multi-step agent, so human oversight (Article 14) and robustness (Article 15) are architectural guarantees rather than aspirations.

Verifiable execution for your workflow history, so your Article 12 records are tamper-evident and your Article 13 traceability is defensible when a decision is challenged.

Identity and access control for every agent, tool, and MCP server, so authorization is enforced and attributable, the governance layer no amount of tracing can provide.

EU Articles

Catalyst runs in your own cloud or on-premises environment, including fully air-gapped deployments, so data residency and sovereignty requirements are satisfied by where it runs, not by a vendor's regional promise.