LEGAL AI TRANSPARENCY / PROVENANCE / HUMAN OVERSIGHT

A Result Is Not a Method:Why Visible MethodsMatter in Legal AI

Transparent legal AI requires more than a plausible result or a citation. This article connects the EU Artificial Intelligence Act, the GDPR and CJEU case law with the technical requirements for source traceability, operational provenance, auditability and meaningful human review.

READING KEY

Artificial Intelligence Act
GDPR
Transparency
Human oversight
Provenance
Automated decision-making

A legal AI result is useful only to the extent that its sources, transformations, limitations and path of human review can be inspected. A citation or a label stating that artificial intelligence was used does not show whether the system applied the law relevant in time and subject matter, retrieved the decisive passage, performed its transformations correctly, or left the decision to a person with the competence and authority to reject the result.

In this article, legal AI is a functional umbrella term for systems that assist with legal research, summarisation, classification, drafting or decision-making. It is not a separate statutory category. Legally material result is likewise an analytical term used by the author: it means a result capable of materially affecting legal research, a legal position, a procedural step or a decision, rather than a type of legal act defined by legislation.

The central claim is narrow but demanding. The law does not prescribe one universal log for every system and every use. For legally material work, however, the method should preserve enough external, verifiable information for a competent person to determine what the result rests on, what happened to the material, which boundaries the system did not cross, and who actually accepted, amended or rejected the result.

A result is not a method

A legal answer can be fluent, well structured and even correct without revealing how it was produced. The correctness of one sentence does not show whether the system used the version of the legislation applicable in time and subject matter, accounted for transitional provisions and corrigenda, retrieved the decisive case law, missed an exception or imported a conclusion from another jurisdiction.

The final text is the result. The method includes, at a minimum, the material that entered the system, the boundary of the corpus searched, the retrieval path, the transformations performed, the versions and configuration of the components used, known limitations and human review. If that path disappears, the claim remains but the reliable means of reviewing it later does not.

The same is true of systems that provide citations. A link may direct a reviewer to a webpage, but it does not by itself establish the existence, authenticity, integrity or temporal applicability of a legal source. It may be wrong, unstable or point to an unofficial copy. Legal work therefore ordinarily requires a direct route to an official repository, a stable identifier such as ELI, CELEX or ECLI, the version or date of the text, the relevant passage and the research cut-off date.

Transparency in legal AI is therefore a property of the process, not decoration added to an answer. Its purpose is not to create the impression that we can look inside a model’s “mind”. It is to preserve objects of inspection that exist independently of an explanation generated after the event: the sources used, operations performed, configuration, limitations, measurements and the decision of the responsible person.

What transparency in legal AI means

Transparency is used for several properties that should not be treated as synonyms.

Concept	Core question	What it shows — and what it does not
Disclosure of AI use	Was artificial intelligence used?	Identifies AI’s involvement in producing content; it does not by itself reveal the sources or establish correctness.
Source traceability	Which source, version and passage supports the claim?	Identifies supporting legal authority; it does not establish that the interpretation is correct or the research complete.
Operational provenance	Which activities transformed the input into the result?	Shows the retrieval, processing and generation path; it does not guarantee that every record is true.
Explainability	Which information, criteria or procedures mattered to the result?	Can provide an intelligible account of influential factors; it is not necessarily a faithful technical history of the computation.
Auditability	Can the process be professionally inspected and challenged after the event?	Enables oversight, correction and allocation of responsibility; it does not itself guarantee a correct outcome.

A system may perform well at one layer and poorly at another. It may disclose the use of AI without showing its sources. It may cite sources without preserving the retrieval path. It may generate a comprehensible explanation that is not a faithful record of the factors that produced the result.

The last distinction matters particularly for large language models. In experiments, Turpin and co-authors showed that a natural-language chain of thought can systematically omit the influence of a biased feature in the prompt and rationalise the answer after the event. Their findings do not establish that every model-generated explanation is false. They do show that a displayed chain of thought should not be equated with a system audit trail. See Turpin et al., Language Models Don’t Always Say What They Think, NeurIPS 2023.

