Introduction
Auditors rarely begin an AI review by asking whether the model is accurate. They start by asking: what systems do you actually use? Central IT may list three licensed tools. HR, credit, and marketing may use others—chatbots, embedded generative features, department-paid connectors—that don’t appear in any register. When a tool has no owner, no documented data sources, no supplier record and no dated approval, there is nothing for an auditor to verify.
This guide is practical, not legal: it shows how to surface and make AI risks defensible during audits and operations. It does not replace counsel or a Data Protection Officer (DPO).
Table of contents
- The un-inventoried risk
- Categories of AI risk and minimal evidence
- How to read a single registry line
- When poor data and bias become real decisions
- From historical records to a signed decision
- What makes mitigation auditable
- Personal data, suppliers and cross-border transfers
- What to record for each supplier
- Automated decisions affecting people and human oversight
- The AI Act and other regulatory touchpoints
- Confirm your AI inventory before the next audit
- Pre-audit checklist
- Common mistakes and FAQs
The un-inventoried risk
This pattern repeats across small organisations and large enterprises. The auditor opens a register and asks for dates, purpose, supplier, and who authorized use. IT can show central licenses but often cannot account for local configurations, department add-ons, or a power-user enabling a copilot.
Lack of formal training or governance does not equal lack of use. It often means more untracked adoption. For audit purposes, it helps to separate three distinct risks that frequently end up in one finding:
- Technical risk: outputs are incorrect or unstable.
- Compliance risk: legal basis, notices or assessments are missing.
- Evidential risk: after an incident nobody can reconstruct which tool, version, data and human control were involved.
A practical first step for many organisations is not a more accurate model but a living inventory: each system with an owner, documented data sources, supplier and dated approval.
Categories of AI risk and minimal evidence
An approved policy alone rarely proves that controls are active. Auditors will look for a named owner, dated evidence, and a scheduled review. The table below summarizes common categories with the minimum verifiable evidence.
- Quality and provenance of data
- Risk: model trained on unauthorized, incomplete or unrepresentative data
- Minimal evidence: registry of data sources, dataset version, usage authorization
- Systematic error and discrimination
- Risk: biased decisions affecting groups of people
- Minimal evidence: group-level metrics, documented error thresholds, dated tests
- Unlawful personal data processing
- Risk: personal data used in prompts or fine-tuning without legal basis
- Minimal evidence: Data Protection Impact Assessment (DPIA), privacy notice, service configuration
- Cross-border transfers
- Risk: data stored or processed in jurisdictions without adequate safeguards
- Minimal evidence: contractual clauses, data localization details, subprocessors list
- Shadow use
- Risk: tools adopted by teams without registration or controls
- Minimal evidence: up-to-date inventory, assigned owner, approval record
- Vendor dependency
- Risk: service interruption or unilateral changes by supplier
- Minimal evidence: contractual continuity clauses, replacement plan, review records
- Automated decisions about people
- Risk: hiring, credit or disciplinary outcomes made without real human review
- Minimal evidence: decision logs, rationale, record of human review
- System manipulation
- Risk: prompt injection, data exfiltration or model memorization
- Minimal evidence: documented tests for prompt injection, incident logs
- Model drift
- Risk: degrading performance after model or data changes
- Minimal evidence: periodic tests, review dates, closure of corrective actions
How to read one line of the registry
Take the data-quality row. If you cannot point to a dataset source and its version, the finding isn’t "the model makes mistakes"—it’s "you don’t know what the model learned from." The same logic applies across other risks: a risk is acceptable only when three elements are present together—an appointed owner, dated evidence attributable to that owner, and a scheduled review. If one of these is missing, the item is an open finding.
There is also a human factor that accuracy tests don’t capture: fluent, confident outputs increase trust even when they are wrong. That cognitive bias means an appealing response is not the same as a verified decision.
When poor data and bias become real decisions
The audit-relevant error is not a single hallucination. It’s the chain that turns biased historical data into a consequential decision about a person. Regulators and data protection authorities expect technical and organizational measures to correct inaccuracies, minimise errors, and protect personal data—especially where discriminatory effects or re-identification risks exist.
From historical records to a signed decision
Imagine a credit score or CV screening model trained on past decisions. The typical escalation looks like this:
- Historical data contain spurious correlations by location, age, education or other proxies.
- Optimization magnifies these correlations because the model rewards what predicted past outcomes.
- The model’s output is stored in a file as if it were an objective fact.
- An operational decision is made based on that output; the statistical error becomes a real-world act.
A printed output proves only that the system responded, not that the result was correct.
What makes mitigations auditable
Make datasets versioned, measure metrics per relevant group, set error thresholds before go-live, monitor drift, and require human review when impact is high. For every model keep a record of owner, purpose, inherent and residual risk, dataset and version, accuracy and fairness metrics, test outcomes, incidents, corrective actions and review date. For every decision preserve a rationale, evidence of human oversight and proof that use remains proportionate to the stated purpose.
A model that is accurate on average can still be harmful for a specific group. Without group-level metrics that issue will not appear in the report you sign.
Personal data, suppliers and cross-border transfers
High-profile regulatory actions show this is not theoretical. Authorities have intervened where suppliers could not explain the categories of personal data collected, their sources, purposes and server locations. A data protection authority can limit processing quickly when a vendor fails to provide details on data types, provenance or localization.
Risk extends beyond names pasted into prompts. Parameters, logs, chat histories, telemetry and fine-tuning data can enable inference, memorization or reconstruction. Treat an “internal” chatbot as you would any data processing activity, not as an IT utility.
What to record for each supplier
For every AI system maintain these dated items, attributable to an owner:
- Supplier and processing locations: where processing occurs and who the subprocessors are
- Data categories and retention: what data enter prompts and outputs and how long they are kept
- Legal basis and anonymization: the legal ground and technical measures applied
- DPIA: a DPIA completed before deployment, not after an incident
- Tests: prompt-injection tests, extraction tests, verification of cross-border transfers
A policy is not enough. You need exported configurations, contracts, processing records, test results and approvals from privacy and security owners. The GDPR connection is operational: it’s the same use-case viewed through data protection obligations. For practical alignment with privacy registers, see our guide GDPR and Artificial Intelligence (/en/blog/gdpr-and-artificial-intelligence).
Automated decisions affecting people and human oversight
The danger is not that a machine "decides alone" but that a formal sign-off is attached to an output no one truly reviewed. Where decisions concern hiring, contract changes or termination, the final decision should rest with a person who has genuine, autonomous authority.
A token click to accept an AI suggestion is not sufficient human oversight. Before deploying automated-influenced decisions, organisations should document four things:
- Who reviews the result: a named person and role, not just "HR team".
- What they check: e.g., alignment with the file, anomalies and missing data.
- When they diverge: escalation criteria that operators know and can use.
- How they document rationale: a written justification linked to the person, not the model.
Proofs are decision logs, escalation criteria, revision evidence, error handling and training records for authorised reviewers. AuditReady can store logs and links, but it does not sign on behalf of the human decision-maker.
The AI Act and other regulatory touchpoints
Regulatory regimes are evolving. The EU AI Act (Regulation 2024/1689) sets phased obligations and penalties. A system that is low-risk today may change classification if you link it to personal data, decisions about people, or a new supplier. Treat classification as a register item with a date, an approver and a re-review schedule.
Key control implications include:
- Evidence of staff training and screening for banned practices
- Technical documentation and training-data summaries for general-purpose models
- Transparency notices for chatbots and synthetic content
- A documented review schedule for high-risk systems
These obligations mean you should collect documentation from suppliers—technical files, copyright policies and training-data summaries—and retain them. A risk classifier tool can help structure the assessment of whether a use case falls into an AI Act category; see our AI Act Risk Classifier (/en/tools/ai-act-risk-classifier). The organisation remains responsible for the classification decision, its approval and the date of the next review.
Confirm your AI inventory before the next audit
Audits usually begin the same way: an auditor picks a sampled system and asks who uses it, which data it touches, and who authorised it. If proposal, approval, execution and verification are all done by one person, the control does not hold. The CISO, DPO, procurement and internal audit are often working off the same list with different timelines.
Practical steps to prepare
- Build a complete inventory. Include AI features embedded inside applications and tools adopted by departments—even those enabled informally. An incomplete perimeter produces false confidence.
- Assign owner, purpose, lifecycle stage and classification. Without these fields the record is not queryable.
- Link processing activities, suppliers and controls. A system without a processing registry or supplier contract is an ungoverned use.
- Set minimal evidence and the review date for each risk category. Deadlines prevent perpetual postponement.
- Open a finding for each deviation, with severity, owner, deadline and closure evidence. A finding in a private email is not visible to an auditor.
- Run an audit-style sample question: if you cannot reconstruct the use, data and signatory within 20 minutes, treat the item as a finding.
Minimum registry fields: ID, system name, owner, purpose, data processed, supplier, inherent and residual risk, compensating controls, review date, and closure evidence.
AuditReady keeps purpose, owner, lifecycle state and risk classification in the inventory. Findings, incidents, tests, privacy notes and manual entries stay centralised with severity, owner, deadline, action and closure evidence. See features on governance and inventory (/en/features/governance-and-inventory).
Pre-audit checklist
- Does every system in the registry have an owner and a next review date?
- Are approvals dated before first use, not reconstructed afterwards?
- For each risk category, is there evidence of the latest control cycle?
- Are exceptions time-bounded and re-evaluated rather than perpetually renewed?
- Does every finding have an owner, deadline and verifiable closure evidence?
- Do samples include timestamps and versioning, not just screenshots?
- Do people-affecting decisions have a named human signatory who can override the tool?
Common mistakes that weaken audits
- Retroactive approvals. A later-signed report dated after a tool was already used is read by auditors as reconstruction.
- Perpetual exceptions. An exception renewed month after month without new assessment becomes de facto ungoverned use.
- Scattered evidence. Emails, chats and personal folders do not form an auditable trail without versioning or stable identifiers.
- Claimed closures not verified. A finding marked “closed” without independent verification is still open.
- Silent screenshots. Images without timestamp, user identifier and system ID cannot prove when a control ran.
Distinguish three event types: an authorised exception (a documented, time-bound derogation), a non-conformity (finding from verification) and an incident (an event that produced impacts on data, people or service). Treating them as the same status makes reports unreadable.
Frequently asked questions
Who is accountable for a classification produced by a tool? The human signatory who has the authority to change the classification. The tool is not an owner and cannot answer an auditor.
If a team is using an unregistered tool, should I just switch it off? No. Open a finding, record the system, data and an owner, then decide whether to suspend or regularise use. Deleting the tool removes evidence.
When should I re-evaluate AI Act classification? At every change in data, purpose or context of use, and at the review date recorded in the system entry. Each re-evaluation should leave a dated trace.
Is a vendor log alone sufficient evidence? No. Supplier logs must be paired with internal approvals, configuration exports and in-house tests. A third-party log shows what the vendor recorded, not that your controls ran.
Conclusion
AI controls become auditable when they are visible: owned, dated, and reviewed. Maintaining a single inventory that links systems, data, suppliers, evidence and findings transforms the next audit from a scramble for last-minute screenshots into a demonstration of dated, verifiable controls.
AuditReady centralises AI inventories, versioned evidence and findings with owners and deadlines so your next audit starts with dated proof rather than a week of frantic collection. AuditReady does not replace legal advice or assert compliance on your behalf. To see how to prepare your dossier, visit AuditReady (/en/?lang=en).