AI audit checklist: what auditors ask about local AI

What does an auditor want to see when a company runs AI? Six things: an inventory of the systems, request logs, an access control concept, the provenance and licence of the models, evidence of the data flows, and named owners. A company that can produce those six items gets through a customer audit, a data protection review and internal audit without drama.

Status: 2026-09-12

The trigger is less often the EU AI Act itself than people assume. The deployer obligations for high-risk systems under Article 26 only start applying to most use cases on 2 December 2027. What audits you today is everyone else: the large customer whose supplier audit now includes AI questions, the data protection officer who wants to know where employee data goes, internal audit, the insurer. The questions those reviewers ask are remarkably similar, and this checklist is built from them.

1. The inventory: which AI is running at all

Every audit opens with the same question: which AI systems do you use, and for what? Hesitate here and the rest of the conversation is uphill, because everything else hangs off this list. A usable inventory is a table with one row per system: name, model and version, purpose, categories of data touched, where it runs, who owns it. Shadow usage belongs on the list too, meaning the private ChatGPT account someone in accounting set up. An inventory that only knows the official systems falls apart in the first employee interview.

The inventory should also settle the role question: for each system, are you the deployer or the provider? For bought-in and self-hosted systems used as intended you are the deployer, and that should be noted per system.

2. Logging: who asked what, and when

An auditor wants to see that requests to the system can be reconstructed: timestamp, user or role, which model answered. With a locally run model this is a configuration choice, since the gateway or serving layer logs anyway. The trap is not the technology but the missing rule: how long are logs kept, who may read them, when are they deleted?

There is no general statutory retention period. The reference point that has established itself is Article 26 of the EU AI Act, which requires at least six months for high-risk systems. Adopting those six months as a written house rule gives you an answer every auditor accepts, and at the same time a deletion deadline that holds up under data protection review.

3. Access control: who may reach which model

The third question targets permissions. Who may use the model, who may configure it, who can reach the data behind it? This becomes critical the moment a retrieval pipeline sits on top of internal documents: if the model can search contracts and HR files, the search must respect the same permissions as the document store itself. An audit tests this with one simple question: can a warehouse employee find salary data through the chatbot? The answer has to be a provable no, enforced by a role concept in the pipeline, not by hope.

4. Model provenance and licence: what is actually running

For locally operated open-weight models, the auditor asks about origin and legal basis: which model, which version, obtained from where, under which licence? Documenting this takes five minutes and carries real weight, because it separates an orderly operation from a hobby basement. Due diligence includes reading the licence itself: not every open model is equally free. Llama ships under its own community licence with conditions, many Qwen models under Apache 2.0, some sizes again under their own licence. Record model name, version, source, checksum and licence per system, and this question is answered in one line.

5. Data flows: proving that nothing leaves

The strongest argument for local AI is also the question where cloud setups lose the most audit time: where does the data go? With a cloud service the answer is a data processing agreement, standard contractual clauses and trust that the provider follows its own policy. With a local system the answer is a piece of evidence: an egress rule in the firewall that denies the AI server outbound connections, or a documented packet capture showing zero outbound traffic during inference.

The point is to produce that evidence once, cleanly and dated, rather than improvising it during the audit. That is the core of data sovereignty: not the promise, but the provability.

6. Owners and competence: who carries this

Finally, the organisational layer. An auditor wants a name per system: who operates it, who approves changes, who steps in when it produces wrong output? Then comes the training question. Article 4 of the EU AI Act has required measures to support the development of AI literacy among staff since 2 February 2025, as a best-efforts duty without its own fine, but a duty nonetheless. A short, documented training record per role answers it. Human oversight belongs on the same line: which outputs require four eyes, and which must never go out automatically?

Why local is easier in an audit, but not automatically

The six areas apply to any AI, cloud or own server. The difference is how the evidence comes into being. Run locally, you know which model and version is live, the logs stay in the building, and the data flow evidence is a firewall rule instead of a stack of contracts. What does not happen by itself locally is the organisation: someone has to write down the inventory, the retention rule, the access concept and the owners. A local model without those documents performs barely better in an audit than a cloud account without a contract.

This reflects our understanding of common audit practice and is not legal advice for your specific case. If you want the six items set up properly for your company once, from the inventory to the documented data flow evidence, that is exactly part of our pilot project.