For legal verification, the more important question is whether a reviewer can inspect the sources used, operations performed, known limitations and human decision. Those records can be required even where the model’s internal computation cannot be fully explained.

What European Union law actually requires

European Union law does not impose a general rule requiring every output of every legal AI system to contain a complete technical history. The applicable obligations depend on the actor’s role, the intended purpose, the field of use, the type of data, the effect on the individual and the date from which the relevant provision applies.

When legal AI is a high-risk AI system

Under point 8(a) of Annex III to Regulation (EU) 2024/1689 — the Artificial Intelligence Act, high-risk systems may include systems intended to be used by or on behalf of a judicial authority to assist in researching and interpreting facts and the law, applying the law to a concrete set of facts, or being used in a similar way in alternative dispute resolution. The intended purpose, function and user are decisive. The provision does not make every legal-research tool used by a private law firm automatically high-risk.

Nor does inclusion in an Annex III use case complete the assessment. Article 6(3) provides a filtering test: an Annex III system is not considered high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision-making, and at least one of four situations applies:

the system performs a narrow procedural task;
it improves the result of a previously completed human activity;
it detects decision-making patterns or deviations from prior patterns and is not intended to replace or influence a previously completed human assessment without proper human review; or
it performs a preparatory task for an assessment relevant to one of the use cases in Annex III.

If the system profiles natural persons, the final subparagraph of Article 6(3) provides that it is always considered high-risk. A provider that concludes that an Annex III system is not high-risk must document that assessment. Classification is therefore not a marketing label but a concrete legal and functional determination. At the article’s cut-off date, the Commission’s additional explanations were still published as draft guidelines on the classification of high-risk AI systems and could not be treated as a final or binding source.

Logs, transparency and human oversight are not the same obligation

For high-risk AI systems, Article 12 requires technical capability for the automatic recording of events over the system’s lifetime. The logging capability must enable a level of traceability of the system’s functioning appropriate to its intended purpose. This is not a requirement to record every prompt, a model’s entire chain of thought or all data without limitation.

Article 13 requires a sufficiently transparent operation to enable deployers to interpret a system’s output and use it appropriately. The instructions for use must be clear, among other matters, about the intended purpose, performance, limitations, expected accuracy, relevant characteristics of input data, human-oversight measures and logging mechanisms.

Article 14 is principally a design requirement for the provider: the system must be designed with appropriate interfaces and measures that enable effective human oversight during use. Depending on the risk, the person exercising oversight must be able to understand the system’s capabilities and limitations, detect anomalies, guard against automation bias, interpret the output correctly, and disregard, override or reverse it, or stop the system.

Article 26, by contrast, governs the deployer’s conduct. The deployer must assign oversight to natural persons with the necessary competence, training and authority and provide them with the necessary support. The provider’s technical enablement of oversight and the deployer’s organisational duty are not the same thing. A system may contain a stop button, yet oversight will still be ineffective if the user lacks time, knowledge, access to sources or actual authority to reject the result.

Articles 19 and 26(6) add an operational duty to retain automatically generated logs. Providers and deployers must retain those logs, to the extent they are under their control, for a period appropriate to the system’s intended purpose and for at least six months, unless applicable Union or national law provides otherwise, particularly data-protection law. The six-month minimum is not a general licence to retain every input and entire case file indiscriminately. The content of a log, access rights and retention period must still be assessed against purpose, risk and other applicable rules.

These requirements support a traceable system. They do not prescribe the particular record proposed in this article, nor do they require every log to be published.

The right to explanation under Article 86 of the Artificial Intelligence Act

Article 86 is the provision closest to this article’s central claim. Subject to its statutory conditions, an affected person who is subject to a deployer’s decision based on the output of a high-risk AI system listed in Annex III, other than a system under point 2 of that Annex, has a right to a clear and meaningful explanation of the role of the AI system in the decision-making procedure and the main elements of the decision taken. The decision must produce legal effects or similarly significantly affect the person in a way that the person considers to have an adverse impact on their health, safety or fundamental rights.

