Generative AI has an unusual adoption pattern. It arrives from the bottom of the organisation, not the top — staff are already using it, often on personal accounts, well before anyone has approved anything. By the time a formal pilot is proposed, the real question is not whether to adopt but how to bring existing usage inside the perimeter.
Four decisions to make before the build
- What data may leave. Be specific at the level of document classes, not principles. “No customer PII” is a policy. “Contracts and HR files stay in the tenant, published marketing material may go out” is a rule an engineer can implement.
- Where the model runs. Vendor API, cloud tenant or self-hosted. This is largely a compliance and cost decision, not a quality one.
- Who is accountable for output. Every deployment needs a named human owner of what the system produces, in the same way any other published work has an author.
- What is logged. Prompt and response retention is both a debugging necessity and a data protection obligation. Decide the period deliberately.
Design for being wrong
The failure mode that matters is not gibberish — people spot that. It is a plausible, well-formatted, incorrect answer delivered with total fluency. Systems should be built so a wrong answer is cheap:
- Ground answers in retrieved documents and show the source next to the claim.
- Keep a person in the loop wherever the output leaves the company or affects an individual’s money, employment or health.
- Prefer drafting over deciding. Summarising a call, drafting a reply and extracting fields are forgiving tasks. Approving a claim is not.
Measure something real
“Productivity improved” is not a finding. Pick a metric that existed before the pilot: hours spent on first-draft responses, tickets resolved without escalation, time from enquiry to quotation. Baseline it for a few weeks. If the pilot cannot move a number that already existed, it is a demonstration rather than a project.
Where the durable value sits
In our client work the persistent wins are unglamorous: search across scattered internal documents, summarising long call transcripts, extracting structured fields from supplier paperwork, and helping non-specialists write a first draft of something they would otherwise avoid. These are all cases where the human reviewing the output already has the expertise to spot an error.
A reasonable first step
Publish an acceptable use note, choose one workflow with an existing metric and a competent reviewer, and run it for a quarter. Governance written after a pilot tends to be written under pressure, which is the most expensive time to write it.
