The clearest starting point for understanding how the EU AI Act affects software development is Chapter III, Section 2: Requirements for high-risk AI systems (Articles 8–15). Read together, these provisions connect risk management to data, documentation, logging, interfaces, and system performance. Article 17 then connects those requirements to the organisation’s development and quality processes.
This is a framework for high-risk systems, whose classification is addressed in Article 6. It should not be treated as a universal set of obligations for every application that incorporates AI.
Michael Veale’s unofficial recast combines the original Act with the 2026 amendments. It is useful for reading the provisions together; the legal sources remain Regulation (EU) 2024/1689 and Regulation (EU) 2026/1744.
The lifecycle approach in Article 9 makes risk management an ongoing development concern. An assessment needs to remain useful through changes to requirements, implementation, and operation. Once it describes a system that no longer matches production, its value as a basis for release decisions begins to weaken.
Testing gives that relationship a practical form. The requirement for predefined metrics and thresholds appropriate to the intended purpose means that evaluation criteria need a justification before results are available. Selecting a metric is itself a substantive decision: it determines which failures become visible and which may remain outside the assessment.
Engineers and lawyers therefore meet at the question of what a result establishes. Passing an evaluation can support a particular claim about the system, within the conditions tested. Deciding whether that claim adequately addresses an identified risk also requires examining the assumptions, coverage, and remaining uncertainty. Those decisions need evidence that can survive beyond the release meeting.
That evidence depends on records which often sit in different parts of a development organisation. Data preparation, evaluation results, system configuration, and release history may each be well maintained while still being difficult to connect. The relationship between data governance in Article 10, technical documentation in Article 11, and logging in Article 12 brings this fragmentation into focus.
Documentation needs to explain the system being assessed, while operational records make it possible to examine what the deployed system did. Maintaining the connection between them requires attention to versions and changes. Otherwise, an investigation can retrieve a valid test report without establishing whether it applies to the release under review.
Version control and release automation can help maintain those relationships. Their usefulness depends on the substance of the records: a reproducible build establishes little about the suitability of evaluation data, and a large volume of logs may still omit the events needed to understand a failure. Traceability is therefore a question of whether the evidence supports an investigation, as well as whether records exist.
The same concern with usable information carries into transparency and oversight. Article 13’s provisions on information for deployers sit alongside Article 14’s requirement for effective human oversight. Reading them together draws attention to how knowledge about a system reaches the people expected to supervise it.
A description of limitations has operational value when it informs a decision at the point of use. Its placement, clarity, and relationship to the output all matter. Permissions and workflow matter too: someone may understand that an output is unreliable but lack the authority or opportunity to intervene.
Assessing oversight consequently involves more than inspecting the available controls. It requires examining whether people can interpret the system’s behaviour and use those controls effectively. Interface design, supporting information, and the organisation of work become connected parts of the assessment. This is where a legal requirement reaches directly into product design and usability evaluation.
Oversight also depends on understanding the conditions in which performance claims hold. Article 15 brings accuracy, robustness, and cybersecurity into the lifecycle assessment, broadening the question beyond a model’s benchmark score.
An integrated product depends on data processing, external services, configuration, and user interaction. Evaluation at the model level leaves uncertainty about the behaviour of that wider system. The engineering task is to establish which properties have been tested at each level and whether the combined evidence supports the claims made about the product.
Those claims can become less reliable as dependencies or operating conditions change, even if the model remains unchanged. Maintenance therefore needs a way to recognise when earlier evaluations warrant review. The risk assessment, records, and operational information discussed above provide the basis for making that judgement.
Keeping these relationships intact takes an organisational process. Article 17’s documented quality management system connects design, development, testing, and modification management, giving the preceding requirements a place within software delivery.
The central issue is continuity of responsibility. A risk decision should remain connected to the requirement it informs, the control intended to address it, and the evidence used to evaluate that control. When the implementation changes, someone needs responsibility for deciding which parts of that reasoning remain valid.
For engineers, this makes the reasons behind development constraints available for review. For lawyers, it provides a route from an obligation to the decisions and evidence supporting its implementation. The resulting process can accommodate changing software while preserving a basis for assessing it. These connections are an engineering reading of Chapter III, Sections 2 and 3, rather than a prescribed architecture or delivery methodology.
The July 2026 amendments matter when reading older explanations of the Act. The Commission’s implementation overview confirms that the Digital Omnibus entered into force on 27 July 2026 and gives the revised dates for high-risk rules:
Those dates are set out in the amendments to Article 113. There are also narrower transitional provisions. For example, providers of synthetic-content systems placed on the market before 2 August 2026 have until 2 December 2026 to comply with Article 50(2). That is a specific transition, rather than a postponement of every transparency obligation. See the amending Regulation, Article 1, points 39–40.