There is no AI regulator in the way there is a banking regulator. What exists is a set of layers, and the layer doing most of the work is the oldest one. Most AI systems running today are governed by law written before anybody was thinking about them.
The law that was already there
A recruitment model that discriminates is an employment law problem. A model trained on customer records is a data protection problem, and Europe's rules on automated decisions predate this generation of systems by years. A diagnostic tool does not stop being a medical device because the conclusion came from a model, a financial product does not escape conduct rules, and a product that injures somebody is covered by product safety and liability law whatever produced the fault.
This is why sectoral regulators matter more than the headlines suggest. They have investigatory powers, precedent and staff already, and their general position is that existing duties apply to the new technology without being rewritten. For a product team the practical point is that the compliance question is rarely whether an AI law applies. It is which of the obligations you already carry now have a harder version.
Law written for AI itself
The EU AI Act is the most developed example and the usual reference point. It sorts systems by the risk of the use rather than the technology. A small set of uses is prohibited, a defined set is high risk and carries duties on data quality, documentation, human oversight, accuracy and monitoring after release, and a lighter transparency duty covers telling people they are dealing with a machine and marking generated content. Obligations fall mainly on the provider that builds a system and, more narrowly, on the organisation deploying it.
Elsewhere the routes differ. Some governments have issued executive direction rather than statute, some are legislating narrowly on particular harms such as synthetic likenesses or automated hiring, and others are still consulting. A product sold in more than one market meets more than one regime.
Voluntary frameworks and standards
The NIST AI Risk Management Framework is the best known voluntary one. It creates no obligations and is influential because it gives an organisation a structure for the work, built around governing, mapping, measuring and managing risk. Buyers increasingly ask about it, which gives a voluntary document something close to contractual force.
ISO 42001 sits nearer the auditable end, specifying a management system for AI that a certification body can assess, much as ISO 27001 does for information security. Standards bodies also write the technical documents regulation depends on, since a law requiring a system to be robust needs somebody to define how robustness is measured, and that is settled in a committee rather than a parliament.
What organisations do for themselves
Most decisions about what a model may do are made by the organisation that built it. Published use policies, internal review boards, staged release processes and safety frameworks committing to evaluations before a capability threshold is crossed all live here, and they are frequently more specific than any law currently in force.
The limit is structural rather than a question of sincerity. The organisation writing the policy benefits from a permissive reading of it, decides what counts as a breach, and can revise the text. Self governance is worth taking seriously as a source of practice and it is not an external check, which is why independent audit exists in every other regulated field.
Why international coordination is hard
Models cross borders and law does not. Coordination has produced principles, declarations and a network of national safety and evaluation bodies, which is real and not binding.
Three things make agreement difficult. Governments disagree about what the risk is, so they are not writing rules about the same object. Regulation is also industrial policy, and no government wants to constrain a domestic industry ahead of its competitors. Enforcement is territorial, so a rule one jurisdiction declines to adopt is a rule with a gap in it. The practical expectation is convergence on documentation and transparency, where agreeing is cheap, long before agreement on what a system is permitted to do.