STIVAn AI governance policy should cover which AI systems are approved, what each may be used for, which data they can access, which actions need human approval, how activity is logged and reviewed, and who is accountable when something goes wrong. Keep it short enough that teams actually read it, and specific enough that someone can tell whether a given use is allowed.
A practical outline
- Scope: which teams, systems, and kinds of AI the policy covers, including AI agents that take actions, not just chat tools.
- Approved systems: the list of AI tools and vendors cleared for use, and how a new one gets approved.
- Permitted uses: what each system may be used for, by role or division.
- Data access: which data each system may read or write, and what must never be shared with it.
- Approval rules: which actions require a person to approve before they happen, and who that person is.
- Logging and review: what is recorded, how long it's kept, and who reviews it and how often.
- Incidents: how a wrong or harmful output is reported, contained, and corrected.
- Accountability: the named owner for each AI system and for the policy itself.
- Review cycle: when the policy is revisited, at least yearly and whenever a new kind of AI is adopted.
The section most policies get wrong
Approval rules are usually written as a principle — 'humans remain in control' — rather than a rule someone can follow. Write them as a list: external emails, financial entries, contract redlines, and access changes need approval from the owning role; internal summaries and drafts for review don't. If an employee can't tell from the policy whether their case needs approval, the policy isn't finished.
Make the policy enforceable, not just written
A policy only works if the systems enforce it. Prefer AI tools where permissions can be scoped by role, approval gates can be configured per action type, and every recommendation and decision is logged in one place you can export. Otherwise the policy describes what should happen and the audit only finds out later what did.
STIV is designed around that model — role-scoped access, configurable approval gates, and one audit trail across divisions — and this piece on our security architecture covers the details. Check any specific regulatory requirements for your industry and country with your legal team; this outline is a starting structure, not legal advice.