Questions to Ask When Drafting an AI Policy

The request that exposes a gap in your AI policy rarely comes through procurement. It arrives from a subsidiary in another country, from a lawyer who used a generative tool to summarize a dispute, or from a business team whose output fed a commercial decision. By the time anyone asks who approved the tool, what data it processed, and where the review is recorded, the answer is usually: no one knows. The questions to ask when drafting an AI policy are not primarily technical. They are organizational, and they need to be answered before the first sentence of the policy is written.

An AI policy built on principles alone fails on the first real request. The sections below give legal departments a structured set of questions to work through, organized by the decisions the policy must actually govern.

What AI is the organization actually using?

Your policy should cover how the organization acquires, configures, uses, monitors, reviews, and retires AI systems. That scope is wider than most first drafts assume. It includes generative tools employees open directly and AI features built into software the organization already approves. If the policy governs only tools with a purchase order, it governs a fraction of the real exposure.

A legal team may use an AI function inside a document tool without treating it as a separate purchase. A subsidiary may have adopted a tool that never reached the group’s procurement process. Shadow AI is not a technology problem; it is a visibility problem, and the policy must address it before setting any rules.

Questions about the lifecycle

• Which AI systems are developed, bought, configured, deployed, or used by the organization, including features embedded in approved software?
• At what point does the policy apply, from first assessment through retirement?
• Which risks must be governed centrally, and which require local review by the relevant entity?
• What evidence must be kept for the life of each system?
• Who can pause or retire a system when its use, data, or risk profile changes?

Questions about scope

State clearly who must follow the policy. That typically means employees, temporary workers, contractors, consultants, vendors, outside counsel, and other third parties acting on behalf of the organization. A supplier using AI within a service it delivers may fall within scope even if no internal staff touches that system directly. For every use, ask which entity owns it, which jurisdictions and sector rules may apply, which business activity it supports, whether a third party runs part of the process, and who remains accountable for the result.

Which decisions does each AI output feed?

The most useful question when mapping AI use is not “what does the tool do?” but “which decision does this output feed, and who is responsible for it?” Start with the work people actually do, including informal uses that never reached procurement, legal, security, or privacy. Generic rules fail in practice. A rule that permits “approved AI tools for low-risk work” does not tell anyone whether a contract summary, a hiring shortlist, or an internal investigation falls into that category.

For each use case, establish whether it is operating, planned, or informal; what task the system performs and what it is intended for; who owns the business outcome and who approves the use; who may be affected by the result; and where the final decision is recorded. Then ask what happens if the system is wrong, biased, manipulated, unavailable, or trusted more than it deserves. Decisions that touch employment, access to services, pricing, legal rights, financial commitments, or external statements need the strictest attention. Write rules based on use, give each one a named owner, and define a review point.

Can you see every AI use before you set permissions?

Sensible permissions cannot be set for uses that are not visible. Build the inventory first, then test it against real workflows rather than procurement records or self-declarations alone. Each entry should record the tool, its supplier, and its business owner; the approving authority, approval status, and any restrictions; the purpose and the business process it supports; the users, affected people, and relevant roles; the data categories and their sensitivity; the entity, jurisdictions, connected systems, and third parties involved; and the human review points, escalation path, and date of the last risk assessment.

Give employees and partners a clear channel to declare a tool or use case. They describe the information involved and request a decision. Disclosure should not become a disciplinary trap by default. Classify the use, set an interim restriction where needed, and name who owns the follow-up. If the risk is material, suspend the activity and preserve the relevant facts.

How should permissions be structured?

Separate permitted use, use requiring approval, and prohibited use. The distinction depends on the task, the information involved, the people affected, the level of autonomy granted to the system, and the cost of an error. It does not depend on whether a tool is popular or already in use elsewhere in the group.

Define permissions across five elements: the action (summarize, classify, draft, recommend, decide, or act autonomously); the information (public, internal, confidential, personal, privileged, or restricted); the recipients (internal users, customers, regulators, suppliers, or the public); the autonomy level (advisory output, required human approval, or limited authorized action); and the evidence required (input, output, reviewer, approval, exception, and final decision).

