On 2 August 2026, the EU AI Act's full obligations for high-risk AI systems under Annex III become enforceable. That is eight weeks from now. For companies that have classified their AI systems, started documentation, and engaged a compliance programme, eight weeks is enough time to close the remaining gaps. For companies that have not yet started, it is not.
This article is for the first group. It covers the three areas where compliance files are most commonly incomplete at this stage, and what completing them actually requires.
A reminder of who this affects
Annex III of the AI Act defines the high-risk categories. If your AI system is used in any of the following contexts and is placed on the EU market or used by EU entities, you are a provider or deployer with obligations under the full framework:
- Biometric identification and categorisation of natural persons
- Management and operation of critical infrastructure
- Education and vocational training (AI making or influencing access or assessment decisions)
- Employment, worker management, and access to self-employment — including CV screening, interview analysis, and performance monitoring
- Access to and enjoyment of essential private services: credit scoring, insurance risk assessment, benefits eligibility
- Law enforcement and predictive policing
- Migration, asylum, and border control
- Administration of justice and democratic processes
This list is broader than many companies initially assume. If you are in B2B SaaS and your product helps HR teams screen candidates, assess performance, or make promotion decisions — you are in scope as a provider. If you use an external AI vendor's system to make any of these decisions yourself — you are in scope as a deployer.
What a compliant deployment looks like: a worked example
Consider a hypothetical company: a 40-person HR technology startup based in Amsterdam, building a platform that uses machine learning to rank job applicants by predicted job performance. The product is sold to enterprise clients across Germany, the Netherlands, and Belgium.
This company is unambiguously a provider of a high-risk AI system under Annex III (employment, worker management category). From 2 August 2026, they must have in place — and be able to demonstrate to a market surveillance authority — the following:
- A risk management system that has identified and assessed the risks their ranking model creates, including bias risks across protected characteristics
- Technical documentation sufficient to demonstrate compliance, including training data governance records, model performance metrics, and a description of the conformity assessment procedure followed
- A human oversight mechanism that allows deployers to override or ignore the system's outputs — and instructions for use that explain how this works
- Post-market monitoring procedures to detect performance degradation or new risks after deployment
Their enterprise clients — the companies actually using the system to screen candidates — are deployers. They have their own obligations: implementing the human oversight measures, conducting a DPIA if personal data is processed (which it is), and informing job applicants that an automated system was involved in processing their application.
Gap 1: Technical documentation that is not technically sufficient
Annex IV of the AI Act specifies what technical documentation must contain. This is the requirement most companies have addressed last and least thoroughly. The common failure mode is documentation that describes the system at a conceptual level without providing the specific technical detail the regulation requires.
Annex IV requires, among other things:
- A general description of the AI system including its intended purpose, the natural persons responsible for it, and its place within a larger system where relevant
- A description of the elements of the AI system and the process for its development — including design specifications, design choices, training methodology and techniques, training data characteristics, and the steps taken to examine training data for biases
- Detailed information about the monitoring, functioning, and control of the system, including its capabilities and limitations, and the circumstances under which the system may not perform as expected or may give rise to risks
- A description of the changes to the system and its performance made during its lifecycle and the schedule for periodic re-assessment of the risk management system
What this means in practice: the documentation must contain enough technical detail that a market surveillance authority reviewing it could meaningfully assess whether the required risk management measures have been implemented. A three-page summary with bullet points does not meet this standard.
What to do in the next four weeks: Review your technical documentation against each item in Annex IV. For each item, ask: does the documentation contain sufficient technical specificity that a technical reviewer could assess compliance? Flag the gaps and assign them to the engineers and data scientists who built the system — they are the only people who can provide this detail.
Gap 2: The risk management system is a document, not a process
Article 9 of the AI Act requires a risk management system that is a "continuous iterative process run throughout the entire lifecycle of a high-risk AI system." The key word is continuous. The risk management system is not a risk assessment you conduct once and file. It must be a living process with documented review cycles, identified owners, and clear triggers for reassessment.
Most companies at this stage have produced a risk assessment document. Few have built the governance structure that makes it a continuous process. The distinction matters because market surveillance authorities will ask for evidence of the process — not just the document. They will want to see: when was the risk management system last reviewed? Who owns it? What was the trigger? What changed?
Specific requirements of the Article 9 risk management system include:
- Identification and analysis of the known and reasonably foreseeable risks the system poses to health, safety, or fundamental rights
- Estimation and evaluation of risks from intended use and reasonably foreseeable misuse
- Identification of risk mitigation and control measures
- Testing of the system against those measures — this is a documentation requirement, meaning you must record test results
- Consultation with end users where relevant
What to do in the next four weeks: Assign a named owner to the risk management system. Establish a review schedule (at minimum annually, and on each material change to the system). Document the review process and its outputs. Ensure the current risk identification is complete against the specific risk categories relevant to your Annex III sector — bias in employment AI, for instance, is a near-universal finding and must be specifically addressed.
Gap 3: Human oversight is not designed into the product
Article 14 requires that high-risk AI systems be designed and built so that they can be effectively overseen by natural persons. This is an architectural requirement, not a policy statement. It has three practical dimensions:
Interpretability: The system must produce outputs that the human overseeing it can understand. If your system produces a ranked list of candidates with no explanation of why each was ranked as it was, the oversight requirement is not met. The human responsible for the final decision must be able to understand the basis for the AI's output.
Override capability: The system must be designed so the human overseeing it can disregard, override, or modify the output. This must be technically possible and the instructions for use must explain how to do it. A system where the AI's output is the only pathway to a decision — where the human is formally in the loop but functionally unable to deviate — does not meet the standard.
Monitoring capability: The system must allow the human overseeing it to monitor its operation and detect anomalies. For continuously operating systems, this means logs and dashboards that make anomalous behaviour visible.
Back to the Amsterdam HR tech example: if their platform presents a ranked candidate list without any explanation of the ranking, the system is not AI-Act compliant regardless of the quality of the technical documentation. The platform UI must explain why each candidate was ranked as they were, and the HR user must have the ability to disregard that ranking without it affecting the platform's function.
What to do in the next four weeks: Conduct a product review specifically against the Article 14 requirements. Does the UI provide sufficient explanation of outputs? Can users override the system's recommendations without friction? Are there logs that allow a compliance audit of the system's operation? Identify the engineering changes required and prioritise them for the next two sprints.
What deployers still need to do
If you are a deployer — using someone else's high-risk AI system — the August deadline applies to you too. Your obligations are different from a provider's, but they are real:
- You must implement the human oversight measures the provider specifies in the instructions for use. This means someone in your organisation must be assigned responsibility for monitoring the system's operation.
- If the system processes personal data — which high-risk AI systems in employment, credit, or social services almost certainly do — you must conduct a DPIA before deployment.
- Where required (employment decisions, benefits eligibility, law enforcement), you must inform the individuals affected that they have been subject to a high-risk AI system. The form of this disclosure depends on context.
- You must report serious incidents and malfunctions to the provider without undue delay.
What happens after 2 August 2026
The AI Act does not have a soft enforcement period after the deadline. Market surveillance authorities — designated by each member state — will have the power to request technical documentation, conduct inspections, and issue orders to withdraw non-compliant systems from the market. Fines for non-compliance with high-risk AI obligations reach €15 million or 3% of global annual turnover, whichever is higher.
More immediately: if a regulated deployer (a bank, an insurance company, a public authority) discovers that a system they are using has not undergone the required conformity assessment, they face both AI Act exposure and potential liability under their own sectoral regulation. Enterprise customers will increasingly require providers to demonstrate AI Act compliance before renewing contracts — and some are already doing so.
Eight weeks is enough time to close the gaps described above for a company that has already done the foundational classification and risk work. It is not enough time to start from scratch. If you are in a high-risk Annex III category and have not yet begun your compliance programme, the question is no longer whether you will be compliant by the deadline — it is how you manage the exposure after it.
Frequently Asked Questions
My company uses an AI tool from a third-party vendor for HR screening. Am I a provider or a deployer?
You are a deployer. The provider obligations — technical documentation, risk management system, conformity assessment — fall on the vendor who built the system. Your obligations as a deployer include: implementing the human oversight measures described in the vendor's instructions for use, conducting a DPIA if personal data is processed, and informing job applicants that an AI system was involved. Before August 2026, you should request evidence from your vendor that they have completed the required conformity assessment for their system.
Does the AI Act apply to AI systems we use internally, not sold to customers?
Yes, for the purposes of Annex III. If you deploy a high-risk AI system within your organisation to make or significantly influence decisions about employees — performance management, promotion, disciplinary decisions — you are a deployer with obligations under the Act, even though the system is not sold externally. The Act's deployer obligations apply to any use of a high-risk AI system within the EU, not only commercial deployment.
What does "placing on the EU market" mean for a SaaS company based outside the EU?
The AI Act follows the same extraterritorial logic as GDPR. If your AI system is made available to users in the EU — regardless of where your company is established — you are a provider under the Act. A US-based SaaS company whose EU customers use a high-risk AI application is within scope and must comply with the full provider obligations. The fact that servers are outside the EU does not affect this.
What is the conformity assessment procedure for a typical high-risk Annex III AI system?
For most Annex III categories — including employment, credit scoring, and access to essential services — providers can follow a self-assessment procedure. This means you conduct the conformity assessment yourself against the requirements of Articles 9–15, document the results in your technical file, draw up a declaration of conformity, and affix CE marking. You do not need a third-party notified body for most Annex III systems. The exceptions where a notified body is required are biometric identification systems and certain law enforcement applications.
If we miss the August 2026 deadline, what is the likely enforcement sequence?
Market surveillance authorities are expected to focus initial enforcement on complaint-driven investigations and sectors with concentrated use of high-risk AI. A company that misses the deadline but has a documented programme in progress — with evidence of classification, partial documentation, and a remediation plan — is in a materially different position from a company with no compliance activity at all. That said, the legal position is clear: from 2 August 2026, operating a non-compliant high-risk AI system in the EU is an infringement. The safest position is compliance before the deadline, not a plan to demonstrate good faith after it.