AI Governance & Acceptable Use

Overview

AI tools have become part of how engineers write code, review PRs, generate tests, and investigate problems. That integration has happened faster than most organisations have agreed on the ground rules. The result is a surface that is productive but under-governed: engineers make sensible individual decisions about what to paste into a prompt, those decisions vary, and the organisation has no consistent view of its exposure.

This page is the canonical statement of what we consider acceptable use of AI tools in engineering work. It is the document Legal and Security need to exist; it is also the document a new engineer can read to know what is and is not allowed — before they have to guess.

For the tooling itself, see AI Code Assistants and AI-Driven PR Reviews. For secrets hygiene (a specific case of the data rules here), see Secrets Management.

---

Why It Matters

Data that leaves the organisation is difficult to call back. Once a prompt has been sent to a third-party AI service, the data is in that vendor's systems — in logs, in caches, potentially in training datasets. Even a subsequent deletion does not always reach every copy. The first line of defence is not sending it in the first place.

Regulatory exposure follows the data, not the intent. Customer data, personal data, health data, and financial data are subject to regimes (GDPR, HIPAA, PCI, sector-specific law) that do not care whether the engineer meant to share them. A well-intentioned prompt that pastes customer records into a chatbot is still a data processing event that may violate policy or law.

Licence and intellectual-property exposure is real. AI tools produce code that may be under restrictive licenses; they can also, at the margin, reproduce training material. Inputs and outputs both carry IP consequences, and the organisation has liability on both sides.

The rules need to exist before they are needed. Writing acceptable-use rules during or after an incident is writing them badly. Writing them up front, plainly, is an inexpensive form of insurance.

---

Standards & Best Practices

The data classification rules

We recognise four classes of data. The rules below apply to everything put into an AI tool — prompts, attachments, context, and iterative follow-ups:

The default class for data in our systems is Internal — meaning most internal code can go into approved AI tools. Code in directories the team marks as sensitive, fields handled by the privacy layer, and anything obviously falling into the Restricted class does not.

The "approved tools" list exists and is kept current

Engineers use AI tools that the organisation has evaluated and approved — not whatever tool appeared in a blog post last week. An approved tool has been reviewed for:

• Its data handling (retention, training use, regional processing)
• Its security posture (how credentials are scoped, how data is isolated per customer)
• Its contractual terms (what the vendor is entitled to do with inputs)
• Its operational fit (IDE integration, model quality, cost model)

Approval is not permanent. Tools are re-evaluated as their contracts change and as the organisation's needs evolve. A tool moving from approved to unapproved is a signal, not a surprise.

Never paste secrets, credentials, or tokens — ever

This is not a guideline; it is the rule with the lowest tolerance for exception. Anything that grants access — an API key, a database password, a signed token, a private key — is treated as compromised the moment it touches an AI tool, regardless of the tool's stated policies. Rotate immediately on accidental disclosure.

The reason for no-exceptions is that the consequences of a leaked secret are severe and irreversible, and no AI tool's policy can undo them. The only safe policy is "it never goes in."

See Secrets Management for the full hygiene around secrets.

Customer data never enters AI tools used for engineering work

Production customer data — including PII, account identifiers, content created by customers, and logs that contain customer data — does not get pasted into an AI prompt, even to debug a problem. If an engineer needs AI assistance with a customer-data-adjacent problem, they work with:

• Synthesised or anonymised examples that preserve the shape of the problem
• Schema-only representations
• Sanitised extracts produced by the organisation's privacy-preserving tooling

Teams whose work genuinely requires AI-assisted processing of customer data use a separate, contractually-constrained path with privacy review — not the same tools used for routine coding.

Respect the licence of code we generate with AI

Code produced by AI tools is code the organisation is responsible for. Licence obligations, attribution requirements, and patent positions do not evaporate because the code came from a model. Standards:

• Treat AI-generated code as code that must pass the same review, including licensing review where applicable
• Prefer AI tools whose terms give the organisation clear ownership or license to the output
• Where a tool produces output that appears to reproduce a known open-source snippet, treat it as if it did — check the source and handle attribution or licensing appropriately
• Do not use AI tools to deliberately launder the provenance of external code

Respect the licence of code we put into AI prompts

The other direction matters too. Pasting code into an AI tool is a use of that code. If the code is under a licence we are obligated to respect:

• Internal proprietary code follows the Confidential rule (approved, no-training tools)
• Third-party code the organisation has integrated remains bound by its licence; pasting it into a tool that will train on it may violate the licence
• Code from partners or customers is treated per the contract — often more restrictively than our own code

Generated content is reviewed with the same scrutiny as human-written content

AI-generated code, tests, documentation, and review comments all pass through the same review process as human work. The review rules do not relax because "the AI did it":

