A seven-part operating model for growing businesses
AI adoption often begins before governance. A team starts using an assistant to summarise meetings, draft customer replies, screen applications or prepare analysis. Within weeks, outputs from the system may influence decisions even though nobody has defined what the tool may access, what it may decide or who must verify its work.
A policy document cannot control those details by itself. Practical governance has to reach the point where data enters a tool, an output enters a process and a person decides whether that output can be used.
For a growing business, this does not require a large committee. It requires a small set of controls inside each AI-enabled workflow: a defined purpose, permitted data, review thresholds, evidence requirements, escalation rules and an accountable owner.
Governance becomes useful when it changes the workflow
The NIST AI Risk Management Framework organises AI risk management around four functions: Govern, Map, Measure and Manage. That structure is useful because it connects governance with the specific setting in which an AI system is used rather than treating risk as a property of the tool alone.
The same model can create very different risks in different workflows. Asking AI to reorganise internal notes is not equivalent to asking it to rank job applicants, approve a refund or send financial guidance to a customer. The consequences depend on the data, the affected people and what happens after the output is produced.
Governance therefore starts with the workflow. A business should be able to trace an AI-assisted task from input to action and identify where a person, rule or technical control prevents an unreliable output from becoming a business decision.
1. Inventory use cases instead of tools
A list of approved tools is useful, but it is not an AI inventory. One application may support ten use cases with ten different levels of risk, while the same use case may move between applications as vendors and features change.
Record each use case by purpose, users, input data, expected output, affected people, connected systems and business owner. Include informal uses that have already emerged, such as employees pasting customer messages into a public chatbot or using generated summaries as the official record of a meeting.
This inventory does not need to be complicated. A spreadsheet is enough if it shows where AI is used, what the organisation expects it to do and who is responsible for the result.
2. Match controls to consequences
Every use case should receive a risk tier based on the consequence of failure. The tier should determine how much access the system receives, how thoroughly its output is reviewed and whether it may trigger an action.
Low-consequence uses may include brainstorming, reformatting or drafting internal material. Medium-consequence uses may include customer communications, operational recommendations or externally published content. High-consequence uses include decisions affecting employment, eligibility, finance, legal rights, health or safety.
A high-consequence workflow should never inherit the controls designed for a low-consequence drafting task. It may require qualified human approval, independent verification, restricted data access, a documented rationale and a clear way for an affected person to challenge the result.
This risk-based approach also reflects the direction of regulation. The European Commission describes the AI Act as a framework that applies different requirements according to risk, with most provisions applying from 2 August 2026. Businesses operating in or serving the EU should determine which obligations apply to their particular role and use case.
3. Define data permissions before prompting
Employees need to know which data may enter an AI system before they start writing prompts. The rule should cover personal information, customer records, employee data, credentials, confidential contracts, unreleased financial information and proprietary material.
The workflow should use least-privilege access. An AI assistant that drafts a follow-up email may need the relevant meeting notes, but it does not need unrestricted access to the entire customer database. Connected tools, plug-ins and agents should receive only the permissions required for the approved task.
The business should also document retention settings, vendor terms and whether prompts or uploaded material may be used to improve a provider’s models. If personal data is involved, privacy review belongs at the design stage rather than after deployment.
The UK Information Commissioner’s Office guidance on AI accountability places responsibility on the organisation and treats impact assessment as a practical way to identify and control risks. The ICO currently notes that this guidance is under review, so businesses should confirm the latest requirements in their jurisdiction.
4. Replace vague human oversight with review rules
Saying that a human is in the loop does not explain what the human must do. Review works only when the business defines who is qualified to review, what that person must check and which findings require rejection or escalation.
A low-risk internal draft may need a quick accuracy check. A customer-facing response may require verification against the account record and approved policy. A high-consequence recommendation may require a subject-matter expert, a second reviewer and a rule that prevents the system from completing the action automatically.
Reviewers also need enough time and authority to disagree with the system. If employees are expected to approve hundreds of outputs quickly, human oversight may exist on paper while functioning as a rubber stamp.
Set explicit rejection criteria. Missing sources, invented facts, unsupported confidence, discriminatory language, disclosure of restricted data or an action outside the approved scope should stop the workflow.
5. Require evidence for important outputs
Important outputs should carry enough evidence for another person to understand how they were produced and why they were accepted. The evidence may include source links, the data version, the prompt or template used, the model or system version, the reviewer and the reason for the final decision.
Evidence requirements should increase with the stakes. A brainstorming session does not need the same record as an AI-assisted hiring recommendation or a response to a regulatory question.
The NIST Generative AI Profile supplements the AI Risk Management Framework with risks and actions specific to generative systems. Its emphasis on testing, evaluation and documentation provides a useful reminder that a polished output is not proof of accuracy.
Evidence also makes improvement possible. When a mistake occurs, the team can determine whether the cause was poor source data, an ambiguous instruction, weak review or an inappropriate level of automation.
6. Create an escalation and failure path
An AI workflow needs a defined response when the system behaves unexpectedly. Without one, employees may improvise, quietly correct outputs or continue using a failing process because nobody knows who can pause it.
Escalation triggers may include conflicting sources, unexpected personal data, repeated factual errors, a customer complaint, an attempted action beyond the system’s permission or a material change in model behaviour. The workflow should identify who receives the issue, whether automation stops and what evidence must be preserved.
Security teams should be part of this design. The OWASP Top 10 for LLM and generative AI applications includes prompt injection, sensitive information disclosure, improper output handling, excessive agency and misinformation among its core risks. These risks become operational when an AI system can retrieve data, call tools or trigger downstream actions.
Maintain a simple incident log. Record what happened, which use case was involved, the impact, the immediate response and the control changed afterward.
7. Assign ownership and monitor performance
Every use case needs a named business owner. That person is responsible for the purpose, acceptable risk, review design and performance of the workflow, even when a vendor supplies the model or a technical team manages the integration.
An operational or technical steward can maintain access rules, templates, testing and change records. The business owner should still decide whether the workflow remains useful and whether its outcomes are acceptable.
Useful measures include error and override rates, complaints, exceptions, review time, unsupported claims, privacy incidents and actions blocked by permission controls. Track the measures that reveal whether the workflow is safe and useful rather than reporting the number of prompts or users as proof of success.
Reassess the workflow when the model changes, new data is connected, the process expands to a new audience or a regulation changes. Approval at launch does not cover every future version of the system.
A practical governance session for one workflow
A growing business can establish the first version of these controls in a focused working session. Choose one active AI use case rather than attempting to govern every possible use at once.
- Write the business purpose and the actions the system is not allowed to take.
- List the data it receives, the systems it can access and the people affected by its output.
- Assign a consequence tier and define the required human review.
- Specify the evidence that must accompany an output before it can be used.
- Name the owner, reviewer and escalation contact.
- Choose two or three measures and set the next review date.
The result is a control record tied to real work. It can later become part of a wider policy, risk register or compliance programme, but it already changes what employees and systems are allowed to do.
Proportionate governance is an operating discipline
Growing businesses do not need to copy the governance structure of a multinational company. They need controls that match the consequences of their own use cases and remain clear enough for employees to follow.
When permissions, review, evidence and escalation are built into the workflow, governance becomes repeatable and auditable. It also becomes easier to expand AI use responsibly because the business can see which controls must change as the stakes increase.
The most useful governance question is practical: what must happen between an AI output and a business action? A company that can answer that question for every important workflow has moved beyond policy language and into accountable use.
