Legal Prompting - Analyzing Supervisory Authorities' Decisions
S01:E02

Legal Prompting - Analyzing Supervisory Authorities' Decisions

Episode description

Second episode of the Legal Prompting series.

How to use artificial intelligence to analyze a supervisory authority’s decision on data protection: why “analyze this document” is not enough, how to build a structured prompt (role, context, specific instructions, output format), the traps to watch for — normative hallucinations, loss of argumentative nuances, fabricated cross-references — and the compliance implications of using cloud-based models.

Read the column in the newsletter → nicfab.eu

Download transcript (.srt)
0:10

Welcome back to the NicFab podcast dedicated to legal prompting.

0:14

I am Nicola Fabiano and this is the second episode.

0:19

In the first episode, I introduced the topic, explained what legal prompting is, and set

0:26

out three fundamental premises that will accompany every episode of this series.

0:32

Let me briefly remind you.

0:35

Language models do not reason like lawyers.

0:39

The European regulatory framework imposes precise limits on the use of artificial intelligence

0:45

in professional activities.

0:48

The choice of model and infrastructure is not a technical decision.

0:54

It is a compliance decision.

0:56

Today we get into the practical side.

0:59

We are going to talk about how to use artificial intelligence to analyze a decision issued

1:06

by a data protection authority.

1:09

Why start with the supervisory authority's decisions?

1:14

Those who work in data protection, lawyers, DPOs, compliance officers, deal with supervisory

1:22

authorities' decisions daily.

1:26

And I am not talking only about one's own national authority.

1:32

A DPO operating in European contexts must engage with decisions from the Italian Garante,

1:39

the French CNIL, the UK's ICO, the German BFDI, the Irish, Belgian, and Austrian authorities,

1:48

as well as the decisions and guidelines of the EDPB at European level.

1:55

These are often lengthy, technically dense documents, with layered regulatory references

2:03

written in different languages.

2:06

Reading them takes time, understanding them requires expertise, extracting the information

2:13

relevant to one specific case requires a method, that is, the most natural use case

2:21

for legal prompting.

2:23

Not because artificial intelligence can replace the lawyer's reading of the text that must

2:29

be said clearly, but because it can accelerate a preliminary phase, orienting oneself within

2:36

the document, identifying key points, structuring an initial analysis to be then verified in-depth.

2:47

The problem saying analyze this decision is not enough.

2:52

The first mistake, and I see it very often, is passing a decision into a chat window and

2:59

writing something like analyze this document or tell me what it says.

3:06

The result is usually a generic superficial summary that is of no use in a professional context.

3:15

Sometimes it is also inaccurate.

3:19

Why does this happen?

3:22

Because the model has no context.

3:26

It does not know who you are.

3:29

It does not know why you are reading that decision.

3:34

It does not know what you need to extract and it does not know in which regulatory framework

3:43

or jurisdiction to place the analysis.

3:47

Without precise instructions, it produces a generic output and a generic output in legal

3:55

work is a useless output when it is not a dangerous one.

4:02

The method building a structured prompt.

4:06

Legal prompting applied to decision analysis requires a structured prompt.

4:13

Let's see how to build one step by step.

4:17

The first element is the rule.

4:20

You need to tell the model in which professional capacity you are approaching the text.

4:26

That is not a minor detail.

4:29

A DPO reads a decision differently from a lawyer defending the data controller who

4:36

reads it differently from a consultant assessing the impact on an entire sector.

4:44

The role shapes the analysis.

4:47

The second element is context.

4:50

You need to explain why you are analyzing that decision.

4:56

Are you verifying your organization's compliance?

5:00

Are you preparing a legal opinion?

5:04

Are you assessing whether a particular processing activity is at risk in light of a precedent?

5:12

Are you comparing the approaches of two different authorities on the same issues?

5:20

Context defines the scope of the analysis and makes the output relevant.

5:27

The third element is specific instructions.

5:31

What do you want to extract?

5:33

The violations identified, the legal basis applied, the corrective measures imposed,

5:40

the criteria for calculating the fine, the precedence cited and the interpretation of

5:49

a specific GDPR article, the more precise the instruction, the more usable the output.

5:57

The fourth element is the output format.

6:01

Do you want a discursive analysis, a table with violation, provision and fine, a structured

6:09

comparison with another decision, a list of points relevant to a specific impact assessment?

6:17

The format must be specified, otherwise the model decides on its own and it rarely chooses

6:26

the format most useful to the reader.

6:29

A practical example.

6:32

Let's take a concrete example.

6:35

Suppose a DPO needs to analyze an enforcement decision issued by a supervisory authority

6:43

for breach of transparency obligations.

6:48

This topic cuts across all European jurisdictions because articles 13 and 14 of the GDPR apply everywhere.

7:00

An ineffective prompt would be analyze this decision.

7:06

A structured prompt following the legal prompt method would be something like this.

7:13

Act as a data protection officer of an organization that processes data on a large scale within

7:23

the European context.

7:26

I need to assess whether my organization's privacy notices have shortcomings similar

