The list that took two days to build

The email comes from the customer's security team, cc'd to procurement: a questionnaire, ahead of renewal, one section titled "AI systems in production." It asks for a list — every model touching their data, what it can see, who signed off on it, when it was last checked. The person who has to answer forwards it to engineering. Engineering says two, maybe three, and lists the ones everyone remembers. Someone in IT pulls up server logs and finds a fourth, a proof-of-concept from a hackathon in the spring that quietly got merged into a release and never taken back out. Nobody can say who approved it, because nobody did — it just worked, so it stayed. Two days and four Slack threads later, an answer goes out. Nobody in the room is confident it is complete.

Why we build it this way

The usual fix is an audit: once a year, or once a quarter, somebody goes around and asks every team what they have running, writes it down, and files it. It is out of date within a month, because nothing about the way people actually build stopped in the meantime. A team stands up a new use of a model on a Tuesday, and the list does not know until the next audit finds it, if it ever does.

The deeper problem is that knowing which models are in use was never anyone's job in the moment it mattered. It lived in whoever built the thing, in a chat message approving it informally, in a ticket that later got closed and archived. That is folklore — true, but only as long as someone remembers it and is still around to be asked. A registry that depends on someone filling in a form after the fact is asking people to do the record-keeping on top of the work, for a document they will rarely open themselves. It loses.

So the record cannot be a separate chore. It has to be attached to the same gate that already decides whether a model is allowed to touch a given class of data in the first place — the approval a model needs before it can run at all. Getting listed and getting turned on become the same act, not two acts where only the second one feels urgent.

How it works, roughly

For every model with a live approval, the record carries:

• Where it runs, and which system it is wired into
• Which classes of data it is allowed to see
• Who approved it, and on what date
• When it was last evaluated, and against what it was checked

Answering a question like the one in that email becomes a query against this record, not a search party across three teams and a set of old messages. When something in it looks wrong — a data class someone thinks should not be listed, an evaluation date someone disputes — a person who owns that entry corrects it, and the correction is what the next query reads, not a guess repeated from memory.

A year in, the next security questionnaire is a five-minute reply instead of a two-day scramble, and the list that goes out is one nobody has to hedge.

AI Transformation · drag to turn