The public discussion about AI regulation often takes place at a level of abstraction that makes agreement relatively easy. Artificial intelligence should be safe, fair, transparent, accountable, privacy-preserving and subject to appropriate human oversight. Few organisations would object to those ambitions, and variations of them now appear across government frameworks, international standards, corporate policies and legislation.
The difficult part begins one level below the principle.
What does fairness require when an AI system ranks job applicants? How transparent should a bank be about a model used in lending? What constitutes meaningful human oversight when an automated system makes thousands of decisions each day? How should an organisation demonstrate that an AI system is sufficiently accurate for its intended purpose, and who should be responsible when a model supplied by one company is incorporated into a service operated by another?
These are regulatory questions because regulation ultimately has to translate broad social objectives into decisions about who must do what, under which circumstances, and what evidence they must retain to demonstrate that they have done it.
Understanding AI regulation therefore requires moving beyond the principles themselves and examining the machinery that turns them into practice.
AI is not regulated in a legal vacuum
One misconception is that, unless a country has enacted a dedicated AI Act, artificial intelligence is effectively unregulated.
That is rarely the case.
An organisation using AI may already be subject to privacy and data protection law, consumer protection, employment law, anti-discrimination requirements, intellectual property law, product safety obligations, financial services regulation, professional standards, contractual duties and sector-specific requirements. The fact that a decision was produced with machine learning rather than conventional software does not ordinarily cause those obligations to disappear.
Australia provides a useful example. The Australian Government’s AI guidance sits alongside existing laws rather than replacing them, and its own material makes clear that the use of AI can already engage laws of general application as well as sector-specific requirements. Australian privacy requirements also apply to the collection and handling of personal information in AI-related contexts, with the Office of the Australian Information Commissioner explicitly incorporating AI into updated guidance on the Australian Privacy Principles.
The regulatory question is consequently broader than whether there is a statute containing the words “artificial intelligence”. An organisation may face legal obligations because of what its AI system does, what information it uses, whom it affects and the context in which it operates.
Dedicated AI regulation adds another layer by addressing characteristics that may not fit comfortably within existing legal categories, particularly where AI systems operate at scale, change over time, produce probabilistic outputs or are supplied through complex chains of developers, model providers, integrators and deployers.
Regulation usually begins with risk
A recurring feature of contemporary AI governance is the idea that not every AI system should be regulated in the same way.
This is important because “AI” covers an enormous range of applications. A system recommending the order in which products appear on an internal inventory screen does not present the same risks as one determining access to employment, credit, healthcare or essential public services.
A risk-based regulatory model attempts to distinguish between them.
The European Union’s AI Act is the most developed legislative example, applying different requirements according to the type of system, its use and the risks associated with it. The Act entered into force in August 2024 and has been applying progressively, with prohibitions and AI literacy provisions beginning in February 2025, general-purpose AI obligations from August 2025, and further transparency and enforcement provisions applying from August 2026. Other requirements, including important rules for designated high-risk systems, follow later under the current implementation timetable.
The significance of this approach is conceptual as much as legal. Regulation becomes less concerned with whether software technically qualifies as AI and more concerned with the combination of capability, use and consequence.
An AI model that generates a draft birthday message presents relatively little regulatory concern. The same underlying model incorporated into a system that assesses candidates for employment raises a different set of questions because the context changes the consequences of error.
Risk attaches to systems in use, not simply to models in isolation.
Principles become obligations
Consider the principle of transparency.
At the level of principle, transparency sounds straightforward. People should have some understanding of when AI is being used and how consequential decisions affecting them are made.
Turning that principle into practice immediately requires additional choices.
Should people always be told that they are interacting with AI? Should an organisation disclose which model it uses? Should it explain which categories of data influence a decision? Should affected individuals receive an explanation of a particular outcome, or is a general description of the system sufficient? How much technical information can reasonably be provided without exposing security-sensitive information or intellectual property?
The same problem occurs with fairness.
A commitment that an AI system should be fair does not specify which groups should be compared, which measure of fairness should be used, what level of disparity is acceptable, or how legitimate differences between cases should be distinguished from discriminatory treatment.
Regulation has to move from the noun to the verb. Transparency becomes requirements to disclose, document or explain. Fairness becomes obligations to test, assess and mitigate. Accountability becomes named responsibilities, governance processes and records. Safety becomes testing criteria, monitoring arrangements and incident responses.
This transition from principle to operational requirement is where most of the real work of AI governance occurs.
High risk does not necessarily mean bad AI
The language of “high-risk AI” can also be misleading because it can sound like a judgement that a technology is inherently dangerous or undesirable.
That is not necessarily what the term means.
A system may be classified as high risk because the consequences of an incorrect or inappropriate decision are significant, even where the technology itself produces substantial benefits.
Medical devices provide a familiar analogy. We regulate them carefully not because medicine is undesirable, but because mistakes can matter. Similar reasoning applies when AI influences employment, credit, education, safety or access to important services.
The appropriate response to higher risk is therefore generally stronger assurance rather than automatic prohibition.
This can mean more extensive testing, better documentation, clearer responsibility, stronger data governance, closer monitoring, greater capacity for human intervention and more robust mechanisms through which affected people can challenge outcomes.
The regulatory burden becomes proportional to consequence.
That principle also provides a useful guide for organisations even where particular regulatory obligations do not apply. An AI system used to generate ideas for an internal workshop does not need the same governance architecture as a system influencing who receives a mortgage.
Treating them identically would create considerable administrative effort without necessarily improving outcomes.
Some uses may be treated differently again
Risk-based regulation does not imply that every risk can be managed through additional controls.
Some applications may be prohibited or tightly restricted because regulators conclude that the underlying use creates unacceptable risks that cannot be adequately addressed through ordinary governance measures. The EU AI Act, for example, contains prohibitions applying to specified AI practices rather than merely imposing additional documentation or testing requirements on them.
This creates an important hierarchy.
At one level are ordinary applications where existing organisational controls may be sufficient. At another are systems whose consequences justify additional regulatory obligations. Beyond those sit particular uses that a jurisdiction may determine should not occur at all, or should occur only within narrowly specified conditions.
The dividing lines are legal and jurisdiction-specific, but the underlying regulatory logic is relatively clear: as potential harm increases, the justification for stronger intervention also increases.
The model provider is not the only responsible party
AI regulation becomes more complicated because contemporary AI systems are assembled through supply chains.
A company might develop a foundation model. Another company provides access to it through a cloud service. A software provider incorporates the model into an application. A consulting firm configures the application for a client, and the client ultimately uses the system to make or support decisions affecting customers.
If something goes wrong, who is responsible?
The answer cannot always be “the company that made the model”, because many important risks arise from how the technology is configured and used.
A general-purpose model provider may have no knowledge that its model will eventually be incorporated into a recruitment process. The organisation deploying that recruitment system, by contrast, knows the population affected, the decision being supported, the data being supplied and the consequences of an error.
This is why contemporary regulatory frameworks increasingly distinguish among actors across the AI supply chain. Australia’s earlier Voluntary AI Safety Standard, for example, explicitly distinguished developers from deployers and placed substantial emphasis on the responsibilities of organisations using AI systems, including governance, risk management, testing, human control, transparency and record keeping.
Responsibility therefore follows both technical control and contextual knowledge. The developer may know most about how the model was built, while the deployer may know most about how it is being used.
Effective governance requires information to move between them.
Documentation is not bureaucracy for its own sake
One of the most visible consequences of AI regulation is likely to be an increase in documentation.
That can easily be dismissed as compliance bureaucracy, particularly by organisations accustomed to experimenting with AI tools informally. Yet documentation performs an important economic and organisational function because it creates institutional memory about why a system exists, how it was evaluated and who accepted the associated risks.
Imagine that an organisation introduces an AI system for customer service. Twelve months later, the employees who implemented it have moved roles, the model has been updated several times and a customer challenges an automated decision.
Can the organisation establish which model was used, what data it accessed, what testing was performed, which limitations were identified, who approved deployment and what monitoring has occurred since?
Without records, accountability becomes largely retrospective guesswork.
Documentation also makes governance scalable. Senior executives cannot personally inspect every AI interaction, and boards cannot evaluate every model output. They need evidence that appropriate processes exist and that those processes have been followed.
This is why record keeping appears repeatedly in governance frameworks. It converts responsible AI from an assertion into something that can be examined.
Testing turns principles into evidence
A similar transition occurs with concepts such as reliability, safety and fairness.
An organisation cannot establish that a system is reliable simply by adopting a policy stating that AI should be reliable. It needs evidence about how the system performs.
That might involve testing factual accuracy, error rates, performance across relevant populations, robustness to unusual inputs, cybersecurity vulnerabilities, privacy risks or the ability of the system to operate within defined constraints.
The required tests should depend on the system.
An AI tool used to summarise internal meeting notes might be assessed primarily for factual fidelity, privacy and information security. A model used to rank employment applicants would warrant much closer examination of selection effects, discriminatory outcomes, data quality and the consequences of false positives and false negatives.
The US National Institute of Standards and Technology’s AI Risk Management Framework provides a useful illustration of this approach. It is voluntary rather than legislation, and is organised around managing AI risks across design, development, deployment, use and evaluation, with characteristics including validity, reliability, safety, security, accountability, transparency, explainability, privacy and fairness.
Its significance lies partly in translating broad principles into a risk-management process rather than assuming that compliance with a list of values is sufficient.
Regulation increasingly asks organisations to demonstrate what they know about the behaviour of their systems.
Human oversight has to mean something
“Human in the loop” has become one of the most common responses to concerns about AI, but the presence of a person somewhere in a process does not automatically constitute meaningful oversight.
Suppose an AI system assesses 5,000 applications and produces a recommended shortlist of 100 candidates. A recruiter then reviews those 100 names before interviews are offered.
There is clearly a human in the process.
But if the AI incorrectly excluded a qualified candidate from the original 5,000, the recruiter may never see that person. Human review of the final shortlist does not necessarily provide oversight of the selection process that produced it.
Meaningful oversight therefore depends on what the person can observe, understand and change.
Does the reviewer have enough information to identify an error? Can they override the system? Are they given sufficient time to review decisions properly? Are they likely to defer automatically to the model’s recommendation? Can excluded cases be sampled to determine whether the system is systematically missing particular candidates?
These are design questions rather than slogans.
Human oversight becomes meaningful when the surrounding process gives people genuine capacity to detect and correct important failures.
Regulation also changes procurement
Most organisations using AI will not build their own foundation models, which means that a substantial part of AI governance will occur through procurement.
Before acquiring an AI system, organisations increasingly need information about the provider’s data practices, security arrangements, testing, model limitations, incident processes and approach to updates. They may need to understand whether organisational data are retained, where processing occurs, whether information is used for model improvement and what happens when the underlying model changes.
This creates an interesting shift in the market.
Responsible AI becomes partly a supplier-management problem.
A buyer cannot directly inspect every aspect of a proprietary model, so contracts, technical documentation, certifications, audit rights and supplier assurances become mechanisms for transferring information through the supply chain.
This can also favour providers capable of producing credible evidence about their systems. A technically impressive AI product that cannot answer basic questions about data governance, security or evaluation may become difficult to use in regulated environments regardless of its benchmark performance.
Governance therefore becomes part of product quality.
Regulation does not mean that every decision requires explanation at the level of the model
One recurring concern is that modern AI systems can be difficult to interpret internally. If regulators require complete explainability, does that make advanced machine learning impossible to use?
The issue is more nuanced because explanation can occur at several levels.
An organisation may not be able to provide a simple account of the contribution made by every parameter inside a large neural network, but it may still be able to explain what the system is intended to do, what information it uses, how its performance was evaluated, what limitations are known and how a particular decision can be challenged.
For many regulatory purposes, these forms of procedural and outcome-level transparency may be more useful than a technically exhaustive description of internal model mechanics.
The appropriate explanation also depends on the audience. A regulator, technical auditor, customer and affected employee may reasonably require different information.
Transparency is therefore not a single technical property of a model. It is a relationship between information, audience and purpose.
Australia illustrates another regulatory path
Australia is particularly useful because its approach demonstrates that AI governance need not begin with a single comprehensive AI statute.
The Australian Government previously consulted on mandatory guardrails for high-risk AI, but subsequently stated that it would not proceed with those proposals at that time, with the consultation instead informing the National AI Plan. Meanwhile, the earlier Voluntary AI Safety Standard has evolved into updated guidance for AI adoption, while existing Australian laws continue to apply according to the context in which AI is developed and used.
This differs institutionally from the European Union’s more comprehensive legislative model, but it illustrates an important point about AI regulation internationally: jurisdictions can pursue similar objectives through quite different combinations of legislation, existing regulators, voluntary standards, technical frameworks and sector-specific rules.
For organisations operating across markets, the practical challenge is therefore not simply complying with one universal AI rulebook. It is building governance processes capable of mapping different external requirements onto the same internal systems.
That makes interoperability between standards and frameworks increasingly valuable.
Regulation and standards are not the same thing
It is also important to distinguish laws from standards, frameworks and organisational policies.
A law creates legally enforceable obligations within its jurisdiction. A technical standard can establish agreed practices or management requirements. A risk-management framework can help organisations structure their internal processes. An internal policy can determine what employees are permitted to do.
These instruments can reinforce one another without being interchangeable.
NIST’s AI Risk Management Framework, for example, is expressly voluntary and is currently being revised, while its Generative AI Profile provides additional guidance directed towards risks associated with generative systems. Compliance with such a framework is therefore not the same thing as compliance with legislation, although the practices it encourages may help an organisation develop the evidence and controls required under applicable law.
This distinction matters whenever an organisation claims that an AI system is “compliant”. The immediate question should be: compliant with what?
A certification, internal policy, voluntary framework and statutory obligation have different legal and evidentiary significance.
Good regulation changes incentives before something goes wrong
The most important effect of regulation may occur long before a regulator imposes a penalty.
If organisations know that consequential AI systems must be tested, documented and monitored, those requirements influence how systems are designed and purchased. If suppliers know that customers will ask for evidence about data provenance, security and performance, they have stronger incentives to produce that evidence. If decision-makers know that affected people can challenge an automated outcome, there is greater reason to consider how those outcomes can be explained and reviewed.
Regulation therefore operates partly by changing the incentives surrounding technology development and deployment.
Poorly designed regulation can also create undesirable incentives. Requirements that are excessively prescriptive may entrench existing technologies, impose disproportionate costs on smaller firms or encourage compliance activity that generates paperwork without improving outcomes. Rules written around particular technical architectures can become obsolete as technology changes.
The challenge is to make obligations sufficiently concrete to influence behaviour while remaining sufficiently adaptable to apply as systems develop.
This is one reason risk-based approaches have become prominent. They attempt to concentrate regulatory effort where the expected consequences justify it rather than applying the same burden to every use of AI.
From principle to practice
For an organisation, the path from a statement such as “we use AI responsibly” to an operational governance system can be expressed relatively simply.
First, identify the AI systems being used and the decisions or processes they influence. Without visibility over where AI is operating, there is little basis for governance.
Next, assess the context and consequence of each use. A writing assistant and an employment screening system should not enter the same governance pathway simply because both contain generative AI.
Then identify the obligations that apply, including existing law, sector regulation, contractual requirements, relevant standards and internal policy.
Those obligations need to be translated into controls. Depending on the system, these might include access restrictions, data minimisation, testing, human intervention, approval thresholds, disclosure, monitoring, security measures and mechanisms through which affected people can challenge decisions.
Finally, retain evidence that the controls exist and work. That can include risk assessments, test results, model and system documentation, approval records, monitoring data, incident logs and records of significant changes.
This progression is what turns an ethical principle into organisational practice:
Principle → Risk → Obligation → Control → Evidence
The sequence also helps explain why AI regulation is becoming a management issue rather than something that can be delegated entirely to legal or technical teams. Lawyers can interpret obligations, technical specialists can evaluate models, risk teams can design controls and operational teams can monitor systems, but somebody still has to connect those activities into a coherent decision about whether and how the organisation should use AI.
The practical question is not whether AI should be regulated
The debate is sometimes presented as a choice between innovation and regulation, as though organisations could either move quickly with AI or subject it to governance.
In practice, organisations already govern technologies that matter. Financial systems have permissions and audit trails. Software changes are tested before production. Employees have delegated authorities. Sensitive data are subject to access controls. Major investments require approval. Products are tested against standards and legal obligations.
AI extends these familiar problems into systems whose behaviour can be probabilistic, adaptive and difficult to predict completely in advance.
The practical challenge is therefore to determine which existing controls remain adequate, where AI introduces genuinely different risks and where new forms of assurance are justified.
Good AI regulation should ultimately make that allocation clearer. It should distinguish low-consequence experimentation from consequential deployment, assign responsibilities to the actors capable of managing particular risks, require evidence where assertions are insufficient and provide stronger protections where failures can materially affect people.
For organisations, the objective is not to accumulate principles or produce the longest AI policy. It is to know which systems they are using, understand what those systems can affect, establish controls proportionate to the consequences and be able to demonstrate why those controls are adequate.
That is the point at which responsible AI stops being a statement of intent and becomes a way of operating.