Skip to main content
Category: Data Subject Rights

Meaningful Information About the Logic

Also known as: Meaningful information about the logic involved, Right to explanation (in the context of automated decision-making)
Simply put

This is the requirement that an organisation using automated decision-making explain, in a way people can understand, how such decisions are reached and what they mean for the individual. Rather than disclosing every technical detail, the aim is generally to give a person enough insight to understand the reasoning and challenge the outcome where appropriate. Commentators and case law have debated how far this obligation extends, so the precise scope can vary by context.

Formal definition

A transparency and access obligation associated with solely automated decision-making, including profiling. Under the GDPR, the information duties and the right of access are framed to require controllers to provide 'meaningful information about the logic involved, as well as the significance and the envisaged consequences' of such processing for the data subject. This obligation appears in the GDPR's information provisions (see Article 13, and correspondingly the equivalent transparency and access provisions, subject to verification against the current text). It is generally understood not to demand disclosure of source code or trade secrets, but rather comprehensible details about the rationale, criteria, and effects of the decision-making. Whether this amounts to a full 'right to explanation' is contested in academic literature (e.g., Selbst and Powles, 2017) and has been the subject of clarification by the CJEU regarding the extent of the required information. The precise boundaries remain subject to evolving guidance and case law, and readers should verify article references and the current position against official sources and regulator guidance (including the UK ICO under the UK GDPR).

Why it matters

Automated decision-making can determine outcomes that significantly affect people's lives, such as access to credit, employment, or services, yet the reasoning behind these decisions is often opaque to the individuals subject to them. The requirement to provide 'meaningful information about the logic involved' addresses this imbalance by obliging controllers to give data subjects enough insight to understand how a decision was reached, what it means for them, and where appropriate, to challenge it. Without this transparency, individuals would struggle to exercise other rights or to contest outcomes they believe to be unfair or inaccurate.

The scope of this obligation is genuinely contested, which makes it a high-stakes area for organisations deploying automated systems, including AI. Academic literature has debated whether the phrase amounts to a full 'right to explanation'; Selbst and Powles (2017) argued that Articles 13-15 do confer such a right, while others have characterised the obligation more narrowly. The Court of Justice of the European Union has since clarified aspects of what controllers must provide, but the precise boundaries continue to evolve. Organisations should therefore treat the extent of the disclosure duty as subject to ongoing guidance rather than settled.

Because the obligation sits at the intersection of transparency, access rights, and automated processing, getting it wrong can expose organisations to complaints and regulatory scrutiny. At the same time, the requirement is generally understood not to compel disclosure of source code or trade secrets, so there is a balance to strike between comprehensibility for the individual and the protection of an organisation's proprietary and commercially sensitive information. Readers should verify the current position, including any divergence between the EU GDPR and the UK GDPR as interpreted by the ICO, against official sources.

Who it's relevant to

Data Protection Officers and Compliance Leads
DPOs and compliance teams must ensure that privacy notices and access request responses adequately convey the logic, significance, and consequences of any solely automated decision-making. Given the contested and evolving scope of the obligation, they should monitor CJEU rulings and regulator guidance and be prepared to adjust their approach, treating the current position as subject to change rather than fixed.
Engineers and Data Scientists Building Automated Systems
Those designing profiling and automated decision-making systems need to build in the capability to generate comprehensible explanations of how decisions are reached. The requirement is generally understood not to demand disclosure of source code, but systems should be able to surface the criteria and rationale in an understandable form so the organisation can meet its transparency and access obligations.
Privacy and Technology Lawyers
Lawyers advising on automated decision-making must navigate genuine uncertainty about how far the obligation extends, including the ongoing debate over whether it amounts to a 'right to explanation'. They should ground advice in the current statutory text, relevant CJEU case law, and applicable regulator guidance, while flagging where interpretation remains unsettled and where the EU and UK positions may diverge.
Individuals Subject to Automated Decisions
Data subjects affected by solely automated decisions, including profiling, are the intended beneficiaries of this obligation. It is designed to give them enough insight to understand the reasoning behind an outcome and, where appropriate, to challenge it, though the precise level of detail they can expect depends on evolving interpretation.

Inside Meaningful Information About the Logic

Nature of the term
"Meaningful information about the logic involved" is language drawn from the GDPR provisions on transparency and data subject access in the context of automated decision-making, including profiling. It appears in the information obligations (generally associated with Articles 13 and 14) and the right of access (generally associated with Article 15), and connects to the safeguards around solely automated decisions (generally associated with Article 22). Readers should verify the precise article references against the current official text.
Logic involved
This refers to an explanation of the rationale, criteria, and general functioning of the automated system or model used to reach a decision, rather than a mere confirmation that automated processing occurs. It typically covers the categories of input data used, the factors weighted, and how those factors generally influence the output.
Meaningful
The qualifier "meaningful" indicates that the explanation must be intelligible and useful to the data subject, enabling them to understand and, where relevant, contest a decision. Regulatory guidance has generally emphasised that this is an accessibility standard rather than a requirement to disclose the full technical complexity of an algorithm.
Significance and envisaged consequences
The relevant provisions typically pair the logic explanation with information about the significance and the envisaged consequences of the processing for the data subject, so that the individual understands the practical impact of the automated processing on them.
Trade secret and IP boundary
The obligation is generally understood, including in guidance and recital-level commentary, not to require disclosure that would adversely affect trade secrets or intellectual property. However, controllers cannot rely on such interests to refuse all information; the balance between transparency and protecting proprietary systems remains subject to assessment and is an area of recognised uncertainty.

