Posted by Mahdi
Posted by Mahdi
Choosing an AI Provider for Umbraco Without Lock-In
Learn how to choose an AI provider for Umbraco without hard-wiring your CMS to one vendor's models, APIs, data controls, or operations.
Choosing an AI provider for Umbraco is not only a model-quality decision. It is also a decision about where your prompts go, how your credentials are managed, which capabilities are available in the CMS, how logging and review work, and how painful it will be to switch providers later.
As of June 20, 2026, Umbraco's official documentation describes Umbraco.AI as a provider-agnostic AI layer built on Microsoft.Extensions.AI. That is a strong foundation, because it separates providers, connections, profiles, and requests. But provider-agnostic tooling does not eliminate lock-in by itself. Teams still create lock-in when they tie one use case to one provider's data policy, one provider's stateful features, or one provider's model-specific prompts without an exit plan.
This guide explains how to choose an AI provider for Umbraco more carefully, what to compare before rollout, and how to use Umbraco's architecture to keep your options open.
What To Score Before You Pick a Provider
The cheapest short-term decision often becomes the most expensive switch later. Score the things that are hard to unwind, not only the first demo.
Data Boundary
Check training policy, logging, retention, regional storage, regional processing, and whether stateful features store content.
Capability Fit
Confirm the provider supports the Umbraco capabilities you actually need, such as chat, embeddings, or speech-to-text.
Operational Controls
Compare logging, telemetry, abuse monitoring, key management, and environment-specific secret handling.
Prompt Portability
Ask how much of your prompt design, tools, and output formatting depend on one provider''s behavior.
Integration Surface
Keep application code on standard abstractions and move provider-specific settings into Umbraco connections and profiles.
Exit Cost
Estimate what a provider swap would force you to rebuild: prompts, embeddings, evaluations, governance, and user workflows.
Where AI Lock-In Usually Happens in Umbraco Projects
Lock-in rarely starts with the CMS itself. It usually starts in surrounding decisions.
| Decision area | How lock-in appears | Safer pattern |
|---|---|---|
| Application code | Controllers and services call one vendor SDK directly. | Keep application code on Umbraco.AI and Microsoft.Extensions.AI types. |
| Credentials and endpoints | API keys and URLs are hard-coded into the app or database. | Use Umbraco connections with configuration references and environment-specific secrets. |
| Use-case setup | One giant default configuration serves every task. | Create separate profiles for writing, support, embeddings, search, and internal workflows. |
| Prompts and tools | Prompts depend on one provider's quirks, tool schema, or output style. | Keep prompts task-focused and test them across candidate providers before rollout. |
| Data policy | The team chooses a provider before checking retention, logging, or region requirements. | Score governance and data handling alongside quality and price. |
| Stateful features | Stored conversations, files, or evaluations become tied to one platform. | Use stateful features deliberately and document how data would be exported, rebuilt, or retired. |
The practical question is simple: what will break, need rework, or trigger re-approval if we swap providers in 6 or 12 months?
Use Umbraco's Architecture as Your Anti-Lock-In Layer
Umbraco.AI gives teams a useful structure for avoiding unnecessary coupling. Its core concepts documentation defines a hierarchy of provider, connection, profile, and AI request. That separation matters because each layer should carry a different responsibility.
Provider: capability and protocol
Umbraco's provider documentation says a provider is a NuGet package that handles authentication, request formatting, and response parsing for a specific AI service. The same documentation currently lists official provider packages for OpenAI, Anthropic, Google Gemini, Amazon Bedrock, and Microsoft AI Foundry.
Connection: credentials and endpoint details
Connections store the provider choice plus settings such as API key and endpoint. Umbraco also supports configuration references for secrets and variables, including values resolved from appsettings.json, environment variables, and Azure Key Vault. That means secrets do not need to live directly in the database.
Profile: use-case defaults
Profiles combine a connection with a model and capability-specific settings. A writing profile, an embedding profile, and a support-assistant profile do not need to share the same provider or model. This is one of the cleanest ways to reduce lock-in: bind providers to use cases, not to the whole CMS.
Middleware: cross-cutting controls
Umbraco's middleware layer can add logging, caching, rate limiting, tracing, and custom behavior around requests. The middleware docs also point to Microsoft.Extensions.AI middleware such as OpenTelemetry support, structured logging, and function invocation. Operational controls are much easier to preserve during a provider change when they sit in middleware instead of being buried in one provider SDK.
How to Compare Providers Without Chasing Hype
1. Start with the capability you need, not the brand you recognize
Umbraco's provider list shows that supported capabilities vary by provider package. In the current docs, OpenAI supports chat, embedding, and speech-to-text; Microsoft AI Foundry supports chat and embedding; some other providers currently expose chat only. If your Umbraco use case depends on embeddings for search or classification, or speech input in a backoffice workflow, you should eliminate providers that do not support those capabilities in Umbraco before you compare pricing or benchmark screenshots.
2. Keep the application surface portable
Microsoft's official documentation says Microsoft.Extensions.AI provides abstractions such as IChatClient and IEmbeddingGenerator, and recommends that service consumers use those abstractions instead of hardcoding to a specific AI service. Microsoft explicitly says this improves portability across models and services, simplifies testing, and keeps the API consistent even when different services are used in different parts of the application.
If your Umbraco implementation stays close to those abstractions, swapping a provider is mostly a connection, profile, and evaluation problem. If your code depends deeply on one vendor's SDK features, the switch becomes a rewrite.
3. Separate direct model quality from operating-model fit
A provider can be strong on raw model output and still be the wrong choice for the business. The harder questions are operational: Which team manages keys? Which region matters? What must be logged? Which requests need review? What content must never be stored? Which use cases need stateful features? Those questions often matter more than small benchmark differences.
Compare Data Handling Before Procurement, Not After Build
For many Australian Umbraco teams, the first serious provider comparison is not just Which model writes better?
It is Which provider fits our data, audit, and regional requirements with the least friction?
OpenAI platform considerations
OpenAI's current data-controls documentation says API data is not used to train or improve OpenAI models by default unless the customer explicitly opts in. The same documentation also says abuse monitoring logs are generated by default and retained for up to 30 days, with additional controls such as Modified Abuse Monitoring and Zero Data Retention available for approved customers.
That same OpenAI guide also matters for regional design. In the regional table, Australia is listed at au.api.openai.com with regional storage available, but regional processing marked No, and it requires Modified Abuse Monitoring or Zero Data Retention. If your requirement is only where data is stored, that may be workable. If your requirement is where inference is processed, it needs closer review.
Microsoft AI Foundry / Azure considerations
Microsoft's official privacy documentation for Models sold by Azure, including Azure OpenAI models, says prompts, completions, embeddings, and training data are not used to train foundation models without your permission or instruction. Microsoft also states that the models are stateless and that prompts and completions are not stored in the model itself.
At the same time, Microsoft documents important caveats for stateful or optional features. Responses API history, Threads, stored completions, files, and vector stores may persist data in the service. Microsoft also says stored data for those features is kept in the customer's Azure geography, while certain deployment types such as Global or DataZone can broaden where processing occurs. That means an Azure choice still needs architecture review; it is not automatically lock-in free or region-risk free.
The main lesson is not that one provider is universally better. It is that data policy differences should shape provider choice early, before prompts, workflows, or editor expectations become dependent on a platform you later cannot approve for production.
A Practical Selection Model for Umbraco Teams
- Choose one supported Umbraco capability first. For example: blog drafting, FAQ summarisation, semantic search, or support-assistant responses.
- Create separate profiles per use case. Do not make one global profile carry writing, search, and internal support.
- Put provider credentials behind configuration references. Use Umbraco connections so keys and endpoints can vary by environment.
- Test two providers on the same prompt set. Measure quality, latency, cost, moderation friction, and editing effort.
- Document the data path. Note what is sent, what is stored, where it is processed, who can review it, and what retention controls exist.
- Plan the exit before rollout. Decide how you would replace prompts, re-run evaluations, rebuild embeddings, or retire stored state if the provider changed.
If one provider clearly wins for one workflow, that does not mean it should become the standard for every AI feature in Umbraco. A common low-lock-in pattern is to use one provider for one job, with profiles and middleware keeping the system consistent around it.
A Sensible Default Recommendation
For most teams, the safest starting position is not to ask, Which provider should own AI in Umbraco?
It is to ask, Which provider is the best first fit for this one approved use case, and how do we keep the next decision open?
In practice, that usually means:
- keeping application code on Umbraco.AI and Microsoft.Extensions.AI abstractions
- using connections for secrets, endpoints, and environment differences
- using profiles to isolate use cases and model choices
- adding middleware for telemetry, logging, and policy controls
- reviewing stateful features, retention, and regional requirements before adoption
- treating embeddings and stored history as higher-switch-cost decisions than ordinary chat prompts
That approach does not remove switching cost. It does reduce the chance that a future provider change turns into a CMS rebuild, a security exception, or a content-operations crisis.
Frequently Asked Questions
Short answers for teams trying to choose an Umbraco AI provider without painting themselves into a corner.
Sources Checked
- Umbraco Documentation: AI in Umbraco
- Umbraco Documentation: Core Concepts
- Umbraco Documentation: Providers
- Umbraco Documentation: Connections
- Umbraco Documentation: Profiles
- Umbraco Documentation: Middleware
- Microsoft Learn: Microsoft.Extensions.AI libraries
- OpenAI Developers: Data controls in the OpenAI platform
- Microsoft Learn: Data, privacy, and security for Models sold by Azure
- Umbraco: Long-term Support and End-of-Life
Choose the Provider, Keep the Escape Route
VaniTech can help you compare Umbraco AI provider options, design low-lock-in profiles and middleware, and align the rollout with governance, region, and operational needs.