Enterprises have written the policies. Risk teams have approved the tools. And yet the governance that decides whether an AI deployment is safe is exercised thousands of times a day by employees deciding what to paste, which tool to open, and whether to trust what comes back. That is where governance has to live.
Short answer: in the deployments we run, effective AI governance is a workforce capability before it is a policy document. Six controls carry most of the weight: a data classification ceiling that applies in every format; a purpose test, because permitted data can still be used in a prohibited way; a tool selection rule for multi-tool environments; evaluation skill, so employees know when an output is wrong in a way that matters; tiered build permissions by persona; and human review placed deliberately at the points where it changes outcomes. Policy and committee structure define these controls. Training is what makes them operate.
Why does AI governance fail between the policy and the keyboard?
Because the policy is written once, by a few people, and exercised continuously, by everyone.
Every large enterprise we work with now has an AI acceptable-use policy, a risk sign-off process for new tools, and usually a committee. Those are necessary. They are also not where most governance decisions happen. The decisions happen when a procurement analyst decides whether a supplier meeting note can go into an assistant, when a product manager chooses between Copilot and Claude for a task, when a team lead decides whether an agent's output can go to a client without a second look. A policy that employees have read but cannot apply at that moment is not governing anything.
Our engagement data points the same way. The strongest predictor of realised AI return in our 2026 dataset is not licence count or budget but whether governance discipline and workforce enablement are run as one system rather than as parallel initiatives owned by different functions. Where risk owns the policy and L&D owns the training, the two rarely meet in the employee's hands.
Are employees under-trained on AI risk?
Usually not. They are under-trained on the operating skills that make safe use possible.
Employees arrive at training with a reasonably calibrated sense of AI risk. At a leading North American bank, pre-workshop confidence in safe and responsible use measured 3.9 out of 5, against 2.6 for prompting. Organisations tend to over-invest in risk messaging their people have already absorbed and under-invest in the skills that determine whether the tool produces value at all, and whether the person can tell when it hasn't. The governance gap is not awareness. It is competence.
What is a data classification ceiling, and why does it need a purpose test?
A ceiling names the highest classification permitted in the tool, in every format. A purpose test stops permitted data being used for prohibited ends.
The clearest implementation we have seen is at a global airline group deploying Claude alongside Copilot. Four classifications: Public, Internal, Confidential, Strictly Confidential. The first three are approved; Strictly Confidential (personal data, safety and security data, board-restricted material) is prohibited in every format, including screenshots and pasted extracts. Confidential is the ceiling, and the same ceiling applies regardless of which tool is open.
The ceiling alone is not enough. The airline's programme teaches a second check: is the purpose permitted? Summarising approved documents, drafting market analysis, and producing first-draft reports are approved purposes. Personal projects, working around blocked systems, HR and people processes, and monitoring or comparing individual colleagues are out of scope even when the underlying data is permitted. Employees practise both checks on realistic files before they touch a live task: a public market report (use), a confidential supplier report for a weekly update (use), unlabelled meeting notes (check first), a screenshot of a contact list with personal numbers (do not use), team emails used to rank colleagues (do not use).
How should a multi-tool environment be governed?
With one data boundary across all tools and an explicit rule for which tool starts which kind of task.
Over the past six months most enterprises we work with have moved from a single assistant to a multi-tool environment, typically a general-population tool for everyone and Claude for subsets whose work is heavier on synthesis and building. The governance cost is real: harder to oversee, stacked licences, and unclear rollout logic. The control that works is simple to state. The classification ceiling and purpose test apply identically in every tool, and employees learn a location rule: start in the Microsoft tool when the work is inside an open file and needs in-place edits; start in Claude when the work is drafting or synthesis across several permitted sources. A rule employees can apply beats a policy that lists approved vendors.
Why is evaluation the governance skill enterprises most overestimate?
Because knowing when an AI output is wrong in a way that matters is assumed, and in our training rooms it is the skill most consistently missing.
Human review is only a control if the human can tell what to look for. Leading adopters are responding structurally. One airline group has formalised a two-dimensional agent-testing framework: in-scope requests tested for accuracy, out-of-scope requests tested for graceful refusal. A life insurer runs a formal challenge for its actuaries on interpretability, fairness, and selection bias. In our own curricula, evaluation is taught as deliberately as generation: every produced output is checked against its sources before it leaves the session, and the method is turned into a reusable Skill so the check runs the same way every time. Evaluation is on its way to becoming what spreadsheet literacy was in the 1990s: an unglamorous skill that decides who gets trusted with the important work.
How do tiered build permissions work?
By matching what a person may build to what they have demonstrated they can govern.
A semiconductor manufacturer we work with has formalised three personas, Business User, Citizen Developer, and Power User, with escalating build permissions attached to each tier. Advancement is earned through a programme that ends in a demonstrated, tested artifact. The airline group applies the same logic to features: Projects and Skills are enabled with sharing disabled for the first cohort, connectors are limited to an approved list, and the roadmap for widening access is published rather than implied. Governance by permission tier is more durable than governance by prohibition, because it gives capable people a route to more capability and gives the organisation evidence before it grants it.
Where should human review sit?
At the points where it changes an outcome, placed deliberately, and taught as a positive responsibility rather than a disclaimer.
For knowledge workers, the principle has not changed and should not: the model drafts; the person reviews, verifies, edits, and owns the action. Even in a world where models were never wrong, an organisation would not want its people to outsource judgement. What has changed is where the review sits for technical teams. Engineers using agentic development tools increasingly specify what code must do and how it will be verified, let the agent implement, and spend their judgement on review and tests. The control moves from "check every line" to "specify the test and inspect the result." In both cases the governance question is the same: name the step where a person decides, and train the person to decide well.
How does memory change the governance picture?
It doesn't change what is permitted. It adds a hygiene habit employees need to be taught.
Workspace memory in enterprise assistants saves stable context (role, format preferences, terminology) to reduce repeated setup. Memory never expands what the organisation permits an employee to enter. Three habits make it safe: save stable, permitted context deliberately; review saved memories periodically rather than only when something looks wrong; delete what is outdated. We teach them in the first session, alongside the data boundary, because a policy about memory that employees have never opened the settings page to apply is not a control.
Who operates governance after the programme ends?
A champion layer, selected and equipped to answer the questions a help desk cannot.
The decisions that block AI at the pilot-to-production boundary, data access, risk sign-off, funding the next phase, are executive decisions and belong with executives. The decisions that happen at the keyboard need a nearer answer. AI Champions, roughly 5 to 10 percent of employees distributed across functions, carry the data boundary, the purpose test, and the tool rule into their teams, coach colleagues through them, and route use cases to the centre through the same impact, feasibility, and scope gates the centre applies. Champions who have built something themselves are the only ones with the credibility to do this, which is why governance and capability-building are the same programme in our model, not two.
What does this mean for how enterprises should structure AI governance?
Write the policy with risk and legal. Then treat every training programme as the place the policy is installed.
Published frameworks for AI risk management and the regulatory regimes now in force define what an organisation must be able to show. They do not install themselves. In our programmes, governance is not a module appended to the end; it is the first session, the pre-send checklist in every session, and the evaluation step in every build. One client described the requirement precisely: responsible AI embedded throughout, not treated as an afterthought. That is the design principle, and it is measurable: pre/post capability on the governance skills, incidents avoided at the keyboard, and the share of agents that pass a testing framework before they reach production.
Key takeaways
- The governance that holds is exercised at the keyboard; policy defines it, training installs it.
- Employees are not under-trained on risk awareness; they are under-trained on the operating skills (prompting, context, evaluation) that make safe use possible.
- Six controls carry most of the weight: a classification ceiling in every format, a purpose test, a tool selection rule, evaluation skill, tiered build permissions by persona, and placed human review.
- Evaluation is the most overestimated governance skill; teach it as deliberately as generation and formalise agent testing (accuracy in scope, graceful refusal out of scope).
- Champions who have built carry governance into teams after the programme ends.
Frequently asked questions
The policies, controls, and capabilities an organisation uses to make sure AI tools are used safely, lawfully, and effectively. In practice it includes data classification rules, purpose restrictions, tool selection rules, human review requirements, evaluation and testing of AI outputs and agents, and the training that lets employees apply all of these.
A document stating which data may be entered into AI tools, for which purposes, by whom, and with what review. Effective policies set a classification ceiling that applies in every format and pair it with a purpose test, then train employees to apply both on realistic examples.
A check that the intended use of the data is approved, separate from whether the data itself is approved. For example, confidential business documents may be permitted for drafting reports but prohibited for HR decisions or comparing individual colleagues.
Apply one data classification ceiling and purpose test across all tools, publish a rule for which tool starts which kind of task, and teach both in the first training session. Governing by approved vendor list alone leaves the decision at the keyboard unguided.
A design in which a person reviews, verifies, and owns AI output at the points where the decision matters. For knowledge workers this means the model drafts and the person owns the action; for engineering teams using agentic tools it increasingly means specifying tests and inspecting results rather than reviewing every line.
A common framework tests two dimensions: in-scope requests for accuracy against sources, and out-of-scope requests for graceful refusal. Agents that pass both, with a named owner and documented tests, proceed to pilot.
They overlap but are not identical. Responsible AI training builds the awareness and skills employees need; governance is the full set of controls, including policy and oversight. Training is how governance becomes operational.
Install your AI governance where it operates
Correlation One builds data boundaries, purpose tests, evaluation skill, and agent testing into every enablement programme, and measures whether they hold.