AI Acceptable Use Policy

An AI acceptable use policy tells people which AI-assisted activities they may perform, with which information, under whose authority and subject to which checks. It should cover predictive tools, image generators, embedded assistants and agents as well as chatbots. The useful unit of permission is an activity in a defined environment: an approved product name alone leaves too much undecided.

For Saudi organisations, the policy should connect everyday use to existing information handling, employment, procurement and decision-making rules. An employee should be able to answer a practical question without interpreting a legal framework: can I upload this file, rely on this recommendation, publish this image or let the assistant send this message? Where the answer depends on a specialist assessment, the policy must identify the route and the temporary boundary.

This guide is for policy owners, department managers and security or privacy teams building that operational layer. It provides a proposed activity matrix and adoption method. The clauses are an original internal-policy design for adaptation; they do not replace the organisation's applicable legal requirements or the broader enterprise AI governance policy framework.

Define the conduct that the policy actually controls

Start with verbs employees recognise: enter, upload, connect, generate, recommend, publish, approve and execute. Each verb changes the decision. A tool may be approved for generating public brainstorming material but not for ingesting client contracts. A forecast may be useful to a planner while remaining unsuitable as an automatic instruction to purchase inventory. A generated message can be reviewed internally before any permission to send it exists.

State who is covered, including temporary staff and contractors where their agreements and organisational arrangements permit. Identify work performed on behalf of the organisation, including use of personally purchased subscriptions for business tasks. Avoid claiming control over unrelated private activity. Explain how the policy intersects with confidentiality, professional obligations and any specific restrictions in client contracts.

The policy owner should also define the treatment of AI already embedded in ordinary software. Employees may not recognise a meeting-summary button or recommendation panel as a separate AI service. Ask them to use the approved feature catalogue and report unfamiliar capabilities. Technical administrators and procurement must maintain that catalogue; employees cannot reasonably be expected to discover an undocumented supplier architecture.

Use a permission matrix with four separate dimensions

A practical permission record combines the business task, information class, output audience and action authority. Keep those dimensions separate. Otherwise a broad label such as “low risk” can conceal a serious change in how a result is used. The matrix below illustrates possible internal rules; the organisation must determine the actual permissions and controls.

Example structure for an AI acceptable-use matrix

Dimension	Question for the employee	Policy record
Task	What are you trying to produce or decide?	Named permitted activity and excluded extensions
Information	What will the service receive or retrieve?	Allowed sources, fields and handling conditions
Audience	Who will see or rely on the result?	Internal draft, client communication or public release
Authority	Can the tool change anything outside the draft?	Read-only use, recommendation or specifically delegated action

Add the approved account or tenant and any required configuration. Two people using the same branded tool may operate under different contracts, retention settings or integrations. A policy that specifies only the brand can accidentally approve an entirely different processing arrangement. Record the environment in terms a user can recognise, such as the company sign-in route and the enabled feature.

Keep the matrix concise enough to use during work. Detailed evidence belongs in the associated approval record, not in a crowded employee table. Link a matrix row to the relevant AI inventory entry so owners can maintain the evidence without asking every employee to read procurement files.

Write clear rules for information entering AI tools

Use a proposed clause such as: “Use only the information categories and sources listed for the approved activity. Do not add attachments, connectors or personal information outside that scope without review.” The important word is scope. An employee may legitimately access a document for ordinary work without having authority to send it to a new service or make it available through a shared assistant.

Explain that removing a name may leave a person identifiable through context, account references or a distinctive event. Likewise, an image can contain visible badges, floor plans or unpublished designs even if its filename looks harmless. Give employees examples from their work and a simple route for uncertain cases. Avoid requiring them to make unsupported claims that a document is fully anonymous.

Define how approved source material is prepared and who checks it. For example, a project coordinator may use a published specification while a commercial owner must approve any extract from a confidential cost sheet. The policy should state whether a task may proceed with a reduced or synthetic example while the real-data question remains unresolved. That provides a useful alternative to copying the full file under deadline pressure.

