How Should a Company Approve Employee Use of Generative AI?

Approve a defined use of an AI service: the employee task, permitted information, account and product edition, connected systems, output destination and required review. Grant permission only when those conditions are supportable, and name who can suspend it when they change. A place on an approved-tools list should never silently authorize every task that the product can perform.

I would begin with the work, because a product can be suitable for drafting a public announcement and unsuitable for processing a confidential personnel file under the same configuration. The relevant decision is whether a particular arrangement is acceptable. Security features, contractual permissions and the reliability of the resulting work all matter, but they answer different questions.

This paper develops an organizational admission and continuing-approval method. It synthesizes twelve checked sources, including one research meta-analysis, and uses an invented workflow and workload calculation. It does not report an organizational trial, certify a vendor or determine legal compliance. The proposed method is an analytical contribution whose usefulness needs testing in the organization adopting it.

Define what permission actually covers

“Employees may use approved AI” leaves the crucial boundaries implicit. Does approval include customer attachments? May the service search the web using a confidential question? Can an employee enable a repository connector? Is an answer an internal working note or advice sent directly to a customer? These are material changes in processing and consequence, even when the interface looks unchanged.

I would represent each permission as a record containing seven elements: task, input classes, service configuration, integrations, recipients, review conditions and withdrawal triggers. Give the record an owner, revision and review date. The employee needs a short usable instruction derived from that record; the assessment team needs the supporting evidence. Combining those two audiences into a lengthy policy usually makes neither audience's decision sufficiently clear.

The NIST AI Risk Management Framework connects AI risk assessment to purpose, context, intended users and organizational tolerance. Its GOVERN outcomes also address inventories, responsibilities and decommissioning (Tabassi, 2023, GOVERN 1.6–2.3; MAP 1–2). I use those outcomes to frame a bounded approval record, rather than treating the framework as an approval certificate.

An approval should describe exclusions as concretely as its permitted use. For example: draft an internal summary from an approved collection of public documents; do not add unpublished commercial assumptions; do not enable external actions; verify substantive claims before circulation. An employee should be able to determine whether the next request remains inside that permission without interpreting a risk taxonomy from scratch.

Separate disclosure permission from decision quality

There are at least three different acceptance questions. Is the organization entitled to process these inputs through this service? Can the configured service maintain the required handling conditions? Can the resulting output be used responsibly for the intended decision? A positive answer to one does not repair a negative answer to another.

An employee's legitimate access to a document establishes neither permission to disclose it to another processor nor permission to use it for a new purpose. Conversely, acceptable handling terms cannot make an unreliable answer suitable for a consequential decision. I would keep these as separate gates, with unresolved evidence recorded explicitly, rather than collapsing them into an average risk score.

CNIL's deployment guidance recommends starting with an identified need, defining authorized and prohibited uses, examining deployment conditions, training users and involving relevant organizational stakeholders (Commission nationale de l'informatique et des libertés [CNIL], 2024). These are useful operational distinctions. They do not establish that a particular company's processing is lawful in every jurisdiction.

The proposed decision rule is conjunctive: the purpose, input authority, handling arrangement and output controls must each be adequate for the proposed use. A large productivity benefit cannot compensate for missing authority to send a client's document. Where a defect is correctable, record a conditional hold with the evidence needed to lift it. Where the task is unsuitable, prohibit that task without pretending the entire technology category has been assessed.

Map the information journey before evaluating promises

The visible prompt is only one possible input. A workflow may include uploaded files, conversation history, document retrieval, web searches, feedback submissions and copied output. I would map the actual enabled paths from source to destination, identifying where content leaves a system, who receives it and which conditions govern that transfer. An unenabled feature belongs in the change register, not in an assertion about current processing.

NIST's Privacy Framework 1.0 considers potential problems arising throughout data processing, including operations that function as intended. Privacy risk therefore extends beyond security incidents (National Institute of Standards and Technology [NIST], 2020, §1.2.1). This distinction matters when a technically secure service processes information for a purpose the organization has not assessed. The 2020 framework is used here as a conceptual source, not described as the latest revision.

The map should distinguish business confidentiality from personal information. Removing a person's name may leave a distinctive negotiation, proposed acquisition or unusual operational problem identifiable to its recipient. NCSC's early LLM analysis explicitly discusses sensitivity arising from who asks a question, when it is asked and the aggregation of queries (Chismon & Paul J, 2023). Its historical product predictions should not be substituted for current terms.

