Bring your own AI model to dotAI
AI features only provide value if you are allowed to switch them on. For many organizations, that has been the sticking point - and the obstacle is rarely the AI itself. It is the model vendor. Content, prompts, and structured data have to be processed somewhere, and if that somewhere is a single external provider your organization has not approved, the conversation ends before it starts.
dotAI now runs on the AI provider you choose. You configure it once in the dotAI app, and every AI capability in dotCMS - writing assistance in the block editor, AI workflow actions, automatic tagging, semantic search, and image generation - runs on the provider you selected. There are seven supported providers. Four of them are multi-vendor gateways that reach thousands of models - AWS Bedrock, Google Vertex, Azure OpenAI (Microsoft Foundry), and OpenRouter, which fronts hundreds of models from dozens of creators behind a single key. And if you are already using dotAI, existing setups keep working exactly as they did, no need to update configurations unless you want to start using additional models.
The model is a governance decision, not just a feature
Three separate pressures push organizations toward provider choice, and most compliance-led organizations feel at least one of them.
The first is where the data is processed. Healthcare, financial services, government, and telecommunications organizations frequently operate under rules that require content and data to stay inside an approved cloud boundary. If AI processing means sending content to a vendor outside that boundary, it is a non-starter regardless of how good the feature is.
The second is contracts and cost. Many organizations already hold agreements with Azure, AWS, or Google Cloud that include AI services, with negotiated pricing and data-handling terms already in place. Being asked to sign a separate agreement with a different model vendor, on different terms, just to use AI in the CMS is friction nobody wants.
The third is independence. Teams do not want to bet their content operations on a single model vendor's roadmap, pricing, or availability. The ability to move - to a different provider, or a different model for a specific task - is worth as much as any individual model's quality.
What shipped
dotAI is now provider-agnostic. In the dotAI app there is a single Provider Config field, written as JSON, with three independent sections: chat, embeddings, and image. Each section names its own provider and model, so you can run chat generation on one provider and semantic-search embeddings on another. You select a provider by identifier, and the supported set is:
Azure OpenAI, AWS Bedrock, and Google Vertex AI - the three major cloud AI platforms, so you can run dotAI inside the cloud boundary you already trust and contract with.
Anthropic and Google AI Gemini - direct providers that need nothing more than an API key. No cloud project, no IAM setup: paste a key and dotAI is live on Claude or Gemini.
OpenAI - the original direct provider, unchanged.
OpenRouter - an aggregator that reaches hundreds of models across families (OpenAI, Anthropic, Meta Llama, Mistral, DeepSeek) through one API key and one bill.
Text generation works across all seven providers. Embeddings for semantic search run on the providers that support them - OpenAI, Azure OpenAI, AWS Bedrock, and Google AI Gemini - and image generation runs on OpenAI, Azure OpenAI,and Google AI Gemini. Though model capabilities and availability is constantly changing.
How it works
Under the hood, dotAI is built on LangChain4j. A single factory holds all of the provider-specific logic, one strategy per provider, and the rest of the product talks to a common client that returns responses in a consistent shape. That design is why a provider swap is transparent to everything above it: the block editor, the workflow actionlets, the embeddings service, and the $ai ViewTool do not know or care which vendor answered the call. Adding a provider is a contained change - a strategy class and a registry entry - not a rewrite of the AI pipeline.
A few details that matter to a platform team:
Credentials stay in configuration and out of logs. Provider keys and secrets are redacted, and built models are cached by a hash of the configuration, never by the credentials themselves. Rotating a key or changing config evicts the cache.
In-cluster AWS auth is first-class. AWS Bedrock can use the default AWS credential chain - environment, profile, or IRSA on EKS - so you do not have to paste static keys into the app to run inside your own AWS account.
Gateways and proxies are supported. Most providers accept an endpoint override, so if your organization routes AI traffic through an internal gateway, dotAI can point at it.
Per-request tuning is available per section: temperature, token limits, retries, and timeouts, plus provider-specific options like embedding dimensions and image size.
What it looks like in practice
A financial-services organization that can only use AI hosted inside its contracted cloud points dotAI at Azure OpenAI. Its content teams keep using the same writing assistance, auto-tagging, and semantic search they would have anyway - the difference is that it all runs inside the boundary the organization already approved. The editor experience does not change; the governance requirement is simply met.
A smaller team with no cloud-AI contract takes a different path. A developer pastes a single Anthropic or Google AI Studio key into the chat section, and dotAI is running on Claude or Gemini in minutes - no GCP project to stand up, no AWS roles to configure.
A platform team that wants to keep its options open configures OpenRouter once. From there it can direct chat at any of hundreds of models and change its mind by editing a config value - useful when a new model lands, or when a particular task turns out to be better served by a different one, all under a single bill.
Why this matters beyond the provider list
The point of provider choice is not the length of the list. It is that the model becomes a decision you own rather than a constraint you inherit. dotAI has always been content-aware - it understands your content types, your workflows, and your taxonomy - and that value is now available on whatever model your governance, your contracts, and your team's judgment point you toward. You do not trade control for capability.
Availability
Multi-provider support is available in dotCMS now. If you are already using dotAI on OpenAI, nothing changes until you decide to change it. If you have been waiting to turn on AI until you could run it on a provider you approve, that wait is over: the configuration is a few lines in the dotAI app.