Bring Your Own AI: Provider Choice as an Architecture Requirement

Ask an architecture team how they'd evaluate a new modelling tool and you'll get a familiar list within thirty seconds: where does the data live, who can see it, can it be exported without a fight, does it integrate with what we already run. Ask the same team whether the tool's AI features are built against one vendor's model, hardcoded into the product, and you'll usually get a shrug. AI is treated as a feature, evaluated on whether it's clever, not as an architectural dependency, evaluated on whether it's safe to depend on. That's the wrong category, and it's worth spending some time on why.

The lock-in nobody puts on the checklist

Vendor lock-in in architecture tooling is a well-worn topic. Everyone who has evaluated an EA repository knows to ask about the export format, whether the underlying data is stored in something open or something proprietary, whether switching tools later means a migration project or a file copy. That's file-format lock-in, and it's been on procurement checklists for years, for good reason: a tool that only speaks its own dialect holds your architecture hostage the moment you want to leave.

There's a second, quieter form of lock-in that most of that same due diligence skips entirely, and it has arrived through the AI features that architecture tools have started bolting on over the past couple of years. If a tool's "AI assistant" is wired directly to one provider's API — model names hardcoded, prompts tuned to that model's quirks, response parsing built around that provider's specific output format — then the organization using the tool has taken on a dependency it never evaluated as a dependency. Not on the tool vendor. On the tool vendor's relationship with a third company that neither the tool vendor nor the customer fully controls.

This matters for reasons that have nothing to do with which AI happens to be good this quarter. A provider can change its terms of service. It can change what it does with input data, or announce that a model version is being deprecated on a schedule that doesn't match the tool vendor's release cycle. It can become commercially unavailable in a jurisdiction, or fail a procurement review that an organization's own AI or data-governance policy now requires every vendor to pass. None of that is hypothetical risk-modelling — it's the ordinary lifecycle of commercial AI services, which move faster and change terms more often than architecture tools themselves do. A tool that hardcoded its AI layer to one provider inherits every one of those changes on someone else's timeline, and passes the disruption straight through to whoever is depending on the tool to keep working.

The file-format version of lock-in is visible because everyone has lived through a bad migration at some point and remembers the pain. The AI-vendor version of lock-in is invisible until the day the underlying provider relationship breaks, at which point it looks less like a technical problem and more like the tool itself stopped working — because, from the customer's side, it did.

What "works fully with AI disabled" actually buys you

The cleanest test for whether a tool has genuine architectural independence from its AI layer is a blunt one: turn the AI off. Not hide the button — actually disable it, at the account or organization level, and see what's left.

In a lot of tools, what's left is not much. The AI wasn't a feature added on top of a working product; it was quietly load-bearing, and turning it off exposes how much of the day-to-day workflow had been rebuilt around it. Search that used to be a filter is now a natural-language query with no fallback. A "generate diagram" button that used to be manual drag-and-drop was replaced rather than supplemented. The product, without its AI vendor, isn't a smaller version of itself — it's a different, worse product, or in the least charitable cases, barely a product at all.

Mooodels is built on the opposite assumption, and it's worth being specific about what that means rather than treating it as a slogan. Visual editing on the canvas, deterministic rules and linting, graph-based impact analysis, views resolved as queries over the canonical model, and import/export against formats like Archi and Sparx EA — every one of those works completely with AI switched off. Nothing routes through an AI call as a hidden dependency. The AI assistant sits alongside those capabilities as an additional way to work with the model, not as a layer the rest of the product secretly depends on to function.

What this buys an organization isn't abstract resilience for its own sake. It's a specific, concrete guarantee: the ability to keep doing architecture work — modelling, governance, impact analysis, documentation — without that ability depending on any AI vendor relationship staying intact. If a provider changes terms in a way that fails procurement, if a contract lapses, if an organization's own policy shifts to restrict which AI services staff may use, or if AI access simply isn't approved yet for a particular team or client engagement, the tool keeps working. Nobody has to explain to a client why the architecture repository is unavailable because a subscription to a language-model API expired. The fallback path isn't a degraded mode bolted on for compliance theater — it's the same product, running the same deterministic mechanics it always ran, with one optional layer switched off.