• Code is reviewed for correctness, security, and fit with the codebase
• Tests are reviewed for whether they actually test what they claim
• Review comments are treated as suggestions, not directives
• Accountability for the merged output sits with the human who merged it

"The AI wrote it" is not a defence, and it is not context the rest of the team needs to know when reviewing. The artefact is evaluated on its merits.

Agentic and unattended workflows have additional guardrails

An AI that is asked a question and returns an answer is one kind of exposure. An AI that is given tools and allowed to act on them — read files, run commands, modify state — is a different kind. The governance standards for agentic workflows:

• The set of actions the agent can take is explicitly scoped (not "shell access"; specific allowed operations)
• Writes to shared state (databases, production systems, publish operations) require a human confirmation
• Agentic work happens in isolated environments when possible (sandboxes, scoped credentials, separate branches)
• Actions are audit-logged — what was run, when, by which session

This is a developing area and the guardrails evolve as the tools evolve. What does not change: the agent is acting on behalf of a human who is accountable for the outcome.

Transparency where it matters

Engineers can and should use AI tools to be more productive. Where transparency genuinely matters — in customer-facing communications, in specific compliance contexts, in work being represented as human-authored — the use of AI is disclosed. In routine internal engineering, disclosure of AI use is not required; the artefact is evaluated on its merits.

The organisation's position is: AI is a tool, like an IDE or a linter. We expect people to use good tools and be accountable for their output.

---

How to Implement

What an engineer can do without asking

• Use an approved AI tool on internal code that is not in sensitive directories
• Paste error messages, stack traces, and diffs (after scrubbing anything that looks like a secret or customer identifier)
• Ask the AI for help with design, testing, documentation, and refactoring
• Accept or reject AI-generated code on its merits

What requires consultation with security or legal

• Use of a tool that is not on the approved list, for any reason
• Use of an approved tool on data that falls outside the default Internal classification
• Use of AI to process anything in the Restricted class, even synthesised, if the output will be used against production systems
• Agentic workflows with access to production state
• Publication of any AI-generated content as authored by a named individual in contexts where authorship matters (legal filings, certifications, public communications)

What is never allowed

• Pasting secrets, tokens, or credentials into any AI tool
• Pasting customer data or PII into any AI tool used for engineering work
• Using AI tools for engineering purposes on personal (non-approved) accounts
• Using AI tools to circumvent other organisational controls (code review, access control, approval workflows)

When something goes wrong

Accidental disclosures happen. The right response, in order:

1. Rotate any secret or credential that may have been disclosed
2. Tell security — openly, early, without softening. A disclosure reported immediately is often containable; a disclosure reported weeks later usually is not
3. Document what happened, in a blameless postmortem style, so the organisation learns
4. If customer data was involved, follow the privacy incident process

The goal of the response process is to contain impact, not to punish the engineer. Teams that fear reporting will delay reporting, and delay is the most expensive possible response.

---

Common Pitfalls

The individual-judgment drift. Every engineer decides for themselves what "sensitive" means. Ten engineers have ten different thresholds. The organisation's actual exposure is the union of all ten, and no one knows what that union looks like. A written policy is not about distrusting engineers; it is about converging on a single shared threshold.

Approving tools once and forgetting. A tool is evaluated and approved in year one. In year two, the vendor updates its terms; by year three, the tool is training on our inputs. A working approval process re-evaluates on a cadence — not just at intake.

"It's in a private repo, so it's fine." Private does not mean the AI tool will not train on it, retain it, or expose it in a novel way. The classification is about the content, not the repo. Treat private code as Internal by default and Confidential where appropriate.

Vendor-trusting as policy. "The vendor says they don't train on our data" is not itself a guarantee; it is a statement subject to the terms in place at the time. The terms can change; the interpretation can drift; the enforcement is outside the organisation's control. Policy is built on "what is in our direct control" plus "what the contract specifies" — not on vendor promises alone.

Governance by blocking tools. An organisation that bans AI tools outright will find them being used on personal accounts, outside its visibility, with worse guarantees than the approved path would have provided. Governance is safer when it provides a sanctioned path that engineers actually want to use.

"This is just a small snippet." The repeated pasting of small snippets, each individually trivial, aggregates into substantial exposure. The decision about what goes into the tool is made per-prompt; the exposure is cumulative.

Expecting engineers to memorise a long policy. A governance document that is twelve pages long is a document no one reads. The rules that matter need to fit in short form — the four data classes, the "never secrets, never customer data" rules, the approved tools list — and be referenced from where engineers work. The long document exists for reference; the short rules exist for use.

Conflating AI governance with AI distrust. The goal of governance is to make AI usable, not to make it unused. A policy that is purely restrictive produces shadow IT; a policy that names the approved path and the forbidden ground produces trust and visible adoption.