An AI acceptable-use policy should answer the employee’s next question

Can I paste this supplier proposal into the assistant we have been given? An employee asking that question needs an answer they can apply before the sourcing deadline. “Use AI responsibly” sends the decision back to someone who may not know the account settings, contract restrictions or consequences of an inaccurate summary.

The enterprise AI lead should make the policy useful at that point of work. State what staff may do, which information they may use, which route is approved and what must happen before the output affects the business. Keep detailed supplier assessments behind the policy, where the people maintaining it can find them.

Approve a use with boundaries

A product name is too broad a unit of permission. Specify the company-managed service and account, relevant feature, task and data category. If extensions, connected repositories or actions require additional approval, say so where employees encounter that choice.

Supplier protections are one input to that decision. Google’s Workspace AI privacy material, for example, says customer data is not used for generative AI model training outside the customer’s domain without permission. Google also describes administrative controls over access to Gemini. Those statements help an organisation evaluate a managed service. They do not decide whether a particular employee may upload a supplier’s confidential proposal or rely on the resulting comparison.

The internal policy must make that second decision explicit. Otherwise staff may reasonably interpret “approved tool” as permission to use every feature with every document they can access.

NIST’s AI Risk Management Framework Playbook connects AI policies to existing governance, data practices and defined responsibilities. That is useful here: employees should not need to reconcile a new AI document with contradictory procurement, information-security and records rules on their own.

Write the instruction at the level of the task

For a hypothetical organisation that has approved limited AI assistance in sourcing, the employee-facing instruction could read:

You may use the company-managed assistant to draft a summary of a supplier proposal only when the proposal’s information classification and handling conditions permit that use. Use the approved sourcing workspace. Include only the material needed for the comparison.

A procurement analyst must check prices, dates, exclusions and commitments against the original proposal before using the summary. Do not use the assistant to make the award decision or send a response to the supplier. If the proposal’s handling conditions are unclear, ask the procurement operations owner before uploading it; use the existing manual review process meanwhile.

The wording answers the practical questions: what task is allowed, which route to use, what data boundary applies, what review means and where uncertainty goes. It is an example to adapt to an organisation’s actual approval, not permission for every organisation to process supplier documents this way.

Notice the specificity of the review. “Human in the loop” could mean someone glancing at a fluent paragraph. Checking prices, dates, exclusions and commitments asks the reviewer to verify the facts that could change a commercial decision. Give reviewers access to the originals and enough time to do that work.

Where the approved service changes, update the instruction and its linked service entry together. Staff should be able to recognise the correct account and workspace without interpreting a vendor’s contract or comparing model names.

Make restrictions lead somewhere useful

Organise the policy around a small number of ordinary situations: drafting from public information, working with internal material, handling restricted information and allowing software to take an action. These categories need different instructions. A tool that may draft an internal note need not be permitted to update customer records or send an external message.

For restricted or uncertain uses, identify a decision owner and the information they need: the task, proposed service, data involved and intended output or action. Define an achievable response route with the team that will operate it. An approval inbox nobody owns leaves the business need unresolved.

Offer an alternative when the proposed route is unsuitable, such as using public inputs, removing unnecessary material or retaining the existing manual process. Avoid suggesting that removing names automatically makes a document suitable; confidential commercial facts can remain sensitive without personal identifiers.

Also tell staff what to do after a mistake. If information was uploaded to the wrong account or an unreviewed output reached a customer, the instruction should lead promptly to the existing reporting and response process. Make it possible to report what happened without requiring the employee to diagnose the technical impact first.

Test the policy with representative employees using realistic tasks before rolling it out. Ask them to explain what they would do and where they would seek help. Ambiguous answers are findings about the wording or support model, not merely training failures.

Keep permitted uses connected to an AI use-case inventory with accountable owners. That gives the policy a way to change when a feature gains new data access, a task becomes more consequential or the person authorised to approve it moves on.