The situation
A professional services firm, 1,400 staff across nine offices, doing audit, tax and advisory work. Finance ran a twelve-month review of card spend looking for duplicate SaaS subscriptions and found something else. There are 41 distinct AI tools in the claims, spread across roughly 1,900 expense lines, totalling about AUD$140,000 a year. None of it appears in the IT budget. Six of the tools show up in claims from more than twenty people each. The rest are one or two seats, bought by someone who needed a thing done that afternoon.
Asking around fills in the uncomfortable part. At least nine of the 41 hold client material: meeting transcripts, draft advice, extracts from client ledgers. Three are connected into firm systems rather than sitting outside them. Two of those run through a mailbox integration, and the third through a browser extension with read access to every page a fee earner opens. The firm already has one sanctioned thing, an internal assistant built on Amazon Bedrock and used by about forty people in a single practice group.
Eight months ago the COO sent an email banning AI tools until further notice. Twenty-four of the 41 subscriptions started after that email. The firm’s vendor onboarding process takes about eleven weeks, and the partnership will not run it for a AUD$20-a-month seat licence. Whatever replaces the ban has to be readable by people who do not work in IT. It also has to produce an inventory the firm can show a regulator without flinching.
What actually matters
Everything here turns on disclosure. The register is accurate only when a person who has just found a useful tool tells someone about it, rather than putting it on their card and saying nothing. The ban is the proof. It produced a register containing zero tools and an estate containing 41, and it did that while looking, on paper, like the strictest control available. The measurable version is the gap between what the register says the firm uses and what the card statement says the firm pays for. Every other control in the design sits downstream of closing that gap, because a control applied to an inventory that names none of the 41 protects nothing.
Second is where accountability sits. The AWS shared responsibility model splits security of the cloud, which AWS owns, from security in the cloud, which the customer owns, and the customer’s share changes with the service. For abstracted services such as Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system and the platforms. What stays with the customer is managing the data, including its encryption options, classifying assets, and applying the right permissions. That framing transfers to third-party AI tools, with one difference that runs against the firm. For the 41 bought on personal cards there is no contract at all. The firm holds the client obligation and the professional-body exposure while a vendor it never signed with holds the data. One missing register entry means a client file sitting somewhere no engagement letter contemplated, and no internal policy retrieves it once it has been used for training.
Third, effort has to match what a tool touches rather than what it costs, and the turnaround has to beat the alternative. A diagram generator that never receives an upload and a transcription service holding recordings of audit interviews are not the same risk. Run both through the same eleven-week assessment and neither goes through it. If the sanctioned route is slower than the personal card, the card wins every time, and the firm learns nothing about what people are doing. Turnaround is a design parameter set deliberately, not a number that emerges from however busy the reviewer happens to be.
Fourth, approvals decay and states need owners. An approval is a statement about one vendor at one moment: their retention window, their subprocessor list, whether customer content trains the next model, whether the enterprise tier that carried those commitments is still the tier the firm is on. Vendors change all of those without announcing it, so an entry with no re-review date is a claim the firm cannot support a year later. Blocks decay in the same direction. A tool blocked in early 2026 for having no way to turn off training may be perfectly acceptable now, and a block nobody revisits becomes a rule nobody can explain. Each state needs a person whose name is on it. The register also needs an answer for the state nobody designs, which is not listed at all. Leave that undefined and every reader supplies their own interpretation, which is how the firm got to 41.
What we’ll filter on
- Disclosure. Does the design make a member of staff more likely to declare a tool they are already using, or less?
- Readable criteria. Can a requester read, before asking, what would get their tool approved and what would get it blocked?
- A named owner and a stated turnaround per state. Is there one person accountable for each state, and a published number of days a requester can plan around?
- Expiry. Do approvals and blocks carry a re-review date, so neither stands unexamined for years?
- Resolution for the 41 already running. Does the design have a route for tools in use today, including ones holding client material, rather than starting from an empty catalogue?
The landscape
Six approaches to cataloguing AI tools show up in organisations this size.
Reissuing the ban with enforcement behind it means blocking merchant categories on corporate cards, refusing reimbursement, and adding vendor domains to a web filter. It is fast to announce. It moves consumption rather than stopping it: onto personal devices, onto personal accounts, out of the firm’s sight. It also removes the only thing the firm currently has, which is a group of people willing to say what they use when finance asks.
Discovery only treats the problem as an inventory exercise. Pull card spend, SaaS management data and directory sign-in logs, build the list, publish it, decide nothing. That produces the most honest picture of the estate and no decisions at all, which leaves the nine tools holding client files exactly where they are.
Routing everything through the existing vendor-onboarding queue is the answer procurement usually proposes. It has real criteria and real owners. Eleven weeks for a AUD$20 seat makes the queue a thing to avoid rather than a thing to use, and uniform process applied to non-uniform risk pushes the small end of the estate underground.
A closed allow-list publishes a short catalogue of approved tools and forbids everything else, with no route from outside the list to inside it. It is easy to communicate, and it has the same failure mode as the ban, arriving a step later. A need the list does not cover has nowhere to go, so it goes on a card. The list ages, the gap between it and the work widens, and nobody notices compliance falling away.
A published three-state classification names each tool as approved, blocked, or under evaluation. It publishes the criteria that separate the three and defines the route from one state to the next. Under evaluation is the state that distinguishes it. A request gets somewhere legitimate to sit while a decision is being made, which turns “I need this today” into a register entry rather than a card transaction.
On the AWS side, the mechanism closest to a curated catalogue is AWS Marketplace Private Marketplace. An administrator builds an experience, which AWS describes as a curated catalogue of approved products with custom branding that controls what users in the organisation can procure. That experience is associated with an audience: the whole organisation, an organisational unit, or an individual account. Experiences flow down through the AWS Organizations hierarchy, and the live experience closest to an account governs it, so a default experience can cover the firm while a practice group with different needs gets its own. Products are approved or declined per experience, so the same tool can be available to one audience and declined for another. Product procurement requests are on by default, so a user who reaches a product outside their experience sees a banner with a Request product button. Administrators and requesters both receive events when a request is raised, approved or declined, and those events can be turned into email.
AWS Marketplace Vendor Insights sits alongside it, publishing a security profile for a participating SaaS product across ten control categories. The profile draws on three sources. The seller completes a self-assessment, either the Vendor Insights security self-assessment or a CAIQ response. The seller’s ISO 27001 and SOC 2 Type II audit reports are mapped onto the same control categories. And 25 of the controls carry live evidence from the seller’s own production accounts, so that part of the profile reflects the current configuration rather than the date a questionnaire was signed.
That is a good implementation of an allow-list with a request path, and it covers the part of the estate that flows through AWS procurement. None of the 41 does. Private Marketplace governs what can be bought through AWS Marketplace. It has nothing to say about a browser extension bought on a personal credit card. Treating it as the whole answer confuses the enforcement point with the register.
The framing for the register itself comes from the governance vocabulary the platform side already uses and, more usefully at this altitude, from the AWS Cloud Adoption Framework. AWS CAF groups its capabilities into six perspectives, and Governance is one of them. Among the Governance capabilities is application portfolio management, which turns on keeping an accurate and complete application inventory in order to minimise application sprawl and support application lifecycle planning. Forty-one undeclared AI subscriptions is application sprawl with a shorter procurement cycle and a worse data story. The capability that addresses it is one the firm already has a name for.
Evaluation
Side by side
| Approach | Disclosure | Readable criteria | Owner and turnaround | Expiry | Resolves the 41 |
|---|---|---|---|---|---|
| Reissued ban with enforcement | ✗ | ✗ | ✗ | ✗ | ✗ |
| Discovery only | ✓ | ✗ | ✗ | ✗ | ✗ |
| Vendor-onboarding queue as the only route | ✗ | ✓ | ✓ | ✗ | ✗ |
| Closed allow-list | ✗ | ✗ | ✗ | ✗ | ✗ |
| Private Marketplace experience alone | ✗ | ✗ | ✓ | ✗ | ✗ |
| Three-state register with a fast lane | ✓ | ✓ | ✓ | ✓ | ✓ |
Only one row carries disclosure and resolution together, and those are the two the firm is failing at today. The vendor-onboarding queue and Private Marketplace both score on owner and turnaround, because both have a real request path with a named administrator behind it. Both lose on disclosure, because neither reaches the spending that never touched them. The closed allow-list scores worse than it feels. A catalogue is a list of answers, and without published criteria a requester cannot tell whether their tool would pass, so they do not ask.
Routing a tool into a state
The solution
Publish a three-state register, put a fast lane in front of it, and run an amnesty to load it with the 41 the firm already has.
The entry is the unit of governance, not the tool. Every row carries the tool name, one sentence on what it is for, the state, the named business owner, the decision date, the re-review date, and the data classes permitted. A blocked row also names the substitute a requester should use instead. A row without an owner is a line item nobody has to answer for. Approval attaches to a use, so the same vendor can appear twice: approved for internal drafting, blocked for anything with a client name in it. The condition goes where a fee earner will read it rather than into a policy appendix.
The criteria are published before anyone asks. Three questions decide the lane. Does the tool receive client or personal data at any point? Does it connect into firm systems, meaning a mailbox, a file store, or a browser extension with page access? Is it under AUD$50 a seat on the vendor’s standard terms? A no, no, yes takes the fast lane: two working days, one named reviewer, approved with an explicit no-client-data condition. Anything else takes the standard lane: ten working days, a security and data-protection review, and a partner named as business owner before approval. A requester who reads those three questions can predict their own outcome, which stops the register being experienced as a lottery.
Under evaluation carries a clock and an escalation. A request that passes its stated turnaround escalates to a named person. It does not sit, and it does not auto-block, because an auto-block is the ban rebuilt from parts. The queue is capped. When it is full, the answer is that the reviewer is the constraint, which is a resourcing conversation the firm can have rather than a silence it cannot.
Not listed is defined, in the first line of the register. A tool that is absent is treated as under evaluation and needs a request. Say it explicitly or every reader chooses between “absent means fine” and “absent means forbidden”, and the population splits roughly the way it split before.
Every block names a substitute or a date. The firm’s internal Bedrock assistant covers most of what the transcription and summarisation tools were bought to do. Where nothing internal fits, the block records the date by which the firm will say what does. A block with nowhere to go is a ban with a smaller blast radius, and it produces the same behaviour eight months later.
Enforcement goes where the money moves. Expense policy changes so an AI subscription is reimbursable only against a register entry, which turns the card statement from a discovery tool into a control. Corporate cards get merchant-level rules for the vendors already blocked. For anything procured through AWS, a Private Marketplace experience associated with the organisation root carries the approved products. Product procurement requests stay on, so a user who reaches a product outside the catalogue can request it rather than being stopped there, and the request events go to the register owner. Vendor Insights profiles do part of the standard-lane review for SaaS products that publish one, which is worth checking before commissioning a questionnaire the seller has already answered.
Re-review dates are set at approval. Twelve months for a general approval, six where client data is permitted, and immediately on notice that the vendor has changed its terms, its subprocessors, or its position on training against customer content. Blocked entries carry dates too. Expect a meaningful share of blocks to flip on review as vendors ship enterprise controls. A register where nothing ever moves out of blocked is a register nobody is reading.
An approval does not move accountability to the vendor. The split the shared responsibility model describes narrows the firm’s share as the service becomes more abstracted, and the client obligation stays where it started whatever the vendor’s page promises. The register is also an application inventory. It belongs with the firm’s other inventories under application portfolio management rather than in a security team’s private spreadsheet, and it gets the same treatment for sprawl, ownership and lifecycle as the rest of the estate.
Measure four things monthly. The disclosure gap, meaning AI spend on cards with no matching register entry. Median days to decision in each lane. The share of approved entries past their re-review date. And the count of blocks with no named substitute, which is the leading indicator of the next round of personal-card purchases.
Worked example
The amnesty runs for thirty days. Declaring a tool during the window carries no consequence, including for the nine already holding client material, and the announcement says so rather than implying it. All 41 are declared. Eleven more arrive that nobody in finance knew about, because a few people had been paying personally and never claimed.
A transcription service for client interviews arrives from the audit practice. Gate one is a yes, so it takes the standard lane. The review finds a thirty-day server-side retention window with no way to shorten it, and no data-processing agreement in place. The entry lands as blocked, with the reason written in one sentence and the substitute named. The internal Bedrock assistant already handles summarisation for the practice group next door, and the register records a date for extending it to interview audio. The fourteen seats are cancelled, and a deletion request goes to the vendor, tracked on the entry.
A diagramming tool arrives from a consultant who pastes in bullet points and gets an architecture sketch out. No client data, no connection into firm systems, AUD$18 a seat, standard terms. Fast lane, decided in a day and a half, approved with the condition that nothing identifying a client goes into it. That entry does the most work in the register, because it is the first proof to 1,400 people that asking is faster than not asking.
A research assistant surfaces from the tax team with three years of client memos already uploaded into it. It was bought by someone who left in March, and it is still billing to a card nobody was reconciling. It goes to under evaluation on day one rather than being blocked on sight, because blocking it would end the firm’s access to the account and to the deletion controls inside it. The named owner becomes the tax partner, and the review runs the full ten days. The outcome is a paid enterprise tier with training against customer content disabled, and the memos exported and removed. Same vendor, different answer from the one the fast lane would have given, and the register says why.
Six weeks in, three numbers matter. The card statement now shows three subscriptions with no register entry, against 41 when the review started. Median fast-lane time is under two days. Four requests are sitting past their turnaround in the standard lane, which is the useful signal: the reviewer is the constraint, and it surfaced as a queue length rather than as another year of card spend.
What’s worth remembering
- Shadow AI is a disclosure problem before it is a security problem, so score any design first on whether it makes people more likely to declare what they are already using.
- A transparent classification needs three states and a published route between them, because approved and blocked alone leave a new tool nowhere legitimate to sit while someone decides.
- Every entry needs a named owner, a stated turnaround and a re-review date; an approval with no expiry is a claim about a vendor that stopped being true at some point nobody recorded.
- Define what an unlisted tool means in the first line of the register, or every reader will decide for themselves and you will rebuild the estate you started with.
- A block without a named substitute or a date for one is a ban, and it produces the same behaviour the ban produced.
- AWS Marketplace Private Marketplace experiences, with product procurement requests on and Vendor Insights profiles feeding the review, enforce the register for anything bought through AWS; the personal-card estate needs the expense policy to do that job.