7:33

to those identified in this decision.

7:38

Analyze the attached decision and extract

7:41

1. The specific deficiencies identified by the authority in the privacy notices provided

7:49

to data subjects.

7:51

2. The provisions breached with precise reference to the relevant GDPR articles.

8:01

3. The corrective measures imposed and their respective deadlines.

8:08

4. The criteria used to calculate the fine with reference to the relevant GDPR guidelines.

8:16

5. Any mitigating or aggravating circumstances recognized by the authority.

8:26

Present the result in tabular format with one column for each element.

8:33

At the end, add the paragraph on the practical implications for a DPO who needs to verify

8:40

the compliance of their own privacy notices.

8:44

The difference between the two prompts is enormous and the difference in the output

8:51

is equally enormous.

8:54

Note something important.

8:57

This very same prompt works regardless of which authority issued the decision.

9:04

It works with decisions from the Italian Garante, the CNIL and the Spanish Authority.

9:12

The method is the same.

9:14

The facts change.

9:16

The language changes.

9:19

But the prompt structure remains valid.

9:23

The pitfall.

9:25

Even with a well-structured prompt, there are pitfalls to be aware of.

9:31

The first is the hallucination of regulatory references.

9:38

The model may cite incorrect articles, embed paragraphs that do not exist,

9:46

or attribute to a provisioned content that belongs to another.

9:52

This risk increases when the decision is in a different language from the prompt,

9:59

because the model must perform a double mediation, linguistic and legal.

10:05

Every regulatory reference in the output must be verified, always, without exception.

10:15

The second pitfall is the loss of argumentative nuance.

10:21

Supervisory authorities' decisions have a precise structure.

10:27

There is a substantial difference between a fact reported in the investigation's reconstruction,

10:36

an argument put forward in the controller's defense,

10:41

and a conclusion reached by the authority.

10:45

The model may conflate these levels,

10:49

attributing to the authority a position that was in fact the party's.

10:57

In a professional context, this is a serious error.

11:03

The third pitfall concerns precedence and cross-references.

11:09

If the model cites previous decisions or ADPB guidelines,

11:14

those references must be verified.

11:18

They may not exist, or they may exist but say something different from what the model reports.

11:28

I have seen models embed decision reference numbers,

11:34

attribute to ADPB guidelines content that was never expressed,

11:40

and confuse Article 29 Working Party opinions with the ADPB opinions.

11:47

These errors in a legal opinion or a board report can have serious consequences.

11:56

The three premises are applied.

12:00

Let's return to the three premises from the first episode and see how they apply to this use case.

12:09

Human oversight.

12:12

The analysis output is not the final product.

12:16

It's a starting point.

12:20

The DPO, the lawyer, and the consultant must read the original decision,

12:26

compare the model's analysis, verify every reference,

12:31

and integrate it with their own expertise and contextual knowledge.

12:38

Artificial intelligence does not replace the lawyer.

12:41

It accelerates a phase of the work, but responsibility remains entirely human.

12:52

Regulatory framework.

12:54

The decision behind analyzed may contain personal data of the parties involved.

13:02

Passing that text into a cloud-based model without having verified the provider's terms of service.

13:10

The safeguards for international data transfer and the existence of an adequate data processing agreement

13:19

that is a compliance issue.

13:23

These may also apply when the decision is made public,

13:28

because if it still contains identifiable personal data,

13:33

the legal or institutional publication of the document does not automatically permit

13:40

any subsequent reuse of such data.

13:44

Any use of the text in a cloud-based model still requires

13:49

an independent assessment of the legal basis, purpose, necessity, data minimization,

13:58

the provider's role, and safeguards regarding data transfers.

14:02

Choice of model and infrastructure.

14:07

When analyzing decisions that contain confidential information,

14:13

I am thinking of decisions not yet published,

14:18

drafts, documents exchanged in the course of ongoing proceedings.

14:24

A local model may be the most appropriate choice from a data protection perspective.

14:30

It is not always necessary, but the question must be asked beforehand, not afterwards.

14:41

Analyzing a data protection authority's decision with artificial intelligence

14:46

is not about copying and pasting a text and waiting for an answer.

14:52

It is a process that requires method,

14:57

precision in instructions, and rigorous verification of the output.

15:04

Legal prompting is exactly about this,

15:09

transforming an approximate use of the tool into a professional and informed one.

15:17

Indeed, in the next episode, we will discuss another concrete use case,

15:23

drafting privacy notices with the assistance of artificial intelligence.

15:31

We will look at how to structure prompts, which mistakes to avoid,

15:38

and why a privacy notice generated without supervision can create more problems that it solves.

15:47

If you want to learn more, visit my blog.

15:53

nicfab.eu

15:55

You will find an article on legal prompting, with references and useful links.

16:03

And every Tuesday, in the NicFab newsletter,

16:06

you will find the legal prompting column also in written format.

16:13

Subscribe to the newsletter at nicfab.eu

16:16

Thank you for listening. See you in the next episode.