AI technical file: what it is, what it must include and how to prepare it before it becomes mandatory

The AI Act requires every high-risk AI system to have a complete technical file. We explain the 16 sections it must include, how it connects to the FRIA and the DPIA, and a practical strategy for starting to document your systems today

When people talk about the AI Act, the conversation usually focuses on risk classification or penalties. But there is a less visible obligation that will demand a huge operational effort from companies: the technical file.

The technical file is the complete documentation for an AI system. It is not an executive summary or a product sheet. It is an exhaustive dossier describing what the system does, how it works, which data it uses, how it is evaluated, who supervises it, how it is secured and what happens when it fails. For high-risk systems, keeping this file up to date is not a best practice: it is a legal obligation.

The problem is that most companies do not document their AI systems at this level of detail. They have code in repositories, models in production, scattered configurations and knowledge distributed across their engineers’ heads. Turning all that into a structured technical file takes time, process and a clear template.

In this article we explain what the technical file is, why the AI Act requires it, which sections it must include and how to start building it even if your systems are already in production.

What the technical file is and why you need it

The technical file is the central document in an AI system’s compliance documentation. The AI Act requires it for all high-risk systems (for providers and deployers alike), and it must be available to supervisory authorities if they request it.

Its purpose is threefold:

• Traceability: It makes it possible to reconstruct how the system works, which data it was trained or configured with, which metrics are used to evaluate it and who makes deployment decisions.
• Accountability: It documents technical and organizational decisions: why that model was chosen, why those thresholds were set and who approved the move to production.
• Operational continuity: If the person responsible for the system changes role or company, the file allows anyone with the right profile to understand, maintain and audit the system.

The technical file is not paperwork. It is the institutional memory of your AI system.

The 16 sections of the technical file

Based on the requirements of the AI Act and best practices in AI governance, a complete technical file includes the following sections:

Block 1: Identification and context (sections 0–2)

1. Cover page and metadata. System name, version, date, product owner, deployment owner, provider, DPO and CISO. System status (design, pilot, production or retired). Applicable regulations: GDPR, AI Act, DSA, DMA and NIS2.
2. Purpose and limits. System purpose, supported processes, included and excluded populations and channels, and abstention assumptions. Intended use according to the provider’s instructions. Substantial changes that require reassessment.
3. AI Act classification and role. Organization’s role (provider, deployer, importer or distributor). System classification (prohibited, high risk under Annex III, embedded high risk under Annex I, limited or minimal). Required assessments: DPIA yes/no, FRIA yes/no.

Block 2: Architecture and data (sections 3–5)

1. Architecture and environments. End-to-end system diagram. Description of components, external dependencies and control points. Endpoints by environment (development, staging and production). Degraded mode and continuity: RTO, RPO and test evidence.
2. Data and governance. Dataset inventory: origin, whether it contains personal or sensitive data, legal basis for processing, representativeness, retention, transfers and data owner. Links to DPIAs and data processing agreements (DPAs).
3. System method and configuration. Technique used (supervised model, RAG, agent, etc.), provider, model ID/version, key parameters, guardrails and policies. For RAG systems: top-k, reranking, context windows and prompt templates.

Block 3: Evaluation and supervision (sections 6–8)

1. Evaluation, metrics and thresholds. Metrics with formula, evaluation dataset, target, threshold and operational trigger (review or rollback). Evaluation frequency and owner. This is the technical heart of the file.
2. Human oversight. Control points where a human intervenes. For each point: activation condition, human action, authority level, evidence generated and SLA.
3. Logging and traceability. What is recorded in each interaction: input, context, cited passages (if RAG), output, scores, decision and user/agent. Log retention, access and location.

Block 4: Security and transparency (sections 9–10)

1. Security and continuity (NIS2/DR-BCP). Security controls with evidence, frequency, owner and status. RTO, RPO, recovery test results and degraded mode.
2. Transparency and user information. AI notice text, detectability of synthetic content and explanatory pages. Screenshots and versions of notices.

Block 5: Risks and changes (sections 11–14)

1. Risks and safeguards (FRIA/DPIA summary). Summary of risks identified in the FRIA and DPIA: risk, affected right, severity × probability, measures, residual risk and evidence.
2. Change management. Changelog for every relevant modification: ID, date, change subject, expected impact, test evidence and decision.
3. Roles and responsibilities (RACI). RACI matrix for critical activities: DPIA/FRIA, metrics, logging, security, transparency, changelog and deployment.
4. Incidents and post-market monitoring. Incident register with date, description, severity, corrective action and closure. Links to post-mortems.

Block 6: Closing (sections 15–16)

1. Appendices and links. Inventory of linked documents: metrics, checklists, RAG evidence, changelog, incident runbook, DPA, DPIA and FRIA.
2. Approvals. Signatures from the product owner, data owner/ML, legal/DPO, security/CISO and management. Approval date and review trigger.

Key point: The file must be completed before Gate 2 (the AI governance system’s pre-deployment gate). It must be updated after substantial changes or once the post-go-live stabilization window has ended.

Example: what the file for a customer-service RAG chatbot would include

