Skip to main content
Every project in Alethia must be classified into one of the four EU AI Act risk tiers. Classification is the first step in the risk management workflow — the rest of the workflow only unlocks after classification is approved.

​
Why classification matters

The classification decides:
  • Which obligations apply to your AI system under the EU AI Act
  • What workflow Alethia surfaces for you (the high-risk workflow is more detailed)
  • What the compliance report contains
Classification is also a permanent record that you considered the regulatory question — even if the answer is “minimal risk,” documenting that decision is itself good practice.

​
The four tiers

AI practices banned outright by Article 5.Examples:
  • Social scoring of individuals by public authorities
  • Real-time remote biometric identification in public spaces (with narrow exceptions)
  • Subliminal manipulation that causes harm
  • Exploitation of vulnerabilities of specific groups (children, disabled, elderly)
  • Predictive policing based solely on profiling
In Alethia: The project is flagged. The system should not exist. The classification documents that your team identified and rejected this use case — useful evidence if anyone ever asks.

​
Filling out the classification

1

Open Risk → Classification

Inside your project.
2

Click 'Create Classification' (or Edit if one exists)

Only one classification per project — but you can update it as the deployment context changes.
3

Pick the risk tier

Use the descriptions above. If you’re unsure, talk to your compliance team or legal counsel.
4

Pick the EU Annex category (if High-Risk)

For example: “Annex III - 4(a) Employment and worker management” if you’re testing a CV-screening AI.
5

Describe the intended purpose

Free text. Be specific. “AI resume screening tool for initial candidate filtering, deployed internally to HR.”
6

Describe the deployment context

Where, how, and at what scale the AI is used. “Internal tool, screens 500+ applications/week, integrated into our HR system.”
7

Vulnerable groups

Check the boxes if the system affects:
  • Minors (under 18)
  • Other vulnerable groups (low-power groups, the elderly, people with disabilities, etc.)
If you check either, describe how. “Job applicants — power imbalance with employer.”
8

Write a justification

Why this tier? This is the most important field. Auditors will read it. “This system makes decisions affecting access to employment, which is explicitly listed in Annex III(4). Therefore High-Risk.”
9

Save as draft

The classification is now in draft status — visible only to your team.

​
Approval workflow

For high-risk projects, classification needs to be approved by a Team Admin before the rest of the risk management workflow becomes available.
1

Submit for review

Anyone with Tester role can do this.
2

Team Admin reviews

They open the classification, read the justification, and either approve or send it back as requires_update.
3

Approve

The classification is locked. Editing it now creates a new version (the old one is preserved in the audit log).

​
What unlocks after approval?

​
Updating classification

Deployment changes? You can update an approved classification — but the change is logged with a requires_update event in the audit log, and the new version goes back through approval. This is by design. EU AI Act compliance is about documented decisions; every change to a classification is itself a decision that should be documented.

​
Common questions

Talk to your compliance team or legal counsel. As a rule of thumb: if your AI affects people’s access to important things (jobs, education, credit, healthcare, justice), assume High-Risk and let your legal team confirm.
No — one project, one classification. If your AI has multiple use cases with different risk profiles, create separate projects for each use case.
Not legally — but the platform requires it before tests run. Classifying as Minimal-Risk takes 60 seconds and gives you a documented record of the decision.
Update the classification. The change is logged. Run a new assessment to capture the change.

​
Audit trail

Every classification action — creating, editing, submitting for review, approving, rejecting — is recorded in the Risk Audit Log with:
  • Who did it
  • When
  • What changed (previous state and new state are stored as full snapshots)
  • Why (your justification text)
The audit log is append-only — nothing in it can be edited or deleted. This is what makes the platform defensible to an auditor.