Skip to main content
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:
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.

​
What’s in a mitigation entry?

​
The lifecycle

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

1

Open the risk

From the Risk Register, click the risk you want to mitigate.
2

Click 'Add Mitigation'

Inside the risk’s detail view, on the Mitigations tab.
3

Pick the type

Elimination, Reduction, or Information. The platform pushes you to consider the highest-priority option first.
4

Title and description

Be specific. “Added Llama Guard as an output filter on top of the model” is much better than “Added a filter.”
5

Assign and set a due date

Who’s doing the work, and by when. The dashboard will surface overdue mitigations.
6

Save

Status defaults to planned.

​
Verifying a mitigation

This is where mitigations connect back to test results. Here’s the typical flow:
1

Implement the mitigation in your system

Outside Alethia. This is your team building / configuring / shipping the change.
2

Update the mitigation status to 'implemented'

On its detail page in Alethia.
3

Run a fresh batch of tests

On the prompt categories that originally exposed the risk. Use the same prompts for a fair before/after.
4

Open the mitigation, click 'Verify'

The verification dialog opens.
5

Link the new test runs

Pick the test runs from after the mitigation was applied.
6

Set effectiveness rating and notes

  • 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%.”
7

Save

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:
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:
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.