Welcome back to the NicFab podcast dedicated to legal prompting.
I am Nicola Fabiano and this is the second episode.
In the first episode, I introduced the topic, explained what legal prompting is, and set
out three fundamental premises that will accompany every episode of this series.
Let me briefly remind you.
Language models do not reason like lawyers.
The European regulatory framework imposes precise limits on the use of artificial intelligence
in professional activities.
The choice of model and infrastructure is not a technical decision.
It is a compliance decision.
Today we get into the practical side.
We are going to talk about how to use artificial intelligence to analyze a decision issued
by a data protection authority.
Why start with the supervisory authority's decisions?
Those who work in data protection, lawyers, DPOs, compliance officers, deal with supervisory
authorities' decisions daily.
And I am not talking only about one's own national authority.
A DPO operating in European contexts must engage with decisions from the Italian Garante,
the French CNIL, the UK's ICO, the German BFDI, the Irish, Belgian, and Austrian authorities,
as well as the decisions and guidelines of the EDPB at European level.
These are often lengthy, technically dense documents, with layered regulatory references
written in different languages.
Reading them takes time, understanding them requires expertise, extracting the information
relevant to one specific case requires a method, that is, the most natural use case
for legal prompting.
Not because artificial intelligence can replace the lawyer's reading of the text that must
be said clearly, but because it can accelerate a preliminary phase, orienting oneself within
the document, identifying key points, structuring an initial analysis to be then verified in-depth.
The problem saying analyze this decision is not enough.
The first mistake, and I see it very often, is passing a decision into a chat window and
writing something like analyze this document or tell me what it says.
The result is usually a generic superficial summary that is of no use in a professional context.
Sometimes it is also inaccurate.
Why does this happen?
Because the model has no context.
It does not know who you are.
It does not know why you are reading that decision.
It does not know what you need to extract and it does not know in which regulatory framework
or jurisdiction to place the analysis.
Without precise instructions, it produces a generic output and a generic output in legal
work is a useless output when it is not a dangerous one.
The method building a structured prompt.
Legal prompting applied to decision analysis requires a structured prompt.
Let's see how to build one step by step.
The first element is the rule.
You need to tell the model in which professional capacity you are approaching the text.
That is not a minor detail.
A DPO reads a decision differently from a lawyer defending the data controller who
reads it differently from a consultant assessing the impact on an entire sector.
The role shapes the analysis.
The second element is context.
You need to explain why you are analyzing that decision.
Are you verifying your organization's compliance?
Are you preparing a legal opinion?
Are you assessing whether a particular processing activity is at risk in light of a precedent?
Are you comparing the approaches of two different authorities on the same issues?
Context defines the scope of the analysis and makes the output relevant.
The third element is specific instructions.
What do you want to extract?
The violations identified, the legal basis applied, the corrective measures imposed,
the criteria for calculating the fine, the precedence cited and the interpretation of
a specific GDPR article, the more precise the instruction, the more usable the output.
The fourth element is the output format.
Do you want a discursive analysis, a table with violation, provision and fine, a structured
comparison with another decision, a list of points relevant to a specific impact assessment?
The format must be specified, otherwise the model decides on its own and it rarely chooses
the format most useful to the reader.
A practical example.
Let's take a concrete example.
Suppose a DPO needs to analyze an enforcement decision issued by a supervisory authority
for breach of transparency obligations.
This topic cuts across all European jurisdictions because articles 13 and 14 of the GDPR apply everywhere.
An ineffective prompt would be analyze this decision.
A structured prompt following the legal prompt method would be something like this.
Act as a data protection officer of an organization that processes data on a large scale within
the European context.
I need to assess whether my organization's privacy notices have shortcomings similar
to those identified in this decision.
Analyze the attached decision and extract
1. The specific deficiencies identified by the authority in the privacy notices provided
to data subjects.
2. The provisions breached with precise reference to the relevant GDPR articles.
3. The corrective measures imposed and their respective deadlines.
4. The criteria used to calculate the fine with reference to the relevant GDPR guidelines.
5. Any mitigating or aggravating circumstances recognized by the authority.
Present the result in tabular format with one column for each element.
At the end, add the paragraph on the practical implications for a DPO who needs to verify
the compliance of their own privacy notices.
The difference between the two prompts is enormous and the difference in the output
is equally enormous.
Note something important.
This very same prompt works regardless of which authority issued the decision.
It works with decisions from the Italian Garante, the CNIL and the Spanish Authority.
The method is the same.
The facts change.
The language changes.
But the prompt structure remains valid.
The pitfall.
Even with a well-structured prompt, there are pitfalls to be aware of.
The first is the hallucination of regulatory references.
The model may cite incorrect articles, embed paragraphs that do not exist,
or attribute to a provisioned content that belongs to another.
This risk increases when the decision is in a different language from the prompt,
because the model must perform a double mediation, linguistic and legal.
Every regulatory reference in the output must be verified, always, without exception.
The second pitfall is the loss of argumentative nuance.
Supervisory authorities' decisions have a precise structure.
There is a substantial difference between a fact reported in the investigation's reconstruction,
an argument put forward in the controller's defense,
and a conclusion reached by the authority.
The model may conflate these levels,
attributing to the authority a position that was in fact the party's.
In a professional context, this is a serious error.
The third pitfall concerns precedence and cross-references.
If the model cites previous decisions or ADPB guidelines,
those references must be verified.
They may not exist, or they may exist but say something different from what the model reports.
I have seen models embed decision reference numbers,
attribute to ADPB guidelines content that was never expressed,
and confuse Article 29 Working Party opinions with the ADPB opinions.
These errors in a legal opinion or a board report can have serious consequences.
The three premises are applied.
Let's return to the three premises from the first episode and see how they apply to this use case.
Human oversight.
The analysis output is not the final product.
It's a starting point.
The DPO, the lawyer, and the consultant must read the original decision,
compare the model's analysis, verify every reference,
and integrate it with their own expertise and contextual knowledge.
Artificial intelligence does not replace the lawyer.
It accelerates a phase of the work, but responsibility remains entirely human.
Regulatory framework.
The decision behind analyzed may contain personal data of the parties involved.
Passing that text into a cloud-based model without having verified the provider's terms of service.
The safeguards for international data transfer and the existence of an adequate data processing agreement
that is a compliance issue.
These may also apply when the decision is made public,
because if it still contains identifiable personal data,
the legal or institutional publication of the document does not automatically permit
any subsequent reuse of such data.
Any use of the text in a cloud-based model still requires
an independent assessment of the legal basis, purpose, necessity, data minimization,
the provider's role, and safeguards regarding data transfers.
Choice of model and infrastructure.
When analyzing decisions that contain confidential information,
I am thinking of decisions not yet published,
drafts, documents exchanged in the course of ongoing proceedings.
A local model may be the most appropriate choice from a data protection perspective.
It is not always necessary, but the question must be asked beforehand, not afterwards.
Analyzing a data protection authority's decision with artificial intelligence
is not about copying and pasting a text and waiting for an answer.
It is a process that requires method,
precision in instructions, and rigorous verification of the output.
Legal prompting is exactly about this,
transforming an approximate use of the tool into a professional and informed one.
Indeed, in the next episode, we will discuss another concrete use case,
drafting privacy notices with the assistance of artificial intelligence.
We will look at how to structure prompts, which mistakes to avoid,
and why a privacy notice generated without supervision can create more problems that it solves.
If you want to learn more, visit my blog.
nicfab.eu
You will find an article on legal prompting, with references and useful links.
And every Tuesday, in the NicFab newsletter,
you will find the legal prompting column also in written format.
Subscribe to the newsletter at nicfab.eu
Thank you for listening. See you in the next episode.