What should an internal AI-use approval record contain?

An internal AI-use approval record should answer a simple question months later:

What did the person propose, which policy applied, what was decided, why was it decided, and what conditions had to be followed?

That requires more than an Approved label. It does not require a copy of every prompt, output, document, or conversation either.

The useful middle ground is a short decision record containing the proposed task, tool, information category, intended use, human review, applicable policy version, outcome, reasoning, safeguards, owner, and time. Higher-risk uses can link to deeper privacy, security, legal, procurement, or impact assessments.

Is an internal AI-use approval record legally required?

There is no universal law requiring every employee AI question to use one standard approval form.

The need to document a particular use depends on the organisation, jurisdiction, sector, information involved, people affected, and role of the AI system. An ordinary request to improve the wording of a public announcement is not the same as using AI to rank job applicants or analyse patient information.

However, several established governance sources point in the same direction:

• The voluntary NIST AI Risk Management Framework calls for documented roles, AI-system inventories, risk decisions, intended uses, impacts, human oversight, and continuing review.
• The UK Information Commissioner’s Office publishes an internal AI-use policy under which AI governance decisions are logged, risks have owners, AI functionality is inventoried, and deployments are assessed proportionately.
• The EU GDPR requires controllers to be able to demonstrate compliance, minimise personal data, maintain appropriate records of processing, and conduct a data protection impact assessment where processing is likely to create a high risk. These are separate obligations with different scopes, not a command to retain every employee prompt. See GDPR Articles 5, 30 and 35.
• Where the EU AI Act applies to deployers of high-risk AI systems, Article 26 includes obligations concerning human oversight, monitoring, automatically generated logs, workplace information, and support for applicable data protection impact assessments.

An internal approval record can support accountability. It does not replace an AI inventory, record of processing activities, data protection impact assessment, fundamental-rights impact assessment, vendor assessment, or the technical logs required for a particular system.

What is the record actually for?

A good record serves four practical purposes.

It gives the employee a usable answer

The employee should know whether the proposed use may continue, must stop, or needs review. If it may continue only under conditions, those conditions should be visible in the result.

It gives the reviewer enough context

The reviewer should not need to begin with a blank email asking which tool, account, information, or audience is involved. The request should arrive with the facts that caused the escalation.

It preserves the policy decision

Policies change. A later reader should be able to identify the exact policy version used, rather than judging an earlier decision against today’s wording.

It helps improve the policy

Repeated escalations can expose unclear tool rules, undefined information categories, missing owners, or safeguards employees do not understand. The record becomes feedback for the policy owner, not merely evidence that a form was completed.

The 12 parts of a useful AI-use approval record

The following is a practical minimum. The depth of each part should reflect the risk.

1. A stable record identity

Give every completed decision a unique reference. The identity should remain stable so an employee, reviewer, auditor, or support team can refer to the same record without emailing its full contents.

Also capture when the request was submitted and when the decision became final.

2. The requester and accountable business owner

Record who asked and which team owns the work. If a different person remains accountable for the final output, record that person or role too.

The requester, reviewer, and accountable owner may be different people. Keeping those roles separate avoids turning “a human will review it” into an undefined promise.

3. The proposed task and intended result

Describe the work in plain language:

Summarise an internal project plan into five discussion points for a team meeting.

That is more useful than “use ChatGPT.” The record should explain what AI will do and what the person wants to produce.

Keep this description concise. It should not contain the confidential document itself.

4. The AI tool, account, and relevant configuration

Identify the tool and how it will be accessed. The difference between a company-managed enterprise account and a personal account may change the policy result.

Where relevant, include the product, model or service tier, connected feature, and whether the tool appears on the approved-tool list. Do not assume that approving a vendor approves every future use of that vendor.

5. The information category

Record the highest relevant information classification, such as:

• public;
• internal;
• confidential company information;
• customer or client information;
• personal information;
• special-category or highly sensitive personal information; or
• credentials, secrets, source code, or security findings.

Record the category, not the sensitive material itself. An approval system should not become a second repository for the very information the policy is trying to protect.

6. The people and decisions affected

Record whether the output concerns employees, applicants, customers, patients, students, members of the public, or another group.

Also record whether AI is merely helping draft private material or influencing a consequential decision. Recruitment, performance, credit, insurance, healthcare, legal status, safety, and access to essential services deserve a different route from low-impact drafting.

7. The intended audience and action

An internal draft and an external decision are not interchangeable.

Record whether the output will remain private, be shared internally, go to a customer, be published, support a human decision, or trigger an automated action. This helps the policy distinguish reversible assistance from uses that can directly affect another person.

8. The human review that will occur

“Human in the loop” is too vague on its own.

The record should state:

• who will review the output;
• what they are expected to check;
• whether they have authority to reject or override it; and
• who remains responsible for the final work.

NIST’s framework specifically treats human-AI roles and oversight responsibilities as matters that should be defined and documented. Review should be meaningful, not ceremonial.

9. The policy and rule set applied

Record the policy name, fixed version, effective date, and relevant rule set.

