Three firms, three AI policies
Your product uses one AI provider for drafting and review. The first large firm to buy it has an AI policy that allows only Azure OpenAI, running in a UK or EU region, under the firm's own tenancy if possible. The second firm allows Anthropic Claude through a specific cloud platform but not direct APIs. A third firm is still deciding and wants AI features switched off entirely until its committee meets.
Your code calls one provider directly from dozens of places. Serving all three firms means either turning them down or forking your product.
Then the first firm's IT team asks a follow-up question: when the preferred model is busy, does your product ever send their requests somewhere else? Nobody on your team is completely sure, because retry logic was added in a hurry during an outage last spring.
Why firms differ so much on AI
Firms reach their AI policies through their own risk assessments, client demands and committee decisions. Some are shaped by what their largest clients require. The policies differ and change over time.
- Some firms approve providers through their existing cloud agreements with Microsoft, AWS or Google.
- Some specify regions for data processing, or require no retention by the provider.
- Some want their own provider account used, so they hold the relationship and the logs.
- Some restrict AI to certain practice groups or document types.
- Policies are reviewed regularly, so approval can be added or withdrawn.
What a single hard-wired model costs
Every firm whose policy does not match your provider becomes a lost deal or a long negotiation. Firms that tighten their policy mid-contract put you in a difficult position with no quick way to comply. Your engineers spend time on special cases rather than improving features. And when a provider has an outage, every firm is affected at once, with no fallback.
Firm policies also generate questions your team has to answer case by case. Which region does this feature run in? Is anything retained by the provider? Can we use our own account? Without a model layer, each answer depends on reading code, and the answer can change the next time an engineer adds a feature that calls a provider directly.
How we build per-firm model routing
What we build separates your product's AI features from the providers that run them.
- A model layer your features call instead of calling providers directly, with a common interface for prompts, retrieval and outputs.
- Provider adapters for the options your firms approve, such as Azure OpenAI, Anthropic Claude directly or through a cloud platform, and others as needed.
- Per-firm policy settings: approved providers and models, regions, whether the firm's own account is used, and which features or practice groups may use AI at all.
- Evaluation tests for each feature against every approved model, so you know how each performs before switching a firm to it.
- Safe behaviour when an approved model is unavailable: queue, retry or tell the user, never silently fall back to a model the firm has not approved.
- A record of which provider and model processed each request, per firm, for audits and firm questions.
| Firm policy | What the model layer does |
|---|---|
| Azure OpenAI in a UK or EU region only | Routes to that deployment, no other |
| Firm's own provider account | Uses the firm's credentials and account |
| AI off until committee approval | AI features hidden for that firm |
| AI for certain practice groups | Features enabled per group |
| Approved provider outage | Queue or clear message, no unapproved fallback |
Serving all three firms
The first firm's requests go to an Azure OpenAI deployment in a UK region under their account. The second firm's go to Claude through their approved cloud platform. The third firm sees no AI features until their committee approves, and when it does, an admin switches them on for two practice groups. Evaluation results show each feature performs acceptably on all approved models, and where one model is weaker for a task, you know it before a firm does.
Is your AI setup blocking firm deals?
- Your product calls one AI provider directly throughout the code.
- Firms with different AI policies are turned away or kept waiting.
- You cannot switch AI features off for one firm or one practice group.
- A provider outage affects every firm at once.
- You cannot show which model processed a given firm's requests.