From drafting to enforcement
The legislative phase of AI regulation is largely complete in the major jurisdictions. What follows is slower, less dramatic and considerably more consequential for operators: supervisory authorities building capacity, issuing guidance and testing their powers against real deployments.
Early enforcement rarely targets the most sophisticated actors. It targets the clearest violations — undisclosed automated decision-making, absent documentation, systems deployed in high-risk categories without assessment.
For most organisations the realistic risk is not a headline fine. It is a supervisory request for documentation that takes three weeks of unplanned engineering effort to satisfy.
The converging compliance backbone
Despite different legal traditions, three obligations recur almost universally. First, disclosure: people should know when they are interacting with an automated system or when one materially influences a decision about them.
Second, provenance: synthetic media should carry durable signals of its origin, with technical standards now stable enough to implement rather than merely discuss.
Third, incident reporting: serious malfunctions in higher-risk systems must be reported to a supervisory authority within a defined window, which presupposes that the organisation can detect them at all.
Risk classification carries legal weight
Most frameworks scale obligations by risk category, which makes the classification decision itself legally significant. Organisations that classify casually and document nothing will find that position difficult to defend.
The practical approach is a short written assessment per system covering purpose, affected people, potential harms and mitigations. Two pages, reviewed annually, signed by an accountable owner.
This document does double duty: it satisfies regulators and it forces the internal conversation that catches poorly conceived deployments before they launch.
What vendors will and will not absorb
Model providers are publishing more documentation, adding provenance signals and offering contractual assurances. That helps considerably with technical documentation obligations.
It does not transfer accountability. In every major framework, the organisation deploying a system into a real-world context carries responsibility for how it is used, regardless of who trained the underlying model.
Procurement teams should therefore focus on evidence they can inherit — certifications, documentation, provenance support — rather than on indemnity language that will not satisfy a supervisor.
Regional divergence that still matters
Divergence persists in three areas: how narrowly high-risk categories are drawn, how training data transparency is treated, and how aggressively cross-border data transfer is restricted.
Multinational operators should map their systems against the strictest applicable regime and treat that as the internal baseline. Maintaining separate compliance postures per jurisdiction is expensive and error-prone at scale.
Practical next steps
Inventory your systems, classify each one in writing, implement disclosure where automated decisions affect people, and build the detection capability that incident reporting presupposes.
None of this requires legal specialisation to begin. It requires an owner, a template and a recurring calendar entry.
Comments (0)
Discussion is opening soon. Be the first to comment.