EU AI Act and Enterprise Architecture: Where to Start by Mapping Your AI Systems

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

Start with a question the AI Act keeps asking: which AI systems do you run?

The EU AI Act is recent, and many teams are still unsure where to begin. The honest answer is that you cannot govern what you cannot list. Almost every obligation in the regulation — from risk classification to documentation to human oversight — presupposes one thing: that you actually know which AI systems your organization deploys or uses, what they do, and what they touch.

For most organizations that inventory does not exist as a single, trustworthy view. AI has crept in through procured software, point solutions, embedded features and a handful of in-house models, owned by different teams. So the first practical step is not a legal one. It is an architectural one: build a current, traceable inventory of AI systems. This article is a preparation and documentation aid, not legal advice — but it shows where an architecture map gives you a head start.

Understand the shape of the obligations (neutrally)

Without quoting article numbers or dates we are not certain of, the AI Act's logic is risk-based. It distinguishes a small set of prohibited practices, a high-risk category that carries the heaviest obligations, uses subject to transparency duties (such as making clear that a person is interacting with AI or that content was AI-generated), and lower-risk uses with lighter requirements. Obligations fall on developers of AI systems and, importantly, on the organizations that deploy or use them.

Two practical consequences follow. First, classification is per use, not per vendor — the same model can sit in a high-risk process and a trivial one. Second, deployers carry real duties even when they did not build the model. That is why a passive 'we just buy software' posture is risky: you still need to know what that software does with AI, and to be able to show it. The exact classification of any system is a legal and technical assessment you should confirm with counsel; the architecture is where you record the result.

• Risk-based tiers: prohibited, high-risk, transparency-duty, lower-risk
• Duties on developers and on deployers / users, not only on builders
• Classification is per use case, not a fixed property of a tool
• We do not assign risk classes for you — that is a legal/technical call

Your application map is the natural home of the AI-system inventory

An enterprise architecture model already holds most of the scaffolding you need. It lists applications, the business capabilities and processes they support, and the data that flows between them. That is precisely the structure an AI-system inventory has to sit on: an AI system is not free-floating — it lives inside an application, serves a process, and reaches some data.

So instead of starting a blank register, you extend what you have. Tag each application that embeds or calls AI. Against each tagged entry, record the determined risk class, the accountable owner, the nature of the human oversight, and the categories of data it touches. Because the map already encodes dependencies, you can also see second-order reach: which downstream processes rely on an AI-driven component, and what breaks or needs review if that component changes.

• Reuse existing entities: applications, processes, data flows, owners
• Add AI attributes: embeds-AI flag, risk class, oversight, data touched
• Trace reach through dependencies, not just the single application
• One queryable view instead of a static spreadsheet that ages overnight

Trace where AI touches processes and data — the part spreadsheets miss

The questions an auditor or a risk committee will ask are relational: not 'do we have a chatbot' but 'which customer-facing processes use AI, what personal data does each reach, and who can override the outcome'. A flat list answers the first; only a connected model answers the rest.

Mapping AI onto the architecture lets you follow a thread from a business process down to the application that embeds the model and on to the data it consumes — and back up to the people accountable for oversight. That traceability is the raw material of the technical documentation and record-keeping the AI Act expects, and it is far easier to keep current as a living model than as a document re-typed each quarter. The same living-model discipline underpins your DORA and NIS2 evidence; rather than repeat it here, see our dedicated piece on architecture governance for DORA and NIS2.

The meta-angle: pointing AI at your architecture is itself an AI use

Here is the part teams overlook. The moment you use AI agents to query, summarize or reason over your architecture model, you have created another AI use — and an unusually sensitive one. The architecture is close to a complete blueprint of the organization: system inventory, critical dependencies, obsolete components, data flows, sometimes security measures. An AI use of that material deserves the same governance scrutiny you apply to any other.

So the same inventory entry applies to your own tooling: what is the system, what does it reach, who oversees it, and — critically — where does the context physically go. If answering a question about your architecture means shipping that blueprint to an external, non-EU model, you have turned an internal asset into an exposure. We believe the right answer is a sovereign context layer: a governed System of Context that lets agents reason on the architecture without the sensitive map leaving your control. To be clear about claim discipline: that sovereign, data-residency-aware approach is the direction we are building toward — a conviction and roadmap, not a shipped product we are asking you to take on faith.

• Treat 'AI on the architecture' as a governed AI use, not a free pass
• The architecture is near-blueprint-grade sensitive material
• Ask where the context goes, not only who is allowed to query
• A sovereign context layer is our conviction and roadmap, not a shipped MCP

A pragmatic place to begin — and an honest boundary

If you want a first move that creates real value regardless of how the legal interpretation settles, build the inventory: take your application portfolio, flag every entry that embeds or calls AI, and capture risk class, owner, oversight and data touched against each. Then pilot the traceability on a single high-stakes process before scaling. You will end up with documentation you would have needed anyway, and a clearer picture of your own exposure.

The honest boundary: this helps you document and prepare; it does not make you compliant. Compliance is a legal outcome that depends on your specific systems, processes and qualified counsel. Archilu's contribution is the connected, EU-hostable model that makes the inventory and traceability practical to build and keep current — with published pricing, native French and English, and hosting you control. A fast way to see where your practice stands today is the free EA Maturity Assessment: ten dimensions, a prioritized action plan, 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