Common questions

Answers to the questions practitioners most commonly ask about Meaningful Information About the Logic.

Does providing 'meaningful information about the logic' require disclosing the full algorithm or source code?
Generally, no. The requirement under the GDPR's transparency and access provisions relating to automated decision-making is typically understood to call for information that allows the individual to understand the rationale and main factors behind a decision, not a complete disclosure of the underlying algorithm, source code, or full mathematical model. Guidance from the former Article 29 Working Party (endorsed by the European Data Protection Board) has generally taken the view that the emphasis is on comprehensibility for the data subject rather than technical exhaustiveness. The precise boundary can be contested, may need to be balanced against trade secrets and the rights of others, and can vary with regulator and national law, so this should be assessed case by case and verified against current official guidance.
Is this obligation only triggered by fully automated decisions, or does it apply to any use of algorithms?
The specific duty to provide meaningful information about the logic is most clearly associated with solely automated decision-making producing legal or similarly significant effects, as addressed in the GDPR's provisions on automated individual decision-making. It is not a general obligation attaching to every use of algorithms or every instance of profiling. That said, broader transparency principles and information duties may still require some explanation of processing that involves algorithms even where the automated-decision threshold is not met. Whether a given process crosses that threshold is a matter of assessment, and interpretations of 'solely' automated and 'similarly significant' can differ between regulators, so the reader should verify against current guidance.
What level of detail should typically be included when explaining the logic to a data subject?
In most cases the aim is to convey, in clear and plain language, the categories of data used, the main factors or criteria taken into account, their general role or weight in the outcome, and the envisaged consequences of the processing for the individual. The goal is generally to enable the person to understand and, where relevant, to contest the decision or seek human intervention. The appropriate depth is context-dependent and subject to assessment, balancing intelligibility against the protection of trade secrets and the rights of others.
How can an organisation provide meaningful information for complex or machine-learning models that are difficult to interpret?
Where a model is not readily interpretable, organisations typically focus on explaining inputs, the main relevant factors, and the general logic and purpose rather than the internal mechanics of the model. Approaches may include describing the categories of data considered, illustrative examples of factors that influence outcomes, and the consequences for the individual. Model-explainability techniques may assist, but their sufficiency for legal purposes is a matter of assessment and may attract differing regulator views. There is recognised uncertainty here, and the position may evolve as guidance develops, so the approach should be documented and reviewed.
When should this information be provided, and in what form?
Information about the logic is generally provided at the point of collection or when informing the individual about the processing, and again where an individual exercises access rights in relation to automated decision-making. It is typically expected to be concise, transparent, intelligible, and in clear and plain language, and may be layered so that a short notice links to fuller detail. The exact timing and format depend on the processing context and applicable transparency obligations, and should be assessed against current requirements.
How can an organisation reconcile providing meaningful information with protecting trade secrets or intellectual property?
The obligation is generally understood to be balanced against the protection of trade secrets, intellectual property, and the rights and freedoms of others, so full disclosure of proprietary detail is typically not required. In practice organisations often provide functional, outcome-focused explanations that convey the main factors and consequences without revealing protected technical detail. The precise balance is context-dependent, may be contested, and can vary by jurisdiction and regulator, so it should be assessed case by case, documented, and verified against current guidance and national implementing law.

Common misconceptions

Providing meaningful information about the logic requires disclosing the source code or the full algorithm.
Regulatory guidance has generally indicated that a complex or technical explanation, such as source code, is not required and may not satisfy the "meaningful" standard. What is typically expected is an intelligible account of the general logic, the main factors, and their relevance, presented in a way the data subject can understand. The precise scope remains subject to assessment and evolving guidance.
The obligation applies to every use of automated tools in processing personal data.
The specific transparency obligation regarding the logic involved is generally tied to automated decision-making, including profiling, of the kind described in the relevant provisions (commonly associated with Article 22). Not all use of automation triggers the full obligation, and the applicability depends on whether the processing meets the relevant threshold, which should be assessed case by case.
Trade secret protection lets a controller decline to explain the logic at all.
While protection of trade secrets and intellectual property can limit the level of detail disclosed, it is generally not treated as a basis to refuse any explanation. Controllers are typically expected to find a way to convey meaningful information without necessarily revealing proprietary details. The boundary between the two is an area of divergence and ongoing interpretation.

Best practices

Explain the general logic in plain, intelligible language, focusing on the categories of input data used, the main factors considered, and how those factors generally influence the outcome, rather than defaulting to technical or source-level detail.
Provide the accompanying information on the significance and envisaged consequences of the processing for the individual, so the explanation is practically useful and not purely descriptive.
Assess whether the processing actually falls within the scope of the relevant automated decision-making provisions before determining the extent of the obligation, and document that assessment.
Where trade secret or intellectual property concerns arise, identify a level of explanation that remains meaningful to the data subject rather than withholding information entirely, and record the reasoning for the balance struck.
Verify the current article references and any updated regulatory guidance against the official text and relevant supervisory authority publications, as interpretation in this area continues to evolve.
Align the explanation across the information notices and any access request responses so that data subjects receive consistent information about the logic at each relevant touchpoint.