Layer 06 · AI governance
AI Compliance & Audit
Prove alignment with law, regulation, and policy, on demand.
This is the base of the stack, where everything above becomes evidence. Compliance is not a document you write once; it is the ability to show, at any moment, that your AI meets the law, your regulators’ expectations, and your own policy. Five controls turn the outputs of the five layers above into a defensible, audit-ready record, so that when someone asks you to prove it, you can.
Always audit-ready
Evidence for every obligation, on demand
Regulators do not accept intentions; they ask for records. This layer maps each AI Act obligation to a control, enforces policy, and keeps the audit trail that proves conformance.
*Illustrative figures for a representative estate.
01 · Where it begins
AI Compliance & Audit Challenges
When a regulator, auditor, or customer asks you to prove your AI is compliant, the answer cannot be “give us a few weeks.” Five questions decide whether you are audit-ready. Each points to a control in this layer.
02 · The controls, explained
The five controls that make AI compliant
Each control is a distinct capability with a clear definition, a working mechanism, where the field is heading, and the consequence of skipping it. Together they turn the evidence produced across the framework into compliance you can prove on demand.
EU AI Act mapping
Knowing which obligations apply, and whether you meet them.
Definition
The practice of mapping each AI system to its regulatory risk tier and the specific obligations that follow, turning a broad, evolving law into a concrete, per-system checklist of what you must do.
How it works
Each system’s classification and risk tier is mapped to the applicable obligations: prohibited-practice rules, general-purpose model duties, and the high-risk requirements for risk management, data governance, documentation, logging, transparency, human oversight, and robustness. Gaps become a remediation plan with owners and dates.
How we help
We map your systems to their obligations across the relevant jurisdictions, identify where you fall short, and give you a prioritised, dated remediation plan, so compliance is a managed programme, not a scramble before an enforcement deadline.
Without it
Obligations are discovered late, often after an enforcement date has passed. High-risk systems run without required controls, and the organisation cannot say, system by system, whether it is compliant or exposed.
Latest regulatory news
2026–28The deadlines are now fixed. Three obligations land in August 2026: users must be told when they are interacting with AI (Article 50), regulators can begin issuing fines, and the rules for large general-purpose models become enforceable. Model providers who sign the EU’s voluntary Code of Practice are treated as compliant by default. The watermarking grace period for generative models released before August 2026 ends on 2 December 2026. Under the newly adopted Digital Omnibus, stand-alone high-risk (Annex III) obligations apply from 2 December 2027 and high-risk AI embedded in regulated products (Annex I) from 2 August 2028, so mapping is a present-tense compliance task, not future planning.
AI literacy
Ensuring the people using AI understand it.
Definition
The practice of ensuring that the people who build, deploy, and operate AI have sufficient understanding of its capabilities, limits, and risks to use it responsibly, now a legal duty, not just good practice.
How it works
Literacy is delivered as role-based training: leaders understand governance and accountability, builders understand testing and limits, and operators understand oversight and escalation. Completion is tracked, so the duty becomes evidence rather than an assumption.
How we help
We design role-based AI-literacy programmes matched to your risk profile, from board briefings to practitioner training, and give you the completion records that turn a training obligation into demonstrable compliance.
Without it
People deploy and rely on AI they do not understand, over-trusting outputs, missing risks, and mishandling incidents. The organisation also falls short of an explicit legal requirement it may not realise applies to it.
Latest regulatory news
2025AI literacy becomes mandatory. Providers and deployers are now required to ensure staff who work with AI have adequate literacy, making a documented, role-based training programme a baseline compliance control across the whole organisation.
Policy enforcement
Turning written policy into controls that actually bite.
Definition
The practice of translating written AI policy (acceptable use, approval gates, prohibited uses) into enforced technical and process controls, with a managed exceptions process for the cases that fall outside them.
How it works
Each policy statement is tied to a control that enforces it: approval workflows before deployment, automated checks against acceptable use, and blocks on prohibited practices. Exceptions are requested, approved, time-boxed, and logged, not granted informally and forgotten.
How we help
We connect your AI policy to the controls that enforce it, design the exceptions process, and make enforcement visible, so policy is something the organisation lives by, not a document that exists only to be shown to auditors.
Without it
Policy is decorative. It reassures on paper while the actual behaviour of teams and systems drifts freely from it, a gap that becomes glaring the moment an incident or audit compares what the policy says to what actually happened.
Latest regulatory news
2025–26Policy-as-control gains ground. The direction of travel is to embed policy directly into deployment workflows and automated checks, so compliance is enforced at the point of action rather than assessed after the fact.
Incident reporting
Detecting, reporting, and learning from what goes wrong.
Definition
The practice of detecting AI incidents, reporting them to the right internal and external parties within required timeframes, and feeding what is learned back into the system: a defined process, not an ad-hoc response.
How it works
The process defines what counts as a reportable incident, the triggers that surface it, the accountable owner, the internal and regulator-facing timelines, and the feedback loop that pushes findings back into testing and controls. Serious incidents for high-risk systems carry specific reporting obligations that the process is built to meet.
How we help
We build an incident-response process for AI (triggers, owners, SLAs, regulator-notification timelines, and a learning loop) and connect it to the escalation paths in the human oversight layer so a flagged issue and a reportable incident travel one accountable route.
Without it
Incidents are missed, mishandled, or reported late, breaching notification duties and repeating the same failures because nothing was learned. Regulators treat a poor incident response as evidence the whole programme is immature.
Latest regulatory news
2026Serious-incident reporting takes effect. Formal duties to report serious incidents involving high-risk AI are arriving, with defined timelines, making a tested, time-bound incident process a regulatory requirement rather than an internal nicety.
Audit trails
A complete, tamper-evident record of what AI did and why.
Definition
The automatic, tamper-evident logging of AI system activity (decisions, versions, approvals, and overrides), retained and exportable so the organisation can reconstruct what happened, and why, on demand.
How it works
High-risk systems generate automatic logs of their operation. Combined with the version, approval, and override records from the layers above, this produces a traceable history for any decision, with retention periods and an export path that meets what a regulator or auditor asks for.
How we help
We define what must be logged, ensure records are tamper-evident and retained appropriately, and build the export path, so an audit request becomes a report you generate, not an archaeology project across disconnected systems.
Without it
When a decision is challenged, you cannot reconstruct it. Logs are incomplete, scattered, or missing, and the organisation cannot evidence what its AI did: the fastest way to turn a defensible position into an indefensible one.
Latest regulatory news
2025–28Record-keeping becomes a legal duty. The EU AI Act makes logging an explicit obligation for high-risk systems: Article 12 requires automatic, lifetime event recording; Article 19 requires providers to keep those logs for at least six months; Article 26 places the same retention duty on deployers; and Article 72 requires post-market monitoring built on that data. Alongside the Act, UK and EU GDPR accountability (Article 5(2)) and records of processing (Article 30) already demand evidence of how personal data flows through AI. The field is moving in the same direction: emerging observability standards such as the OpenTelemetry GenAI conventions are turning plain logs into full decision traceability, so the audit trail remains the single most valuable artefact you can hold when a decision is questioned.
Regulatory timeline
The compliance clock is already running
The EU AI Act obligations that are already live, and the ones on the horizon. Governance has to be ready by the date each applies, not after.
Aug 2, 2026General application+
- Chatbots and other AI systems interacting with people must clearly disclose that the user is dealing with AI (Article 50).
- Deployers of emotion-recognition and biometric-categorisation systems must inform the people exposed to them.
- National authorities, market surveillance and penalty regimes go live: fines up to €35m or 7% of global turnover become practically enforceable.
- AI literacy (Article 4) has applied since Feb 2, 2025; what starts now is national enforcement and penalties for it.
Dec 2, 2026Watermarking and new bans+
- Generative AI outputs (text, image, audio, video) must carry machine-readable “AI-generated” markers; the grace period for systems already on the market before Aug 2, 2026 ends on this date.
- New prohibition on AI used to generate or manipulate CSAM and non-consensual intimate imagery (the “nudification” ban).
Dec 2, 2027Stand-alone high-risk AI (Annex III)+
- Full compliance for high-risk systems in employment, credit scoring, education, law enforcement, essential services, and similar domains: risk management, data governance, technical documentation, logging, conformity assessment, and human oversight.
- Delayed from Aug 2026 by the Digital Omnibus; conditional on harmonised standards being ready, so it could slip further.
Aug 2, 2028Embedded high-risk AI (Annex I)+
- High-risk AI that is a safety component of already-regulated products (medical devices, machinery, vehicles) gets until this later date.
03 · Framework convergence
One evidence base, many frameworks
The major AI frameworks overlap far more than they diverge. Evidence produced across the six layers satisfies all of them, which is why a common vocabulary makes AI risk legible to executives and auditable across organisations.
| Framework | What it governs | Evidenced by layers |
|---|---|---|
| EU AI Act | Legal obligations by risk tier | All six · especially AI inventory, Model assurance, and Compliance & audit |
| NIST AI RMF | Govern, Map, Measure, Manage | AI inventory · Model assurance · Human oversight · Compliance & audit |
| ISO/IEC 42001 | AI management system | All six layers |
| OWASP LLM Top 10 | AI application security | Security & access · Model assurance |
| ISO/IEC 23894 · 42005 | AI risk & impact assessment | AI inventory · Model assurance · Compliance & audit |
04 · Audit-ready in practice
The compliance checklist
Audit-readiness is a state you can lose overnight. A compliant programme maintains the following on an ongoing basis.
- A per-system obligation map. Each system is mapped to the laws and standards that apply and its current compliance status.
- Documented AI literacy. Role-based training is delivered and completion is recorded.
- Enforced policy. Every policy statement is tied to a control, with a logged exceptions process.
- A tested incident process. Triggers, owners, SLAs, and regulator timelines are defined and exercised, not just written.
- Complete audit trails. Decisions, versions, approvals, and overrides are logged, retained, and exportable.
- A public transparency statement. A defensible, plain-language account of how your AI is governed: a low-cost, high-value artefact.
From the white paper
“Who owns this when it breaks?” should have a name as the answer, not a department.
Regulators ask for records, not intentions. There is no standard AI audit-trail template: the audit trail is the whole stack, a documented inventory, validated data, security protocols, test results and oversight logs. NIST tells you the process, map, measure, manage, govern, and leaves you to fill in the thresholds.
T3 AI risk white paper
Failure modes
How audit-readiness fails
The governance gaps our reviews surface most often. Examples are illustrative patterns, not descriptions of specific clients.
Principles without a why
The most common P0 gap: principles state what, never why, what outcome, or who is accountable.
Fix · Every principle carries a purpose, a target outcome and a named owner.Stops at the org boundary
Governance covers employees but never suppliers and partners.
Fix · Extend requirements into vendor and third-party obligations (ISO 42001 §8.2, EU AI Act).Changelog is not a review cycle
An edit history that looks like maintenance but names no cadence.
Fix · Review cadence set in the standard’s RACI, with stated repercussions for non-compliance.Conflating the three
Treating a silent spec the same as a contradictory one.
Fix · Separate VIOLATIONS (contradicts), AMBIGUITIES (unclear) and GAPS (silent). Never conflate them.Locate yourself
The FIPA maturity lifecycle
Where an AI governance programme sits on the road to external assurance.
Foundation
Principles set, policies drafted, scope defined.
Implementation
Controls stood up across the lifecycle; risk tiering live; roles assigned.
Productionization
Runtime guardrails, agentic autonomy limits and incident detection wired into operations.
Assurance
Independent validation, a complete audit trail, ISO 42001 certification and EU conformity-assessment readiness.
Go deeper
The compliance playbook
Six distinctions that separate defensible compliance from paperwork theatre.
DefinitionCompliance versus audit-readiness+
Compliance is meeting the obligation; audit-readiness is being able to prove you meet it, on demand, with exports rather than explanations. An organisation can be compliant in substance and still fail a review because the evidence cannot be produced within the window the reviewer allows.
Build for the second standard. It contains the first.
FrameworkHow an obligation becomes a control+
- Classify: place the system in its EU AI Act risk tier using the Layer 1 inventory.
- Map: attach the specific articles that follow from that tier; not the whole Act.
- Assign: give each obligation a named owner, a control, and an evidence source.
- Test: check the control produces its evidence before an auditor asks, not after.
An obligation without an owner and an evidence source is a finding waiting to be written.
FrameworkWhat counts as evidence+
Logs are not evidence until they are retained, tamper-evident, and exportable. A record that can be silently edited proves nothing; a record that only an engineer can extract will not survive a regulator’s timeline. The test: could a non-technical reviewer receive it as a dated report within a day?
Field noteOne evidence base satisfies many masters+
The frameworks overlap far more than they diverge: a risk tier, a test result, or an audit trail produced once typically discharges obligations in several at the same time. References worth mapping to:
MethodLiteracy is role-based, not one-size+
The AI-literacy duty is satisfied by training matched to what each role actually does with AI: a claims handler needs to recognise over-trust and escalation triggers; a data scientist needs obligation mapping and logging duties; a director needs accountability and sign-off thresholds.
One generic e-learning module for everyone is the pattern reviewers now flag first.
MethodThe incident clock starts before you are ready+
Regulator-notification windows are measured from when the incident occurred or was discovered, not from when your process caught up. That is why the process is rehearsed in advance: triggers defined, owners named, severity tiers agreed, and the reporting template pre-drafted so the window is spent on facts, not formatting.
Sources: EU AI Act obligations and timeline; ISO/IEC 42001 clauses; T3 compliance review practice.
05 · In practice
Real-world scenarios
Compliance is not abstract. Each scenario below is an illustrative composite, drawn from patterns we see across regulated industries rather than any single client engagement, showing a genuine challenge, the controls that address it, and the outcome.
Challenge
A bank faced a supervisory review and could not evidence, system by system, which regulatory obligations applied to its AI or whether it met them.
Controls applied
EU AI Act mappingAudit trails
Outcome
A per-system obligation map and consolidated audit trail let the bank answer the review’s questions with exports rather than promises, and turned open gaps into a dated remediation plan.
Key learning
Regulators judge maturity by how quickly you can produce evidence. The ability to export beats the ability to explain.
Challenge
An NHS Trust needed to demonstrate governance over its clinical AI, which processes special-category patient data under UK GDPR Article 9, ahead of a joint review, but policy and practice had drifted apart.
Controls applied
Policy enforcementAI literacyIncident reporting
Outcome
Policy was tied to enforced approval gates, role-based literacy training was delivered and recorded, and a tested incident process closed the gap between what the policy said and what actually happened.
Key learning
A policy no one enforces is a liability, not a defence. Enforcement and training are what make a policy credible under review.
Challenge
An insurer pursued ISO/IEC 42001 certification to win enterprise business but had governance evidence scattered across teams and tools.
Controls applied
EU AI Act mappingPolicy enforcementAudit trails
Outcome
Evidence from all six layers was consolidated into a management-system structure aligned to the standard, and the conformance assessment passed with the audit trail doing most of the work.
Key learning
Certification is largely an evidence-assembly exercise. A framework that produces evidence as a by-product makes it almost routine.
Challenge
A SaaS firm kept stalling in enterprise procurement, unable to answer buyers’ AI-governance questionnaires with anything concrete.
Controls applied
EU AI Act mappingAudit trailsIncident reporting
Outcome
A public transparency statement and an evidence pack became standard attachments to proposals, and procurement questionnaires that once caused weeks of delay were answered from a single source.
Key learning
Compliance evidence is increasingly a sales asset. The firms that can prove governance quickly win the deals that hinge on it.
Disclaimer: illustrative use cases based on anonymised real-world scenarios.
06 · Questions leaders ask
Compliance & audit Q&A
Back to the top of the stack
Related layers
Next step
Could you prove your AI is compliant tomorrow?
Book a complimentary AI compliance review: a structured, qualitative session that walks through your obligation mapping, policy enforcement, incident response, and audit trails against the five controls in this layer. It is a discussion of where you are exposed today, not a scored benchmarking exercise, and you keep the findings either way.
Book your compliance call today →Why T3
Why T3 for AI Compliance and Audit?
T3 is an award-winning AI implementation partner for high-risk industries.
We support the adoption of trustworthy AI across the entire lifecycle. We design and engineer bespoke AI controls, conduct adversarial red teaming on models and AI systems, and implement end-to-end AI governance operating models, aligned to standards we helped write such as the EU AI Act, ISO/IEC 42001, and NIST AI RMF.
Where off-the-shelf GRC platforms stop, we build the custom controls, integrations, and assurance that fit your stack, your models, and your regulator.
Trusted by two-thirds of BigTech and Financial Services, this is where policy meets engineering.
