Building an AI System Register Your Auditor Will Accept

The question you could not answer

Somebody asked you what AI is running in this company. It might have been the board, the statutory auditor, a banking client's third-party risk team, or your own CEO after reading something. You gave a partial answer: the customer chatbot, the document extraction pipeline, the thing procurement bought last year. Then you went to find out, and the list grew for three weeks.

What you discovered is the normal state of affairs. AI adoption in most organisations did not come through an architecture review. It arrived as a feature inside software you already owned, as a self-service subscription on somebody's corporate card, as a pilot that quietly became load-bearing, and as a browser extension three teams installed. Nobody concealed anything. There was simply no place to record it, so it was not recorded.

A register fixes that, but only if it is built to be read by someone sceptical. This paper is about the version that holds up when an auditor opens it, picks three rows and starts pulling. It is written for a CISO, DPO or head of governance who has to produce that artefact and then keep it true.

A model list is not a register

Most first attempts produce a spreadsheet with four columns: system name, model used, team, and a status that is usually "live". It feels like progress. It fails on contact with an auditor for a simple reason — it records what exists, and governance is about what is controlled.

The difference is testable. Pick any row in your current list and ask six questions. Who is personally accountable if this produces a harmful output on Monday? What personal data does it consume, and under which stated purpose? What actions can it take without a human? Who reviews those actions, and how many do they see per hour? What evidence exists that it was evaluated before go-live, and what is the date on that evidence? When does it get switched off, and who decides?

If a row cannot answer those, it is an inventory entry, not a governance record. An inventory tells you the surface area. A register tells you whether the surface area is managed, and it produces the evidence as a by-product rather than as a project each time somebody asks.

There is a second difference that matters more over time. An inventory is a snapshot and decays. A register has a maintenance model — named owners, a review cadence, change triggers, a change history — so its decay is itself measurable. An auditor who cannot see that model will not trust the contents, however complete they look.

What belongs in each row

The table below is the column structure we deploy. It looks heavy. In practice a tier-3 internal productivity tool takes fifteen minutes to register and a tier-1 system that influences a credit decision takes a day of conversations you should have been having anyway. Resist the urge to trim columns before you have populated twenty rows; the ones that feel redundant are usually the ones the auditor asks about.