Minimization then becomes a workflow design question. Can the task be completed with public inputs, a synthetic example or a narrower extract? If an extract preserves the same confidential fact, calling it redacted does not resolve the issue. If removing context destroys usefulness, the honest options are a suitable processing arrangement or a different method, rather than a misleading claim that the information has become harmless.

Read product assurances at the level where they apply

“No training on our data” is a meaningful condition, but it does not by itself establish absence of storage, provider access, onward processing or customer-side disclosure. I would translate each proposed assurance into a narrower question: which data, in which feature, under which account and agreement, with what exceptions? Then identify the evidence that answers that question.

Microsoft's enterprise data protection documentation states that covered prompts, responses and Microsoft Graph data are not used to train foundation models. The same document describes separate handling for web search queries and directs customers to examine agents' terms and privacy statements (Microsoft, 2026). The admission decision therefore needs the enabled feature path as well as the headline protection statement.

Google's Workspace Privacy Hub similarly identifies the qualifying editions and services to which its protections apply, and describes commitments concerning customer content, human review and model training outside the domain without permission (Google, 2026). I would not extend those statements to every account bearing the same product brand. The organization must establish which covered arrangement its employees actually use.

Anthropic's commercial retention explanation distinguishes API processing from saved product conversations and identifies exceptions, including contractual arrangements, particular features, safety and legal circumstances (Anthropic, 2026). A retention conclusion must follow the relevant branch of that explanation. A single duration copied into a procurement spreadsheet could conceal precisely the exception that matters for the proposed data.

These are vendor representations checked on October 29, 2026, not independent inspections of their systems or this reader's tenant. The acceptance record should preserve the dated applicable terms and settings evidence, identify any negotiated variation and require reassessment when scope changes. Public documentation is useful evidence; it is not proof that someone purchased, enabled or enforced the corresponding controls.

Make the approved route usable and enforceable

After deciding which arrangement is acceptable, the organization needs a practical way for employees to enter it. Specify the work account, permitted service entry point and relevant configuration. Verify the distinction between the managed arrangement and a personal account using an authorized test account. A policy that merely says “use the enterprise version” leaves account selection and enforcement untested.

Integrations require their own scope decision. NIST's least-privilege control applies both to users and to processes acting on their behalf, limiting access to what assigned tasks require (Joint Task Force, 2020, AC-6). An employee's broad access across several business functions should not automatically become the desired scope for an AI connector serving one narrow drafting task.

For each connector, identify which resources it can read, whether it can write, which identity it uses and how permission is withdrawn. Test representative allowed and denied cases in a controlled environment. If the service cannot express the required boundary, that is a limitation in the proposed arrangement. An instruction inside a prompt should not be recorded as equivalent evidence of an access-control boundary.

The employee-facing instruction should also explain the fallback: where to request a new use, what information to provide and how to finish urgent work without the AI service. A slow, opaque exception process can undermine a carefully specified approved route. I would measure how long legitimate requests remain unresolved and distinguish missing information from a policy choice the organization has not made.

Allocate decisions to people who can answer them

The business owner should explain the task and consequences. Information owners should establish which inputs can be processed under what conditions. Security should examine identity, configuration and integration boundaries; privacy and legal specialists should address the applicable processing and contractual questions; procurement should connect the assessment to the purchased service. One accountable owner should assemble the decision without pretending to possess every specialty.

The UK government's AI Playbook recommends involving commercial colleagues early and aligning expectations for internally developed and externally procured systems (Government Digital Service, 2025, Principle 8). Its public-sector setting matters. I adapt the sequencing principle here: contractual questions belong before operational dependence, while the organization still has realistic alternatives, rather than after employees have built an essential workflow around a trial account.

Specify who can grant a limited pilot, who can approve routine use and who can suspend either. The owner who benefits from adoption can sponsor the request, but should not silently waive another owner's unresolved handling requirement. Disagreement should produce a recorded decision and rationale, not an unexplained green status inherited from the product catalogue.

The level of process should follow consequence. A reusable approval for drafting from public material may need a compact assessment and standard controls. Processing restricted information or generating advice that changes a person's opportunities requires a substantially different examination. Proportionality means varying the work required to establish the conditions; it does not mean assuming those conditions because the request is popular.

Define human review as an operational capability

“Human in the loop” is incomplete unless the person can identify an error, obtain supporting evidence, challenge the output and prevent its use. The ICO's human-review guidance identifies competence, authority, independence, sufficient time and manageable workloads as relevant conditions (Information Commissioner's Office [ICO], n.d.). That page is marked under review following legislative change; I use its operational observations here, not as a current legal classification test.

