CelinQ Insights · No. 78

Enterprise Architect AI Without Data Leakage: Sovereign and Customer-Hosted Deployment Patterns

Sovereign mode is a real, deploy-time hard stop for organisations that cannot accept any external AI exposure; customer-hosted inference is the pattern that sits beyond it.

Somewhere in most government, defence, banking, and healthcare architecture practices, there is a question that ends the conversation about a new tool before the tool's actual capabilities are even discussed: does anything about this product require sending our architecture to a third party over the public internet. It is not an unreasonable question, and it deserves a precise answer rather than a reassuring one. A precise answer distinguishes between what the product does by default, what it can be configured to do, what it can be configured to never do under any circumstance, and what remains, honestly, a direction rather than a delivered capability. This article is that precise answer for CelinQ.

The short version is that CelinQ's core — synchronisation, Fusion, presence, monitoring, revisions, audit, backup, the entire Control Plane and API — has no dependency on external AI at all, and never has. The optional AI layer that generates recommendations, explanations, and summaries is a genuinely separate concern, wired in behind an interface the deterministic engine knows nothing about. For an organisation that cannot accept any AI exposure whatsoever, CelinQ supports a sovereign deployment mode that removes external AI as a possibility entirely, set once at deployment and not reversible from any administrative console. For organisations somewhere between "AI is fine, with governance" and "AI can never touch this," the same architecture that makes sovereign mode possible is what makes a customer-hosted or private-endpoint AI provider a coherent future direction — a pattern the system is built to support, not a box you can tick today.

Sovereign mode: what it actually disables, and what it deliberately does not

Sovereign mode is not a checkbox in the administrative interface. It is a deployment-time configuration flag, set by whoever stands up the CelinQ Server, and once it is active it cannot be re-enabled — or disabled — by anyone using the console afterwards, including an instance administrator with full privileges otherwise. That distinction is deliberate. A setting an administrator could flip from a web page is a setting that could be flipped by mistake, under pressure, or by someone who should not have had the authority to do it. A setting fixed at deployment and asserted by the underlying configuration store is a structural guarantee rather than a policy preference, and it is the only kind of guarantee that satisfies a security team asking "can this ever be turned on by accident."

With sovereign mode active, the AI policy gateway that every potential external call must pass through fails the check at its very first gate, before any question about workspace policy or capability opt-in is even evaluated. No request is ever built, which means no field-level data policy question ever becomes relevant, because there is no scenario in which a request reaches the point of being assembled. This is a stronger guarantee than "AI is disabled by default and nobody has enabled it," because that weaker version depends on nobody making a configuration mistake in the future. Sovereign mode does not depend on anyone continuing to make the right choice. It removes the choice.

Everything else is left untouched. Synchronisation continues to run at its normal cadence. Fusion continues to merge automatically wherever a merge is provably safe and to raise a capsule for a human wherever it is not — the entire deterministic proof-carrying merge pipeline operates identically with sovereign mode on or off, because it was never built to depend on AI being available. Users, roles, and access control work the same. Audit logging, monitoring, revision history, and backup and restore work the same. The entire REST and gRPC API surface remains available. An organisation running in sovereign mode is not running a stripped-down edition of CelinQ; it is running the same product with one category of optional functionality structurally absent, and every other category present at full strength.

Why "AI-disabled" and "sovereign" are not quite the same claim

It is worth separating two statements that sound similar but carry different weight. "AI is disabled" describes the current state of a configuration that could, in principle, change: an administrator with the right privileges could enable it tomorrow. "Sovereign mode is active" describes a structural property of the deployment that no console interaction can alter. For most organisations, disabled-by-default with strong governance around who can change it is entirely sufficient, and the granular, audited, field-level controls described in the companion article on secure AI are built for exactly that majority case, where the goal is deliberate, narrow, reviewable use of AI rather than its total absence. Sovereign mode exists for the minority of deployments — a defence programme, a classified environment, a regulator that has specifically prohibited any external data flow tied to a system of record — where the acceptable answer to "could this ever send data externally" has to be no, not "no, and here is the policy that currently prevents it."

Choosing between the two is a genuine decision an organisation has to make deliberately, not a default to accept passively. Sovereign mode forecloses AI-assisted recommendations, summaries, and natural-language conveniences permanently for that deployment, and reversing the decision later means a new deployment, not a settings change. That is by design, and it is worth naming as a real cost rather than glossing over it: an organisation that later decides AI-assisted conflict recommendations would in fact be valuable, having deployed sovereign, faces a harder path back than an organisation that started with AI disabled by policy and simply flips a switch. The choice deserves the same deliberation any irreversible architectural decision does.

Sovereign mode is not "AI, but careful." It is the absence of a category, chosen deliberately and fixed at deployment, for the organisations that need an answer stronger than a policy promise.

What "customer-hosted" and "air-gapped" mean as a pattern, honestly stated