Column	What goes in it	Why it is asked for	Where it usually goes wrong
System ID and name	A stable identifier plus the name the business actually uses for it	So the register, the change log, the incident record and the test report refer to the same thing	Rows named after the vendor, so two business uses of one platform collapse into one row
Accountable owner	A named individual with budget or decision authority	Accountability has to land on a person who can stop the system	"Data team" or a departed employee; a single owner holding forty rows
Business purpose	One sentence naming the decision or output it affects	Purpose limitation under DPDP, and the basis for tiering	Technology descriptions — "LLM-based summarisation" says nothing about consequence
Lifecycle stage	Pilot, limited production, production, deprecated, retired	Pilots carry different controls and have a habit of becoming production silently	Everything marked production, or a two-year-old pilot serving real customers
Risk tier and rationale	The tier, the triggers that set it, the date and who decided	The tier drives every other control; the rationale is what makes it defensible	A tier with no written reasoning, so it cannot be challenged or re-derived
Data categories consumed	Mapped to your existing data classification scheme, not free text	Links the register to the personal data inventory and the retention schedule	"Customer data" as a single category, hiding sensitive subsets
Personal data and special categories	Yes or no, plus which categories, plus whose	Drives notice, consent purpose mapping and data principal request handling	Missed free-text fields and uploaded attachments, which almost always contain more than the schema suggests
Data principals affected	Customers, employees, candidates, patients, students, minors; approximate population	Scale and vulnerability of the affected group are tiering inputs and notification scope	Minors present and not flagged, which changes the duty of care substantially
Inference input sources	Every channel by which text or data reaches the model at run time, flagged trusted or untrusted	This is the handover to security testing and the prompt-injection exposure	Only the user interface listed; retrieval sources, email intake and tool responses omitted
Training or fine-tuning data	Whether the system was trained or tuned, on what, with what provenance and permission	Training data creates obligations that inference data does not, and cannot be unwound easily	Conflated with inference data, so nobody knows whether personal data is in the weights
Model provider, identifier and version	Vendor, exact model identifier, version in use, and who approves version changes	Evaluation and test evidence is only valid for the version it was produced against	"GPT-class model" or a provider default that silently rolls forward
Deployment route	Hosted API, internal gateway, self-hosted, or embedded inside a SaaS product	Determines where data physically goes and which contract governs it	Embedded-in-SaaS systems left out entirely because no engineer built them
Tools and actions available	Every tool, API or integration the system can invoke, with the credential each uses	Defines the blast radius if the system is manipulated or simply wrong	Tools added after registration; one broad service account behind all of them
Autonomy level	Advises a human, drafts for approval, acts with reversible effect, acts irreversibly	The single strongest predictor of how much harm a failure causes	Claimed as "drafts for approval" where approval is a single click with no detail shown
Human oversight point	Who reviews, at which step, what they are shown, and how many items per hour	Oversight that cannot be exercised is not oversight, and auditors now test this	A named reviewer who has never rejected anything; review volumes nobody measured
Evaluation evidence	Link to the evaluation, the dataset used, the metrics, the date and who ran it	Shows fitness for purpose was assessed on your task, not assumed from a vendor benchmark	Evidence dated after go-live, or a vendor datasheet standing in for your own test
Security test evidence	Date, scope, findings status, and residual risk for AI-specific testing	Connects governance to the actual technical assurance on high-tier systems	A general application penetration test cited as AI security testing
Logging and monitoring	What is logged (prompts, outputs, tool calls), where, retained how long, who reviews	Determines whether you can investigate an incident at all	Prompts containing personal data retained indefinitely in a vendor's logs
Vendor, contract and DPA reference	Processor name, contract reference, data-handling terms, sub-processors, exit route	Ties into the vendor risk register and the DPDP processor obligations	Terms accepted by an individual user through a self-service sign-up
Cross-border transfer	Where data is processed and stored, and under what basis	Residency and transfer commitments you have already made to customers	Unknown, because the inference endpoint region was never specified
Known limits and failure modes	Documented behaviours it gets wrong, and the conditions under which accuracy degrades	Evidence that the system is understood rather than merely working	Left blank, which reads to an auditor as "not yet tested in anger"
Approval record	Approver, date, conditions attached, and whether conditions were met	The decision trail that shows governance operated before deployment	Approval by email thread, with conditions nobody tracked to closure
Next review date	A date, set by tier, with an owner	Makes the register a live control rather than a document	Dates in the past across most rows
Decommission date or trigger	A fixed date, or the condition that ends its use, plus who executes it	Prevents indefinite pilots and orphaned systems holding live credentials	Absent, so retired systems keep their API keys and index access for years

Tiering risk so the tier can be defended

Tiering goes wrong in one of two ways. Either everything lands in the middle tier, which means the tier carries no information, or tiers are negotiated downward by the teams who would otherwise have to do more work. Both are visible to an auditor within minutes.

The fix is to write the triggers before you tier anything, and to make any single trigger sufficient to promote a system. We use three inputs:

1. Consequence to a person. Does the output affect someone's money, credit, employment, admission, health, benefits, legal position or access to a service? Does it affect their rights or their ability to contest a decision?
2. Autonomy and catchability. Does the output take effect without a human who has the information and the time to catch an error? A reviewer seeing four hundred items an hour with a summary and an approve button is not a catch mechanism, and should be recorded as autonomous.
3. Data sensitivity and population. Sensitive categories, minors, large populations, or data you hold under a narrow stated purpose.

From those, four tiers with written triggers:

