Company AI use policy: rules and rollout

An AI use policy defines permitted uses, the data you can submit, the human checks required, and what to do when something goes wrong. To work in practice, it needs clear rules, a list of approved tools, and named people responsible for decisions. The examples below provide a starting point to adapt to your business, contracts, and applicable obligations.

Define the scope before writing the rules

Start by describing what the policy covers: writing, translation, research, document analysis, image generation, coding assistance, and automation. Include AI features built into software you already use, extensions, and browser-based services. Enabling a feature in an existing application deserves the same scrutiny as purchasing a new subscription.

Specify who the policy applies to: employees, executives, interns, and contractors working for the company. For external contributors, incorporate the relevant requirements into appropriate instructions and contracts. Publishing a policy on your intranet does not ensure that a subcontractor knows your rules.

Then organize the framework into separate documents:

the policy sets out principles and responsibilities;
the catalog lists approved tools and uses;
procedures explain how to request approval or report an incident;
guidance for specific roles gives examples of acceptable and prohibited uses.

This structure avoids rewriting the entire policy whenever a vendor changes its offering. Each document should have a date, a named owner, and a designated location for the current version.

Find out how people actually use AI before making decisions. Shadow AI, meaning AI tools used outside the organization’s established oversight, can also be identified by asking teams how they complete their work. The AI tool catalog organized by need can help you identify categories of use, but inclusion there does not mean your company has approved a tool.

Separate internal policy from legal compliance

The policy turns your decisions into working instructions. It does not replace reviewing a vendor contract, assessing the processing of personal data, or completing the steps required for a regulated use. Avoid any blanket statement suggesting that following the policy automatically makes every use legally compliant.

For activities in France and the European market, have relevant uses reviewed for data protection, employment law, confidentiality, intellectual property, and the EU AI Act. Obligations vary with the system, its purpose, and your role. The article AI Act: what changes for AI agents explores that last point further.

The European Commission explains that AI literacy measures should reflect the context, risks, and knowledge of the people involved. Its AI literacy FAQ, accessed on October 24, 2026, does not present reading a policy as a sufficient guarantee of preparedness.

Suggested rule: any project involving recruitment, assessment of individuals, health, credit, or another sensitive decision must undergo a review before use. General approval for a writing assistant does not cover these purposes.

Before incorporating the policy into your internal framework, have the applicable procedural requirements checked, particularly in light of its implications for employees. Clearly distinguish legal obligations, contractual commitments, and additional restrictions chosen by the company.

Classify data and approve specific uses

A workable rule addresses a concrete situation: which data, in which tool, for which task? Approval to use an application should never be treated as permission to upload every company document.

France’s data protection authority, the CNIL, recommends defining conditions of use and controlling the information entered into tools. Its guidance sheet for microenterprises and small and medium-sized businesses, accessed on October 24, 2026, provides a starting point for this internal policy.

The following table is an example of an internal classification scheme to adapt to your document management system.

Criterion	Public data	Internal data	Confidential data or data requiring stronger protection
Example	A brochure already published	A procedure that is not public	Customer file, health information, technical secret
Suggested use	In a tool approved for the task	In an explicitly authorized environment	Following a specific review, or prohibited depending on the circumstances
Check before submission	Confirm public status and usage rights	Remove unnecessary information	Check necessity, recipients, and safeguards
Generated output	Review before sharing	Retain the appropriate classification	Apply restrictions based on the information it contains

These categories overlap: personal data can be public, and commercial information can be confidential without identifying anyone. Never assume that processing information is permitted simply because it is available online.

Suggested rule: if you are unsure how a document should be classified, do not submit it. Ask the designated person to determine its classification. Removing a name does not always prevent identification: an unusual job title, an address, or detailed context may still reveal who someone is. Provide fictional examples that people can use during training.

Maintain a catalog of approved tools and configurations

The catalog should identify the service, subscription plan and contractual terms, work account, and permitted features. The same brand may offer different terms depending on the subscription, interface, or access method. Approval must therefore apply to a specific configuration.

For each entry, record the business owner, intended users, permitted data, and approved purposes. Include the conditions reviewed: conversation retention, possible use of data to improve models, deletion, administrator access, subprocessors, and transfers. If something remains unknown, record that uncertainty before making a decision.

