What an Auditor Will Ask About Your AI's Access to Architecture Data

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 day AI gets access to your architecture, the audit clock starts

An enterprise architecture repository is one of the most sensitive maps your organisation holds: the system inventory, the critical dependencies, the obsolete components, the known vulnerabilities, the sensitive data flows. The moment an AI agent can query that repository, you have created a new control surface — and a regulator, an internal auditor, or a CSSF inspection will treat it as one.

This is not a reason to ban AI from your architecture. It is a reason to know, before the conversation happens, exactly what an auditor will ask and what evidence answers it. The good news: these questions are predictable. The honest caveat: producing the evidence is your work, not a vendor checkbox. This piece is an audit-readiness aid — it helps you prepare evidence — and it is not legal compliance or legal advice.

Below are the six questions you should expect, framed the way audit actually frames them: the question, then what good evidence looks like.

Question 1 — Who and what can query the architecture data?

The first question is about the access model. An auditor will not accept "the AI can read the repository" — they will ask which agents, acting for which users, can query which objects, and under what authorisation.

The trap is that AI access is often bolted on outside your normal identity and permission model. If the agent sees everything regardless of who is actually asking, you have effectively granted blanket access to your most sensitive map. Good evidence is an explicit access model that ties every query to an authenticated user and their entitlements, so an agent returns only what that user is permitted to see.

• Evidence: a documented access model mapping agents and users to repository objects
• Evidence: per-user permission enforcement, not a single service account that sees all
• Evidence: a review process for who is granted AI-query rights, and when it is revoked

Question 2 — Where does the data go, and across which borders?

This is the residency and transfer question, and for EU-regulated finance it is often decisive. When an agent answers, your architecture context becomes the input to a model. If that model runs outside your control — a US-cloud LLM, for example — then your system inventory, dependencies and vulnerabilities may leave your region and your governance perimeter.

An auditor will want the data path drawn, not described in the abstract. Good evidence is a documented hosting region, a clear account of any cross-border transfer, the contractual and data-processing terms that govern it, and — where it matters most — the ability to keep inference within an environment you control. Be precise about what you can prove today versus what is aspirational; auditors notice the difference.

• Evidence: documented hosting region for the model and the context it receives
• Evidence: a data-transfer map and the legal basis for any cross-border flow
• Evidence: data-processing agreements covering the model provider
• Evidence: where required, EU-region or on-premise inference you control

Question 3 — What is logged, and can you reconstruct it?

Auditability of prompts and answers is what separates a governed AI capability from an opaque one. An auditor investigating an incident — a leaked design, a wrong recommendation acted upon — will ask you to reconstruct who asked what, when, and what the agent returned.

If those interactions are not logged, you cannot investigate and you cannot demonstrate proportionate control. Good evidence is a durable, tamper-evident log of queries and responses, retained for a defined period, queryable during an investigation, and protected so the log itself cannot be quietly edited. Treat it as a first-class artefact from day one, because retrofitting logging after an incident is how organisations fail an audit.

• Evidence: a query-and-answer log capturing user, timestamp, request and response
• Evidence: a defined retention period aligned to your record-keeping obligations
• Evidence: log integrity controls so the trail cannot be silently altered

Question 4 — How are sensitive objects classified and protected?

Not every object in the repository carries the same risk. A capability map is one thing; an inventory of unpatched vulnerabilities or the data flows touching personal or supervisory data is another. An auditor will ask how you distinguish them and how the sensitive ones are protected from an agent that might surface them carelessly.

Good evidence starts with classification: a scheme that labels architecture objects by sensitivity, applied consistently. On top of that sits redaction or withholding — the ability to keep the most sensitive attributes (known weaknesses, security measures, regulated data flows) out of an agent's answers unless explicitly authorised. "The AI just summarised everything it found" is not an answer an auditor will accept for your crown-jewel objects.

• Evidence: a classification scheme applied to architecture objects and attributes
• Evidence: redaction or withholding rules for high-sensitivity objects
• Evidence: a defensible rationale for what an agent may and may not surface

Question 5 — Who is accountable for an AI-influenced decision?

This is usually the hardest question, and the one that exposes weak governance fastest. If an architecture decision was shaped by an agent's answer, an auditor will ask who owns that decision and whether the answer can be traced to a governed source — a real object in your repository — rather than to a model's plausible-sounding improvisation.

Good evidence is a human-in-the-loop accountability model: a named owner for decisions that AI informs, and traceability from the agent's answer back to the source objects it drew on. The point is not that humans approve everything; it is that accountability never evaporates into the model. If you cannot name an owner and cite a source, the rest of your controls read as decoration.

• Evidence: a human-in-the-loop model naming owners for AI-informed decisions
• Evidence: traceability from an agent's answer to citable source objects
• Evidence: a clear boundary between AI suggestion and human decision of record

Question 6 — How is third-party and ICT risk governed (DORA)?

An AI agent that reaches your architecture data is, almost always, a third-party ICT dependency. Under DORA, that pulls it into your ICT third-party risk management: it should appear in your register of information, with the concentration, sub-outsourcing and exit considerations that any critical provider attracts.

An auditor will ask whether the AI provider is governed like any other ICT supplier — assessed, contracted, monitored, and exitable. Good evidence is an entry in your ICT third-party register, contractual terms that meet DORA expectations, and a tested answer to "what happens if this provider fails or must be replaced?" The architecture repository itself helps here: it is where the dependency on the AI capability should be modelled, so the risk is visible rather than hidden in a procurement folder.

• Evidence: the AI capability listed in your ICT third-party register of information
• Evidence: contract terms and monitoring aligned to DORA expectations
• Evidence: a documented and tested exit / substitution plan

Prepare the evidence before you need it

These six questions are not a reason to keep AI away from your architecture — they are the agenda for doing it defensibly. Each one is answerable, and each is far cheaper to answer before an inspection than during one. We are building ArchiLU toward a sovereign, data-residency-aware context layer for exactly this conversation; that MCP layer is conviction and roadmap, not a shipped product, and we will not pretend otherwise. What exists today is a connected EA model, EU-region or on-premise hosting you control, native FR/EN, and a structure built around DORA/CSSF documentation needs.

Start from where your practice actually stands. ArchiLU's free EA Maturity Assessment scores ten dimensions and returns a prioritised action plan in about ten minutes — a concrete way to see how ready your architecture governance is for the questions an auditor will bring once AI agents start asking your repository for answers.

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