AI Governance Registers and Technical Documentation

This article accompanies Hour 3: EU AI Act Scope, Obligations and Governance in our full-day CPD programme on XpertAcademy. Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.

A legal team has an AI inventory spreadsheet. It was created quickly after a board question: "Where are we using AI?"

The spreadsheet has 43 rows. Some entries are approved enterprise tools. Some are free web tools used by individual teams. Some are AI features inside software the organisation already bought. The columns are tool name, vendor, department and notes. There is no owner, no risk classification, no AI Act role, no personal data field, no DPIA status, no review date and no trigger for reassessment.

That spreadsheet is still useful. It is the start of discovery. It is not yet an AI governance register.

For DPOs and privacy teams, this distinction matters. A thin inventory can create false comfort because it suggests the organisation has "done the AI register". In reality, the register must help people decide what needs review, what evidence exists, who owns the system, which risks have been accepted, and when the conclusion should be reopened.

Technical documentation is different again. Under the EU AI Act, providers of high-risk AI systems must draw up technical documentation to demonstrate compliance with the relevant requirements, and general-purpose AI model providers have their own documentation and information duties. Most organisations using third-party AI tools will not hold the provider's full technical documentation. They will still need enough provider evidence, instructions and internal governance records to use the system responsibly.

The job, then, is not to turn every privacy team into a product documentation office. It is to build an internal register that connects live AI use to the evidence needed for AI Act and GDPR accountability.

This article is general CPD-support information, not legal advice on a specific system or documentation obligation.

A Register Is Not Just a List

An inventory answers a discovery question: what AI tools or features appear to be in use?

A governance register answers a management question: what have we decided about each use, what evidence supports that decision, who owns the controls, and when will we look again?

That difference is practical. If an entry says "AI meeting assistant – Sales", the privacy team still cannot tell whether the tool records employees, transcribes customers, creates performance inferences, stores data outside the EEA, trains models on user content, or feeds summaries into a CRM. Nor can it tell whether the organisation is simply deploying a vendor tool, modifying it, offering it to clients, or using it in a context that may change the risk category.

An effective register should therefore track systems and use cases, not just products. The same product may have one low-risk use and one use that needs a DPIA, AI Act transparency review or senior sign-off. A generative AI assistant used to rewrite internal policy wording is not the same governance case as the same assistant used to triage employee grievances or summarise patient records.

Where Technical Documentation Fits

The AI Act uses documentation as part of accountability. For high-risk AI systems, provider obligations include technical documentation, record-keeping, quality management, instructions for use, conformity assessment and post-market monitoring. The technical documentation is intended to demonstrate that the system complies with the AI Act requirements.

That does not mean every deployer receives or should attempt to recreate the provider's full technical file. In many procurement relationships, the deployer will receive instructions for use, security and privacy documentation, risk classification information, summaries of testing, audit reports, conformity statements, transparency information and contractual commitments. Those materials may be enough for the deployer to make a proportionate governance decision, or they may reveal gaps that need escalation.

General-purpose AI also has a documentation angle. Providers of general-purpose AI models have obligations to maintain technical documentation, provide information to downstream providers, maintain a copyright policy and publish a summary of training content using the AI Office template. A privacy team buying a GPAI-enabled service does not automatically become responsible for those provider obligations, but it should understand what provider evidence is available and how it supports the organisation's use case.

The practical register should therefore include two kinds of evidence fields:

• internal governance evidence, such as DPIA screening, role mapping, data-flow notes, risk acceptance, training and review dates;
• external provider evidence, such as instructions for use, AI Act classification rationale, technical summaries, conformity information, security documentation and model or service update notices.

Keeping those fields separate avoids a common muddle. A missing provider document is not the same as a missing internal decision. Both may matter, but they need different owners.

Worked Example: Turning an Inventory Into a Register

Take the legal team's spreadsheet. One row says:

That row is not enough. The privacy team starts with four known facts: the vendor is already approved for the document platform; the AI feature has been enabled for three departments; staff can upload documents; and outputs are copied into ordinary work systems.

Several facts are still unknown. The team does not know whether customer or employee personal data is uploaded, whether special category data appears in the documents, whether prompts and outputs are used to train the vendor's model, whether the vendor hosts data outside the EEA, whether the tool is used only for drafting or also for decisions, and whether staff have been trained on acceptable use.

The decision question is: can DraftAssist AI remain in general controlled use, or does one or more departmental use case require a DPIA, AI Act role review, additional provider evidence or suspension until controls are agreed?

The improved register should split the product into use cases.

