A European client emails and asks you to confirm your AI use complies with the EU AI Act.
You’re in Australia. No office in Europe, no European staff, and because of that you may be thinking that European law can’t reach you.
But it can.
The EU AI Act is not a toothless tiger that Australian businesses can simply ignore.
It is a real legal framework with real, business-ending consequences for non-compliance.
Think of it as the AI equivalent of the GDPR, but with sharper teeth.
The EU has a proven track record of enforcing its digital laws globally, and this Act carries maximum penalties of up to €35 million or 7% of global annual turnover, whichever is higher.
For many Australian businesses, a single penalty of that scale is a business death sentence.
This guide sets out to show whether the EU AI Act reaches your Australian business – and why it may matter even sooner than the legal deadline suggests.
I’ll cover two situations, because the Act treats them very differently:
- You use AI in your business – Tools, features, assistants – anything you didn’t build.
- You build AI into a product you sell – For example – you’re a startup shipping software with AI inside it.
While the obligations carry more weight for second situation, don’t think you’re off the hook because you’re only using AI, not selling it.
The EU AI Act isn’t bound by geography. It’s bound by who your AI affects.
Most people may assume European law only applies to European companies.
This one doesn’t work that way.
If your AI system’s output is used in the EU – a tool that ranks EU job applicants, a model that scores EU customers, a service EU users interact with – you can be in scope even with no European presence at all.
According to the Act, the Regulation applies to providers placing AI systems on the market or into service in the Union, irrespective of whether those providers are established in the Union or in a third country.
This mirrors GDPR, which caught plenty of Australian businesses the same way.
Telling regulators: “But we’re not in Europe” was not a credible defence then either.
First, work out which one you are: deployer or provider
This is the distinction that determines everything else:
A deployer uses an AI system – You bought it, or you subscribed to it, and you use it in your work. Your obligations are real but manageable – transparency, human oversight, using the tool as intended.
A provider builds an AI system and puts it on the market – Your obligations are substantially more detailed: involving risk management, data governance, technical documentation, logging, conformity assessment.
Here’s the trap, which seems to have caught a few startup founders I’ve spoken to:
You can become a provider without building a model.
If you plug into an API like OpenAI or Anthropic, or use an open-source model, you might assume you’re just a user.
But if you fine-tune it, materially alter its output, put your own name on it, or apply it to a specific high-stakes domain – such as HR, fintech, education – you may be legally classified as the provider of that system.
You absorb the liability, even though you’re not nearly on the scale of an OpenAI or Anthropic and you didn’t train a thing.
If you’re a startup using an AI model’s API anywhere in your product and selling it, by far the safest option is to assume you’re a provider until a lawyer tells you otherwise.
Does the Act apply to you? A quick and rough self-check
Give the following four questions some thought and answer honestly:
- Do you sell a product or service which may be used by anyone in the EU? Customers, users, members – anyone based there.
- Does it use AI? Including AI features inside tools you resell or embed, not just AI you built.
- Does the AI’s output reach an EU person? A decision, a score, a recommendation, generated content, a chatbot they talk to.
- Is it used for something consequential? Hiring, credit, education, access to services – anything affecting someone’s rights or opportunities points toward the “high-risk” tier, where the real obligations sit.
More “yes” than “no” means you’re likely affected by the act, or close enough that you can’t assume otherwise.
You should also note that this simply rough guidance and should not be taken as legal advice.
But it may give you an indication as to whether you need to assess your exposure in more detail (and if you’re reading this – you probably should).
What is defined as high risk AI?
The EU AI Act flags specific use cases where AI decisions directly impact a person’s life, career, or bank account.
If your business or product does any of the following, you are almost certainly operating in the high-risk zone:
- HR and recruitment – AI that screens CVs, ranks job applicants, targets job ads, or tracks employee workplace performance.
- Fintech and insurtech – AI used for credit scoring, assessing eligibility for a loan, or calculating insurance premiums and risk.
- Edtech – AI tools that score exams, grade student essays, or decide who gets admitted into a course or school.
- Biometrics – Software doing facial recognition, emotion tracking, or categorising people based on sensitive biometric data.
- Critical infrastructure – Embedded AI that optimises or controls physical networks like traffic lights, water systems, or renewable energy grids.
- Safety components – If your AI is built into a physical product already subject to strict EU safety checks – medical devices, machinery, smart toys.
Note that this catches deployers too, not just builders.
An Australian firm using an AI tool to screen job applicants in the EU is in the high-risk zone, even though someone else built the tool.
If you checked any of those boxes, now is the time to stop wondering. The deadlines for high-risk rules are approaching.
Book a chat with a technology lawyer sooner rather than later.
A small upfront outlay now beats a drawn-out legal process and company-destroying fine in a couple of years.
Two deadlines
So far, I’ve spoken mostly about the legal ramifications but if you’re operating in the EU in any capacity, you’re not just running against the regulatory deadline.
There are also commercial considerations to take into account.
- The legal deadline – Key obligations were set for August 2026, but a simplification package pushed high-risk duties to 2 December 2027 for stand-alone high-risk AI systems, and 2 August 2028 for high-risk AI systems embedded in products. Whether this changes again is unclear at the time of writing, but the deadline is real and approaching.
- The customer deadline – EU buyers are increasingly writing AI Act expectations into contracts and questionnaires. Suppliers are being asked to confirm compliance well before any regulator gets involved.
The customer deadline is the one that will probably hit your business first.
Even if you’re happy to live in denial and betting on the probability that an EU regulator may never question you, you should still be prepared when your EU customers do.
What “getting ready” actually looks like
While you don’t need to become an EU compliance expert, you do need to have answers ready for the following questions when they come:
- Where and how do you use AI? List every AI system and feature touching your product or your EU-facing work. (If you’re not sure, that might be due to Shadow AI).
- Does each AI use case have an owner? One person who can answer for what it does and what data it touches. Accountability is the spine of every framework, this one included.
- Have you assessed risks by consequence? How does your AI use touch EU people or customers? Which do something high-stakes? Those matter first.
- Do you have an AI register? What each system does, what data goes in, who owns it, what you’ve checked.
- Do you have proof? When a client or auditor asks, you can say: “Here’s what we use, here’s who owns it, here’s where we are, and here is the evidence”
At the very least, compiling your AI register is a low investment way to get a head-start on meeting regulatory requirements which only requires a spreadsheet or Notion file.
Starting your AI register
At its most simple, an AI register documents the lifecycle of your AI use. It should show:
- What the AI does – The system’s exact purpose, limitations, and intended use cases.
- What data goes in – The data ingredients, where they came from, and how they are cleaned.
- Who owns it – Clear accountability – who built it, who maintains it, who reviews it.
- What gets checked – The monitoring, bias checks, and guardrails in place.
- When and how – The schedule for regular audits, performance tests, and system updates.
- By whom – The specific roles responsible for signing off on safety and compliance.
Why DIY compliance is a risk
Starting an AI register in a spreadsheet is a great first step. But don’t rely on DIY compliance to protect your business.
Considering the stakes and the size of the penalties, if you have users, data, or clients in the Eurozone, book a chat with a specialised technology lawyer sooner rather than later.
Here’s why.
- The risk categories are tricky – The Act ranks systems from minimal risk to unacceptable risk. A lawyer needs to look at your exact use case to tell you where you land in a way that is legally defensible. Misclassify a high-risk feature and the fines are severe.
- The provider trap is easy to fall into – Plugging into someone else’s model doesn’t keep you safe. Alter the output, or apply it to a regulated domain, and you may absorb the full provider liability.
- Investor due diligence for startups – Sophisticated VCs will start asking for legal sign-off on AI compliance. A lawyer-approved framework makes you look professional and investable.
If you build AI into a product: assume you’re high risk until you’re sure you’re not
If you’re a startup or software companies shipping AI-enabled product, the safest option is to assume you’re high risk until you can definitively prove that you’re not.
The EU AI Act works on a sliding scale of risk, and the boundaries can be blurry. If you don’t know exactly what risk level your AI represents, don’t cross your fingers and assume you’re safe.
The safest rule of thumb: treat your system as high risk from day one.
It is vastly easier – and cheaper – to build documentation, data tracking, and guardrails into your product now, rather than trying to reverse-engineer compliance later when an auditor knocks on your door.
It also has added benefits. It helps future-proof your business if you decide to scale with AI in the coming years, and it encourages good habits around AI hygiene.
What assuming high risk looks like in practice
Five simple habits to build into your development workflow:
- Build a kill switch – Design the architecture so a human can instantly override, pause, or shut down the AI if it starts producing harmful, biased, or highly inaccurate output.
- Keep the training receipts – Document exactly where your training data came from, how it was filtered for bias, and how you prevent copyrighted or private personal information from slipping in.
- Log everything automatically – Set up system logs that track the AI’s operations, uptime, errors, and any instances where a human had to step in and correct its output.
- Write a plain-English user guide – Clear documentation for end-users explaining how the AI works, what its limitations are, and how they can review or challenge its decisions.
- Appoint a safety lead – Assign one person (even if it’s a member of the founding team) to own the AI safety mantle, ensuring risk reviews happen before every major deployment.
Why it’s worth getting ready now, regardless of your legal standing
Whether or not the EU AI Act legally binds your Australian business depends on specifics only you can check.
But the question underneath isn’t just legal. It’s commercial.
Your EU customers are deciding, right now, whether you’re a supplier who has their AI use handled safely, or one who carries too much risk to deal with.
It’s happening in Europe, and signs indicate it will be happening in Australia very soon too.
Being prepared means knowing what AI you use, who owns it, and being able to show proof when a customer or an auditor asks.
That’s worth having whether the law reaches you or not.