This article is about the structure of how obligations arrive, not a survey of jurisdictions. The only regime read at source here is the European one, and the only document quoted is identified with its source and the date it was read. Where a jurisdiction is not mentioned, that is not a statement about that jurisdiction, by implication or otherwise. Nothing here is legal advice in any jurisdiction.
- Technology-neutral drafting means an obligation written before a technology existed can apply to it with no amendment. That is why the first demands an operator meets rarely come from AI-specific law.
- The worked example: the first coordinated supervisory statement on frontier AI risk in the European Union runs on the operational resilience regime, and its ask is to execute existing obligations faster rather than to meet new ones.
- Supervisors move through published expectation, which takes a paragraph. Legislatures move through amendment, which takes years. The gap between those two speeds is where operators are caught.
- Ten rails carry AI demands without an AI statute, and enterprise procurement is among the fastest of them.
- Build an obligation-first register and map AI systems into it. An AI-first register invents a category no regulator uses and drifts from the records that matter.
Section 1. The pattern, stated plainly
There are two ways a legal system can bring a new technology inside its rules. It can write a new instrument aimed at the technology, define the objects, set thresholds and attach penalties. Or it can apply instruments it already has, on the basis that the duty was never about the technology in the first place.
The first route is visible, slow, contested and heavily reported. It produces the trackers and the countdowns. The second route is close to invisible, fast, uncontested and barely reported, because nothing has changed on paper. A supervisor publishes a paragraph explaining that an existing duty covers a new situation, and it does, and there is no legislative event to track.
Operators plan almost entirely around the first route, for the understandable reason that it is the one that produces dates. The consequence is a systematic timing error: the business is prepared for an obligation that has not yet applied and unprepared for a demand that arrives under a rule it has held for a decade.
Section 2. The example this desk has read at source
In the European Union, a joint statement of the European Supervisory Authorities, issued through their Joint Committee under the title Toward a consistent and risk-based approach for ICT risks from frontier AI models, sets out expectations for financial entities and for the authorities that supervise them.
The interesting part is which body of law it belongs to. It names both the operational resilience regime and the AI Act as providing a solid foundation. It then says that the requirements set out in the resilience regime remain highly relevant and lists them: the implementation of the ICT risk management framework, testing, incident and recovery management, and ICT third-party risk management. Its treatment of the AI Act is a single sentence pointing at obligations that sit on providers of general-purpose models with systemic risk, rather than on the entities being addressed. The machinery to go and work on is the older machinery.
The statement is explicit about why. It observes that the regulatory framework remains technology-neutral, and that what has changed is the length of the vulnerability discovery and exploitation cycle, which led the authorities to encourage entities to act fast and proactively and to adapt their capabilities to the new context. That is a regulator declining to write a new rulebook and instead saying the existing one must be executed faster. It is also framed as encouragement rather than requirement: the annex states that it does not establish additional requirements and should not be regarded as a comprehensive checklist.
The full reading of the document, including the governance ask and what it does not do, is at agentliability.eu. One jurisdiction is not a law of nature, and this article does not present it as one. It is presented as a worked example of a mechanism that any technology-neutral legal system makes available.
Section 3. Why this is structural rather than accidental
Four reasons, and none of them is specific to any legal tradition.
Drafting style. A great deal of modern regulation deliberately avoids naming technologies, because naming them dates the instrument. A duty to manage technology risk, to oversee an outsourced function, to keep systems secure, to treat customers fairly or to explain a decision does not need updating when the means of breaching it change.
Institutional speed. Amending a statute requires a legislature. Applying one requires a supervisor with a publication channel. The second is available in days and the first in years, and supervisors are usually the parties who notice a problem first because they are the ones in the room.
Enforcement capability. A new instrument needs new powers, new procedures and often new bodies before anything can be enforced under it. An existing instrument arrives with its enforcement architecture already assembled and its case law already accumulated, which makes it a considerably more attractive route for anybody who wants an effect this year.
Definitional avoidance. AI-specific law has to define its objects, and those definitions are hard, contested and prone to drift. A resilience or outsourcing duty avoids the whole problem by never asking what the system is, only what it does and what depends on it. That is a real advantage and it is why these rails will keep carrying the load even after AI-specific law is fully in force.
Section 4. Ten rails that carry AI demands without an AI statute
Listed in the rough order in which this desk sees them bite. None of these requires the word AI to appear anywhere in it.
1. Operational resilience and technology risk. The obligation to identify, manage and test the technology your operations depend on. Reaches AI as a component of the estate, which is what it is.
2. Outsourcing and third-party risk. The duty to oversee functions you do not perform yourself. An AI capability bought as a service is an outsourced dependency, and it is usually a concentrated one.
3. Security and incident notification. Duties to protect systems and to report when something goes wrong. AI changes the tempo of the threat and the surface of the system, and changes nothing about the duty.
4. Sectoral licensing conditions. Where a business holds a permission to operate, general duties usually ride alongside it: sound systems and controls, competent management, adequate resources. Those duties are elastic by design.
5. Data protection. Rules on processing, on the basis for it, and in many regimes on decisions taken about people without meaningful human involvement. This rail is the one most operators do check, and it is also the one where the AI question is oldest.
6. Consumer protection and unfair practices. If a system misleads, the fact that a model generated the words does not change what was communicated or who communicated it.
7. Product safety and product liability. Where software is treated as a product, defect and causation questions apply to it as they do to anything else, a point we treat at where strict liability reaches AI deployers.
8. Professional conduct rules. For regulated professions, the body that admits practitioners sets standards for the work, and delegating part of the work to a system does not delegate the standard.
9. Enterprise procurement. Not law at all, and frequently the fastest of the ten. A large customer can impose a requirement in a contract renewal cycle, which is faster than any legislature has ever moved. For many suppliers this is the rail that actually changed their behaviour.
10. Investor and listing disclosure. For companies with reporting obligations, a material dependency or a material risk has to be described, and a description that omits a critical dependency is its own problem.
A useful exercise takes an hour: for each of the ten, name the instrument that applies to your business in your principal market, and the person inside the business who owns it. The gaps in that table are usually more informative than any AI regulation tracker, including our own.
Section 5. Build the register the other way round
The common response to AI governance is to create an AI compliance programme with its own register, its own owner and its own reporting line. It is the natural response and it has a structural flaw.
An AI-first register organises records around a category that no supervisor uses when it comes to ask a question. A supervisor asks about a function, a dependency, a decision or an outcome. When the answer lives in a separate AI register maintained by a separate team, two things follow. The answer takes longer to produce, and the two registers diverge, because the operational one is maintained by people doing the work and the AI one by people documenting it.
An obligation-first register inverts this. Start from the duties the business already holds, in the markets where it holds them, and map systems into those duties. The question stops being what does AI law require of us, which nobody can answer completely, and becomes which of the duties we already hold are now engaged differently because a system behaves in a way our controls did not anticipate. That is a question the business can answer this quarter, and it produces records that live where the work lives.
The related error of assuming the strictest regime can be adopted everywhere as a shortcut is treated at the strictest regime fallacy, and the question of which evidence transfers between frameworks at what evidence transfers.
Section 6. The six artefacts that answer most rails
The practical reward for reading obligations this way is that the underlying evidence turns out to be nearly common. Six artefacts recur across almost every rail listed above.
An inventory of deployed systems with named owners, purpose, and a criticality and exposure classification. Every rail starts here, and it is the artefact organisations most often lack, which we set out at agentcertified.eu, on the inventory as the first artefact.
A dependency map covering the parties you do not control, including model providers, hosting, identity, retrieval and any outsourced monitoring.
Dated test results. Not a statement that testing occurs. Results, with dates, against a described system state.
A change log covering the four surfaces that move: model version, instructions and configuration, retrieval sources, and tool permissions.
A human oversight record showing who reviews what, with what authority to stop it, and whether that authority has ever been used.
An incident procedure that has been rehearsed, including the decision about who is told and how quickly, which differs by rail and by market and therefore has to be decided in advance rather than during.
Produced once to the highest standard any single rail demands, those six answer a supervisor, an assessor, an underwriter, a large customer and a court, in the sense that each of them is asking for a subset. Whether to convert them into a certificate or an attestation is a separate decision, taken later, and it is cheap once the evidence exists and expensive before. That distinction is at required and available assurance.
Section 7. Two traps, in opposite directions
Waiting. An operator that treats the absence of AI legislation in a market as the absence of an obligation has confused the visibility of a rule with its existence. The duties on rails one to ten are already held and already enforceable, and the first demand almost always arrives on one of them.
Inventing. The mirror error is assuming a requirement exists because it would be sensible, or because a comparable market has one. That is how a governance programme comes to be built around obligations nobody has, which is expensive and, worse, makes the real obligations harder to see inside the noise. This desk holds itself to the same standard: where it has not read a position at the administering body's own source, it does not describe it, which is why this article names exactly one jurisdiction.
The discipline that avoids both is unglamorous. For each duty you think you have, be able to say where you read it. For each you think you do not, be able to say what you checked.
Section 8. The point in one sentence
The map of AI legislation tells you what will eventually be required, and the map of duties you already hold tells you what will be demanded first, so an operator that builds only the first map will be prepared for the wrong conversation with the right regulator.
Questions
Why do AI obligations arrive through rules that do not mention AI?
Because most regulation is drafted to be technology-neutral, which means an obligation written years before a technology existed can apply to it without any amendment. A duty to manage information technology risk, to oversee outsourced services, to keep systems secure, to explain an automated decision or to sell fairly does not need the word AI in it in order to catch an AI system. Amending a statute takes years and is politically contested. Applying an existing one takes a supervisor a single published paragraph. The result is that the first concrete demands an operator meets are usually made under law that was already in force and already understood.
What is the worked example behind this argument?
In the European Union, a joint statement of the European Supervisory Authorities on the ICT risks of frontier AI models sets out expectations for financial entities. It names both the operational resilience regime and the AI Act as providing the foundation, but the machinery it asks entities to adjust is the resilience machinery: the ICT risk management framework, testing, incident and recovery management, and third-party risk management. It observes that the regulatory framework remains technology-neutral and that what has changed is the length of the vulnerability discovery and exploitation cycle, so its ask is to act faster within the existing framework rather than to comply with a new one. This desk has read that document at source. It has not read the position in any other jurisdiction and characterises none.
Which rules should an operator check besides AI legislation?
Ten families, in rough order of how early they tend to bite. Operational resilience and technology risk rules. Outsourcing and third-party risk rules. Security and incident notification duties. Sectoral licensing conditions and the general duties attached to them. Data protection rules on automated decision-making and on processing. Consumer protection and unfair or misleading practice rules. Product safety and product liability regimes. Conduct rules issued by professional bodies for regulated professions. Contractual conditions imposed through enterprise procurement, which in practice regulate faster than any legislature. And listing or investor disclosure obligations for companies that have them. None of these needs to mention AI to reach it.
Does this mean AI legislation does not matter?
No. It means AI legislation is the wrong single lens, not that it is the wrong lens. AI-specific law defines categories, thresholds and penalties that nothing else does, and where it applies it is decisive. The error is sequencing: an operator that waits for AI law to tell it what to do will meet its first real demand from somewhere else, usually a supervisor applying an existing framework or a customer applying a contract. Plan for both, and expect the older instrument to arrive first.
How should a multi-jurisdiction operator organise this?
Do not build an AI compliance register. Build a register of the obligations the business already has, jurisdiction by jurisdiction, and map AI systems into it. An AI-first register invents a category no regulator uses and creates a second set of records that drifts from the first. An obligation-first register asks a better question, which is not what does AI law require of us but which of the duties we already hold are now engaged differently because a system behaves in a way our controls did not anticipate.
Is there a single evidence set that answers all of these rails?
Close to it, and this is the practical payoff of the argument. Six artefacts recur across almost every rail: an inventory of deployed systems with named owners and criticality, a dependency map covering the parties you do not control, dated test results, a change log covering model version, instructions, retrieval sources and permissions, a human oversight record showing who can stop what, and an incident procedure that has been rehearsed. Produce those once, to the highest standard any single rail demands, and most of the work of answering the others is already done. The certificate or attestation question is a separate and later decision.