“Human in the loop” is not a control on its own. Ask what the human must verify. Ask whether they can change the result. Ask whether they have the authority to reject it. Require the strictest review wherever an output affects employment, access to services, pricing, legal rights, financial commitments, safety, or external statements. Define when a second reviewer or local entity approval is required, and record every override with the reason and the person who made the final call.

Plan for incidents

Define the reporting channel, what a report must capture, the response owner, and the preservation steps. A report should capture the system and the user involved, the entity and the jurisdiction, the information processed and the output produced, the decision taken and the people affected, and the immediate action taken. Set rules for suspension and return to service. The response owner decides whether to stop a workflow, restrict a user, notify stakeholders, or assess legal duties. The authorized approver confirms resumption once controls are restored.

What information rules apply to AI use?

Information rules should follow the data categories your workflows actually use. A general ban on “sensitive information” is difficult to apply because employees often cannot tell whether a document contains personal data, trade secrets, privileged material, or third-party restrictions. For each category, decide whether it is allowed without extra approval, allowed only in an approved tool, allowed after masking or aggregation, restricted to a named use and user group, or prohibited unless a designated authority approves it.

Review the tool’s access rights. Check retention and deletion terms, security controls, and subcontractors. Confirm incident notification provisions, audit rights, data location, and the permitted use of inputs and outputs. Direct users to the approved procurement and security process for supplier review rather than letting each team interpret supplier terms independently. For legal work specifically, require that any cited authority is verified to exist, is current in the relevant jurisdiction, and applies to the entity and facts involved. A generated output can support drafting without being ready for external use. Separate drafting support from approved communications, legal advice, business decisions, filings, contract terms, and commitments.

How does the AI policy connect to existing governance?

An AI policy should connect to existing controls rather than create a parallel rulebook. Link it to security, privacy, records retention, acceptable use, procurement, employment, legal review, incident response, continuity planning, and information classification. Ask which existing policy governs each decision: security may own access and technical testing; privacy may own personal data assessments; legal may review contractual, regulatory, and intellectual property issues; procurement may approve suppliers; and business owners remain accountable for the process and its outcome.

For a group operating across multiple entities, the policy must separate central decisions from local ones. The group may approve common tools, minimum controls, and shared records. A local entity still needs to approve a use where its workforce, data, sector, regulator, or customer obligations differ from the group baseline. The issue is not whether to centralize or decentralize. It is knowing which decisions belong at each level and making that explicit in the policy.

Name people or roles, not only departments. A policy that assigns a task to “Legal” or “IT” still leaves no decision-maker, no escalation route, and no one responsible for keeping it current. Every exception needs an authorized requester, a documented reason, defined controls, an expiry date, and a review date. An exception without an end date quietly becomes policy.

Who owns each part of the AI governance process?

Each recurring activity needs a named owner, not a department. Assign one person or role for the inventory, use-case assessment, approvals, exceptions, training, incident handling, evidence retention, and periodic review. An executive sponsor, such as the Group General Counsel, sets risk appetite and resolves material conflicts. A legal operations or AI governance lead runs the process day to day. Local legal, privacy, security, HR, procurement, and business owners make decisions within their own authority.

Give employees and partners one channel for questions and reports covering inaccurate outputs, unauthorized data entry, discriminatory impact, security issues, supplier changes, and uses the inventory does not yet cover. Choose a periodic review interval and add event-based triggers on top of it. Reopen the policy after a material change in a system, supplier, data category, or jurisdiction; after an incident; after a new use case or a new jurisdiction; after a major process change; or after a shift in assessed risk.

How do you know the policy works before publishing it?

Test the policy on one full workflow before publishing it across the group. Take a request from a subsidiary and follow it through every step. Identify the entity and jurisdiction. Name the tool and the information involved. Apply the permissions. Assign the reviewer. Record the decision. Preserve the evidence. A legal intake request is a useful test case: an AI function classifies it, a legal operations team routes it, a lawyer reviews the generated summary, and the responsible legal lead approves the response. The test should show which rule applies at each step and where the final decision is stored.

Publish the group baseline where employees and third parties can actually find it. Send local questions to named owners. Tie every local addition back to the common policy. The real aim is not a document describing an ideal process. It is a working control system that shows what the organization permits, who decides, what information may be used, when a person must intervene, and where the evidence lives. Keep the unanswered questions beside the draft: those gaps show where the policy still rests on assumptions, and they are the first items to close before the draft goes for approval.

