Purpose of the Template
When your team uses a generative AI tool for critical tasks like summarizing interview transcripts or searching policy documents that influence asylum decisions, transparency is essential. The UK Home Office's Asylum Case Summarisation (ACS) and Asylum Policy Search (APS) tools, based on OpenAI's 2023 GPT-4 model and Microsoft Foundry, highlight the risks of non-disclosure. These tools aren't listed in the UK's public repository of algorithmic tools, despite the UK's AI Playbook requiring such listings. Asylum seekers remain uninformed about the tools' involvement in their cases. A research group found that the ACS summaries' error rate is significantly higher than the reported 9 percent from the pilot evaluation.
This template is for an internal transparency register entry. Complete it for every AI tool that impacts a person's rights, status, or access to services. It requires you to document the tool, its oversight model, performance, and disclosure status before an auditor, journalist, or regulator asks.
Prerequisites
Before filling out the template, ensure you have:
- An AI system inventory. Identify all tools, including those adopted by individual business units, pilots, and third-party General-Purpose AI Models.
- A Risk Tiering scheme. Tools affecting decisions about liberty, status, or livelihood should default to the highest tier. ISO/IEC 23894 and the NIST AI RMF support context-driven tiering.
- Access to Validation Evidence from both pre-deployment testing and live operation.
- A named accountable owner with authority to pause the tool.
- Mapped disclosure obligations. Know which public registers, privacy notices, and individual notification duties apply.
The Template
Copy this into your governance system. Every field is mandatory; "Unknown" is acceptable only with a remediation date.
AI TRANSPARENCY REGISTER ENTRY
SECTION 1: IDENTIFICATION
Tool name:
Business owner (named individual):
Technical owner:
Date first used (pilot or production):
Current status: [Pilot / Production / Suspended / Retired]
Public register listing: [Listed (link) / Not listed, reason and target date]
SECTION 2: PURPOSE AND DECISION CONTEXT
What the tool does (one sentence):
Decision(s) it informs:
Who is affected by those decisions:
Risk tier and rationale:
Can the affected person's rights, status, or liberty change as a result? [Y/N]
SECTION 3: MODEL AND SUPPLY CHAIN
Underlying model and version:
Hosting platform:
Vendor retirement or deprecation date for the model:
Fine-tuning or prompt configuration applied:
Change-control process for model updates:
SECTION 4: HUMAN OVERSIGHT
Role of the tool: [Assists / Recommends / Decides]
Who reviews the output, and what training have they received?
Is the reviewer required to check the output against the source record? [Y/N]
How is over-reliance monitored?
Can the reviewer easily override or discard the output? [Y/N]
SECTION 5: PERFORMANCE AND LIMITATIONS
Pilot error rate and how it was measured:
Live error rate, measurement method, and date:
Error definition (factual error, omission, misrepresentation):
Quality control in place for each output type: [Describe / None]
Known failure modes (including fabricated content):
Evaluation published? [Y/N, link]
SECTION 6: BIAS AND EQUITY
Populations, languages, and dialects affected:
Bias testing conducted and results:
Residual risks (for example, loss of cultural nuance in translated or transcribed material):
Mitigations and monitoring cadence:
SECTION 7: DISCLOSURE AND REDRESS
Are affected individuals told the tool was used? [Y/N, how]
Are their representatives able to find out? [Y/N]
How can an individual challenge an AI-generated output?
Data protection assessment completed? [Y/N, date]
Privacy notice wording reviewed on:
SECTION 8: OVERSIGHT AND REVIEW
External scrutiny received (regulator, inspector, audit):
Date of next review (maximum 6 months):
Suspension criteria:
Sign-off: [Owner] [Governance lead] [Legal]
Customizing the Template
Section 2 is critical. If the answer to the final question is yes, every other section becomes mandatory with evidence attached. For lower-risk tools, shorter entries may suffice.
Section 3 addresses vendor-driven changes. Record the vendor's lifecycle dates and tie them to your change-control process. This ensures a model swap triggers revalidation, not a silent behavior change. This aligns with lifecycle discipline in ISO/IEC 5338.
Section 4 distinguishes "assists" from "decides". It's not enough to say a human makes the final call. Document what the reviewer sees and whether they're expected to verify it. If throughput targets reward speed, note that as an over-reliance risk.
Section 5 requires two error rates. Pilot conditions rarely match live operation. The gap between published pilot rates and those found by outside researchers, as seen in the Home Office case, is what this field exposes. Define "error" precisely. Where an output type lacks quality control, write "None" to trigger remediation.
Section 6 demands specificity. "Bias tested" isn't enough. Name the languages, regions, and communities represented in the material the tool processes. Describe how you check for flattened or lost nuance. ISO/IEC TR 24027 offers a vocabulary for bias sources and mitigation.
Section 7 is often weak. If people can't learn that a tool touched their case, they can't contest it. Pair this section with your Data Protection Impact Assessment and ensure your privacy notice is specific.
Validation Steps
A completed register entry is a claim. Test it.
- Reconcile against the inventory. Every high-tier tool should have an entry. Sample business units and ask what they're using that isn't listed. A register with gaps creates false assurance.
- Verify the public listing. If your obligations include a public repository, check it yourself. Don't rely on the owner's statement.
- Re-measure performance independently. Have someone outside the owning team draw a fresh sample of live outputs and score them against your error definition. Compare to Section 5.
- Run an oversight audit. Ask reviewers to walk you through how they check outputs. Look for cases where the summary was accepted without consulting the source record.
- Test the redress path. Submit a mock challenge as an affected person would. Time how long it takes to find out a tool was used and how to contest it.
- Check Section 8 dates. Overdue reviews are an early warning that the register is decaying into paperwork.
- Escalate gaps. Any "None" or "Unknown" entry for a tier-one tool goes to your governance committee with an owner and a deadline.
The point of the register is straightforward. As one researcher noted in the Home Office case, you can't ask questions about tools you don't know are being used. Make sure your organization can answer "is this being used, and how well does it work?" on request.