Separate review of output from authority to act

A review requirement must name what the reviewer verifies. For text, that may include factual claims, quotations, numbers, commitments and confidential material. For a forecast, it may include the input period, assumptions, uncertainty and how the forecast will influence a decision. For an image, it may include whether the output misrepresents a real project or creates an unauthorised likeness or brand association.

State that generating an output does not confer permission to publish it, make a contractual promise or alter a business record. The person responsible for the normal business decision retains that responsibility. Where an agent can act, the allowed actions need a separately approved authority boundary and a means to stop or investigate execution; see governance for agentic AI.

Make review feasible. A manager who receives hundreds of unexplained recommendations cannot meaningfully approve them by clicking a batch button. The approved use should expose the relevant source, change or consequence and allow rejection. If those conditions are absent, reduce the task or retain a human process. “Human reviewed” should describe a real decision, not a label attached to automated throughput.

Worked example: an exhibition-design company's six requests

Consider a fictional exhibition-design company introducing an acceptable-use policy. Its teams propose six activities. The example describes proposed internal decisions, not a legal ruling or an Open for AI client result. The company wants useful experimentation while keeping customer commitments and confidential design material under their existing owners.

Illustrative decisions for six AI-assisted activities

Requested activity	Initial policy treatment	Reason
Brainstorm stand themes from public material	Permit in the approved environment with normal creative review	No confidential source is required for the defined task
Summarise a confidential cost workbook	Hold pending approved data handling and restricted access	Tool approval does not establish permission for commercial inputs
Predict fabrication demand from approved historical totals	Permit a planning recommendation within the evaluated scope	Purchasing authority remains with the planner
Publish an AI-generated image as a completed client installation	Do not permit that representation	The proposed caption would misstate what actually exists
Draft a customer installation update	Permit a draft using approved facts, with named review	The output may contain commitments that need confirmation
Let an agent confirm supplier bookings	Require a separate action-authority review	The activity creates external commitments

The team does not give the image tool a universal green status and the forecasting tool a universal amber status. Permission follows the activity and evidence. A different image task could require review because it includes a customer's unpublished design. A forecasting recommendation could require renewed approval if it starts triggering purchase orders rather than informing a planner.

The policy owner records the six outcomes, the associated environments and the reasons. Employees receive the activity matrix, while detailed evidence stays with the relevant owners. The useful result is that staff can recognise the next action: proceed within the boundary, prepare reduced inputs, ask for review or use the ordinary process. No invented numeric policy-compliance score is needed.

Make exceptions temporary and specific

A policy needs a controlled route for a legitimate task that falls outside an existing permission. The requester should describe the work, why the approved route is insufficient, the proposed information and recipients, and the period required. A business deadline is context for the decision; it is not by itself evidence that the alternative is acceptable.

Specify who can approve which exception and what they cannot waive. A department manager may accept an internal workflow inconvenience without authority to override a contractual restriction or decide a privacy issue. The exception management design should preserve that distinction, record conditions and set an expiry or review event.

Make the outcome visible where work happens. If an exception permits one controlled evaluation with synthetic material, it must not appear in the catalogue as general production approval. When the period ends, the owner should confirm whether access and copied material have been handled as agreed. Repeated exceptions for the same unmet need should trigger a policy or service-design review rather than becoming an unofficial permanent route.

Give staff a useful reporting route

Employees need to report uncertain use, unexpected disclosure, a misleading output or an unintended action without first proving that a formal incident occurred. Provide one recognisable entry point and an alternative if it is unavailable. Ask for the tool, activity, approximate time and what happened; avoid encouraging staff to paste confidential prompts into an unrestricted support ticket.

The first response should preserve relevant evidence and limit additional exposure using the organisation's established procedures. A policy can tell employees to stop the affected activity and seek help, but technical containment and legal notification decisions require the responsible teams. Do not insert one universal statutory notification deadline into a general employee policy.

Explain how reports lead to practical improvements. The shadow AI response should distinguish unmet business needs from intentional misuse, and the AI incident response plan should handle potential harm. A constructive reporting channel does not remove accountability; it makes the organisation more likely to learn about a problem while it can still act.

