How to audit AI systems for compliance: a data-provenance checklist.

This piece covers how to audit AI systems for compliance, then gives you a data-provenance checklist to run against your own pipeline before anyone else does.

What an AI compliance audit actually examines

An AI audit is a systematic review of whether a system meets the standards that apply to it. It borrows from traditional auditing: define a scope, gather evidence, test against criteria, document findings, and remediate. There's no universal template; the rules vary by industry, jurisdiction, and use case, but the spine is consistent, and most credible frameworks converge on a similar sequence:

• Define the scope. Which systems, models, or pipelines are under review — production models, prototypes nearing deployment, and any third-party models you've integrated? Identify the risks and stakeholders that matter.
• Map the AI lifecycle. Document the full path from data collection and model design through deployment and post-market monitoring, so nothing operationally significant sits outside the audit.
• Assess the data. Examine the sourcing, provenance, quality, and labelling of training data, including the right to use it. This is where audits often find gaps.
• Evaluate the model. Accuracy, robustness, explainability, and bias against relevant fairness metrics.
• Check compliance. Map the system against the specific regulations that apply, using tailored checklists where they exist.
• Document findings and remediate. Produce a report with issues, supporting evidence, and an action plan, then agree on owners and timelines.

Notice how early the data shows up — step three of six, and how much it depends on it. You cannot assess bias without knowing how the data was labelled or prove the right to use data without provenance. The data layer isn't one topic among many; it's the foundation on which the others stand. That's why it deserves its own checklist.

Provenance and lineage: not the same thing

Two terms get used interchangeably and shouldn't be, because an auditor will expect both.

Data provenance is the origin story: where a piece of data came from, who collected it, under what consent or license it was collected, and how it was handled. It answers, "What is this, and were we allowed to use it this way?"

Data lineage is the journey: the path the data took through transformations, filters, and merges, from raw source to the dataset a model is actually trained on. It answers, "what happened to it along the way, and can we trace any output back to its source?"

You need both. Provenance without lineage tells you the data was clean at the start, but not whether a downstream step compromised it. Lineage without provenance traces a path back to a source you can't actually vouch for. Together, they establish a chain of custody: the unbroken, documented record that lets you stand behind a dataset under scrutiny.

The data-provenance checklist

Run this against each dataset that feeds a model in scope. If you can't answer "yes, and here's the evidence" to an item, that's a finding better discovered by you now than by an auditor later.

Origin and rights

• Can you identify the source of every dataset, including third-party and purchased data?
• Do you hold documented consent, a license, or a legal basis for using each source in the way you actually used it?
• For personal data, can you locate every record tied to an individual — the prerequisite for honouring deletion or "right to be forgotten" requests?

Labelling and human judgement

• Is there a record of who annotated each dataset, their relevant qualifications, and the guidelines they worked on?
• Where annotators disagree, is the disagreement and its resolution captured — not just the final label?
• Is annotation quality measured with a defensible metric (such as inter-annotator agreement), rather than asserted?

Transformation and lineage

• Can you trace any training dataset back through every transformation to its raw sources?
• Is each model version linked to the specific dataset versions it trained on, so a given model behaviour can be traced to the data behind it?
• Are dataset versions fixed and identifiable (for example, by content hash), so "the data we trained on" is unambiguous?

Evidence and retention

• Are labelling actions and data changes logged automatically, as they happen, rather than reconstructed afterwards?
• Are those logs tamper-evident, so a reviewer can trust they weren't edited after the fact?
• Are records retained for a period that meets both the relevant regulation and your model's lifecycle?
• Can you produce a chain-of-custody export in a format that an external auditor would accept, without scrambling?

Access and separation of duties

• Is access to datasets controlled and recorded, so you know who touched what and when?
• Are the people who produce labels, review them, and audit them in genuinely distinct roles?

This checklist maps directly to what the regulations increasingly expect. AI model risk management frameworks and the EU AI Act alike push toward documented provenance, traceable lineage, and an evidence trail that survives independent review. The detail varies; high-risk systems may warrant field-level lineage, while lower-risk ones need only dataset-level tracking, but the direction of travel is the same everywhere: be able to show your working.

Where LabelFort fits

This is the problem LabelFort was built to solve at the source — Predusk AI's data annotation platform for teams whose training data must withstand external review, designed so that the checklist above is satisfied by default rather than retrofitted under a deadline.

Every labelling action, reviewer decision, and dataset change is captured in a tamper-evident audit trail as it happens. Chain of custody for any project exports in formats that auditors already accept. Annotation quality is measured as inter-annotator agreement, scored and validated on your own data, with disagreements recorded rather than smoothed over. Distinct role-based workspaces enforce separation of duties, and human-in-the-loop review means no automated label enters a dataset unverified. The result is that "can you prove how this data was handled?" has an answer you can export, not improvise.

To be precise about scope: this governs the training-data layer of your audit. It complements the model-level and runtime controls and the rest of an AI audit; it doesn't replace them. But the data layer is where audits most often stall, and it's the part with the longest lead time, which is exactly why it's worth getting right first.