How Alf supports AI governance in legal departments

Alf is the operating infrastructure for global legal departments: it connects people, processes, knowledge and AI agents in one governed system. The challenge most legal departments face when drafting an AI policy is not a shortage of principles. It is the absence of an operational layer that makes those principles enforceable across entities, jurisdictions, and teams.

Alf is designed to provide that layer. Features include configurable workflows and forms that translate group-level rules into entity-specific approval steps, a chronological history for each dossier that records who reviewed what and when, role-based access rights that reflect the permission structure the policy defines, and an AI agent that operates within the context of each dossier rather than outside it. When a validation is required before an AI output can move forward, that requirement is built into the workflow, not left to individual judgment. Recorded validations and decisions make it possible to respond when a regulator, a client, or leadership asks how AI was used on a matter.

For a group managing AI governance across multiple entities, Alf is built to let the center set the baseline while local teams apply their own requirements within it. A new entity joins the existing operating model rather than rebuilding its own process from scratch. The more autonomous AI agents become, the more the organizational context in which they operate matters. Scale legal operations without scaling complexity.

Frequently asked questions

Who should approve an AI use case in a group with multiple entities?

The business owner proposes the use and remains accountable for the process and its outcome. Each function approves the risks within its own authority: security for access and technical controls, privacy for personal data assessments, legal for contractual and regulatory issues, and procurement for supplier terms. High-risk uses need an approver who can require changes, impose conditions, reject the use, or suspend it later.

In a multi-entity group, the group level sets the baseline and escalation threshold. The local entity approves uses where its workforce, data, sector, or regulatory obligations differ from the group standard. Record the decision, any conditions, the exception period if applicable, and the next review date. A policy that assigns approval to a department without naming a role or person leaves no one accountable when a decision is needed.

How often should an AI policy be reviewed?

Set a regular review cycle, then add event-based triggers on top of it. A periodic review ensures the policy keeps pace with how AI use in the organization evolves. Event-based triggers ensure it responds to changes that cannot wait for the next scheduled review.

Reopen the policy after a material change in a system, supplier, data category, or jurisdiction; after an incident; after a new use case is approved; after a major process change; or after a shift in assessed risk. Keep the inventory, approvals, exceptions, training records, and review dates linked so that a change in one area surfaces the need to update the others.

What should an AI policy say about AI-generated outputs?

The policy should make the person who approves and uses an output responsible for the decision or communication, not the tool. Require verification of facts, sources, calculations, and legal authorities before professional use. Keep records of who reviewed what and when. A generated output can support drafting without being ready for external use, and the policy should draw that line explicitly.

Separate drafting support from approved communications, legal advice, business decisions, filings, contract terms, and commitments. For legal work, require that any cited authority is verified to exist, is current in the relevant jurisdiction, and applies to the entity and facts involved. The reviewer must have read the underlying document, not only the AI summary of it.

Does an AI policy need to vary by jurisdiction?

A group AI policy sets the baseline that applies across all entities. But local entities operate under their own legal frameworks, sector rules, and regulatory obligations, and those differences affect how the group policy is applied in practice. What is permitted at the group level may require additional approval, additional controls, or a different review process in a specific jurisdiction.

The policy should identify which decisions the group makes centrally and which require local entity approval. It should also require local entities to document where their requirements differ from the group baseline and to name the owner responsible for managing those differences. Treating the group policy as a complete rulebook for every jurisdiction is one of the most common drafting errors.

How does Alf help legal departments implement an AI governance policy?

Alf is designed to give legal departments the operational infrastructure to make an AI governance policy work in practice rather than on paper. Features include configurable workflows that translate group-level rules into entity-specific approval steps, role-based access rights that reflect the permission structure the policy defines, and a chronological history for each dossier that records who reviewed what and when. The AI agent in Alf operates within the context of each dossier, with defined boundaries on what it can do, on which data, and up to which threshold before a human must intervene.

For groups managing AI governance across multiple entities, Alf is built to let the center set the baseline while local teams apply their own requirements within it. Recorded validations and decisions make it possible to respond when a regulator, a client, or leadership asks how AI was used on a matter. Legal departments using Alf include Air France, SNCF, ENGIE Home Services, and CCI Paris Île-de-France.