From AI Policies to Compliance Evidence: What Auditors Will Ask For

Quick answer: An AI policy says what should happen. Compliance evidence shows what did happen, for a specific system. To get there, record each AI system's purpose, users, data and risks, decide which legal and internal requirements apply, give every control a named owner, and keep dated records of assessments, tests, human oversight and changes. NIST AI 600-1 and the EU AI Act text are sensible starting points.

Most organisations now have an AI acceptable-use policy. Far fewer can answer a simple follow-up question from an auditor, a customer's security team or a regulator: "Show me how this policy applies to this system, and prove it was followed last quarter." The gap between a policy document and evidence is where most AI compliance programmes stall.

Example (fictional companies): Harlow Group, a 2,000-person services firm, runs two AI features. The first is an internal writing assistant that helps staff draft emails and reports. The second is a screening tool that ranks job applicants for its recruiting team. Both were approved under the same one-page AI policy, both went through the same vendor security questionnaire, and both sit behind single sign-on. When a candidate asks how their application was scored, Harlow discovers it has no record of who approved the ranking criteria, when the model was last changed, whether anyone tested it for biased outcomes, or whether recruiters were actually reviewing its rankings. The writing assistant and the hiring tool carry very different risks, but the paperwork treats them as the same thing.

How are teams handling AI compliance today?

Most teams start with controls they already know, which is reasonable. The common pattern looks like this:

• An AI policy that lists approved tools, banned uses and rules about putting confidential data into prompts.
• Vendor reviews that reuse the existing third-party risk questionnaire, sometimes with a few AI questions added about training on customer data and data residency.
• Identity and access management, so only employees can reach internal AI tools, plus data loss prevention rules on the browser or network.
• An AI committee or review board that approves new use cases, often by email or in a meeting, with a spreadsheet as the register.
• Guardrails from the model provider or platform: content filters, prompt-injection classifiers and output moderation.

All of this is useful. It just answers a different question. It shows that the organisation has rules and some technical protections. It does not show, system by system, that the right requirements were identified, that someone owned each one, and that the controls kept working after launch.

What do current approaches miss?

The Harlow example shows four recurring gaps.

One review for every risk level. A writing assistant that drafts internal emails and a model that ranks job applicants should not go through the same review. Under the EU AI Act, AI systems used for recruitment or selection, such as filtering applications or evaluating candidates, are listed among the high-risk use cases in Annex III. That brings duties such as risk management, technical documentation, logging and human oversight. A writing assistant usually carries far lighter obligations. A single generic questionnaire hides the difference.

No system-level record. Policies talk about "AI tools" in general. Auditors ask about a particular system: what it is for, who uses it, which data it touches, which model and version it runs, which tools it can call and who is accountable. Without that inventory, you cannot show which requirements apply.

Controls without owners. "Recruiters review AI rankings" is a control only if someone is responsible for it, and if there is a record that it happened. In many programmes, controls are written down once and nobody is assigned to check them.

Evidence that stops at launch. The approval email shows the system was acceptable on the day it shipped. AI systems change often: the provider updates the model, someone edits the prompt, a new data source is connected. If changes do not trigger a new review, the original approval quietly stops describing the system you actually run. The first article in this series covers the same blind spot from the security side.

How do you turn a policy into evidence?

Think of compliance evidence as a short chain: system record, applicable requirements, controls with owners, then dated records showing that each control ran. Each link should point to the next.

1. Build a system record for each AI use case

For every AI system, capture its purpose, intended users, affected people (for example, job applicants who never use the tool), data categories, model and provider, connected tools and data sources, deployment context and a business owner. Keep it in a register people actually update, not a slide deck.

2. Classify and map requirements

Use the system record to decide which obligations apply: the EU AI Act risk category, data protection law, employment or sector rules, customer contracts and your own policies. The NIST AI Risk Management Framework's MAP function is built for exactly this context-setting step. The hiring tool and the writing assistant end up in different tiers with different control sets.

3. Assign control owners

Each control gets one named owner, a frequency and an evidence type. "Bias testing before each model change, owned by the people analytics lead, evidence: test report stored with the change ticket" is auditable. "We test for bias" is not.

4. Keep records as a by-product of the work

Evidence is cheapest when it is produced by normal workflows: approvals in the ticketing system, test results from CI, oversight actions logged by the application itself. The audit trails article in this series covers what to log at the system level.

A minimal system record can be as simple as this:

system: applicant-ranking
purpose: rank inbound applications for recruiter review
affected_people: job applicants
risk_tier: high (EU AI Act Annex III, employment)
model: vendor-hosted LLM, version pinned in config
data: CVs, application answers; no special-category data
business_owner: head of talent acquisition
controls:
  - id: HO-1  human review of every rejection   owner: recruiting ops lead
  - id: TS-2  bias and accuracy test per change   owner: people analytics lead
  - id: CH-1  change triggers re-assessment     owner: ML platform lead
evidence_location: grc/applicant-ranking/

Recommendations: a checklist

1. Create an AI system register with purpose, users, affected people, data, model, tools and a business owner for each system. Owner: AI governance lead.
2. Define risk tiers and a short triage questionnaire, so a writing assistant and a hiring tool take different paths. Owner: legal and compliance.
3. Map each tier to concrete requirements from the EU AI Act, data protection law, contracts and internal policy, and record why each one applies or does not. Owner: legal.
4. Name one owner per control, with a frequency and the expected evidence. Owner: system business owner.
5. Run and file assessments: impact assessment, security testing against the OWASP Top 10 for LLM Applications, and accuracy or fairness testing where outcomes affect people. Owner: security and data science.
6. Log human oversight in the product: who reviewed, what they changed, when. Owner: engineering.
7. Treat changes as review triggers: model version, prompt, data source, connected tool or intended use. Owner: platform or ML lead.
8. Review the register quarterly and retire systems nobody owns. Owner: AI governance lead.

How does this map to NIST, the EU AI Act and OWASP?

NIST AI RMF and AI 600-1. The NIST AI Risk Management Framework organises work into four functions: Govern, Map, Measure and Manage. The Generative AI Profile, NIST AI 600-1, published in July 2024, is a companion profile that describes 12 risks that are unique to or made worse by generative AI and suggests actions for each, organised under those four functions. Its four primary considerations are governance, content provenance, pre-deployment testing and incident disclosure. The AI RMF Playbook lists suggested actions per subcategory, which helps when you write control descriptions. Both are voluntary.

EU AI Act. The official text is Regulation (EU) 2024/1689 on EUR-Lex. For high-risk systems it sets requirements including a risk management system (Article 9), technical documentation (Article 11), record-keeping through automatic logging (Article 12) and human oversight (Article 14), and Article 26 sets obligations for deployers. Check dates carefully: Regulation (EU) 2026/1744, the Digital Omnibus on AI, amended the Act in 2026. According to the EUR-Lex summary, high-risk obligations now apply from 2 December 2027 for Annex III systems and from 2 August 2028 for systems tied to Annex I product legislation. Read the consolidated text rather than older summaries, and get legal advice on your own classification.

ISO/IEC 42001. If you want a certifiable management system around all of this, ISO/IEC 42001:2023 specifies requirements for an AI management system.

OWASP. The current OWASP Top 10 for LLM Applications 2026, published 4 August 2026, gives your security testing a shared vocabulary: for example LLM01:2026 Prompt Injection, LLM02:2026 Sensitive Information Disclosure and LLM03:2026 Excessive Agency. Citing those IDs in test reports makes them easier for auditors to follow. The OWASP GenAI Security Project hosts the official publication and related guidance.

Where to discuss and learn more

• The OWASP GenAI LLM Top 10 GitHub discussions, including a thread on prioritising LLM Top 10 risks with quantitative methods such as FAIR, useful when you rank controls.
• The OWASP Slack, where the GenAI Security Project has working-group channels, and the project's contribution page.
• Within Acta's blog, the compliance check for client calls shows what a review record can look like in a regulated workflow.

Frequently asked questions

Is an AI policy enough for an audit?

Usually not. A policy shows intent. Auditors also ask which systems it covers, who owns each control and what records show the controls ran during the audit period.

Do internal tools like writing assistants need the same review as hiring tools?

No. Triage by purpose, affected people and data. A low-risk internal assistant may need only a register entry, a vendor review and data handling rules, while a tool that ranks applicants needs a fuller assessment, testing and documented human oversight.

Which framework should we start with?

Many teams use the NIST AI RMF and AI 600-1 to structure the programme, the EU AI Act text to identify legal obligations if they operate in the EU, and the OWASP Top 10 for LLM Applications to scope security testing.

How often should evidence be refreshed?

Whenever the system changes in a meaningful way, such as a new model version, prompt, data source or tool, plus a regular review cycle, often quarterly for higher-risk systems.

Acta builds AI features on meeting data and takes these questions seriously; see our security page. Next in this series: continuous AI security testing and incident response.