Suggested rule: work activities must use company-approved accounts. Users may not independently enable an extension, document connection, or email access. Any addition that expands the data available to the tool or the actions it can perform requires fresh approval.

Plan for staff departures and service termination as well: remove access, revoke connections, transfer useful material, and delete data under the agreed rules. Shared accounts make these tasks harder and make it more difficult to determine who performed an action.

Locally installed tools also need review. Check outbound communications, updates, logs, and any remote services they use. Where a tool runs does not, by itself, tell you the full path your data takes.

To document that path, AI agents and the GDPR: what data leaves, and where does it go? provides useful supporting guidance for your catalog. Keep the contractual and technical evidence alongside the approval decision.

Write rules for verification and publication

A hallucination is a plausible response that is false or unsupported. The policy must explain what verification involves: finding a source, checking a calculation, comparing an answer with the original document, or testing a program. Reading a response to see whether it sounds natural does not perform those checks.

Suggested rule: any AI output used in a professional deliverable must receive a review proportionate to its potential consequences. The reviewer must have the expertise, time, and access to sources needed to perform that review. If those conditions are missing, the output cannot be treated as verified.

Apply this rule to individual tasks:

for a summary, check facts, qualifications, and omitted passages;
for a calculation, revisit the input data and verify the result independently;
for research, open the cited sources and check that they support the claims;
for code, review the changes and perform appropriate checks;
for a translation with legal or contractual implications, have the technical terms and stated obligations checked.

Address content rights as well. Users must be authorized to supply source documents and must check the conditions for reusing the output. A generated response is neither proof of ownership nor a guarantee that it contains no protected material.

Finally, define transparency rules: when to disclose AI assistance, who approves publication, and how to inform someone interacting with an automated system. These decisions must reflect applicable obligations and commitments to customers. Explicitly prohibit fabricated quotations, references, and testimonials.

Set boundaries for agents that can take action

An assistant that drafts a message and an agent that sends it have different consequences. For systems connected to files, business applications, or email, the policy must define permitted actions, recipients, and ways to stop the system.

Prompt injection includes placing malicious instructions in content the system reads. An incoming document or a webpage must not gain the authority to approve an action. The French cybersecurity agency ANSSI’s security recommendations for generative AI systems, accessed on October 24, 2026, provide a supporting technical framework.

Suggested rule: each agent receives only the access needed for its task. External messages, payments, deletions, and sensitive changes require an approval process defined before the agent starts. A general request to complete a task does not authorize changes to permissions.

The approval request must show the actual action: recipient, content, any amount involved, affected files, and expected consequences. A vague request to continue does not support informed review.

Also establish consumption limits, a suitable execution time limit, useful logs, and a named person who can suspend operation. Test access revocation and the return to a manual process before putting the system into production.

The policy states the requirements; technical teams must turn them into effective settings. The guide Securing an AI agent explains how to do this, while the Lab’s security assessment helps identify areas to examine.

Assign responsibilities and manage exceptions

Avoid placing all responsibility on the end user. The company chooses the tools, defines access, and organizes controls; users follow instructions, check matters within their expertise, and report difficulties. Human approval cannot compensate for poor organizational arrangements.

Define the roles, even if a small organization assigns several to the same person:

management approves the policy and decides what resources to allocate;
the business owner describes the task and accepts the results;
IT administers accounts, connections, and access;
security reviews technical risks and incidents;
legal, data protection, and human resources specialists contribute as the issues require.

Assign an owner and a backup for every approved use. Specify who can stop the service as well. A collective decision is difficult to enforce if nobody is responsible for putting it into practice.

Suggested rule: every exception must be requested before use, documented, and restricted to a defined scope. It must identify the purpose, data, users, compensating controls, decision-maker, and condition for ending the exception. It cannot override a legal or contractual obligation.

Make the status of pending requests clear: until approval is granted, the proposed use remains on hold. Still, provide an approved way to complete the work so that a slow procedure does not encourage people to bypass it.

Keep a record of rejected requests and the reasons for rejection. Repeated requests may reveal a business need that the current catalog does not address.

Prepare an incident reporting procedure people can use

The policy must explain what to do after a mistake without requiring users to know its legal classification first. A confidential attachment sent to the wrong service, a conversation link made public, or an unexpected agent action must be easy to report immediately.

