> ## 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 Classification

> Assign your project to one of the four EU AI Act risk tiers — and unlock the right workflow.

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

<Tabs>
  <Tab title="Prohibited">
    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.
  </Tab>

  <Tab title="High-Risk">
    AI systems in **Annex III** domains, or **safety components** of products covered by Annex I.

    **Annex III domains include:**

    * Biometrics
    * Critical infrastructure (water, gas, electricity)
    * Education and vocational training (admissions, evaluation)
    * Employment, worker management (CV screening, performance evaluation)
    * Essential private and public services (credit scoring, benefits)
    * Law enforcement
    * Migration, asylum, border control
    * Administration of justice and democratic processes

    **In Alethia:**
    The full workflow unlocks: classification, risk register, assessments, mitigations, HITL overrides required, and compliance reports.
  </Tab>

  <Tab title="Limited-Risk">
    AI systems with **transparency obligations** under Article 50.

    **Examples:**

    * Chatbots that interact with humans
    * Deepfake generation
    * Emotion recognition systems
    * Biometric categorization

    **In Alethia:**
    A lighter workflow. The risk register is optional. Tests in transparency-related categories (`authenticity_and_impersonation`, `manipulation_and_deception`) are highlighted.
  </Tab>

  <Tab title="Minimal-Risk">
    Everything else — spam filters, AI in video games, AI-assisted content tagging.

    **In Alethia:**
    No regulatory obligations. The platform still supports voluntary risk management for organizations that want it.
  </Tab>
</Tabs>

## Filling out the classification

<Steps>
  <Step title="Open Risk → Classification">
    Inside your project.
  </Step>

  <Step title="Click 'Create Classification' (or Edit if one exists)">
    Only one classification per project — but you can update it as the deployment context changes.
  </Step>

  <Step title="Pick the risk tier">
    Use the descriptions above. If you're unsure, talk to your compliance team or legal counsel.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Describe the intended purpose">
    Free text. Be specific. *"AI resume screening tool for initial candidate filtering, deployed internally to HR."*
  </Step>

  <Step title="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."*
  </Step>

  <Step title="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."*
  </Step>

  <Step title="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."*
  </Step>

  <Step title="Save as draft">
    The classification is now in `draft` status — visible only to your team.
  </Step>
</Steps>

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

```
   draft  ──►  under_review  ──►  approved
                     │
                     └──────►  requires_update
```

<Steps>
  <Step title="Submit for review">
    Anyone with Tester role can do this.
  </Step>

  <Step title="Team Admin reviews">
    They open the classification, read the justification, and either approve or send it back as `requires_update`.
  </Step>

  <Step title="Approve">
    The classification is locked. Editing it now creates a new version (the old one is preserved in the audit log).
  </Step>
</Steps>

## What unlocks after approval?

| Status                         | What's unlocked                                             |
| ------------------------------ | ----------------------------------------------------------- |
| `draft`                        | Editing the classification                                  |
| `under_review`                 | Read-only                                                   |
| `approved` (high-risk)         | Risk Register, Assessments, Mitigations, Compliance Reports |
| `approved` (limited / minimal) | Light workflow — risk register is available but optional    |

## 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

<AccordionGroup>
  <Accordion title="What if I'm not sure which tier applies?">
    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.
  </Accordion>

  <Accordion title="Can I have multiple risk tiers in one project?">
    No — one project, one classification. If your AI has multiple use cases with different risk profiles, create separate projects for each use case.
  </Accordion>

  <Accordion title="Do I have to classify Minimal-Risk projects?">
    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.
  </Accordion>

  <Accordion title="What if my classification changes mid-deployment?">
    Update the classification. The change is logged. Run a new assessment to capture the change.
  </Accordion>
</AccordionGroup>

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