The EU AI Act: What Australian Software Exporters Must Do Now
The EU AI Act applies to Australian software and AI vendors selling into Europe, regardless of where they are headquartered. This post explains how the risk tiers work, what high-risk obligations actually require, and a practical compliance path for Australian exporters.
The EU AI Act: What Australian Software Exporters Must Do Now
The EU AI Act is now in force, and its reach extends well beyond European borders. If your Australian software or AI product is used by customers in the EU — or if you're planning to expand into European markets — the Act applies to you, regardless of where your company is headquartered. This post breaks down what the legislation actually requires, how the risk tiers work, and where to start if you haven't begun yet.
What Is the EU AI Act?
The EU AI Act is a comprehensive regulatory framework adopted by the European Union that establishes binding obligations for the development, deployment, and placing on the market of artificial intelligence systems. It came into full legal effect in August 2024, with obligations phasing in across 2024 and 2025. It is the first major binding AI regulation of its kind globally.
The Act takes a risk-based approach, categorising AI systems into tiers — from minimal risk through to prohibited practices — and assigning obligations proportionate to potential harm. The higher the risk your system poses to people's rights, safety, or livelihoods, the more rigorous the compliance requirements.
Does the EU AI Act Apply to Australian Companies?
Yes, with a clear condition: if your AI system is placed on the EU market or its output is used within the EU, the Act applies — regardless of where the provider is located.
The Act's extraterritorial scope mirrors the approach taken by the EU's GDPR. An Australian SaaS company selling into European businesses, an AI-powered platform used by EU consumers, or a model integrated into a European partner's product can all fall within scope. The key test is whether the output of your AI system affects people or organisations in the EU.
If you export software into Europe or have EU-based customers, you cannot treat this as someone else's problem.
Understanding the Risk Tiers
The Act classifies AI systems into four broad categories. Understanding where your product sits determines almost everything about your compliance obligations.
Unacceptable Risk (Prohibited)
Certain AI practices are outright banned. These include systems that use subliminal manipulation to distort behaviour in harmful ways, exploit vulnerabilities of specific groups, enable real-time biometric surveillance in public spaces by law enforcement (with narrow exceptions), and social scoring by public authorities. If your product falls here, it cannot be deployed in the EU, full stop.
High Risk
High-risk AI systems are permitted but subject to the most demanding obligations. The Act specifies categories that qualify as high risk, including:
- AI used in critical infrastructure management
- Systems influencing access to education or vocational training
- AI used in employment, worker management, or recruitment
- Systems involved in essential private and public services (credit scoring, insurance risk assessment)
- AI used in law enforcement, migration, or border control contexts
- AI that assists in the administration of justice
For Australian exporters, fintech, healthtech, HR technology, and legal tech products are the categories most likely to fall here.
Limited Risk
Systems with specific transparency obligations — primarily chatbots and synthetic content generators — must disclose to users that they are interacting with an AI. This is a lower burden but still a binding obligation.
Minimal Risk
Most AI applications — spam filters, AI-powered search ranking, recommendation engines — carry minimal or no specific obligations under the Act. Voluntary codes of conduct are encouraged but not mandatory.
| Risk Tier | Examples | Key Obligations |
|---|---|---|
| Prohibited | Social scoring, subliminal manipulation | Cannot be placed on EU market |
| High Risk | Credit scoring AI, HR screening tools, medical devices | Conformity assessment, documentation, human oversight, registration |
| Limited Risk | Chatbots, deepfake tools | Transparency disclosure to users |
| Minimal Risk | Spam filters, recommendation engines | Voluntary codes only |
What Do High-Risk Obligations Actually Require?
If your product is classified as high risk, the compliance requirements are substantial. They are not optional extras — they are preconditions for placing your system on the EU market.
Technical Documentation
You must maintain detailed technical documentation describing the system's purpose, design, training data, performance characteristics, and known limitations. This documentation must be kept current and available to regulators on request.
Conformity Assessment
Depending on the system category, you may need to undergo a conformity assessment — either a self-assessment against the Act's requirements or a third-party assessment by a notified body. The assessment must be completed before the system is deployed in the EU.
Data Governance
Training, validation, and testing datasets must be subject to documented data governance practices, including bias examination and relevance checks. If your model was trained on data with gaps or representational problems, that needs to be documented and addressed.
Human Oversight
High-risk systems must be designed to allow meaningful human oversight — the ability for a human to monitor, intervene, and override outputs. This is a design and architectural requirement, not just a policy statement.
Transparency and User Information
Users and deployers of high-risk systems must receive clear information about the system's capabilities and limitations, including circumstances where outputs should not be relied upon without verification.
EU Representative and Registration
Non-EU providers placing high-risk AI on the EU market must appoint an authorised representative established in the EU. High-risk systems must also be registered in the EU database for AI systems before deployment.
What's the Timeline?
The Act's requirements are phasing in rather than applying all at once. Prohibited practices became enforceable in February 2025. Obligations for general-purpose AI (GPAI) models apply from August 2025. High-risk system requirements take full effect from August 2026, with some categories having extended timelines. Fines for non-compliance can reach €35 million or 7% of global annual turnover for the most serious violations.
For Australian exporters, 2025 is the year to assess, design, and build compliance into your systems — not to wait and see.
The Intersection With Australian Privacy Law
Australian software exporters must consider both the EU AI Act and their obligations under Australian privacy law simultaneously. The Australian Privacy Act 1988 and the Australian Privacy Principles (APPs), administered by the Office of the Australian Information Commissioner (OAIC), govern how personal information is handled domestically. For products that process personal data of EU individuals, the GDPR also continues to apply in parallel with the EU AI Act.
Compliance with the APPs does not satisfy GDPR or EU AI Act requirements — they are separate frameworks with different mechanisms and scope. A compliant Australian data handling practice may still fall short of what the EU requires, particularly around data subject rights, consent standards, and the specific data governance obligations attached to high-risk AI systems.
If your product handles personal data and uses AI to make or influence decisions about people, you are operating at the intersection of all three frameworks.
A Practical Compliance Path for Australian Exporters
Compliance with the EU AI Act is a genuine engineering and governance challenge, not just a legal checkbox exercise. Here is a reasonable starting sequence.
Step 1: Classify Your Systems
Map every AI component in your product — models, automated decision tools, generative features — against the Act's risk tiers. Be honest about what your system actually does. A credit risk model that influences lending decisions is high risk even if you call it a "recommendation engine".
Step 2: Assess Your Data Practices
For any system that may be high risk, audit your training data provenance, labelling practices, and bias testing history. Document what you have and identify gaps. This intersects directly with your data infrastructure maturity — poor data foundations make compliance much harder.
Step 3: Review Your System Architecture
Human oversight requirements are architectural. Review whether your system is designed to support meaningful intervention — not just in theory, but in the actual user experience and API design. If your system makes automated decisions without a credible override mechanism, that needs to change.
Step 4: Build Technical Documentation
Begin building the documentation artefacts the Act requires: model cards, system purpose statements, risk assessments, and performance evaluations. Treat these as living documents, not one-off exercises.
Step 5: Identify Your EU Representative Requirement
If your system is high risk, determine whether you need an authorised EU representative and begin that engagement. This is a relationship, not just a legal appointment.
Step 6: Embed Compliance Into Development Process
Compliance is not a one-time audit — it requires ongoing monitoring, incident logging, and documentation updates as your system changes. This is where AI engineering practices matter: building observability, model monitoring, and change management into the development lifecycle from the start.
How AI Product Strategy Shapes Your Compliance Posture
The most important compliance decisions are made early — at the product strategy and architecture stage, not after you've shipped. Choosing which AI capabilities to build, which decisions to automate versus augment, and which markets to target all affect your risk classification and compliance burden.
If you're designing a new AI-powered product for European markets, building with EU AI Act obligations in mind from the outset is substantially less expensive than retrofitting compliance into an existing system. This is exactly the kind of decision that should be part of your AI product strategy — understanding the regulatory environment is as important as understanding the technical feasibility.
What Australian Exporters Often Get Wrong
A few common misconceptions worth addressing directly.
"We're a small company — it won't apply to us." The Act's scope is based on where your AI system is used, not your company size. Micro-enterprises have some reduced procedural obligations in limited areas, but the substantive requirements for high-risk systems apply regardless of revenue or headcount.
"Our EU customer is responsible, not us." The Act distinguishes between providers (those who develop or place AI systems on the market) and deployers (those who use them). As the developer, you carry provider obligations. Your EU customer's obligations as a deployer sit alongside yours, not in place of them.
"We'll deal with it when regulators come knocking." EU member states are establishing national market surveillance authorities. The registration requirements and conformity assessments are preconditions for lawful deployment, not post-hoc obligations triggered by enforcement action.
Starting Points
If you're an Australian software business with EU customers or EU market ambitions, the practical starting point is an honest classification exercise. Understand what your AI systems actually do, where they sit in the risk tiers, and what documentation and architectural work would be required to meet high-risk obligations if that's where you land.
For growing technology companies building or scaling AI products, this is also a useful moment to revisit broader AI product strategy — ensuring that regulatory requirements are treated as design inputs rather than compliance afterthoughts.
For more on building AI systems that are production-ready and defensible, explore our insights on AI engineering, data infrastructure, and AI product strategy.
If your team is working through EU AI Act classification and wants a technically grounded view of what compliance means for your architecture and product roadmap, we're happy to start that conversation. No pressure, no 200-page deck — just an honest discussion about where your product sits and what the path forward looks like.
Chris Kerr
Partner at Horizon Labs, an AI product consultancy and venture studio. A commercially focused product and technology leader with 20+ years building and scaling digital platforms, teams, and businesses across SaaS, travel, eCommerce, logistics and transport, and digital marketing — operating at the intersection of product, engineering, and data. Writes about platform strategy, AI transformation, modern data ecosystems, and the operational discipline that separates AI demos from AI products.
