Category: Models. “Approved AI provider” leaves important questions unanswered. Which model? Through which service? With which settings? For which information and purpose? This register makes those distinctions explicit. It is a practical editorial tool for teams that need a decision they can explain later, rather than a logo beside a green tick. Copy the fields and examples freely into your internal working document; no sign-up is needed.
General information, not legal advice. This register does not classify a system, resolve a contractual question or determine regulatory obligations. Adapt it with the relevant business, security, data protection, procurement and legal reviewers. All named organisations, services, models, records and decisions in the examples are fully synthetic. No real provider is assessed or endorsed.
One approval needs several boundaries
Separate the supplier relationship from the model and from the route used to reach it. The same model name might appear in a public chat service, a business workspace and a separately hosted endpoint. Those routes can have different identities, settings and evidence. Record the exact route you assessed. Do not let a familiar model name stand in for a description of where requests go or who operates the service.
Then separate technical access from permitted use. An employee may be able to select a model while still lacking permission to submit a particular file. An approval for public-source summarisation says nothing about confidential case analysis. Make the unit of approval a combination of service, model or deployment identifier, configuration, data class and workflow. This creates more rows than a supplier list, but each row becomes a decision someone can actually apply.
Copy the register fields
REGISTER HEADER Register owner / deputy: [ ] Revision / decision record location: [ ] Who may approve, suspend and withdraw a row: [ ] How staff find the current permitted-use list: [ ] MODEL-USE ROW (repeat) Row ID and decision state: [unassessed / conditional / approved / suspended / withdrawn] Business purpose / workflow owner: [ ] Supplier / contracting entity / service operator: [ ] Service route / endpoint / deployment identifier: [ ] Model identifier / version behaviour / fallback behaviour: [ ] Configuration baseline and change owner: [ ] Permitted users / groups / connected tools: [ ] Permitted input data classes and source restrictions: [ ] Prohibited inputs and excluded uses: [ ] Processing destination evidence and unanswered questions: [ ] Content retention / service logging / model-training settings: [ ] Who controls each setting and evidence of that control: [ ] Quality evaluation scope / failure examples / human review: [ ] Security and data-flow evidence references: [ ] Contract review reference and unresolved terms: [ ] Approval owner / decision rationale / conditions: [ ] Review date / event triggers / expiry rule: [ ] Suspension route / fallback / queued-job treatment: [ ] Evidence access owner and retention decision: [ ] Open item / accountable person / closure evidence: [ ]
Keep evidence references specific enough to retrieve. “Supplier website” is weak; a document title, captured revision, assessed clause and internal evidence location are more useful. Record when a setting was inspected and who can change it. A statement in sales material and an effective tenant setting answer different questions. Where you cannot obtain evidence, record the gap and the resulting restriction rather than inferring a favourable answer.
Three completed synthetic entries
Synthetic context: the invented Cedar Quay Advisory team maintains register CQ-MR-02. “Harbour Text”, “Mesa Reason” and “Local Reed” are invented model labels. Every evidence identifier below is fictional. The states illustrate how a register can distinguish a bounded decision from an unanswered procurement question.
| Model-use row | Decision and evidence | Boundary and next action |
|---|---|---|
| M1: Harbour Text revision H7 through the firm’s dedicated service endpoint. Public-source briefing drafts only; research group only; no connected write tools. | Conditional. Business owner: research lead. Synthetic evidence E-M1-01 covers route settings; E-M1-02 is a recorded public-text evaluation. | No restricted material, external sending or fallback model. Security lead must confirm who can change endpoint settings before broader access is considered. |
| M2: Mesa Reason through an unassessed browser service. Requested for confidential complaints analysis. | Unassessed. Procurement owns unanswered retention and operator questions. No evidence reference supports the requested data class. | Requested use remains unavailable. Requester can use a non-AI review route while evidence is gathered; there is no automatic exception. |
| M3: Local Reed revision L3 on a managed device. Synthetic training exercises only. | Conditional. IT owner records installation package identity and disables unassessed connectors in synthetic evidence E-M3-01. | Local execution alone is insufficient to approve confidential inputs. IT must inspect outbound connections, update behaviour and access to saved conversations. |
Notice that M1 is not a general approval of Harbour Text, and M3 is not a claim that a local model is inherently suitable for every file. The register describes an assessed use boundary. Expanding that boundary creates a new decision, even when the model stays the same. For M2, the absence of a completed assessment is visible; an empty cell does not mean that someone else checked it.
Evaluate the workflow people will use
Use a small set of representative synthetic tasks before approving a purpose. Include incomplete information, conflicting source passages, requests outside the agreed role and questions for which the right response is uncertainty. Define what the human reviewer must verify: source accuracy, missing context, unsupported conclusions and inappropriate disclosure. Save failure examples as well as acceptable outputs. The point is to understand where the workflow needs a person, not to produce a flattering demonstration.
A useful evaluation record states the input class, model identifier, settings, tool access and review method. It also records exclusions. A public-document drafting exercise does not establish suitability for individual eligibility decisions. A text-only evaluation does not cover image inputs or a newly connected retrieval source. Avoid turning a narrow exercise into an organisation-wide “approved model” badge. Keep the exact tested configuration linked to the row.
Write the withdrawal plan before you need it
- Name who can suspend the route and who can restore it. Give each role a deputy and a contact path.
- Describe how new requests are stopped across the routes in scope. Record routes outside your control as coverage gaps.
- Decide what happens to queued and in-flight requests. Stopping new selection does not resolve an already dispatched request.
- Tell staff how to continue essential work. A fallback can be manual; another model needs its own permitted-use decision.
- Preserve the decision and relevant evidence with controlled access. Avoid copying every conversation into the suspension record.
- Define restoration evidence: the issue understood, the affected boundary checked and the decision owner recorded.
Review triggers should include a model alias changing its target, a service operator changing, new retention terms, a new input type, a new connected tool or a significant error in a relied-on output. A calendar reminder is useful, but these changes can occur between reviews. Assign someone to notice them. If the service cannot identify which revision handled a request, record that limitation and decide whether the intended workflow can tolerate it.
Connect the register to daily decisions
Publish a short staff view containing the approved purpose, allowed input class, access route, human checks and reporting contact. Keep detailed contract and security evidence in an appropriately restricted location. Record exceptions as time-limited, named decisions; do not edit the normal row to hide them. When a row is withdrawn, retain its history so an earlier decision can still be explained. The register is useful when both the person doing the work and the person reviewing the decision can find the relevant answer.
Related: model independence as a governance property, the agent approval matrix and the acceptable-use policy starter. Explore the AI workspace vision, workflow needs or all resources.