To make this tangible, let’s see how the file would apply to a customer-service RAG chatbot in an ecommerce business. This system uses generative AI to answer customer questions about orders, returns and products, based on an internal knowledge base.

• Classification: Limited risk (it is not in Annex III, but it interacts directly with consumers). Transparency is required: the user must know they are talking to an AI.
• Architecture: Indexed knowledge base (policy documents, FAQs and product catalog) → vector search (top-k=5) → reranking → LLM with a system prompt that includes grounding instructions → response to the user.
• Key metrics: Faithfulness (fidelity to context) ≥ 90%, hallucination rate < 5%, user satisfaction (CSAT) ≥ 4.0/5 and human-agent escalation rate < 15%.
• Human oversight: Automatic escalation when the chatbot detects formal complaint intent, a refund request above €200 or three consecutive questions without a satisfactory answer.
• Transparency: Visible banner: “This assistant uses artificial intelligence. To speak with an agent, type AGENT.” Synthetic-content detectability if images or summaries are generated.
• Security: Periodic prompt-injection testing, guardrails against generating information on topics unrelated to the business, and personal-data filtering in logs.

Even if this system is not high risk, documenting it with a technical file is a good practice that makes maintenance and internal auditing easier and demonstrates due diligence if a problem arises.

The mistakes we see most often when documenting AI systems

• Retrospective documentation: The system has been in production for months and nobody has documented anything. Reconstructing the file from scratch is possible, but expensive in time and effort.
• Static documentation: The file is created once and never updated. An outdated file is worse than having none, because it creates a false sense of compliance.
• Focusing only on the model: The file is not just the AI model’s profile. It includes data, security, human oversight, transparency, incidents and organizational governance.
• No metrics or thresholds: A file without measurable metrics is a descriptive document, not a control instrument. You need to know when the system is working well and when it is not.
• Disconnected from the FRIA: The technical file and the FRIA must be linked. The risks identified in the FRIA must be reflected in section 11 of the file together with their safeguards.

A practical strategy: how to start without bringing work to a halt

You do not need to document everything at once. The most effective strategy is progressive:

1. Weeks 1–2: Inventory. List every AI system in use or under development. For each one, identify its name, owner, status (design/pilot/production) and preliminary AI Act classification.
2. Weeks 3–4: Prioritization. Classify each system under the AI Act. High-risk systems (Annex III) need a complete file. Limited-risk systems need proportional documentation.
3. Month 2: Cover page + Classification + Architecture. Complete sections 0–3 for the prioritized systems. They are the easiest because the information already exists; it only needs to be structured.
4. Month 3: Data + Method + Metrics. Complete sections 4–6. This is the technically dense part: it requires coordination with data and engineering teams.
5. Month 4: Oversight + Security + Transparency. Sections 7–10. This is where operations, security and legal teams come in.
6. Month 5: Risks + Governance + Approvals. Sections 11–16. Link them to the FRIA and DPIA, establish the RACI and obtain approvals.

If you start today at this pace, you will have complete files for your critical systems in five months. That gives you some margin before August 2026.

The file within the AI governance framework

The technical file does not live in isolation. In the 5 Pillars of AI Transformation model, it is a central piece of the Compliance Pillar and connects to the entire governance ecosystem:

• Gates (control gates): The file starts at Gate 1 (project approval) and must be complete for Gate 2 (pre-deployment). At Gate 3 (post-deployment), its currency is checked.
• FRIA and DPIA: The file incorporates them in section 11 and references them in the appendices. It does not replace them: it complements them with the technical dimension.
• AI Steering Committee: The AI committee reviews the file as part of the GO/FIX/KILL decision. An incomplete file is an argument for FIX.
• AI Lite Policy: The policy’s principles of observability and reversibility are operationalized in the file’s logging (8) and degraded-mode (9) sections.

Who should participate in preparing the file

A common mistake is to assume that the technical file is solely the responsibility of the data or engineering team. In reality, it requires coordinated participation from several profiles:

• Product Owner / business owner: Defines the system’s purpose, usage limits and success criteria. Responsible for sections 1 and 2.
• Data Engineer / ML Engineer: Documents the architecture, data, method, metrics and logging. Sections 3–6 and 8.
• Legal / DPO: Validates the AI Act classification, FRIA, DPIA and transparency requirements. Sections 2, 10 and 11.
• Security / CISO: Documents security controls, continuity and recovery tests. Section 9.
• Operations: Defines and documents human-oversight points, the incident runbook and degraded mode. Sections 7 and 14.

The RACI matrix (section 13) formalizes these responsibilities and is key to keeping the file alive after its initial creation.

Conclusion: document today what will be mandatory tomorrow

The technical file is probably the AI Act obligation that requires the greatest operational effort. It cannot be solved with a generic document: every system needs its own file, with specific data, real metrics and documented decisions.

The good news is that most of the information already exists in your organization. The challenge is to structure it, centralize it and keep it up to date. With the 16-section template and a progressive cadence, you can have your files ready before the obligation comes into force.

If you need help building the technical files for your AI systems, defining evaluation metrics or integrating documentation into your governance framework, at Impulsa3 we have the template, methodology and experience to support you.

impulsa3.com · Digital Transformation & AI for SMEs and ecommerce · servicios@impulsa3.com