Assurance is the deepest layer of system documentation. Where the inventory and risk assessment answer "what is this and how risky is it", assurance answers "what can you prove it with". For that, every AI system has 16 record types – three of them exist exactly once per system, the rest take any number of entries.

At a glance

Included from: Starter (part of the controls feature)
Where in the app: Open an AI system → Assurance
Output: A defensible evidence file per system, including conformity and authority status
API: /api/v1/assurance

The three singleton records

These three exist exactly once per AI system. They are not created but maintained – and they are the first thing opened in an audit.

Classification profile

System type, actor roles (provider, deployer, importer, distributor), risk category, intended purpose, target users, decision impact and deployment context. Plus three yes/no questions with immediate legal consequences: is a GPAI model used? Is this a public sector deployment? Is EU database registration required? The classification rationale is its own field – it is the part auditors read.

Fundamental rights assessment (FRIA)

Affected groups, rights areas touched, misuse scenarios, mitigation measures, residual impact, summary and reviewer. For high-risk systems at certain deployers it is mandatory before first use – and it is not the same as the Art. 35 GDPR DPIA, even though parts can be reused.

Authority pack

Conformity status across five dimensions: conformity assessment, declaration of conformity, CE marking, EU database registration and authority response. Plus whether a notified body is required, the authority contact details, and the list of supporting artifacts. This is the page you open when a market surveillance authority gets in touch.

The registers

These registers take any number of entries per AI system. You do not have to fill all of them – which ones matter depends on risk class and role.

Register	What it holds
Hazard library	A catalogue of possible hazards with code, category, description and default controls. The template from which risk register entries are created.
Risk register	Concrete risks with likelihood, severity, inherent and residual risk, control, owner role, monitoring metric and review date.
Dataset register	Training and test datasets with version, source, legal basis, licence, personal data flag, PII categories, represented groups, quality checks, lineage and bias findings.
Vendor register (system-scoped)	Suppliers for this specific system: role, criticality, contract owner, security assessment status, DPA status and exit plan.
AI literacy records	Training per audience with delivery mode, completion rate, last run, refresh date and evidence link – the Art. 4 evidence for this system.
Human oversight rules	Review mode, whether automatic decisions are allowed, confidence threshold, escalation path and owner role.
Validation suites	Validation type, reference dataset, metric thresholds, revalidation trigger, and whether red teaming and shadow mode are required.
Pipeline gates	Approval points in the delivery pipeline: stage, required checks, approval role, whether the gate blocks, and when it was last evaluated.
Observability profiles	Monitoring type, metric catalogue, alert thresholds, source system, dashboard link and on-call role – the operational side of post-market monitoring.
Model registry entries	Model, dataset and prompt version, registry URI, lineage reference and approval stage. Complements the standalone model registry with system-scoped evidence.
Release orchestration	Links a release to its model registry entry, validation suite and pipeline gate: target environment, deployment status, rollback readiness, change reference and evidence link.
QMS artifacts	Quality management system documents with type, content, owner role, approver, review cycle in days and next review date.
Authority response cases	Individual cases with authorities: type, trigger, external reference, severity, response owner, submission status, deadline and lessons learned.

Status model

Classification, FRIA, dataset register and QMS artifacts share the same four-level maturity model.

Status	Meaning
DRAFT	Being worked on, not yet submitted for review.
REVIEW	Submitted for review.
APPROVED	Approved by the responsible function.
FINAL	Closed and frozen for evidence purposes. The classification profile additionally carries a version number that increments on material changes.

Integration warnings in the response

Assurance entries can carry integration warnings – for example when a release references a validation suite that no longer exists, or when a pipeline gate is never evaluated. These warnings appear in the interface and in the API response; they block nothing, but they show where the file no longer hangs together internally.

Not every system needs everything

For a minimal-risk AI system, the classification profile and a short risk register are enough. The full scope – FRIA, validation suites, pipeline gates, authority pack – is meant for high-risk systems. Trying to fill all 16 registers for every system produces documentation nobody maintains, which hurts rather than helps in an audit.