This is not a general right for every user to obtain source code or the complete internal architecture. Article 86 permits exceptions or restrictions arising from Union law or national law compliant with Union law, and it operates subsidiarily where an equivalent right is not already provided under Union law. The precise conditions are set out in Article 86 of the current consolidated text.

An open legal question. Article 86 sits in Chapter IX, to which the general application date of 2 August 2026 applies. The application of Sections 1 to 3 of Chapter III, including the Article 6(2) classification rule for Annex III systems, has meanwhile been deferred until 2 December 2027. The text therefore raises a question about how Article 86 operates during a transitional period in which Article 86 is formally within its period of application under the general rule in Article 113, while the provisions on which classification of the relevant systems depends are not yet applicable.

At the cut-off date, neither case law nor final official guidance had resolved that relationship. This article therefore claims neither that the right is already fully operational in every case nor that it cannot be invoked before 2 December 2027. It is an open question of how the law in force should be interpreted, and both temporal elements and the limit of the conclusion must remain visible. The transitional operation of Article 86 merits a separate OpenLegalCore analysis; later case law, official guidance or legislative amendment may require this part of the article to be updated.

Article 50: disclosure of AI use is not provenance

Article 50 of the current text of the Artificial Intelligence Act applies from 2 August 2026 to specified systems and content. Among other requirements, it covers informing a natural person that they are interacting directly with an AI system where that fact is not otherwise apparent; marking specified synthetic audio, image, video and text outputs in a machine-readable format; and disclosing deep fakes and certain AI-generated or manipulated text published to inform the public on matters of public interest.

For the final category, an exception applies where the content has undergone human review or editorial control and a natural or legal person bears editorial responsibility for its publication. The provision contains further limitations and exceptions, including for legally authorised law-enforcement uses. Its precise scope must therefore be assessed in context, not merely by asking whether a generative model contributed to the text.

Article 50 demonstrates the difference between disclosure and provenance. A label stating “AI-generated” may satisfy a particular information obligation, but it does not reveal which legal sources were used, which model version ran, how the result was transformed or who checked the material claims.

Temporal application: publication, entry into force and application are different

The Artificial Intelligence Act was published as Regulation (EU) 2024/1689 on 12 July 2024 and entered into force on 1 August 2024, the twentieth day after publication. Its general date of application was set at 2 August 2026, but individual chapters and obligations follow different dates. Regulation (EU) 2026/1744 further changed that timetable: Sections 1 to 3 of Chapter III apply from 2 December 2027 to systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 to product-related systems under Article 6(1) and Annex I.

Article 111 contains specific transitional rules. For high-risk systems placed on the market or put into service before the application date of the relevant part of Chapter III, the Regulation generally applies only if, from that date, those systems are subject to significant changes in their design. Irrespective of that rule, providers and deployers of high-risk systems intended for use by public authorities must take the necessary steps to comply by 2 August 2030. Providers of systems generating synthetic audio, image, video or text content that were placed on the market before 2 August 2026 must take the necessary steps to comply with Article 50(2) by 2 December 2026. Different transitional rules may apply to other groups.

Citations must also distinguish a legal act from a documentation tool. The consolidated text dated 27 July 2026 is useful for research, but EUR-Lex expressly states that it has no legal effect in itself. The authentic texts are those published in the Official Journal. A reliable citation must therefore account for the original Regulation (EU) 2024/1689, the amendment made by Regulation (EU) 2026/1744 and the relevant corrigenda of 9 October 2025 and 19 December 2025. For a concrete matter, asking whether an instrument is “in force” is not enough. The text applicable in time and subject matter to the relevant facts must be identified.

The Artificial Intelligence Act does not displace data-protection law. Article 2(7) expressly preserves the application of the GDPR, Regulation (EU) 2018/1725 and Directive (EU) 2016/680. Where the analysis concerns automated individual decision-making about a natural person, Articles 15 and 22 GDPR are particularly important.

