Ardoq MCP vs Bizzdesign MCP: what "talk to your architecture" leaves out

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

Two leaders shipped "talk to your architecture" — and they did it well

Ardoq and Bizzdesign are racing to let an AI assistant query your enterprise architecture through MCP, the Model Context Protocol. The pitch is seductive and, frankly, real: instead of clicking through views, you ask a question in natural language and the model answers from your architecture repository. Both companies have done credible engineering here, and this article will not pretend otherwise.

But MCP is a protocol — the USB port of AI, a commodity. Nobody should pick a platform because it "does MCP." The interesting questions are narrower: how does each leader expose the model, how good is the reasoning, and — the part neither centers — where does your architecture data go when the AI answers? That last question is the one that decides it for regulated finance.

Ardoq: first-to-market, read-only, permission-aware

Credit where it is due: Ardoq was first to market with a generally available MCP server for enterprise architecture. That is a real milestone, and it reflects the philosophy Ardoq has built for years — architecture as a continuously evolving, graph-based data model rather than a static set of diagrams.

Their MCP approach is deliberately conservative in the right ways, and that conservatism is a strength, not a limitation.

• Read-only by design: the AI queries the model, it does not silently mutate your repository.
• Metamodel-aware: it understands Ardoq's graph metamodel, so answers are grounded in real relationships, not guesses.
• Viewpoints and dashboards: the assistant can reason over curated views, not just raw nodes.
• Permission-aware: it respects who is allowed to see what, so AI access does not become a backdoor around access control.

Bizzdesign: thin versus native, and deep ArchiMate semantics

Bizzdesign frames its MCP direction differently, and that framing is genuinely useful. The thin-versus-native distinction — whether an MCP server merely passes raw data through or actually understands the modeling language underneath — is exactly the right question to ask, and Bizzdesign is well placed to ask it because of where it comes from.

Bizzdesign is one of the most established ArchiMate-first names in the field, with a long Gartner Leader history and a governed-model discipline. A native MCP over deep ArchiMate semantics can, in principle, give an AI far richer, more correct answers than a thin pass-through over a generic store — because the meaning of layers, relationships and viewpoints is preserved.

• Native over thin: an MCP that understands ArchiMate semantics, not just a generic data tunnel.
• Deep modeling discipline: governed, role-scoped models from a recognized ArchiMate authority.
• Richer reasoning surface: layers, relationships and viewpoints carry meaning the AI can use.

The question neither MCP centers: where does the data go?

Here is the unstated assumption underneath both pitches: that connecting Claude, ChatGPT, Gemini or Copilot to your EA repository is acceptable. For many organizations it is. For regulated finance, it often is not — and that gap is the entire subject of this article.

An enterprise architecture map is not a tidy diagram. It is a near-complete blueprint of the organization: the full system inventory, critical dependencies, obsolete components, known vulnerabilities, sensitive data flows, and sometimes the security measures themselves. Stream that to a US-cloud LLM and you have created a data-residency, third-party-dependency and transfer question under DORA, CSSF expectations, GDPR and the EU AI Act. Permission-aware and metamodel-aware are necessary — but they govern who queries and how well it reasons, not where the data physically lands.

The diagram above lays this out across four axes — modeling depth, freshness, governance and data residency. On the first three, Ardoq and Bizzdesign are strong. On the fourth, residency is simply not the framing either one leads with. That is not a knock on their engineering; it is a difference in who they are built for.

The missing third option: a sovereign context layer

We believe there is a third position that neither leader is centering, and it is the one regulated EU institutions actually need: a sovereign context layer. The idea is to make data residency and governance first principles, so an AI can reason on your architecture without that architecture leaving the EU or your control.

To be completely clear, and per our own honesty rule: Archilu's MCP server is not built. We are describing conviction and roadmap — the approach we are building toward — not a shipped feature. We will never write that "Archilu's MCP lets you" do anything today, because it does not yet exist.

What we can claim today is concrete and unglamorous on purpose: a connected EA model with capabilities, application portfolio and dependencies; EU-region or on-premise hosting you control; native French and English; published pricing with unlimited users; and a posture built around DORA and CSSF documentation needs. A sovereign, data-residency-aware MCP should sit on top of exactly that kind of governed, living context — which is why we build the context first and treat MCP as the last layer, not the headline.

• Sovereign Context Layer: governed enterprise context an AI can use without data leaving your control.
• Data-residency-aware MCP: governs where the data goes, not only who queries — the axis the giants under-serve.
• Living context: continuously refreshed, because an MCP over an 18-month-old snapshot is worthless.

A decision frame: when each one fits

None of this is a verdict that one approach wins. It is a fit question, and the honest answer depends on who you are and what an auditor will ask you.

Choose Ardoq's MCP if you already run Ardoq and want data-driven, permission-aware AI access to a living graph. Choose Bizzdesign's native framing if your practice is ArchiMate-deep and governed inside Bizzdesign and you want the semantics preserved. Weigh the sovereign approach when you are an EU-regulated institution — a bank, insurer, critical-infrastructure or public-sector body — where the EA map is sensitive, the buyers are CISO, DPO, Head of Architecture and CSSF-facing roles, and the first question in the room is "where does the data go?" rather than "how clever is the answer?"

One caveat we will repeat, because it matters: a tool helps you document and prove; it does not make you compliant. Residency and governance reduce exposure and give an auditor something to accept — they are not a substitute for your own legal assessment.

Start from your maturity, not the protocol

MCP is the last thing you should choose, not the first. Before connecting any AI to any repository, the useful question is whether your architecture context is fresh, governed and trustworthy enough to be worth querying at all — and whether your governance is ready for an auditor to ask where it travels.

Archilu's free EA Maturity Assessment scores ten dimensions and returns a prioritized action plan in about ten minutes. It is a fast, concrete way to see whether your context is agent-ready and your governance audit-ready — before you let any MCP, sovereign or otherwise, point an AI at the most sensitive map in your organization.

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