Bring Your Own Models
DocAI Fabric's cloud service normally runs on AI models we choose and pay for. With Bring Your Own Models (BYOM) you keep the same hosted service, and the AI work runs on model deployments in your own cloud subscription, for example your Microsoft Foundry or Azure OpenAI resources. You choose the models, where they run, and you pay your provider for them directly.
This page explains what that means in practice: which models the service needs, how the contract decides which tasks are yours, and how to connect, test and choose your models.
What Stays With Us, and What Is Yours
| Standard SaaS | SaaS with your own models | |
|---|---|---|
| Hosting, storage, backups, security, updates, monitoring, support | DocAI Fabric | DocAI Fabric |
| Where your documents and results are stored | The Region of your account | The Region of your account |
| AI models (classification, extraction and the rest) | Chosen and paid for by DocAI Fabric | Chosen by you, in your subscription, paid by you to your provider |
| Where AI processing runs | Global by default, or the location in your Order Form | Where you deployed your models |
| Model quota and throughput | DocAI Fabric | You |
| Our price | Per page, models included | Per page, models not included |
You can also combine the two: your own models for some tasks and ours for others. Your Order Form says which (see What the Order Form Decides).
One Model Is Not Enough
A common first plan is "we will give you our GPT deployment and everything will run on it". A language model can indeed serve most tasks, but not all of them: reading the text of a scanned page is done by an OCR service, not by a chat model, and voice input needs a speech service. And the in-app assistant needs a model that can call tools.
These are the tasks DocAI Fabric uses a model for. Each one needs a model, from you or from us, unless your Order Form marks it as not used.
| Task | What uses it | What the model must be able to do | How it is connected |
|---|---|---|---|
| OCR | The OCR step: every page of every document | Azure AI Document Intelligence (the Read model; Layout too if a project uses it) | Models page, as an OCR model |
| Split | The Split step, when it splits by AI | Text in, structured (JSON) answer out | Models page |
| Classify | The Classify step | Text in, structured answer out; images if the step sends page images | Models page |
| Extract | The Extract step | Text in, structured answer out; Image if the step sends page images, which most invoice and form projects do | Models page |
| Redact | The Redact step's AI pass that finds sensitive data | Text in, structured answer out | Models page |
| Translate | Translate Text in the document viewer | Text in, text out | Models page |
| Assistant | The in-app assistant, and the Agent Review step unless that step names another model | Tool calling and Streaming; Image so it can look at pages | Models page |
| Assistant background | The assistant's conversation titles, summaries and prompt suggestions | Text in, text out; a small, fast model is enough | Models page |
| Voice input | The microphone button in the assistant | Azure AI Speech, or an Azure OpenAI transcription deployment | Models page, as a voice input model. Or it stays off |
One deployment can serve several tasks. A capable current model (a GPT model on Azure, for example) usually passes every language task on this list, while many teams use a smaller, cheaper model for Split, Classify and Assistant background and a stronger one for Extract and the Assistant. The Test button on the Models page tells you, task by task, whether a model can do the work (see Testing and Measuring Models).
What the Order Form Decides
Bring Your Own Models is sold on an annual Order Form, under the Master Services Agreement. Its Models by Task table lists every task above with who supplies the model:
- You: the task runs only on your deployments. We use none of our models for it (other than for the analysis by Anthropic in Data Processing Agreement clause 13.8), and never fall back to ours: if your deployment is unavailable or throttled, the documents wait and are retried on your deployments. Time lost that way does not count against our availability commitment (Service Level Agreement, section 5.2).
- DocAI Fabric: the task runs on our models, at the location the table states.
- Not used: the feature is switched off for your account.
When every task is yours, the platform's models are not available on your account at all, on the Models page or anywhere else. When some tasks are ours, the models we provide for them appear on your Models page, and the Defaults tab shows which model each task uses.
The providers of your models (Microsoft, for example) work for you under your own agreement with them; they are not our sub-processors. Your documents' text and page images are sent to your deployments for the tasks that are yours, so the location you choose for each deployment is where that processing happens. Everything we store stays in the Region of your account, apart from the temporary copies of Data Processing Agreement clause 13.8, as the Data Handling page describes.
Before You Start: Prepare Your Deployments
In your own subscription:
- Language models. Deploy the models you want to try, for example in Microsoft Foundry or Azure OpenAI. Choose the deployment type with the location in mind: a regional or data-zone deployment keeps processing in that region or zone, a Global one may process anywhere the provider runs the model.
- Quota. Give each deployment enough tokens per minute for your volume, with room for peaks. A Performance run on the Models page shows what a deployment sustains; the Hosting Options page, with SaaS with your own models chosen, plans what your volume needs. Too little quota does not lose documents, it makes them wait.
- OCR. Create an Azure AI Document Intelligence resource and add it on the Models page as an OCR model, with its endpoint and key. Its Test reads a reference page. Then choose it as the OCR default.
- Voice input (optional). Create an Azure AI Speech resource (or a transcription deployment on Azure OpenAI) and add it on the Models page as a voice input model, then choose it as the voice input default. Or leave voice input off.
- Content filtering. Business documents (invoices, medical forms, legal papers) can trip a provider's default content filter, which then refuses the request. If your provider lets you, apply a filter policy suited to document processing.
Connect and Test Your Models
For each language model:
- Open Models (Integrate > Models) and click Add model. Copy settings from a model that already works, for example a system model of the same family, fills in the API version and request settings; you then add your endpoint, deployment name and key. Full field reference: Models.
- Tick the Supported tasks the model should serve, and its Modalities (Image for extraction from page images and for the assistant, Streaming for the assistant).
- Press Test. It checks, operation by operation, that the endpoint is reachable and can do each task you ticked, with synthetic data, never your documents.
- Enter the model's Estimated cost from your provider's price list, so the Usage tab, budgets and the Evaluation page show your real cost per page.
- On the Defaults tab, choose your model for each task. A workflow step that names a model in its own settings uses that model; every other step uses the default.
Add a second endpoint to a model (another deployment, another region) to spread load and keep processing when one deployment is throttled: DocAI Fabric balances and fails over between the endpoints of a model, and only between yours.
To script these steps, for example to set up several environments the same way, use the
da command-line tool: da models add, da models test and da models defaults do
what the page does (From the command line).
Choose Your Models with Evaluation
Test proves a model can do a task. Whether it does it well on your documents is a question for the Evaluation page:
- Build an evaluation dataset: a set of your real documents with their correct values (ground truth).
- Run it with your first candidate and note accuracy, processing time and cost per page (Cost in Evaluation).
- In the project's draft, change the model of a step (or the default on the Models page), re-run the dataset, and compare.
- Keep the model that gives the accuracy you need at a cost and speed you accept, and publish the project.
Repeat this whenever you consider a new model or a new version of one. Models change behaviour between versions, and your evaluation dataset is how you find out before your production documents do.
Questions We Are Often Asked
Can we start with your models and move to ours later? Yes. A change of the Models by Task table is a new Order Form or an amendment; the switch itself is made on the Models page.
What happens when we retire or replace a model? Add the new one, test and evaluate it, then change the default or the steps that name the old one. Until you do, the steps keep using the old deployment, and fail if you delete it.
Do you see our model keys? Keys you enter on the Models page are stored encrypted for your account and used only to call your deployments. Keys you send us for OCR and voice input are handled by our operations team only for that connection.
Does this change what you do with our data? No. The Data Processing Agreement applies to everything we store and process, including the analysis by Anthropic of its clause 13.8, and we never train models on your content.