Article 22(1) GDPR is not engaged merely because a system is automated or performs profiling. In its judgment of 7 December 2023 in Case C-634/21, SCHUFA Holding (Scoring), ECLI:EU:C:2023:957, the Court of Justice expressly identified three cumulative conditions:

there must be a decision;
it must be based solely on automated processing, including profiling; and
it must produce legal effects concerning the person or similarly significantly affect that person.

Article 22(2) contains limited exceptions. For some of them, Article 22(3) requires safeguards including the right to obtain human intervention, express a point of view and contest the decision. Article 22 is therefore not a general prohibition of all automation.

In SCHUFA, the Court held that the automated establishment of a probability-based credit score may itself constitute a decision within Article 22 where a third party draws strongly on that score when establishing, implementing or terminating a contractual relationship. The case matters beyond credit scoring: a formally later human step does not necessarily exclude Article 22 if the automated result in practice determines the outcome. This does not mean that every human confirmation is legally irrelevant. The actual influence of the human participant must be assessed in the specific process. See in particular paragraphs 43–50 and 73 of the judgment in C-634/21.

In its judgment of 27 February 2025 in Case C-203/22, Dun & Bradstreet Austria, ECLI:EU:C:2025:117, the First Chamber of the Court clarified the scope of “meaningful information about the logic involved” under Article 15(1)(h) GDPR in the context of automated decision-making within Article 22(1). The controller must describe the procedure and principles actually applied, using relevant information presented in a concise, transparent, intelligible and easily accessible form. The data subject must be able to understand which of their personal data were used and how. Merely disclosing a complex mathematical formula or a detailed description of every technical step is not sufficient. One useful approach may be to explain how a variation in the personal data taken into account would have produced a different result. See in particular paragraphs 55–62 and the operative part of the judgment in C-203/22.

A trade secret or the protection of third-party data does not automatically justify a complete refusal of access. If the controller considers that the requested information contains third-party data or trade secrets, it must submit the allegedly protected information to the competent supervisory authority or court. That authority or court must balance the rights and interests involved and determine the appropriate scope of access. This follows from paragraphs 67–76 and point 2 of the operative part of Dun & Bradstreet Austria.

Both judgments have a defined scope. They do not create a general right for every user of a legal tool to obtain its source code, model parameters or complete internal architecture. Nor is profiling enough without the remaining conditions of Article 22. They do show, however, that where automation has a legally material effect, it must be possible to understand the procedure actually used, the data involved and the role played by the automated result.

The right under Article 15(1)(h) GDPR and the right under Article 86 of the Artificial Intelligence Act should therefore not be collapsed into one:

Legal basis	Core trigger	Substance of the explanation
Articles 15(1)(h) and 22 GDPR	A decision satisfying Article 22 and involving personal data	Meaningful information about the logic involved, its significance and envisaged consequences; after Dun & Bradstreet Austria, an intelligible description of the procedure, principles and use of data.
Article 86 of the Artificial Intelligence Act	A deployer’s decision based on the output of a specified type of Annex III high-risk AI system, with the required adverse effect	A clear and meaningful explanation of the AI system’s role in the decision-making procedure and the main elements of the decision taken.

The two regimes may overlap, but they have different conditions, addressees and temporal questions.

In judicial use, a technical explanation does not replace legal reasons

In judicial decision-making, transparency sits within a binding procedural and fundamental-rights framework. Article 47 of the Charter of Fundamental Rights of the European Union guarantees an effective remedy and a fair hearing before an independent and impartial tribunal previously established by law. Article 6 of the European Convention on Human Rights guarantees a right to a fair trial within its field of application. This article does not derive from those provisions a new, judicially recognised and specific right to disclosure of every technical detail of a generative model. They are, however, binding context requiring the use of a system to preserve judicial authority, the procedural rights of the parties and verifiable reasons for the decision.

