Two different calendars, 22 September 2026. The EU AI Act is a regulation already in force, with obligations that don't depend on any national plan. The Plan IA360, presented on 21 September 2026, still has no call for applications and no governing rules. This page doesn't explain the Regulation — for that, see our content on the AI Act — but what gets built, inside an AI project, to respond to it.
The Plan IA360's business voucher will fund services that incorporate, in the plan's own words, «desarrollo, integración, conocimiento sectorial, tratamiento de datos o rediseño de procesos» ("development, integration, sector knowledge, data processing or process redesign"), with a roll-out method that will incorporate a prior maturity diagnosis, identification of a specific use case and subsequent measurement of the impact on productivity. That method — diagnose, document a case, measure — isn't only the criterion for a future voucher: it is, under another name, a good part of what a system needs once its risk classification calls for it. A well-run project doesn't keep the two things in separate folders.
Why the order matters
The four pieces in this section can't be built in just any order, and they don't carry the same weight in every project. The AI Act applies regardless of the Plan IA360, and the scope of what it requires depends on how each system is classified: that's why the first piece — classifying — sets the size of the other three. A project that starts documenting without having classified first risks overdoing the work on a minimal-risk system, or falling short on a high-risk one.
Four pieces built inside the project
Classifying the system. The Regulation doesn't treat a minimal-risk system the same as a high-risk one, and the difference doesn't depend on the technology but on the specific use it's put to. Before documenting anything, it's worth knowing which category each system falls into: it's the first step of the technical inventory described below, not a screening exercise settled on a standalone form.
Technical documentation. The system's architecture, the data it was trained on or connects to, quality metrics: the inventory that later lets you answer if someone asks how a specific model was built. It isn't a document written once and filed away; it's updated with every relevant change to the system.
Evaluation. Bias metrics by subgroup when the system affects people, and adversarial testing — the same red-teaming exercise this guide covers in another piece — when the system can fail through deliberate manipulation, not just statistical error.
Human oversight and monitoring. An auditable record of what the system decided and why, a mechanism that flags if its behaviour degrades over time, and the point at which a person reviews or signs off on the decision before it takes effect on a customer or a process.
From the voucher's phase to the technical piece already being built
The table below cross-references the method the plan describes for the voucher with the technical compliance piece that, in practice, is already being built by following that method:
| Phase of the voucher's method (per the plan) | Technical piece already being built |
|---|---|
| Prior maturity diagnosis | Inventory and classification of the AI systems in use |
| Specific use case | Technical documentation of that case: architecture, data, metrics |
| Measurement of the impact on productivity | Monitoring system and auditable record for that case |
This reading has a limit worth marking precisely: at no point does the plan say that having built this technical layer grants preference, priority or a formal advantage under the future voucher. What is true is that the work doesn't get thrown away between one exercise and the other: the data, the documentation and the knowledge of the use case serve both purposes at once.
What this isn't
A technical project doesn't certify compliance with the AI Act, and it's worth saying plainly: Summum IA isn't a certification body. What a technical AI governance project delivers is the laboratory part — inventory, documentation, evaluation, monitoring — that later underpins any broader compliance process, together with the legal and procedural part that belongs to a different discipline.
Frequently asked questions
Do I have to wait for the voucher's call for applications to build this?
No. As of today the voucher still has no call for applications and no published governing rules, and this technical layer answers to the EU Regulation, which has its own calendar of obligations, already in force and independent of whatever pace the plan keeps.
Does this mean I already comply with the AI Act?
Not on its own. The technical documentation, the evaluation and the monitoring are the part built in the project; full compliance also includes legal and procedural pieces that the technical work alone doesn't cover.
Does this apply the same way to any AI system?
No. The scope depends on each system's risk classification: a minimal-risk assistant doesn't need the documentation work of a high-risk one. That classification is the first step of the technical inventory described above, not a separate formality.
Where can I read exactly what the EU AI Regulation requires?
In the content we already have published on that regulation, starting with AI Regulation in Europe.
Flagship project 11 (Diffusion area) and flagship project 4 (Security area), of the Plan IA360 (official La Moncloa PDF). For the rest of the plan, see the complete guide to the Plan IA360.
Content last verified: 22 September 2026.