Transparency and logging for AI systems: what ISO 42001 and the EU AI Act require

When something goes wrong with an AI system, the first question is always the same: what exactly happened? What input did the system receive, which version of the model was running, and did a human look at it? Organizations that cannot answer these questions have a problem bigger than the incident itself. They cannot reconstruct, cannot learn and cannot account for their decisions. This is exactly why both ISO 42001 and the EU AI Act set requirements for transparency and logging of AI systems. In this article: what those requirements involve, what you should record in practice and where audits reveal the gaps.

Why transparency and logging belong together

Transparency and logging are often treated as separate topics, but they are two sides of the same coin. Transparency is about what you communicate before and during use: to users, to affected persons and to customers. Logging is about what you can demonstrate afterwards: which decision was made, based on what and under which circumstances. An organization that claims to be transparent but logs nothing cannot substantiate its own claims. And an organization that logs everything but informs nobody does not meet the expectations of the standard and the law either.

What ISO 42001 requires

ISO 42001 approaches transparency as a control objective that runs through the entire AI management system. First, the standard expects technical documentation per AI system: what the system does, its intended purpose, the data it uses and its known limitations. Second, the standard expects relevant interested parties to be informed about the use of AI, in a way that fits their role. A customer who is assessed automatically needs different information than an internal administrator. Third, the standard requires recording events throughout the lifecycle of the system, so that it can be reconstructed afterwards how the system behaved and which changes were made.

Importantly, the standard does not prescribe a specific technique. The auditor tests whether the organization has determined what should be logged and communicated per system, whether that choice aligns with the risk assessment, and whether practice matches policy. A low-risk internal application requires less than a system that makes decisions about people. But you must be able to explain that proportionality.

The EU AI Act: logging as a legal obligation

For high-risk AI systems, the EU AI Act makes logging explicitly mandatory. Article 12 requires that high-risk systems are technically capable of automatically recording events over their lifetime. The purpose is traceability: it must be possible to identify situations that may present a risk or lead to substantial modification, and to verify the functioning of the system afterwards.

Article 13 obliges providers to supply deployers with clear instructions for use: the capabilities and limitations of the system, the intended context, the expected level of accuracy and the circumstances in which the system should not be used. Organizations that procure AI are therefore entitled to this information and would be wise to actually request and retain it as part of their own evidence base.

Deployers themselves have obligations too. Article 26 stipulates, among other things, that they keep the automatically generated logs of a high-risk system for a period appropriate to its purpose, with a minimum of six months, to the extent the logs are under their control. In practice this means that when procuring high-risk AI, you must arrange that you actually receive or can access those logs. That belongs in the contract, not in a discussion after the fact.

In addition, the regulation contains transparency obligations that are independent of risk classification. Anyone offering a chatbot or other interactive AI system must let users know they are communicating with AI. Synthetic content such as AI-generated audio or video must be recognizable as such. These obligations apply broadly and are quite often overlooked for applications that are otherwise low risk.

What should you log in practice?

A workable baseline per AI system with meaningful impact looks like this. First, the context of each relevant processing: timestamp, system version and model version, and the configuration or thresholds that were active. Second, the input and output at a level that enables reconstruction, where you must choose carefully what you do and do not retain. Third, human intervention: who reviewed, adopted or overruled an outcome, and when. Fourth, changes: retraining, new model versions, adjusted prompts or thresholds, with date and responsible person.

Watch out for the tension with the GDPR. Logs of AI systems quickly contain personal data, and more extensive logging means more data you must secure and delete on time. Determine per system a retention period that serves both reconstructability and the principles of data minimization, and document that trade-off. Logging is not a goal in itself; it is a control measure with its own risk profile.

Where audits reveal the gaps

We repeatedly encounter three patterns. The first: logging exists, but nobody determined in advance what it is for. During an incident the logs turn out to lack exactly what is needed, for example because the model version is missing or prompts were not retained. The second: transparency exists only on paper. There is a fine privacy statement, but the user who actually interacts with an AI system sees nothing of it at the moment of decision. The third: for procured AI, access to the vendor's logs was never arranged, making the legal retention obligation practically impossible to fulfil.

The common thread: logging and transparency must be designed, per system and in advance. Those who treat it as a by-product discover the gaps at the worst possible moment.

Conclusion

Transparency and logging are the accountability layer of AI governance. ISO 42001 requires it from the management system perspective, and the EU AI Act anchors it legally for high-risk systems and interactive applications. Organizations that do this well have determined per AI system what is logged and why, have weighed retention periods against the GDPR, and can reconstruct what happened for every relevant decision. That is not bureaucracy; it is the difference between a managed incident and an unmanageable file.

Secure Audit helps organizations build demonstrable AI governance, from logging and transparency requirements to a certifiable AIMS under ISO 42001. Get in touch for a no-obligation conversation.