Logged in Plain Sight: A One-Hour AI Use Register for UK Client Teams

Most UK service firms have now reached an awkward middle ground on artificial intelligence. There is no outright ban, because a ban would be ignored. There is no clear policy either, because nobody has had the time to write one. What exists instead is quiet, uneven use: a drafting assistant here, a transcription tool there, a summariser that someone found useful and told two colleagues about.

That arrangement works perfectly well until a client asks a direct question. Which tools have been used on our files? Where does our data go? Who checked the output before it reached us? At that point, silence is the worst possible answer — and it is the answer most firms currently have available.

The alternative to a ban and to silent adoption is a log. Not a compliance artefact with forty fields and a steering group, but a short register that records where AI touches client work and who stood behind the result. It can be built, tested and in use inside an hour.

Why neither prohibition nor silence holds

A blanket ban fails on contact with reality. Staff under deadline pressure will use the tool that saves them twenty minutes, and they will not announce it. The practical effect of prohibition is not less use; it is invisible use, which is strictly worse than visible use.

Silent adoption fails differently. It leaves the firm unable to describe its own processing, which sits badly against the accountability principle under UK data protection law and the ICO's guidance on AI and personal data. It also leaves confidentiality obligations unexamined. Many engagement letters and master services agreements restrict disclosure to third parties; whether a cloud AI tool counts as a disclosure depends entirely on what was typed into it, and nobody can assess that if nobody knows.

A register resolves both problems by making use ordinary, visible and discussable. It does not require anyone to be enthusiastic about the technology. It only requires them to write down what happened.

What the register actually needs to hold

Resist the urge to design something comprehensive. Seven fields are enough, and fewer is better if it means the log is actually completed.

• Date of use.
• Tool and version, named precisely enough that a later reader knows what was involved.
• Client or matter reference — the internal code, not a free-text description.
• Data involved, in categories: none, internal only, client-identifiable, special category.
• Purpose, in a short phrase: summarise a call, draft a first response, check tone, extract dates.
• Reviewer, by name, with a note of what they checked.
• Output status: used as drafted, amended, or discarded.

One row per use, not one row per prompt. A person who spends an afternoon working with a tool on a single matter should record the session, not thirty interactions.

The distinction between drafting assistance and decision support matters and should be visible in the purpose column. A tool that tidies a paragraph is a different proposition from a tool that ranks a complaint or recommends an outcome. The second category deserves a second pair of eyes every time.

Building it before lunch

The sequence below is deliberately modest.

1. Choose the container. A single spreadsheet in a controlled location with access limited to the delivery team and the nominated owner. Not a personal drive, not a shared folder that half the company can edit.
2. Fix the field list. Use the seven above. Do not add a training column, a risk score or an approval workflow on day one.
3. Populate three real examples from the past fortnight. This is the most valuable step. It tests whether the fields make sense against actual work, and it establishes immediately that the register describes things that have already happened rather than things that are now permitted.
4. Write a one-page rule. Two sentences will do: if a client can be identified in what you put in, or in what comes out, it gets a row; rows are completed the same working day.
5. Name an owner. One person, not a committee. Their job is a fifteen-minute monthly read, not gatekeeping.
6. Set the review rhythm. Quarterly, alongside whatever operations review already exists.

That is the whole implementation. Anything more elaborate should wait until there is evidence it is needed, which the register itself will supply.

What "who checked the output" should mean

A name in a cell is not a check. The reviewer column earns its place only if it records what was verified: figures against the source document, names against the client record, commitments against the engagement terms. "Reviewed" on its own tells a later reader nothing.

The habit to build is simple. The reviewer is the person who would be answering the client if the output turned out to be wrong. That framing tends to sharpen attention considerably.

Keeping it honest rather than performative

Two cultural conditions determine whether the register survives its first month.

The first is that logging carries no penalty. If the first person to record an awkward use is treated as a problem, the log will empty within a fortnight while the use continues. The failure to be corrected is the failure to record, not the use itself.

The second is that the review actually changes something. A quarterly read should answer: which tools are in play, which teams have adopted them, which clients are most exposed, and where a tool being used informally ought to be procured, contracted and supported properly. Registers that are read only by the person who maintains them become paperwork within a quarter.

The client conversation it unlocks

A populated register changes the tone of a client query from defensive to factual. Most clients are not looking for a vow of abstinence; they want to know that someone is paying attention. Being able to say, in a scheduled call, that a summarisation tool is used on call notes for one workstream and that a named manager checks every output, is a stronger position than a general assurance that AI is handled responsibly.

It also feeds contract review. Where an engagement restricts sub-processors or third-party disclosure, the register shows which tools are relevant and whether a conversation with the client is needed before the next project rather than after the next incident.

The point of the exercise

A register is not there to prove virtue. It is there so that the firm can answer a question about its own work without guessing. An hour spent setting one up, and fifteen minutes a month maintaining it, buys something that is otherwise unavailable: a truthful account of how client material is handled.

That is a modest ambition. It is also the difference between a firm that knows what it does and one that hopes for the best.