The AI Vendor and Model Register: What to Track, Who Owns It, and Why It Can't Live in a Spreadsheet

Why the AI vendor register is now a regulatory artifact, not an IT list

Most enterprises already keep a vendor list. Procurement has one, security has another, and the data protection officer maintains a record of processing activities that names processors. What almost nobody has is a single, current record of which AI vendors and which specific models touch the organisation, in what capacity, and on what legal basis. That gap is where an AI vendor register under GDPR earns its place.

The reason is structural. A conventional SaaS vendor processes data in a way you can describe once and revisit annually. An AI vendor changes underneath you. The model behind a feature is swapped, a sub-processor is added, inference moves to a different region, a provider starts training on prompts by default after a terms update. Each of these changes can alter your GDPR position without anyone signing anything new. A register that records only the vendor name and contract date cannot detect any of it.

The EU AI Act raises the stakes. Article 26 places obligations on deployers of high-risk systems, including using the system according to the provider's instructions, assigning human oversight, and retaining logs. Article 4 requires AI literacy for the people operating these systems. Article 50 imposes transparency duties for certain interactions and generated content. You cannot discharge any of these for a system you cannot name. The register is the artifact that makes the rest of the compliance programme addressable.

Our view is blunt: if your organisation cannot produce, within a working day, a list of every AI model in use, the vendor behind it, where inference happens and which transfer mechanism covers it, you do not have a register. You have an intention to build one. Regulators, auditors and enterprise customers running their own due diligence are increasingly asking for exactly this list, and the organisations that can hand it over quickly are the ones that close deals and clear audits without a scramble.

Vendor versus model: the distinction most registers get wrong

The most common design error is registering vendors when the real unit of risk is the model and the use case. Microsoft is a vendor. Azure OpenAI, Copilot, and a fine-tuned model deployed in your tenant are different things with different data flows, different residency options and different contractual terms. Registering only the vendor collapses all of that into one row and hides precisely the detail a DPO needs.

A workable register therefore has at least three linked layers. The first is the vendor entity: the legal counterparty, its establishment, its sub-processors and the paper that binds it. The second is the model or service: the specific model family and version, the deployment mode (vendor-hosted API, private tenant, self-hosted open weights), and whether the provider is a general-purpose AI model provider under the Act. The third is the use: the business process, the team, the categories of data going in, and the decisions or outputs coming out.

This layering matters because the same model can be low risk in one use and high risk in another. A foundation model summarising internal meeting notes is a different compliance object from the same model screening job applicants, which falls into the Annex III employment category and triggers the full deployer duty set under Article 26. Likewise, one vendor can appear several times at different risk levels. The register has to express that without forcing duplicate data entry.

It also needs to capture dependency. Many AI products are wrappers around someone else's model. When your CRM vendor adds a generative feature powered by a third-party model, you have acquired a fourth party without a procurement event. A register that records the upstream model provider for every embedded AI feature gives you visibility into concentration risk and into who is actually processing your data. Without this, your DPA chain has holes you cannot see.

The fields that matter: residency, DPAs, transfer mechanisms and training terms

A register is only as useful as its fields. Based on what DPOs, procurement and legal teams actually need to answer questions, we recommend treating the following groups as non-negotiable.

Start with data location and residency. Record where data is stored at rest, where inference is executed, and where support personnel can access it. These are often three different answers. A vendor advertising EU data residency may still run inference in a US region or permit remote administrative access from outside the EEA, and under GDPR Chapter V remote access can itself constitute a transfer. Capture each separately, with the date the vendor last confirmed it.

Next, the contractual layer. Record whether a data processing agreement under Article 28 GDPR is in place, its version and signature date, the list of authorised sub-processors, and the notification mechanism for changes. Then record the transfer mechanism for any restricted transfer: an adequacy decision, standard contractual clauses, or binding corporate rules, along with the status of the transfer impact assessment and, for US providers, whether the vendor is certified under the EU-US Data Privacy Framework. Adequacy decisions can be challenged, so the register should hold the mechanism and a review trigger, not just a tick.

Then the AI-specific terms that traditional vendor files omit. Does the provider train on your inputs or outputs, and is that off by default or only by opt-out? What is the retention period for prompts and completions, and is zero-retention available? Is there human review of conversations for abuse monitoring? Finally, add the Act-facing fields: the system's risk classification, whether it is a high-risk system under Annex III, the provider's conformity documentation, and the status of any Article 27 fundamental rights impact assessment where you are a public body or a qualifying private deployer. Each field should carry an owner and a last-verified date, because an unverified field is a liability dressed up as an answer.

Who owns what: assigning accountability across procurement, legal, the DPO and the business

A register fails organisationally long before it fails technically. The usual pattern is that everyone contributes and nobody is accountable, so entries decay. The fix is field-level ownership rather than a single register owner.

Procurement should own commercial and lifecycle facts: the contract, renewal dates, spend, licence counts and the vendor's onboarding status. Legal should own the contractual position: the DPA, liability terms, audit rights, and the review of changes to terms of service, which for AI vendors are frequent and consequential. The DPO owns the data protection fields: residency, transfer mechanisms, sub-processor changes, DPIA status and the link to the record of processing. Security owns the technical assurance evidence, such as certifications, penetration test summaries and access controls.