Suggested rule: users must stop any operations that could make the incident worse, contact the designated reporting point, and preserve useful evidence according to the instructions they receive. They must not try to conceal the mistake by deleting records. They must not copy exposed data into another channel to explain the problem.

The reporting form can ask which service was involved, when the event occurred, what kind of information was affected, and what actions have already been taken. The appropriate teams then assess the exposure, remove access if necessary, and organize corrective measures.

For a personal data breach, the CNIL distinguishes between internal documentation, notification to the authority depending on the risk, and communication to affected individuals when there is a high risk, subject to applicable exceptions. Notification must, where feasible, occur no later than 72 hours after becoming aware of the breach: reference accessed on October 24, 2026, in the GDPR chapter published by the CNIL. This deadline is not a waiting period for internal reporting.

Once the incident has been handled, update settings and training examples. Conduct a factual review that addresses the underlying cause, beyond the individual mistake alone.

Roll out the policy in stages

The prerequisite is a rollout owner with an initial catalog, a support channel, and contacts for sensitive questions. The guide Deploying AI agents in your company places this work within the broader organization of a project.

Identify current practices. Ask teams about the tasks, data, and connections they use. Look for AI features built into existing software as well.
Write concrete rules. For each common situation, state what is permitted, prohibited, or subject to approval. Check with users that the wording is clear.
Have the framework reviewed. Check technical, contractual, employment, and data protection issues. Resolve gaps between the written rules and what the tools actually support.
Run a limited pilot. Use representative tasks with information appropriate to the approved scope. Observe errors, requests for help, and the time needed for verification.
Train people before expanding. Have users practice spotting an invented source, classifying a document, and reporting an incident. A record showing that someone has read the policy does not measure these abilities.
Publish and revise. Make the current version easy to find, announce changes, and withdraw outdated documents.

Choose useful measures: quality after verification, corrections needed, incidents, exception requests, and total costs. The number of accounts created describes access to the service, not its usefulness. Include checking and rework when measuring time spent.

Common problems and checks before publication

The rules remain abstract. Replace general appeals to caution or ethics with observable situations. An instruction should help someone decide whether they can submit a document or share a response.

The catalog does not reflect actual work. Identify needs without an approved solution, then offer an alternative or a review process. A ban that leaves people unable to complete their work encourages hidden use.

Human approval becomes a formality. Check that reviewers have the information they need and can reject or stop an action. If results arrive too quickly to examine, reduce the scope or pace.

Logs create another source of exposure. Define what they contain, who can access them, and how long they are retained. Explain the monitoring to the people concerned; collecting every conversation is not a security policy in itself.

Nobody reviews approvals. Require a new review when contracts, connections, purposes, or data categories change. Previous approval does not automatically cover an expanded use.

Before publication, check the following:

The scope and people covered are defined.
Approved uses are tied to identified configurations.
Data submission rules include examples.
Human checks are practical and assigned to named people.
Agent actions have limits and a way to stop them.
Reporting, exceptions, and responsibilities are documented.
Training includes exercises suited to people’s roles.
The current version, its owner, and review conditions are visible.

Frequently asked questions

Does every company need an AI use policy?

A document called an AI use policy is separate from the obligations that apply to your use of AI. Those obligations depend on factors such as data processing, the systems involved, and the workplace context. A policy helps organize your response, but signing it does not establish compliance across the board.

Who should write an AI use policy for a small business?

Management can appoint someone to coordinate the work with the people responsible for IT, human resources, and data protection. Employees who use the tools should contribute so the rules reflect actual working practices. Sensitive legal questions require review by someone with the appropriate expertise.

Can employees use personal AI accounts for work?

Your policy should give an explicit answer. A cautious approach is to restrict work use to accounts approved and managed by the company. Any exception should specify which data is permitted and what deletion requirements apply.

Do you have to disclose AI use on every document?

A blanket disclosure requirement depends on your internal policy, contractual commitments, and the obligations that apply to the content. Distinguish between basic proofreading, substantial content generation, and automated interaction with a person. Any disclosure should accurately explain the AI’s role in clear language.

How do you keep an AI use policy current as tools change?

Keep lasting principles in the policy and settings that change in managed appendices. Changes to a connector, contract, or permitted data category should trigger a review. Users should be able to find the current rule without searching through outdated attachments.

Writing your company’s AI use policy: what to include, sample rules, and rollout