High-risk AI and the December 2027 deadline

First, the good news about the date

The stage everyone expected on 2 August 2026 did not arrive. The high-risk regime was pushed back by roughly sixteen months, six days before it was due to land.

The reason was practical rather than political. The technical standards that were supposed to tell companies how to meet the requirements had not been published, and the European Commission had missed its own deadline for guidance on classifying high-risk systems. Regulating without telling anyone how to comply was untenable, so the deadlines moved: 2 December 2027 for the stand-alone high-risk uses, 2 August 2028 for AI built into regulated products. Those dates are now fixed and no longer conditional on standards being ready.

For a South African company selling AI into Europe this is a genuine reprieve — and the right way to use it is as a preparation window. The work involved is organisational, not just documentary, and organisations move slowly.

What counts as high-risk

The Act lists the specific uses that qualify. Below are the four clusters that matter most to South African exporters — but they are examples, not the full list. The complete list also covers critical infrastructure, public assistance and healthcare benefits, emergency response, law enforcement, migration and border control, and the administration of justice and democratic processes.

Being on the list is also not always the end of the analysis, which is the part most summaries leave out. Under Article 6(3), a listed system is not high-risk if it poses no significant risk to health, safety or fundamental rights and does not materially influence the outcome of decision-making — provided it meets one of four narrow conditions: it performs a narrow procedural task; improves the result of a previously completed human activity; detects decision patterns or deviations without replacing or influencing the earlier human assessment without proper review; or performs a preparatory task. Profiling of natural persons is always high-risk, whatever else is true. If you rely on this exclusion you must document the assessment before placing the system on the market, and register it under Article 6(4).

A South African fintech selling scoring models to European lenders, an HR-tech vendor with European employer clients, or an insurtech supplying pricing engines to European insurers is building in exactly this territory. So is a BPO whose AI-assisted output feeds any of those decisions for a European client. Check whether the Act reaches you at all before working through this page.

If you build it: the provider stack

This is the substantial part of the Act, and it is worth seeing in one place so the scale is honest. Nine obligations, each of which is real work.

The quality management system is the item most companies underestimate. It is not a document you write in a week — it is an organisation-level process covering design, development, testing and post-market monitoring, and it has to be genuinely operating before a conformity assessment means anything. If you expect to be in scope, that is the piece to start on first.

You will need someone in Europe

One requirement deserves separating out, because it is structural rather than procedural and it surprises South African founders.

A provider established outside the EU must appoint an authorised representative established inside it before making a high-risk system available. That representative verifies your documentation, keeps it available for authorities, and cooperates with them. Critically, the representative must resign and notify the regulator if it considers you are not complying — so this is not a mailbox arrangement.

Failing to appoint one is itself finable, and in practice it blocks market access. It is also the answer to the question South African boards keep asking about how Europe could ever enforce against them: the representative requirement gives regulators an address, and market-surveillance authorities can act on the product itself — ordering corrective action, restricting availability, or forcing withdrawal — without ever needing jurisdiction over your company.

If you only use it: deployer duties

Businesses that use a high-risk system rather than build it carry a lighter set of duties. These land on European subsidiaries of South African groups, and on the European customers of South African vendors — which is precisely why those customers push obligations back up the chain to you.

• Use the system according to the provider’s instructions.
• Assign human oversight to people who are trained and competent to exercise it.
• Make sure the input data you control is relevant and sufficiently representative.
• Monitor how the system operates in practice.
• Keep the automatically generated logs for at least six months.
• Inform workers before you use such a system in the workplace.
• Inform the individuals affected by decisions the system contributes to.

Some deployers go further. Bodies governed by public law, private entities providing public services, and any deployer of credit-scoring or life and health insurance pricing AI must complete a fundamental-rights impact assessment before first use. Note that the last category turns on what the system does, not on what kind of business you are — so it reaches a lender or insurer only because of the AI they deploy. If your South African group has a European insurer or lender in it, that duty is coming for them directly.

The white-label trap

The Act polices the value chain, and this is where South African development houses need to be deliberate.

A distributor, importer, deployer or any other third party that puts its name or trademark on a high-risk system, substantially modifies one, or repurposes a general-purpose system into a high-risk use becomes the provider — and inherits the entire stack above.

The distinction matters commercially. You cannot contract out of being the provider if your conduct makes you one — but you can, and should, agree who performs the compliance work and who pays for it. Article 25(4) assumes exactly that: it requires the provider and a third party supplying tools, services or components to set out, by written agreement, the necessary information, capabilities, technical access and assistance.

In the ordinary white-label arrangement the European client becomes the provider, because they supply the system under their own name, and you are a supplier to them. Record that in the contract along with who hands over technical documentation and instructions for use, who notifies incidents, who controls substantial modifications, and who provides log access so the deployer can meet its own retention duty — understanding that those terms govern the relationship between you and your customer, not your status under the Act.

Sixteen months, in order

The sequencing matters, because the expensive items depend on the cheap ones being done first. There is no point building a quality management system before you know whether your product is even high-risk.

1. Now – mid 2027Live now

   Classify and assess

   For each system in scope, fix your role — provider, deployer or neither — and classify it against the high-risk list. The European Commission published draft classification guidelines in May 2026, three months after its own deadline; use them, but treat them as draft until the final version lands. If your system is likely high-risk, run a gap assessment against the Article 9 to 15 requirements. Negotiate role allocation into your white-label and development contracts now, while there is still leverage.

2. Mid 2027Ahead

   Build the machinery

   Stand up the quality management system, plan the conformity-assessment route, and line up an EU authorised representative. The QMS is the long pole — it is an organisational change, not a document.

3. 2 Dec 2027Ahead

   Annex III high-risk obligations apply

   Full compliance for stand-alone high-risk systems — recruitment, credit, insurance, education, biometrics. Conformity assessment, CE marking, EU database registration, deployer procedures, and fundamental-rights impact assessments where the deployer category requires them.

4. 2 Aug 2028Ahead

   AI embedded in regulated products

   AI built into products that are already regulated for safety. The route differs by product type: machinery, toys, lifts and medical devices sit in Annex I Section A; motor vehicles, aviation and rail sit in Section B, where the requirements are carried through the existing sectoral regimes rather than applied as the Act’s own stack. Check which list your product falls under before assuming the obligations.

Frequently asked