DORA and Architecture Traceability in the Age of AI Agents

Sovereign context operating model

An AI agent is only as good as the context it can reach. For a regulated enterprise, that context — the architecture repository — is also one of its most sensitive assets.

The operating model that matters is not "expose the repository over MCP"; it is "govern what context leaves, to whom, and under which residency and audit constraints".

• Decide which object types are queryable, and which are never exposed
• Keep context fresh: reconcile the repository against live sources, not a yearly snapshot
• Make every answer traceable to a governed source the user is entitled to see

DORA already asked you to make architecture traceable

Long before AI agents entered the picture, DORA set a clear expectation for regulated finance: know your ICT dependencies, identify which of them support critical or important functions, document your third-party arrangements, and be able to explain — with evidence — how your operational resilience holds together. That is, at heart, a traceability requirement applied to your architecture.

Our companion pillar on architecture governance for DORA and NIS2 covers the machinery that produces this: the review board, decision records, the application register and ICT dependency mapping. This article does not repeat it. It looks at what changes when AI agents start reasoning over that same architecture data — because the traceability bar does not drop when a model joins the workflow; it rises.

One disclaimer up front, and we will keep it honest throughout: nothing here makes you legally compliant. DORA compliance is decided by regulators and auditors against your organisational, contractual and security measures. A governed architecture model — with or without AI — helps you document and evidence what you do. It does not replace legal, risk and security work.

What an AI agent changes about your ICT supply chain

An AI agent that answers questions about your architecture, or proposes a remediation, is not a neutral feature. It usually depends on an external large language model. The moment that model influences an operational or resilience decision, the provider behind it has a claim to be part of your ICT supply chain — exactly the kind of relationship DORA expects you to identify, document and assess.

Treated honestly, this raises familiar third-party questions in a new place. Who is the provider, and under what contract? Where does the data go? And — the one teams forget — if three or four critical workflows all quietly depend on the same model, you have a concentration risk you never recorded. The discipline is to treat any external model as a dependency to document, not an invisible utility you reach for by default.

• An external model provider behind an agent is a candidate ICT third party
• Several critical workflows on one model is a concentration risk to record
• Contract, data location and exit posture are the usual third-party questions, applied to AI
• The honest default: document the model dependency, do not hide it

Prompts and responses are a data flow you have to describe

When an agent sends architecture context to a model, think about what that context actually is. It can include system inventory, criticality ratings, dependency maps, hosting details — in aggregate, a near-complete blueprint of the organisation. The prompt is an outbound data flow; the response that shapes a decision is an inbound one. DORA-minded governance expects you to know what data moves where, and AI does not get an exemption.

This is where the source of the context matters enormously. If the agent draws from scattered exports and ad-hoc copies, you cannot describe the flow with confidence — and you certainly cannot prove it later. If the context comes from one governed model you can point to, the flow becomes describable: this defined slice of the architecture, with these residency attributes, was the input. The cleaner the source, the cleaner the evidence.

A living, governed model is the traceability anchor

The asset that makes any of this defensible is a current, governed architecture model — not an eighteen-month-old snapshot. A living application register, mapped ICT dependencies and recorded decisions are already what a resilience review wants to see. They are also what an AI agent should be reasoning over, because grounding an agent in stale or shallow data produces confident answers that no auditor would accept.

Concretely, this is the same backbone the governance pillar describes, used for a new purpose. The register tells you which applications support a critical function. The dependency map tells you what those applications rely on. When an agent's recommendation is grounded in that model, the recommendation inherits the model's traceability instead of floating free in a chat window.

• An application register with owners, criticality and hosting attributes
• Mapped ICT dependencies from critical functions down to providers
• Decision records that capture the human choice and its rationale
• Continuously maintained, so the agent reasons on current reality

Keeping AI-influenced decisions inside the frame

The risk with agents is not that they give bad answers; it is that a good-looking answer arrives with no provenance. A resilience decision that can only be traced to an opaque conversation is precisely what a supervisory review does not want. The remedy is to anchor the decision: the agent's input was this versioned slice of the model, the human choice was recorded as a decision linked to the affected applications, and the trail runs from critical function to dependency to provider without a gap.

This is the practical discipline. Use the agent to accelerate analysis, then capture the outcome as a first-class decision in the same governed model — context, options, decision, rationale — exactly as you would for any significant architecture change. The AI speeds up the thinking; the governed record keeps it traceable. One without the other is either slow or indefensible.

Toward a sovereign context layer for regulated AI

There is a forward-looking version of this we are convinced is the right direction, and we will be clear that it is conviction and roadmap, not a shipped feature. We believe regulated organisations should be able to give their AI agents a sovereign context layer: a governed system of context, kept in a region you control, that an agent can reason over without the sensitive architecture map leaving your boundary. The goal is to answer the DORA questions — what depends on what, where does the data go — by design rather than after the fact.

That is where ArchiLU is heading: context first, regulatory reasoning next, and any data-residency-aware access for agents built on top of a model that was already governed, current and yours. For today, the defensible move is unglamorous and real — keep a living architecture model, treat any external model as a documented dependency, and anchor every AI-influenced decision to a governed source. If you want a fast read on where your practice stands, the free EA Maturity Assessment scores ten dimensions and returns a prioritised plan in about ten minutes.

Regulated AI context KPIs

Measure whether your context is trustworthy and governed, not how many queries the agent runs.

• Context freshness: median age of architecture objects vs live reality
• Share of answers traceable to a governed, permission-scoped source
• Sensitive object types covered by redaction/residency policy
• Audit coverage: prompts and responses logged and reviewable

Common mistakes

Most MCP-for-EA initiatives fail on context quality and governance long before they fail on the protocol.

• Exposing the full architecture repository to external LLMs without data-residency controls
• Treating MCP as the differentiator instead of the governed context behind it
• Connecting an 18-month-old, hand-maintained repository an agent cannot trust
• No permission-awareness, logging, or redaction of sensitive object types

Practical checklist

Run this before connecting any AI agent to your architecture repository.

• Confirm where prompts and responses go, and whether data stays in your region
• Enforce permission-aware access so the agent only sees what the user may see
• Classify and redact sensitive object types (vulnerabilities, data flows, controls)
• Log prompts and answers for audit, and keep a human in the loop for any change