An enterprise agreement is signed, and the organisation begins behaving as though every use of the tool is now approved. It is the most common governance error we find in AI readiness work, and it is a category error rather than a lapse: the two approvals answer different questions, are owned by different people, and expire on different triggers.
Why this is specific to AI. Conventional software arrives with its purpose built in — a payroll system does payroll, and approving the vendor approved the use in the same breath. A general-purpose model has no intrinsic purpose. The purpose arrives with the prompt, weeks after procurement closed the only gate anyone built.
Plain-English explainer · ISO/IEC 42001:2023 · Reviewed August 2026 — vendor terms and plan tiers change, so verify current documentation
Vendor approval decides whether you may contract with a supplier. Use-case approval decides whether a particular purpose may be pursued — over a stated data class, with a stated consequence, under a stated oversight arrangement, by a named accountable owner. A signed enterprise agreement settles the first question completely and the second one not at all. The failure that follows is predictable enough to schedule. Within weeks of a tenant-wide rollout, someone is ranking job applicants with it, someone else is drafting a customer-facing incident notice with it, and a third person has given an agent write access to a repository that touches payments. None of those decisions was refused. None of them was made. The gate that everyone believes exists closed months earlier, around a question none of them asked. What follows is why the two approvals are structurally different, which uses always need their own decision regardless of vendor status, how to build a two-tier structure that leaves ordinary work alone, what the approval record has to contain, who signs what, when a decision has to be reopened, and — the part almost no public page covers — what an assessor actually asks you to produce.
Key Takeaways
- Vendor approval and use-case approval answer different questions. The first examines a supplier, its contract, its posture and its data handling. The second examines a purpose, its data classes, its consequence and its oversight. Neither substitutes for the other, and only one of them is usually happening.
- The reason this is an AI-specific problem is that a general-purpose model has no built-in purpose. Conventional procurement worked because the tool encoded the use. Here the purpose arrives with the prompt, after every gate has already closed.
- Some uses need their own approval regardless of vendor status: decisions about people, anything a customer or regulator receives unmediated, legal work, financial actions, and any output that reaches effect without a human deciding.
- A two-tier structure only works if the lower tier is genuinely frictionless — standing approval for a published envelope, registration without a queue. If fewer than roughly nine in ten registered uses land there, people will route around the process and you have manufactured shadow AI with your own policy.
- A use-case record is only a control if it names an accountable owner, enumerates data classes in and out, states the consequence class, describes the specific human oversight point rather than asserting a human in the loop, and carries conditions and an expiry.
- Re-approval is triggered from both sides. Your purpose, data, audience or autonomy changes, or the vendor ships a capability, changes a sub-processor or moves a model version. A register with no refusals, no amendments and no retirements over twelve months is not being run.
Two approvals, two different questions
Read the last row first. Each approval has a blind spot that the other one covers, which is the whole reason both have to exist. A vendor file cannot record purpose, because purpose has not been decided yet when the file is written. A use-case record cannot evaluate a supplier, because the person writing it is a recruiter or an engineer rather than a third-party risk analyst.
| Dimension | Vendor approval | Use-case approval |
|---|---|---|
| Question it answers | Is this supplier acceptable to contract with, on these terms, for this class of data? | Is this purpose acceptable to pursue — over this data class, with this consequence, under this oversight, owned by this person? |
| Object of the decision | A company: its security posture, its contract, its sub-processors, its jurisdictions, its incident commitments. | A job of work: what goes in, what comes out, who receives the output, and what happens if the output is wrong. |
| What triggers it | A purchase, a renewal, a new supplier entering the estate, a material change of terms. | Someone wanting to do something new with a tool that is already bought and already on the desk. |
| Who owns it | Security and procurement, with legal on terms and privacy on transfers. Centralised by design. | The accountable owner of the business process, with review proportionate to consequence. Distributed by necessity. |
| What is examined | Assurance artefacts (a SOC 2 report, an ISO/IEC 27001 or 42001 certificate), the data processing agreement and sub-processor list, retention and training terms on the contracted plan tier, breach and incident commitments, processing locations. | Purpose, data classes in and out, whether an output reaches a person or a system unmediated, reversibility, the human oversight point, the evaluation performed before go-live, and the failure mode. |
| Evidence it produces | A vendor file: the review record, the artefacts relied on, the residual risks accepted, the approver and the next review date. | A use-case record: owner, purpose, data classes, consequence class, oversight design, conditions, decision, decider, date and expiry. |
| ISO/IEC 42001 anchor | Annex A.10.2 (allocation of responsibilities) and A.10.3 (suppliers) — the third-party and customer relationship controls. | Annex A.9.2, A.9.3 and A.9.4 (processes for responsible use, objectives for responsible use, intended use of the AI system), with A.5.2 and A.5.4 where impact assessment is engaged. |
| SOC 2 anchor, where AI sits inside the described system | CC9.2 — the entity assesses and manages risks associated with vendors and business partners. | CC3.2 and CC3.4 (identifying risks, and identifying changes that could significantly affect internal control) with CC5.1 for the control activities selected in response. |
| Its blind spot | It cannot see purpose. Nothing in a vendor file records what anyone will actually ask the model to do once the contract is signed. | It cannot see the supplier. A carefully designed use case running on an unvetted vendor is still an unmanaged third-party risk. |
The two rows naming standards are worth dwelling on, because they show that this is not a TCSA invention. ISO/IEC 42001:2023 separates them itself: the supplier and responsibility-allocation controls sit under Annex A.10, while the use controls — A.9.2 processes for responsible use, A.9.3 objectives for responsible use, A.9.4 intended use of the AI system — sit in a different objective entirely, and an organisation can be entirely compliant on one and empty on the other. Where an AI use touches a system covered by a SOC 2 examination, the same split appears as CC9.2 on the vendor side and the risk-identification and change-assessment criteria on the use side.
Software used to carry its purpose with it
Procurement governance was built on an assumption so reliable that nobody wrote it down: the tool encodes the purpose. Approving a payroll system approved payroll processing. Approving a ticketing system approved ticketing. The vendor decision and the use decision were the same decision, made once, at the only moment anyone was paying attention. Every approved-tools list in every organisation is a monument to that assumption.
A general-purpose assistant inverts it. The purchase decides the envelope — which supplier, which tier, which tenancy, which contractual terms — and nothing else. The purpose arrives later, from whoever opens the window, and it can change between one message and the next. The control that used to be implicit in the purchase has to be made explicit somewhere else, or it simply does not exist. That is the entire argument of this page, and everything below is engineering.
Two further things sustain the confusion. The first is that the enterprise tier genuinely feels like a control, and to a real extent it is one: enterprise and consumer tiers generally differ in retention, administrative visibility, audit logging and contractual protection, and moving people onto the enterprise tier is one of the highest- value early moves available. But it is a control over how the supplier handles what you send. It says nothing about what you should send, or what anyone should do with the answer. Note also that the specifics are plan-tier and contract dependent and change over time, which is why the approval record below carries a verification date rather than an assertion.
The second is that the artefact everyone already has is a list of allowed tools, and it has one column. It records that a tool is permitted. It has no column for what the tool is permitted for. When a certification body asks how you satisfy the intended-use control, or a customer asks where AI touches the service they buy, that list cannot answer, because it was never a record of use in the first place. It is a supplier register wearing the name of a use register.
Where vendor status decides nothing
These seven categories need their own approval whatever the supplier, whatever the tier, and whatever was signed. In each case the risk is carried by the purpose rather than by the platform, so nothing in the vendor file moves the answer even slightly.
| Decisions about people | Screening, ranking, shortlisting, promotion, performance, discipline, or anything that changes someone’s standing at work. Regulatory attention here is heavier than anywhere else: New York City Local Law 144 requires an independent bias audit of an automated employment decision tool conducted no more than a year before it is used, a publicly posted summary of the audit results, and notice to candidates at least ten business days before the tool is used on them, including how to request an alternative selection process. The EU AI Act lists employment among the Annex III high-risk areas and places obligations on the deployer, not only the provider — including assigning human oversight to natural persons with the necessary competence, training and authority. Where a decision is based solely on automated processing and produces legal or similarly significant effects, GDPR Article 22 is engaged in its own right. None of that is affected by which supplier you bought from. |
| Anything a customer receives unmediated | Support replies, incident notifications, pricing statements, product claims, contractual answers. The exposure here is rarely privacy. It is that the organisation has made a statement it did not intend to make and may be held to. Breach and incident notification drafting is the sharpest case — the artefact is regulator-facing, time-bound and legally consequential, and the input is by definition incident data. Approve the template and the named approver, not the general ability to write to customers. |
| Legal work | Contract review, redlining, positions on obligations, regulatory analysis. Two separable risks travel together and are usually conflated. The first is what goes in: counterparty confidential material, and in some jurisdictions material that carries privilege. The second is what comes out and whether anyone will rely on it without checking. A use may be safe on the first and unacceptable on the second, which is exactly why the vendor answer settles nothing. |
| Financial actions | Anything that moves money, changes an entitlement, prices something, raises a credit or refund, or writes to a ledger. Reversibility is the test that matters. A wrong summary is embarrassing and correctable, but a wrong payment instruction is an incident with a recovery process attached. Where a use writes to a financial system, the approval question extends into the controls that were already there — segregation of duties, authorisation limits, and the reconciliation that would catch the error. |
| Any consequential automated outcome | The general form of the rule, and the one worth writing into policy: wherever an output reaches effect without a person deciding, the use needs its own approval regardless of data class or vendor. That includes agentic tool use, automatic merge, automatic send, automatic ticket closure, automatic provisioning and automatic escalation. The distinction is not how clever the system is. It is whether a human judgement sits between the output and the consequence. |
| Special-category, regulated and contractually restricted data | Health, biometric, children’s data, financial account data, and — the one most often missed — customer data that your own contracts forbid you from sub-processing or moving between regions. An enterprise agreement with your AI supplier does not amend the agreement you signed with your customer. Where a customer contract names permitted sub-processors, adding a model provider to a workflow that touches their data is a contractual event before it is a technical one. |
| Security and access decisions | Access grants and revocations, security alert triage and closure, fraud and anti-money-laundering dispositions, vulnerability risk acceptance. These are the controls other controls rely on. An assistant that drafts a triage note is a different proposition from one that closes alerts, and only the second changes what the control evidence means when an auditor tests it. |
A caution on the regulatory references above. The EU AI Act’s applicability timetable has been amended since adoption, and United States state law on automated decision-making has moved repeatedly — Colorado’s statute has been delayed and substantially rewritten more than once. Treat the specific dates as things to verify against the current text rather than as settled facts, and design to the durable point instead: consequential automated decisions about people attract obligations somewhere, under some instrument, in most markets you sell into. Our ISO 42001 and EU AI Act comparison covers the relationship between the management system and the statute in more detail.
Five questions that decide the tier
“Consequential” needs a definition somebody can apply in ninety seconds without a meeting. These five questions do that. The highest answer across all five sets the tier, and the routing is deterministic rather than a matter of who happened to read the request.
Whose data goes in?
Public, internal, confidential, personal, special-category, or data your customer contract restricts. The last category is the one people forget, and it is the one that turns a technical decision into a contractual breach.
Whose decision comes out?
Nobody’s, the user’s own work, a colleague’s, a customer’s, or an individual’s rights, livelihood, money or safety. This is the axis that matters most and the one least often written down.
Who receives the output?
The author alone, an internal reader, a customer, a regulator or court, or a system that will act on it. Each step down that list adds a party who cannot check the work.
Can it act?
Read-only, suggests, executes on confirmation, or executes autonomously. Where the answer is either of the last two, enumerate the connectors and permissions on the record — the tool is not the unit of approval, the reach is.
Can the affected person tell, and can they contest it?
If the answer is no to both and the outcome is adverse, you are in the highest tier regardless of everything above it, and you have a disclosure question to answer before you have a technical one.
One counter-intuitive result is worth stating explicitly, because it is where most home-made matrices go wrong: consequence dominates data class. A use running on entirely public data that ends in an automated adverse decision about a person sits higher than a use running on confidential internal data that produces a draft one person reads and edits. Matrices built on data sensitivity alone route the first one to self-service and the second one to a committee, which is exactly backwards.
A two-tier approval that stays out of the way
Two tiers, not five. Tier 1 is standing approval for a published envelope of ordinary work, registered without a queue. Tier 2 is a decision made by a named person before the use starts, with an escalation path inside it for the small set that needs an impact assessment. Any design with more tiers than this becomes a routing argument, and routing arguments are how governance loses.
| Dimension | Tier 1 — standing approval | Tier 2 — reviewed approval |
|---|---|---|
| What it covers | A published envelope of ordinary work: drafting, summarising, translating, research, code assistance, meeting notes — where the output is a draft that a person reads and edits before anything happens. | Everything outside the envelope. Any use touching a restricted data class, producing a consequential outcome, reaching a customer or regulator unmediated, or giving a system the ability to act. |
| Data classes permitted | Public and internal data, on the sanctioned platform and contracted tenancy only. No personal data beyond ordinary workplace contact details, no customer content, no credentials, no special-category data. | Anything above that line, enumerated on the record rather than described as “internal data”. Special-category, regulated and contractually restricted classes escalate within Tier 2. |
| Consequence ceiling | A person reviews and edits the output before it has any effect, and a wrong output costs rework. If the worst realistic outcome is a bad draft, it belongs here. | A person or a system acts on the output, or the output reaches someone outside the team unaltered. If the worst realistic outcome needs a remediation plan, it belongs here. |
| Who decides | Nobody. Approval is standing and was granted once when the envelope was published. The individual registers the use, and their line manager is the accountable owner. | A named reviewer with a stated deputy — in practice security plus the process owner. People-affecting, money-moving, regulator-facing and autonomous uses escalate to the AI governance forum with legal and privacy present. |
| What must happen before use | A register entry: owner, one-sentence purpose, platform and tier, data classes, and confirmation the use sits inside the envelope. Two minutes, no queue, no waiting. | A submitted record, a decision, and written conditions. Where the use affects individuals, an AI system impact assessment before deployment, and a documented human oversight design. |
| Turnaround | Immediate. The register entry is a notification, not a request. | A published service level — five working days is achievable and is what we recommend committing to. An unpublished turnaround is the thing people route around. |
| Record retained | The register entry with a creation date and the envelope version it was registered against. | The full approval record, the impact assessment where required, the conditions, the decision with decider and date, and the expiry. |
| Expiry and review | Annual attestation by the owner that the use is unchanged and still needed, plus automatic retirement when the owner leaves. | A stated expiry — twelve months for a steady-state use, sixty to ninety days for a pilot. Expiry means positive re-approval, and silence retires the use. |
| Health check | If fewer than roughly nine in ten registered uses land here, the envelope is drawn too tightly and people will work around it. | If nothing has ever been refused or made conditional, the tier is decorative and an assessor will say so. |
The frictionless requirement is not a concession to convenience. It is the control. A queue in front of ordinary work does not stop the work, it moves the work somewhere you cannot see — a personal account, a browser extension, a phone. Governance that manufactures its own shadow AI has produced a worse outcome than having no process at all, because it has also produced a register that is confidently wrong. Publish the envelope, publish the Tier 2 turnaround, and measure both.
The same platform, approved and refused
An illustrative composite, drawn from the patterns we see in readiness work rather than from any single organisation: a 400-person B2B software company with financial-services customers and both EU and Indian entities. Watch what stays constant across every row — the supplier, the contract, the tier and the tenancy — and what changes.
| Platform | Use proposed | Decision | The reason — never about the vendor |
|---|---|---|---|
| Microsoft 365 Copilot · enterprise tenancy | Meeting summarisation and document drafting for internal readers, grounded in tenant content. | Approved — Tier 1, registered 4 February 2026 | Inside the published envelope. Output is a draft, the audience is the author and their team, nothing acts on it, and no restricted data class is involved. No reviewer, no queue, no waiting. |
| Microsoft 365 Copilot · same tenancy, same licence, same agreement | Scoring and ranking job applications held in a recruitment library, with the ranking used to decide who is interviewed. | Refused as proposed — 19 February 2026 | Nothing about the supplier was in question, and the vendor file did not change by a word. The refusal rested on the use: an adverse ranked outcome about individuals, no documented oversight design, no evaluation of the ranking against a representative sample, no candidate notice, and no answer to how a rejected applicant would contest the result. |
| Microsoft 365 Copilot · re-submitted narrower | Assistive summarisation of applications for recruiters, with no scoring and no ranking, and the recruiter recording an independent reason for every rejection. | Approved with conditions — Tier 2, 11 March 2026, expires 11 March 2027 | The consequential step was removed rather than supervised. Conditions: summaries are advisory and marked as such, application content stays inside the recruitment workspace, a sample of summaries is checked monthly against source documents, and any move toward scoring is a new approval rather than an amendment. |
| ChatGPT Enterprise | Campaign and marketing drafting on public and internal marketing material. | Approved — Tier 1 | Envelope work. The only condition that applies is the standing one: published claims go through the existing marketing review, which was already a control before any of this. |
| ChatGPT Enterprise · same agreement | Drafting the customer notification for a live security incident. | Refused as proposed — 2 April 2026 | Regulator-facing, time-bound and legally consequential, with incident facts as the input. Approved in narrower form on 16 April: drafting from a pre-approved notification template only, counsel named as the approver before any send, and no incident specifics entered until the incident has been classified. |
| Coding assistants — GitHub Copilot, Cursor, Claude Code | Suggestion and review assistance across product repositories. | Approved — Tier 1 | The existing change-management control does the work. Every merge still needs an approving review from someone other than the author, so the assistant changes how code is written and not how it reaches production. |
| The same assistants, running as an agent | An agent holding repository write access and CI credentials, operating unattended in the payments service. | Refused — escalated, then approved bounded | A reach question, not a vendor question. Approved in a bounded form: the same repositories, non-author human approval still required on every merge, no production credentials, connector set enumerated on the record, and elevation time-bound. Excessive Agency sits at LLM03 in the OWASP GenAI LLM Top 10 2026 — it was LLM06 in the 2025 edition — and this is precisely its shape. |
The same organisation, five months
| Starting position | January 2026 | A 400-person B2B software company with financial-services customers and EU and Indian entities. Enterprise agreements signed for a tenant-wide Microsoft 365 Copilot rollout and for ChatGPT Enterprise. The only governance artefact is an approved-tools list with two rows on it. Nobody can say what either tool is being used for. |
| Move 1 | 4 February 2026 | The Tier 1 envelope is published and the use-case register opens. Registration takes two minutes and grants the seat. In the first fortnight 61 uses are registered across nine platforms, and 55 sit inside the envelope and are live the moment they are entered. |
| Move 2 | 19 February – 11 March | CV scoring is refused as proposed, re-submitted without the scoring step, and approved on conditions with a twelve-month expiry. The vendor file is not touched at any point in the exchange, because nothing about the supplier was ever the question. |
| Move 3 | 2 – 16 April | Incident-notification drafting is refused, then approved in a narrower form: template-based, counsel as named approver, no incident specifics entered before classification. The refusal takes ten days, and the narrower approval takes four. |
| Move 4 | 6 May 2026 | The first monthly reconciliation. The register shows nine platforms, but the identity provider shows fourteen applications holding OAuth grants against the corporate directory. Of the five unmatched, two are retired, two are registered retrospectively with owners, and one turns out to be an embedded feature of a CRM bought in 2023 that nobody had ever thought of as AI. |
| Move 5 | 15 June 2026 | A tenancy-level toggle would let an assistant send mail on a user’s behalf. Under the change-watch rule it stays off while the four affected use cases are reviewed. Two are amended, one is re-approved unchanged, one is retired. Total elapsed time: eight days, none of it in an emergency. |
Two things in that sequence are worth extracting. The first is that the vendor file was never opened during any of the refusals — nothing about Microsoft, OpenAI, GitHub or Anthropic was ever the question, and treating those refusals as vendor problems would have produced an argument with procurement instead of a decision. The second is the 6 May reconciliation. A self-declared register cannot establish its own completeness. The gap between nine registered platforms and fourteen applications holding directory grants is not a failure of the register, it is the register working, and the CRM feature nobody thought of as AI is the single most representative finding in the whole exercise.
What a use-case approval has to contain
Sixteen fields, most of them a sentence long. The third column is the one to read if you are deciding what to cut: it is why each field is asked for, which is usually a question somebody will put to you later with less patience than we are putting it now.
| Field | What good looks like | Why it is asked for |
|---|---|---|
| Use-case identifier and title | A stable identifier that survives renaming, and a title a stranger can understand without asking. | The identifier is what evidence, incidents and re-approvals attach to. Renaming a use case without one silently breaks its history. |
| Accountable owner | A named person who owns the business process, not the tool. Their manager where the use is consequential. | “IT owns it” is the answer that produces an unowned use case. An assessor will ask who would be answerable if the output caused harm, and expects a name. |
| Business purpose, in one checkable sentence | “Summarise inbound support tickets for the agent handling them.” Specific enough that you could tell whether it was being done. | “Improve support efficiency” cannot be approved, refused or tested, because nothing would contradict it. Purpose is the field the whole record hangs off. |
| Platform, plan tier and tenancy | The licence actually in use, the tenancy or workspace, and the region where processing is contracted to occur. | Consumer and enterprise tiers generally differ in retention, administrative visibility, audit logging and contractual protection. The tier is part of the approval, not a detail. |
| Data classes in | Enumerated: which categories, whose data, and whether any of it arrives from a customer environment. | This is the field that determines whether a customer contract or a privacy notice is engaged. “Internal data” hides exactly the cases that matter. |
| Data classes out and destination | What the output contains, where it is stored, who reads it, and whether it is retained as a record. | Outputs become records. A summary of a personal file is itself personal data, and it inherits the retention and access obligations of what it summarises. |
| Whether inputs leave the contracted tenancy, and the date that was verified | A statement of the position as documented on your plan tier, the link to the documentation reviewed, and the date of the check. | This is the most volatile field on the record. Terms, defaults and plan tiers change. An unverified assertion made eighteen months ago is not evidence of anything. |
| Retention and model-training position on this tier | Recorded the same way: what the current documentation and contract say, checked on a date, with a re-check scheduled. | Assessors and enterprise buyers both ask. The defensible answer names the source and the date rather than repeating a claim from a sales conversation. |
| Consequence class | The highest of the routing answers, written down: advisory, influential, decisional, or autonomous. | It is the field that sets the tier, the oversight requirement and the expiry. Recording it makes the routing decision auditable rather than a matter of who happened to review it. |
| Human oversight point | The named role, the specific moment in the process, what that person is able to change, and what evidence the review leaves behind. | “Human in the loop” is a slogan, not a design. EU AI Act Article 26 asks deployers of high-risk systems to assign oversight to natural persons with the necessary competence, training, authority and support — all four words do work. |
| Evaluation performed before go-live | What was tested, on what sample, against what acceptance threshold, by whom, with the result. For people-affecting uses, the fairness testing and who performed it. | Without this the approval is an opinion. It is also the field that lets you re-run the same test after a model version change and see whether anything moved. |
| Failure mode, detection and reversal | What a wrong output does, how anyone would notice, how it is undone, who is told, and within what time. | This is the field that distinguishes a use that can be approved quickly from one that cannot. Irreversibility, not sophistication, is what makes a use case hard. |
| Conditions of approval | The specific constraints that made the answer yes, written as things someone could check. | An approval with no conditions is rarely a decision — it is usually a rubber stamp with a date on it, and it reads that way to an assessor. |
| Decision, decider, date, expiry | Who decided, when, on what basis, and when the decision stops being valid. The decider is never the requester. | Approval dated after go-live, or approval where requester and approver are the same person, is the most common single defect we find in AI use registers. |
| Re-approval triggers, listed on the record | The specific changes that would reopen this decision, named on the record rather than left in a policy nobody reads. | Triggers written on the record are the only ones people actually notice. A trigger list in a policy document is a trigger list nobody applies. |
| Disclosure position | Whether affected people are told AI is involved, how, and — where relevant — how they contest or appeal the outcome. | Transparency obligations attach to specific uses, not to the tool. It is also the field a customer questionnaire increasingly asks about directly. |
Where a use affects individuals, the record is accompanied rather than replaced by an AI system impact assessment. ISO/IEC 42001 requires an organisation to assess the potential consequences of its AI systems for individuals and groups, and ISO/IEC 42005:2025 provides a methodology for performing that assessment. It is a different instrument from a data protection impact assessment and from the organisation-facing risk assessment — a distinction we set out at length in AI risk assessment versus AI impact assessment. Producing one and filing it under the other is the most common reason an assessor asks for a document that management believes it has already given them.
Who approves what
Most stalled AI governance programmes are stalled on this table rather than on any technical question. Note the pattern: security owns the supplier, the business owns the purpose, and the forum exists to decide the small number of cases where those two answers point in different directions.
| Decision | Who decides | Who must be consulted | Recorded where |
|---|---|---|---|
| Whether the organisation may contract with the supplier at all | Security, on a documented vendor review | Legal on terms, privacy on transfers and sub-processors, the requesting business owner on need | Vendor file, with a next-review date |
| Which plan tier, tenancy and administrative configuration are permitted | Security with IT | Privacy where retention or region differs by tier | Vendor file and the published envelope |
| What the Tier 1 envelope covers | The AI governance forum, once, and reviewed on a stated cadence | Legal, privacy, security, and the functions whose work sits inside it | Published policy with a version number |
| Whether a Tier 1 use may proceed | Nobody — standing approval. The individual registers it | Line manager is the accountable owner and is notified | Use-case register |
| Whether a use outside the envelope may proceed | The named Tier 2 reviewer — in practice security with the process owner | Privacy where personal data is involved, legal where a contract or a regulator is | Use-case approval record with conditions and expiry |
| Whether a use that affects individuals may proceed | The AI governance forum | HR or the owning function, legal, privacy, and the impact assessment author | Approval record plus the AI system impact assessment |
| Whether an output may reach a customer or regulator unmediated | The function that owns the relationship, with legal for regulated content | Security where the content concerns an incident | Approval record, naming the approver of each send where required |
| Whether an agent may hold credentials and take action | Security jointly with the system owner | The control owners whose controls the agent would touch | Approval record with the connector and permission set enumerated |
| Whether a use continues after a vendor capability change | The original approver, positively — silence is not renewal | The change-watch owner who raised it | An amendment on the existing record, dated |
| Whether to accept a residual risk that cannot be mitigated | The executive accountable for the function, with board visibility where material | The AI governance forum, which frames the options rather than deciding | Risk register entry cross-referenced to the use-case identifier |
| What TCSA decides | Nothing. TCSA designs the structure, drafts the records and prepares the evidence | Throughout — as an adviser, never as an approver of your uses | Engagement documentation. Certificates are issued by accredited certification bodies and SOC reports by licensed CPA firms |
A note on roles, because the vocabulary matters when you write this into a policy. ISO/IEC 42001 expects responsibilities across the AI supply chain to be allocated explicitly, and a company that only buys and uses AI still holds a substantial set of them — the deployer obligations in the EU AI Act make the same point from the legal side. Where you need help deciding which role you are actually occupying for a given system, our note on AI roles under ISO 42001 works through the provider, deployer and wrapper cases. Where the organisation has no internal owner senior enough to hold the forum, a fractional CISO or DPO engagement is the usual arrangement.
What an assessor actually requests
Three audiences ask, and they ask in the same order: a certification body auditing an AI management system, a licensed CPA firm examining controls where AI now sits inside the described system, and an enterprise customer’s security review. The requests below are what those conversations actually consist of, and the third column is where most first-year programmes lose time.
| What is requested | What satisfies it | What gets rejected |
|---|---|---|
| The complete inventory of AI use cases in operation during the period | The register exported with a run date and a record count, reconciled against at least two independent sources — the identity provider’s application and OAuth grant list, sign-in logs for AI destinations, the admin consoles of each sanctioned platform, the card and expense ledger, the SaaS management tool, and the installed-application list on your code repositories. Differences are listed and dispositioned rather than removed. | A register with no export date and no counts. A list assembled during fieldwork. A register whose newest entry predates a capability everyone in the building is visibly using. Any inventory that cannot establish its own completeness, which is every self-declared list not reconciled to something the users do not control. |
| The approval records for a selection of registered uses | For each selection: the record, the decision, the decider, a date that precedes first use, the conditions attached, and the expiry. Where the population of Tier 2 approvals is small — and in the first year it usually is — expect it to be tested in full rather than sampled. | An approval dated after go-live. An approval where requester and approver are the same account. “Approved at the AI committee” with no minute naming the item. A record with no conditions and no expiry, which is a note rather than a decision. |
| The impact assessment for a use that affects individuals | An assessment following a stated methodology — ISO/IEC 42005:2025 provides one for AI system impact assessment — naming the affected groups, the potential harms, the oversight measures and what happens if a risk materialises. Dated before deployment and reviewed by someone other than its author. | A single row in a risk register. A data protection impact assessment offered in its place: a DPIA answers a data protection question and an AI system impact assessment answers a decision-quality and affected-persons question, and neither substitutes for the other. |
| Evidence that the human oversight actually operated | System-generated review records with reviewer identity, timestamp and outcome. The proportion of outputs amended or rejected. And at least one instance where the reviewer overrode the system and the record shows what happened next. | A policy stating that a human reviews everything. A reviewer whose throughput makes genuine review implausible — an assessor can and does divide volume by hours. Sign-off with no name or no date. |
| Evidence of what happened when the vendor changed something | A change-watch record showing what was monitored and by whom, a dated assessment of the change against the affected use cases, and either a re-approval or a recorded decision that none was needed. | Nothing at all, which is the usual answer and the one that converts a good register into a stale one. Also rejected: a screenshot of the vendor’s current documentation offered as evidence about a period that closed months ago. |
| Evidence that the register is used rather than merely kept | Entries retired, conditions enforced, uses suspended after an incident, and at least one refusal. A register that has changed shape over the period is a register somebody is running. | Twelve months of approvals with no refusals, no conditions and no retirements. It invites the same question as any review that has never found anything, which is whether the control is performed at all. |
The population problem, stated plainly
Every one of those requests depends on a population, and the population here has a property that makes it harder than most: it is self-declared. A list of user access grants comes out of a system that users do not control. A list of AI use cases comes out of people telling you what they are doing. That is why the reconciliation sources matter more than the register format, and why we treat the monthly reconciliation as the actual control with the register as its output. The same completeness reasoning applies here as anywhere else in an examination — the underlying principles are set out in our note on what auditors accept as evidence.
On sample sizes, be realistic about the arithmetic. In a first year, the population of Tier 2 approvals is frequently between five and twenty. Populations that small are normally tested in full rather than sampled, which means every defect is a known defect rather than a projected one: one approval dated after go-live in a population of eight is not a rounding error, it is a twelve-and-a-half per cent deviation with nothing to absorb it. The sampling mechanics are the same ones that make small-population controls unforgiving everywhere else.
One boundary worth stating, since it comes up in every kickoff. TCSA designs this structure, drafts the records, builds the reconciliation and prepares the evidence. TCSA does not certify, attest, audit or sign. ISO/IEC 42001 certificates are issued by accredited certification bodies, and SOC reports are issued by licensed CPA firms under the attestation standards. The separation is the reason the evidence is worth anything.
Re-approval triggers, from both sides
An approval is a decision about a state of the world, and the world moves on both sides of the contract. Half of these triggers come from you and half arrive from the vendor without asking, which is why one named person needs to own watching for the second kind.
| Trigger | Where it comes from | Required response |
|---|---|---|
| Purpose changes — assistive becomes decisional | Your side | A new Tier 2 decision before the change ships. This is the single most common uncontrolled drift: the summary that “people started relying on”. |
| Data class widens | Your side | Re-approval. Where the new class is special-category, regulated or restricted by a customer contract, escalate and check the customer agreement before the technical work. |
| Output audience changes — internal becomes customer-facing or regulator-facing | Your side | Re-approval with legal named on the record, and an approver identified for each send where the content is regulated. |
| Autonomy increases — the tool gains the ability to act, or a connector is added | Both sides | Re-approval, with the connector and permission set enumerated again. Treat a new connector as a new use case rather than an amendment. |
| Volume or population changes materially — pilot to all applicants | Your side | Re-approval, and re-test the oversight design at the new volume. Oversight that worked for forty items a week frequently does not survive four hundred. |
| Vendor ships a capability change or auto-enables a feature | Vendor side | Assess within the stated change-watch window. Tenancy-level toggles stay off until the affected use cases have been reviewed. |
| Plan tier, tenancy, processing region or sub-processor changes | Vendor side | The vendor review reopens, and every use case whose approval carried a residency or sub-processing condition is re-approved or suspended. |
| Model version changes in a way that could alter behaviour | Vendor side | Re-run the pre-go-live evaluation on the same test set and compare. This is the return on having written down what was tested the first time. |
| A new obligation or customer clause affects the class of use | External | Legal-triggered review of every use case in that class, not only the one that prompted the question. |
| An incident, a complaint, or an oversight failure involving the use | Either side | Suspend, review, then re-approve, amend or retire. The decision and its basis go on the same record. |
| Expiry reached | Calendar | Positive re-approval by the original approver or their successor. Silence retires the use — that is what makes the expiry real. |
| The owner leaves or changes role | Your side | Re-assign within a stated window or suspend. An unowned use case is an unapproved one. |
The trigger nobody implements is the last one but one: expiry meaning positive re-approval, with silence retiring the use. It feels bureaucratic until the first audit, at which point it is the only mechanism that distinguishes a register of decisions from a register of things somebody once said yes to.
The edges that generate the real questions
The structure above handles the straightforward eighty per cent. These nine are where the arguments happen, and where a policy written in the abstract stops being useful.
The capability that arrived without a decision
Platform vendors ship new abilities into existing licences, and some arrive enabled. A use approved when the tool could only summarise is a materially different use once the tool can send, schedule, browse or act. The workable answer is a named change-watch owner, a stated window to assess vendor release notes, and a default that tenancy-level capability toggles stay off until the affected use cases have been reviewed. This looks like excessive caution right up until the first assistant quietly gains the ability to send mail on a user’s behalf.
Agents, plugins and MCP servers
Approving a tool is not approving its reach. Two decisions live here and only one of them is usually made: what the agent may read, and what it may do. The second is where the risk is. The rule that survives contact with engineering is to approve the connector and permission set explicitly, enumerate it on the record, and treat any change to that set as a re-approval trigger. An agent whose tools can be extended at runtime by whoever is using it has not been approved in any meaningful sense.
Model routing and sub-processors underneath the vendor
Your supplier may serve requests from a model, a sub-processor or a region you never evaluated, and may change that without telling you unless the contract requires it. This is a vendor question that reaches back and reopens use-case decisions wherever residency or sub-processing was a condition of approval. The two mitigations that work are a contractual notification commitment on sub-processor change, and a named person subscribed to the vendor’s change feed whose job is to ask which of your use cases just changed.
AI embedded in software you already bought
The CRM ships a summariser. The ticketing tool ships suggested replies. The HR platform adds candidate matching. Nobody procured AI, there is no new supplier, no new invoice and no procurement event, so no gate fires — and this is the single largest source of unregistered use cases in most estates. The remedy is unglamorous: at each vendor’s annual review, ask what AI capability the product has gained since the last one, and register the answers as uses in their own right.
Personal accounts and the consumer tier
An employee pasting into a personal account sits outside both approvals and outside every contractual protection you negotiated. Policy language alone does not touch this. The controls that do are technical and the sequencing matters. Make the sanctioned path fast and obviously better first, then enforce. Enforcement before there is a good sanctioned path produces concealment rather than compliance, which is the subject of a separate discussion about shadow AI.
The oversight that is not oversight
A reviewer approving two hundred outputs an hour is not exercising judgement, and the arithmetic is available to anyone who asks for the volumes. Automation bias is real and well documented: people defer to a confident-looking output, particularly under time pressure. If the throughput makes review implausible, either the oversight design is wrong or the claim is. The fix is usually to reduce what is reviewed — sample deliberately, review exceptions in full — rather than to keep asserting universal review nobody performs.
The pilot that became production
A use approved as a two-week experiment with ten users and no expiry is, eighteen months later, a production dependency that has never been assessed at its current scale or consequence. Expiry dates exist for this. Pilots get sixty to ninety days and an explicit statement of what would have to be true to move to steady state, including a re-test of the oversight design at production volume rather than at pilot volume.
One use, two jurisdictions
A use approved for one entity’s data is not automatically approved for another’s. A customer contract may forbid processing outside a named region. India’s DPDP Act brings its own notice and consent architecture for personal data. An EU deployment may engage obligations that a US one does not. The record should state the jurisdictions and entities the approval covers, rather than the tool’s global availability, and a new jurisdiction should be a re-approval rather than an assumption.
Who approves the governance function’s own uses
The team running the register will want to use these tools too, sometimes on the register itself. The same rule applies, and the honest arrangement is that their Tier 2 submissions are decided by someone outside the function — internal audit, a second executive, or a named external adviser. A governance function that approves its own consequential uses has the same defect it exists to prevent.
What gets pushed back on and the answer
Some of these come from your own engineering leadership and some from a buyer’s security team. They arrive in roughly this order, and in every case the useful reply is more specific rather than more emphatic.
“We signed an enterprise agreement. We are covered.”
The agreement covers what it says it covers, which is the supplier relationship: terms, retention position, security commitments, sub-processors, incident handling, and in most cases a materially better posture than the consumer tier. What it does not do is decide whether screening applicants, drafting a regulator-facing notice, or letting an agent act on a payments repository is something the organisation should do. Those questions are not about the supplier, and no clause in the contract answers them. Ask the person making the claim which paragraph decides the purpose. There is not one.
“This will slow every team down.”
It should not, and if it does the design is wrong rather than the principle. The whole point of the two-tier structure is that ordinary work has standing approval and no queue in front of it: registering a Tier 1 use is a notification, not a request. Two numbers tell you whether it is working — the proportion of registered uses landing in Tier 1, which should be around nine in ten, and the actual turnaround on Tier 2 against the published service level. Publish both. A process people can predict is one they use.
“The vendor says our data is not used for training, so there is no risk.”
Two separate problems with that sentence. First, training is one question among several — retention, human review for abuse monitoring, sub-processors, processing region, incident commitments — and the answer is a contractual position on a specific plan tier rather than a property of the technology, so it needs a verified date and a scheduled re-check rather than a remembered assurance. Second, even where the answer is exactly what you want, it governs what happens to the input. Use-case approval governs the output: whether anyone should rely on it, and what happens when it is wrong.
“We are not high-risk under the EU AI Act, so none of this applies.”
Classification decides one specific statutory obligation set. It does not decide what your customers ask in security reviews, what your certification body examines, or what your own risk appetite should be. It is also worth being precise about who is bound: the AI Act places obligations on deployers as well as providers, and a company that only buys and uses AI is a deployer. The applicability timetable has been amended since the Act was adopted, so check the current consolidated text and your own classification rather than either assuming or dismissing.
“Our data processing agreement covers it.”
A DPA governs how a processor handles personal data on your instructions. It is necessary and it is not the same question. It does not decide whether the purpose is one you should pursue, whether the output may be relied upon for a decision, whether an affected person is told, or whether they can contest the result. It also does not reach the uses that involve no personal data at all and are still consequential — pricing, contractual positions, code that moves money.
“Nobody will keep the register current.”
True, if the register is a spreadsheet that exists in parallel to how people actually get access. It stays current when registration is the path to the seat: the licence is issued on registration, the entry carries the owner, and a monthly reconciliation against the identity provider’s application and grant list surfaces anything registered nowhere. Currency is a plumbing problem rather than a discipline problem, and every organisation we have seen solve it solved it by making the register load-bearing rather than by asking people more firmly.
“You are asking us to approve every prompt.”
No. What is approved is a class of use, once, and inside the envelope there is no approval step at all. A marketer drafting copy, an engineer asking about a stack trace and an analyst summarising a report are all covered by a decision made months earlier. If your process feels like prompt approval, the envelope has been written too narrowly — usually because it was drafted defensively by people who will not be using it. Draft it with the functions that will.
“Our security questionnaire only asks whether we use AI.”
For now. The direction of travel in enterprise reviews is toward asking where AI is used in the provision of the service, what data it touches, and whether a human decides. That question cannot be answered from a supplier list, because a supplier list does not know what anyone did with the tool. It can be answered from a use-case register in an afternoon. The register is a governance artefact that happens to also be the fastest route through a procurement review.
If AI use has entered a system already covered by an examination, the questionnaire conversation and the report conversation start to converge — see SOC 2 and security questionnaires for how the two are usually reconciled, and vendor SOC 2 requirements for the supplier half of the same problem.
Frequently Asked Questions
What is the difference between vendor approval and AI use-case approval?
We signed an enterprise agreement. Is that not approval to use the tool?
Which AI uses always need their own approval?
How do we approve use cases without slowing everyone down?
What should an AI use-case approval record contain?
Who should approve AI use cases?
When does an AI use case need re-approval?
Does ISO 42001 require use-case approval specifically?
Is an AI impact assessment the same as a DPIA?
How do auditors test that use-case approval actually operated?
Does using AI break our existing SOC 2 report?
Sources for this page
- OWASP GenAI Security Project — Top 10 for LLM Applications, 2026 edition (Excessive Agency at LLM03, which was LLM06 in the 2025 edition)
- ISO — ISO/IEC 42001:2023, artificial intelligence management system. Clause 6.1.4 defines the AI system impact assessment process, and clause 8.4 requires it to be performed and its results retained. ISO/IEC 42005:2025 gives the methodology.
- European Commission — regulatory framework for AI, covering Regulation (EU) 2024/1689 and its subsequent amendments to the applicability timetable
- NYC Department of Consumer and Worker Protection — automated employment decision tools (Local Law 144): bias audit, published summary and candidate notice
- Colorado General Assembly — SB24-205, Consumer Protections for Artificial Intelligence (the original statute, since repealed)
- Colorado General Assembly — SB26-189, Automated Decision-Making Technology (the repealing and reenacting statute)
References checked August 2026. Three of these move faster than the rest of the page: the OWASP list renumbers between editions, the EU AI Act’s applicability timetable has already been amended once, and United States state law on automated decisions is being rewritten as it is litigated. Cite the edition and the date, and confirm the current text before relying on anything quoted here. Vendor plan tiers, retention defaults and tenancy controls change on their own schedule — verify those in the supplier’s current documentation rather than against the examples above.
Related Reading
The Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreWhen Does a Tool Become an AI Agent?
The four properties that move something from assistant to agent — and why the product label tells you nothing.
Read moreBuilding an AI System and Agent Inventory
What belongs in it, the fields that make it useful, and why discovery tooling alone is not enough.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more