Building a Compliance Evidence Pack

13 min read · updated August 4, 2026

A compliance evidence pack is not a document. It is a set of artefacts, each produced by a system or a person as a by-product of doing the work properly, assembled so that somebody can be handed the answer to a question within a day. This page lists the artefacts, says where each one comes from, and gives the structure to put them in.

Information, not legal advice. Reviewed 4 August 2026. The artefact list is drawn from the EU AI Act, the GDPR, ISO/IEC 42001 and ordinary audit practice; your obligations depend on your role, your risk classification and your jurisdiction, and not every item below will apply to you. Where an item is required by the AI Act it is marked with the article; where it is good practice rather than obligation, it says so.

What actually gets asked for

The request that arrives is rarely “send us your compliance documentation”. It is one of about eight specific questions, and building the pack around them is more useful than building it around a standard’s clause list.

Which AI systems do you use, and what does each do?
Which of them make or influence decisions about people?
Who decided this one was not high-risk, and on what basis?
Show me the assessment you did before you deployed it.
Who reviews the output, and what authority do they have?
Show me a decision from March and how it was made.
What happens to the personal data you send to the model?
What did you do when it went wrong?

Every one of those is answerable from an artefact. If it is answerable only from a person’s memory, it is not evidence.

The structure

Four layers. One that is organisation-wide, one per system, one operational and continuous, one collected from suppliers.

compliance/
  00-inventory/
    ai-system-inventory.csv          # every system, owner, status
    role-determinations/             # one memo per system
    literacy/                        # materials, attendance, rationale
    policies/                        # AI policy, acceptable use, incident
  systems/
    cv-shortlister/
      01-classification.md           # Annex III analysis, Art 6(3) if used
      02-impact-assessment.md        # FRIA / DPIA / state assessment
      03-technical-file/             # provider role only: Annex IV set
      04-instructions-for-use.pdf    # from vendor, or written by you
      05-evaluation/                 # eval set, results per model version
      06-oversight.md                # who reviews, authority, competence
      07-transparency/               # notices shown to affected people
      08-changes.md                  # model, prompt, threshold change log
    support-triage/
      ...
  operations/
    decision-logs/                   # or a pointer to where they live
    incidents/                       # register plus per-incident records
    monitoring/                      # metric definitions, alerts, reviews
    access/                          # who can call what, reviewed quarterly
  vendors/
    <vendor>/
      dpa.pdf  subprocessors-2026-08-04.pdf  certifications/
      model-documentation-2026-08-04.pdf
      training-content-summary-2026-08-04.pdf
      acceptable-use-2026-08-04.pdf  change-log-notes.md

The dates in the vendor filenames are the point. A vendor page that changes silently is not evidence of what you relied on; a dated PDF retrieved on a known day is.

Layer 1: inventory and role

Artefact	Description
AI system inventory	Every system, its purpose, its owner, the models it calls, the data it touches, its classification and its status. Source: not a survey — derive it from API key issuance, gateway request logs, cloud billing and procurement records, then confirm with owners. Surveys miss what nobody thinks of as AI.
Role determination memo	Provider, deployer or both, per system, with reasons. Six fields, one page. The first document a supervisory authority asks for and the one that decides which of the rest apply.
AI policy and acceptable use	What staff may and may not do. Required in substance by ISO/IEC 42001 clause 5 and useful evidence everywhere else.
AI literacy records	Materials, attendance, and the rationale for the tiering. Required by AI Act Article 4, in force since February 2025.
Risk register entries	AI risks in the organisation's existing register rather than a separate one. A parallel register is a sign the governance is bolted on.

Derive the inventory rather than surveying for it. Ask a hundred people what AI they use and you get sixty answers naming four tools; look at which credentials call which endpoints and you get the actual list, including the two nobody wanted to mention.

Layer 2: per-system evidence

Artefact	Description
Classification record	The Annex III analysis, and where you concluded a listed system is not high-risk, the documented Article 6(3) assessment — which the Act requires you to have made before placing on the market, and to register. A documented negative is an obligation, not an omission.
Impact assessment	A fundamental rights impact assessment under AI Act Article 27 where you are in one of the categories that owes one; a GDPR Article 35 data protection impact assessment where the processing is high risk; a state data protection assessment where a US privacy law requires one. Write one document to the strictest applicable standard rather than three that disagree.
Technical documentation	Provider role only. The Annex IV element list for a high-risk system: general description, design and development, monitoring and control, risk management, changes, standards applied, the EU declaration of conformity, and the post-market monitoring plan.
Instructions for use	As provider you write them (Article 13); as deployer you keep the version you received and use the system in accordance with it (Article 26). This is the single document that most determines whether a deployer's conduct was compliant.
Evaluation set and results	Fixed inputs, adjudicated expected outputs, version-controlled, with a result recorded for every model version and every material prompt change. Evidence for accuracy and robustness under Article 15, for validation in a financial services context, and for the acceptance criteria in your contract.
Human oversight design	Who reviews what, their competence, their authority to override and to stop, and how you know review actually happens rather than being nominal. Article 14 for the provider's design, Article 26 for the deployer's assignment.
Transparency artefacts	Screenshots of the notice a person actually sees, dated. Article 50 disclosures, the deployer's information duty, and any sector-specific notice.
Change log	Model version, prompt, retrieval configuration, threshold, and who approved each change. Not required in those words by any instrument, and the artefact that most often decides whether the rest is credible.