For an employee drafting a brief, review might require checking each material assertion against an accessible source, verifying quotations, assessing omissions and deciding whether the conclusion follows. NIST's generative-AI profile describes confabulation, including confidently presented false content and citations (Autio et al., 2024, §2.2). Asking the same system whether it was correct does not provide independent source evidence.

Research also cautions against treating the presence of a person as a performance guarantee. Vaccaro et al. (2024) synthesized experiments published from 2020 through June 2023 and found heterogeneous results: human–AI combinations did not, on average, outperform the better of the human-only and AI-only alternatives. This does not establish how a current workplace tool will perform. It supports testing the actual combination rather than assuming benefit.

I would define observable review actions and stopping conditions. A reviewer unable to locate a cited source should not approve a factual claim merely because the paragraph reads well. A reviewer who cannot assess a specialized conclusion needs an escalation route or a narrower task. The approval must account for that work before the organization relies on the output at scale.

Compare a bounded pilot with the existing workflow

A pilot should test the proposed use, including its inconvenient cases. Select examples covering ordinary inputs, missing context, conflicting evidence, ambiguous instructions and cases where the correct behavior is to decline or escalate. Preserve a suitable reference answer or assessment rationale. The employee workflow, settings and review process should resemble the arrangement being considered for approval.

Compare complete work products rather than prompt-response speed. Record quality, omissions, unsupported claims, correction effort, review time and escalation demand. Keep the manual baseline comparable: if manual work includes fact checking, AI-assisted work must include it too. Avoid assigning the easiest items to the AI condition and the hardest ones to the baseline, then interpreting the difference as a tool effect.

Where feasible, alternate or randomize comparable assignments, separate those judging outputs from those producing them, and record prior familiarity with the task. Small operational pilots will still have selection and learning effects. Report those limits and preserve the cases that failed. A pilot can justify a narrower permission even when it does not support the original broad request.

Detailed failure-case design deserves its own evaluation procedure. Here, the governance decision is which evidence must exist before a use becomes routine. A pilot result should support a particular task and review arrangement, not become permanent approval for later models, new data classes or a different audience.

A fictional approval decision with different outcomes

Consider an invented organization, Tern, assessing an assistant for internal supplier-research briefs. The proposed first use takes public reports and produces a draft for an analyst. Tern has not been observed or measured; the example isolates decisions that are often compressed into one product approval.

Proposed use	Decisive unresolved question	Illustrative decision
Summarize a specified set of public reports for an internal analyst	Can the analyst verify the material claims within the available review capacity?	Limited pilot; routine permission depends on the assessed workflow
Upload a customer contract to explain supplier obligations	Does the applicable agreement permit this processing through the selected service?	Hold until authority and handling conditions are established
Remove names from that contract but retain distinctive pricing terms	Has the restricted information actually been removed?	Keep the hold; deletion of names alone does not answer it
Add a connector to a shared contract repository	Which additional documents and actions become accessible?	New scope assessment before enabling the connector
Send the generated brief directly to a customer	Who accepts responsibility for its claims and intended use?	Assess the recipient and review change before external delivery

The table deliberately gives no universal answer based on the word “contract” or “public.” A public document can still produce an unreliable consequential recommendation, while restricted information may be processable under an appropriate, verified arrangement. The point is to identify the condition that changes the decision and the evidence needed to establish it.

If Tern approves only the first use, that permission does not transfer to the other rows. The record should be discoverable by employees and connected to the configured service. When an employee requests the connector, the reviewer can reuse relevant product evidence while assessing the additional scope, rather than either repeating the whole procurement exercise or assuming the earlier approval already covers it.

Count the review workload before claiming efficiency

Suppose, purely for illustration, Tern prepares 100 briefs in a period. Manual preparation and checking take an assumed 20 minutes per brief, or 2,000 minutes. Under the proposed AI workflow, preparation takes four minutes per brief and review takes eight: 400 plus 800 minutes. Ten exceptions each require another 25 minutes, and administration takes 120 minutes.

The assumed assisted workload is therefore 400 + 800 + 250 + 120 = 1,570 minutes, leaving 430 minutes relative to the assumed baseline. The exception time is additional to ordinary review; it is not a replacement for it. All inputs are invented. This calculation illustrates accounting boundaries, not an observed saving, financial return or forecast for another organization.

The result is conditional on comparable accepted quality. If the AI workflow produces inferior briefs, the time difference does not establish a worthwhile improvement. Nor is the 800-minute review requirement interchangeable with any spare staff time. The organization needs qualified reviewers available when decisions are due, with capacity for exceptions as well as ordinary work.

