The situation
A logistics company of about 200 staff moves palletised freight between depots in three states. Four AI uses have appeared inside a month, none of them planned together, none of them by the same people.
Dispatchers have started pasting customer emails into a free public chatbot to draft replies. Nobody approved it; a manager noticed it during a screen share. Separately, the transport management system the company licenses has switched on an AI summarisation feature in its latest release, on by default, condensing delivery exception notes for depot managers. Two developers have built an internal assistant on Amazon Bedrock over the driver handbook, the depot procedures and the dangerous-goods rules. It works in staging, and the operations director wants it on drivers’ phones before Christmas. The same two developers have fine-tuned a smaller model on four years of consignment notes so it can classify why a delivery failed. That classification already feeds a weekly report the board reads.
The chief operating officer has given one person, the operations manager who used to run quality, six weeks to put governance in place before any of it goes further. There is no budget for an external audit and no appetite for a programme that stops the work. The board wants a one-page answer to “are we allowed to do this”.
What actually matters
Governance here means the organisational machinery around AI use: what is written down, who reviews what, when the review happens again, and what the company tells the people affected. The exam guide calls the routines an organisation commits to its governance protocols, and following them is a different job from writing them. A policy nobody is reviewed against is a document rather than a control, and a review board with no calendar entry is an intention.
How much governance a use needs follows from how much of it the company actually owns. When a dispatcher pastes text into a public chatbot, nearly every technical control belongs to somebody else, and the only levers the company holds are who may use it and what may go into it. When the developers fine-tune a model on consignment notes, the training data, the resulting weights, the prompts, the outputs and the evaluation are all theirs to run or to skip. Sorting a use by ownership before choosing its review stops both of the common failures: a heavyweight sign-off on something nobody here can change, and a wave-through on something the company built end to end.
Cadence follows change. A repeat review is worth scheduling only when something could plausibly differ by the time it comes round. A vendor ships a new model version. A retrieval corpus grows every night. A fine-tune drifts as the freight mix changes. In each case the thing that was approved is not the thing running six months later. A system whose model, prompts and data are all frozen can sit on a slow annual cycle. One where the vendor can swap the model underneath you without an announcement cannot, and the trigger for that review is the vendor’s release note rather than a date.
Who does the reviewing is a cost decision as much as a rigour one, and the cost is mostly calendar time. Sending everything to a cross-functional board turns the board into a queue, and a queue is what people route around. Sending everything to a self-assessment checklist means the one use that could reach a customer gets the same attention as a summariser nobody outside the depot ever sees. All of it rests on people knowing the rules exist. A dispatcher who has never been told that customer addresses may not go into a public chatbot has not broken a policy. They have not met one.
What we’ll filter on
- How much of the stack do we own? Everything from “we chose to use it” to “we trained it” changes which controls are ours to run.
- What can change underneath us without anyone here doing anything? The model version, the vendor’s terms, the corpus, the business the fine-tune was trained on.
- Who reads the output, and does the effect leave the company? An internal summary and a message to a customer carry different consequences for the same mistake.
- What would we have to show somebody in a year? A decision with no written record is one that has to be defended from memory.
- Who has to be trained before touching it, and does that training exist yet?
The landscape
A governance programme is assembled out of six pieces. None of them is a service you switch on.
Policies
A policy states what is permitted, what needs approval, and what is prohibited. Three lists, written for the people doing the work and in their language. “Do not put sensitive data into AI tools” fails at a depot; “do not put customer addresses, driver licence numbers, consignment values or commercial rates into any tool on the approved list” is a rule somebody can follow at their desk. Keep the prohibited list short and absolute, because a long one gets treated as advisory. Name the approved tools explicitly, because a policy that permits “approved tools” without a list has just moved the problem.
The needs-approval list does the work the other two cannot. It is the route by which a new idea reaches somebody who can say yes, and if that route does not exist people will guess. State who to ask, and how long an answer takes.
Review cadence
The review cadence is when reviews happen: at design, at launch, and then on a repeating schedule. The design review comes before the build, when changing your mind is cheap and the question whether this needs a model at all can still be answered honestly. The launch review comes before real users, and it checks what was actually built rather than what was proposed. The recurring review is the one organisations skip, and it is the one that catches drift.
Set the recurring interval by what changes, not by tidiness. A frozen model over a frozen corpus can go twelve months. A retrieval corpus refreshed nightly, or a vendor feature whose model version is not yours to pin, wants a quarter at most. On top of the interval, define event triggers that pull a review forward: a vendor model change, a new data source, an incident, or the system being used for something it was not approved for.
Review strategies
Review strategies are who does the reviewing, and they run from cheap to expensive.
A self-assessment checklist has the person who built the thing answer a standard set of questions and file the answers. It costs an hour or two, it catches the obvious omissions, and its weakness is obvious as well: the author marks their own work. A peer review puts a second person from the same team through the same checklist, which costs half a day and catches what familiarity hides. A cross-functional review board brings legal, security, operations and the business owner into one room. It costs a fortnight of calendar time to convene. It is also the only one of the four that can weigh a legal exposure against an operational benefit, because it is the only one with both people in it. An external audit brings in somebody outside the company, costs weeks and real money, and produces the one thing the others cannot: evidence a third party will accept without knowing you.
Match the strategy to the consequence of getting it wrong. A summariser that only ever produces an internal note is a checklist. Anything a customer reads is a board.
Governance frameworks
Governance frameworks give a programme a structure to hang itself on, so nobody has to invent the list of things to consider. AWS publishes the Generative AI Security Scoping MatrixAWS’s five-scope classification for generative-AI use, running from a consumer app you only use (Scope 1) to a model you trained from scratch (Scope 5), which decides how many of the security controls are yours to implement rather than assure., which sorts a generative-AI use into one of five scopes by how much of the stack the user owns.
Scope 1 is a consumer application: somebody uses a public AI service through its own interface under its own terms, with no contract negotiated for the purpose. Scope 2 is an enterprise application: a business application procured under a contract has AI features built in, running on models the vendor picked and hosts. Scope 3 is an application you build on a pre-trained model somebody else supplies, which is where a Bedrock assistant lands. Scope 4 is that model fine-tuned on your own data. Scope 5 is a model your organisation trains from scratch. Placing a use is a matter of asking how much of it you would have to rebuild if the supplier vanished, and the scope then tells you how much of the control surface is yours rather than contractual.
Two external standards get named alongside it. ISO/IEC 42001 is the AI management system standard, the sibling of ISO 27001 for AI specifically, and it is certifiable, which matters when a customer asks for a certificate rather than an explanation. The NIST AI Risk Management Framework is voluntary and non-certifiable, organised around four functions (govern, map, measure and manage) that describe what a programme should do at each stage. Both tell you what a programme ought to contain. Neither tells you what your company’s answer is.
Transparency standards
Transparency standards cover what gets disclosed, to whom. There are two halves. The first is telling a person that they are dealing with an AI system at all, rather than letting them assume a human wrote the reply. The second is publishing what a system is and is not for, so that nobody uses the delivery-exception classifier to decide who gets a bonus.
Two artefacts carry the second half. AWS AI Service Cards are AWS’s own published documentation for its AI services, covering intended use cases, design choices and limitations, so a team choosing a managed service can read what it was built for before adopting it. Amazon SageMaker Model Cards are where you record the same information for a model of your own: intended use, training data, evaluation results, limitations and the decisions taken along the way, versioned and kept with the model. Reach for one the moment the company trains or fine-tunes anything. It sits next to the separate question of whether a decision has to be explainable to the person it affects.
Transparency and governance get confused because both look like paperwork. Disclosure to stakeholders is transparency. The organisational process that makes the disclosure happen every time is governance.
Team training requirements
Team training requirements say who has to be taught what before they are allowed to build, use, or approve. Three audiences, and they need different things. Everyone needs acceptable use: which tools are approved, what may never be pasted in, and who to ask. Builders need data handling, evaluation, guardrails and prompt safety, which is a day rather than a slide. Approvers need to be able to read an evaluation result and to recognise the answers that should stop a launch, because a reviewer who cannot say no is decoration.
Training only functions as a control when it has a date and a record against each name. Tie it to the gates: nobody sits on a launch review who has not done the approver session.
Evaluation
Side by side
| The use | Scope | What we own | What we can only assure | Review gate | Cadence |
|---|---|---|---|---|---|
| Dispatchers pasting into a public chatbot | 1: consumer application | Who may use it, what may go in, the training that says so | Retention, logging, model behaviour, where the text ends up | A policy decision plus a filed self-assessment; there is nothing built to review | On any change to the tool’s terms, otherwise annual |
| AI summarisation inside the transport management system | 2: enterprise application | Whether the feature is on, which users see it, what the contract and data processing agreement say | The model, the prompts, the vendor’s data handling and retention | Peer review of the vendor’s written answers, then sign-off by the contract owner | Every vendor release that touches the feature, and at contract renewal |
| The Bedrock assistant over the handbook | 3: pre-trained model | Prompts, retrieval corpus, guardrails, identity, logging, the interface, the disclosure | The base model’s own training data and behaviour | Design review, then a cross-functional launch review | Quarterly, because the corpus changes nightly |
| The fine-tuned exception classifier | 4: fine-tuned model | Everything in scope 3, plus the training data, the fine-tuned weights, the evaluation and the model card | The base model underneath the fine-tune | Design review, cross-functional launch review, and a documented evaluation with the model card attached | Quarterly, and again on every retrain |
Read the table across rather than down. The top two rows produce no engineering work at all, and a governance programme that only looks at projects will never see them. Nobody filed a ticket for the chatbot, and the vendor feature arrived switched on. The controls available for both are a policy, a decision about who may use them, and a conversation with a supplier.
The interesting jump is between rows three and four, because it looks small and is not. Fine-tuning adds to the scope 3 obligations rather than replacing them. Everything true of the assistant stays true of the classifier. On top come the provenance of four years of consignment notes, whether the people who wrote them expected those notes to train a model, and a set of weights that can memorise what went into it. A model card stops being optional at that row, because the company is now the author of a model rather than a user of one, and the answers about training data exist nowhere else. The dataset questions themselves are the ones asked before a model sees the data.
Scope 5 does not appear, which is normal. Very few companies train a foundation model from scratch, and a governance programme that spends its first six weeks preparing for that scope has spent them on the row it will never fill in.
Two of the four rows are already in production without ever having passed a gate. That is the ordinary situation, and it changes the sequencing rather than the design: the register comes before the policy, because the policy has to cover what is running and not only what is proposed.
The solution
Six weeks, one person, no budget. The order matters more than the polish.
Start with a register, not a policy. One row per AI use, listing what it does, who owns it, what data goes in, who reads the output, and its scope from the matrix. Six rows will surface that were not in the four, because somebody in finance is using a transcription tool and somebody in HR has an AI screener switched on. A governance programme cannot cover a use it has never heard of. The register is also the evidence artefact: when an assessor asks what AI this company runs, the answer is a document rather than a meeting.
Then the policy, and keep it to one page. Three lists. Permitted: the named approved tools, for the named kinds of work. Needs approval: anything new, anything that touches customer data, anything whose output leaves the company, with the name of who to ask and a stated turnaround. Prohibited: a short, absolute list, with customer addresses, driver licence numbers and commercial rates in a public tool at the top of it. Publish it where people already look rather than in a policy library nobody opens.
Then the gates. Design review is the two developers plus one reviewer working through a checklist, and it happens before the build. Launch review is the cross-functional board, which for a company of 200 is four people and a standing hour a fortnight rather than a committee. Recurring review is calendar entries derived from the cadence column, plus the event triggers written into the policy. Publish the turnaround time for each, because a gate with no route to yes gets bypassed and then nobody knows what is running.
Then the transparency standard, which fits in three sentences. Any output a person outside the company reads is labelled as AI-assisted. Any internal tool carries a short note saying what it is for and what it is not for. Every model the company trains or fine-tunes gets a model card before it goes near a decision.
Then training, with dates. The all-staff session covers the policy and takes twenty minutes. The builder session is a day. The approver session is an afternoon and is the prerequisite for sitting on the board.
Four things will go wrong in the order listed. The prohibited list grows, because every review adds a line to it and nobody removes one, and at about fifteen entries people stop reading it. The board becomes a queue, which is why the gate is tiered by scope rather than applied to everything. The scope 2 vendor feature gets missed at the next release, because nothing internal changed and no ticket was raised. Tie that row’s review to the vendor’s release notes, and give somebody the job of reading them. And somebody will propose ISO/IEC 42001 certification in week two: use the framework’s structure now, and treat certification as a decision to take once the register has been stable for a year and a customer has actually asked.
None of this produces the evidence itself. The register, the reviews and the model cards record what the company decided. Showing that a bucket was never public, or who deleted a guardrail, is a separate set of AWS services. Name which one answers each recurring question before an assessor turns up.
Worked example
Two of the four rows, traced from the register to a decision.
The chatbot the dispatchers already use
It goes in the register as scope 1, owned by the dispatch team lead, with customer email text going in and drafted replies coming out. There is no build to review and no configuration to harden, so a design review would produce nothing. What the company can decide is whether the use is permitted at all, on which tool, and with what redaction rule.
The operations manager files a self-assessment against it. What data has gone in so far, whether the account is a personal one or a company one, whether the tool’s terms allow business use, and what the retention period is. The answers decide the policy line. Here the drafting is useful and the data going in is the problem. The permitted list gains one named tool on a company account, and the prohibited list gains a line about customer addresses and consignment values. The dispatchers get the twenty-minute session, and the recurring review is annual with a trigger on any change to the vendor’s terms. Total effort, about a day. Trying to run a cross-functional board on this would cost a fortnight and change nothing, because none of the technical controls are the company’s to move.
The fine-tuned classifier already in the board pack
It goes in the register as scope 4, owned by the two developers, with four years of consignment notes as training data and a weekly report as the output. It is running, which means the launch review is happening after the fact and the first job is deciding whether to pause it. The test is who is affected: the classification feeds a report, not a decision about a person or a payment, so it keeps running while the review happens, and that judgement gets written down alongside the reason.
The review asks the scope 4 questions in order. Where did the training data come from and what did the people who wrote those notes expect it to be used for. What does the evaluation say, broken down by depot and by exception type rather than as a single accuracy number, because an average can hide a group the model is bad at. What happens when the classifier is wrong, and who would notice. What the report says about how the numbers were produced, since nothing in the board pack currently mentions a model at all.
Three things come out. A model card recording intended use, training data, evaluation results and limitations. One added sentence in the weekly report, disclosing that the categories are model-generated and reviewed by the depot manager. A quarterly review, with a retrain trigger. The retrain trigger is what stops this becoming a one-off, because the fine-tune was trained on a freight mix that will not be this year’s for long.
What’s worth remembering
- Governance protocols are policies plus a review cadence, review strategies, a framework, transparency standards and team training requirements, and each one names a person or it does not exist.
- The Generative AI Security Scoping Matrix places a use by how much of the stack you own: scope 1 consumer application, scope 2 enterprise application, scope 3 an application on a pre-trained model, scope 4 that model fine-tuned, scope 5 a model trained from scratch.
- Review cadence follows what can change underneath you, so a frozen system reviews annually while a nightly corpus or an unpinned vendor model wants a quarter plus event triggers.
- Review strategies cost what they are worth: a self-assessment checklist for internal-only output, a peer review for a vendor feature, a cross-functional board for anything a customer sees, and an external audit only when somebody outside needs to accept the evidence.
- Transparency standards mean disclosing that a system is AI and publishing what it is and is not for, with AWS AI Service Cards documenting AWS’s services and Amazon SageMaker Model Cards documenting yours.
- ISO/IEC 42001 is the certifiable AI management system standard and the NIST AI Risk Management Framework is the voluntary one, and both describe what a programme should contain rather than what your organisation’s answer is.