• Tier 1. Affects an individual's rights, finances, health, employment or access to a service, or acts irreversibly without effective human review. Requires named approval at executive level, documented evaluation on your own data, AI-specific security testing, a monitoring plan and a review every quarter.
• Tier 2. Processes personal data at scale, or informs a decision a human makes about a person, or can take reversible external actions. Requires owner plus governance approval, documented evaluation, security review, and a half-yearly review.
• Tier 3. Internal use on non-sensitive data with a human consuming the output and no external effect. Requires registration, an acceptable-use acknowledgement and an annual review.
• Tier 4. Experimental, on synthetic or public data, no personal data, no production integration. Requires registration, a time limit and a decommission trigger. If a tier-4 system acquires real users or real data, it is not tier 4 any more and the register entry must change before that happens, not after.

Two disciplines make this hold. Record the rationale in the row, in a sentence that names the trigger. And allow the tier to be challenged through a written process with a decision recorded — because a tier that cannot be challenged gets worked around instead.

How the register feeds DPDP obligations

The register is not a parallel compliance artefact. If it is built properly it becomes the fastest route to several DPDP answers you currently assemble by hand.

• Purpose and notice accuracy. The business purpose and data categories columns let you check that what each system actually does with personal data matches what the notice says. Mismatches here are the most common finding we see, and they are usually caused by a system quietly acquiring a second use.
• Consent purpose mapping. Where processing rests on consent, the register tells you which purposes each system relies on, so a withdrawal has a defined downstream effect rather than a mailbox and a hope.
• Data principal requests. Access and correction requests need to know where a person's data sits. An AI system holds it in more places than people expect — prompt logs, vector indexes, evaluation datasets, vendor-side retention and, if it was fine-tuned, the weights. The register should record each, per system, so the request workflow is not improvised under a clock.
• Erasure, honestly. Removing a person's data from a vector index is an engineering task. Removing their influence from a fine-tuned model is not a solved problem in general. The register's job is to make this known in advance, per system, so your response is a prepared position rather than a discovery during a complaint.
• Processors and transfers. The vendor, contract and cross-border columns feed the processor list and the transfer basis directly, and keep the AI register and the vendor risk register from diverging.
• Breach scope. When something goes wrong, the data categories, population and logging columns determine notification scope. That determination is much faster from a maintained register than from interviews.

How the register feeds security review

Three columns do most of the work here. The inference input sources column, with each source flagged trusted or untrusted, tells the security team which systems are exposed to indirect prompt injection and therefore which need AI-specific testing rather than a conventional assessment. The tools and actions column, with the credential behind each tool, gives the blast radius if a system is manipulated. The autonomy level column tells you whether a wrong output becomes an event or stays a suggestion.

Used this way, the register becomes the scoping document for testing rather than a compliance by-product. The pattern to look for is a system with untrusted inference inputs, a side-effectful tool and an autonomy level above advisory. Those rows go to testing first, regardless of tier, because that combination is where manipulation turns into consequence. The traffic runs both ways: test findings and the model version they were produced against belong back in the row, because evidence tied to a version that has since changed is not evidence.

Who maintains it, and on what cadence

Registers die from maintenance, not from design. Decide these four things explicitly and write them into the policy:

• The register has one custodian. Usually governance or the DPO's function. The custodian does not own the systems; they own the completeness and the cadence, and they escalate rows that go stale.
• Each row has a named accountable owner who attests to its accuracy on a schedule — quarterly for tier 1, half-yearly for tier 2, annually below that. Attestation is a recorded act with a date, not an unanswered email.
• Change triggers update the row before the change ships. A model version change, a new tool, a new data category, a new user population, a new integration or a move from pilot to production all require the row to be amended first. Make the register entry a gate in the change process, not a follow-up task.
• Registration is a step in procurement and in the software development lifecycle. If a system can reach production without passing through the register, the register will always be behind, and the custodian will spend their time doing archaeology instead of governance.

Keep a change history. Not for its own sake: an auditor who can see that rows were added, amended and retired over time will believe the current state. One who sees a spreadsheet with a single modification date, three weeks before the audit, will not — and they will be right not to.

