How to write a generative AI use policy for your company

AI policies usually fail for one of two reasons. Either they’re written like a contract, and no one reads them, or like a list of prohibitions, and everyone works around them. The policy that works reads more like a user guide than a rulebook, and it starts with a decision that comes before the text: who owns it. Without an owner, no one updates the list of tools, no one answers questions and the document ages within a few months.

What follows is a working structure, not a legal opinion. Before publishing, legal and the privacy team (including the data protection officer, if the company has one) need to review the text.

Principles of a policy that works

• Enable before you prohibit: say first what’s allowed, with which tool and for what. The prohibitions come afterwards, few and clear.
• Plain language: if an intern and a director understand different things, rewrite it.
• Short: a few pages in the main body. Technical detail goes into appendices and supporting guides.
• With examples: "don’t paste the salary spreadsheet" teaches more than "don’t enter sensitive data".
• With an owner and a review date: tools and risks change fast, and the policy needs to keep up.
• Consistent with what already exists: information security, privacy, the code of conduct and client contracts.

A policy template to copy

This is the order of sections that usually works. Each one fits in a few lines:

1. Purpose: why the company wants people to use AI, and with what care. Two or three sentences, no jargon.
2. Who it applies to: employees, interns, contractors and service providers with access to the company’s systems or data.
3. Approved tools: the list, always in the enterprise version, and the path to request an evaluation of a new one (whom to ask and who decides).
4. Allowed and prohibited data: the company’s classification applied to AI, with concrete examples for each level.
5. Accountability and review: whoever uses AI is accountable for the deliverable as if they had done it alone, and certain deliverables require review by a second person.
6. Transparency: when to tell colleagues and clients that AI was used, and how.
7. Intellectual property and third-party content: what can’t be pasted (material under confidentiality, copyrighted content) and the care needed with what’s generated for external use.
8. Client data: only what the client contract allows, and only in the tool approved for it.
9. Agents and integrations: connecting AI to email, drives, the CRM or internal systems requires prior approval and minimum permissions.
10. Where to ask questions: a channel and a person responsible, with a short response time.
11. Review date: when the policy will be reviewed and by whom.

A three-level data classification

The data section is the one that raises the most questions day to day, and the simplest way to settle it is to tie each level to a usage rule:

• Public: information already published or unrelated to the company, such as text published on the website or a general-knowledge question. It can go into any approved tool.
• Internal: company information that isn’t public but isn’t critical, such as agendas, processes and presentations without sensitive numbers. Only in the approved enterprise tool.
• Restricted: sensitive personal data, client data protected by contract, undisclosed financial results, negotiations, mergers and acquisitions, passwords and credentials. It doesn’t go into any tool without a formally approved exception.

If the company already has an information classification, use the same one and add only what applies to AI. The guide on how to use AI without exposing confidential data goes deeper into the habits that sustain this rule in an executive’s daily work.

Data protection law and sensitive personal data

In practice, pasting a résumé, a client spreadsheet or a customer service record into an AI tool is a way of processing personal data, and data protection law applies to it as it does to any other system. In Brazil, that’s the General Personal Data Protection Law (LGPD). The law pays special attention to sensitive personal data: racial or ethnic origin, religious belief, political opinion, union membership, data concerning health or sex life, and genetic or biometric data.

The policy should name these categories outright, because they show up in ordinary places: medical certificates and reports in HR, engagement surveys, medical records, registrations with biometrics. Questions such as legal basis, purpose and retention belong with legal and the data protection officer, not with the AI policy alone.

When the company needs more than a policy

The policy is the first step of governance, not the last. When AI becomes part of processes, products or decisions that affect clients, the company needs more structured risk management. Two references help organize that step:

• NIST AI RMF: NIST’s AI risk management framework is organized into four functions: Govern, Map, Measure and Manage. The same page has the generative AI profile, NIST AI 600-1, published in July 2024.
• ISO/IEC 42001:2023: the standard sets requirements for an AI management system, for organizations that provide or use AI.

Deciding how far to go is senior leadership’s job, and a committee helps make that decision with method. The guide on how to set up an AI committee with senior leadership shows who sits on it and what it decides. At Almai, governance and security are among the topics of the Advanced Modules.

How to roll it out so it doesn’t become a forgotten document

A policy posted on the intranet and never discussed doesn’t change behavior. The rollout weighs as much as the text:

1. Leadership communicates it: the announcement comes from the board, in person, explaining why the company wants people to use AI and where the limits are.
2. Leadership sets the example: directors use the approved tools, in enterprise accounts, in full view of the team.
3. Short, practical training: examples from each area’s daily work, with what can and can’t be pasted.
4. A channel for questions: with someone who answers quickly. An unanswered question becomes hidden use.
5. Periodic review: the questions received and the incidents feed the next version.

AI doesn’t start with the tool. It starts with leadership.

In Almai’s view, the policy only takes hold when the board works with AI within it; without that example, it becomes a rule for everyone else. For companies that operate or sell in the European Union, there’s one more reason to take training seriously: Article 4 of the AI Act, the EU’s AI regulation, in effect since February 2, 2025, requires providers and deployers of AI systems to take measures to ensure a sufficient level of AI literacy among their staff.

Common mistakes

• Copying another company’s policy: the tools, the data and the clients are different.
• Prohibiting without offering an alternative: without an approved tool, the policy pushes use onto personal accounts, the scenario described in the guide on the team that uses AI in secret.
• Writing in legalese: the text protects the company on paper and guides no one in practice.
• Forgetting agents and integrations: the risk changes when AI starts reading email and accessing systems.
• Publishing and never reviewing: before long, the list of tools no longer matches what the team uses.