The Documents the Law Requires
Some obligations are satisfied by behaving a certain way. Others are satisfied only by producing a specific document.
This chapter covers the second kind, because they are the ones organizations most often discover late.
This chapter covers:
- Why these documents exist
- The instruments you will meet
- What each one is actually for
- Why timing matters more than content
- What goes into them, and who supplies it
- Why one deployment can require several
Why These Exist
Regulators cannot inspect every AI system in operation. What they can do is require you to examine it yourself, in writing, before you deploy it.
That is what these documents are. A structured record that you looked, and what you found.
Two consequences follow, and both matter.
The document is evidence of the thinking, not a substitute for it. A completed assessment that nobody engaged with satisfies nothing.
The absence of one is itself a finding. In several enforcement decisions the failure was not that a system caused harm. It was that the organization had never assessed whether it might.
The Instruments You Will Meet
Four, broadly. The names vary by jurisdiction, and the acronyms overlap in unhelpful ways.
Data Protection Impact Assessment
Where it comes from: General Data Protection Regulation, Article 35. The UK equivalent applies under UK GDPR.
In force since: May 2018 in both the EU and the UK.
What it examines: risk to data and to the people the data is about.
When it is required: before processing likely to result in high risk. Large-scale sensitive data, systematic monitoring, and automated decisions with significant effects are the common triggers.
Commonly abbreviated: DPIA.
Fundamental Rights Impact Assessment
Where it comes from: EU AI Act, Article 27.
Applies from: December 2027.
What it examines: risk to people's fundamental rights — whether the system treats them fairly, whether it creates disadvantage, and whether affected people can meaningfully challenge an outcome.
Who it applies to: the obligation reaches specific deployer categories rather than every deployer of a high-risk system. The categories are defined in the Article, and whether your organization falls inside them is a question for counsel.
Commonly abbreviated: FRIA.
Worth knowing: the official template contemplated by the Act has not been published. Organizations are building the assessment from the Article's own requirements.
State privacy and data protection assessments
Where they come from: US state comprehensive privacy laws. Virginia, Colorado, Connecticut, Texas and others each have their own version.
In force since: 2023 in the earliest states, with more added each year.
What they examine: processing that presents heightened risk to consumers.
When they are required: common triggers include profiling with significant effects, targeted advertising, sale of personal data, and processing of sensitive categories.
A caution on abbreviations. These are variously called data protection assessments, privacy risk assessments, and data privacy impact assessments depending on the state. Read the statute rather than the acronym.
The one that is not an assessment at all
"DPA" is used for both a data protection assessment — a document you produce — and a data processing agreement — a contract you sign with a vendor.
They are unrelated. One is an internal analysis. The other is a bilateral agreement under a different provision entirely.
Write them out in full. This causes real confusion in real organizations, including between people who should know better.
When These Took Effect
This is the part worth pausing on.
Three of the four have been mandatory for years. Only one is still ahead.
| Instrument | Mandatory since |
|---|---|
| Data Protection Impact Assessment — EU | May 2018 |
| Data Protection Impact Assessment — UK | May 2018 |
| Virginia data protection assessment | January 2023 |
| Colorado data protection assessment | July 2023 |
| Connecticut data protection assessment | July 2023 |
| Texas data protection assessment | July 2024 |
| California risk assessment requirements | January 2026 |
| Fundamental Rights Impact Assessment | December 2027 |
A note on the UK date. The obligation did not begin at Brexit. It applied from May 2018 while the UK was an EU member state, and carried over into UK GDPR when the transition period ended in January 2021.
Organizations sometimes assume the UK requirement is newer than it is. It is not.
What that means
If your organization has European exposure, the Data Protection Impact Assessment obligation is eight years old.
If you have consumers in Virginia, Colorado, or Connecticut, the state assessment obligation has been live since 2023.
These are not deadlines to prepare for. They are requirements that already apply.
The Fundamental Rights Impact Assessment is the only one of the four that is genuinely future work — and it is the one attracting most of the attention.
The practical read
An organization focused on the December 2027 date, while carrying an unmet assessment obligation from 2018, has its attention in the wrong place.
Check what is already required before planning for what is coming.
Timing Matters More Than Content
This is the part organizations get wrong most often.
Several of these must exist before the activity begins.
- A Data Protection Impact Assessment is required before high-risk processing starts
- A Fundamental Rights Impact Assessment is required before the system is put into use
An assessment completed after deployment may satisfy the form. It does not satisfy the requirement, and the date on it says so.
What this means practically
The trigger point is procurement or design, not go-live.
By the time a tool is running, the window for a pre-deployment assessment has closed. You cannot reopen it.
Two implications:
- Your assessment process has to connect to whatever approves new tools
- Deployments already running need a different conversation than new ones
For deployments already live
You cannot backdate. You can document honestly.
A defensible position:
- The assessment was completed on this date
- The deployment predated the process
- Here is what we found and what we changed
Not defensible: an assessment with no date, or a date that quietly implies it existed all along.
Chapter 2 covered this. It applies here in the most concrete way.
What Goes Into Them
Every one of these documents has two halves, and they are supplied by different people.
The regulatory half
- Which framework applies and why
- Which provisions are engaged
- What the statute requires the document to address
- How the instrument must be structured
- What the vendor's published practices are
This half requires knowing the law. It requires nothing about your organization.
The organizational half
- What your controls actually are
- How the data actually flows
- What risk mitigations you have chosen
- Who owns the system
- Whether what you have is adequate
This half requires knowing your organization. No one outside it can supply this.
Why the split matters
The two halves fail differently.
Get the regulatory half wrong and the document addresses the wrong requirements. It can look complete and satisfy nothing.
Get the organizational half wrong and the document is inaccurate about your own operations. That is worse, because it is discoverable.
And the sufficiency judgment — whether what you have is adequate — is neither half. That is counsel's.
Why One Deployment Can Require Several
The instruments are not alternatives.
A high-risk deployment in Europe can require a Data Protection Impact Assessment under data protection law and a Fundamental Rights Impact Assessment under AI law. They examine different things.
- One asks what happens to the data
- The other asks what happens to the people
Neither answers the other's question, and completing one does not discharge the other.
And the state assessments multiply by state
A deployment reaching consumers in several states may trigger an assessment obligation in each of them, under each state's own rules.
The arithmetic is the same as Chapter 3. It is not one document per tool. It is a set of documents per deployment, determined by where the people are and what the system does to them.
Where Counsel Comes In
Reasonably yours:
- Identifying which assessments the deployment triggers
- Assembling the factual record
- Completing the organizational half
- Tracking what exists and what does not
Counsel's:
- Whether a contested applicability question is met
- Whether an exclusion applies
- Whether the completed assessment is sufficient
- Sign-off
Escalate early when:
- The applicability question is genuinely close
- The deployment sits in a high-consequence domain
- An exclusion is being relied on that cannot be clearly evidenced
- The assessment surfaces a risk nobody has decided how to handle
That last one is worth watching for. An assessment that identifies a serious risk and records no decision about it is not a finished document.
The Practical Reality
For one deployment, this is manageable. You determine what is required, assemble the record, complete it, and get it reviewed.
Across your AI tool inventory, the arithmetic changes:
- Several deployments per tool
- Several jurisdictions per deployment
- Several instruments per jurisdiction
- Each one dated, each one reviewed
- All of it revisited when the law moves
Organizations rarely fail this because they cannot complete an assessment. They fail because they cannot complete forty of them, keep each one current, and evidence when each was done.
Chapter 7 covers that problem directly.
Use and reuse
Free to use, share, and adapt within your organization. Attribution appreciated, not required. No warranty of any kind — this is practitioner guidance, not legal advice, and sufficiency is determined by your counsel.
LegisGate · Regulatory Intelligence for AI Deployments · legisgate.com
Written by compliance and audit practitioners who spent decades on the other side of the table.
Version 1.0 · Current as of August 2026 · Verify time-sensitive claims against current sources before relying on them.