This is what lets the organisation explain why two similar requests received different answers after a policy update. A link to a living document without a version is weaker because its contents may change after the decision.

10. The outcome, reasoning, and required safeguards

The result should be more precise than approved or rejected. A useful set of outcomes might include:

• allowed;
• allowed with safeguards;
• approval required;
• more information required; or
• not allowed.

Record the reason and the next step. If the use is conditional, list the conditions explicitly, for example:

• use only the company-managed account;
• remove customer identifiers before submission;
• verify every factual claim against an authoritative source;
• do not use the output to make the final employment decision; or
• obtain privacy review before continuing.

The final record should reflect the authoritative decision that was actually issued, not an earlier preview.

11. The reviewer, decision time, and scope

When a human decision is required, record who made it, their role, and when it was made.

Also define what was approved. An approval for one task, dataset, client, department, or pilot should not silently become permission for all uses of the tool.

Where appropriate, include an expiry date, review date, usage limit, or event that reopens the decision, such as a vendor change, new data source, new audience, policy update, or material change in the workflow.

12. The history of later changes

Do not overwrite the original decision without a trace.

If the request is clarified, approved with new conditions, withdrawn, revoked, or reviewed under a newer policy, retain the event history: what changed, who changed it, when, and why.

This is different from pretending that every decision is permanent. Retention and deletion still need a defined policy, but changes to a retained record should remain explainable.

A minimum viable example

For a routine workplace request, the finished record might read:

This is enough to understand the decision without storing the prompt, generated email, or source notes.

What should not be copied into the approval record?

More evidence is not always better evidence.

Avoid collecting the following by default:

• full prompts and outputs;
• uploaded documents;
• passwords, API keys, credentials, or authentication tokens;
• customer records or employee files;
• special-category personal information;
• privileged legal advice;
• confidential source code; or
• duplicate copies of vendor and policy documents.

Instead, store classifications, concise descriptions, stable references, and links to access-controlled assessments where a reviewer genuinely needs them.

This follows a basic data-minimisation principle: collect what the decision requires, not everything the employee could provide. The record itself creates privacy and security responsibilities, so access and retention should be designed before widespread use.

Do not force every governance document into one record

An employee’s per-use decision record is one layer of governance.

AI inventory

The inventory describes the organisation’s tools and systems: owner, vendor, intended uses, risk tier, lifecycle, and related assessments.

Vendor and security assessment

This evaluates the provider, contract, data handling, access, hosting, subprocessors, security, and procurement conditions.

Privacy and impact assessments

A DPIA, legitimate-interests assessment, equality assessment, or fundamental-rights impact assessment has its own scope and legal criteria. A short employee check can identify that one is needed or link to an existing assessment, but should not imitate one badly.

Technical system logs

Technical logs may record system events, operation, access, errors, and model activity. Under Article 26 of the EU AI Act, deployers of high-risk AI systems must retain automatically generated logs under their control for an appropriate period of at least six months, subject to other applicable law. That technical-log obligation is not the same as a per-use policy decision record.

Keeping these layers connected but separate makes each easier to maintain and gives access only to people who need it.

How long should the record be retained?

There is no responsible universal retention period for every organisation and use.

Set the period according to the purpose of the record, legal and contractual requirements, limitation periods, sensitivity, employee expectations, and need to investigate incidents or explain decisions. Different categories may need different periods.

The retention rule should answer:

• why the record is kept;
• who can access it;
• when it is reviewed or deleted;
• what happens when a legal hold applies; and
• whether a minimal deletion marker must remain after authorised deletion.

Do not choose “forever” merely because storage is inexpensive. Do not delete records immediately if doing so defeats the organisation’s stated accountability purpose.

Use proportional approval routes

Not every request should wait for a committee.

A mature process can resolve a low-risk use automatically when the tool, account, information, purpose, audience, and human review clearly fit the current policy. It can then route exceptions to the responsible manager, privacy lead, security team, legal adviser, HR owner, or another named reviewer.

The ICO’s own policy describes a fast-track route for sufficiently similar low-risk uses after relevant assessments. That is a useful design principle, not a universal template: make ordinary compliant work easy, and reserve specialist time for decisions that genuinely need it.

Our guide to who should approve AI use at work explains how to choose the route.

Turn the policy into a decision record, not another blank form

A static approval form can collect all 12 parts and still fail if employees must interpret the policy themselves.

The better workflow is:

1. Ask only for facts that can change the policy result.
2. Apply the organisation’s current published policy.
3. Resolve routine cases consistently.
4. Route uncertainty with the relevant context already attached.
5. Issue the authoritative result only when the check is completed.
6. Preserve the result against the exact policy version used.
7. Review recurring uncertainty and improve the next policy version.

Can I Use AI? turns a workplace AI policy into that guided process. Each completed check records the proposed use, relevant facts, policy answer, reasoning, safeguards, next step, and exact published policy version without requiring the employee to paste the underlying confidential material into the approval record.

This article provides general operational information, not legal advice. Organisations should determine their documentation, privacy, employment, retention, and AI-governance obligations for their own activities and jurisdictions.