Should a Regulated Bank Connect AI Agents to Its Architecture?

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

The question CIOs and CISOs are actually asking

The market keeps saying "talk to your architecture." Vendors race to connect Claude, Copilot, ChatGPT or Gemini to the EA repository so an architect can ask questions in plain language. For a regulated bank, that pitch lands differently. The person who has to sign off is not excited by the demo — they are calculating what just left the building.

So the real question is not "is AI useful on our architecture?" It almost certainly is. The question is whether connecting an agent to the EA repository is a defensible decision for a DORA/CSSF-supervised institution, and if so, under what conditions. This is a decision and risk framework, not a recommendation to connect or to abstain. It is a documentation and risk-framing aid — not legal advice, and it does not make you compliant with DORA, GDPR, the EU AI Act or CSSF expectations.

The upside — why this is worth the conversation

If the risk were trivial nobody would push back, and if the value were trivial nobody would push forward. The value is real. An agent reasoning over a living EA model can compress work that today eats weeks of architect time.

Three uses tend to justify the whole conversation. Impact analysis: "if we decommission this core component, what breaks and which critical functions are affected?" — answered against the dependency graph in seconds instead of a fortnight of interviews. Rationalization: surfacing redundant or obsolete applications as candidates for retirement. Compliance reporting: drafting the architecture sections of a DORA register or a CSSF submission from the model rather than from memory. None of this is hypothetical hype; it is the ordinary work the EA repository already holds the answers to.

• Impact analysis on the dependency graph — minutes instead of weeks
• Rationalization: redundant and obsolete applications surfaced as retirement candidates
• Compliance and audit reporting drafted from the model, not from tribal memory
• Faster onboarding: a new architect can interrogate the estate without a guided tour

The exposure — what the EA map really is

Here is the part the demo skips. An EA map is not a tidy diagram; it is a near-complete blueprint of the bank. It holds the full system inventory, the critical dependencies, the obsolete components still in production, the known vulnerabilities, the sensitive data flows, and sometimes the security measures themselves.

Assembled, that is the single most useful document an attacker could obtain — and the single disclosure a supervisor is most likely to question. When you attach EA context to a prompt sent to a general US-cloud LLM, that context leaves your control and crosses a third-country boundary. The agent answered a question; you also exported the blueprint. That is the asymmetry at the heart of this decision.

• Full system inventory and critical dependencies — the bank's nervous system
• Obsolete components and known vulnerabilities — a ready-made attack map
• Sensitive data flows and, sometimes, the security controls themselves
• A near-complete blueprint that, once sent out, you cannot recall

The regulatory frame: DORA, GDPR, the EU AI Act, CSSF

Four regimes shape this decision, and they overlap rather than stack neatly. Treat the summary below as the map for a conversation with your second and third lines of defence, not as a clearance.

DORA brings ICT third-party risk and concentration into scope: a general-purpose LLM provider can become a critical ICT third party, and routing your most sensitive context through one model concentrates risk in a way the regulation expects you to manage. GDPR applies the moment any personal data appears in the context and governs the transfer when inference happens outside the EU. The EU AI Act layers obligations that scale with how the use case is classified. CSSF expectations sit on top for Luxembourg-supervised entities, where outsourcing and ICT-risk circulars set the supervisory tone. None of these say "never"; all of them say "govern it, and be able to evidence the governance."

• DORA — ICT third-party risk and concentration when an external model becomes critical
• GDPR — personal data in context, and EU-to-third-country transfer at inference time
• EU AI Act — obligations scaling with the use case's risk classification
• CSSF — outsourcing and ICT-risk expectations for Luxembourg-supervised entities

How to decide: which questions are safe, which objects must never leave

The decision is not "AI or no AI." It is a question-by-question and object-by-object judgment, which is exactly why a flat ban and a blank cheque are both wrong. Split the space into what can be answered safely and what must stay inside the perimeter.

Many questions are low-risk: aggregate counts, capability coverage, ownership lookups, high-level dependency direction. Some are categorically not: anything that returns the live vulnerability list of a critical function, the security controls protecting a system, or a sensitive data flow tied to identifiable people. The discipline is to define those classes once, encode them, and let the gate — not the architect's judgment in the moment — enforce them.

• Generally safe to ask: aggregate inventories, capability coverage, ownership and high-level dependencies
• Never let leave the repository: live vulnerability lists, security controls of critical systems, person-linked data flows
• Decide by object type and sensitivity class, defined once — not improvised per query
• Default to deny for anything touching a critical function until explicitly cleared

The four gates and the sovereign options

If the institution decides to proceed, four gates turn "connect an agent" into something defensible. Residency: keep inference in the EU or on infrastructure you control, so context does not cross a third-country boundary. Permissions: the agent sees only what the asking user is entitled to see — per-user, not a god-mode service account. Redaction: sensitive object types (vulnerabilities, security controls) are withheld at the boundary even when the rest of the answer flows. Logging: every query is recorded — who asked what, when — so the governance is evidenced, not asserted.

Those gates are only fully achievable with a sovereign delivery model. The options are concrete: an EU-hosted model, a private or on-premise deployment, or a European LLM. This is what we mean by a data-residency-aware MCP — an interface that governs where the data goes, not only who queries. To be honest about our own state: a sovereign MCP server is the direction ArchiLU is building toward, our conviction about how this should work, not a feature you can switch on today. What we do offer today is the governed context underneath it — an EU-region or on-premise EA model you control, native FR/EN, built around DORA/CSSF documentation needs.

• Residency gate — inference in the EU or on infrastructure you control
• Permission gate — per-user entitlements, never a god-mode service account
• Redaction gate — withhold vulnerabilities and security controls at the boundary
• Logging gate — who asked what, when, retained as audit evidence
• Sovereign options — EU-hosted model, on-premise deployment, or a European LLM

The verdict: yes — but only governed and sovereign

Connecting an AI agent to the architecture of a regulated bank is not reckless and it is not inevitable. It is a governed decision. Done with residency, permission, redaction and logging gates over a sovereign delivery model, the high-value uses — impact analysis, rationalization, compliance drafting — become defensible, and you can show your supervisor the governance rather than promise it. Done by pointing a general US-cloud LLM at the live repository, you have exported the blueprint of the bank and you cannot take it back.

Start from where your practice actually stands, not from a vendor demo. ArchiLU's free EA Maturity Assessment scores ten dimensions in about ten minutes and gives a concrete read on whether your context is even governed enough to connect an agent to it responsibly. Remember the disclaimer throughout: this framework helps you document and reason about the risk; it does not constitute legal advice and does not by itself make you compliant with DORA, GDPR, the EU AI Act or CSSF expectations.

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