The CEPEJ Guidelines on the Use of Generative Artificial Intelligence for Courts, CEPEJ(2025)18Final, adopted in December 2025, are a non-binding professional instrument of the Council of Europe. They recommend documenting information sources, criteria and methods, checking legal references against official databases, ensuring traceability of use and preserving human judicial decision-making. They proceed from the propositions that the exercise of judicial power remains the exclusive responsibility of courts, access to a human judge must be secured, and generative-AI output is not binding.

Two kinds of explanation must be distinguished. A technical explanation describes the operation of the system, the data used or the factors affecting the result. A legal statement of reasons, by contrast, contains the reasons that the competent decision-maker adopts as their own and gives for the particular decision. A model’s chain of thought is not a legal statement of reasons and is not necessarily a faithful technical trace. A verifiable standard combines external provenance, accurate sources, documented operations, measurable tests and legal reasons for which the competent person or institution takes responsibility.

Why a citation is not yet verified legal authority

A legal system that retrieves official sources is ordinarily easier to verify than a model answering solely from learned parameters. Retrieval-augmented generation (RAG), however, does not remove the correctness problem. It divides that problem into a chain in which several links can fail.

The system may select the wrong document, miss the decisive paragraph, return an excessively broad passage, use a text that is in force but not yet applicable, or overlook a rule that remains applicable to past facts. It may miss transitional provisions, a corrigendum or later case law. The model may misstate a genuine passage or derive from a correct rule a conclusion that the source does not support. It may then add a perfectly formatted link that creates the appearance of verification.

In a pre-registered empirical comparison of US commercial legal-research products, Varun Magesh and co-authors found that the tested LexisNexis and Thomson Reuters tools hallucinated in approximately 17 to 33 per cent of queries in their measurement environment. The study’s concept of factual hallucination was broader than an invented citation, and its results cannot be generalised to every tool, jurisdiction or later version. It does, however, refute the absolute claim that a closed legal corpus and RAG by themselves guarantee hallucination-free output. See Magesh et al., Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools, Journal of Empirical Legal Studies 22(2), 2025, pp. 216–242.

Evaluation must also follow the chain. LegalBench-RAG, a 2024 research preprint and public dataset, separates retrieval quality from generation quality. It contains 6,858 expert-annotated query–answer pairs in the reported corpus and evaluates retrieval of precise supporting passages rather than document identifiers or large blocks of text alone. It is a benchmark with its own methodology, not a universal measure of every legal system. Its methodological lesson remains useful: if the system did not retrieve the decisive passage, better prose cannot compensate for the omission.

A material legal claim therefore needs traceable supporting legal authority. A reviewer should be able to determine:

which official or other authoritative source was used;
which stable identifier and version identify it;
which passage supports the claim;
which jurisdiction and hierarchy of authority are relevant;
which text is applicable in time and subject matter;
whether an exception, corrigendum, transitional provision or contrary authority exists; and
what logical relationship connects the passage to the conclusion.

This is not a procedural-law assessment of the admissibility or probative value of evidence used to prove facts. It is verification of legal sources and the quality of legal reasoning.

The verification envelope of a legal result

The practical answer is not an unlimited technical log but a proportionate verification envelope: a structured set of information that supports reconstruction of the legally relevant path of a particular execution. The expression is an analytical and technical term created for this article, not a term used in the Artificial Intelligence Act, the GDPR or procedural legislation.

Layer	What should remain inspectable	What the record does not establish by itself
Execution identity	unique ID, time, purpose, user context, jurisdiction and cut-off date	that the purpose was legally permissible
Source boundary	collections searched, documents, versions, dates, ELI, CELEX, ECLI or other stable identifiers	completeness of every possible legal source
Retrieval	query or its controlled representation, filters, corpus, ranking and decisive passages	that the best source, or every contrary source, was found
Transformations	OCR, normalisation, chunking, deduplication, reranking, translation and applicable rules	that a transformation did not alter meaning
Execution environment	model, provider, version, configuration, tools and prompt-template version	that a later execution will produce the same result
Claims and legal authority	connection between each material claim and a specific source passage	correctness of the legal interpretation
Limitations	warnings, refusals, known deficiencies and areas not reviewed	that no other unknown error exists
Human review	reviewer or role, scope of review, decision, amendments and time	quality of the review without a clear protocol
Integrity and access	checksums, separately protected anchor, signatures or seals, timestamps, access rights, amendments and retention period	origin, authenticity or time of creation if the reference data can also be altered

