Decision Note · Enterprise AI Governance

What an enterprise AI acceptable-use architecture actually needs

A useful AI policy is not a list of prohibited prompts. It is an operating architecture that connects work, data, platforms, authority, actions, oversight and exceptions.

Published: 17 October 2026 · Current practice note

Organizations often respond to generative AI with a short acceptable-use policy: do not enter confidential information, check outputs, use approved tools. Those rules matter, but they do not tell an employee what to do when real work crosses several systems, data classes and decision rights.

The stronger design question is: for this work, with this information, using this platform, what may AI assist with, what may it act on, and who remains accountable?

Policy needs an operating model underneath it

An enterprise can approve ChatGPT, Copilot, Gemini, Claude or another managed platform and still have unsafe use. Conversely, a blanket ban can leave employees with legitimate demand and no workable route to satisfy it. Acceptable use therefore has to govern the combination of work × data × environment × authority × action.

The seven control layers

1 · Work

What task, workflow or decision is being supported?

2 · Data

What information is entering, being retrieved, generated or retained?

3 · Environment

Which managed platform, model, workspace, connector and account may be used?

4 · Authority

What may AI recommend, draft or decide, and what requires a human owner?

5 · Action

May the system only produce content, or also read systems, write records, send messages, execute transactions or trigger workflows?

6 · Assurance

What review, logging, evaluation, monitoring and evidence are proportionate to the use?

7 · Exception

Where does a user go when the approved route cannot perform the work?

Start with use classes, not one universal rule

A practical architecture can classify work into four operating zones. The names can vary; the important point is that controls rise with consequence.

Zone	Typical work	Default operating rule
Open assistance	Low-consequence drafting, brainstorming, public information	Approved environment; normal human review
Controlled enterprise work	Internal analysis, enterprise knowledge, project or operational material	Managed identity and approved data boundary; evidence-linked review where material
Restricted / consequential work	Personal data, sensitive commercial information, regulated processes, consequential recommendations	Named use case, accountable owner, explicit platform/data/action controls and stronger oversight
Prohibited or separately authorised	Uses outside organizational risk appetite or legal/contractual authority	Do not use without formal approval or redesign

Separate assistance from authority

The most important boundary is often not whether AI is used, but what authority is delegated to it. A model that drafts a supplier-risk summary is different from an agent that changes a supplier status. A copilot that proposes a schedule recovery option is different from a system that commits a project baseline.

Generate → Recommend → Prepare action → Execute bounded action → Close consequential decision

Control should become stronger as the system moves to the right.

For consequential work, organizations should identify the human role that can understand the context, challenge the output, intervene and remain accountable. This is consistent with the EU AI Act’s treatment of human oversight for high-risk systems: deployers must assign oversight to people who are equipped and enabled to exercise it. High-risk rules phase in later, but the design principle is useful now.

Connectors and agents change the risk boundary

Acceptable-use policies written for chat interfaces become incomplete when AI can search enterprise repositories, call tools, operate software or act through agents. The permission architecture then matters as much as the model.

Use least-privilege access for connectors and agent tools.
Separate read, draft, write, approve and execute permissions.
Do not let model confidence substitute for organizational authority.
Log material actions and retain evidence appropriate to the workflow.
Define stopping conditions and escalation routes before autonomous execution.

The policy should be executable by employees

An employee should not need to interpret twenty pages of policy before asking AI for help. The operating surface can be much simpler:

1. What work am I doing?

2. What data will AI see?

3. Am I in the approved environment?

4. Is AI assisting or exercising authority?

5. Can it act in another system?

6. What review or evidence is required?

7. If the approved route cannot do the job, where do I escalate?

Regulation adds specific operating requirements

In the EU, AI literacy is already an organizational obligation for providers and deployers. The European Commission states that Article 4 has applied since 2 February 2025, with supervision and enforcement beginning in August 2026. The obligation is contextual: organizations should support literacy appropriate to people’s knowledge, experience and the systems they use.

Article 50 transparency obligations have applied since 2 August 2026. They cover defined situations including direct interaction with AI and certain AI-generated or manipulated content. For high-risk systems, deployer obligations include operation according to instructions, monitoring, enabled human oversight and—in specified workplace uses—information to affected employees and workers’ representatives. High-risk requirements now phase in from December 2027 and August 2028 depending on the category.

These requirements should not be pasted indiscriminately onto every low-risk productivity use. They should be mapped to the actual use-case inventory and implemented through the relevant workflow, platform and accountable role.

Treat exceptions as intelligence

If employees repeatedly request an unapproved tool, upload data through workarounds or bypass a slow workflow, the organization has learned something. The response may still be to prohibit the behavior, but the exception also reveals unmet capability, poor usability, missing integration or an unclear boundary.

That makes exception handling part of the transformation system:

Exception → classify demand → assess risk → provide route or refuse → update control → observe recurrence

A minimum viable acceptable-use architecture

AI inventory: platforms, accounts, use cases, owners and data classes.
Approved environment: managed identity, contractual/data settings and access boundaries.
Use classification: clear operating zones linked to consequence and data sensitivity.
Authority matrix: what AI may generate, recommend, prepare, execute or never close.
Action permissions: connector/tool permissions separated by read/write/approve/execute.
Human oversight: named roles with competence, information and intervention authority.
Evidence and monitoring: proportionate logging, evaluation, review and incident handling.
Exception route: fast escalation for legitimate work the approved system cannot support.
AI literacy: role- and context-specific capability rather than a one-off awareness module.
Review cycle: controls change as products, workflows, regulation and observed use change.

The management implication

Acceptable use is not primarily a document-management exercise. It is the operating interface between organizational demand for AI and the boundaries within which that demand can safely become capability.

The objective is not maximum restriction or maximum freedom. It is to make the approved path clear, useful and governable enough that ordinary work can move through it—while consequential decisions, sensitive data and autonomous actions receive the control they require.