Every AI system has its own document file. It holds three different things that are often confused: freely created documents, four reserved technical evidence slots with fixed meaning, and the compliance statement as the closing declaration. Keeping those three apart gives you a file that fills the Annex IV dossier almost by itself.

At a glance

Included from: Starter (core feature)
Where in the app: Open an AI system → Documentation
Output: A versioned document file per system, the basis for Annex IV and exports
API: /api/v1/documentation

The three layers of the file

1. Free documents

Any number of entries with title, document type, summary and content. Language (German or English) and status (draft or final) are set per document. Everything that describes the system but has no reserved slot goes here: architecture descriptions, operations manuals, release records.

2. Four technical evidence slots

Bias assessment, data lineage, model update log and risk mitigation measures. Each type exists exactly once per system and ships with a pre-filled outline. These four are what auditors ask for first – which is why they are fixed slots rather than free-text documents.

3. Compliance statement

The closing declaration for the system: scope, your own declaration text, the approver’s name and an explicit confirmation. Saving also writes a snapshot of the underlying facts – so the statement stays traceable even if the system data changes later.

Annex IV dossier

The fourth level for high-risk systems: seven sections with mandatory fields, its own approval workflow and a version number. It has its own documentation page.

The four technical evidence slots

Each slot is pre-filled with an outline that you overwrite. The outline tells you what an auditor expects to find there.

Evidence	Pre-filled outline	Annex IV section
Bias assessment	Scope and protected groups · metrics and thresholds · results and findings · mitigations and owners	Data governance
Data lineage	Data sources and legal basis · transformation steps · storage and retention · access controls and approvals	Data governance
Model update log	Version/tag and release date · change rationale · impact and risk check · approval and rollback plan	Testing and validation
Risk mitigation measures	Control description · linked risks · verification evidence · residual risk and review date	Testing and validation

Evidence metadata per document

On top of the content, every document carries four fields that turn text into a manageable piece of evidence:

Owner role – who maintains the evidence. A role rather than a person, so the evidence survives staff changes.
Due date – by when the evidence has to be refreshed at the latest.
Version – the release the content refers to (for example the model version).
Artifact links – references to the actual files or systems, if the evidence lives elsewhere.

FINAL is an approval, not a formatting switch

A technical evidence entry can only be set to FINAL once its governance workflow is approved. Trying to set the status before that is rejected with an error – deliberately: in an audit, "final" means "approved by the responsible function", not "finished typing".

The documentation assistant

The assistant guides you through up to eleven steps per system. Steps that do not legally apply to the system are not shown at all. Instead, a line above the step bar such as "3 steps do not apply to this system" lists every hidden step with its legal basis. Which steps appear depends on risk level and role:

Situation	Visible steps
High risk, provider	All: system & owners, Annex IV: master data, Annex IV: workflow & approval, measures, assurance, technical evidence, post-market monitoring & incidents, ongoing monitoring & CAPA, ingestion, go-live gate & trust pack, compliance statement & export.
High risk, deployer only	System, measures, assurance, monitoring & incidents (Art. 26(5), Art. 73), ongoing monitoring, go-live gate (Art. 26(1)). Annex IV, technical evidence and the declaration are dropped. These are provider obligations (Art. 10, 11, 15, 16, 47).
Limited or minimal risk	System, measures, assurance.
Prohibited practice	System, measures, assurance. Operating and high-risk steps are dropped because the system must not be operated.
Not assessed yet or role open	System, measures, assurance, with a note that further steps appear once risk level and role are known.

Information

Exception: if a system already holds data for a hidden step (such as a recorded incident), the step stays visible. That way no entries become unreachable. The ingestion step only appears when data sources are connected. Progress counts only the visible steps.

Assurance sections by role and risk

The assurance area also hides what does not apply ("x sections do not apply to your role" or "… to this system"). Without a saved role, nothing is narrowed by role; the app then asks you to set the role.

Section	Applies to
Classification & roles, AI literacy records	Always (Art. 6, Art. 4)
Vendor & supply-chain registry	From limited risk
Human oversight rules, monitoring & observability profiles, authority response cases	High risk, both roles
QMS artifacts, risk register, dataset register, validation suites, pipeline gates, model registry & lineage, release orchestration	High risk, provider (Art. 9, 10, 11, 15, 17, 43(4))
Authority & conformity pack	High risk, provider; public deployers because of registration under Art. 49(3)
Fundamental rights impact assessment	High risk, deployers within the scope of Art. 27(1) (public bodies, providers of public services, Annex III point 5(b)/(c))

Pre-filling "Classification & roles"

What the app already knows, you do not have to type again:

Risk category: always the result of the newest risk assessment. It cannot be edited in the profile; the backend writes it on every save.
Own role: provider or deployer from the newest completed legal logic. Pre-filled but editable, for example for importers, distributors or a deliberate deviation.
System type: GPAI model only if the inventory states that you provide or train the model yourself; otherwise AI system.
Intended purpose and rationale: suggestions from the inventory and from the reasoning of the newest risk assessment, which you adopt with a click.

Recommended order

1Create the system in the inventory and run the risk assessment – only then is the required depth of evidence clear.
2Fill the four technical evidence slots. The pre-filled outline is your checklist.
3Add supporting documents: operations manual, user instructions, release records.
4Obtain governance approval and set the evidence entries to FINAL.
5For high-risk systems: fill the Annex IV dossier, which draws on this evidence.
6Complete the compliance statement and export the system report.

Documentation & evidence