Usage Policy and Governance

When one person uses AI, mistakes stay small. When a team does, without shared rules, the same mistakes multiply, and nobody knows who is responsible. In this lesson you will learn to write a clear, short usage policy, define roles, train people, handle incidents and deal with the reality of "shadow AI", the tools people use without telling anyone.

So far you have built your own way of working with AI. In this chapter, you move from personal use to collective use: a team, a department or a small company. We start with the foundation that makes everything else possible: shared rules.

Nadia discovers shadow AI

During a coffee break, Nadia learns that three colleagues in different departments use free chatbot accounts to draft documents. One of them pasted part of an employee survey with comments into it. Nobody did it with bad intentions; there was no rule, no approved tool and no training. Nadia's director now asks her to propose "something simple" before the situation gets worse.

This is a very common story. When people feel that AI makes them more efficient and the organization offers no framework, they use whatever is available. This is often called shadow AI, by analogy with "shadow IT". Banning everything usually pushes the use further underground; the answer is to provide clear rules and approved tools.

What a good usage policy contains

A policy is not a thick legal document. A good one is short enough to be read, clear enough to be applied, and updated when things change. For a small organization, one or two pages are enough. Here are the building blocks.

1. Purpose and scope

Who does this apply to (employees, interns, contractors)? What does it cover (generative AI assistants, plug-ins, built-in AI features in other software)? Why does it exist (to benefit from AI safely)?

2. Approved tools

A list of tools that may be used for work, with their purposes and any conditions (for example, "only with the business account", "no file uploads"). Also say how to request a new tool and who decides.

3. Data rules

The most important part. Use the traffic-light model from chapter 1:

Category	Examples	Rule
Allowed	Public information, your own generic texts, anonymized examples	Any approved tool
Conditional	Internal documents, non-public plans, anonymized customer cases	Approved tool only, minimal data, anonymized where possible
Forbidden without explicit authorization	Personal data about identifiable people, health, HR files, credentials, trade secrets, data under professional secrecy	Not entered into AI tools unless that tool and use were specifically authorized

4. Human validation

State which outputs must be reviewed and by whom. A simple version: "Nothing generated by AI is sent outside the organization, published or used for a decision without a human having read and validated it. The person who sends or signs is responsible." Add stricter rules for sensitive outputs (legal, financial, HR, safety, medical).

5. Transparency and traceability

When must AI use be mentioned (to a client, in a publication, in a deliverable)? What do you keep as a record (the prompt, the version, who validated)? Traceability does not mean surveillance; it means you can reconstruct what happened when there is a question or an incident.

6. Prohibited uses

For example: making decisions about people without human judgment, creating misleading content (fake reviews, impersonation), processing special categories of personal data in unapproved tools, or bypassing security controls.

7. Contacts, incidents and review

Who can be asked questions? How to report a mistake, a leak or a worrying result? How often is the policy reviewed?

A ready-to-use prompt: draft a one-page policy

Help me draft a one-page AI usage policy for [type and size of organization, e.g. a company of 80 employees in services].
Information about our situation: approved tools: [list or "none yet"]; types of data we handle: [categories, no real examples]; sensitive areas: [e.g. HR, customer files]; who validates: [role].
Structure it in 7 short sections: purpose and scope; approved tools; data rules (allowed, conditional, forbidden); human validation; transparency and traceability; prohibited uses; contacts, incidents and review.
Use simple, direct language. Write rules as concrete statements, not principles. Do not claim legal obligations: where a legal point is relevant, write [to be checked by legal or data protection contact]. At the end, list 5 questions my management should decide before this policy is final.

Use the draft as a starting point only. Then adapt it to your reality and have it reviewed by the people who are accountable for data protection, security and legal matters in your organization.

Roles and responsibilities

Rules without owners do not work. Even in a small organization, make these roles explicit (one person can have several):

• Sponsor: a manager who supports the initiative and arbitrates.
• Policy owner: keeps the policy up to date and answers questions.
• Data protection and security contacts: advise on data, tools and risks.
• Team referents ("AI champions"): colleagues who help others, collect good practices and report problems.
• Every user: responsible for what they enter and what they send.

Training and AI literacy

Rules are useless if people do not understand them. Training should be practical, short and repeated: what AI can and cannot do, how to write and verify, what data never goes in, and what to do in case of doubt. The European regulation on AI (the "AI Act") also includes an obligation for organizations that provide or use AI systems to take measures to ensure a sufficient level of AI literacy among their staff, in proportion to context and use. The application dates and details of the regulation are phased, so check the official text on EUR-Lex and the guidance of the competent authorities, and ask your legal contact what applies to you. Whatever the legal position, training people is simply good management.

Incidents

Mistakes will happen: a wrong figure sent to a client, a document pasted in the wrong tool, a generated text that offends someone. What matters is that people report them early, without fear of blame, so you can limit damage. Define a simple procedure:

1. Stop: stop using the tool for that task and keep the evidence (prompt, output, date).
2. Report: inform the named contact immediately.
3. Assess: what data or decision is concerned? Is personal data involved? (If so, the data protection contact assesses obligations, including possible notification to the authority and to the people concerned within the timeframes set by the GDPR.)
4. Correct: fix the output, inform those affected, delete what can be deleted.
5. Learn: update the rules, the training or the prompt library.

Dealing with shadow AI in practice

• Ask, don't accuse: run an anonymous survey or open discussion about which tools people use and for what.
• Offer an approved alternative for the real needs you discovered.
• Give an amnesty period for declaring past uses, then apply the rules.
• Make the right way the easy way: a simple request process, a good prompt library, quick answers.
• Review regularly: tools and features change, so the list of approved tools should too.

Bad use versus good use

Bad practice	Good practice
Banning all AI tools with a one-line memo.	Approving suitable tools, defining clear data rules and training people.
A 30-page policy that nobody reads.	One or two pages, concrete examples, reviewed regularly.
Blaming the person who reports an incident.	Treating incident reports as a source of learning and thanking those who report early.

Your turn: write your charter draft

Exercise. Draft a one-page usage charter for your team (or for yourself if you work alone), using the seven sections. Use the prompt above for a first version, then reduce it to the rules you really intend to apply. Add three concrete examples: one that is allowed, one that is conditional and one that is forbidden. Finally, write the incident procedure in five lines.

See a solution

A short excerpt of Nadia's charter: "Approved tool: the business account provided by IT; no personal accounts for work. Data: Allowed: a generic job description. Conditional: an anonymized summary of survey results (no verbatim comments). Forbidden without explicit authorization: anything about an identifiable employee or candidate. Validation: whoever sends or publishes a text generated with AI has read it and checked the facts and is responsible for it. Incident: stop, keep the evidence, tell Nadia and the IT contact the same day."

She adds one question for the management committee: "Do we want to authorize an approved tool for HR files, and under what conditions?", which she cannot decide alone and which needs the data protection contact and legal input. Naming a decision as not yet taken is part of a good draft.