AI Audit Under the EU AI Act: What It Requires

Nobody can audit a system that left no trace. That is the simple sentence underneath a complicated debate. The AI Act requires traceability but leaves the design of audit roles largely to sectors and Member States. What is not negotiable is the technical precondition. Without logs, without access records and without version history, any audit fails, regardless of who conducts it or when.

This piece sets out what an AI audit involves, which articles trigger which obligation, who each obligation falls on, and what infrastructure makes an audit possible in the first place.

The timeline, before anything else

The AI Act, Regulation (EU) 2024/1689, has been in force since 1 August 2024. The Article 5 prohibitions and the Article 4 literacy duty have applied since 2 February 2025, the general-purpose AI obligations and the penalty framework since 2 August 2025, and the Article 50 transparency framework since 2 August 2026, subject to the Omnibus transitional rule for Article 50(2) machine-readable marking (European Commission).

The high-risk catalogue this article concerns has moved. The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and has been in force since 27 July 2026 (European Commission). Under it, the rules for high-risk systems listed in Annex III apply from 2 December 2027, and those for high-risk AI embedded in physical products under Annex I from 2 August 2028 (European Commission). The core Article 50 transparency duties were not postponed as a bloc: most applied from 2 August 2026, with a transitional grace period until 2 December 2026 for the Article 50(2) machine-readable marking duty for generative AI systems placed on the market before that date (European Commission; White & Case LLP). Since 2 August 2026, organisations must still disclose that users are interacting with an AI system, label deepfakes and certain AI-generated content, and notify people subject to emotion recognition or biometric categorisation (European Commission).

That is why this text does not argue from urgency. The date an obligation bites and the date the infrastructure has to exist are two different dates. The second one comes first.

What an AI audit is

The AI Act does not define "AI audit" as a single role, and the term refers to three different things depending on context.

As a role, it means an internal or external party assessing a system for conformity. The AI Act governs conformity assessment in Article 43 and the regime of notifying authorities and notified bodies in Articles 28 to 39. The AI Act does not create a protected professional title of "AI auditor". Internal compliance functions, statutory auditors and specialist technical assessors can all take the role, depending on the system and the sector.

As a process, it means systematic risk assessment, documentation review and ongoing post-market monitoring. The process starts before productive use and runs across the whole lifecycle. Substantial modifications trigger fresh assessment (Article 43, AI Act Service Desk).

As infrastructure, it means the technical preconditions that make an audit possible: logging, access control, version evidence. This third meaning is the only one that cannot be delegated. An organisation can buy in the role and the process. It has to operate, or at minimum control, the infrastructure itself.

Which article triggers which obligation

Precision pays here, because the summaries in circulation routinely swap two articles.

Article 11: technical documentation. It must exist before placing on the market and cover the information set out in Annex IV. The update duty is what matters: system changes, new model versions or altered conditions of use require it to be brought current. Article 11 requires the documentation to be kept up to date; in practice, new model versions, configuration changes or changed conditions of use need corresponding version and change evidence in the audit file, not optional metadata (Article 11, AI Act Service Desk).

Article 12: logging capability. High-risk AI systems must technically allow for the automatic recording of events over the lifetime of the system. The logging has to enable a level of traceability appropriate to the intended purpose, covering events relevant to identifying the situations where the system might present a risk or have substantial modification, and to facilitating post-market monitoring under Article 72. The regulation prescribes no format and no mandatory field list for most systems, only those purposes (Article 12, AI Act Service Desk).

Article 19: retention by the provider. Providers keep the logs referred to in Article 12(1) that their high-risk systems generate automatically, to the extent those logs are under their control, for a period appropriate to the intended purpose and at least six months, unless Union or national law provides otherwise. Providers that are financial institutions maintain them as part of the documentation kept under financial services law (Article 19, AI Act Service Desk).

Article 26(6): retention by the deployer. The mirror duty on the deployer side, again at least six months for the logs under its control, with the same financial-services carve-out (Article 26, AI Act Service Desk).

In short: Article 12 requires that the system can log. Articles 19 and 26(6) require that someone keeps the logs. Citing Article 19 as the source of the logging obligation misses the structure, and you will be asked about it in a tender.

The wider audit set also includes Article 9 (risk management system), Article 10 (data governance), Article 14 (human oversight), Article 17 (quality management system) and Article 72 (post-market monitoring).

Provider or deployer: the role question governs everything else