The business owner of each use case, a named individual and not a department, owns the use description, the data categories, and the human oversight arrangement required by Article 26. This is the entry people most often skip and the one auditors most often probe, because oversight has to be assigned to a person with competence, authority and support. Someone also needs to own the register as a system: a governance lead or AI office that defines the schema, chases stale fields and reports on completeness. That role is stewardship, not data entry.

We recommend a simple operating rule. No AI system goes live, and no renewal is signed, unless its register entry is complete for the fields its owners are responsible for. This turns the register from a reporting exercise into a control point. It also makes ownership visible. When a field is blank, the register shows whose it is, which is far more effective than a quarterly email asking everyone to update the spreadsheet.

Why the spreadsheet fails: five predictable breakdown points

Almost every register starts as a spreadsheet, and that is reasonable for the first twenty rows. The problems arrive at predictable points, and they are not about discipline. They are about the nature of the data.

The first is staleness without signal. A cell that was true in March looks identical in October. A spreadsheet has no concept of verification age, so a transfer mechanism confirmed two years ago reads the same as one confirmed last week. The second is the relational problem. Vendors, models, uses and sub-processors form a graph. Flattening it into rows forces duplication, so when one vendor changes its sub-processor list you must update a dozen lines and will miss some.

Third is the absence of workflow. When a vendor announces a new sub-processor, someone needs to be notified, a review needs to be assigned, an objection window needs to be tracked and the outcome needs to be recorded. A spreadsheet cannot do any of that, so the process lives in email and the register drifts from reality. Fourth is access and evidence control. Sensitive fields such as transfer impact assessments should be visible to some roles and not others, with a tamper-evident history of who changed what and when. Shared spreadsheets offer version history at best, not an audit trail an inspector would accept.

Fifth, and most damaging, is the lack of connection to the rest of the compliance stack. The register should feed risk classification, the deployer obligations tracker, incident reporting and the fundamental rights impact assessment. When it is an isolated file, every downstream process re-asks the same questions and produces slightly different answers. Fronterio's customer-owned register is built as a connected object for this reason: each entry carries owners, verification dates and links into obligations, so a change to a vendor's residency can surface the affected systems and the obligations they trigger, rather than waiting for someone to notice.

Keeping the register true: change detection, review cadence and evidence

Building the register is a project. Keeping it true is an operating discipline, and it is where most programmes quietly collapse. Three mechanisms make the difference.

The first is event-driven review in addition to calendar review. An annual vendor review is too slow for AI. Triggers should include a vendor terms update, a new sub-processor notice, a model version change, a new data category entering a use case, a security incident at the vendor, and a change in the legal basis for a transfer. Each trigger should open a task assigned to the field owner, with a due date. Where the register is connected to your intake process, new AI use cases arrive as entries rather than being discovered later through shadow usage.

The second is evidence attached to claims. A residency answer should link to the vendor documentation or written confirmation that supports it, with a date. This is the idea behind an auto-evidence ladder: claims move from self-declared, to vendor-attested, to independently evidenced, and the register shows the rung each field sits on. A DPO reviewing a register should be able to see at a glance which answers are assertions and which are proven, and prioritise accordingly.

The third is a defined cadence of reporting. Quarterly, the governance lead should be able to report completeness, the number of fields past their verification date, open sub-processor reviews, systems without a named oversight owner, and any vendor concentrations. These are simple measures, but they give leadership a view of whether the register is a living control or a document. They also feed the post-market monitoring and incident obligations. Under Article 26, deployers who identify a serious incident must inform the provider and the relevant authorities, and Article 73 sets the reporting framework. You can only run that workflow quickly if you already know which vendor, which model and which use are involved.

A practical path to a working register in 30 days

Organisations often delay because the register feels like a large undertaking. It does not need to be, if you sequence it sensibly and accept that the first version will be incomplete.

In the first week, discover. Pull the vendor master from procurement, expense and card data, single sign-on logs and browser or network telemetry to find AI tools in use, including those nobody formally bought. Add the embedded AI features in platforms you already license. Do not aim for perfection. Aim for a candidate list that is long enough to be uncomfortable.

In the second week, classify and prioritise. For each candidate, record the minimum viable fields: vendor, model or service, business owner, data categories and a first-pass risk view. Then rank by exposure, putting anything touching personal data, special category data, employment, credit, education or other Annex III areas at the top. Those entries get the full field set first.

In the third week, close the contractual gaps for the priority systems. Confirm the DPA, collect the sub-processor lists, document the transfer mechanism and establish training and retention terms. Assign every field an owner and a verification date. Expect to find vendors that cannot answer your questions quickly. That finding is itself valuable and should inform renewal decisions.

In the fourth week, operationalise. Set the intake rule that no new AI system or renewal proceeds without a complete entry, configure triggers for vendor changes, and agree the quarterly reporting measures. Then link the register to your obligations and assessments so that it stops being a standalone list. The goal at day thirty is not a finished register. It is a register with owners, evidence, triggers and a rule that keeps it current, which is a far stronger position than a polished spreadsheet nobody trusts.