Layer 3: operating evidence

Layers 1 and 2 are written. Layer 3 accumulates, and it is the layer that cannot be produced retrospectively — which is why an audit that arrives before you started collecting it cannot be passed by working harder.

Logs. Providers of high-risk systems must design for automatic logging (Article 12) and keep the logs (Article 19); deployers must keep the logs under their control for a period appropriate to the purpose and at least six months unless other law provides otherwise (Article 26). Practically: request, model version, inputs or a hash of them, output, latency, cost, the caller, and any human action taken. Redact personal data at capture rather than later, because a log full of personal data is a liability that grows with retention.
Decision records. Where the system affects a person: the decision, the inputs, the model version, the threshold, whether a human reviewed it and who, and the reason given to the individual. This is what answers “show me a decision from March”.
Monitoring. The metrics, the thresholds, the alerts, and the record of periodic review. A named metric with a threshold is evidence; “we monitor” is not.
Incident register. Every incident, its classification, what was done, and whether it met a reporting threshold. AI Act Article 73 requires providers of high-risk systems to report serious incidents to market surveillance authorities promptly and in any event within fifteen days of becoming aware, with shorter deadlines for the most serious categories — take the exact deadlines from the article. Deployers must inform the provider and the authority. The runbook for AI-specific failures is a separate exercise from the register.
Access reviews. Who can call which model with which key, reviewed on a cadence. Ordinary access control, and the thing that most often reveals a system missing from the inventory.

Layer 4: what you collect from vendors

Model documentation. The Annex XII downstream information, or the Model Documentation Form where the provider signed the Code of Practice, or the model card. Dated on retrieval.
Training content summary and copyright policy, where the provider is a general-purpose model provider. Also dated.
Data processing agreement, with the sub-processor list as at a date, the transfer mechanism, and the retention terms.
Certifications and reports. ISO 27001, SOC 2, ISO 42001 where held, with their scope statements — the scope is the part that matters and the part nobody reads.
Acceptable use policy. Because it is the document that tells you which uses the provider has excluded, and an excluded use is how you become the provider.
Change notifications. Every deprecation notice and material change notice you received, filed against the system it affected.

Assembling it in a week

For an organisation with nothing, five days of concentrated work produces a defensible pack. It will not be complete; it will be honest, which is a better position than an incomplete pack that pretends otherwise.

Day 1 — inventory. Pull API keys, gateway logs, cloud billing lines and expense claims for AI tools. Build the list. Assign a named owner to each row. Expect the list to be somewhere between two and five times as long as anyone predicted.
Day 2 — triage and role. For each system: does it touch personal data, does it affect a decision about a person, is it customer-facing. Those three answers sort the list into the ones that need work and the ones that need a line in the inventory. Write the role determination memo for the systems that need work.
Day 3 — classification and assessments. Annex III analysis for each system that affects people, with the Article 6(3) reasoning written down where you rely on it. Start the impact assessment for anything high-risk. Set the folder structure and put what exists into it.
Day 4 — vendors. Retrieve and date every vendor artefact in layer 4. This is mechanical and can be delegated. It also surfaces the gaps you have to ask the vendor for, and asking takes weeks, so it must start early.
Day 5 — gaps and plan. Write a single gap register: what is missing, who owns closing it, by when. Then write a one-page summary of the whole pack for someone who will never open the folders. That summary is what an executive or an auditor reads first.

What you will not have after a week: operating evidence, because it accumulates. Start the logging and the incident register on day one so that in six months you have six months of it.

Keeping it from going stale

A pack assembled once and never touched is worse than none, because it documents a state of affairs that has since changed and it does so with your signature on it. Four cadences keep it alive:

Cadence	Description
On change	Model version, prompt, threshold, retrieval source, vendor. The change log entry is written when the change is made, by whoever made it. If this is not automated or enforced in review, it will not happen.
Quarterly	Re-derive the inventory from the logs and reconcile it against the recorded one. Access review. New systems get a role determination.
Twice a year	Re-run the evaluation set against current model versions. Re-read the classification for anything whose use has broadened. Refresh vendor artefacts and diff them against the dated copies you hold.
Annually	Impact assessments reviewed. Literacy materials refreshed and re-delivered. Management review of the whole pack, minuted — required by ISO/IEC 42001 and good discipline regardless.

The single highest-value habit in the list is the diff against dated vendor artefacts. Providers change acceptable use policies, sub-processor lists and retention terms without announcement, and the change is often the thing that invalidates an assumption three layers up in your own documentation.