Telling people, and keeping the receipts

People are owed the fact

When an automated system writes to a person, say so. Transparency duties of this kind now appear in law in several jurisdictions, including the European Union’s AI Act; the details vary and will keep moving. The practical reason does not move: a person who knows they are dealing with a machine behaves usefully differently. They stop writing three paragraphs of context. They ask for a human when they need one. And they do not discover it later, which is the outcome that costs you the relationship.

Disclosure that does not irritate anyone

A banner reading this response was generated by artificial intelligence is legally tidy and reads as a disclaimer. What works better is naming the accountability:

Drafted automatically and checked by Priya in support. Reply to this email and a person will read it.

That sentence tells the reader three things (how it was made, who is responsible, how to reach a human) and it does not sound like a warning label. Keep it short, and keep it near the content rather than in a footer.

What an audit record has to contain

Per action taken in the world:

• what was done, with the arguments
• which run and step, linking to the full trace
• the model id, pinned to a dated version rather than a floating alias
• the prompt version: a hash, or the commit it came from
• the inputs that led to it, or a reference to them
• who approved it, if anybody did
• when, in UTC, with the local timezone recorded separately if it matters

The prompt version is the field people leave out and then need. Six months later somebody asks why a refund was approved in April. Without the prompt that was in force that day, the honest answer is that you do not know, and there is no way to reconstruct it.

Pin the model

If your code names a floating alias, the model can change underneath you with no change in your repository. Your audit trail will say nothing happened, your evaluation numbers will move, and the investigation will start in the wrong place. Pin the version, upgrade deliberately, and record the upgrade like any other deploy.

Retention, and the store everybody forgets

Traces are full of personal data. Decide three things before you turn tracing on: how long you keep them, who can read them, and what is redacted at write time.

Then make sure a deletion request actually reaches the trace store. Teams build careful deletion for the main database and leave a year of transcripts sitting in an observability tool that never made it onto the data map. If you promise erasure, the promise covers everywhere.

Name a person

Every automation has one named owner, written in the repository. Not a team, a person, with a deputy.

This is not bureaucracy. When something goes wrong the first question is always who is going to look at it, and an automation that belongs to everybody belongs to nobody at 3am. It is also the answer to the question a customer, a regulator or your own board will ask, in those words: who decided this? The answer has to be a name.