AI Governance for Enterprise Operators

AI governance gets framed as either "we'll write a 200-page policy document" or "let's just see what people use." Both are wrong. Here's what an actual baseline looks like — the version your auditor and your engineers will both accept.

Why governance matters now

The honest reason isn't compliance. It's that staff are already pasting customer data into ChatGPT, suppliers are pitching AI features at every renewal, and the board is asking what your AI strategy is. Without a baseline, you're stuck between two losing positions: blocking everything (and watching adoption move underground) or allowing everything (and accepting unknown risk).

A working governance baseline gives staff clear permission to use AI for the things that genuinely help, removes ambiguity for the cases that matter, and gives you something credible to show when an auditor or a customer asks "how do you handle AI risk." The goal isn't a perfect policy. The goal is a policy that's actually followed.

Data classification, but for AI

Most organisations already have a data classification scheme: public / internal / confidential / restricted, or some local variant. The simplest governance baseline maps your existing classification to "what can go into which AI tool":

• Public. Press releases, marketing copy, published documentation. Free to use any AI tool.
• Internal. Meeting notes, project plans, non-customer-specific work. Approved enterprise AI tools (your sanctioned Microsoft Copilot, ChatGPT Enterprise, etc.) only.
• Confidential. Customer data, supplier contracts, financial detail, employee PII. On-premise inference or contractually-bounded enterprise tools only. No public models.
• Restricted. Regulated data (health records, payment data, classified material). No AI tools without explicit per-case approval, full audit trail, and legal review.

This four-tier mapping is enough for 80% of the policy. The remaining 20% is the edge cases where category is ambiguous; route those to a named owner (typically your DPO or CISO).

PII and sensitive data

The pattern that works: PII gets scrubbed before it touches an external LLM, full stop. Practical implementation:

• Gateway redaction. If you're routing AI traffic through an internal gateway, run a PII detection pass and redact (or block) before forward. Most enterprise AI proxies offer this off the shelf.
• On-premise inference for the workflows that genuinely need PII visibility (HR queries, customer-specific support). The model quality may be slightly lower; the privacy posture is far higher.
• Audit logging on the rest. Even when redaction passes, log what entered the gateway, what got redacted, who initiated the call. You'll need this when an incident happens.

Audit trail design

What to log, in priority order:

• User identity (who issued the prompt).
• Timestamp (when).
• Tool / model / version (which AI service).
• Prompt (or hash of prompt). Storing the full prompt long-term creates its own PII liability; hash it and store full content only briefly unless legal explicitly requires longer retention.
• Response (or hash). Same trade-off.
• Token counts and cost. For chargeback and trend analysis.
• Outcome flags. Was the response used? Did the user override? Was it flagged as wrong?

Vendor evaluation

The diligence checklist when a vendor pitches "AI features":

• Where does the data flow? Which model, hosted by whom, in which region. Get this in writing in the contract, not in the sales-deck.
• Will the data be used to train? Most reputable enterprise vendors say no by default; verify the contract language matches the marketing.
• Region of inference. If you have data residency requirements (GCC, EU, regulated industry), the inference region matters as much as the data-storage region. Many SaaS vendors pass requests to a US-hosted model regardless of where they store the data.
• Sub-processors. Get the sub-processor list in writing. The model provider is the obvious one; there are usually one or two others (analytics, support tooling) that get less attention.
• Security certifications. SOC 2 Type 2, ISO 27001 baseline. For health/finance data, look for the relevant sectoral certifications.
• Exit clause. What happens to your data on termination, in what format, on what timeline.

Internal acceptable-use policy

Keep it to one page. Two columns:

• Allowed. Drafting emails. Summarising meetings. Code suggestions on internal repos. Brainstorming. Document templates. Translating internal text. Asking general knowledge questions.
• Not allowed without specific approval. Pasting customer data, supplier contracts, financial detail, source code from sensitive products, employee personal data, anything covered by an NDA.
• Where to ask. A named person or team. Without this, the policy will be ignored at the margin where most of the risk lives.

One page, plain language, examples. Anything longer doesn't get read.

What an auditor will ask

The questions that come up first time, in roughly the order they get asked:

1. What AI tools are in use across the business? Have an inventory; auditors will be unimpressed if you can't answer this within a week.
2. How is data classified for AI use? The four-tier mapping above answers this.
3. Where does data flow when staff use AI? Data-flow diagrams for the top three or four AI tools by usage.
4. How is access controlled? SSO, role-based access, MFA. Standard enterprise hygiene.
5. What logging exists? Show the audit trail design above.
6. What's the incident response for AI-specific incidents? Data leakage, hallucinated decisions used as basis for action, vendor outage. Most companies have nothing here; even a one-page playbook beats nothing.
7. How are vendors assessed? Show the diligence checklist above.

Related reading: RBAC design for CAFM systems covers the access-control side that AI governance has to slot into. For the practitioner perspective on using AI on your own client work, see Practical Prompt Engineering for ERP Consultants.