This is still a register, not a full assessment. Its job is to route work correctly. It shows that the legal team use may be manageable through acceptable-use controls and vendor evidence, while the HR use needs earlier privacy involvement because employee data and workplace power imbalance change the risk picture.

What the DPO or Privacy Team Should Check

The DPO or privacy team should resist owning every register field. The register should be a shared governance tool, not a privacy cupboard where awkward AI questions are stored until something breaks. Privacy's value is in shaping the fields that make accountability possible.

For each material use case, check:

• the specific purpose, not just the tool name;
• the affected individuals or groups, including employees, customers, patients, students, applicants or vulnerable people;
• the AI Act role assumption and whether any branding, integration, modification or onward offering could change it;
• the risk category being assumed, including whether the use may be prohibited, high-risk, transparency-risk, GPAI-related or minimal/no-risk;
• the GDPR role and processing purpose, including controller, processor or joint-controller questions;
• the personal data categories, sensitivity, source, volume, retention and access controls;
• whether the use involves profiling, inferences, special category data, biometric data, monitoring or significant effects;
• lawful basis, transparency, fairness and data minimisation;
• whether a DPIA, transfer assessment, vendor review, security review or human rights/fundamental rights assessment is needed;
• what provider evidence exists and what is still missing;
• the owner, approver, action log, risk acceptance and next review date.

The review trigger is one of the most important fields. A register without triggers quickly goes stale. Useful triggers include a new department, new user group, new data source, vendor model change, new output type, movement from drafting support to decision support, complaints, incidents, audit findings, regulator questions or changed legal guidance.

Evidence That Should Exist Afterwards

After the inventory clean-up, the organisation should have more than a tidier spreadsheet. It should have a register that can support governance conversations.

For each reviewed use case, the evidence should include:

• a named business owner and governance owner;
• a short description of the use case and intended purpose;
• AI Act role and risk assumptions, with rationale and uncertainties;
• GDPR role, personal data and DPIA screening status;
• provider evidence reviewed and gaps still open;
• internal controls, such as access limits, acceptable-use rules, human review and retention decisions;
• transparency or staff communication actions;
• escalation and sign-off notes;
• next review date and triggers.

For higher-risk use cases, the register should link to deeper documents rather than trying to contain everything itself. A register entry can link to a DPIA, vendor due diligence pack, information security review, contract addendum, risk acceptance paper, board assurance note, staff training record or post-deployment monitoring log. The register is the index and decision record. It is not the whole library.

That structure also helps when auditors, boards or regulators ask questions. Instead of searching across procurement folders, email threads and local spreadsheets, the organisation can show the system, purpose, owner, decision, evidence and review position from one place.

Common Failure Points

The first failure point is product-level recording. If the register has one row for "Microsoft Copilot", "ChatGPT Enterprise" or "AI CRM add-on", it may hide several very different use cases. The second is ownerless recording. If no one owns the row, no one will notice when the use changes.

The third is treating provider material as a substitute for internal governance. A vendor's AI Act statement may be useful, but it does not decide whether the organisation's own use is fair, transparent, proportionate or compatible with the provider's instructions. The fourth is treating GDPR assessment as a substitute for AI Act role mapping. A DPIA may be essential, but it will not automatically answer provider, deployer, importer or distributor questions.

The fifth is failing to distinguish unknown from approved. A blank field should not be read as low risk. It should mean "not yet assessed", with an owner and due date.

How This Connects to AI/DPIA Lifecycle Support

Registers are most useful when they sit inside a lifecycle. Discovery identifies AI uses. Intake captures the facts. Role mapping and risk classification decide the route. DPIA screening and provider review test the evidence. Approval records the decision. Training and controls shape behaviour. Monitoring and review keep the record alive.

XpertDPO's AI Governance and DPIA Lifecycle Support is designed around that lifecycle. The aim is to help organisations build a register that routes work sensibly, links to DPIA evidence where needed, and gives legal, privacy, security, procurement and business owners a shared factual baseline.

Where a specific use case is difficult, XpertDPO's DPIA Support and DPO Support can help test assumptions, identify missing evidence and keep the final decision owned by the organisation.

What This Means for CPD

For Event B Hour 3, the practical learning is that AI governance is not proven by having a spreadsheet. It is proven by having a register that can answer the next sensible question.

Who owns the use? What is the purpose? What AI Act role and risk category are assumed? What personal data is involved? What provider evidence exists? What internal assessment has been done? What controls apply? What would make the organisation look again?

The smallest safe next step is to choose one AI inventory row and convert it into a register entry with those fields. That exercise usually reveals whether the organisation has a governance record or only a list of tools.

This article is intended to support the learning covered in Hour 3 of our XpertAcademy CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.