A checksum or hash value shows only whether the inspected record matches the record from which the reference value was calculated. It does not prove origin, authenticity or time of creation if the reference value can also be replaced without detection. Depending on the risk, additional measures may include a separately protected anchor, an electronic signature or seal, a qualified electronic time stamp under eIDAS, an append-only and tamper-evident log, and an audit of access and changes. No single mechanism replaces substantive verification.

Such a record can be modelled as a provenance graph. The W3C PROV-O Recommendation distinguishes Entity, Activity and Agent: a document or result is an Entity; retrieval, OCR, classification or review are Activities; and a software component, organisation or human may be an Agent where responsibility for an activity or entity is attributed to it. PROV-O provides a neutral language for describing relationships, but does not by itself guarantee the truth, integrity, confidentiality or legal permissibility of the record.

The voluntary NIST Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, published in July 2024, similarly emphasises data provenance and transformations, citation verification, limitations, human feedback loops and monitoring. NIST is not a European legal source, and its profile must not be presented as an obligation under EU law. It is useful as a technical framework for turning a general transparency principle into verifiable procedures.

A verification envelope need not be a single document. It may consist of a user-visible map of claims and sources, a more detailed log for internal review, and a protected record available to a supervisory authority or court. What matters is that the layers refer to the same execution, that the connections between them are protected and that access does not exceed the legally permitted scope.

Human review is a decision, not a signature

The presence of a person in a process does not itself establish human oversight. If that person lacks the time, knowledge, sources or authority to reject the result, their involvement may become merely the final step of automation.

Effective review will ordinarily require:

an understanding of the system’s intended purpose, performance and known limitations;
access to the source documents, not only summaries;
verification of material legal claims and decisive citations;
attention to missing exceptions, contrary authority and temporal applicability;
the ability to require a fresh search or conventional legal research;
sufficient time, support and actual authority to accept, amend or reject the result, or to stop use of the system; and
a record of the scope of review and the changes adopted.

Article 14 of the Artificial Intelligence Act governs what the design of the system must enable. Article 26(2) requires the deployer to assign oversight to persons with the necessary competence, training, authority and support. Article 4 additionally requires measures supporting the development of AI literacy, taking account of knowledge, experience, education and context. Under the current text, that obligation does not require a guarantee that every individual will attain a particular level of AI literacy.

Under Article 22 GDPR, the issue is more specific. The EDPB Guidelines on Automated Individual Decision-Making and Profiling explain that a controller cannot avoid Article 22 through token human involvement. Oversight must be meaningful and performed by a person with the authority and competence to change the decision. SCHUFA adds an assessment of the automated result’s actual weight in the final decision.

The label “human-reviewed” is therefore under-specified. It does not reveal whether the reviewer corrected grammar, opened every source, checked the legal reasoning or examined the entire file. A visible method must distinguish the scope of review, the decision taken and institutional responsibility.

Inspectable does not mean public

A visible method has legal boundaries. Legal documents may contain personal data, special categories of personal data, personal data relating to criminal convictions and offences, trade secrets, material from criminal or family proceedings, internal legal strategy, or information protected by professional secrecy. A log that indiscriminately stores the input, prompt, entire document and model response can create a new repository of high-risk information.

Identify the applicable legal regime first

The GDPR is not the applicable regime for every processing of personal data. The relevant framework depends on the actor and the purpose of processing:

Processing context	Principal regime	Practical consequence for the record
General processing of personal data in the EU	GDPR; in Slovenia, supplemented by Zakon o varstvu osebnih podatkov (ZVOP-2), the Slovenian Personal Data Protection Act — descriptive, unofficial translation	The legal basis, principles, data-subject rights, roles, security, any DPIA and transfers must be assessed.
Processing by competent authorities for the prevention, investigation, detection or prosecution of criminal offences, the execution of criminal penalties and related public-security purposes	Directive (EU) 2016/680, the Law Enforcement Directive; in Slovenia, Zakon o varstvu osebnih podatkov na področju obravnavanja kaznivih dejanj (ZVOPOKD), the Slovenian Act on the Protection of Personal Data in the Field of Criminal Offences — descriptive, unofficial translation	The GDPR is excluded for that purpose; the specialised law-enforcement regime and national rules apply.
Processing of personal data by EU institutions, bodies, offices and agencies	Regulation (EU) 2018/1725	Rights, roles and supervision are assessed under the regulation specific to EU institutions.

The Artificial Intelligence Act does not displace these regimes. Nor does transparency mean that every record must be accessible to everyone. A user may see claims and their sources; a quality-assurance team may see a more detailed operational trace; and a supervisory authority or court may inspect protected information in a legally justified procedure.

Legal basis, sensitive data and the actors’ actual roles

At every layer where personal data are processed, the purpose and legal basis must be identified. Under the GDPR, this requires at least an assessment under Article 6. If special categories of personal data are involved, an appropriate condition under Article 9 must be satisfied in addition to an Article 6 basis. Article 10 governs personal data relating to criminal convictions and offences. The specialised regimes contain parallel but not necessarily identical rules.

The roles of controller and processor are not determined by the label used in a contract. Under Articles 4(7) and 4(8) GDPR, the decisive questions are who actually determines the purposes and essential means of processing, and who processes personal data on that party’s behalf. The Artificial Intelligence Act roles of provider and deployer do not automatically map onto the GDPR roles: the same entity must be assessed separately under each instrument. An external service provider processing data only on a customer’s documented instructions may be a processor and require an arrangement under Article 28. If it uses inputs or prompts for its own purposes, such as its own training or service improvement, its role for that processing may change. The assessment must be factual and purpose-specific; the EDPB Guidelines 07/2020 on the Concepts of Controller and Processor provide relevant guidance.

Before using an external service provider, the organisation should therefore check at least:

whether the service provider may reuse inputs, prompts or results for training or its own purposes;
which sub-processors are involved and where processing takes place;
whether the provider or its personnel access the data from a third country and which mechanism under Chapter V GDPR covers the transfer;
retention periods, deletion, security measures and incident response;
whether the contract and technical design protect professional secrecy, file confidentiality and other legal restrictions; and
whether data-subject rights and requests from a supervisory authority or court can be fulfilled.

Where processing is likely to result in a high risk to the rights and freedoms of natural persons, Article 35 GDPR requires a data protection impact assessment (DPIA). An expressly relevant case is a systematic and extensive evaluation of personal aspects based on automated processing on which decisions producing legal effects or similarly significantly affecting a person are based. Article 26(9) of the Artificial Intelligence Act requires a deployer to use the information supplied by the provider to comply with any applicable DPIA obligation. For specified deployers and uses of high-risk AI systems, the fundamental rights impact assessment (FRIA) under Article 27 of the Act may also be relevant. The Act allows it to incorporate or cross-refer to a DPIA, but the two assessments are not automatically the same document.

Pseudonymisation and hash values do not automatically mean anonymisation

Pseudonymisation, redaction, encryption and separate identifiers are important safeguards. They do not necessarily mean that the information has ceased to be personal data. The GDPR defines pseudonymisation precisely as processing in which the data can still be attributed to a person by using additional information that is kept separately and protected by measures. A hashed identifier may likewise remain personal data if it can be linked to an identifiable person, particularly where it is calculated from a predictable identifier or a linkage table exists. The EDPB accordingly treats anonymisation and pseudonymisation as distinct concepts.

