CelinQ Insights · No. 77

Secure AI for Enterprise Architecture: Using OpenAI Without Making AI Mandatory

How CelinQ lets an administrator switch on external AI deliberately, narrowly and auditably, while every core capability keeps working with it switched off.

There is a conversation that happens in almost every security review of a modelling tool that offers AI features, and it tends to follow the same shape. Someone from the security team asks what happens to the model when the AI is used. Someone from the vendor answers with an enthusiastic description of what the AI can do. The two statements talk past each other, because the question was about exposure and the answer was about capability, and by the time anyone notices the mismatch the meeting has moved on. The result, too often, is a tool that gets deployed with AI features either switched off entirely out of caution, starving the organisation of anything useful, or switched on without anyone being entirely sure what data left the building to make it work.

CelinQ's approach to this problem starts from a decision that shapes everything downstream: external AI is not something the product assumes you want. It is off by default, it stays off until an administrator deliberately turns it on, and turning it on does not touch anything that made the product work before that point. Synchronisation, Fusion, presence, monitoring, revisions, backups, and the entire Control Plane operate identically whether AI has been enabled or not, because the Fusion core that resolves conflicts and the sync engine that keeps repositories converged have no reference to any AI type anywhere in their implementation. This is not a configuration flag bolted on as an afterthought. It reflects the fact that the deterministic engine was built first, proven on its own, and AI was added later as an optional layer on top of infrastructure that never needed it.

What "off by default" actually means in the architecture

It is worth being specific about what "off by default" guarantees, because the phrase is used loosely enough in the industry that it deserves scrutiny rather than trust. In CelinQ, every potential call to an external AI provider passes through a policy gateway before it can happen, and that gateway fails closed at each of several independent checks: is sovereign mode active, is the global AI switch on, is the specific capability enabled, and does the workspace's own policy — inherit, disabled, or enabled — permit this particular request. Any one of those checks failing is enough to stop the call before it is built. This is the opposite of a system where AI is reachable by default and an administrator has to remember to lock it down; here, nothing reaches an external provider until several independent affirmative decisions have all been made, and the absence of any one of them is sufficient to keep the door closed.

That layered structure matters because organisations do not make AI decisions once. A workspace holding a client's confidential architecture might need AI disabled permanently regardless of what the rest of the organisation decides, while a workspace used for internal tooling might reasonably want every available capability switched on. The policy gateway makes both true at once inside a single deployment: the global switch controls whether AI exists as a possibility for the organisation at all, and the workspace-level setting controls whether that possibility is realised for a specific body of work. An architect moving between the two workspaces experiences the difference directly — the AI-assisted suggestions are simply absent in the restricted workspace, not present-but-disclaimed, because the gateway never allowed the request to form.

Choosing capabilities individually, not accepting a bundle

A second design choice worth naming is that enabling AI does not enable everything AI could plausibly do. An administrator opts into specific capabilities one at a time — recommendations for ambiguous Fusion conflicts, explanations of why a conflict needs a human decision, summaries of a model or a package, summaries of a revision — and none of them is switched on implicitly by switching on the others. This granularity exists because the risk profile of these capabilities is not uniform. A summary of a public-facing system diagram is a low-stakes convenience. A recommendation touching a conflict inside a workspace that holds sensitive integration details is a different proposition, and an organisation should be able to say yes to the first and no to the second without an all-or-nothing switch forcing a compromise on either.

This matters as much for adoption as it does for governance. A security team asked to approve "AI" as an undifferentiated bundle has every incentive to say no, because the request is unbounded and therefore unassessable. A security team asked to approve conflict-explanation summaries, specifically, with a defined data policy attached, is being asked a question it can actually answer. Narrow, individually enabled capabilities are what make the conversation with a security reviewer productive instead of adversarial, and that productivity is not a side benefit — it is usually the difference between a pilot that gets approved this quarter and one that stalls indefinitely.

The provider, the key, and where the boundary actually sits

Every call to an external AI provider originates from the CelinQ Server, never from a browser and never from the EA add-in running on an architect's laptop. This is a deliberate architectural boundary, not an implementation detail: it means the API key that authorises calls to the provider never has to exist on a client machine or travel across the network to a browser session — an individual architect's laptop simply has nothing to leak, even if it were compromised. The key is stored write-only — it can be set, tested, and deleted, but it is never returned to any caller, never logged in full, never included in diagnostics or in the application payload of a backup. After it is saved, the interface shows only a masked confirmation with the last four characters, enough for an administrator to recognise which key is configured without ever displaying the whole thing again. At rest, the key is encrypted using platform-appropriate protection — Windows DPAPI at the machine scope, or AES-GCM under an operator-supplied master key elsewhere — and if neither protection mechanism is available, the store refuses to persist the key in plaintext rather than silently degrading to an insecure fallback.

