What Belongs in an AI Policy

An AI policy is not a list of prohibitions. A list of prohibitions is a starting point, not a policy. A complete AI policy tells employees what they are allowed to do, under what conditions, with what data, and with what level of human oversight. It tells them what to do when the system produces a result they are uncertain about. It tells them who to call when something goes wrong. Without those elements, the policy is decorative.

The Structure of a Complete AI Policy

The nine sections are not suggestions. Each one answers a specific question that employees, auditors, or regulators will ask. Omitting a section creates a gap that will be discovered at the worst possible time: during an incident investigation, a customer audit, or a regulatory inquiry.

Purpose and Scope: Establishing the Boundary

The purpose section states why the policy exists in one or two sentences. It is not a statement of values; it is a statement of intent. "This policy governs the acceptable use of AI systems by employees, contractors, and authorised third parties acting on behalf of [Organisation] to ensure that AI is used in a manner consistent with our obligations to customers, regulators, and affected individuals."

The scope section defines who the policy applies to and which AI systems it covers. It must explicitly include third-party tools — if ChatGPT is used in the organisation without being named in the policy, the policy does not govern its use. The scope section should also state what is explicitly out of scope, to prevent the policy from being cited in inappropriate contexts.

Approved Systems: Named Tools, Named Approval Process

An approved systems list names every AI tool the organisation permits employees to use. It is not a category ("approved AI writing assistants") but a list of specific named tools. Each tool should have a note on the conditions of its approval: "Claude/Anthropic API — approved for internal document drafting only; personal data must not be entered."

The approval process for tools not on the list must be described. Who receives the request, what information is required (use case, data to be processed, risk assessment), and what the turnaround time is. Without a process, the approved list becomes a list of tools that people have happened to get away with using.

Permitted and Prohibited Uses

The permitted uses section is frequently underwritten. Organisations list what is prohibited and assume that everything else is permitted. This creates ambiguity in every borderline case. The permitted uses section should be explicit: drafting internal documents where a human reviews the output before use; summarising internal data where the output is not transmitted externally; writing or reviewing code where a human reviews before deployment.

The prohibited uses section must use language that can be evaluated by a compliance officer. "Used responsibly" is not evaluable. "Used to generate output that will be presented to a third party as unassisted human work, without disclosure" is evaluable. The section should include five to seven specific prohibitions, not a general instruction to act ethically.

Data Handling: Sensitivity Tiers for AI Use

General data protection requirements are necessary but not sufficient for AI data handling. The data handling section must define sensitivity tiers specific to AI use: what data may be entered into external AI systems, what data may be processed by internal AI systems, and what data is prohibited in all AI systems regardless of hosting arrangement.

The most common omission in this section is the prohibition on entering credentials, API keys, and secrets into AI systems. This is not a data protection requirement; it is a security requirement. It belongs in this section because it governs the data that employees input.

Refusal Protocols: When AI Must Not Proceed

The refusal protocols section is the operational expression of the organisation's position on AI limits. It defines the conditions under which an AI system must decline to produce output, return an error, or escalate to a human. These conditions must be specific enough that an employee can evaluate them at the moment of use.

Standard refusal conditions include: requests requiring the AI to act as a licensed professional; requests involving data the system is not authorised to process; outputs that would be irreversible and consequential without human verification; and outputs where the system has flagged low confidence. Industry-specific conditions should be added: a financial services firm might add "requests involving customers in active complaints or legal proceedings."

The section must also specify what employees must not do when a refusal is triggered: they must not attempt to work around the refusal through rephrasing, context injection, or use of an unapproved alternative system. This prohibition is more important than the refusal condition itself, because it is the point at which governance collapses in practice.

HITL Requirements: When Human Review Is Mandatory

The HITL section specifies the situations that require a qualified human reviewer before an AI output is acted upon or transmitted. It must name the triggers, the reviewer role, the evidence required for the review decision, and what happens if the reviewer does not respond within the SLA. An HITL requirement that has no SLA and no default behaviour is an HITL requirement that will be bypassed under time pressure.

The connection between the HITL section and the contextual governance framework is direct: the policy's HITL triggers should map to the organisation's risk tier structure. Tier 2 deployments require a gate review; Tier 3 require sequential approval. The policy makes these requirements explicit for non-technical audiences.

Incident Response: From Discovery to Regulatory Notification

The incident response section defines what constitutes an AI-related incident and what happens when one occurs. An AI incident is any situation where an AI system produces an output that causes or risks harm to an individual, the organisation, or a third party; involves unauthorised processing of personal or sensitive data; or results in an irreversible action that would not have been taken without AI involvement.

The section should specify the reporting chain in order, the time limit for initial report, and the assessment of whether regulatory notification is required. In jurisdictions where GDPR or equivalent law applies, an AI incident involving personal data may trigger a 72-hour notification obligation to the supervisory authority. The policy must make this explicit.

For organisations building an AI policy from scratch, the AI Policy Generator produces a structured nine-section policy from a 15-field configuration form. It is aligned to NIST AI RMF and ISO/IEC 42001 and includes the standard refusal conditions, HITL triggers, and incident response procedure. The output is Markdown that can be reviewed and adapted before finalising with legal counsel.

Keeping the Policy Current

An AI policy becomes outdated faster than most governance documents because the AI landscape changes faster than most domains. The policy must be reviewed within 30 days of any material change to the organisation's AI use: a new tool approved, a use case moving from internal to external, or a regulatory change. An annual review is the minimum; semi-annual is better practice in organisations deploying in regulated contexts.

The review process should include an assessment of whether any refusal conditions or HITL triggers have been bypassed in practice since the last review. A refusal condition that is routinely circumvented is evidence that the condition was set incorrectly or that the process to work around it is easier than the governance team assumed.