How to make AI results in compliance traceable

Table of Contents

• The question will arise
• No source, no result
• Who made the decision?
• Traceable decisions
• Scrutinising the AI
• Five questions before getting started
• Conclusion

 

The question will arise

Use artificial intelligence (AI) in governance, risk and compliance (GRC) and you quickly notice how much time it saves. Contracts can be pre-checked faster, information can be extracted in a targeted way and assessments can be prepared.

But time savings alone say little about whether a result will stand up to an audit. Another question is decisive: how did it come about? Internal audit, external auditors and supervisors need to be able to understand what your assessment is based on and who is responsible for it. If this information is missing, your work starts all over again in the audit meeting.

A typical question is: “Why was this service classified as non-critical, and who made that decision?” Saying “The AI suggested it” is of little help at that point.

Behind such a classification sits a regulatory definition. Under Article 3(22) of the Digital Operational Resilience Act (DORA), a function is critical or important if its disruption would materially impair the financial performance of a financial entity or the soundness and continuity of its services. Whether a particular service falls under this is therefore always a judgement and it is exactly that judgement which has to be justifiable later on.

The decision only becomes traceable once the information used, the assessment criteria and the expert approval have been documented.

 

No source, no result

For us, this is a core principle: every substantive statement made by the AI must be verifiable. If it assesses a contractual clause as sufficient to cover a specific DORA requirement – for instance one of the key contractual provisions set out in Article 30 of Regulation (EU) 2022/2554 – it must cite the relevant passage, ideally with page and section. If it suggests a classification, it needs an understandable rationale based on the underlying information and criteria.

If there is no reliable evidence, the assessment remains open. Convincing wording is no substitute for a sound factual basis. Nor is a source reference enough on its own. The cited passage must actually support the statement. Checking this is part of the expert review: does the passage really say what the AI claims? And is it sufficient to justify the assessment?

 

Who made the decision?

AI suggests, a person decides. For this principle to hold up in day-to-day work, the process has to reflect it. At aixom, we have implemented this in our GRC platform Leno: an AI suggestion is only adopted as an assessment once the person responsible has confirmed or adjusted it.

It must remain clear what the AI suggested, what was changed and who made the final decision. An approval documents responsibility. It should be the result of an expert review. Clear permissions are just as important. Assessments with far-reaching consequences for contracts, monitoring or risk management should only be approvable by the people responsible for them.

 

Decisions must remain traceable later on

Ask a language model the same question twice and you will not necessarily get the same answer: models select their output afresh on every run, and model versions or system settings may also have changed in the meantime. For a later audit, simply running the analysis again is therefore not enough.

What needs to be recorded is the original AI suggestion, the documents used in the version available at the time, the rationale, and the expert review and approval. Subsequent changes must also be traceable. If an assessment is adjusted later, its history must not be lost. This makes it possible to show what information was available at what point in time and why a decision was made.

 

The AI itself needs scrutiny too

Control must not end with the individual result. The AI used and the way it is integrated into the GRC tool must also be considered. Article 6 of DORA requires financial entities to have a “sound, comprehensive and well-documented” framework for managing ICT risk – that is, risk relating to information and communication technology. This framework must be documented and reviewed at least once a year. For the use of AI in GRC, this means including the associated systems, data flows and dependencies in the risk assessment.

Do you know what data is processed, where processing takes place and which providers are involved? It must also be clear whether your inputs or documents may be used to train models and who can access them.

On top of this come clear rules for use: who is allowed to start AI analyses? Which data has been approved for this purpose? And when is explicit approval required? These rules must match the protection requirements of the information and the respective use case.

 

Five questions before you start

Before you use AI results in production, you should be able to answer five questions:

1. Are statements verifiable? Are sources and assessment criteria stated, and is missing evidence identifiable?
2. Is responsibility documented? Is it traceable who reviewed, adopted or changed a suggestion?
3. Is the basis for decisions preserved? Are results, document versions and changes stored traceably for the required retention period?
4. Are approvals clearly defined? Is it set out who may review and approve which assessments?
5. Is the use of AI under control? Have data processing, hosting, access rights, use for training and internal approvals been settled?

If you can answer these questions convincingly, you have a sound basis for the next audit.

 

Conclusion

Traceability comes from the everyday use of AI. Check your sources, assign responsibility clearly and document decisions properly, and you keep your time savings even when internal audit comes asking.

You might also be interested in these articles

• Artificial Intelligence & IT Security
• Mastering IT regulation
• IT Regulations: Which IT laws should you be aware of in 2026?