Is the AI impact assessment the same as a Data Protection Impact Assessment?

The two overlap but are not identical. A DPIA under GDPR Article 35 covers any processing of personal data that presents a high risk to the rights and freedoms of natural persons. An AI impact assessment under the EU AI Act covers the AI system regardless of whether personal data is processed. When the AI system processes personal data at scale, the two documents overlap heavily. The deployer can combine them into a single document, provided each regulator's specific questions are addressed. The combination is encouraged by several Data Protection Authorities.

How often does the assessment have to be reviewed?

The EU AI Act does not specify a fixed cadence. The Article 9 risk management system requires the deployer to keep the assessment current across the lifecycle. In practice, that means a quarterly review on stable systems and an event-driven review whenever the system changes materially (model change, training data change, scope change, deployment change). A six-month gap is the longest most regulators will tolerate without a justifying memo.

Who signs the impact assessment?

The signer depends on the deployer's governance. For high-risk systems in regulated sectors, the signer is typically the executive accountable for the use case (CRO for credit, CMO for clinical decision support, CHRO for employment), with a co-sign from the deployer's compliance function. For public-sector deployers, the head of the deploying authority signs.

Does the assessment have to be published?

Generally, no. EU AI Act Article 27(4) requires the deployer to notify the market surveillance authority of the assessment and any update. Public-sector deployers face a stronger publication norm under several Member State transposition rules. The deployer's contract obligations to upstream regulators (Fannie Mae, EBA, FDA) may require disclosure on demand. The assessment is a regulatory artefact, not a marketing document.

How does the assessment interact with the Annex IV technical documentation?

Annex IV technical documentation is the provider's-side artefact characterising the AI system. The impact assessment is the deployer's-side artefact characterising the deployment. The two reference each other. The deployer's impact assessment references the Annex IV documentation for accuracy figures, training data summaries, and resilience claims. The Annex IV documentation references the deployer's intended purpose to scope the conformity assessment.

AI Impact Assessment Template: The Fields a Regulator and an Auditor Both Read

An AI impact assessment is the structured document the deployer produces before placing an AI system into operation, then keeps current across the lifecycle. The format differs across regimes. The fields it has to contain are surprisingly stable. EU AI Act Article 27 lays out a fundamental rights impact assessment for high-risk systems used by certain deployers. GDPR Article 35 lays out the data protection impact assessment (DPIA). Fannie Mae LL-2026-04 lays out the governance documentation a mortgage lender's risk-management function expects. The NIST AI RMF profiles each map back to the same primitives.

I want to walk through the fields a single template has to contain to hold up under any of those reviews, the questions each field answers, and the runtime evidence the deployer needs to keep the assessment honest.

The fields the template has to contain

The template breaks into four sections. Each section maps directly to a regulator's questioning sequence.

System description

| Field | What it captures | |---|---| | System identifier | The internal name and reference used in the AI inventory | | Intended purpose | The specific task and the population the system serves | | Deployer role | Whether the organisation is provider, deployer, importer, or distributor under the EU AI Act | | Classification under EU AI Act | Annex III category, GPAI status, or out-of-scope, with justification | | GPAI provider and model | If the system uses a GPAI model, the provider, model identifier, and Code of Practice signature status | | Geographic scope | The jurisdictions in which the system operates or whose residents it affects |

Data and identity

| Field | What it captures | |---|---| | Data classes processed | PII, PHI, financial NPI, biometric data, special-category data under GDPR | | Lawful basis under GDPR | The Article 6 basis and any Article 9 condition | | Identity context source | How the natural person behind each request is identified at the runtime layer | | Training data summary | The provider's transparency-form data summary for GPAI, or the deployer's training data summary for proprietary models | | Cross-border transfer | Whether processed data crosses jurisdictional boundaries and the safeguards applied |

Risk analysis

