Bring Your Own Model: How Drupal Works With Any AI Provider
The first thing that stalls AI in an enterprise CMS is rarely a feature. It’s the question of whose model it is.
With Drupal, the answer can be yours. That’s what bring your own model means: the AI in your CMS runs on an account your organization already controls, under its own data terms and budget. Drupal makes that possible because the Drupal AI module connects to 95 AI providers, including OpenAI, Anthropic, Google Gemini, Amazon Bedrock, and Azure. An enterprise CMS shouldn’t tie you to any one of them.
Enterprise teams often expect us to bring the AI. Then their governance team asks for exactly that. So the work shifts from features to four decisions: which account, which model for each task, who pays for the tokens, and what your AI governance board needs to approve it.
Key Takeaways
- Drupal AI connects to 95 providers through one framework, so no AI feature is tied to a single vendor.
- Each type of task can use its own provider and model, and switching providers is a configuration change.
- Running the model in your own account means your data terms, your region, and your token bill.
- A governance board can approve the plan in one review if it sees one roadmap, agents on a “later” slide, and a diagram of what the model sees.
How does Drupal connect to AI providers?
Drupal connects to AI providers through the Drupal AI module, which sits between your site and the provider. Each provider plugs in through its own module. Drupal.org counts 95 of them, from the ones above to Google Vertex, Hugging Face, and amazee.io.
Your AI features talk to that framework rather than to a vendor’s API. That’s what keeps you from being tied to one provider. Changing providers is a configuration change, and nobody has to rewrite the feature.
The framework is in wide use. Drupal.org shows 25,644 sites running it, and its stable releases are covered by Drupal’s security advisory policy. Provider modules mature at their own pace, though. The OpenAI provider has a stable, covered release. As of mid-October 2026, the AWS Bedrock and Azure providers had only beta releases, so check the status of yours before it goes to your board.
For a map of the wider ecosystem, our contributor's guide to Drupal AI modules in 2026 sorts what is production-ready from what is still experimental.
Can different tasks use different providers and models?
Yes. Drupal AI lets a site set a default provider and model for each type of operation, such as chat, chat with image vision, or embeddings. Alt text can run on one model while content review runs on another, even from a different provider.
Even one provider account can hold several model families: Drupal’s Azure provider also reaches Llama, Mistral, and Phi models.
Version 1.4 added rerouting and failover between providers. The OpenAI and Azure providers store API keys through Drupal’s Key module, the only module Drupal AI requires. The Bedrock provider authenticates through AWS profiles or assumed roles.
If your policy rules out cloud providers, Drupal AI can also use a model you host yourself, through the Ollama provider.
Why your CMS shouldn’t be tied to one AI provider
AI models change faster than CMS platforms do. Models retire, different tasks need different models, and your governance team may require a provider you didn’t plan for. A CMS tied to one provider can turn each of those into a rebuild. In Drupal, each one is a configuration change.
That’s why I treat provider flexibility as a requirement when choosing a CMS for AI. Drupal AI is open source and model-agnostic, so the model can run in whatever account your board approves, and you can change it when a better one comes along.
Software won’t tell you who owns the account, who pays, or who signs off. Answer those first, and the build is the easy part.
Whose account should the model run in?
Yours. If your organization already has an Amazon Bedrock, Azure OpenAI, or OpenAI API account, that’s where the model should run. We configure Drupal to use it, and the account stays yours.
How the three accounts compare:
Provider account | Where the bill lands | Controls you set | Drupal provider module, October 2026 |
|---|---|---|---|
Amazon Bedrock | Your AWS account | Routing within one Region, one geography, or globally; per-model token quotas | AWS Bedrock Provider 1.1.0-beta4, no stable release |
Azure OpenAI (in Microsoft Foundry) | Your Azure subscription | Deployment type (regional, DataZone, or Global) and region for each model | Microsoft Azure AI 1.2.0-beta1, no stable release |
OpenAI API project | Your OpenAI organization, by project | Organization and project spend limits | OpenAI Provider 1.2.5, stable and covered |
Each provider publishes data terms your board will want to read. AWS says Amazon Bedrock doesn't store or log prompts and completions, use them to train AWS models, or share them with third parties. Microsoft says prompts and completions sent to Azure OpenAI models in Microsoft Foundry aren't available to OpenAI.
Routing decides where a request can be processed. On Bedrock, geographic routing keeps requests within a defined geography, such as the US, while global routing can use any commercial AWS Region. On Azure, prompts are processed in the geography you choose, unless you pick a Global or DataZone deployment.
For government, intergovernmental, and other regulated teams, the routing setting belongs in the board submission.
Which model fits which task?
Use a fast vision model for alt text and a stronger model for content review.
The AI Image Alt Text module, used on 14,221 sites, works with any vision-capable model through Drupal AI. Its maintainers name models from OpenAI, Anthropic, Google, and Fireworks AI, and you can switch between them without changing how editors work. It can resize images before sending them to cut API costs.
Content review needs the stronger model. Ahmad Khader leads development of AI Content Review on our team. In his introduction to AI Content Review, he explains that the review agent drives most of the quality. Every review is a set of calls to your provider.
Models also retire. On Amazon Bedrock, a model enters a Legacy period before end-of-life. For models launched from 7 September 2026, that period is usually six months, and AWS lists the end-of-life date on the model card. Check it before you name a model in your plan.
Who pays for the tokens, and how much?
You do, through your own account. Providers charge by tokens, the units a model reads and writes, at a published price per model. A monthly estimate is new items × AI calls per item × tokens per call × price per token.
The number that’s easy to miss is the backfill: a one-time run of a feature over content that already exists. The alt text module includes a bulk sub-module that writes alt text for every existing image.
On a hypothetical site with 40,000 images that adds 500 a month, the backfill equals 80 months of normal volume, all at launch.
Plan the backfill against provider quotas, too. Bedrock sets per-model token quotas per minute in each Region. AWS says it prioritizes quota increases for customers already using their current allocation.
Turn on AI Metering before launch. It’s been stable since August 2026, and it logs tokens, cost, and the calling feature for every call across providers. It can also set a monthly quota per user. When someone hits it, calls can fall back to a local model instead of stopping work.
After launch, the other running cost is the account owner’s time:
- Reviewing metering data and provider quotas each month.
- Testing provider module updates, especially for modules still in beta.
- Re-testing a feature when its model is retired.
- Updating the board when an item moves from "later" to "now."
What does an AI governance board need to approve it?
An AI governance board is the group that approves new AI use in your organization. It can approve the whole plan in one review if it sees two things: one roadmap with agents on a separate “later” slide, and a diagram of what the model can and cannot see.
That matters because review is where AI work slows down. OneTrust's 2026 AI-Ready Governance Report surveyed 1,200 senior business decision-makers in eight countries. According to Help Net Security's summary of the report, 96% said governance, risk, or review had slowed, paused, or complicated at least one AI initiative. A third had seen employees turn to unapproved AI because approved tools came too slowly.
The roadmap lists the editor features that ship now, each with its task, its model, and the account it runs in. Agents go on the later slide. In the same survey, agentic workflows were the AI initiatives most often slowed by review.
AI-assisted generation and content tagging already run in production at enterprise scale. More ambitious agentic workflows should be piloted first, as I wrote when I explained why we joined the Drupal AI Initiative as a Gold Sponsor.
Agents also raise permission and audit questions, which we covered in our article on the trust layer AI agents need.
The diagram shows what each feature sends to the model. Alt text sends the image and the prompt your team configured. Content review sends only the fields its instructions name. The diagram should also show what no feature sends, such as user records and form submissions.
And it should show where calls are logged. Drupal AI’s Observability submodule logs every AI request in the same format, whichever provider served it, and can feed tools such as Datadog, Grafana, or Splunk through OpenTelemetry. The AI Logging module is the simpler option. Either way, those logs hold prompts and responses, so they need the same access rules as your content.
What should you bring to your AI review?
One page that covers the four decisions. This is what goes on it, and how to tell you’re ready:
Decision | Bring to the board | You're ready when |
|---|---|---|
Provider and account | Account owner, provider data terms, routing or region, Drupal module status | You can name the account, its administrator, and where requests are processed |
Model per task | Each feature's task and the model it uses | Every feature has a named model |
Token bill | Monthly estimate, backfill estimate, provider quotas, metering plan | The budget owner has signed off on both estimates |
Approval scope | One roadmap, agents on a later slide, data-flow diagram, logging plan | The board can see what ships now, what comes later, and what the model sees |
Then check where you stand:
- Ready to submit if you can fill all four rows from facts your team already holds.
- Procurement first if your organization has no approved account with a provider that Drupal AI supports.
- A budget owner first if no one has signed off on the backfill estimate.
- Split the submission if agents and editor features sit in the same request.
Where should you start?
Fill in that page before your next AI review is on the calendar.
If you want a second opinion on where your CMS stands, our AI readiness and consultancy team can assess it with you. We’re a Gold Sponsor of the Drupal AI Initiative and maintain the Varbase AI recipes. Every contribution we make is on the public record at drupal.org.