Keyboard-level rules
Every rule answers a question someone actually faces mid-task — which tool, which data, whose approval — not a question a committee faces annually.
AI governance and usage policies from Aun & Co.: approval gates, input rules and ownership written at workflow level — sized for teams that actually work.
AI governance fails at the extremes: fifty-page frameworks nobody reads, or a paragraph of good intentions nobody can apply. The working middle is a short policy written at the level of the actual workflow — which tools are approved, what may and may never be entered into them, where the human approval gate sits, what gets logged, and who owns the answers. The firm writes these policies from its own governed practice: every rule it drafts for clients is a rule it can live under itself.
The policy is drafted from observation, not template: how the team actually works, which tools are actually in use, where the real risk moments occur. Rules are written as decisions a person can make at the keyboard — this document class, this tool tier, this approval step — and every rule carries an owner and an exception path, because a policy without an exception path is a policy people route around silently. Rollout includes the training and attestation that make it enforceable.
Every rule answers a question someone actually faces mid-task — which tool, which data, whose approval — not a question a committee faces annually.
The firm operates under its own AI policy daily; the drafting reflects what governed use feels like from inside.
Ownership, logging, attestation and an exception path built in — the components that separate a policy from a poster.
A typical engagement: a professional team of fifteen with a dozen AI tools in informal use. The firm drafts a four-page policy — three tool tiers, a data classification, one approval gate — runs the rollout training, and the shadow use converges into the governed channel within a month.
Described in abbreviated, anonymised form to preserve client confidentiality.
Five things: the approved tools by tier, the input rules — what data classes may enter which tier, the human-approval gates for consequential outputs, the logging expectations, and a named owner with an exception path. Beyond those, length is usually a symptom.
Write it at the level of their actual tasks, keep it short, give it an exception route, and pair it with training that shows the workflows rather than reciting the rules. People route around policies that ignore how the work happens — fit is the enforcement mechanism.
For a small-to-mid-size team, a drafted policy typically lands within two to three weeks — observation, draft, review round — with rollout and attestation the week after. Speed matters: every ungoverned week is exposure accumulating quietly.