Under the EU AI Act, many companies will not experience compliance pressure first through a regulator. They will experience it through a contract.
That is the core argument behind Regulation by Contract — a framework for understanding how AI governance will move through the market before it fully moves through national enforcement structures.
The mechanism has five parts: a driver jurisdiction with stronger enforcement or guidance capacity; a transmission channel such as contracts, procurement conditions, or intra-group governance; a receiver jurisdiction where suppliers or subsidiaries are based; an affected operator such as an IT vendor, manufacturer, or health AI company; and a commercial consequence, because non-compliance may lead not immediately to a fine, but to a failed procurement, a delayed onboarding, a lost contract, or a forced remediation plan.
A LinkedIn article introduced the mechanism. This piece goes deeper.
The point is not that the EU AI Act creates something entirely new. The point is that it will reuse legal and commercial machinery that companies already know from earlier EU regulatory cycles — especially GDPR, Germany’s Supply Chain Due Diligence Act, and public procurement. What is new is the breadth of the subject matter. Data protection clauses mainly followed personal data. Supply-chain due diligence clauses mainly followed labour and environmental risk. AI Act clauses will attach to software, models, workflows, HR tools, industrial systems, medical devices, and outsourced digital services. That makes Regulation by Contract both more pervasive and, in some sectors, commercially more immediate.
From GDPR to AI: the first precedent
The clearest precedent is GDPR. Long before many smaller vendors had internalized the Regulation in operational terms, their customers had already done so through contractual documentation. Article 28 GDPR requires controllers to use only processors that provide sufficient guarantees, and it requires processing to be governed by a binding contract that includes specific obligations on the processor. Those obligations are familiar to anyone who has handled a data processing agreement: act only on documented instructions, ensure confidentiality, implement security measures, support the controller’s compliance duties, delete or return data at the end of the engagement, and make available the information necessary to demonstrate compliance, including contributing to audits and inspections.
That is Regulation by Contract in action. A SaaS company in the United States, India, Israel, or Ukraine might not initially have been thinking about Article 28 as the centre of its market-entry strategy. But if it wanted to sell to EU corporate clients, the GDPR arrived in the form of a DPA, a vendor security review, and a procurement checklist. The first real enforcer was often not a supervisory authority. It was a customer’s legal team.
The relevance for the AI Act is direct. Most companies already have the contracting architecture in place: DPA annexes, supplier onboarding packs, audit clauses, incident-notification workflows, and compliance representations. AI governance will not start from a blank page. It will be layered onto these existing templates. That is why AI Act pressure is likely to show up first in amended MSAs, procurement packs, technical appendices, and internal vendor questionnaires — long before many national AI market surveillance authorities become operational.
LkSG: when compliance started arriving as a supplier questionnaire
The second precedent is Germany’s Supply Chain Due Diligence Act, or LkSG. The law applies directly to large companies operating in Germany, but its practical reach extends much further because the due-diligence burden runs through supply chains. Companies in scope must implement risk management, carry out regular risk analysis, establish preventive and remedial measures, and maintain complaints procedures. Official and legal guidance makes clear that these measures can include contractual clauses with suppliers, supplier codes of conduct, and follow-up remediation obligations.
This is where many Central and Eastern European companies learned what Regulation by Contract actually feels like. They were not necessarily directly subject to LkSG. Yet German clients sent updated supplier questionnaires, revised contractual annexes, and new audit and reporting expectations. Suddenly a Polish manufacturer, a Romanian service provider, or a Czech industrial supplier was being asked to certify conditions and controls because a German customer needed evidence for its own due-diligence obligations.
The law also has commercial teeth that matter beyond the legal exposure. BAFA can impose fines for non-compliance, and companies can be excluded from public tenders for up to three years. Once public procurement and reputational risk enter the picture, legal compliance stops being a narrow legal-office issue and becomes a board-level commercial one.
The AI Act should be understood through the same lens. The same German company that learned to push human-rights and environmental diligence through supplier contracts now has to prepare for AI governance obligations. The questions will not centre on forced labour or grievance procedures. They will centre on technical documentation, system classification, human oversight, logging, bias controls, incident handling, model provenance, and whether a system falls into a prohibited or high-risk category.
The AI Act is likely to produce the same supplier-side experience as LkSG — but attached to digital systems rather than labour conditions. Many suppliers will not meet the AI Act first as a regulation. They will meet it as a customer questionnaire.
Public procurement: the under-discussed enforcement vector
A third channel deserves more attention than it usually receives: public procurement. Procurement is where public institutions convert abstract policy principles into operational requirements for real vendors. This matters because governments and public authorities are becoming significant buyers of AI-enabled systems, while the law and practice of AI procurement are still developing.
Recent practical guidance on AI procurement has started to address this gap, including work on model contractual clauses and AI-specific procurement safeguards aligned with data protection and emerging AI governance expectations. A vendor selling into the public sector may find that the first place it is asked to explain human oversight, robustness, incident reporting, or accountability is not in front of a regulator but in the tender documentation.
This is particularly relevant in countries that are simultaneously promoting AI adoption in government while still building out their supervisory architecture. Poland is a good example. The 2021 Polish AI development policy explicitly recommended that local governments allocate ten percent of procurement budgets to AI. Once governments become AI buyers at scale, the procurement process itself becomes an enforcement channel. A bidder does not need to be fined to feel pressure. It is enough to fail the tender.
The logic is not limited to Poland. It applies anywhere public authorities use RFPs, framework agreements, or digital modernisation budgets to shape vendor behaviour. In AI governance terms, procurement can move faster than formal case law and be more demanding than early regulatory guidance. A ministry, hospital network, or local authority may require documentation, testing, or contractual safeguards as a condition of award, even when national regulators have not yet published detailed guidance on those requirements.
Procurement is one of the most important practical vectors of Regulation by Contract — and one of the least appreciated in current AI Act commentary.
The accumulation effect
Most operators will not face one of these channels in isolation. They will face them simultaneously.
A Polish IT company exporting to Germany may receive GDPR-style DPA amendments from one client, LkSG-derived supplier questionnaires from another, and AI Act technical documentation requests from a third — all in the same quarter, without any Polish regulator having yet issued formal guidance. A US SaaS vendor selling HR tools into Europe may find that its EU distributor requires contractual AI Act representations, its German enterprise clients require Annex III classification evidence, and a public-sector tender it wants to bid on requires a human oversight description. None of these pressures come from a supervisory authority. All of them are real.
The accumulation effect is what makes Regulation by Contract strategically significant rather than merely academically interesting. When compliance obligations arrive through multiple commercial channels simultaneously, the aggregate burden can be substantial — and the timeline is set by clients and procurement authorities, not by the legislative calendar. That is why compliance architecture is necessary now rather than when the local regulator publishes its first guidance note.
Non-EU vendors: why the AI Act is already a market-access issue
The fourth element is the non-EU vendor angle. Too much AI Act discussion still assumes a purely intra-EU compliance story. That framing is wrong both legally and commercially.
Legally, Article 2 of the AI Act is explicit. The Regulation applies to providers placing AI systems or general-purpose AI models on the EU market irrespective of whether they are established in the Union or in a third country. It also applies to providers and deployers in third countries where the output produced by the AI system is used in the Union. Many non-EU companies are in scope before anyone reaches for a contract.
Commercially, the contract is still likely to be where the issue becomes real. A US or UK enterprise vendor selling AI-enabled HR or fraud-detection tools into Europe may encounter AI Act compliance not through a formal notice from a regulator but through a procurement annex from a German bank, a due-diligence questionnaire from a French enterprise buyer, or technical documentation requests from an EU distributor. The same applies to Indian outsourcing providers, Israeli cybersecurity firms, Ukrainian development shops, and Latin American service vendors supporting EU clients.
GDPR provides the roadmap. Many non-EU vendors learned about European data protection not by reading the Regulation first, but by being told that signing a DPA and passing a security review was the price of doing business. The AI Act will follow the same pattern. Customers will ask for evidence that no prohibited practices are involved, that the provider can support logging and incident handling, that technical documentation exists, and that the allocation of responsibilities between provider, deployer, importer, and distributor is contractually clear.
For non-EU vendors, this shifts AI Act readiness from a legal compliance issue to a market-access issue. The sales team may feel it before the legal team does.
What this looks like in practice
A Polish software vendor with German clients receives an updated master services agreement in Q1 2026 with a new annex requiring it to confirm whether any AI components in its deliverables fall under Annex III of the EU AI Act, and to provide technical documentation on request. No Polish regulator has contacted them. The pressure came from the contract.
A public hospital network in an EU Member State issues a tender for an AI-assisted triage system. The specification requires the vendor to describe human oversight mechanisms, provide a risk classification under the AI Act, and commit to incident reporting obligations as a condition of award. The national AI supervisory authority has not yet published guidance on triage AI. The tender got there first.
A US enterprise HR software vendor selling recruitment and candidate-ranking tools into European corporate clients receives a due-diligence questionnaire from a German procurement team asking whether the system involves automated decision-making affecting employment, what bias controls are in place, and whether technical documentation per Article 11 of the AI Act exists. The vendor’s EU legal team had not yet flagged the classification issue. The customer did.
How to spot Regulation by Contract in the wild
Once you start looking for it, the pattern is identifiable. The table below maps the most common signals, what they indicate, and who typically feels them first.
| Signal | What it indicates | Who feels it first |
|---|---|---|
| Contract annex referencing the AI Act, high-risk AI, or prohibited practices | Buyer transmitting compliance scope to supplier | Legal / contracts team |
| Vendor questionnaire asking whether AI is used in the product or service | Buyer mapping AI exposure in supply chain | Sales / account management |
| Request for technical documentation, model summaries, or risk classification evidence | Buyer preparing for its own MSA compliance obligations | Product / engineering |
| Audit rights extended to AI systems, training data, or performance monitoring | Buyer securing oversight access through contract | Legal / compliance |
| Incident-reporting clauses covering AI-related failures | Buyer aligning AI Act Article 73 obligations with suppliers | Operations / compliance |
| Tender documents requiring explainability, oversight, or robustness as condition of award | Public authority converting policy into procurement requirement | Bid / sales team |
For exporters, suppliers, and subsidiaries, these signals matter because they show where AI Act pressure will materialise first. In most cases the sequence will be commercial first, regulatory later.
Why this matters now
The most useful frame for Regulation by Contract is this: the AI Act will often move through the market before it fully moves through national authorities.
That is not a loophole. It is how modern regulation increasingly works in integrated economies. A regulation creates obligations for major market actors. Those actors transmit part of the compliance burden through contracts, procurement rules, and group governance. Smaller companies, suppliers, and foreign vendors feel the pressure early — even where local enforcement is still immature.
For executives, the implication is direct. Do not ask only whether your home-country regulator is ready. Ask whether your customers, parent companies, procurement authorities, and major EU buyers are ready. In many sectors, they will be the first effective enforcers.
The CEE Contractual Enforcement Channel Matrix — available as a free download — maps where this mechanism is strongest across eleven countries, which driver jurisdictions matter most, and which sectors are most exposed.
The first AI Act deadline you miss may not be a statutory one. It may be the date a client asks for documentation you do not yet have.
Ovidiu Suciu is an EU AI Act and European AI governance analyst. He is the founder of ovidiusuciu.com, an independent European AI regulation and governance intelligence platform serving companies, compliance and legal teams, policy professionals, and investors.
This article does not constitute legal advice.
