The AI Act and GenAI systems: organising documentation that is useful to a technical team
A useful AI Act file links the use case, the organisation's role, technical decisions, risks, tests, traces and changes. Here is a working method to prepare usable evidence without confusing internal documentation with legal advice.
Documenting a GenAI system for the AI Act is not about producing a legal file after the build. You need to link the use case, the organisation's role, the data, the versions, the controls, the tests, the incidents and the change decisions. A technical team can then show what was designed, what was observed and who approved the changes.
In short
- Start with a scope sheet: real use, people affected, decisions influenced, the organisation's role and connected systems.
- Do not confuse the technical documentation expected for a high-risk system with a deployer's operations file. The two complement each other, without having the same owner.
- Version the elements that change behaviour: model, system prompt, rules, connectors, corpus, tests and access rights.
- Prepare readable evidence: test result, risk decision, minimised execution trace, approval and a link to the version concerned.
IgnitionAI helps technical leaders scope, build and put enterprise GenAI systems into production. This page offers a documentation method. On its own, it cannot legally qualify a system or attest to its compliance.
Why does technical documentation become an architecture topic?
In a GenAI system, behaviour does not depend only on application code. It can also change with a model, a retrieval configuration, a prompt, a connector, an authorisation policy or a dataset. If these elements are not linked, the team cannot explain why an answer, a refusal or an action changed.
For high-risk systems, Regulation (EU) 2024/1689 requires technical documentation drawn up before the system is placed on the market or put into service, and kept up to date. Its Annex IV describes, among other things, elements on the system's purpose, development, data, human oversight, accuracy, robustness, cybersecurity, risk management and life cycle.
This requirement does not mean that every GenAI project falls under the high-risk regime. Qualification depends on the use case, the organisation's role and the applicable framework. The right first question is therefore not "which model are we using?" but "which decision does this system support or produce, for whom and in what context?"
Which scope sheet should you open before the build?
A short scope sheet keeps documentation from becoming an inventory of components without business use. It also triggers the right reviews before a connector or an automation becomes hard to change.
| Element | Question to document | Evidence or owner to link |
|---|---|---|
| Use case | Which task is assisted, recommended or executed? | Description approved by the business owner |
| People affected | Who uses the system or is affected by its effects? | Population, context and limits of use |
| Decision | Does the system inform, recommend or trigger an action? | Expected human decision and refusal cases |
| Organisation's role | Does the organisation provide, deploy, distribute or modify the system? | Role analysis to be validated by the relevant functions |
| Dependencies | Which models, tools, sources and downstream systems are involved? | Register of vendors, connectors and owners |
| Data | Which data comes in, goes out or is searched? | Classification, source of truth and access rules |
For a RAG, add the documents searched, the identities used, the rule that limits retrieval and the expected behaviour when no source is accessible. The guide on access control in a RAG details the choices that must remain verifiable between the source and the answer.
How do you distinguish the provider's file from the deployer's?
The roles defined by the regulation do not automatically map to internal teams. The same organisation can hold several roles depending on what it builds, makes available, modifies or uses. This analysis must be carried out on the concrete case.
For a high-risk system, the technical documentation referred to in Article 11 and Annex IV concerns the system and falls, in particular, under the provider's obligations. For its part, the deployer must, among other things, use the system in accordance with the instructions, organise human oversight where it applies, monitor operation, keep certain logs under its control and report serious incidents under the conditions set by the regulation.
In practice, a technical team can organise two linked spaces:
- The system file. It describes the use case, the architecture, the components, the limits, the risks, the tests and the changes.
- The operations file. It describes access, procedures, supervision, traces, incidents, releases and decisions taken in the field.
This separation avoids a common mistake: asking the team that operates a system to reconstruct on its own the information the provider must supply, or conversely assuming that the provider's instructions describe the deployer's internal permissions, corpus and processes.
Which elements should you version in a GenAI system?
Documentation must let you compare an observed behaviour with a specific configuration. To do so, do not version only the code repository. Set a versioning convention for the elements that change the scope, the accessible data or the expected outputs.
| Element that changes | Reference to keep | Control question |
|---|---|---|
| Model and vendor | Model identifier, parameters and known update date | Which behaviour or limit may change? |
| Prompts and rules | Version of the system prompt and guardrails | Who approved the change and which tests were rerun? |
| RAG corpus | Source, scope, ingestion date and rights rules | Which documents could be retrieved? |
| Connectors and tools | Authorised operations, technical identities and scope limits | Can an action exceed what is planned? |
| Access policy | Source of truth, attributes used and revocation mechanism | What proves that a refusal remains effective? |
| Test set | Cases, expected result, version and observed result | Which gap was accepted, fixed or postponed? |
A version identifier is only useful if it is tied to a decision. When a team changes a model or opens a new connector, it must be able to find the change request, the risk analysis, the tests run, the approval and the rollback plan.
The representative RAG test set offers a structure to keep cases, expected results and gaps. For an agentic system, complete it with the action limits and human approvals suited to each operation.
How do you document risks without creating an abstract register?
A risk register becomes usable when it is tied to a system function, a usage situation, a control measure and a piece of verification evidence. Avoid general entries such as "hallucination" or "data leak" without a precise scenario.
A useful entry can answer these questions:
- which output, decision or action can cause harm;
- under which conditions the deviation can occur;
- which person, data or activity can be affected;
- which control prevents, detects or limits the deviation;
- how this control is tested and who handles the failure;
- which decision was taken on the residual risk.
For example, for a RAG assistant connected to internal documents, a scenario is not just "unauthorised access". It can specify that a passage from a restricted space is retrieved for an identity that does not hold the corresponding rights. The expected evidence can combine a negative test, the access policy applied, the minimised trace of the search and the correction decision.
This approach aligns with NIST's GenAI profile, which invites organisations to document risks and impacts, monitor outputs and track errors or incidents according to their context. It does not replace a legal, security or data protection analysis.
Which traces should be linked to the documentation?
Logs must not become a durable copy of conversations and business data. Their role is to support operations, investigation and the follow-up of controls with a proportionate level of detail.
For a significant execution, link at least:
- a trace identifier and the timestamp;
- the version of the workflow, the model and the rules;
- the authorised identity or role, in minimised form when that is enough;
- the policy or approval decision applied;
- the tool or connector called and the scope of the operation;
- the technical result, the failure or the refusal;
- the reference to the incident, review or change decision if a deviation is detected.
The AI agent traceability method explains how to separate a proposal, a control, an authorisation and an execution. This distinction matters: an action considered by a model is not an executed action.
Which review should you prepare before going to production?
Before opening to users, prepare a short review that examines evidence rather than a document written at the last minute. Participants and criteria depend on the use case, but the review must be able to answer the following questions:
- are the scope and the organisation's role described and submitted to the right validation;
- are the data, access rights, connectors and authorised actions identified;
- are the priority risks linked to observable controls and tests;
- do the people responsible for monitoring, stopping or escalating the system know their role;
- do the traces explain a refusal, an error or an impactful action without overexposing data;
- does the change plan include an owner, tests, an approval and a rollback.
If an answer is missing, the team can reduce the scope: read-only, limited corpus, forbidden operations or opening to a restricted group. This decision is more useful than a general statement of compliance. The go/no-go grid for an LLM prototype can be used to formalise this choice before deployment.
Documentation becomes useful to operations when the team responsible for the system takes it over and tests it. Our guide on handing over a GenAI system to internal teams details the file, the responsibilities and the takeover exercise to prepare before delivery.
FAQ
Is AI Act documentation reserved for high-risk systems?
No. The exact obligations depend on the system's qualification and the organisation's role. Even when a system does not fall under the high-risk regime, documenting scope, versions, risks and decisions helps operate it and check the applicable requirements.
Should you document an external model used through an API?
Yes, at least its role in your system, the available version or reference, its known limits, the integration parameters and the controls your team adds. The vendor's documentation does not automatically describe your corpus, your access rights or your operating rules.
Does a documentation sheet prove AI Act compliance?
No. It is evidence of work and decisions. Compliance depends on the use case, the applicable obligations, the quality of their implementation and the appropriate validations.
When should you update a GenAI system's file?
Update it when a change can alter the use case, the people affected, the data, the rights, the performance, the risks or the operational functioning. The team should define review triggers rather than rely on an abstract annual review.
Methodology and sources
- Regulation (EU) 2024/1689 on artificial intelligence, Official Journal of the European Union, 12 July 2024, consulted on 19 September 2026. References used: Article 11 and Annex IV on the technical documentation of high-risk systems, Article 12 on record-keeping, Article 14 on human oversight, Article 18 on documentation keeping by the provider and Article 26 on certain obligations of deployers.
- European Commission, Navigating the AI Act, consulted on 19 September 2026. The page presents the roles, the risk-based approach and the main requirements applicable to high-risk systems.
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, July 2024, consulted on 19 September 2026. The profile proposes documentation, monitoring and risk management practices to adapt to the context.
This page contains no client results and no estimate of time, cost or compliance. It presents a technical working framework. A system's qualification and the applicable obligations must be assessed in the organisation's real context with the relevant functions.
Do you need to link architecture, risks, tests and operations before opening a GenAI system? Describe your context to IgnitionAI. A first conversation can help frame the decision file, the technical evidence and the responsibilities to clarify.