This distinction is frequently stated backwards, usually in the form that the conformity duty stays with the deployer and cannot be handed to the provider. That inverts the scheme.

Conformity assessment is a provider obligation. Article 16 requires providers to ensure their high-risk system undergoes the relevant conformity assessment procedure under Article 43 before it is placed on the market or put into service, alongside the quality management system under Article 17 and the log retention under Article 19. The deployer has its own, narrower obligations under Article 26: operate in line with the instructions for use, ensure human oversight, monitor operation, retain logs.

The point most of those texts are reaching for is different, and correct: you can become a provider without having built a model. Article 25 treats a distributor, importer, deployer or other third party as the provider where they put their name or trademark on a high-risk system already on the market, make a substantial modification that leaves it high-risk, or change the intended purpose of a system, including a general-purpose one, so that it becomes high-risk. So an organisation that rolls out a bought-in model under its own branding as an internal tool, for a purpose it was not intended for, may have moved the entire provider catalogue onto itself (Article 25, AI Act Service Desk).

For procurement that yields a concrete question: what role are we in for this system, and what would we have to change for the role to change?

What the infrastructure has to deliver

Four capabilities carry auditability. None can be retrofitted, because each produces records that later either exist or do not.

Inference-level logging

An auditable log answers, for each request, who made it, which model in which version responded, at what time and under what authorisation. Gaps are not a technical imperfection; they reduce the evidential value of the whole period. It also matters that the logs sit under the organisation's control, because the retention duties in Article 19 and Article 26(6) attach to exactly that.

Documentation and version evidence

Technical documentation under the Article 11 is only as sound as the evidence of which system state it describes. Without a version history of the models in use and the configuration in force, you cannot show that the documentation was accurate at the point being audited.

Access control and policy enforcement

Auditability requires the system to answer, at any time, who was permitted to access which model under which conditions. Role-based access control and model-level policy enforcement are not purely an IT security measure here. They are the context that makes a log meaningful.

Control over the execution environment

An organisation that does not control the infrastructure does not fully control the logs. This is not an argument against external services as such, but a question about evidential scope: which records sit with us, which sit with the provider, and what could we put in front of a supervisory authority on our own?

Shadow AI: the part that escapes the audit

Even the most robust audit infrastructure only covers what happens inside its boundaries. AI use outside approved systems, through public endpoints or consumer applications, leaves no trace in your own infrastructure. There is no log, no access record, no documentation.

For the literacy duty this matters directly: an organisation that does not know which tools its staff actually use can neither train appropriately nor evidence that it did. Note that the duty itself was softened rather than removed. Since 27 July 2026, providers and deployers must take measures that support the development of AI literacy, taking account of knowledge, experience, education, context of use and affected persons, rather than guarantee a specific individual level, and the Commission and the Member States now take a stronger role in promoting it (European Commission).

On penalties, because a great deal of wrong information circulates here: the €35 million or 7% of worldwide annual turnover ceiling under Article 99(3) applies to non-compliance with the Article 5 prohibitions. High-risk and transparency breaches sit at up to €15 million or 3% under Article 99(4), and applying the top figure to them is the single most common error in AI Act commentary. That Article 99(4) list does not name the literacy duty, so there is no dedicated EU-level tier for it; Member States may attach their own under Article 99(1) (Article 99, AI Act Service Desk).

The causal observation still holds, and it is the real point: organisations that fail to provide a compliant and genuinely usable internal alternative generate Shadow AI themselves. People look for tools that work. Where no approved option exists, the unapproved one remains. Prohibitions without an alternative displace the problem rather than solving it.

Conclusion

Auditability does not come from downstream compliance work. It comes from decisions made before productive use. Three steps make sense regardless of the timeline:

First, inventory. Not only the documented systems, but explicitly what runs outside governance. Without that picture, every risk assessment is incomplete.

Second, clarify the role. For each system: provider or deployer, and what would change that classification?

Third, consolidate. Deployment, governance and logging are one decision. Run them as three projects and you will fail at the integration, precisely when evidence is requested.

This decision does not belong to IT alone. The CISO, the data protection officer and legal counsel belong at the table, because the choice of operating model determines the scope of what can later be evidenced at all.

Xinity provides the layer around open models: deploy on your own hardware, enforce access policies, log every inference with user identity, timestamp and model version. Try the 30-day pilot on your own infrastructure, before any long-term commitment.

Sovereign by architecture, not by contract.

AI declaration: this post was drafted with AI assistance and reviewed by the Xinity team.