How to Write an Internal AI Policy (Template)
An internal AI policy is a written document that tells employees which AI tools they may use, for what tasks, with what data, and under whose approval. It sets the rules for acceptable use, data handling, human review, and accountability so staff can adopt AI without exposing the organization to legal, security, or reputational harm. A usable policy maps to recognized standards such as the NIST AI Risk Management Framework and ISO/IEC 42001, and it names the people responsible for each control.
Most organizations already have employees pasting confidential text into public chatbots. The policy question is no longer whether to allow AI. It is how to govern the use that is already happening and set rules for what comes next. The sections below give you the structure, the decision points, and a fill-in template you can adapt this week.
What is an internal AI policy and what does it cover?
An internal AI policy is the operational rulebook that connects high-level governance principles to daily work. A broader AI governance framework defines your principles, oversight bodies, and risk appetite. The internal policy translates those principles into instructions a marketing coordinator or a software engineer can actually follow.
A complete policy covers the following areas:
Scope and definitions. Which systems count as AI, which employees and contractors are bound, and whether the policy covers customer-facing products as well as internal tools.
Approved and prohibited tools. A maintained list of sanctioned applications, plus a process for requesting new ones.
Data handling rules. What categories of information may enter a model, and what must never be entered, including client data, source code, personally identifiable information, and trade secrets.
Acceptable and unacceptable use cases. Concrete examples of permitted tasks and tasks that require special approval or are banned outright.
Human review and accountability. Where a person must check AI output before it is used, and who owns the result.
Disclosure. When AI involvement must be labeled, internally or to customers.
Vendor and procurement requirements. Security and contractual checks before a new AI service is adopted.
Monitoring and enforcement. How compliance is tracked and what happens when the policy is violated.
The policy should be short enough that people read it, usually four to eight pages, with detailed standards and approved-tool lists kept in linked appendices that update more often than the core document.
Why does your organization need a written AI policy?
The case for writing it down comes from concrete exposure, not from following a trend.
Data leakage is the most immediate risk. Many consumer AI services may retain inputs to improve their models unless an enterprise agreement says otherwise. An employee who pastes a draft contract or a customer list into a public tool may have disclosed confidential information to a third party. A written rule that names which data categories are prohibited gives staff a clear line and gives the organization a basis for enforcement.
Regulatory pressure is rising. The EU AI Act classifies AI systems into risk tiers (unacceptable, high, limited, and minimal) and imposes obligations on providers and deployers of high-risk systems. Sector regulators in finance, healthcare, and employment are issuing guidance on automated decision-making. A policy that documents your controls is the artifact regulators and auditors will ask to see.
Output quality and liability are operational concerns. Generative models produce confident text that can be wrong, biased, or infringing. Without a human-review requirement, a fabricated citation or a discriminatory screening decision can reach a customer or a court. Studies on model error rates vary widely by task [stat to verify], which is why review requirements should be tied to the stakes of the output rather than to a single accuracy figure.
Consistency and speed are the upside. A policy does more than restrict. When employees know which tools are approved and which tasks are cleared, adoption moves faster because people stop guessing. The goal is to enable responsible use, not to prohibit AI while unsanctioned use grows.
What are the core sections of an internal AI policy template?
The template below is the base structure. Each section heading is followed by the question it answers and a short note on what to write. Replace the bracketed placeholders with your own decisions.
1. Purpose and scope
State why the policy exists and who it binds. Specify whether it applies to full-time staff, contractors, and vendors, and whether it covers both internally built and third-party AI. Name the systems in scope, including generative text and image tools, coding assistants, analytics models, and embedded AI features in existing software.
2. Definitions
Define artificial intelligence, generative AI, personal data, confidential information, and high-risk use in plain terms. Ambiguous definitions are where policies fail, because employees rationalize edge cases.
3. Roles and responsibilities
List the AI governance owner (often a steering committee or a named executive), the data protection officer, department managers, and individual users. State what each is accountable for. A policy without named owners has no force.
4. Approved tools and request process
Reference the maintained list of sanctioned tools held in an appendix. Describe how an employee requests approval for a new tool and how long review takes.
5. Data classification and handling
Tie permitted inputs to your existing data classification scheme. The table below is a common starting structure.
Data class: Public
Example: Published marketing copy.
Public AI tool: Allowed.
Approved enterprise tool: Allowed.
Data class: Internal
Example: Draft project plans.
Public AI tool: Prohibited.
Approved enterprise tool: Allowed with review.
Data class: Confidential
Example: Client contracts and financial records.
Public AI tool: Prohibited.
Approved enterprise tool: Allowed only within an approved private deployment.
Data class: Restricted
Example: Personally identifiable information (PII), health records, payment data, and source code.
Public AI tool: Prohibited.
Approved enterprise tool: Prohibited unless explicitly approved by the designated responsible role.
6. Acceptable and prohibited use
Give concrete examples. Acceptable: summarizing public documents, drafting first versions of internal copy, generating test data, explaining code. Prohibited without approval: making final hiring or firing decisions, producing legal or medical advice for external use, and generating content presented as human-authored where disclosure is required.
7. Human oversight and review
State which outputs require a person to verify before use, mapped to risk. Higher stakes call for stricter review.
8. Disclosure and transparency
Specify when AI use must be labeled. Many organizations require disclosure for customer-facing content and for any material that informs a consequential decision.
9. Security and vendor requirements
Require a security and data-processing review before any new AI vendor is onboarded, including where data is stored and whether inputs are used for training.
10. Monitoring, enforcement, and review
Describe how usage is monitored, the consequences of violations, and the schedule for reviewing the policy itself. A quarterly or semi-annual cycle is typical given how fast tools change.
How do you map the policy to NIST, ISO 42001, and the EU AI Act?
A policy carries more weight when it aligns to recognized standards, because that alignment is what auditors, customers, and regulators recognize. You do not need to adopt every standard. You need to show your controls correspond to established practice.
The NIST AI Risk Management Framework organizes work into four functions. Use them as a checklist for whether your policy is complete:
Govern. Are roles, accountability, and risk tolerance defined? This corresponds to your roles section.
Map. Do you identify the context and risks of each AI use case? This corresponds to your use-case classification.
Measure. Do you assess performance, bias, and error? This corresponds to your review and monitoring requirements.
Manage. Do you act on identified risks and document decisions? This corresponds to enforcement and the request process.
ISO/IEC 42001 specifies requirements for an AI management system, the organizational structure of policies, objectives, and continual improvement around AI. If you intend to certify, your internal policy becomes one documented control within that system.
The EU AI Act matters even for organizations outside the EU if they serve EU users. Its risk tiers tell you where to concentrate effort. A tool used for resume screening sits in a higher tier than a tool that drafts internal meeting notes, and your policy should require heavier review for the former.
The table below shows how the template sections line up with each standard.
Policy section: Roles and responsibilities
NIST AI RMF function: Govern.
ISO/IEC 42001 element: Leadership and organizational roles.
EU AI Act relevance: Defines the responsibilities of AI providers and deployers.
Policy section: Use-case classification
NIST AI RMF function: Map.
ISO/IEC 42001 element: Risk assessment.
EU AI Act relevance: Supports risk-tier categorization of AI systems.
Policy section: Human review
NIST AI RMF function: Measure.
ISO/IEC 42001 element: Performance evaluation.
EU AI Act relevance: Ensures human oversight for high-risk AI systems.
Policy section: Monitoring and enforcement
NIST AI RMF function: Manage.
ISO/IEC 42001 element: Continual improvement.
EU AI Act relevance: Supports post-market monitoring and ongoing compliance.
Policy section: Disclosure
NIST AI RMF function: Govern.
ISO/IEC 42001 element: Transparency controls.
EU AI Act relevance: Addresses AI transparency and disclosure obligations.
For principles to cite as your foundation, the OECD AI Principles offer a widely referenced statement of values, including human-centered, transparent, accountable, and secure, that reads well in a policy preamble.
How do you roll out and enforce the policy without killing adoption?
A policy that nobody reads or follows is worse than none, because it creates the appearance of control without the substance. Roll it out as a change-management effort, not a memo.
Draft with input from real teams. Pull two or three frequent AI users from different departments into the drafting. They will tell you which prohibitions are unworkable before you publish them.
Inventory current usage. Survey what tools people already use and for what. You cannot govern what you have not measured, and the inventory often reveals risks the policy then addresses.
Approve a starter toolset. Give employees a short list of sanctioned tools on day one. A policy that only prohibits, with no approved path, pushes usage out of view.
Train by role. A salesperson and a developer face different risks. Short, role-specific training works better than a single all-hands deck.
Make the compliant path the easy path. Provide enterprise accounts with data protections so the approved tool is also the better tool. Added effort is what produces unsanctioned use.
Set a review cadence. Assign an owner and a calendar date for the next revision. The tools will change within a quarter.
Track and report. Monitor usage and report adoption and incidents to leadership so the policy stays funded and credible.
Enforcement should be proportionate. A first accidental data-handling mistake calls for coaching and a clearer rule, not termination. Reserve formal discipline for deliberate or repeated violations involving restricted data. Heavy-handed enforcement on minor issues teaches people to hide their AI use, which defeats the purpose.
Next Steps
Use this checklist to move from zero to a published policy.
Name the policy owner and the approval body.
Inventory the AI tools employees are already using.
Map your data classification scheme to permitted AI inputs.
Draft the ten template sections, replacing every bracketed placeholder.
Approve a starter list of sanctioned tools with enterprise data protections.
Define human-review requirements tied to the risk of each use case.
Align controls to NIST AI RMF functions and note EU AI Act risk tiers where relevant.
Run role-specific training for the teams that use AI most.
Publish the policy, communicate it, and set the next review date.
Establish a usage-monitoring and incident-reporting routine.
Frequently Asked Questions
How long should an internal AI policy be?
Keep the core document to four to eight pages so people actually read it. Move volatile details, such as the approved-tool list, data-classification matrix, and request forms, into linked appendices. The appendices can update monthly without reopening the main policy, which usually needs revision only on a quarterly or semi-annual cycle.
Who should own the AI policy?
Ownership should sit with a named executive or a cross-functional steering committee, not solely with IT or legal. Effective ownership combines security, legal, data protection, and business leadership, because AI risk spans all of them. Whoever owns it must have authority to approve tools, set review requirements, and enforce consequences.
Does a small company need an AI policy?
Yes. Smaller organizations often have less negotiating power over vendor data terms and fewer security controls, which raises the stakes of an employee leaking data into a public tool. A short two-to-three-page policy with an approved-tool list and clear data rules covers most of the risk and takes a few days to draft.
How is an AI policy different from an AI governance framework?
A governance framework defines principles, oversight bodies, and risk appetite at the organizational level. The internal AI policy translates those principles into specific rules employees follow day to day: which tools, which data, which approvals. The framework sets direction, the policy sets behavior, and the two should reference each other.
How often should the policy be reviewed?
Review the core policy at least every six months, and the approved-tool appendix more frequently, because available tools and their data terms change quickly. Trigger an off-cycle review when a major new tool is adopted, a regulation takes effect, or an incident reveals a gap. Assign the review to a named owner with a calendar date so it does not lapse.