An appropriate system does not record the maximum possible volume of information. It records the minimum that still permits verification of material actions. Personal-data processing remains subject, among other requirements, to the Article 5 principles of purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, to data protection by design and by default under Article 25, and to security under Article 32. For other confidential information, the relevant question is not necessarily a “legal basis for processing” in the GDPR sense. Rules on professional secrecy, confidentiality, trade secrets, procedure and contract may apply instead.

The visible boundary of the method must therefore also show what cannot be disclosed to a particular recipient because of a legal or security restriction, and who may nevertheless conduct an independent review.

A practical verification test for legal AI results

Before a result is used in legal research, a pleading, a draft decision or another legally material task, the responsible user should receive clear answers to the following questions:

Which jurisdiction and cut-off date govern the answer?
Which legal and data-protection regime applies, given the actor, purpose and type of data?
Has the system been classified correctly under the Artificial Intelligence Act in light of its intended purpose and actual effect, including Article 6(3)?
Does every material claim lead to a specific passage, stable identifier and version of the source applicable in time and subject matter?
Is it clear which official collections the system searched and which it did not?
Are material transformations such as OCR, chunking, translation, deduplication and reranking documented?
Are the model, provider, version, configuration, tools and limits of reproducibility known?
Does the system expose uncertainty, failed retrieval, a missing source and possible contrary authority?
Is it clear whether the requested output was a technical explanation of the system, legal reasons adopted by a decision-maker, or both?
Is it clear who reviewed which parts, with what competence and authority, and what they did with the result?
Have the roles of controller, processor, provider and deployer been determined by their actual functions?
Have the legal basis, special categories of personal data, DPIA, sub-processors and third-country transfers been addressed where relevant?
Is the record protected against unauthorised access and undetected changes by measures proportionate to the risk?
Are retention periods aligned with the Artificial Intelligence Act, data-protection law, procedural rules and other applicable obligations?
Can an error be connected to a particular source or step, the affected record corrected, and the change recorded?

A negative answer does not always mean that use of the system is prohibited. It may mean that the task must be narrowed, expert review added, another tool used, or the result treated only as an initial orientation. A tool without a verifiable path may be useful for generating ideas or editing language, but it must not silently acquire the same degree of professional trust as verified legal research.

Limits of the analysis

A visible method does not guarantee a correct result. A log may be incomplete or manipulated, a source misinterpreted, a review superficial and a measurement poorly designed. Transparency makes it possible to detect and attribute errors; it does not eliminate them.

Nor is exact reproduction of a result always possible. Hosted models change, execution may be non-deterministic and a provider may not disclose every internal detail. A realistic objective is forensic reconstructability: a sufficiently precise record of inputs, sources, versions, operations and decisions to understand and professionally inspect a past execution, even if the system does not later generate identical wording. This too is an analytical and technical term used by this article, not a legally defined standard.

Open-source code helps because it permits inspection of the system’s possible behaviour and independent review of its components. It does not by itself show which code version, configuration, data and external models were used in a particular execution. Conversely, a system containing a closed component can preserve a meaningful degree of operational provenance and auditability, although the limits on its internal transparency will be greater.

The extent of the record should be proportionate to the legal effect. A record for proofreading an internal note is not the same as a record for a system assisting judicial decision-making or a decision with significant effects on a person. Proportionality does not mean that a confident answer is enough for a lower-risk task. It means that the depth of documentation, independent review, protection and retention increases with the risk.

Responsibility does not pass to the system

Legal work does not need a system that confidently narrates how it supposedly reasoned. It needs a system that shows what it worked with, what it did, where its limits lie, and when a competent person or institution took over the decision.

Transparency does not remove the responsibility of providers, deployers, controllers, processors, public authorities, organisations or individual professionals. It makes it possible to identify who set the purpose, selected the source, approved the configuration, authorised access, conducted the review, took the decision or ignored a warning.

A result without that path is a claim. A result with a visible method is an object of professional scrutiny. Its reliability is still not self-evident, but it can be tested, bounded, challenged and improved.

Key primary legal sources

Professional and technical sources

Last research verification: 22 August 2026