The EU AI Act's high-risk system obligations entered the most active phase of their phased rollout in 2026. The headlines focused for years on the prohibited practices and the general-purpose AI rules, but the operational weight of the regulation falls on providers and deployers of high-risk systems. These are AI systems used in domains like recruitment, credit scoring, critical infrastructure, biometric identification, and certain regulated professional services. The obligations are detailed, the documentation expectations are heavy, and the supply chain implications are substantial.
Which systems actually fall under the high-risk classification?
Annex III of the AI Act enumerates the high-risk categories, and the European Commission has been issuing implementation guidance through 2025 and 2026 to clarify edge cases. The categories that matter most for software vendors are AI systems used in employment decisions, in access to essential services like banking and insurance, in education and vocational training, in law enforcement contexts, and in safety components of regulated products. AI systems embedded in products covered by the EU's product safety regulations also inherit high-risk status when they perform safety-related functions.
The classification is not a binary. A system can be high-risk for one use case and low-risk for another, which means the same model can carry different obligations depending on how it is deployed. Providers of foundation models that downstream customers use in high-risk contexts inherit some obligations to support those customers, even when the foundation model itself was not built for a specific high-risk use case.
The practical advice for engineering teams is to treat any AI system that influences a person's access to a service, an opportunity, or a regulated decision as potentially high-risk and to verify the classification with legal and compliance counsel before deployment. The cost of mis-classifying a high-risk system as low-risk is much higher than the cost of overshooting.
What documentation does a high-risk system actually need?
Article 11 and Annex IV define the technical documentation expectations, and they are extensive. The technical file must describe the system's intended purpose, its architecture, its training and validation data, its performance characteristics, its risk management process, its monitoring approach, and the human oversight design. The file has to be maintained for the lifetime of the system plus ten years after withdrawal from the market.
The training data documentation is where most providers underinvest. The Act requires a description of the data, the methodologies used to ensure its quality, and the steps taken to detect and mitigate biases. "We trained on a snapshot of public data" is not a sufficient description. Auditors expect to see data sourcing logs, preprocessing decisions, dataset governance, and evidence that bias testing was performed on representative subgroups.
The risk management process is similarly detailed. Providers must establish, implement, document, and maintain a risk management system across the AI system's lifecycle. This is not a one-time risk assessment, it is a continuous process with iterative testing, mitigation, and re-evaluation. The risk management documentation is one of the most-asked-for items in conformity assessments.
How does the AI Act interact with software supply chain obligations?
The AI Act treats AI systems as products composed of components, and the supply chain implications follow naturally. A provider of a high-risk AI system that incorporates third-party models, datasets, or libraries inherits responsibility for the safety and conformity of those components. The provider can rely on documentation supplied by upstream vendors, but the provider remains accountable to the regulator.
In practice this means high-risk AI providers need an AI-BOM, a dataset inventory, and a provenance trail for each component used in the system. CycloneDX ML components and SPDX 3.0 AI profile both support this, though tooling maturity varies. The pattern that has emerged in 2026 is to extend existing software supply chain controls to cover ML artifacts, treating model weights, training datasets, and inference runtimes as components subject to the same vulnerability management, signing, and attestation requirements as code.
The interaction with the EU Cyber Resilience Act is also significant. An AI system that is also a "product with digital elements" under the CRA carries obligations under both regulations. The technical documentation requirements overlap substantially but not identically, and the practical answer for vendors is to maintain a unified evidence repository that can produce CRA-flavored and AI-Act-flavored technical files from the same underlying data.
What does ongoing monitoring actually look like?
The AI Act requires post-market monitoring of high-risk systems. Providers must collect, document, and analyze data on the system's performance throughout its lifecycle. The monitoring system has to be designed to detect drift, to identify newly emerging risks, and to feed back into the risk management process.
The Act does not specify the monitoring technology, but the operational expectations are detailed. Providers must be able to detect when the system's performance degrades on subgroups of users, when novel inputs trigger unexpected behaviors, and when downstream incidents indicate a problem with the system. The monitoring data has to be retained, has to be accessible to the regulator on request, and has to be tied to the conformity claims in the technical file.
For models that are continuously updated, the monitoring obligations get more complex. Each significant update is treated as a substantial modification, which can trigger re-conformity. The line between a routine update and a substantial modification is not always clear, and the European Commission's guidance through 2026 has been refining the thresholds. Providers managing continuously-trained systems are building governance processes around update categorization.
How are human oversight requirements being implemented in practice?
Article 14 requires that high-risk systems be designed and developed to be effectively overseen by natural persons. The oversight must be possible during the period in which the system is in use, and the system must be designed so that operators can understand its capacities, monitor its operation, and intervene when necessary.
In practice, human oversight implementations vary widely. The strictest implementations include human-in-the-loop review of every consequential decision, with clear escalation paths and intervention controls. Lighter implementations include sampling-based review, anomaly-triggered review, and post-decision audit. The Act does not prescribe a single design, but the design has to be documented, has to be tested, and has to be effective in practice.
The operational challenge is that human oversight at scale requires significant staffing, training, and tooling. AI systems that produce thousands of decisions per hour cannot have meaningful human review of every decision, so the oversight design has to focus on the highest-risk decisions, the cases the model is least confident about, and the cases that affect protected groups. Auditors look for evidence that the design was tested, not just declared.
What changes through 2026 and into 2027?
The conformity assessment process for high-risk systems is becoming more standardized through 2026 as notified bodies build experience. Sector-specific guidance is emerging for financial services, healthcare, and employment, which clarifies expectations in those domains. Cross-border supervision is also becoming more coherent, reducing the variation in how different member states audit the same vendor.
Ongoing market surveillance is expected to ramp up through 2026 and 2027. The first wave of post-market monitoring data is now flowing in, and regulators are beginning to ask vendors to demonstrate that the monitoring systems described in the technical file are actually operating. Vendors who treated post-market monitoring as a documentation exercise are finding the operational gap exposed.
Foundation model obligations are also evolving. The general-purpose AI rules have a phased rollout that continues through 2027, and the line between general-purpose models and high-risk applications is being clarified through guidance. Providers of foundation models are increasingly publishing model cards, evaluation reports, and downstream-use guidance to support customers' high-risk conformity claims.
How Safeguard Helps
Safeguard provides AI Act high-risk system support across the lifecycle. Lino compliance generates and maintains the technical documentation defined in Annex IV from live system data, including AI-BOM, dataset inventory, risk management records, and post-market monitoring evidence. Eagle model-weight scanning verifies model integrity, pickle safety, and signature validity before models are admitted to a high-risk pipeline, and Griffin reachability analysis surfaces dependency risk through the full ML supply chain. Continuous monitoring captures drift, subgroup performance, and anomaly indicators, and ties them back to the risk management documentation so post-market monitoring is a real operational system, not a paper claim. When notified bodies or market surveillance authorities ask for evidence, the technical file is current, the supply chain is documented, and the monitoring data is available without scrambling.