# Enterprise AI enablement: governed access for the whole company Give each team governed access to a few approved models through one gateway, and measure adoption by the work that gets finished. Aigentcy 5 May 2026 13 min read Updated 7 September 2026 ## Key takeaways - Put each team behind one gateway with its own key, budget and allowed models, so access is granted in minutes and removed in one place. - Keep the approved catalogue to four or five routes named after the work, such as routine, hard cases, documents and private data, and retire a route that stops earning its place. - Send routine work to open-weight models. Public price lists put them at a small fraction of frontier prices per token, so judge the switch on cost per finished task. - Cut tokens before buying capacity: cache the stable part of the prompt, retrieve passages instead of pasting whole documents, and split unrelated tasks into separate sessions. - Measure adoption by finished tasks that passed review, review minutes and escalation rate. A login count says nothing about value. **Governed access is one door with several rooms** A team's key says which routes it may use and how much it may spend. Adding a team is issuing a key. Removing one is disabling it, and every application that used it stops at once. Before anyone talks about enterprise AI enablement, each team in the company has already found its own way in. Sales pays for a chat subscription on a card. Support pastes ticket text into a free tool. Engineering keeps three provider keys in a shared vault, and nobody knows which one the nightly job uses. The options on the CIO’s desk both look bad. Block everything and watch the unofficial use grow, or allow everything and lose track of data, spend and quality. Enterprise AI enablement is the third option: governed access for each team through one door, a small catalogue of approved models, and adoption measured by the work that gets finished. Here is how we build it. ## What enterprise AI enablement has to deliver An enablement programme is a service, and a service has deliverables. Ours has five. - **One door.** Every application, person and scheduled job reaches every model through one gateway with its own key. - **A short catalogue.** Four or five approved routes, each named after the work it’s for, each with a budget and a data rule. - **Task templates.** For the ten or so tasks that matter, a written brief that says what goes in, what comes out and who accepts it. - **A route to help.** A named contact for access problems and a separate one for reporting a wrong or unsafe answer. - **Evidence.** A monthly view of finished work, review time and cost by team. The gateway gets the attention because it’s the technical piece. But a team with governed access and no template still produces uneven work, so the templates and the evidence carry as much of the value. ## Start from the tasks teams already do Pick the first use cases for observable output and available reviewers. Drafting an internal briefing from approved documents is easy to assess. “Make everyone more productive” isn’t. For each task, write down the current process, the inputs, the acceptance rule and the person who signs off. Include the time spent finding information and checking the answer, because those steps often decide the value of the workflow. Interview the people who tried AI and stopped, as well as the confident users. The ones who stopped tend to reveal a missing permission, an unreliable source document or a review burden that usage statistics hide. | Work pattern | Starting route | Acceptance question | | --- | --- | --- | | Rewriting approved text | Routine model | Did the meaning and the required details survive? | | Finding an answer in company documents | Retrieval with cited passages | Do the sources support the answer, and do they apply here? | | Weighing uncertain options | Stronger model tested on multi-step analysis | Are the assumptions, trade-offs and omissions visible? | | Reading images or files | A route tested on that input type | Did it read the supplied evidence correctly? | | Changing a business system | Approved tool workflow with a confirmation step | Was the permitted change made and checked? | ## A small approved model catalogue Employees shouldn’t need to follow model releases to decide how to summarise a policy. So the catalogue is written in the language of the work, and each route maps to a model that the platform team can change without retraining anyone. | Route | What it’s for | Typical model tier | Data allowed | | --- | --- | --- | --- | | Routine | Rewrites, summaries, classification, extraction | Open-weight or small proprietary | Internal, non-sensitive | | Hard cases | Analysis, planning, difficult documents | Frontier | Internal, non-sensitive | | Documents | Questions answered from company sources with citations | Retrieval plus the routine model | Whatever the person may already read | | Media | Images, audio, files as input | A route tested on that input type | As above, checked per source | | Private | Regulated or confidential material | Self-hosted open-weight model | Sensitive, inside our boundary | Five routes is enough. Publish what each one is for, which data it accepts and when to ask for something else. When a route stops passing its own tests or nobody uses it, retire it rather than letting the catalogue grow. **A catalogue people can use without following model news** Two of the five tasks land on the routine route, which is where most volume goes. The private route exists for material that cannot leave the company's own infrastructure. The same person may use two routes in one piece of work. The routine route drafts the first summary, and the hard-cases route helps with the one inconsistency that needs real analysis. Human approval stays wherever the consequences call for it. ## One gateway for every model An AI gateway sits between every application and every provider. It holds the provider credentials, so no team ever sees them, and it issues each person, service and scheduled workload a key of its own. How a request passes through the gateway ```mermaid flowchart TD accTitle: How a request passes through the gateway A[Person or service with their own key] --> B[Gateway] B --> C{Model allowed?} C -->|No| D[Refused, logged] C -->|Yes| E{Budget left?} E -->|No| D E -->|Yes| F[Provider] F -->|Provider down| G[Approved fallback] F --> H[Usage recorded] G --> H ``` Each key carries a budget, a list of allowed models and a team. [Bifrost](https://docs.getbifrost.ai/features/governance/virtual-keys), an open source gateway, calls these virtual keys, and its [budget and limits](https://docs.getbifrost.ai/features/governance/budget-and-limits) documentation shows the hierarchy of key, team and customer budgets. Other gateways use different names for the same idea. What the gateway gives a manager: - **Access in minutes.** A new starter gets a key, a budget and the routes for their role on day one. - **Removal in one place.** A leaver’s key is disabled, and every application they used stops working at once. - **A spend figure per team** that finance can read, which we cover in [AI cost management](https://www.aigentcy.com/blog/enterprise-ai-cost-control/). - **Fallbacks you chose.** When a provider is down, the request moves to an approved alternative, and never to one that hasn’t been reviewed for that data. - **One log.** Who called which model, when, for how many tokens, at what cost. A budget refusal ends the request. It doesn’t try another model, because a fallback that steps around a budget defeats the budget. Fallbacks are for a provider being down, and the approved alternative is chosen in advance for each route and its data. Keep sign-in, team membership, model access and tool permissions distinct. Being allowed to use the routine route says nothing about being allowed to read finance documents or update a customer record. The gateway enforces the first. The application has to enforce the rest. ## Open-weight models for routine work Open-weight models publish their trained parameters under a licence. You can run them on a host’s infrastructure or your own. And on a per-token basis, they cost a small fraction of the frontier models. | Tier | Example (source) | Input per 1M tokens | Output per 1M tokens | | --- | --- | --- | --- | | Frontier | Claude Opus 5 (Claude pricing) | $5.00 | $25.00 | | Frontier | GPT-6 Astra (OpenAI pricing) | $10.00 | $50.00 | | Small proprietary | GPT-5.6 Luna | $0.20 | $1.20 | | Open weight, hosted | DeepSeek V4 Flash (Together pricing) | $0.14 | $0.28 | | Open weight, hosted | Llama 3.3 70B | $1.04 | $1.04 | These are list prices from public pages on 7 September 2026, shown to give a sense of the spread. Check the pages before you plan a budget. The routine route is where this matters. Classifying tickets, extracting invoice fields, rewriting approved text and drafting first summaries pass review on a good open-weight model in our tests. So they run there, and the frontier route is kept for the cases that fail. Self-hosting adds hardware, security patching, capacity planning and an on-call rota. It’s worth it when the data can’t leave your boundary or when a steady workload keeps the hardware busy. Our [private AI service](https://www.aigentcy.com/services/private-ai/) is built around that decision, and a hosted open-weight service is the middle path when neither condition holds. Judge every switch on cost per finished task. A cheaper model that needs two extra correction loops costs more than a stronger first attempt, and only your own cases will tell you which way it goes. Before a route changes model, we run the same five checks every time: 1. Build a test set of 50 to 100 real tasks the company is allowed to use, including the awkward ones and a few where the right answer is to ask for clarification. 2. Have two reviewers score both models against the same acceptance rule without knowing which model produced which answer. 3. Count the escalations, retries and corrections each model needed, and price the whole run, including review minutes. 4. Treat any permission or factual failure on sensitive work as a stop, whatever the average score says. 5. Keep the test set, the scores and the model versions with the decision, so it can be rerun when either model changes. ## Token optimisation Before anyone buys more capacity, cut the tokens each task sends. Four habits do most of the work. | Habit | What it cuts | Watch out for | | --- | --- | --- | | Cache the stable prompt | Input cost on the instructions and reference text that repeat every call | Only the unchanged prefix is cached, so put the changing material last | | Retrieve passages, don’t paste documents | The 30-page policy attached to every question | Retrieved passages must be current and enough to answer | | Split unrelated tasks | Long histories that ride along with every message | Carry forward decisions and evidence, then check nothing was lost | | Ask for the length you need | Output tokens, which cost five times input on most lists | A short answer that omits a condition is a wrong answer | Prompt caching is the cheapest win. [Claude’s caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) prices a cache read at 10 percent of the base input price, and [OpenAI’s](https://platform.openai.com/docs/guides/prompt-caching) list shows cached input at similar ratios. It applies to the matching prefix of the prompt, so stable instructions go first and the question goes last. Here is an illustrative before and after for a policy question. The numbers are assumptions, chosen to show the shape. - **Before.** Every question sends the full 30-page policy, around 38,000 tokens, plus 2,000 tokens of instructions. Every token is billed at the full input price. - **After.** The 2,000-token instructions are cached and read at a tenth of the price. Retrieval sends the three relevant passages, around 1,500 tokens. The question adds 200. The billed input falls from 40,000 to under 2,000 full-price tokens. **Cut the tokens before buying capacity** The saving comes from what the request stops sending, so the acceptance test has to run again after each change. Too little retrieved context shows up as a wrong answer rather than an error. Test each change against the same acceptance rule. Cutting context too far removes evidence the model needs, and the failure shows up as a wrong answer rather than an error. ## Access lifecycle and clear refusals Onboarding is the easy part. The service also has to handle movers, leavers, lost keys and temporary exceptions, and every one of those paths needs a test. - **Joiner.** Key, budget, routes and templates for the role, issued by the team lead. - **Mover.** Old team’s key closed, new team’s key issued. Spend history stays with the old team. - **Leaver.** Key disabled on the last day. Every application that used it stops at once. - **Lost key.** Rotate it, and read the log for the window it may have been exposed. - **Exception.** A temporary budget increase or a one-off route, with an expiry date and an approver. Budgets for the first month are guesses, so keep them small and adjust after four weeks of real use. A person on the routine route with a $30 monthly budget and a $5 daily cap rarely hits either. A scheduled job gets a budget sized to its expected run, and a daily cap that stops a looping job within the hour. A refusal has to say why and what to do next. Otherwise people repeat the request, blame the tool and go back to the unofficial one. | Refusal | What the person sees | Next step offered | | --- | --- | --- | | Budget reached | “Your team’s monthly allowance is used up.” | Use the routine route, or ask the team lead for more | | Model blocked | “That route isn’t enabled for your key.” | The routes that are, and who can add one | | Provider unavailable | “The usual provider is down. Using the approved alternative.” | Nothing to do, with the fallback noted in the log | | Sensitive data detected | “This request contains data the route doesn’t accept.” | The private route, or remove the data | ## Teaching people to check the answer Training built on a generic prompt workshop doesn’t stick. Training built on the team’s own briefing, with approved or synthetic material, does. The task template does half the teaching. Ours has four fields, and a brief that fills them in gets a better first answer than any prompt trick: - **Outcome.** What the finished piece is for and who reads it. - **Evidence.** Which approved documents or passages the answer must rest on. - **Constraints.** Length, format, tone, and anything the answer must not include. - **Acceptance.** Who signs it off and what they’ll check. Give people a short review routine: - Check that the answer addresses the actual task and the intended audience. - Open the sources behind any material claim and confirm they support it. - Look for assumptions, missing evidence and details copied from an unrelated context. - Recompute any consequential number independently. - Keep the accountable owner in the approval step. Make feedback specific. “Wrong answer” gives the workflow owner nothing to fix. “It applied last year’s policy to this year’s request” points at a stale source document, and the source owner can correct it. ## Measuring enterprise AI enablement by finished work An enabled account is a starting point. Track whether people come back to the approved routes, and whether the work they finish there passes review. | Measure | Business question | Limit to keep in view | | --- | --- | --- | | Finished tasks that passed review, by workflow | Which uses produce work the team needs? | Activity without acceptance can be wasted effort | | Review minutes per finished task | Where does the process release capacity? | Include correction and queueing, and sample it rather than self-report | | Cost per finished task | Which route is economical at the required quality? | Include shared operation and escalations consistently | | Escalation rate to the stronger route | Where does the default struggle? | Some escalation is intended for hard work | | Refusals and support requests | What stops people using the service? | Low usage can mean friction, and sometimes no demand | Don’t set a usage target. A target rewards requests, and a spreadsheet formula or an existing application is sometimes the right answer. Review adoption at the workflow level with the business owner, and when one team succeeds and another stops, compare the task, the training, the source quality and the permissions before you buy more capacity. ## Rolling out team by team Each team joins through the same five steps, and the review at the end decides who’s next. 1. Choose an owner, one workflow and its acceptance rule. 2. Approve the routes, data sources, budget and tool permissions for that workflow. 3. Test representative tasks, and test the refusals. 4. Train a pilot group on their own material and measure the finished work for a month. 5. Fix the failures that matter before inviting the next team. We ran the [shared code context](https://www.aigentcy.com/case-studies/agentic-second-brain/) rollout for a development team this way, one harness and one repo at a time. The expansion review names the next team’s workflow, the evidence for its route, and the people who’ll maintain the knowledge and controls. Fund that maintenance alongside the model access, because the catalogue and templates decay without it. The result is unglamorous. Each team has a key, a budget and four or five routes they understand, and the monthly report shows finished work rather than logins. If you’re deciding how to give your teams governed access, our [AI governance](https://www.aigentcy.com/services/ai-governance/) and [private AI](https://www.aigentcy.com/services/private-ai/) services cover both halves. ## Frequently asked questions What does enterprise AI enablement include? Governed access for each team, a short catalogue of approved models with budgets and data rules, task templates and training built on real work, a route to help, and evidence that finished work meets the standard. Model access on its own is the smallest part. Does every employee need the most capable model? No. Test representative tasks and set a default route that passes them, with an approved escalation route for the cases that fail. In our rollouts the frontier model ends up on a minority of requests, and the routine route carries the rest. Are open-weight models safe for company data? The model weights are public, so nothing about them leaks your data. What matters is where the model runs and what the host retains. A hosted open-weight service needs the same data terms review as any provider, and a self-hosted one keeps the data inside your own boundary. Does an AI gateway make company data safe automatically? No. A gateway enforces which models a key may call, how much it may spend and what gets logged. Which documents a person may retrieve, which tools an agent may run and how long records are kept still need their own controls and tests. How do we know enablement is working? Count finished tasks that passed review by workflow, the review minutes each took, the escalation rate to the stronger route and the cost per finished task. Compare against the baseline you measured before rollout, and treat a team that stopped using the service as a signal to investigate. ## Related reading - [AI cost management: what an accepted result costs](https://www.aigentcy.com/blog/enterprise-ai-cost-control/)How to report AI spend the way finance reports everything else: by team, by workflow and by accepted result, with unknown charges kept separate from zero. - [Enterprise AI in Slack: one assistant for company knowledge](https://www.aigentcy.com/blog/enterprise-ai-in-slack/)Put one assistant where the questions already arrive, let it search only what each person may read, and measure how fast people reach a verified answer. - [An AI governance framework your team can operate](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/)A decision guide for the people who sign off AI systems: how much governance each one needs, who does what in the first 90 days, what it costs to run, and the evidence that proves the rules were followed. - [Shared code context for a development team](https://www.aigentcy.com/case-studies/agentic-second-brain/)Case study [How we deploy private AI](https://www.aigentcy.com/services/private-ai/) [Talk to us about your project](https://www.aigentcy.com/contact/)