AI Act clauses in your customers’ contracts

Your customer cares more than the regulator does

A South African business can spend a long time working out whether the EU AI Act applies to it as a matter of law — and that is worth doing. But for most companies the question will be settled commercially long before it is settled legally.

The reason is structural. European deployers and importers have their own obligations under the Act and face their own fines. Their most practical risk-management move is to push requirements onto their suppliers. This is exactly the pattern the industry lived through with GDPR: obligations that formally bound European companies ended up in the contracts of everyone who supplied them, worldwide.

So there are two separate questions, and they have different answers. Does the Act bind you as a matter of law? Often no. Three questions settle it. Does it bind you as a matter of contract? Increasingly yes — and a contract you signed is enforceable against you in South Africa without any European regulator being involved at all.

The eight clauses now appearing

These are the terms showing up in European customer paper, with a note on what is reasonable and where to negotiate.

The clause that decides everything else

Of the eight, role allocation is the one to read first. Whether you are the provider or the deployer determines whether you carry the heavy obligations or the light ones — and the Act itself contemplates the parties deciding this by agreement.

In the ordinary white-label arrangement, the European client who sells the system under their own brand becomes the provider, and the South African development house is a supplier to them. That is usually the right outcome — but it should be a decision recorded in the agreement, with a price attached, rather than something discovered when a regulator asks. What the provider role actually commits you to.

The questionnaire arrives before the contract

Before the clauses come the questions. European procurement teams are adding AI sections to their vendor due-diligence packs, alongside the familiar security and data-protection ones. Expect versions of these:

• How do you classify each AI system you supply to us under the AI Act — prohibited, high-risk, transparency-only, or minimal?
• Are you the provider or the deployer of the system, and where is that recorded?
• Do you hold ISO/IEC 42001 certification, or an equivalent AI management system?
• Which models underlie the system, and who are the model providers?
• What documentation, instructions for use and logging can you make available?
• Have you appointed an EU authorised representative, and who is it?
• Where is data processed, and on what basis does personal data leave the EU?
• What is your incident-notification process and timeline?

Answering these from a standing start, under deal pressure, is where suppliers lose weeks and credibility. Answering them from a prepared position — an AI inventory, a written scope conclusion, a classification for each system — turns a compliance burden into a sales advantage. That preparation is the single highest-return piece of work available on this topic.

The same thing is happening upstream

The pressure does not only come from customers. Your own AI and cloud vendors have written AI Act norms into their global terms, which means the obligations reach you from both directions.

OpenAI has published usage requirements telling customers not to use its services for any prohibited practice. AWS states that none of its AI services may be used for prohibited practices under its acceptable use and responsible AI policies. Those terms apply to a South African customer doing purely South African business — you are not regulated by the Act, but you are contractually bound to AI-Act-shaped conduct, and breach is breach of contract with your most important infrastructure supplier.

The allocation is consistent across the hyperscalers, and it is worth understanding because it tells you what you are on your own for. They have taken on the model-level obligations. They have left the system-level ones — transparency, high-risk compliance, avoiding prohibited practices — with the customer. Microsoft casts itself as the upstream provider of AI tools, services and components, and its enterprise customers as the downstream regulated actors it has to support. Google Cloud signed the general-purpose AI code of practice as a model provider and tells customers they are the providers or deployers of what they build. Using their European regions neither creates AI Act exposure nor discharges it.

Where South African law bites back

A European AI annexure lands on a South African contract, and the two do not automatically fit. Three points need local attention.

POPIA. The AI clauses will sit alongside data-protection terms, and the overlaps — incident notification, log access, audit — should be drafted to run off one internal process rather than two conflicting ones. Logs required by the AI clauses routinely contain personal information, which brings them inside your POPIA obligations too.

No adequacy decision. South Africa holds no EU adequacy decision — no sub-Saharan African country does — so personal data flowing from European clients to South African suppliers already travels on standard contractual clauses and similar safeguards. The AI Act now adds a second layer to that due diligence rather than replacing it.

Intellectual property. European model clauses were drafted against European IP assumptions. Documentation-handover and audit provisions need to be squared with South African copyright law and with the ownership positions in your own development agreements — particularly the rule that paying a developer does not, by itself, make you the owner of the code. More on software IP ownership.

Frequently asked