Make the policy enforceable through the environment

Rules and technical controls should agree. If the matrix permits only an approved company workspace, provide the correct sign-in link and prevent misleading shortcuts where feasible. If an activity is read-only, do not give the assistant write credentials and rely on staff remembering not to use them. If a feature remains under review, the administrator should know whether it can be disabled separately.

The UK's voluntary Code of Practice for the Cyber Security of AI includes human responsibility and awareness of prohibited uses. It is a useful international reference, not a Saudi legal mandate. The operational design here turns those general concerns into explicit activities, accountable reviews and verifiable settings.

Document control limitations honestly. Network blocking may reduce access through managed devices without covering personal devices or an embedded service using an allowed domain. A monitoring tool may identify traffic without knowing the business purpose. Use those signals to support review rather than treating their absence as proof that no unapproved activity exists.

Test understanding with decisions, not acknowledgements alone

Before launching the policy, ask a small representative group to work through realistic cases without help. Can they find the approved environment? Can they distinguish a draft from publication? Do they know whether a connector needs review? Observe where they hesitate and revise the wording or catalogue. This is a usability test of the policy, not a test of whether staff can memorise definitions.

Include a case with incomplete information. The correct response may be to ask the named owner or use a permitted alternative. A training exercise that always forces “allowed” or “prohibited” can encourage confident guesses. Managers need the same practice because they may otherwise give informal permission outside their authority.

Use role-based AI training to reinforce the rules and record changes prompted by questions. A signed acknowledgement shows that someone received a version; it does not demonstrate that they can apply it. Review recurring errors, unanswered requests and misunderstood exceptions as evidence about the policy's usability.

Resolve borderline cases without changing the whole policy

Provide a short interpretation record for a case the matrix does not clearly answer. Capture the requested activity, the existing rule, the point of uncertainty, the decision owner and the outcome. The record should say whether it clarifies an existing permission or grants a new, limited exception. Otherwise, a helpful answer in a chat can become an unofficial policy amendment.

In the exhibition-design example, an employee might ask whether a generated concept image can appear in a proposal. The answer depends on its description and audience: a clearly identified proposed concept is a different representation from a photograph of completed work. The interpretation should specify the approved caption and review responsibility, without implying that every generated image is cleared for publication.

Use these records to improve the employee-facing matrix. Repeated questions about the same boundary suggest an unclear rule, a missing approved workflow or a training need. Assign one owner to consolidate the answer, retire inconsistent advice and notify affected teams. Keep the old interpretation linked to the decision it supported so an earlier action can still be explained.

Define fair and usable evidence of policy implementation

Assess implementation through a limited set of practical observations: whether staff can locate the permitted workflow, whether a reviewer identifies a material error, whether a blocked request reaches its owner and whether a reported concern receives a decision. Choose observations that match the policy's actual promises.

Do not make the policy owner responsible for proving that no misuse exists anywhere. Report the scope checked and the unresolved areas. When a problem appears, distinguish an unclear instruction, unavailable approved tool, incorrect configuration and deliberate disregard. Those findings lead to different corrective actions and should not be collapsed into a single employee compliance score.

Keep ownership and review triggers visible

Assign a policy owner, a catalogue owner and the relevant decision owners. They may be the same person in a small organisation, but the responsibilities should remain explicit. Store the effective version and preserve the rule that applied when an earlier approval was made. Do not silently rewrite the conditions attached to a past decision.

Review the policy when a new capability changes what employees can do: connecting another repository, enabling external messages, adding a new information category or changing supplier terms. Routine review dates are useful, but they do not replace these change triggers. The policy should explain how staff learn about changed permissions and what happens to existing work.

For AI governance setup, bring a sample of actual employee tasks, the current approved-tool list and the decisions that remain ambiguous. A governance setup discussion about acceptable use can turn those questions into a workable activity matrix, review routes and adoption checks. The goal is a policy people can follow accurately while completing real work.