An AI-use request form should collect the facts that can change the company’s answer. It should ask about the task, tool, account, information, intended use, human review, frequency, business owner, and relevant region.
That sounds obvious until you try to build the form. The first version usually asks too little, such as “Which AI tool do you want to use?” The next version asks everything the governance team could ever want and becomes a procurement questionnaire.
While building the request flow in Can I Use AI?, I found a better boundary: one form describes one proposed use. The employee should be able to finish it in a couple of minutes. Tool assessments, contracts, and lengthy risk reviews can remain separate and be referenced when needed.
Start with the proposed work
Ask the employee to describe what they want AI to help with and what result they expect. “Use ChatGPT” is too broad. “Summarise customer-support conversations to identify recurring issues” gives the policy something concrete to assess.
The description should stay short. It needs enough detail to distinguish the use from another one, without inviting the employee to paste the customer conversations into the request itself.
Two supporting fields make the request easier to own:
- the team or business area responsible for the work;
- whether the use is one-off, occasional, recurring, or embedded in a process.
Frequency matters because an acceptable experiment can become a very different operational commitment when it runs every day.
Ask for the tool and account together
A product name alone rarely settles the question. The same AI service may be available through a personal account, a free public account, a company-managed workspace, or an internal deployment.
The form should ask:
- which tool will be used;
- whether the company has approved it;
- who manages the account;
- whether the employee is unsure about any of those facts.
Uncertainty should be a valid answer. It gives the policy a clean route to security or the policy owner instead of rewarding a guess.
Classify the most sensitive information involved
Do not make employees list every field in a document. Ask them to choose the highest sensitivity the AI will receive.
A practical set of choices is:
- Public information.
- Ordinary internal information.
- Personal or customer information.
- Highly sensitive information, such as health, biometric, financial, or legal material.
- Secrets or security details, such as passwords, access keys, unreleased source code, or trade secrets.
The examples matter more than the category names. People can answer “Does this include a customer case or employee note?” more reliably than they can interpret an unexplained internal classification label.
Our guide to confidential information in AI tools explains why removing a name may still leave identifying or protected details.
Separate purpose from impact
I initially treated “what are you doing?” as one question. That hides an important distinction.
The purpose describes the AI activity: brainstorming, drafting, translating, summarising, analysing, or training an external model. The impact describes what happens with the output: a private draft, ordinary internal work, external publication, an employment process, an important service decision, or legal, health, or safety guidance.
The same purpose can produce different answers. Drafting an internal outline and drafting a message that will be sent to customers both involve writing. The second use creates an external commitment and usually needs stronger review.
Make human review specific
Ask what review will happen before the output is used. Useful choices include complete review, partial review, or no review.
The policy can then define what complete review means. A responsible person should see the relevant output, understand the subject, and have authority to change, reject, or stop it. Clicking an acknowledgement after an automated action is a different state.
Ask where the work is connected
Region can depend on where the employee works, where information comes from, where affected people are located, or where the output will be used. Give employees an option for “more than one region” and an option for “not sure.”
The form should never force someone to select a confident jurisdiction when the facts are unclear. Route uncertainty to the policy owner and collect the missing detail there.
What should the form produce?
Submission is the start of the decision process. The company policy should return one of a small number of useful paths:
- allowed;
- allowed with named safeguards;
- approval required from a named role;
- another approach required;
- more information needed.
If approval is required, the reviewer should receive the request facts already collected. If the request is resolved, the finished record should preserve the outcome, explanation, policy version, and later changes. The AI-use approval record guide covers that second stage.
Keep the request smaller than the governance system
An employee request does not need to contain the vendor assessment, contract, training record, model card, or every policy clause. Those are related governance objects with different owners and lifecycles.
The request has one job: describe a proposed use well enough for the current policy to resolve it or send it to the right person.
Can I Use AI? turns those fields into an employee request, applies the company’s published policy, and keeps the final decision tied to the exact policy version used.
This article provides general operational guidance. The fields and approval routes should reflect your organisation’s work, contracts, jurisdictions, and professional advice.