The AI use policy: the decisions a working policy makes, and the records that prove it operates.
An AI use policy is the document through which an organization decides how artificial intelligence may and may not be used with its information, its systems, and its name. The substance of the policy is not its wording; it is the decisions inside it. A policy with the decisions unmade is a template, and a policy that does not match observed practice is a finding in every framework this practice supports. This page describes the eight elements a working policy contains, where the policy sits in the governance frameworks, and how development proceeds in practice.
The decisions inside a working AI use policy
- Which AI uses are permitted, prohibited, or need approval
- Which information classes never enter an AI tool
- Which tools and accounts are approved, and on what terms
- How embedded and vendor AI features are reviewed
- Who is responsible for AI-assisted output
- How the policy is taught, enforced, and kept current
A policy is a set of decisions, not a document about intentions.
Most AI use policies in circulation fail the same way: they were downloaded rather than decided. A template can supply the structure, but every clause that matters requires an organization-specific answer. Which tools are approved is a procurement and risk decision. Which data classes are excluded is a legal and contractual decision. Who approves new uses is an authority decision. Who answers for AI-assisted output is an accountability decision. An organization that adopts a template without making those decisions has a document for auditors and no instructions for employees, which is the configuration that produces shadow AI in the first place.
The policy also has a dependency that is easy to get backwards: it should be written after the AI use inventory, not before. A policy drafted in the abstract bans tools people depend on and permits categories nobody uses, and it forfeits credibility on the day it publishes. The inventory work described on the AI governance overview establishes what is actually in use and why, which lets the policy make its decisions against reality: sanctioning what deserves sanction, replacing what needs replacing, and prohibiting what genuinely cannot be permitted, with an approved alternative offered wherever the underlying need is legitimate.
The eight elements of a working AI use policy.
The elements below are the answer to what an AI use policy should include. Each one exists because a real question arrives at the organization from outside, from an employee, a customer, a carrier, or a regulator, and the policy is where the answer has to already be written down.
Scope and definitions
What counts as an AI tool for purposes of the policy, including consumer chatbots, AI features embedded in approved software, browser extensions, and AI-enabled services, and who the policy covers: employees, contractors, and anyone acting with organizational data or accounts.
The three-tier use decision
The core structure: uses that are permitted outright, uses that are prohibited outright, and uses that require approval. Three tiers work where binary rules fail, because most AI use is neither clearly safe nor clearly unacceptable, and the approval tier is where the organization learns what its people actually need.
Data rules
The classes of information that may never enter an AI tool regardless of tier: Controlled Unclassified Information for defense contractors, personal information, customer data held under confidentiality terms, and whatever else the organization's contracts and regulations name. This is the clause that protects the compliance representations the organization has already made.
Approved tools and accounts
The sanctioned path: which tools are approved, under organizational accounts and reviewed terms rather than personal ones, and with data handling and training provisions the organization has actually read. The approved list is what makes the prohibitions enforceable in good conscience.
Embedded and vendor AI
How AI features arriving inside existing software are handled: who reviews vendor AI announcements and administrative settings, which features default to off pending review, and how the review's outcome reaches the inventory. This clause addresses the entry path that employee-facing rules cannot see.
Human oversight and output responsibility
The principle that AI-assisted work product remains the responsibility of the person who produces it, the review that applies before AI-assisted output reaches customers, code bases, or decisions, and any disclosure the organization requires about AI involvement.
Training and acknowledgment
How the policy is taught, when acknowledgment is collected, and how new hires and role changes are covered. A policy nobody was trained on is an unenforced policy, and the acknowledgment records are among the first artifacts a counterparty requests.
Enforcement, exceptions, and review
What happens when the policy is violated, how exceptions are requested and recorded rather than improvised, and the review cycle that keeps the policy current, which in this domain means at least semiannually, because the tools, the vendor features, and the obligations all move faster than an annual cycle.
The one artifact every framework and questionnaire asks for.
The AI use policy is where the governance frameworks converge. The NIST AI Risk Management Framework locates policy in its Govern function, the foundation on which its Map, Measure, and Manage work rests, as described on the NIST AI RMF page. ISO/IEC 42001 makes the AI policy its first Annex A control objective and threads policy through its responsible use and resource objectives, covered on the ISO/IEC 42001 page. Alignment work against either framework begins with the same question a customer questionnaire, a cyber insurance application, and a due diligence review now ask in nearly identical words: does the organization have an AI use policy, and can it show that the policy operates.
This convergence is why the policy is the highest-leverage single document in an AI governance program. It is small, it is buildable in weeks rather than quarters once the inventory exists, and it converts directly into answers the organization is already being asked to give. It does not complete the program, the governance overview describes the rest, but it is the piece that changes the organization's position soonest.
How policy development proceeds in this practice.
Policy development here follows the sequence the document depends on. The inventory comes first, establishing what AI is actually in use and what need each use serves. The decisions come second, and they are made by management, because the policy allocates risk, restricts how regulated and contractual information is handled, and supports representations the organization makes to outside parties; those are leadership decisions that IT implements rather than IT decisions that leadership ratifies. Drafting comes third, written to be followed by the people who will read it, in the organization's language rather than framework vocabulary. The rollout pairs the policy with its approved path, so the announcement that some uses are ending arrives together with the sanctioned way to keep the benefit, and training and acknowledgment complete the record.
The deliverable is a policy the organization decided, an approved tool path that makes it livable, and the record structure that proves it operates: the artifacts that alignment with the NIST AI RMF, readiness for ISO/IEC 42001, and the questionnaires arriving from customers and carriers all draw on. As throughout this practice, the work is independent advisory: no software, no certification, and no template presented as though it were a decision.
The AI use policy, answered briefly.
What should an AI use policy include?
Eight elements: scope and definitions; permitted, prohibited, and approval-required uses; data rules naming the information classes that never enter an AI tool; approved tools and accounts; treatment of embedded and vendor AI; human oversight and output responsibility; training and acknowledgment; and enforcement, exceptions, and review.
Is a template enough?
A template supplies structure, but the policy's value is the organization-specific decisions inside it. A template with the decisions unmade instructs no one, and the gap between what it says and what people do becomes a finding the first time anyone compares them.
Who should own the policy?
Management. The policy allocates accepted risk, restricts regulated and contractual data handling, and supports outside representations, all of which are leadership decisions. IT and security implement and monitor it. The major frameworks place policy in the governance function for the same reason.
How often should it be reviewed?
At least semiannually, with an event-driven review whenever a major tool, vendor feature, or obligation changes. AI tooling and vendor behavior move faster than the annual policy cycle most organizations run, and an outdated approved tool list undermines the whole document.
Does a small company really need one?
If its employees use AI at all, yes, because the questions the policy answers are already being asked of it: by employees who want to know what is allowed, and increasingly by customers, insurance applications, and contract clauses. For a small organization the policy is correspondingly small; what it cannot be is absent.
Discuss Your AI Use Policy
Inquiries may involve developing an AI use policy from a completed inventory, revising a template into a decided policy, building the approved tool path, or structuring the records that customers, carriers, and frameworks ask to see. Call, email, or send a note. I respond personally to every inquiry, usually within one business day.
Discuss an Assessment
Whether the question is what your policy should decide, how to bring an inherited template up to a working standard, or how to build the approved path that makes the rules livable, the first conversation carries no commitment and no pitch.
Discuss an Assessment →