Finding the AI nobody told you about

You will not complete the register by asking people to declare their AI use. Some will not know that the feature they use is AI, some will not want the governance overhead, and some will have forgotten. Combine the ask with evidence from systems you already run:

• Network and proxy logs. Outbound traffic to model API endpoints and AI SaaS domains, aggregated by source. This finds direct integrations and individual usage quickly.
• Identity and OAuth grants. Your identity provider's list of applications users have consented to is one of the richest sources, and it shows which data scopes were granted.
• Expense and card data. Finance can find self-service subscriptions faster than IT can. Search card statements and reimbursement claims for AI vendors.
• Existing SaaS you already bought. This is the largest category and the most often missed. Vendors shipped AI features into products you licensed years ago, sometimes enabled by default. Go through your top thirty SaaS contracts and ask, per product, what AI functionality is active and where the data goes.
• Browser extensions and endpoint software inventory, including developer assistants in IDEs and meeting transcription tools in calendars.
• Code and repository search for model SDKs, API client libraries and endpoint strings.
• Data egress patterns. Documents being uploaded to unfamiliar destinations in volume is often the first visible sign of a workflow nobody registered.

Then bring it in without punishment. The approach that works is a registration window — a fixed period, publicised, during which anyone can register a system with no consequence and get help doing it, followed by enforcement after the window closes. Offer something in return: a tier-3 registration should take fifteen minutes and should come with a straight answer about whether the tool is acceptable to use. If registration is slow and the answer is usually no, people will route around it and your register will be a record of the compliant minority.

Expect to find things you have to stop. Plan for that conversation before you start discovery, including who has the authority to switch something off that a team depends on.

What the auditor will actually do when they open it

They will not read all of it. They will sample and trace. Based on what we see, prepare for these moves:

1. Pick three rows and trace each end to end. Ask for the approval record, the evaluation evidence, the security test, the DPA, the log retention setting and the current model version — and check that the version matches the one the evidence was produced against.
2. Interview a named owner. Does the person in the owner column know they are the owner, and can they describe the system, its limits and the oversight step without reading the row back?
3. Check dates for sequence. Approval before go-live, evaluation before approval, review dates in the future. Out-of-sequence dates are the fastest way to lose credibility on the whole register.
4. Attack the tiering. They will take a low-tier row and test the triggers against it, looking for a system that should have been promoted. Having the rationale written in the row is what turns this from a finding into a conversation.
5. Test the oversight claim. For any row claiming human review, they will ask how many items the reviewer handles, what they see, and how many they have rejected. Have the numbers.
6. Try to find a system that is missing. Usually from invoices, an OAuth grant list or a conversation with a business team. Expect this, and have a documented discovery process to point at — an organisation that can show how it searches is in a far better position than one that claims completeness.
7. Look for retirement. Ask for a decommissioned row and the evidence that credentials, index access and data were removed. A register with no retirements suggests nothing is ever really switched off.

What satisfies an auditor is not a complete register. It is a register with a visible maintenance model, honest gaps, dated evidence in the right sequence, and a named person who can speak to any row. Completeness claimed without that reads as unexamined; acknowledged gaps with owners and dates read as controlled.

What this costs and what it does not solve

For a mid-sized organisation, a first pass — discovery, tiering policy, column structure, and thirty to sixty rows populated with evidence attached to the top tier — typically takes six to ten weeks, most of it spent in conversations with system owners rather than in tooling. Thereafter it costs a custodian’s part-time attention plus an attestation cycle. A spreadsheet register can pass an audit; what it cannot easily do is hold evidence, show change history and chase attestations, which is why most organisations move it into a system of record past roughly forty rows.

Be clear about what the register does not do. It does not make a system safe, accurate or fair — it records whether anyone has checked. It does not substitute for evaluation or for security testing; it tells you which systems need them and whether the evidence is current. And it will be incomplete, permanently, because adoption moves faster than governance. The measure of a good register is not that it is complete but that its gaps are known, owned and shrinking.