Between "external AI, governed" and "no AI at all" sits a third possibility that many regulated organisations ask about specifically: what if the model an architect's questions go to is one the organisation runs itself, inside its own network, so the benefit of AI-assisted analysis exists without any data ever crossing the organisation's boundary. This is a real and reasonable thing to want, and it deserves an honest answer rather than an evasive one. CelinQ's AI advisor sits behind a provider-abstracted interface specifically so that a different provider — including a model hosted inside the customer's own infrastructure, or reached through a private endpoint rather than the public internet — can be integrated without touching the Fusion engine, the sync protocol, or any of the deterministic logic that does not know or care which provider, if any, sits behind the advisory interface. That abstraction is genuine engineering, already in place, and it is exactly what makes a customer-hosted provider a credible direction rather than wishful thinking.

What is equally true, and what this series is committed to stating plainly rather than letting a hopeful reader assume otherwise, is that a customer-hosted or private-endpoint provider is not something you can select from a dropdown in CelinQ today. The provider actually available now is OpenAI's Responses API. A customer-hosted model, an Azure OpenAI private endpoint kept entirely within a customer's own tenant boundary, or fully air-gapped inference running with no network path outward at all are deployment patterns the architecture is built to accommodate — the interface exists, the boundary discipline around what data reaches an advisor exists, the audit and policy gateway exist — but they are not shipped, off-the-shelf configurations an organisation can point at and deploy this quarter. An organisation with a hard requirement for customer-hosted inference should treat that as a scoped integration conversation grounded in this existing abstraction, not as a feature they are choosing between in a settings screen next to "OpenAI."

The same honesty applies to a second pattern that comes up in the same conversations: single sign-on through an organisation's own identity provider. CelinQ's authentication today is a personal-access-token model, with roles enforced consistently across every workspace operation and tokens stored only as salted hashes, never in recoverable form. Integration with an external identity provider — Entra ID, Keycloak, or a comparable OIDC provider — is a planned direction that the existing principal and role abstraction is already shaped to support, not a currently available login option. An organisation planning a deployment timeline around either customer-hosted AI or OIDC single sign-on should plan around them as roadmap items to confirm directly, not as capabilities to assume are already sitting in a configuration menu.

What a sovereign team still has, and it is more than it sounds

It is easy to describe sovereign mode by what it removes and leave the impression that a sovereign deployment is a lesser one, and that impression deserves to be corrected directly, because it is not accurate. A sovereign workspace still has the deterministic model-quality checks that catch orphan elements, missing ownership, and circular dependencies without any AI interpretation at all, the same rule engine and graph analysis described in the article on analysing a repository without sending it to an external AI. It still has the full Fusion pipeline, with F0 proven merges and F1 policy merges resolving the overwhelming majority of concurrent edits automatically and every automatic decision recorded with the specific rule that proved it safe. It still has presence, Smart Sync, complete revision history, workspace-scoped role-based access, TLS-pinned transport, and backup and restore with workspace-epoch recovery for handling a server restored from an older snapshot. None of that is a consolation prize sitting beside the "real" AI-enabled product. It is the same product, built the same way, tested the same way, and the only thing genuinely absent is a narrow, clearly-scoped advisory layer that was always designed to be optional in the first place.

This is worth dwelling on because the framing matters in a procurement conversation. An organisation choosing sovereign mode is not accepting a downgrade in exchange for compliance. It is choosing the deployment configuration of a product whose foundational engineering — the merge engine, the sync protocol, the audit trail — was never built to depend on AI, and therefore loses nothing structural by having AI removed. A product where AI had been woven into the core would look very different in sovereign mode: entire features missing, workflows redesigned around a gap, degraded behaviour presented as an unfortunate but necessary trade-off. CelinQ's sovereign mode looks, from the inside, almost exactly like a normal deployment with one card missing from the Control Plane's admin menu, and that similarity is a direct consequence of AI having been added as a layer on top of a complete system rather than as a dependency threaded through it.

A worked scenario: a defence-sector architecture practice

Consider, concretely, an architecture team inside a defence programme evaluating CelinQ for a shared repository spanning several suppliers and an internal review authority. The security accreditation process for the environment prohibits any system component from having a network path to a commercial cloud AI provider, full stop, and the accreditation is not something a policy toggle can satisfy — it requires a structural argument that the assessor can independently verify. Deployed in sovereign mode, the CelinQ Server the programme stands up on its own infrastructure has the AI policy gateway permanently short-circuited at deployment, and an assessor reviewing the configuration can confirm this by inspecting the deployment configuration itself rather than trusting a runtime setting that a future administrator could change. The programme gets full synchronisation across supplier laptops working from disconnected or intermittently connected networks, full Fusion conflict handling for the inevitable cases where two suppliers touch the same interface definition, and a complete audit trail satisfying the review authority's own record-keeping requirements — all without a single byte of architecture data ever having a theoretical path to an external endpoint, because that path does not exist in the deployed system, not because it has been turned off.