That distinction — optional layer versus load-bearing dependency — is the whole argument. A tool can advertise AI features honestly only if the rest of the product was designed to not need them.

BYOK: cost control and data-handling accountability in one decision

Bring-your-own-key sounds like a billing detail. It isn't. It's the mechanism that determines who is actually accountable for what happens to an organization's architecture data on its way to and from an AI model, and that accountability question is the real reason BYOK belongs in an architecture discussion rather than a procurement footnote.

When a tool vendor operates its own AI subscription and routes every customer's requests through it, the vendor sits in the middle of a data flow it doesn't fully own the terms of. The customer's contract is with the tool vendor. The tool vendor's contract is with the AI provider. Whatever the AI provider's data-handling terms actually say — retention windows, training-data policies, sub-processor lists, regional hosting — the customer is trusting the tool vendor to have read them correctly, negotiated them adequately, and passed the right guarantees through unchanged. That's an opaque pass-through, and opaque pass-throughs are exactly the kind of arrangement that data-protection officers and procurement teams are trained to be suspicious of, because when something goes wrong, responsibility gets argued over rather than assigned.

BYOK removes that middle layer. When an organization brings its own API key, its own contract with the AI provider governs what happens to the data — not a reseller relationship the tool vendor negotiated on the customer's behalf, and not fine print the customer never saw. If the organization has an enterprise agreement with a provider that guarantees no training on submitted data, that guarantee applies directly, because the request is going out under the organization's own credentials and the organization's own terms. If the organization is required to use a specific vetted or sovereign-hosted model — increasingly common for public-sector and financial-sector clients — BYOK is what makes that requirement satisfiable at all, because the tool has to be capable of pointing at whatever endpoint the organization is actually allowed to use, rather than the one the tool vendor happened to build a partnership with.

Cost control follows the same logic. A tool vendor that bundles AI usage into its own subscription is making a pricing bet on your behalf, and it prices in a margin on tokens it doesn't produce. An organization on BYOK pays its AI provider directly, at whatever rate and volume commitment it has already negotiated — often a materially better rate than a smaller reseller can offer, and one the organization can renegotiate on its own terms rather than waiting on a tool vendor's pricing tier changes. It also means AI usage inside the architecture tool shows up on the same bill and the same usage dashboard as every other AI usage in the organization, instead of being a separate, opaque line item buried inside a software subscription that nobody can break down by actual consumption.

There's a secrets-handling detail underneath this that's easy to overlook and worth stating plainly: an API key is a credential, and credentials don't belong inside architecture model files. In Mooodels, provider keys are never written into the canonical model — not embedded in a saved file, not carried along in an export, not sitting in a Git history the moment someone commits their architecture repository. A model file that gets shared with a client, checked into version control, or handed to an auditor should never be capable of leaking an API key as a side effect. Keeping AI credentials entirely separate from the data they operate on is a small architectural decision with an outsized payoff the first time a model file leaves the building.

What a provider abstraction looks like in practice

Provider neutrality is easy to claim in marketing copy and hard to actually build, because the natural way to add AI features to a product is to write code against one vendor's API and then, later, awkwardly retrofit a second one. The result is usually a codebase full of branches that ask the wrong question: if the provider is OpenAI, do this; else if it's Claude, do that. That pattern doesn't scale past two providers, it fossilizes the product around whatever quirks the first-integrated vendor happened to have, and it means every new provider is a bespoke integration project rather than a configuration change.

The alternative is to stop asking "which vendor is this" and start asking "what can this endpoint actually do." Concretely, that means defining an interface — an AIProvider abstraction — that any provider has to satisfy, and having the rest of the application program against that interface rather than against a specific vendor's SDK. A simplified sketch of the shape:

interface AIProvider {
  id: string
  displayName: string

  capabilities: {
    structuredOutput: boolean   // can it return schema-conformant JSON?
    toolCalling: boolean        // can it invoke defined functions/tools?
    streaming: boolean          // can it stream partial responses?
    longContext: boolean        // can it accept the full model + history?
    maxContextTokens: number
  }

  complete(request: CompletionRequest): Promise<CompletionResult>
  streamComplete?(request: CompletionRequest): AsyncIterable<Chunk>
}

// Elsewhere in the app, code asks the interface, not the vendor:
if (provider.capabilities.structuredOutput) {
  result = await provider.complete(patchRequestWithSchema)
} else {
  // fall back to prompted JSON + a parser and a repair pass
  result = await provider.complete(patchRequestWithInstructions)
  result = repairAndValidate(result)
}

The difference between the two patterns isn't cosmetic. "If OpenAI, else if Claude" hardcodes assumptions about what a specific vendor supports at the moment the code was written, and every one of those assumptions has to be manually revisited every time a vendor changes its API or a new provider is added. "If the provider supports structured output" asks a question about capability instead of identity, and the answer stays correct even when the underlying set of providers changes — a new OpenAI-compatible endpoint that happens to support structured output slots in without a single new branch, and a provider that drops a feature, or a smaller sovereign-hosted model that never had it, degrades gracefully into the fallback path instead of breaking outright.

This is also what makes an eventual pivot to "no AI" and "any AI" the same code path rather than two separately maintained ones. A provider that isn't configured simply reports no capabilities, and every capability check in the application already has a defined fallback — because the fallback was never a special case bolted on for compliance, it was the ordinary behavior for a provider that can't do a given thing. That's the same design principle discussed above about the product working with AI disabled, expressed at the code level instead of the feature level: nothing downstream of the AIProvider interface is allowed to assume any particular capability exists.

In Mooodels this abstraction is what sits behind the provider picker in settings: Claude, OpenAI, Mistral, an Azure-hosted deployment, a generic OpenAI-compatible endpoint for anything else that speaks that protocol, or a customer's own private or sovereign-hosted model reachable over an internal network. All of them are configured the same way — an endpoint and a key, held client-side, never written into a model file — and all of them are used the same way by the rest of the application, because the application only ever asks what the provider can do, never which one it happens to be.

Why this matters most for regulated and public-sector work

Every organization has some version of this concern, but it sharpens considerably for public-sector bodies, financial institutions, and other regulated customers, because for them AI vendor choice usually isn't a preference — it's a compliance requirement with a name and a policy document attached. A government agency may be restricted to a specific approved AI supplier list, or required to use a model hosted within national or EU infrastructure. A bank may need to demonstrate to a regulator that customer or portfolio data submitted to any AI service stays within a specific jurisdiction, under a specific data-processing agreement, with no retention beyond the request. A defence-adjacent client may be barred from sending anything to a foreign-hosted model at all, approved or not.

A tool hardcoded to one AI vendor simply fails these requirements the moment they exist, regardless of how good the tool is otherwise. It's not a matter of negotiating better terms with the vendor's AI partner — the architecture is wrong for the requirement, because the requirement is about which infrastructure the request touches, and a hardcoded integration only ever touches one. An organization in that position either can't use the tool's AI features at all, which is where "works fully with AI disabled" stops being a nice property and becomes the difference between a usable tool and an unusable one, or it has to lobby the vendor to build a second integration and wait, possibly indefinitely, for that to happen.

A provider-neutral, BYOK architecture sidesteps the problem entirely, because the requirement and the product's design point at the same thing: whatever AI infrastructure the organization is contractually and legally required to use, that's the endpoint the AIProvider abstraction gets configured to call. No feature gap, no waiting on a roadmap, no exception process. And because AI is genuinely optional rather than load-bearing, a team that's mid-approval on its AI vendor, or that will never get sign-off at all, isn't locked out of the rest of the product while everyone else waits.

