The manufacturer — a precision components firm with four hundred and thirty employees, three facilities, and a customer list that includes two Tier 1 automotive suppliers — came to us because they were trying to renew their cyber insurance. The underwriter had sent a questionnaire. One of the questions asked them to list every AI system in production. They could not answer it.
This was not, as it turned out, a technology problem. The technology was working. AI was running in the quality inspection line, in the demand forecasting model, in the accounts payable automation, in the customer service email triage, in the HR screening tool, and in two internal tools built by the operations team in the previous eighteen months. Seven systems. None of them were on a list anywhere. None of them had a named owner in any governance document. None of them had been reviewed since deployment.
The underwriter's question had exposed something the organisation already knew, at some level, but had not yet been forced to confront: they were operating AI systems they could not describe, owned by people who did not know they owned them, with risks that had never been assessed.
We built the registry in thirty days. This is the account of how we did it, what we found, and what it changed.
The deployment pattern that produces invisible AI.
The manufacturer's situation is not unusual. It is, in our experience, the modal situation for mid-market operators who have been adopting AI over the past three years. The pattern is consistent: AI enters the organisation not through a central program but through departmental initiative. A vendor demo convinces an operations manager. A finance team builds a model in Python. A vendor integration adds an AI feature to an existing platform. Each deployment is a local decision, made by a local owner, without reference to an organisational inventory.
The result is an AI estate that no one has a complete view of. The IT department knows about the systems it manages. It does not know about the systems the operations team built. The operations team knows about its systems. It does not know about the vendor integrations the finance team added. The finance team knows about its tools. It does not know that the HR team's screening tool uses a model that was trained on data that includes protected characteristics.
This is not a failure of intent. It is a failure of structure. The organisation was not designed to have a central view of its AI systems because, until recently, no one needed one. The need arrived faster than the structure.
The first question is definitional.
The first thing we did was define what counted as an AI system for the purposes of the registry. This is not a trivial question. The manufacturer's instinct was to limit the definition to "machine learning models" — which would have excluded the rules-based automation in accounts payable and the decision tree in the customer service triage tool. We pushed back.
Our working definition: any system that uses automated logic — whether machine learning, statistical modelling, or rule-based automation — to make or materially influence a decision that would otherwise require human judgment. This definition is deliberately broad. It is better to over-include and then remove items than to under-include and miss something that matters.
We assembled a four-person task force: the head of IT, the head of operations, the general counsel, and a recorder. We gave them a mandate: in five days, identify every department that might be using AI, and assign a point of contact in each department for the intake questionnaire.
The task force identified nine departments. We sent a two-page intake questionnaire to each department head. The questionnaire asked: what automated tools do you use that make or influence decisions? Who owns them? When were they last reviewed? What data do they use?
What the questionnaire found.
The intake produced thirty-one responses. Of those, fourteen described systems that met our definition of an AI system. Seven of those fourteen were systems we had not known about before the questionnaire. Three of the seven were vendor-provided tools that had been added to existing platforms without IT involvement. Two were internally built tools that existed only in the operations team's shared drive. One was a model the finance team had built to predict customer payment timing, which had been running in production for fourteen months without any documentation.
The fourteenth system was the most significant finding. The HR team's candidate screening tool — a vendor-provided product — had been configured to use a scoring model that the vendor had updated six months earlier. The update had changed the model's weighting in ways that the HR team did not know about and had not reviewed. The team had been using the tool's outputs as a significant input to hiring decisions for six months without knowing that the underlying model had changed.
This is the kind of finding that an AI registry exists to surface. It is not a dramatic failure — no one was harmed, no decision was provably wrong — but it is exactly the kind of undocumented change that, in a regulated context, becomes a significant liability.
Three vendor integrations had been added to existing platforms by department heads without IT involvement. Two internally built tools existed only in a shared drive. The IT department's system inventory was missing nearly half the AI estate.
Every system had a de facto owner — the person who had deployed it or who used it most. None of those owners had been formally assigned governance responsibility. When we asked who was accountable for the HR screening tool, three people named two different people.
The HR screening tool's underlying model had been updated by the vendor six months prior. The vendor's contract did not require notification of model updates. The organisation had no mechanism to detect the change.
Not all AI is equally risky.
The fourteen systems were not equally risky. The demand forecasting model, if it produced a bad forecast, would result in inventory inefficiency — a real cost, but a recoverable one. The HR screening tool, if it produced biased outputs, could result in discriminatory hiring decisions — a different category of risk entirely.
We used a three-tier risk classification: High (systems that influence decisions about people, or that are subject to regulatory oversight), Medium (systems that influence significant operational decisions with material financial consequences), and Low (systems that automate routine tasks with human review of outputs).
Of the fourteen systems, three were High: the HR screening tool, the quality inspection AI (which influenced product release decisions), and the accounts payable automation (which processed payments above a threshold that triggered financial controls). Five were Medium. Six were Low.
The risk tier determined the documentation requirement. High-risk systems required a full model card, a named owner with explicit governance accountability, a review cadence of at least quarterly, and decision-level audit logging. Medium-risk systems required a simplified model card and semi-annual review. Low-risk systems required a registry entry and annual review.
What the registry actually contains.
By day twenty-five, we had a working registry. It lived in a shared Notion workspace — not because Notion is the ideal platform, but because it was the platform the organisation already used and the team already knew how to maintain.
Each registry entry contained: the system name, the vendor or builder, the deployment date, the named owner (a specific person, not a team), the risk tier, a brief description of what the system does and what decisions it influences, the data inputs, the known limitations, the last review date, the next review date, and a link to the model card for High and Medium systems.
The model cards for the three High-risk systems took the most time. Each model card contained: the system's purpose, the training data (or, for vendor systems, the vendor's published description of the training data), the performance metrics the organisation was tracking, the known failure modes, the human oversight process, and the incident log.
The registry was not complete on day thirty. It was not meant to be. Day thirty was the point at which the registry was accurate enough to be useful, maintained by a process that would keep it accurate, and owned by people who understood their responsibility for it.
Three things that were different after.
The cyber insurance question was answered. The underwriter received a complete AI system inventory, with risk tiers and model documentation for the three High-risk systems. The policy was renewed. The premium did not increase.
The HR screening tool was reviewed. The vendor was contacted and asked to provide documentation of the model update. The vendor provided a summary of the changes. The HR team reviewed the changes with legal counsel and determined that the updated model required a bias audit before continued use. The audit was conducted. The tool was cleared for continued use with additional monitoring.
The operations team's two internally built tools were documented for the first time. One of them, on review, was found to be making decisions that exceeded the scope its builder had intended. The scope was corrected. The tool was re-documented with accurate parameters.
None of these outcomes required a large investment. The thirty-day engagement cost less than one month of the HR team's exposure to an undocumented model update. The registry, maintained at a weekly cadence by one person for forty-five minutes, costs less per year than a single compliance incident.
The discipline, not the database.
The registry is not a database. It is not a platform. It is not a software purchase. It is a discipline — the discipline of knowing what AI you operate, who owns it, what it does, and when it was last reviewed.
We have seen the discipline maintained in a Google Sheet, a Notion workspace, a Confluence page, and a SharePoint list. We have seen it fail in a purpose-built AI governance platform that cost six figures and was never updated after the initial implementation. The form does not determine the outcome. The discipline does.
The discipline requires three things: a named owner for the registry itself (not a team — a person), a regular cadence for updates (weekly is the minimum for a live estate), and a rule that if a system is not on the registry, it is not in production. The last rule is the most important. It is the rule that gives the registry its teeth.
The registry is not the goal. The goal is knowing what you operate. The registry is the instrument. The discipline is the practice. The practice is what survives the next vendor update, the next team change, the next audit. — Field note, thirty-day close-out
The manufacturer now runs a forty-five-minute registry review every Monday morning. Four people. One agenda: what changed, what needs action, what is coming up for review. The minute from that meeting is the organisation's governance record for the week. Twelve months from now, the stack of those minutes will be the organisation's actual governance position — not a policy document, not a board presentation, but a record of what they actually decided to do, week by week, about the AI systems they actually operate.
That is the whole argument for the registry. It is not glamorous. It is not a transformation program. It is a list, a cadence, and a discipline. It is also, when the underwriter calls or the regulator writes, the difference between a forty-eight-hour response and a two-week scramble.