There is a useful break-even sensitivity. Holding the other invented inputs constant, 2,000 minus 400 minus 250 minus 120 leaves 1,230 minutes for ordinary review, or 12.3 minutes per brief. Above that average, this particular time advantage disappears. This is a local arithmetic threshold, not a recommended review limit; rushing review to preserve the apparent saving would invalidate the comparison.

Make suspension possible without overstating its effect

Approval should identify events that trigger reassessment: new data classes, a different output audience, changed terms, added search or connectors, loss of required settings, or a pattern of failures outside the accepted conditions. Assign an owner to receive those signals and decide what continues during review. A review date alone cannot handle a material change that happens immediately after approval.

Suspension needs an executable path. Depending on the service, that may involve withdrawing an entitlement, disabling an integration or returning the task to the manual process. The record should distinguish what the organization can enforce from what relies on employee instruction. Test the relevant administrative action within authorized scope before relying on it during a problem.

Stopping future use does not retract an already sent prompt or an externally shared answer. The response may also require correcting recipients, investigating inappropriate disclosure and following the applicable retention or deletion process. Record these as separate actions with separate evidence. A disabled account is evidence about access, not proof that every copy of earlier information has disappeared.

Transaction-level authority for agents is a different problem, examined in AI agent permissions and approval. Organizational permission to use a drafting tool does not authorize an agent to execute every action an employee could perform. Keeping those decisions separate prevents a broad governance approval from being reused as a substitute for specific action controls.

Monitor the permission without collecting everything

Continuing approval needs evidence about scope, not an unrestricted archive of employees' conversations. I would first identify what must be detectable: use of an unapproved account, newly enabled connectors, loss of an administrative restriction or outputs repeatedly escaping the required review. For each condition, identify the least intrusive evidence that can support a useful decision. Collecting full prompts by default may create another repository of the very information the policy is intended to protect.

A record of service access cannot establish what an employee submitted. A connector inventory cannot establish which documents were retrieved. A completed review checkbox cannot establish that the reviewer checked the material claims. State these limits in the monitoring design. Where stronger evidence is necessary, define its purpose, authorized access and retention before collecting it; do not let an assurance requirement become open-ended employee surveillance.

Sampling accepted outputs can help test whether the review process is being performed, but the sample must be appropriate to the decision. A convenient sample of polished briefs will say little about exceptions that were abandoned or sent through another route. Include escalations and declined requests when examining whether the approved workflow remains usable. Record the selection method and avoid treating a small favorable sample as an organization-wide error rate.

The resulting record should connect changes and failures back to a permission revision. If ordinary review capacity has disappeared, the information-handling configuration may remain correct while the approved output process is no longer supportable. That is a reason to narrow or suspend the use, not to leave the overall status green because the product itself has not changed.

Counterarguments and limits

A reasonable objection is that this process could turn inexpensive experimentation into a procurement project. I would address that by approving reusable low-consequence patterns with explicit boundaries and a quick route for exceptions. The organization can reuse evidence for a product and account configuration across tasks. It still needs to examine the task-specific information and consequences that make a new use materially different.

Another objection is that controls around information disclosure do little about false output. That is correct when disclosure dominates the assessment. The proposed separate gates make quality and review capacity independently necessary. Conversely, a highly accurate assistant can still be unsuitable for a particular information flow. Neither a privacy-only policy nor an accuracy-only pilot is sufficient for the whole approval question.

There are limits to the evidence presented here. Public product documentation can change and may differ from negotiated terms. Guidance documents recommend practices without demonstrating their effectiveness in this particular workflow. The meta-analysis covers heterogeneous experimental tasks and an earlier technology period; it cannot supply a current organizational failure rate. No numerical risk reduction or validated maturity score follows from this synthesis.

There are also limits to the proposed method. Recording seven approval elements will not ensure that employees understand them or that settings enforce them. A pilot can miss rare harms and changing behavior. The organization must assess proportionality, applicable obligations and operational feasibility in context. The defensible outcome is a bounded permission supported by inspectable evidence, with a usable way to challenge or withdraw it.

Turn an approved-tools list into a defensible permission

I would start with one workflow employees already want to use. Establish the task, the actual information path and the conditions the organization must maintain. Test whether the proposed review can catch relevant failures at a sustainable workload. Then issue a permission employees can understand, tied to evidence and a named withdrawal authority.

If your approved-tools list cannot answer which information employees may enter, which features they may enable or who can stop an unsuitable use, the next useful engagement is a focused employee-AI workflow assessment. An AI governance advisory discussion can scope that review around one task, its handling conditions and a practical approval record. The purpose is an operationally usable decision, with clear limits, rather than another policy employees have to interpret alone.