| Field | What it captures | |---|---| | Identified risks | The risks to fundamental rights, to data subjects, and to the deployer's organisation | | Severity and likelihood | A consistent rating against the deployer's risk-management framework | | Mitigations | The controls the deployer applies, mapped to each identified risk | | Residual risk | The risk that remains after mitigations | | Acceptable use boundary | The use cases inside the system's documented intended purpose and the use cases outside it |

Operational evidence

| Field | What it captures | |---|---| | Accuracy figure | The figure declared under EU AI Act Article 15 with measurement methodology | | Resilience profile | The adversarial corpus the system was tested against and the failure rate | | Cybersecurity controls | The controls applied at the AI request boundary and the evidence they fire | | Audit log location | The system of record for per-decision audit records and the retention policy | | Human oversight mechanism | The Article 14 mechanism and the role responsible | | Review cadence | The frequency at which the assessment is re-validated against operational evidence |

What each section is actually asked

The fields are static. The questions a regulator asks against each field shift across regimes. The template has to support both.

EU AI Act Article 27 fundamental rights focus

For high-risk systems used by public-sector deployers and certain private deployers (financial services, education, employment), Article 27 expects the deployer to document the categories of natural persons likely to be affected, the specific risks of harm to those persons, the human oversight measures, and the mitigation plan if a risk materialises. The fundamental rights focus is the lens.

GDPR Article 35 DPIA focus

A DPIA looks at processing rather than the AI system as such. It expects the data flows, the necessity and proportionality assessment, the risk to data subjects, and the safeguards. When the AI system processes personal data at scale, the DPIA and the AI impact assessment overlap heavily. The deployer can combine them into a single document, provided each regulator's specific questions are addressed.

Fannie Mae LL-2026-04 supervisory focus

For mortgage lenders, the lender letter expects the inventory, the governance, the audit trail, and the disclosure on demand. The lender's assessment has to identify which AI systems touch loan files, which decisions they influence, and which vendor models the lender depends on. The Government-Sponsored Enterprise has the right to ask on demand and the lender has to produce.

NIST AI RMF profile focus

The NIST AI RMF runs four functions: Govern, Map, Measure, Manage. The Map function corresponds most closely to the impact assessment. A NIST-aligned profile uses the same fields above mapped to the Map function's outputs.

How the runtime architecture keeps the assessment current

An impact assessment that was correct at deployment time and is six months stale at audit time will fail the review. The runtime architecture has to feed evidence back into the assessment continuously.

Identity context flow

The "identity context source" field claims the deployment attaches identity to every request. The runtime architecture has to produce evidence the claim is true. A per-decision audit record showing the verified identity context for sampled requests is the evidence.

Accuracy and resilience evidence

The "accuracy figure" and "resilience profile" fields cite measurements taken at a point in time. The runtime architecture has to re-measure on real traffic at the documented cadence. Without a feed from the runtime, the figures are stale by definition.

Mitigation effectiveness

The "mitigations" field lists the controls the deployer applies. The runtime architecture has to show the controls actually fired. A control that is configured but never triggered is a procurement artefact, not a runtime defence.

Residual risk in production

The "residual risk" field is the deployer's own characterisation. Production telemetry from the AI request boundary tells the deployer whether the characterisation matches reality. Where it does not, the residual risk has to be updated and the mitigations adjusted.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and any LLM. Every request is evaluated against per-route, per-role policies using identity context the application supplies. Prompt content is classified before the request reaches the model.

For the impact assessment, the proxy is the runtime evidence layer the document references. The identity context source claim is supported by the proxy's per-request identity attachment. The mitigation list maps to the proxy's policy configuration. The audit log location is the proxy's per-decision record stream. The accuracy and resilience re-measurements run against the same boundary, on the same traffic the proxy already sees.

The assessment ceases to be a static document and becomes a living artefact backed by production telemetry. When the regulator asks whether the system is operating as the assessment describes, the deployer produces the evidence from the proxy's record stream rather than a screenshot of an internal dashboard.

If you are running AI in a regulated environment and your impact assessment was last updated more than a quarter ago, the regulator will ask why. Book a demo today.