Today, that provider is OpenAI, reached through its Responses API, and the model used is configurable by the administrator rather than fixed in code. The important structural point, for organisations evaluating this now and planning for later, is that the provider sits behind an abstraction — CelinQ's internal advisor interface does not know or care that it happens to be talking to OpenAI specifically. That abstraction is what makes an eventual alternative provider, including an Azure-hosted endpoint or a model an organisation runs on its own infrastructure, a plausible future integration rather than a rewrite. It is important to be precise about what that means today: it is an architectural direction the product is built to support, not a shipped alternative you can select from a list right now. An organisation that needs a customer-hosted model as a condition of adoption should treat it as a conversation about roadmap and deployment pattern, discussed further in the companion article on sovereign and customer-hosted deployment patterns, not as a box to tick in today's configuration screen.

What actually leaves the building, field by field

The question that matters most in a security review is not whether AI is used but what data reaches the provider when it is, and this is where a conservative default policy earns its keep. When a capability like conflict recommendation is enabled, the request built for the provider includes the entity name and the specific conflicting field and its competing values — the minimum information an advisor needs to say anything useful about a scalar or tagged-value disagreement. It excludes, by default, the free-text notes attached to elements, the broader map of tagged values beyond the one in conflict, and the wider neighbourhood of the model around the conflicting entity. User names attached to the conflicting changes are redacted rather than passed through. None of this is a promise taken on faith: an administrator can call the policy preview endpoint before enabling anything and see exactly the shape of what would be sent, field by field, and adjust the policy before the first real call is ever made.

This field-level discipline is what separates "we send the model to the AI" from what CelinQ actually does, which is closer to "we send the smallest fact pattern that lets the AI say something useful, and nothing else." A recommendation about why two people both changed a status field to different values needs the field name and the two competing values; it does not need the note explaining the internal politics behind the change, and CelinQ's default policy reflects that judgement rather than leaving it to be worked out later under time pressure.

The right question is never "is AI secure." It is "what specifically reaches the provider, who decided that was acceptable, and can I see the decision." A policy an administrator can preview before enabling it is a very different thing from a promise a vendor makes in a sales conversation.

Working through a concrete example

Abstractions like "field-level policy" are easy to nod along to and hard to actually picture, so it helps to walk one real case through end to end. Two architects, working offline from each other for part of a day, both change the lifecycle status of the same application component — one sets it to "Retiring," the other sets it to "Active," because one of them was reflecting a decommissioning decision made in a meeting the other had not yet heard about. Fusion detects this as a scalar conflict: same entity, same field, two different values, no automatic resolution available, because guessing which status is correct would be exactly the kind of silent, unreviewable choice the whole merge engine is built to avoid. This is classified as a case requiring a human decision before an AI advisor is ever consulted.

If conflict recommendations have been enabled for that workspace, the request built for the provider contains the element's name, the field in conflict, and the two competing values — "Retiring" and "Active" — plus enough structural context to describe what kind of field a lifecycle status is. It does not contain the note either architect may have attached explaining the decommissioning meeting, it does not contain the dozen unrelated tagged values also present on that element, and it does not contain the names of the two architects, which are redacted before the request is built. What comes back is a short, clearly labelled suggestion — perhaps that the more recent change is more likely to reflect current intent, with a stated confidence — that appears next to the conflict, not in place of it. The architect resolving the conflict sees the same resolution choices they would see with AI switched off, reads the advisory note if they find it useful, and makes the call themselves. The audit trail records that a recommendation was requested and returned successfully, at what time, by which workspace; it does not retain a permanent copy of "Retiring" and "Active" as a standalone artefact outside the conflict record where that information already belonged anyway as part of the model's own history.

Walking through one example this way makes the earlier abstractions concrete: the minimum-necessary field selection, the redaction, the advisory-only status, and the conservative audit trail are not four separate promises to keep track of. They are one coherent policy applied consistently, and the reason it is worth spelling out in this much detail is that a security reviewer evaluating the product should be able to ask for exactly this walk-through and receive the same answer, not a more reassuring-sounding summary of it.

What a less careful integration would have done differently

It is instructive, if slightly uncomfortable, to imagine the same feature built without these boundaries, because a version of it built quickly and without this discipline is not a hypothetical risk — it is roughly what a first draft of "AI conflict help" tends to look like in practice. The easy implementation sends the whole conflicting element, notes and all, because that gives the advisor more context and a developer under deadline pressure will reach for more context every time. The easy implementation calls the provider directly from wherever the conflict is being viewed, because routing everything through a server-side gateway is more work to build. The easy implementation logs the full prompt for debugging and forgets to strip it out before shipping, because debugging output rarely gets the same scrutiny as the feature it supports. Each of these shortcuts is individually explicable and none of them is malicious, and that is precisely why they are dangerous: they accumulate quietly, they pass a demo, and they only become visible during an incident or a security review, at which point the cost of unwinding them is much higher than the cost of not taking them in the first place. Naming the shortcuts not taken is not a rhetorical device. It is the clearest way to show what "secure by construction" actually bought, because the alternative was never a strawman — it was the default path, and avoiding it was a series of specific, deliberate decisions.

