> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alethiaai.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Risk Assessments
> Link test results to risks, document findings, and track risk evolution over time.
A **risk assessment** is a point-in-time evaluation of a specific risk, backed by actual test execution data. Assessments are how you turn "we identified this risk" into "we measured it, here's the evidence, here's our analysis."
EU AI Act Article 9 requires risk management to be **continuous and iterative** — meaning you don't assess once and walk away. You assess again whenever new information comes in: new test results, a model update, a production incident, or a new mitigation being verified.
## When to create an assessment
| Trigger | Assessment type |
| ------------------------------------------ | -------------------- |
| Right after identifying a new risk | **initial** |
| On a recurring cadence (weekly, monthly) | **periodic** |
| After implementing a mitigation, to verify | **post\_mitigation** |
| Following a real-world incident | **post\_incident** |
| Before deploying a new version | **pre\_deployment** |
You'll typically have **multiple assessments per risk over its lifetime** — that's the whole point.
## What's in an assessment?
| Field | What it captures |
| --------------------------------------- | --------------------------------------------------------------------------- |
| **Type** | One of the five above |
| **Linked test runs** | The specific tests that informed this assessment |
| **Linked categories** | Prompt categories evaluated |
| **Aggregate metrics** | Total tests, safe count, unsafe count, inconclusive count, **failure rate** |
| **Assessor findings** | Your written interpretation of the data |
| **Recommended actions** | What you propose to do next |
| **Updated likelihood / impact / score** | Optional revision of the risk's score based on new evidence |
| **Status** | draft → submitted → approved / rejected |
| **Approved by** | The Team Admin who signed off |
## Creating an assessment
From the **Risk Register**, click the risk you want to assess.
Inside the risk's detail view, on the **Assessments** tab.
Initial, periodic, post-mitigation, post-incident, or pre-deployment.
Two ways:
* **By category** — pick a prompt category and a date range. Alethia auto-links every test in that category from that period.
* **Manually** — pick individual test runs from a list.
Alethia immediately calculates aggregate metrics: total, safe, unsafe, inconclusive, failure rate.
**Required field.** This is your interpretation as the human assessor — the thing only you can write.
Examples of what to include:
* "Failure rate of 18% in `bias_and_fairness` is unchanged from the prior assessment. The pattern of failures is concentrated in age-related questions, suggesting bias toward older candidates."
* "Post-mitigation failure rate dropped from 23% to 4%. The mitigation appears effective. Recommend keeping the rule and re-testing in 90 days."
What should happen next? Examples:
* "Add a model output filter for age-related responses."
* "Re-train the model with a balanced age distribution."
* "Acceptable residual risk — no further action."
If the new evidence changes how you view the risk, you can update the scores. The risk's `inherent_risk_score` doesn't change — but the assessment captures your updated view, and the residual risk score can change if you re-link mitigation evidence.
Drafts are visible only inside the risk. Submit when you're ready for a Team Admin to review.
## Approval
For high-risk projects, assessments need a **Team Admin's approval** before they're considered final. The Team Admin can:
* **Approve** — the assessment is locked; changes require a new assessment
* **Reject** — sends it back as `draft` for revisions
Approved assessments cannot be edited (only superseded by a new assessment). This preserves the audit trail.
## How assessments use test data
When you link test runs to an assessment, Alethia counts each one using its **effective verdict** — the human override if any, otherwise the AI consensus verdict. This means:
* **Failure rate** is calculated on what humans actually decided, not raw AI output
* **Human review work shows up** in your assessments automatically
* The same tests can be linked to multiple assessments (e.g., an initial assessment AND a periodic one a month later)
## Tracking risk evolution
The whole point of multiple assessments is to **see how a risk changes over time**. On the risk's detail page, you'll see a timeline:
```
Initial Assessment Periodic (Q1) Post-Mitigation
2026-01-15 2026-02-15 2026-03-01
Failure rate: 23% Failure rate: 19% Failure rate: 4%
Findings: ... Findings: ... Findings: ...
```
This timeline is exactly what an Article 9 audit asks for: evidence of a continuous, iterative process.
## Linking entire categories at once
For periodic assessments, the most efficient pattern is:
Set up a [recurring scheduled test](/testing/schedules) on the relevant prompt category.
Once a month, create a periodic assessment.
Use **Link by category** with a 30-day date range — every scheduled run from that month is auto-linked.
Write your findings, submit for approval, done.
This turns a tedious monthly compliance ritual into a 10-minute task.
## Audit trail
Every assessment action — creation, edits, linking tests, submission, approval, rejection — is logged with full before/after snapshots in the project's risk audit log.