An AI Risk Assessment Template That Survives a Regulatory Review
Most AI risk assessment templates are a spreadsheet of likelihood-times-impact scores that no regulator would accept as evidence. This walks through the fields an assessment actually needs, mapped to NIST AI RMF MAP and MEASURE and to EU AI Act obligations, and shows why the row a template skips most often is where the AI request produces an identity-bound record of what happened at inference.
A useful AI risk assessment produces one thing a spreadsheet of likelihood-times-impact scores never does: a record a regulator or an auditor will accept as evidence that you evaluated the system before you deployed it. Most templates I see stop at a heat map. The NIST AI Risk Management Framework MAP and MEASURE functions describe a higher bar, and the EU AI Act turns parts of that bar into a legal obligation for high-risk systems.
I want to walk through the fields an AI risk assessment actually needs, why each one exists, and the field most templates skip that decides whether the assessment holds up later.
What the template is for
A risk assessment is a decision record. It states what the system is, who it affects, what can go wrong, what controls reduce that, and who signed off. The value is not the score. The value is that six months later, when a decision the system made is challenged, you can produce the document that shows the risk was identified and a control was in place.
That reframing changes what belongs in the template. A field earns its place if it produces evidence. A field that only produces a color on a chart does not.
The fields that carry weight
Here is the skeleton I use. It maps to NIST AI RMF MAP (context and risk identification) and MEASURE (analysis and tracking).
Sections 1 through 4 are where most templates already operate. Sections 5 and 6 are where they thin out, and that is the part an auditor reads first.
The row most templates skip
The control section usually lists "monitoring" and "access review" and moves on. Those words describe intent, not a record. The row that decides whether an assessment survives review is the per-decision audit record: for each AI request, a signed entry stating the identity behind it, the data classification applied, the policy version in effect, and the outcome.
Without that row, the controls column is a list of promises. With it, every other row in the assessment becomes checkable. You wrote that PII redaction was a control; the audit record shows redaction firing on real requests. You wrote that only a certain role may query a certain model; the record shows the denials. I walked through why application logs cannot fill this row in the Article 12 logging breakdown: a system that writes its own audit log is attesting to itself, and self-attestation fails the traceability test.
Where this sits next to vendor risk
An AI risk assessment covers a system you deploy. It is a different document from a vendor risk assessment, which covers a third party you buy from. Both are needed, and they cross-reference. The AI vendor risk assessment template handles the procurement side: what the vendor attests, what their subprocessors do, whether their AI usage is disclosed. This template handles the deployment side. When a vendor embeds AI in a product you run in a high-risk function, both apply, and the deployment assessment inherits the obligation to produce records the vendor may not give you.
Mapping to the regulation
The template is framework-neutral by design, because the same fields satisfy several regimes. NIST AI RMF MAP and MEASURE supply the structure. EU AI Act Article 9 requires a risk management system for high-risk AI across its lifecycle, and Article 12 requires the automatic, lifetime logging that Section 5 of the template describes. For US deployers, the Colorado AI Act as reenacted by SB 26-189 adds consequential-decision documentation and a three-year retention obligation from January 1, 2027. I keep the mapping current against the NIST AI RMF explainer.
DeepInspect
This is the gap DeepInspect closes on the control side of the assessment. DeepInspect sits at the AI request boundary as a stateless proxy between your users or agents and any LLM. It evaluates each request against identity, data classification, and per-route and per-role policy, and it makes a permit, redact, or deny decision inline before the request reaches the model.
For the template, DeepInspect populates Sections 5 and 6 with evidence rather than intent. Every decision produces a signed, per-decision audit record containing the identity, the policy version, the data sensitivity, the outcome, and a timestamp. That record is the artifact that turns a risk assessment from a document describing controls into a document proving they ran.
If you are building AI risk assessments for high-risk systems and your control section is still a list of promises, let's talk today.
Frequently asked questions
- What should an AI risk assessment template include?
At minimum, six sections: system identity (owner, models, providers, including embedded vendor AI), use-case classification against the EU AI Act and any sector regime, a data profile covering what data classes reach the prompt and how they are retained, risk identification of failure modes and affected populations, controls with the specific enforcement and logging in place, and residual risk with an accountable sign-off. The sections that most often decide an audit are the control and sign-off sections, because they must point to evidence that the stated controls actually operate, not just assert that they exist.
- How does an AI risk assessment map to NIST AI RMF?
The NIST AI Risk Management Framework organizes work into GOVERN, MAP, MEASURE, and MANAGE. A risk assessment template draws mainly on MAP and MEASURE. MAP supplies system context, use-case framing, and risk identification, which correspond to the identity, classification, and failure-mode sections of the template. MEASURE supplies analysis and tracking, which correspond to the controls and residual-risk sections. GOVERN sits above the individual assessment as the policy and accountability structure, and MANAGE covers acting on the assessment over the system lifecycle, including the review cadence the template records.
- Is an AI risk assessment required under the EU AI Act?
For high-risk AI systems, yes. Article 9 of the EU AI Act requires a risk management system that runs across the system's lifecycle, and Article 12 requires automatic event logging over the system's lifetime. A one-time assessment does not satisfy Article 9 on its own, since the obligation is continuous, but a template with a defined review cadence and per-decision records is the practical form the requirement takes. Note that the Digital Omnibus deferred standalone Annex III high-risk obligations to December 2, 2027, which extends the timeline without removing the requirement.
- How is an AI risk assessment different from a vendor risk assessment?
An AI risk assessment evaluates a system you deploy and operate. A vendor risk assessment evaluates a third party you buy from. The AI assessment focuses on data reaching the prompt, the decisions the system makes, and the controls and audit records around them. The vendor assessment focuses on the third party's attestations, subprocessors, and disclosed AI usage. They cross-reference: when a vendor embeds AI in a product you run in a high-risk function, you complete both, and your deployment assessment carries obligations, such as producing decision records, that the vendor may not supply on your behalf.