This is also where data residency and AI provider choice stop being separate line items on an evaluation checklist and start being the same question asked twice. "Where does our architecture data live" and "where does our architecture data go when AI touches it" are both, fundamentally, questions about which infrastructure an organization's information crosses and under whose contractual terms. A tool that takes data residency seriously but hardcodes its AI layer to one foreign vendor has only answered half the question — and for a regulated customer, the unanswered half is often the one that blocks procurement.

Objections worth taking seriously

"Doesn't offering every provider mean supporting none of them well?"

This is the honest tradeoff, and the capability-based abstraction is the answer to it rather than a way of avoiding the question. Provider-specific optimization still happens — the application can and does take advantage of a specific provider's strengths when they're present, exactly because it asks about capabilities rather than ignoring them. What it doesn't do is make the presence of any single vendor's specific feature a requirement for the product to function, which is a different claim than "every provider gets identical treatment." A provider with stronger structured-output support gets used more efficiently for schema-bound tasks; one without it gets routed through a slightly heavier fallback. The product adapts to what's actually there instead of assuming a fixed vendor.

"Isn't managing your own API keys and billing more work than a bundled subscription?"

Marginally, yes, in the same way that managing your own cloud hosting account is marginally more work than a fully managed platform. For most organizations evaluating architecture tooling, that marginal setup cost is already something they've absorbed for other tools, because most of them already have an AI provider relationship somewhere in the organization — a subscription, an enterprise agreement, an approved internal deployment. BYOK means plugging the architecture tool into infrastructure that typically already exists, rather than adding a new vendor relationship on top of it. For the regulated customers this matters most for, that existing relationship is often the only one they're allowed to use anyway, which makes the "marginal work" argument moot — there was never a simpler bundled option available to them in the first place.

"Does 'works without AI' mean AI is an afterthought?"

The opposite, if anything. Building a product where every core capability — modelling, rules, graph analysis, interoperability — stands on its own, and then adding AI as a genuinely optional layer on top, is more work than wiring AI calls directly into core flows and calling it done. It requires the deterministic mechanics to actually be complete on their own terms, which is a real product commitment, not a lesser one. What it buys, alongside everything already discussed, is that the AI layer can be evaluated on its own merits — is it useful, is it accurate, does it save time — rather than being defended as load-bearing infrastructure that the rest of the product secretly can't do without.

A short checklist for the next evaluation

The next time AI comes up while evaluating architecture tooling, the same rigor applied to data residency and access control fits directly:

• Can the AI features be pointed at a provider of your choosing, including one you already have a contract with?
• Does the tool still function — modelling, rules, analysis, import/export — with AI switched off entirely, or does turning it off break core workflows?
• Whose contract governs what happens to data sent to the AI model — yours with the provider, or an opaque pass-through through the tool vendor?
• Are API keys and credentials kept separate from the architecture data itself, including in exported files?
• If your organization is required to use an approved, sovereign, or self-hosted model, can the tool actually point at it — today, not on a future roadmap?

A tool that answers all five comfortably has treated AI provider choice as an architectural property of the product, not a settings-page convenience. A tool that stumbles on more than one has quietly made a vendor decision on your organization's behalf — one that, unlike file format, rarely gets written down anywhere for procurement to catch.

Mooodels was built the first way on purpose. AI providers are a configuration choice, not a foundation the rest of the product is poured onto, and the fallback path — the product with AI turned off — is not a degraded mode kept around for compliance optics. It's the same modelling engine, the same rules, the same graph, running exactly as designed, whether or not any AI vendor relationship happens to still be standing. That's what "bring your own AI" is actually for: not a feature checkbox, but the guarantee that an organization's architecture practice doesn't quietly depend on a company it never signed a contract with.