Six months later, suppose the same programme's non-classified internal tooling team, working in a separate, less sensitive environment on a different CelinQ deployment, wants AI-assisted summaries for onboarding documentation. Nothing about the sovereign deployment prevents that second, entirely independent deployment from running with AI enabled and governed under the field-level policy described in the companion article. Sovereign mode is a property of a specific deployment, not a property of the product as a whole, which means an organisation with genuinely different sensitivity tiers across its estate is not forced into a single, organisation-wide answer to the AI question. Each deployment answers it according to what that deployment actually needs to satisfy.

Redaction and data classification as a discipline, not a single control

Even inside a fully governed, non-sovereign deployment, the field-level policy described in the secure AI article is the practical mechanism for data classification in practice: an administrator decides, per workspace, which categories of information — entity names, conflicting field values, notes, the broader tagged-value map, user identities — are permitted to reach an advisor at all, and redaction of user names happens automatically rather than as an opt-in. For organisations doing their own classification exercise, this maps naturally onto standard data-sensitivity tiers: a workspace holding genuinely sensitive architecture can have its AI capabilities disabled entirely at the workspace level regardless of the global setting, while a workspace holding lower-sensitivity, internal tooling architecture can have the full set of capabilities enabled. The mechanism is the same one described previously; what changes here is framing it explicitly as a data-classification control, because that is the language a security review will use to evaluate it, and CelinQ's workspace-level policy maps onto that language directly rather than requiring translation.

The security review questions this is built to answer

A security team evaluating any modelling tool with an AI feature tends to converge on a similar list of questions, and it is worth restating CelinQ's answers to them plainly, in one place, rather than scattered across marketing language. Does the core product function without AI: yes, entirely, and this is provable by disabling AI and observing that sync, Fusion, and every governance feature continue unaffected. Can AI be disabled permanently and irreversibly at deployment: yes, via sovereign mode. Does disabling AI degrade any security, audit, or compliance feature: no, audit logging and access control are unrelated subsystems that do not reference AI. Where does the API key live and who can read it: server-side only, write-only, encrypted at rest, never returned to any caller. What data reaches an external provider when AI is enabled: exactly what a per-workspace policy permits, previewable before enabling, minimum-necessary by default. What happens if the provider fails or misbehaves: the advisory feature reports unavailable and nothing else in the system is affected. Is there a fully private or air-gapped inference option available today: not as a shipped, selectable configuration — it is an architectural direction supported by the current provider abstraction, and any organisation that needs it as a hard requirement should raise it as a specific deployment conversation rather than assume it from the product's general design.

Sovereign is not the same word as air-gapped

One confusion worth heading off directly, because it surfaces in almost every conversation about this topic: sovereign mode and a fully air-gapped network are related but distinct concepts, and treating them as synonyms leads to the wrong deployment decision. Sovereign mode is specifically about removing the possibility of external AI calls; it says nothing about whether the CelinQ Server itself has any network connectivity at all. A programme can run sovereign mode on a server that is otherwise perfectly reachable over the internet for ordinary administrative purposes, TLS certificate renewal, or operating-system patching — sovereign mode simply guarantees that none of that connectivity is ever used to reach an AI provider. A genuinely air-gapped environment, by contrast, has no external network path for anything, which is a stricter and separate infrastructure decision an organisation makes independently of CelinQ, using the on-prem deployment pattern described in the wider discussion of Azure, on-premises, and air-gapped deployment. In practice, the two decisions are usually made together by organisations with the strictest requirements — a fully air-gapped network running CelinQ in sovereign mode — but they are answering different questions, and a security questionnaire that conflates them will produce a confused answer. CelinQ's sovereign mode is a precise, verifiable answer to the AI question specifically; the surrounding network topology is a separate architectural decision the organisation makes about its infrastructure as a whole.

Honest limits

Sovereign mode answers the question of external exposure completely, but it does not answer every question an organisation with strict deployment requirements will have. It says nothing, on its own, about where the CelinQ Server itself is hosted, which is a separate decision an organisation makes when it chooses Azure, on-premises infrastructure, or a private cloud for that server — sovereign mode governs AI specifically, not general infrastructure sovereignty, and the two should not be conflated in a procurement conversation. It also means permanently forgoing a set of genuinely useful conveniences: an architect in a sovereign deployment resolving a Fusion conflict sees exactly the same information a colleague in a fully AI-enabled deployment would see, minus the advisory suggestion that might have pointed them toward the more likely correct resolution slightly faster. That is a real cost, not a hidden one, and organisations that choose sovereign mode are trading a specific convenience for a specific, structural guarantee — a trade that is entirely reasonable for the environments this mode exists for, and one that should be made with eyes open rather than assumed to be free.