Jun 5
/
James Kavanagh
How I scope compliance obligations for AI governance
How to figure out, quickly and systematically, which regulations, standards and frameworks apply to your organisations use of AI.
If you read my previous two articles on how I triage AI governance problems and how I set about fix broken governance, you might have noticed something. I haven't really mentioned compliance yet. The triage was about harm: which systems could hurt people, and which of those are we least able to detect? The diagnostic was about mechanisms: does the governance machinery actually work and what precise improvements are needed? Both of those sit in what you might call the "safe and secure" territory of AI governance.
Assuring yourself of lawful compliance calls for a different approach. It can be done quickly too, with the right preparation, but to explain how I need to take a diversion. Before you can triage compliance gaps, you need to know what's actually applicable to your business. And before you can figure out what's applicable, you need a systematic way to cut through the complexity of hundreds of potential regulations, standards, contracts, and commitments that might be relevant to your use of AI. That's what this article is about: the scoping. How to figure out, quickly and systematically, which sources of external expectations actually apply to you.
If you're a new practitioner in AI governance, you probably started by studying laws, frameworks and standards specific to AI. Then when you actually begin doing the work, you're surprised to find that the most consequential legal requirements on your organisation's use of AI are almost certainly not from any AI-specific legislation.
More likely they're from privacy law. Data protection regulation. Sector-specific legislation in healthcare, financial services, education, employment. Security and resilience requirements from standards like ISO27001 and 27701. Consumer protection law. Anti-discrimination law. Contract law for all the commitments you're bound to in customer and supplier contracts. These frameworks have been around for years, some for decades, and they apply to what your AI systems do regardless of whether anyone has passed a shiny new AI law about it.
I'll give you a local example to illustrate. Take an Australian company building AI-powered tools for healthcare. They might look at the regulatory landscape and think they're in a fairly comfortable spot. No AI Act equivalent has landed. No prescriptive classification scheme. No conformity assessment requirement. And that's true, as far as AI-specific regulation goes. But that company processes personal information under the Privacy Act. They're subject to health records legislation in the states where they operate. They employ people, so the Fair Work Act and anti-discrimination law apply. They serve consumers, so consumer protection law applies. If their AI systems make automated decisions that affect individuals, the Privacy Act's requirements around access, correction, and notification of collection are all relevant. And if they've committed to ISO 27001 certification, those requirements don't politely stop at the boundary where AI begins.
An awful lot of the compliance perimeter is already there, sitting in legislation and standards that predate AI governance as a discipline. You'll find the AI-specific stuff layers on top. It doesn't replace the foundation underneath.
I'm starting here with that reality check because I see practitioners, especially those newer to the field, make a mistake over and over again. They start with the AI-specific artifacts. They pick up the EU AI Act, or ISO 42001, or the NIST AI RMF, and they work through it asking "does this apply to us?" And in doing so, they take for granted that the existing body of requirements, privacy law, sector regulation, employment law, consumer protection, security standards, contractual obligations, is somehow already taken care of. Someone else is handling that. It's already been done by someone else, so it's not my problem.
Except it often hasn't been done, at least not in a way that accounts for AI. Maybe obligations under the Australian Privacy Act were scoped before the organisation started using AI to make automated decisions about people. The health records legislation was interpreted before clinical AI systems were embedded in care pathways. The employment law compliance was designed around human decision-making, never addressing potential issues like algorithmic screening. The existing compliance work may be real, but it almost certainly wasn't designed with AI in mind, and nobody has gone back to check whether the arrival of AI systems has changed what those existing obligations actually require.
Getting to grips with this complexity can be hard, especially when dealing with multiple jurisdictions and needing to comunicate legal requirements across mainly non-legal audiences. When I was leading regulatory intelligence at Amazon Web Services, we had to keep track of thousands of different legislative artifacts, policies, standards, and guidelines that were all potentially applicable to how services were built and operated. Legal teams in each country and globally would interpret the local laws, identify what was new or changing, and work through what it meant for the business. But our role on the assurance side, interfacing with engineering, was different. We had to make sure that the products and services were actually engineered, operated, and assured in ways that could satisfy all of those requirements. And "all of those requirements" was not a small number. Thousands of important pieces of primary and secondary legislation, regulatory guidance, standards, and contractual frameworks, each containing multitudes of specific requirements and processes. All at different stages of implementation, all changing at different speeds. A genuine maze of external expectations brought to bear on how products and services were delivered.
You just can't approach that kind of complexity one artifact at a time. You pick up one regulation, work through it, pick up the next, and by the time you've finished the tenth the first three have changed. And even if you could keep up, the artifact-by-artifact approach doesn't show you the connections, where three different regulations from three different jurisdictions all require essentially the same thing but describe it differently, or where one regulation's requirement directly conflicts with another's. Only a systematic approach can cope with that kind of complexity. That experience is a big part of why I think about compliance scoping the way I do now.
I think there's a better way. It starts not with the regulation, but with the business.
Start with what you do, not what they wrote
There's a concept in environmental management that I think AI governance practitioners should know about. ISO 14001, the environmental management standard, has been helping organisations figure out which regulations apply to them for decades. Its approach is elegantly simple. You start by identifying your "environmental aspects," the specific ways your activities interact with the environment. Emissions, waste, water use, energy consumption. These are factual descriptions of what your business does. Then you assess which aspects are significant. Then you identify the legal requirements that attach to those aspects.
The regulation follows from the activity. Not the other way around.
ISO 37301, the compliance management systems standard, takes a similar approach. It requires organisations to systematically identify their compliance obligations based on their activities, products, and services. It distinguishes between mandatory obligations and voluntary ones. And it makes an important point that I'll come back to later: anything you voluntarily commit to becomes an obligation the moment you commit to it.
Now, I'm drawing on these standards for the principle, not suggesting you go and implement them wholesale. They're good at the structural idea: start from your activities, let the obligations follow. But they don't actually help you with the hard part. ISO 37301 tells you to identify your obligations, but it doesn't give you a method for figuring out what those obligations really need you to do in practice. It operates at the management system level: have a compliance function, assign ownership, monitor for changes, maintain a register. All sensible. But it assumes the obligation identification has been done, and it doesn't give you a practical engine for doing it at scale.
So here's what I do. Instead of starting with a regulation and asking "does this apply?", I start by describing the business. What it does, where it operates, who it serves, what data it handles, what decisions it makes about people. Factual, observable characteristics that either trigger a regulatory obligation or they don't. I think of these as aspects of the business, and I organise them into seven categories.
Seven categories of aspects
I'll take you through them in the sequence I use. And I'll keep coming back to our Australian healthcare company to illustrate.
Activity is what your organisation does. Not what your AI systems do. What your business does. You make employment and recruitment decisions. You provide clinical care. You assess creditworthiness. You deliver education. You administer public services. You sell products to consumers. These are business activities that trigger entire branches of regulation regardless of whether AI is involved. Employment law doesn't care whether you use an algorithm or a human to screen candidates. It cares that you're making employment decisions. When you then use AI to perform those activities, AI-specific regulation layers on top. But the base obligation comes from the activity itself.
Our Australian company provides clinical care, makes clinical decisions about patient prioritisation, employs staff, and sells software products to hospitals. Those are four distinct activities, and each one pulls in its own regulatory branch. Health legislation for clinical care. The Therapeutic Goods Act if any of their software meets the definition of a medical device, and the TGA's 2026 guidance makes clear that AI software intended to influence clinical decisions or patient care is very likely in scope. Employment and anti-discrimination law for hiring. Consumer protection and contract law for the software they sell.
Geography is where you operate, where your customers and users and subjects are, and where data is processed. This is about jurisdictional scope, including extraterritorial reach, which catches a lot of people out.
Our company is based in Australia, so the Privacy Act applies. Straightforward. But lets say they also sell their software to a hospital group in Germany. Now GDPR applies, because they're processing personal data of people in the EEA. And the EU AI Act may apply, because they're arguably placing an AI system on the EU market. From one client relationship, two major pieces of EU regulation come into scope. And if they host their platform on a US cloud provider, that adds another layer around international data transfers. Geography is rarely as simple as "where's our office."
Sector is what industry you operate in. Healthcare, education, financial services, insurance, public administration, law enforcement, critical infrastructure. Sector determines which additional regulatory layer sits on top of the horizontal regulation that applies to everyone.
For our company, the sector is healthcare, and that obviously brings regulatory implications. In Australia, that means state and territory health records legislation, the My Health Records Act if they interact with the national digital health record system, and the TGA's medical device framework. If they're selling into the EU, the Medical Device Regulation potentially applies alongside the AI Act.
Data type is what categories of data your organisation handles. Personal data, special category data, children's data, biometric data, health data, financial data, criminal records data. Each data type can independently trigger obligations regardless of what the system does with it.
Our example company processes health data, which is special category data under GDPR and sensitive information under the Australian Privacy Act. That independently triggers heightened obligations around consent, security, and data handling, regardless of whether AI is involved in the processing. If any of their systems process children's health data, the Privacy Act has specific provisions, and Australia's Information Commissioner is currently developing a Children's Privacy Code under the 2024 amendments. Data type triggers obligations that activity and sector alone might not surface.
Entity type is what kind of organisation you are. Public body, critical infrastructure operator, large enterprise, SME, micro-enterprise, research institution. This one opens or closes entire branches of obligation in one go.
Our example company is a private SME. If they were a public health service, they'd have additional transparency obligations, and the EU AI Act requires fundamental rights impact assessments specifically for public sector deployers. Some regulatory exemptions only apply to micro-enterprises.
Supply chain is your contractual and commercial relationships. What do your clients' contracts require? What do your vendors' terms permit or restrict? What role do you play: did you build the system, are you deploying someone else's, distributing it, importing it?
This is where our company's picture gets complicated. For the software they built and sell, they're a provider under the EU AI Act. For AI capabilities they've embedded from a third-party API, they might be a deployer. Their German hospital client's contract almost certainly requires specific data processing terms, security standards, and possibly AI governance artifacts. Their cloud provider's terms of service restrict how data can be processed and where. And contractual obligations are often the most immediately enforceable of the lot, because the consequence isn't a regulatory fine in three years, it's losing the client next quarter.
Commitments are what you've voluntarily signed up to. ISO 42001 certification. ISO 27001. SOC 2. Industry codes of practice. Public responsible AI statements.
Let's say our company holds ISO 27001 certification and has published a responsible AI statement on their website. Both are now commitments they need to track. A certification body will audit them against ISO27001 and their clients likely rely on it contractually. The responsible AI statement becomes a commitment because consumer protection law can enforce public claims. If your website says you conduct clinical AI validation and you don't, that's likely an issue.
Now, describing your aspects through these seven categories is the straightforward part. Any practitioner can do it, and most of the answers come from conversations with people who know the business. The harder question is: how do you know which regulations each aspect triggers? That's the other side of the match, and it's where expert interpretive work needs to come in. I'll come to that shortly, but first let me explain how aspects work at two levels.
Organisation first, then systems
Organisation-level aspects are properties of the business as a whole. They cascade to everything. For our Australian company, that means: Activity is clinical care, employment, and selling software products. Geography is Australia and EU. Sector is healthcare. Entity type is private SME. And so on. You describe these once and they establish your baseline compliance perimeter, everything that applies to you regardless of what any individual AI system does. And honestly, most of the heavy lifting happens there. Most regulation is triggered by what your business does, not by the characteristics of any specific system.
System-level aspects then extend that perimeter for a specific AI system. Say the company has a patient prioritisation tool. Its system-level aspects might include: processes health data, makes automated decisions about individuals, used in the clinical care activity. These are properties of that specific system that may bring additional obligations into scope, or activate specific provisions within artifacts that are already in the perimeter at the organisation level.
The practical payoff is that when a new AI system comes along, you don't start the entire scoping exercise from scratch. The organisation-level perimeter is already established. You just describe the system's specific aspects, and the additional obligations surface.
The other side: what does each regulation apply to?
So aspects describe your operating reality. But you also need to know, for each regulation or standard or contract, under what conditions it's relevant. Every regulation has scope provisions. Article 2 of the EU AI Act defines its territorial and subject-matter scope. Article 3 of GDPR defines its territorial scope. The Australian Privacy Act defines its application to organisations and agencies above a revenue threshold.
These scope provisions can be expressed as conditions drawn from the same seven categories. The EU AI Act applies when your geography includes the EU market and your supply chain role includes provider or deployer. GDPR applies when your data type includes personal data and your geography includes the EEA. The Australian Privacy Act applies when your geography includes Australia and your entity type meets the thresholds.
I think of these conditions as the applicability of an artifact or at a more granular level, each of the specific expectations within an artifact. They're the other side of the match. When your aspects match an artifact's applicability, that artifact is in scope for your organisation or your system. When they don't, it isn't.
The important thing here is that applicability is interpretive work. Someone with regulatory expertise has to read a regulation's scope provisions and translate them into structured conditions. That's skilled, careful work. But it only needs to be done once per artifact. Once done, it's reusable by every organisation that needs to figure out whether that regulation applies to them.
Let me show you what this looks like in practice. Go back to our Australian healthcare company. Their organisation-level aspects include: Activity is clinical care, employment, and selling software products. Geography is Australia, plus EU through the German client. Sector is healthcare. Data type includes health data and personal data. Entity type is private SME. Supply chain role is provider for their own software, deployer for the third-party AI they've embedded. Commitments include ISO 27001 and a public responsible AI statement.
Now match those against the applicability of the artifacts they might encounter. The Australian Privacy Act applies because Geography includes Australia. Done. GDPR applies because Geography includes EEA and Data type includes personal data. The EU AI Act applies because Geography includes EU and Supply chain role includes provider. The Therapeutic Goods Act applies because Activity includes clinical care and the software is intended to influence clinical decisions. State health records legislation applies because Sector is healthcare and Geography includes the relevant Australian state. ISO 27001 applies because Commitments includes it. The German hospital client's contract applies because it's a contractual artifact with applicability tied to that specific relationship.
Now I know, I'm making this look easy by glossing over the fact that someone had to determine those applicability conditions in the first place. "The Therapeutic Goods Act applies when Activity includes clinical care and the software is intended to influence clinical decisions" is a condition that required regulatory expertise to formulate. That interpretive work is real, and I'll come back to it in a moment. But the point here is that once it's been done, the matching is mechanical.
So that's the baseline perimeter from the organisation-level aspects alone. It already includes seven or eight major artifacts, from three jurisdictions, spanning privacy, health, AI-specific, medical device, and contractual obligations. And nobody had to sit down and read each regulation's scope provisions from scratch. The aspects surfaced the matches.
Now add a specific system. Say they have a patient prioritisation tool that processes health data, makes automated decisions about individuals, and is used in the clinical care activity. The system-level aspects bring additional expectations into scope within the already-applicable artifacts. The Privacy Act's new automated decision-making transparency requirements, commencing December 2026, are triggered by a system that uses personal information to make decisions that could significantly affect individuals' rights. GDPR Article 22 on automated decision-making is triggered. The EU AI Act's Annex III high-risk classification for AI systems used in healthcare is triggered. Each of these was already in the perimeter at the organisation level. The system-level aspects tell you which specific parts of those artifacts apply to this particular system.
I should be clear about something here. This exercise is fundamentally about interpreting legal obligations and exposures. I'm describing a method for structuring that interpretation, but the interpretation itself is not something a governance practitioner or an engineer should do alone. When I'm doing this kind of scoping work, I always work closely with a lawyer. Let me explain why.
Lawyers have resources and training that governance practitioners typically don't. When a lawyer reads a regulation's scope provisions, they're not just reading the text. They're using citators like WestLaw or LexisNexus that tell them whether a provision has been amended or whether courts have interpreted it in ways that change its practical meaning. They work with annotated codes that cross-reference related provisions across different statutes, surfacing interactions between frameworks that a non-specialist reading one regulation at a time would miss. And they have formal training in scope and extraterritorial reach analysis. Conflict of laws, the methodology for determining which jurisdiction's law applies when multiple jurisdictions are in play, is an entire legal discipline. The question of whether GDPR applies to our Australian company's processing of German patient data isn't one you want a governance practitioner answering from first principles.
So why not just hand the whole thing to the lawyers? Because in my experience, legal analysis on its own doesn't produce a governance-ready output. Lawyers tend to work artifact-by-artifact: a privacy lawyer does the GDPR analysis, an employment lawyer does the Fair Work Act, a health regulatory specialist does the TGA work, each producing a separate opinion. Nobody synthesises them into a unified view of what the organisation needs to do for a specific AI system or communicates them succinctly to engineers building the software. That synthesis is the governance practitioner's job. The aspects model provides the structural layer that sits above the legal analysis: here are the characteristics that determine what applies, now let the lawyers do the precise interpretive work within each applicable artifact, and connect the outputs back into a unified view through expectations and controls.
I would also acknowledge that applicability isn't always as clean as a match/no-match. Does a clinical decision support tool that informs but doesn't direct a clinician constitute a "medical device" under the Therapeutic Goods Act? Does an AI system that produces scores that a human reviews before acting constitute "automated decision-making" under GDPR Article 22? These require legal interpretation, and awareness of court decisions. In practice, you need a third category alongside "in scope" and "not in scope": something like "potentially in scope, get legal advice on your specific facts." That third category is probably where a lot of the interesting systems live, and it's where the partnership between governance practitioners and lawyers matters most.
Wrapping up
The compliance scoping I've described here answers a specific question: what sources of external expectations are applicable to my organisation and its systems? It doesn't tell you what those expectations require you to do in practice, and it doesn't tell you where the gaps are. Those are the next steps, and I'll go through them in another article. But you can't do either without first knowing what's in scope.
What I haven't covered is the harder and more time-consuming work: taking each in-scope artifact and decomposing it into specific expectations, then mapping those to controls. What does GDPR actually require you to demonstrably do? Not "comply with GDPR," that's not actionable. What are the specific expectations, at the right level of granularity, that translate into evidence you need to produce and mechanisms you need to operate? That decomposition is a craft, and I'll walk through how I approach it in the next article. And then having done the scoping and the decomposition, time consuming work but , I'll walk through how you can run a rapid compliance gap analysis in days rather than months.
One thing to be aware of: this scoping is not a one-off exercise you do perfectly and then file away. You'll miss aspects. You'll discover systems you didn't know about. Regulations will change. New client contracts will arrive with new requirements. The scoping has to be a living picture that you refine as you learn more about the business and its systems. I find it's better to scope quickly and roughly, then iterate rather than to pursue completeness and never finish.
Subscribe to our newsletter!
Our Doing AI Governance newsletter features the latest in AI Governance news, research and expert insights.