Advisory, and never a shortcut to a write

Everything above governs what data can leave the organisation's boundary. A separate, equally important boundary governs what an AI response is allowed to do once it comes back. The deterministic Fusion engine always decides first whether a conflict needs a human at all — it identifies the cases with no safe automatic resolution before an advisor is ever consulted, so AI is never asked to adjudicate something the deterministic rules could already resolve safely on their own. When a human decision genuinely is required, an AI recommendation may be shown alongside it, clearly labelled as AI-generated and advisory only, and the human still picks the action from the same set of resolutions — keep mine, keep server, restore original, restore as new, or restore parent — that they would choose from with AI switched off entirely. The recommendation informs; it does not decide, and it cannot commit a change on its own. The full mechanics of that boundary, including why it holds even in cascading multi-conflict scenarios, are covered in the article on AI-assisted conflict resolution without giving AI control of the model.

The same discipline extends to every other AI-assisted feature across the product, from generating a semantic change set out of a natural-language request to summarising a package for a non-technical stakeholder. AI proposes; it never writes raw repository rows, and it never bypasses the validation and human-approval steps that every other change, AI-originated or not, has to pass through before it becomes part of the canonical model. The pipeline is the same regardless of where a proposal originated: a person asks, CelinQ retrieves the relevant model context, a semantic change set or recommendation is proposed, CelinQ validates it deterministically, a human approves anywhere the change is ambiguous, and only then does a revision exist. That pipeline is described in full in the article on AI for Sparx Enterprise Architect, and it is the same pipeline underneath every feature this article describes, not a special case invented for security messaging.

Failure that fails safely

A secure design also has to specify what happens when the AI component itself misbehaves, and this is a place where a badly built integration can cause damage even with the best intentions around data handling. An invalid or revoked key, a rate limit, a timeout, a provider outage, or output that does not parse as expected all resolve to the same outcome: an explicit unavailable response with a message safe to show a user, never an exception that propagates into Fusion or the sync engine. The distinction communicated in the Control Plane is deliberately specific — "AI advisor unavailable," never "synchronisation failed" — because those are genuinely different situations and conflating them would train administrators to distrust the sync engine for a fault that has nothing to do with it. An organisation that later decides to stop paying for AI, or whose key expires over a holiday period with nobody noticing immediately, does not lose sync, Fusion, or any core capability while that gap exists. The core keeps running exactly as it did before AI was ever switched on, because it was never depending on AI to begin with.

What gets audited, and why the audit itself is conservative

Every external AI call writes an audit event: timestamp, the acting user, the workspace, which feature was invoked, the provider, whether the call succeeded, and its latency. What the audit event deliberately does not contain is the key itself or the raw prompt and model content sent to or received from the provider. This is a considered trade-off rather than an oversight. An audit trail that captured full prompt content would, in the act of protecting the organisation from one risk — not knowing that AI was used — create a second one, by building a growing store of potentially sensitive model fragments outside the access controls that govern the model itself. The chosen middle ground gives a security reviewer everything needed to answer "was AI used, by whom, on what, and did it succeed" without creating a shadow copy of exactly the content the field-level data policy was designed to keep contained.

Sovereign mode as the hard stop

For organisations where the honest answer to "should AI ever be able to leave this environment" is no, regardless of policy configuration, CelinQ supports a sovereign deployment mode set at deploy time rather than toggled from a console. With it active, external AI is disabled entirely and cannot be re-enabled from the administrative interface — there is no setting an administrator with console access could accidentally flip that would send a single byte to an external provider. Every core capability continues to operate at full strength: synchronisation, Fusion, users and access control, audit, monitoring, revisions, backup, and the full API surface remain exactly as capable as they are in any other deployment. Sovereign mode removes a category of risk, not a category of functionality, and the distinction between those two things is the whole argument of this article compressed into one setting. The deployment patterns that sit around sovereign mode — customer-hosted models, air-gapped environments, private endpoint arrangements — are their own subject, covered fully in the next article in this pair.

Honest limits

None of this makes external AI risk-free, and it would be dishonest to present it that way. The moment a workspace policy permits a field to be sent to a provider, that field leaves the organisation's infrastructure, and no amount of careful engineering on CelinQ's side changes what the receiving provider's own data-handling terms say about retention, training use, or downstream processing — an administrator enabling AI is also implicitly trusting the provider's stated practices, and that trust deserves its own separate scrutiny, not one borrowed from this article. The field-level policy reduces what can leave; it does not reduce it to nothing, because a genuinely useful recommendation needs some real information about the conflict to be worth having at all. And granular control is only as good as the administrator exercising it: a workspace policy set carelessly wide open defeats the purpose of having granularity in the first place, the same way a well-designed lock does nothing for a door that was left open. What CelinQ provides is the mechanism to be precise, auditable, and reversible about AI's reach — the responsibility for using that mechanism well still sits with the organisation that configures it, which is exactly where that responsibility belongs.