Skip to main content
When an auditor, regulator, or internal compliance officer asks “show us your AI risk management,” they want structured documentation — not screenshots and emails. Alethia generates this for you. A compliance report bundles the entire state of your project’s risk management into a single structured document, aligned with the documentation requirements of EU AI Act Articles 11 and 18.

​
What’s in the report?

  • When the report was generated, by whom
  • Project name and target model
  • Report version (incremented each time you regenerate)
  • The chosen tier and EU Annex category
  • Intended purpose and deployment context
  • Vulnerable group considerations
  • Justification text
  • Approval record (who approved, when)
  • Total risks
  • Breakdown by status, priority
  • Average inherent and residual risk scores
  • Risk code, title, scores
  • Most recent assessment with failure rate and findings
  • Every mitigation with status and effectiveness
  • Total tests executed
  • Overall safe rate
  • Per-category breakdown
  • Number of human overrides
A pass/fail checklist showing whether the project meets the basic Article 9 criteria. Lets the auditor see in seconds whether you’re in good shape.

​
Generating a report

1

Open Risk → Reports

Inside your project.
2

Click 'Generate Report'

Alethia compiles the data — usually takes a few seconds.
3

Review

The report opens in the viewer. Each section is collapsible.
4

Export

Three options:
  • JSON — for downstream processing
  • PDF — for sharing with auditors and stakeholders
  • Permalink — a URL the recipient can open (with their own Alethia access)

​
When to generate a report

You can generate a report any time, but typical moments are:
  • Before deployment — gate the launch on a clean compliance report
  • At the end of each quarter — keep a regular evidence cadence
  • Ahead of an audit — generate a fresh report just before sharing
  • After a significant change — model update, new mitigation, classification change
Each report is versioned. Older reports stay accessible — they’re proof of what your compliance state looked like at a specific moment in time.

​
What a clean report looks like

A “clean” Article 9 report has these characteristics:
  • ✅ Classification approved with a clear justification
  • ✅ Risk register populated — at least every category that’s been tested has an entry, even if the entry’s conclusion is “low risk, accepted”
  • ✅ Recent assessments — most risks have an assessment within the last 90 days
  • ✅ Mitigations tracked — risks with elevated scores have at least one mitigation, and verified mitigations show effectiveness
  • ✅ Audit trail intact — every change has a user and timestamp
  • ✅ Residual risks decided — for every risk, someone has marked it accepted, transferred, or closed (or it’s actively in mitigation)

​
What a problem report looks like

Things auditors will flag:
  • ❌ Risks with high inherent scores and no mitigation activity
  • ❌ Old assessments (more than 6 months) on risks marked as still active
  • ❌ Mitigations marked implemented but never verified
  • ❌ Many human overrides without documented reasoning
  • ❌ Classification still in draft while testing is happening
The compliance checklist on the dashboard surfaces these issues before you generate the report.

​
Sharing reports

With internal compliance

Use the Permalink option. They’ll need a Viewer role on the team. They can read but not edit.

With external auditors

Export as PDF. The PDF has all the data flattened, with the audit trail attached as an appendix.

​
Keeping reports defensible

A few principles to keep in mind:
Don’t game the report. If you delete uncomfortable risks before generating, the audit log will show those deletions. Better to leave the risk in and document its mitigation honestly.
Generate often. A regular cadence of reports (e.g., monthly) builds a body of evidence that you’ve been doing this all along — much more defensible than one report generated under deadline pressure.
Annotate when needed. The report is structured, but you can add free-text context to assessments and mitigations. Use this to record qualitative information that doesn’t fit in the structured fields.

​
What the report does NOT do

  • ❌ It doesn’t certify your AI as “compliant” — only your compliance team and (where required) a notified body can do that
  • ❌ It doesn’t replace legal review
  • ❌ It doesn’t satisfy domain-specific obligations (medical, financial, etc.) on its own
What it gives you is a defensible, structured starting point for any compliance conversation.

​
Audit log

Generating a report itself is an audit-logged event — including who generated it and what was in scope at the time. This means even the act of producing documentation is documented, which auditors love.