> ## Documentation Index
> Fetch the complete documentation index at: https://docs.altrum.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How Altrum works

> Understand the six stages of AI governance in Altrum and the pieces that make each one work.

Altrum follows each AI system your organization uses through six stages.

```mermaid theme={null}
flowchart LR
  D[Discover] --> R[Register]
  R --> A[Assess]
  A --> C[Control]
  C --> M[Monitor]
  M --> P[Prove]
```

1. **Discover.** Find AI that is already in use. Model traffic through the AI Gateway that no registered AI system sent shows up in [Discover](/discover.md).
2. **Register.** Add each AI system with an owner and answers to seven risk questions. Altrum works out its [risk rating](/ai-systems/risk-rating.md) and its EU AI Act category.
3. **Assess.** A conversation with Altrum's assistant finds the risks that apply and the controls that answer them. See [Assessments](/assessments/overview.md).
4. **Control.** Guardrails, budgets and model approvals put those controls in place, and someone approves the AI system before it goes live. See [Guardrails](/guardrails/overview.md) and [Lifecycle](/ai-systems/lifecycle.md).
5. **Monitor.** Every request through the AI Gateway is checked. [Reporting](/reports.md), [Alerts](/alerts.md) and [Incidents](/incidents.md) follow what happens.
6. **Prove.** Posture, access reviews, red-team runs, compliance reports and the audit trail show an auditor that it all works.

[Home](/home.md) shows where your organization stands across all six.

## An AI system's life

An **AI system** is anything your organization builds or buys that calls a model: a support assistant, a fraud scorer, a drafting tool. It always sits in one lifecycle stage: **Draft**, **In review**, **Approved**, **Live** or **Retired**. Keys that belong to an AI system work only while it is **Live**, and it gets there only through an approval. Until then, developers keep working on organization or personal keys, which belong to no AI system and are held to your organization's guardrails, budgets and limits. That traffic is what [Discover](/discover.md) finds.

## From assessment to guardrails

An assessment ends with a scope: the risks that apply, the controls that answer them, and the guardrails those controls call for. Submitting it switches those guardrails on in a draft, in **Log only**, and the assistant suggests settings from your answers.

Nothing is enforced until you say so. You review the scope, finish setting up each guardrail, test the draft, and complete the assessment. The draft then becomes the live version. You can also set up guardrails without an assessment at any time.

## From guardrails to traffic

The live version of an AI system's guardrails is what Altrum enforces. Each request an application sends through the AI Gateway is checked before it reaches the model, and each reply is checked before it reaches the application. If a check cannot be made, the request is not sent.

A key attached to an AI system is held to that AI system's guardrails. Any other key is held to your organization's guardrails. See [Guardrails at runtime](/guardrails/at-runtime.md).

## Who does what

Five roles share the work:

* an **Owner** can do everything;
* an **Admin** runs Altrum and the AI Gateway;
* a **Governance Lead** approves AI systems, models and MCP servers, and handles incidents;
* a **Member** registers and runs the AI systems they own;
* an **Auditor** reads the record and changes nothing.

Whatever their role, the owner of an AI system can run its assessment and set up its guardrails. See [Members and roles](/members-and-roles.md).

The words used here, such as risk, control and virtual key, are defined in the [Glossary](/glossary.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.