Seven Structural Weaknesses in the EU AI Act
By Provectio | April 2026 | ~10 minute read
The EU AI Act contains 632 articles. Provectio measured every one using a traceable measurement process that compares obligation strength, operational specificity, and relationships between provisions. The analysis identified seven categories of structural weakness where the regulation's own text creates material uncertainty or tension.
These are measured structural findings from the corpus. Their legal significance remains a matter for qualified counsel, regulators, and courts.
1. Instruction gaps: 35 articles that bind without specifying
Across the Act, 35 articles carry a demand score above 0.70 but an operational (do) score below 0.40. These provisions impose compulsory force without operational specification. The regulation tells you that you must. It does not tell you what you must do.
Article 9 is the clearest example. It requires providers of high-risk AI systems to establish a risk management system. The compulsory force is 0.85. The operational specification is 0.33. The gap between those two numbers is where legal interpretation will diverge.
"Risk management system" is not defined in Article 9 or elsewhere in the Act. The article specifies that the system must be iterative throughout the lifecycle, that it must identify and analyse known and foreseeable risks, and that risk management measures must be adopted. It does not define what constitutes a risk management system, what minimum components one must contain, or what standard of rigour the analysis must meet.
A provider can construct a document called a risk management system and satisfy the literal obligation. A different provider can construct an identical document and be found non-compliant. Both readings are consistent with the text. The 35 instruction gaps distribute that interpretive uncertainty across the Act's enforcement surface.
2. The 10^25 FLOP threshold: a bright line that does not track capability
Article 51(2) classifies a general-purpose AI model as posing systemic risk if it was trained using a total computing power greater than 10^25 floating-point operations. Models above this threshold carry the additional obligations of Article 55, including adversarial testing, incident reporting to the AI Office, and cybersecurity measures.
The threshold is a bright line. A provider training at 9.9 x 10^24 FLOPs avoids systemic risk classification and the additional obligations of Article 55 entirely. There is no intermediate category. There is no proportionality mechanism below the threshold.
The threshold does not account for compute-efficient architectures. Mixture-of-experts models, distillation, and pruning techniques achieve equivalent or superior capability at substantially lower compute. A model trained at 8 x 10^24 FLOPs using a sparse mixture-of-experts architecture may exhibit more capable and potentially more harmful behaviour than a dense model trained at 1.1 x 10^25 FLOPs. Under the Act, the first model is not a systemic risk model. The second is.
Article 51(3) empowers the Commission to update the threshold by delegated act. As of April 2026, no such act has been adopted. The 10^25 threshold in Article 51(2) is the operative standard.
3. The open-source exemption: one undefined condition
Article 53(2) exempts providers who release general-purpose AI models as open-source from the transparency obligations in Articles 53(1)(a) through 53(1)(c). Three conditions must be met: weights must be publicly available, the architecture must be publicly available, and "information on model usage" must be publicly available.
The first two conditions are precise. Weights are either publicly downloadable or they are not. Architecture documentation is either published or it is not.
The third condition is not defined. "Information on model usage" does not appear in the Act's definitions. The recitals do not specify what it requires. The regulation provides no minimum content standard for usage information.
A provider can release weights and architecture and satisfy conditions one and two with certainty. The third condition can be satisfied by a licence file, a one-page usage guide, or an extensive model card. The regulation does not distinguish between them. It also does not establish a mechanism by which a competent authority can determine that usage information is inadequate and therefore the exemption does not apply.
4. The transparency-trade secret conflict: two high-force provisions, no resolution
Article 53 imposes transparency obligations on providers of general-purpose AI models. The transparency force profile on Article 53 averages 0.92 across its sub-provisions. Article 78 protects confidential information and trade secrets held by providers and other parties. The positional force on Article 78 averages 0.88.
Both provisions apply simultaneously to the same provider with respect to the same information.
Article 53 requires, among other things, technical documentation under Annex XI. Annex XI requires disclosure of training data sources and methodologies, evaluation procedures, and system architecture. These are categories of information that providers routinely protect as trade secrets.
The Act does not establish which provision prevails when a provider argues that disclosing information required under Annex XI would violate Article 78. It does not establish a procedure for adjudicating the conflict. It does not establish a threshold of harm to trade secrets that would justify non-disclosure of technically required information. The AI Office and national competent authorities are left to resolve the conflict without statutory guidance.
The pipeline identified 2,203 structural tensions across the Act. The Article 53 and Article 78 tension is the highest-profile instance of a broader pattern: the Act imposes two simultaneous and potentially irreconcilable obligations without specifying which takes precedence.
5. "Where applicable" escape hatches: provider-determined scope
Annex XI Section 2 specifies the technical documentation requirements for general-purpose AI models. Requirements 2(c), S2-2, and S2-3 each carry the qualifier "where applicable."
The regulation does not define the conditions under which these requirements apply. It does not specify who makes that determination. It does not establish a standard of review for that determination. The provider determines applicability.
Requirement 2(c) covers training data sources and methodologies. S2-2 covers adversarial testing results. S2-3 covers system architecture description. A provider can assert that any of these requirements are "not applicable" without a procedural mechanism for a competent authority to challenge that assertion. The qualifier converts a compulsory requirement into a conditional one, and the condition is self-assessed.
The Act contains 38 force deltas: provisions that bind without specifying the means of compliance. The "where applicable" qualifier is a specific mechanism that generates force deltas. It applies binding force to the general requirement while removing it from the specific one, with no bridge between them.
6. Pending delegated acts: obligations that cannot be enforced
Article 53(5) delegates the methodology for measuring FLOPs and energy consumption to a future Commission act. Annex XI 2(d) and 2(e) require technical documentation that includes training compute and energy use figures. The standard against which those figures would be assessed does not exist.
A provider cannot be found non-compliant on Annex XI 2(d) or 2(e) because there is no adopted methodology specifying how the measurements must be taken, what computational scope they must cover, or what reporting format they must follow.
Chapter V of the Act contains 15 provisions. Six of them delegate operational specifics to codes of practice that had not been finalised as of April 2026. The codes of practice were under development by the AI Office. Until they are finalised, the obligations that reference them cannot be fully operationalised by providers and cannot be fully enforced by competent authorities.
Article 51(2) itself -- the FLOP threshold -- carries the same structural dependency on Article 53(5). The threshold is stated. The measurement methodology is not.
7. The addressee gap: institutional obligations without institutional delivery
Not all Chapter V obligations are addressed to providers. Some are addressed to the AI Office or the Commission.
Article 56 places the design and governance of codes of practice almost entirely on institutional actors. The AI Office is responsible for organising the process, inviting participants, and overseeing development. Providers are invited to participate. The provider's substantive obligation under Article 53(4) is to "rely on" codes of practice once they exist.
If the AI Office has not published codes of practice, the provider's obligation to rely on them is unexercisable. The obligation exists in the text. The instrument required to fulfil it has not been provided by the institution responsible for creating it.
This creates a structural gap between the provider's formal obligation and the institutional infrastructure required to satisfy it. The provider is bound. The means of compliance depends on an action that a third party -- the AI Office -- has not completed.
The gap is not a provider failure. It is a consequence of the Act distributing obligations across multiple addressees without establishing sequencing requirements or default compliance standards for the period before institutional delivery.
Methodology
These weaknesses were identified by Provectio's traceable measurement process. The analysis measured how operational, compulsory, declarative, and role-specific each provision is. Force scores are on a 0-1 scale.
The pipeline identified:
- 35 instruction gaps: articles with demand score above 0.70 and operational score below 0.40
- 38 force deltas: provisions with high binding force and low specification of compliance means
- 2,203 structural tensions: provision pairs with opposing force profiles on the same subject matter
The specific articles cited in this post -- Article 9, Article 51(2), Article 51(3), Article 53, Article 53(2), Article 53(4), Article 53(5), Article 55, Article 56, Article 78, and Annex XI requirements 2(c), 2(d), 2(e), S2-2, and S2-3 -- were identified by the pipeline as the highest-signal instances of each weakness category.
Provectio measures. It does not advise. Whether these structural weaknesses amount to exploitable loopholes is a legal determination for qualified counsel and regulators.