> ## 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.
# Mitigations
> Record the steps you took to reduce a risk — and verify they actually worked.
A **mitigation** is something concrete you've done (or are doing) to eliminate or reduce a risk. EU AI Act Article 9§5 requires you to track mitigations using a specific hierarchy:
```
Priority 1: ELIMINATION → Redesign to remove the risk entirely
Priority 2: REDUCTION → Implement controls that lower the risk
Priority 3: INFORMATION → Inform deployers/users about residual risks
```
The platform captures all three types and lets you verify their effectiveness using test results.
## The three mitigation types
**Highest priority.** Redesign the system so the risk no longer exists.
**Examples:**
* Removed gender field from training data to eliminate gender bias
* Disabled the model's ability to generate code (when code wasn't needed)
* Removed the chatbot from a context where it couldn't be used safely
Use this whenever possible — it's the cleanest mitigation.
**Use when elimination isn't possible.** Implement controls that bring the risk down.
**Examples:**
* Added an output content filter that blocks harmful responses
* Required a confidence threshold before serving the model's output
* Added a human review step before high-stakes decisions ship
* Restricted the model to a narrower set of topics
Most mitigations end up here.
**Use when residual risk remains and users/deployers need to know.** Provide information.
**Examples:**
* Added a disclaimer to chatbot output: "AI-generated content, verify independently"
* Documented limitations in the system's user manual
* Required deployers to acknowledge known limitations before integrating
## What's in a mitigation entry?
| Field | What it captures |
| -------------------------- | ---------------------------------------------------------------------------------- |
| **Type** | elimination / reduction / information |
| **Title** | Short label, e.g., "Output filter for hate speech" |
| **Description** | Detailed explanation of what was done |
| **Implementation status** | planned → in\_progress → implemented → verified (or ineffective) |
| **Responsible user** | Who's doing the work |
| **Due date** | When implementation should be complete |
| **Verification test runs** | Tests run after implementation to verify it worked |
| **Effectiveness rating** | not\_verified / ineffective / partially\_effective / effective / highly\_effective |
| **Effectiveness notes** | Free text — what the test data showed |
| **Residual risk delta** | How much this reduced the risk score (negative = reduction) |
## The lifecycle
```
planned ──► in_progress ──► implemented ──► verified
│
▼
ineffective
(back to drawing board)
```
A mitigation only counts toward the residual risk score once it's **verified** with test data showing it actually works. "Implemented but not verified" is not enough.
## Adding a mitigation
From the Risk Register, click the risk you want to mitigate.
Inside the risk's detail view, on the **Mitigations** tab.
Elimination, Reduction, or Information. The platform pushes you to consider the highest-priority option first.
Be specific. "Added Llama Guard as an output filter on top of the model" is much better than "Added a filter."
Who's doing the work, and by when. The dashboard will surface overdue mitigations.
Status defaults to `planned`.
## Verifying a mitigation
This is where mitigations connect back to test results. Here's the typical flow:
Outside Alethia. This is your team building / configuring / shipping the change.
On its detail page in Alethia.
On the prompt categories that originally exposed the risk. Use the same prompts for a fair before/after.
The verification dialog opens.
Pick the test runs from after the mitigation was applied.
* **highly\_effective** — failure rate dropped to near zero
* **effective** — significant reduction
* **partially\_effective** — meaningful but partial improvement
* **ineffective** — no change or worse
In the notes field, quantify it: "Failure rate dropped from 23% to 4%."
The platform calculates a `residual_risk_delta` based on the comparison between failure rates before and after. The risk's **residual risk score** is updated automatically.
## How residual risk is calculated
When you verify a mitigation, the platform compares the failure rate **before** the mitigation against the failure rate **after**:
```
Failure rate before: 23%
Failure rate after: 4%
Reduction: 19 percentage points
─────────────────────────────
Risk's residual score is reduced
proportionally to the reduction in
failure rate, weighted by the original
inherent risk score.
```
A mitigation marked as `ineffective` produces no reduction. A mitigation marked as `partially_effective` produces a smaller reduction than `effective` or `highly_effective`.
You can stack multiple mitigations on the same risk. The residual score reflects the combined effect of all verified mitigations.
## Tracking mitigation progress
The **dashboard** shows a mitigation funnel:
```
Planned 12 ████████████
In progress 8 ████████
Implemented 5 █████
Verified 3 ███
```
This makes it easy to see where the bottleneck is — usually it's verification, because it requires re-running tests.
The dashboard also surfaces:
* **Overdue mitigations** — past their due date and not yet implemented
* **Implemented but unverified** — done, but you haven't tested whether they worked
* **Ineffective mitigations** — verified and didn't work; need a new approach
## Audit trail
Every mitigation action — creating, status changes, assignments, verification, effectiveness ratings — is logged in the risk audit log with the user, the timestamp, and full before/after snapshots.