Two identical legal answers can appear on the same screen. The first may have been produced from the applicable version of a statute, through documented retrieval and recorded transformations; a lawyer checked the sources, corrected a faulty inference and approved the final text. With the second, we do not know which text the system used, how it found it, what it omitted or whether anyone reviewed the result at all.
The sentences are identical. Their evidential value is not.
That is the point of an audit trail in a digital legal process. Its purpose is not to accumulate as many records as possible. It is to preserve a sufficiently reliable path from source to decision. When that path cannot be reconstructed, later review quickly becomes guesswork. The system may have behaved correctly, but no one can now show it. A person may have exercised independent judgement, but the record does not reveal where or how. The source may once have been available, but its relevant version is unknown.
In this article, a digital legal process means a sequence of technical and human steps in which legal sources or data are captured, processed, reviewed and turned into a document, recommendation or decision.
The short answer is this: an audit trail is useful when it permits a reasonable reconstruction of the particular process while remaining purpose-bound, appropriately protected and subject to retention rules. It is not a universal form prescribed by law. Nor is it automatic proof that the decision was correct. It is infrastructure without which legality, professional care and responsibility become materially harder to verify.
An audit trail is more than a log
The terms are often used as though they were interchangeable. They are not.
A technical log may record that a user opened a document at 10:14, that a service sent a request to a model or that a database returned an error. That record may be invaluable for security, debugging or operational monitoring. On its own, however, it will rarely explain why a particular source was selected, which version of it affected the output, how the text changed between stages or who made the final legal judgement.
An audit trail is a broader evidential record designed for a defined purpose. It connects individual events into an intelligible sequence and places them in the context of a particular matter or run. It may draw on several types of record:
| Record | What it can show | What it does not show on its own |
|---|---|---|
| system or security log | a login, access, error or technical event | the full legal and substantive context |
| data provenance | the origin, version and transformation of data | who made the legal decision |
| build provenance | the code and process from which a software artefact was built | what happened in a particular matter |
| process audit trail | the links between sources, execution, interventions and outcome | whether the input was true or the legal conclusion correct |
| explanation | reasons that the person affected can understand and challenge | necessarily every internal event in the technical infrastructure |
The distinction matters because technical observability and legal verifiability do not coincide. A distributed system can have excellent telemetry, traces and metrics yet still be unable to answer a simple legal question: which source supports the material claim in the final document? Conversely, a well-reasoned decision can contain a clear legal argument without exposing every low-level event in the software stack.
The W3C PROV data model offers a useful general grammar. It connects entities, activities and agents through origin, derivation and attribution. In a digital legal process, that technical provenance needs an additional layer of legal meaning. It is not enough to know that an activity generated a new entity. We need to know whether the event was a machine proposal, a human amendment, a formal approval or a decision affecting a particular person.
The law does not prescribe one universal audit trail
The expression audit trail is appealing because it sounds uniform. The law is more fragmented. Different legal regimes require different forms of documentation, for different purposes and under different conditions. Common principles can be drawn from those duties, but not a general rule that every digital legal process must always record everything.
The GDPR: accountability is not an instruction to log everything
The General Data Protection Regulation requires controllers not only to comply with the data-protection principles but also to be able to demonstrate that compliance. This is the accountability principle in Article 5(2), supported by the controller’s obligations under Article 24, data protection by design and by default under Article 25, security of processing under Article 32 and data protection impact assessments under Article 35.
An audit trail may help demonstrate that those responsibilities were actually discharged. The GDPR does not, however, prescribe one case-level log for every legal matter. The records of processing activities required by Article 30 are primarily an organisational inventory. They describe, among other things, purposes, categories of data subjects and data, recipients, envisaged erasure periods and security measures. They are not a chronological history of every operation performed in an individual matter.
Article 22, which concerns decisions based solely on automated processing that produce legal effects or similarly significantly affect a person, likewise does not establish a universal technical logging schema. Yet where automation matters legally, it is difficult to make safeguards effective—or to verify that a human really intervened in the decision—if the intervention left no record.
This is where an important boundary appears. Accountability may justify documentation, but purpose limitation, data minimisation and storage limitation apply at the same time. “Log everything and keep it forever” is not a conservative solution. It may be a new infringement.
ZVOP-2: a processing log is a defined statutory subset
Slovenia’s Zakon o varstvu osebnih podatkov (Personal Data Protection Act; ZVOP-2) is more specific. Article 22 of the authoritative Slovenian text requires a processing log for certain automated processing systems. The duty is tied to conditions specified by statute, including large-scale processing of special categories of personal data, regular and systematic monitoring of individuals, certain high-risk processing and cases in which another law requires it. The English title used here is descriptive; the authoritative text is Slovenian.
Under the statutory wording, the log must record the collection, alteration, consultation, disclosure or transfer, erasure and other prescribed processing operations. It must contain the type of operation, its date and time, the identity of the person who performed it and the identity of users of the personal data in a manner that permits their exact identity to be established later. The Act also limits the purposes for which such logs may be used: demonstrating lawfulness, internal control, supervision by competent authorities, ensuring data integrity and security, and correcting errors in the system or the processing.
Retention is regulated as well. As a rule, the processing log is kept for two years after the end of the calendar year in which the operation was recorded. Retention for up to five years requires an appropriate risk-based justification or impact assessment, subject to the statutory limits. In its opinion on responsibility for maintaining an audit trail, the Slovenian Information Commissioner stressed that the duty does not automatically attach to every application or every automated system and that primary responsibility remains with the controller. The Commissioner also provides an English overview of Article 22 processing logs.
This is a good example of why legal terms should not be stretched beyond their text. A processing log under Article 22 ZVOP-2 is an important part of an audit trail where the provision applies. It is not necessarily the whole audit trail of a legal process. It may record that someone accessed a document without showing which paragraph was used in the legal argument. It may show who changed a data item without explaining why a lawyer accepted the change.
The AI Act: record-keeping for high-risk AI systems
The Artificial Intelligence Act contains a specific requirement for high-risk AI systems. Article 12 requires those systems to technically allow for the automatic recording of events—logs—over their lifetime. Articles 19 and 26 then require providers and deployers respectively to keep logs under their control for a period appropriate to the system’s intended purpose and, as a rule, for at least six months unless Union or national law provides otherwise. The purpose is not indiscriminate collection. It is a degree of traceability appropriate to the system’s intended purpose that supports operational monitoring, risk management and post-market monitoring.
Timing and scope matter here. These provisions do not apply to every AI system, still less to every digital tool used in legal work. In addition, Regulation (EU) 2026/1744 amended the application timetable for high-risk systems. At this article’s cut-off date, Chapter III, Sections 1 to 3, other than Article 6(5), are to apply from 2 December 2027 to systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 to systems classified under Article 6(1) and Annex I. It would therefore be inaccurate to present Articles 12, 19 and 26 as generally applicable duties already binding every potentially high-risk system.
The legal proposition is consequently limited: particular regimes impose express logging and retention duties. The broader conclusion of this article is analytical and architectural. Even where legislation does not prescribe a complete audit trail, preserving an evidential path proportionate to the risk and significance of the legal process is sound practice.
Three layers must be connected
A digital legal process becomes easier to reason about when its audit trail is divided into three layers. None is sufficient on its own.
| Layer | Core question | Typical records |
|---|---|---|
| system | What was the tool capable of doing? | source code, commit, build, dependencies, model, configuration, rules |
| execution | What actually happened in this matter? | sources used, queries, transformations, tool calls, input, output, errors, timestamps |
| decision | Who assessed the result, and what did they do with it? | review, amendment, rejection, approval, reason, role, time, final document |
The system layer describes design and capability. If the code is open, it can be inspected, compared and tested. But a repository without the relevant commit, build process and deployed artefact does not establish what was running in production.
The execution layer describes the particular run. Source, software version, configuration and event meet here. If the system calls an external model through an API, it may be possible to record the model name, a disclosed version, request identifier and parameters, but not the internal state of the provider’s infrastructure. A sound trail does not conceal that limit. It records the boundary of what the organisation actually knows.
The decision layer is often the most important legally and the least developed technically. A “human in the loop” label does not prove that a person conducted a substantive review. The record needs to show who had authority, what they saw, what they changed or rejected and which outcome they ultimately approved. A short reason may also be necessary for a consequential decision. Without that evidence, human oversight becomes a feature of the interface rather than a verifiable act.
What must be reconstructable
Not every system needs to retain the content of every intermediate step. An organisation should, however, decide in advance which questions it will need to answer if an outcome is challenged, a security incident occurs or an internal review discovers an error.
For a material digital legal process, the following groups of information will usually matter.
1. The source boundary
The audit trail must preserve a route back to the source supporting a material claim. That may require a stable document identifier, issuer, date or version, retrieval time, the passage used and, where appropriate, a cryptographic digest. In retrieval, it also matters what was searched, which corpus was used and which temporal or jurisdictional constraints were in force.
A hyperlink alone is often insufficient. A webpage may change, a consolidated statute may be updated and a provider may replace content under the same address. Yet copying the whole source into a log is not always lawful or necessary. The right solution depends on the source. Sometimes a version and digest are enough. Sometimes a permitted snapshot or official identifier must be retained. In other cases, a controlled reference to an archival system is preferable.
2. The identity of the system
“AI was used” has almost no evidential value. The relevant facts include the software artefact, code version, dependencies, configuration, prompt template, model and provider, generation settings, and the rules governing retrieval or post-processing.
In an open-source system, the link should run from commit to build and from build to deployed version. SLSA provenance provides a useful technical framework for stating where, how and from which inputs an artefact was produced. Even verified build provenance principally establishes the origin of the artefact. It does not establish the correctness of the legal analysis or describe the individual matter.
3. The course of execution
Events need a shared run or case identifier so that they can be connected. Material transformations should be recorded: optical character recognition, normalisation, document segmentation, retrieval, result ranking, generation of a draft, use of an external tool and subsequent correction, for example.
It is useful to distinguish the time of an event from the time at which the system observed or received it. The OpenTelemetry Logs Data Model therefore distinguishes, among other fields, Timestamp and ObservedTimestamp, and permits correlation with a trace through TraceId and SpanId. This assists reconstruction of a distributed process, but observability is not automatically an audit trail. Traces may be sampled and telemetry may be optimised for diagnosis. Legally material events should not disappear simply because the telemetry system did not select them for its sample.
4. Human intervention
The record should distinguish viewing from substantive review, amendment, rejection and approval. If a person changed a draft, it should be possible to identify the version they changed and the version that became final. If they rejected an output, that rejection should not vanish merely because it did not form part of the final document.
Identity alone is insufficient. Shared user accounts, or technical accounts used by several people, weaken attribution. Role matters too. The same person may perform a technical check without having authority to grant legal approval.
5. The final outcome and its link to the run
The final document, decision or recommendation should be linked to the run from which it emerged. If it is corrected later, history should not be silently overwritten. A correction is a new event with its own reason and time. The previous version should be retained only for as long and in such form as the purpose, legal basis and retention policy permit.
This link is why the proposition that a result is not a method matters to audit trails as well. The final text is only the last point in a process. Without a path to its source, transformations and human review, the outcome does not reveal how it came into being.
Integrity is not truth
An audit trail should resist undetected alteration. That is a more precise objective than the frequently used word immutability. Absolute immutability may conflict with lawful correction, retention periods, erasure and access restrictions. A better system does not conceal change. It records amendments as new events, protects their sequence and makes interference detectable.
A cryptographic digest can show whether later bytes match the original bytes. It cannot show that the original document was true, complete or legally valid. If the source document is no longer available, the digest alone cannot reconstruct it either. Similarly, inclusion and consistency proofs in a transparency log, such as those described in RFC 9162, can help establish that the log is append-only and that particular entries were not covertly removed later. They do not prove that every event was recorded or that the recorded information was true.
The European electronic-identification framework supplies additional mechanisms. The consolidated eIDAS Regulation gives electronic seals, electronic time stamps and electronic ledgers legal effects under specified conditions, and qualified services benefit from particular presumptions concerning origin, integrity, time or sequential chronological ordering. Those presumptions matter, but they do not validate the legal analysis. A reliable time stamp attached to a wrong document still time-stamps a wrong document.
Nor is an audit trail a magical category of evidence in litigation. Under Article 8 of Slovenia’s Zakon o pravdnem postopku (Civil Procedure Act; ZPP, descriptive English title), the court applies the principle of the free assessment of evidence and reaches its conclusion through a conscientious and careful appraisal of each item of evidence separately and of the evidence as a whole. The Supreme Court of the Republic of Slovenia emphasised the analytical and synthetic nature of that assessment in II Ips 187/2011, ECLI:SI:VSRS:2014:II.IPS.187.2011. The Higher Court in Ljubljana stressed the need for a reasoned and objective assessment in I Cp 697/2000, ECLI:SI:VSLJ:2001:I.CP.697.2000. A log may therefore be evidence, but its weight depends on how it was created, its reliability and completeness, the possibility of interference, and its relationship with other evidence.
Similarly, Articles 31 and 33 of Slovenia’s Zakon o varstvu dokumentarnega in arhivskega gradiva ter arhivih (Protection of Documents and Archives and Archival Institutions Act; ZVDAGA) allow securely preserved records in digital form, subject to specified conditions, to be treated as equivalent to the original records. It does not follow that every application log is archival material or that every database export automatically satisfies the requirements for long-term evidential preservation.
An audit trail must not become a surveillance archive
The easiest mistake is to log too much. In a legal environment, that is particularly dangerous.
Logs can contain clients’ names, health and financial data, the substance of a dispute, legal strategy, draft arguments, communications with a lawyer, system prompts, access tokens and other secrets. Slovenia’s Kodeks odvetniške poklicne etike—the Slovenian Code of Professional Conduct for Lawyers, in descriptive English—treats professional confidentiality broadly and does not confine it to the final case file. If an audit trail indiscriminately copies content into a central log, the system meant to demonstrate responsibility may create a new point of mass disclosure.
Every field should therefore answer four questions: why is it retained, who can see it, how long is it needed, and how will it be securely removed? Sensitive content should often be separated from the structural record. An audit event can retain an identifier, permitted metadata and a digest while the content remains in a purpose-built system with narrower access. Access to the audit trail itself should also be recorded.
The OWASP Logging Cheat Sheet identifies data that should ordinarily not be written directly to logs and recommends sanitisation, protection against tampering, time synchronisation and testing of logging failures. These are technical recommendations, not a legal recipe. Their value lies in making concrete something that law often states more abstractly: the security of an audit trail is part of its credibility.
Availability matters as well. If a system silently stops logging when a disk fills up, the absence of a record does not prove that the event never occurred. Logging needs to be monitored, and its failures treated as material events. An audit trail whose failure no one notices is reliable only in quiet times.
What open source reveals—and what it does not
The connection between audit trails and open source is real, but it should not be romanticised.
The Open Source Definition sets out the conditions under which software can be used, inspected, modified and redistributed. Access to source code allows independent examination of design, detection of defects, verification of implemented rules and reproducible testing. For legal-technical infrastructure, that is an important form of public method.
An open repository does not answer three decisive questions: which commit was actually built, which artefact was deployed and what happened during the particular run. It may not reveal an external model, a database, a secret configuration or a provider’s service-side change. Even completely open code does not guarantee an entirely reproducible result. PyTorch’s reproducibility documentation expressly warns that complete reproducibility is not guaranteed across releases, platforms or CPU and GPU environments.
Open source therefore supports the first layer of the audit trail most directly: it shows how the system was designed and what can be verified in its implementation. Build provenance connects code to artefact. The execution record and the record of human decision must be created separately.
For OpenLegalCore, this supports a restrained but strong principle: public method, controlled audit evidence, private case content. A client’s document need not be published for the method to be open to inspection. A production log need not be public for an authorised reviewer to receive evidence of the version used. Openness and confidentiality are not opposites when they are separated by layer and purpose.
The verifiability envelope: a practical model
We use the term verifiability envelope to connect these layers. It is not a statutory term and it does not denote a new file format. It is an analytical model for a structured set of records that accompanies a material result and preserves its essential links.
Depending on the risk of the process, a minimum verifiability envelope should answer at least the following questions:
- What was the subject of the process? The case or run identifier, purpose of processing and permitted scope.
- Which sources were used? Issuer, version, retrieval time, relevant passages and a verifiable route back to the source.
- Which system operated? Artefact, commit or version, model, provider, configuration and material dependencies.
- What happened? The sequence of significant transformations, queries, tool calls, errors and outputs connected by a shared identifier.
- Where did a person intervene? The reviewer’s identity and role, action taken, amendment or rejection, time and, where necessary, reason.
- What became final? The outcome version, its connection to the run and any later corrections.
- How are integrity and access protected? Digests, signatures or seals, append-only records, access control, encryption and access logging.
- When does the record cease to exist? Legal basis, retention period, any hold imposed because of proceedings, and controlled erasure.
- Which blind spots remain? Sampling, unreliable time, an external provider, an unknown version or failure of a particular step.
The envelope need not be one monolithic file available to everyone. It may consist of linked records with different access rights and retention periods. The structural metadata trail can be separated from confidential content; build evidence from the execution log; the lawyer’s decision from technical telemetry. What matters is that the links remain verifiable and the system does not create a false impression of completeness.
Implementation may use append-only records, cryptographic linking or signatures for material events, segregated administrative roles, backups and regular tests of export and restoration. No single technology is a universal solution. Blockchain is not the default answer. A well-governed append-only log with a clearly trusted source, access control and independent verification will often be enough.
Above all, the claim boundary must remain visible. If the system cannot establish the exact version of an external model, it should say so. If lawful minimisation means that the trail does not retain content, it should explain which evidence was preserved instead. If complete reproduction is impossible, the actual output should be retained rather than promising a theoretical reconstruction that cannot be performed in practice.
An audit trail does not replace explanation or responsibility
A technical export containing thousands of events is not an explanation for a person trying to understand a decision. In Case C-203/22, Dun & Bradstreet Austria, ECLI:EU:C:2025:117, the Court of Justice of the European Union held, in interpreting the right of access to meaningful information about the logic involved, that the information must explain the procedure and principles actually applied in a concise, transparent, intelligible and easily accessible form so that the data subject can understand and challenge the automated decision. Where third-party data or trade secrets are implicated, the protected information must be made available to the competent supervisory authority or court for the required balancing; their existence does not justify an automatic refusal.
The distinction is useful beyond the direct scope of that judgment. An audit trail is raw material for review. An explanation communicates the reasons for a decision. The former may be more detailed and available only to authorised persons; the latter must be intelligible to its addressee. Neither should be passed off as the other.
The same is true of human responsibility. A system may show that a lawyer clicked “approve”. It cannot by itself prove that the review was sufficiently careful. The organisation must define authority, review criteria, adequate time for judgement and a real ability to reject the automated proposal. An audit trail allows those arrangements to be examined. It does not create them on the organisation’s behalf.
Limits of this analysis
This article does not propose a single data schema for courts, law firms, public authorities, companies and legal-technology providers. Their purposes, powers, risks and legal bases differ. Nor does it claim that every technical log becomes evidence, that every item of evidence must be admissible, or that an audit trail itself guarantees regulatory compliance.
Complete technical reconstruction is not always possible. External providers may change models without exposing a complete version history, clocks in distributed systems may diverge, and non-deterministic processes may produce a different result from similar inputs. The right requirement is therefore not absolute reproducibility but an honestly documented degree of reconstructability: what is known, what was preserved and what can no longer be proved.
The applicable requirements also change over time. Before making a production decision based on the AI Act, the current consolidated text, the classification of the particular system and the applicable dates should be checked again. The same applies to sectoral legislation and special rules on evidence, archiving or professional confidentiality.
Build the audit trail before the dispute
Once a complaint, incident or dispute arises, it is too late to invent the missing history. The final output does not reliably reveal which source was used. An open repository does not prove which version was deployed. A “human-reviewed” label does not reconstruct the review that actually occurred.
A sound audit trail is therefore not a software by-product. It is part of the design of the legal process. It connects a publicly verifiable method with controlled evidence of the particular run and with a clear point of human decision. At the same time, it respects its own limits: integrity is not truth, a record is not an explanation, review is not responsibility, and open source is not the history of an individual matter.
The law does not require one universal trail for every digital process. But wherever a digital step may materially affect rights, obligations or legal strategy, one simple test should apply: a year from now, will we still be able to show what the result came from, what happened to it and who made the decision?
If the answer is no, the process is not truly verifiable. It is merely digital.
Sources
Legal sources
- Regulation (EU) 2016/679 — General Data Protection Regulation, in particular Articles 5, 22, 24, 25, 30, 32 and 35.
- Zakon o varstvu osebnih podatkov (Personal Data Protection Act; ZVOP-2), in particular Article 22. Authoritative Slovenian text; the English title is descriptive.
- Slovenian Information Commissioner, Responsibility for ensuring an audit trail (Slovenian) and Security of personal data (English overview).
- Regulation (EU) 2024/1689 — Artificial Intelligence Act, consolidated English text as at 27 July 2026, in particular Articles 12, 19, 26 and 113.
- Regulation (EU) 2026/1744, in particular Article 1(40), amending Article 113 of the Artificial Intelligence Act.
- Regulation (EU) No 910/2014 — eIDAS, consolidated English text as at 18 October 2024, in particular Articles 35, 41, 45k and 46.
- Zakon o pravdnem postopku (Civil Procedure Act; ZPP), in particular Article 8. Authoritative Slovenian text; the English title is descriptive.
- Supreme Court of the Republic of Slovenia, judgment and order II Ips 187/2011, ECLI:SI:VSRS:2014:II.IPS.187.2011, 20 March 2014, in particular the decision headnote (Slovenian).
- Higher Court in Ljubljana, order I Cp 697/2000, ECLI:SI:VSLJ:2001:I.CP.697.2000, 16 May 2001, in particular the decision headnote (Slovenian).
- Zakon o varstvu dokumentarnega in arhivskega gradiva ter arhivih (Protection of Documents and Archives and Archival Institutions Act; ZVDAGA), in particular Articles 5, 10, 26, 27, 31 and 33.
- Court of Justice of the European Union, Case C-203/22, Dun & Bradstreet Austria, ECLI:EU:C:2025:117, 27 February 2025, in particular paragraphs 58–66 and the operative part.
- Kodeks odvetniške poklicne etike (Slovenian Code of Professional Conduct for Lawyers), in particular Article 51. Authoritative Slovenian text; the English title is descriptive.
Technical sources
- W3C, PROV-DM: The PROV Data Model.
- OWASP, Logging Cheat Sheet.
- OpenTelemetry, Traces and Logs Data Model.
- SLSA, Provenance and Verifying artifacts, version 1.2.
- Open Source Initiative, The Open Source Definition.
- IETF, RFC 9162: Certificate Transparency Version 2.0.
- PyTorch 2.13, Reproducibility, updated 14 May 2026.
Last research verification: 26 August 2026.