Field note: Most AI policies fail at the moment of use. They describe values but leave a practitioner alone with a document, a prompt box, and a deadline. A useful policy connects risk to observable actions: what may be entered, what requires approval, what must be checked, and what must be recorded.
Operational question
What is the smallest set of rules that keeps routine AI-assisted work safe without forcing every low-risk experiment through a committee?
A workable method
- Inventory real tasks. List the ten or fifteen tasks people are already trying: summarizing public material, drafting learning objectives, analyzing survey comments, generating code, or handling learner records. Policy should begin with work, not vendor names.
- Classify data and consequences. Use a simple matrix. One axis describes information sensitivity; the other describes the consequence of a wrong output. Public copy with human review is different from personnel data or a safety-critical recommendation.
- Define required human checks. Name the reviewer, the evidence they inspect, and the point at which they can stop release. “Human oversight” is not actionable until responsibility and authority are explicit.
- Publish examples and an exception path. Provide allowed, restricted, and prohibited examples, then give people a quick route for unusual cases. An exception path prevents quiet workarounds.
What this looks like in practice
A training team may allow a public model to draft quiz distractors from non-sensitive source material, require a qualified instructor to verify every answer, and prohibit uploading assessment banks or identifiable learner data. The policy records the task and review standard without pretending all AI use has the same risk.
Evidence to collect
Choose a small set of measures before implementation. Record the baseline, the source of each measure, the review cadence, and who is authorized to act on the result.
- percentage of common use cases with a clear policy answer
- median time to resolve an exception request
- number and severity of issues found during required review
Field checklist
- Write the decision, accountable owner, and decision date.
- Describe the current workflow and the conditions that shape performance.
- Confirm the source hierarchy, permissions, and local requirements.
- Test the method under representative—not merely convenient—conditions.
- Review both intended outcomes and burden on the people doing the work.
- Record a change, escalation, and stop rule before results arrive.
Watch-out
Do not write a policy that depends on a fixed list of products. Capabilities, contracts, and data handling terms change. Govern the task, data, consequence, and control, then maintain a separate approved-tools register.