By Karl Lehnert, Director, DevProStudio
The EU AI Act stopped being a distant policy story on 2 August 2026. That is when the Act became generally applicable and European enforcement moved into its operational phase. For an Australian SME, the uncomfortable question is no longer “does Europe regulate AI?” It is “can we prove what our AI system does, which data reaches it and who is responsible when it acts?”
This matters even if your office is in Brisbane or Perth. An Australian software business may sell into Europe, process data for a European customer, provide an AI-enabled feature used there, or depend on a supplier whose obligations flow down through contracts. The right response is not a 70-page policy copied from a multinational. It is a small, testable evidence system.
The European Commission’s current AI Act timeline says prohibited-practice and AI-literacy requirements applied from February 2025, general-purpose AI model obligations from August 2025, and transparency rules from August 2026. Some high-risk requirements have later dates. The dates differ because the obligation depends on your role and use case—not merely on whether a feature contains a large language model.
First decide whether you are in the chain
The Act distinguishes providers, deployers, importers and distributors. In practical terms, an SME that builds an AI feature under its own name faces different duties from a business that simply uses a third-party assistant internally. A company can also occupy more than one role across different systems.
Start with four questions:
- Is the AI system or its output offered or used in the EU?
- Do we build the system, put our name on it, or substantially modify it?
- Does it influence employment, education, credit, essential services, biometrics or another sensitive decision?
- Are we producing synthetic content that a person should know is machine-generated?
Do not let a vendor badge answer these questions. “Powered by” a compliant model does not automatically make your workflow compliant. The workflow may add private data, retrieval, business rules, human approvals and downstream actions that the model provider cannot see.
Build the minimum viable AI register
Our operator view is blunt: most AI governance programs start too late in the stack. Teams debate principles before they can list their systems. Build the register first.
For every AI use case, record its owner, purpose, users, geography, model or service, input data, generated output, connected systems, decision impact, human review point and retention arrangement. Add supplier terms and the date of the last review. A spreadsheet is acceptable at the start; an unowned spreadsheet that nobody updates is not.
This register becomes the index for your evidence. It should link to test results, risk decisions, data-flow diagrams, incident records and user disclosures. Keep the artefacts proportionate. A marketing-draft assistant and a recruitment-ranking system should not pass through the same review depth.
Use a three-lane implementation playbook
Lane 1: low-impact assistance
For summarisation, drafting and internal search, document approved inputs, access controls, retention settings, output review and the disclosure rule. Prevent staff from pasting sensitive information into unapproved tools. Give each tool an accountable business owner.
Lane 2: customer-facing AI
For chat, recommendations or generated content, add pre-release evaluation, failure handling, user notices and a route to a human. Test the whole application, not just a model in isolation. Record which version ran each evaluation so a model update does not silently invalidate the result.
Lane 3: consequential decisions
If AI affects hiring, credit, essential services or similarly sensitive outcomes, pause before shipping. Obtain specialist legal advice on role and classification. Design for human oversight, logging, data quality, risk management and contestability. The Commission identifies several of these areas as high-risk, with the current timeline listing Annex III requirements from 2 December 2027 and certain regulated-product requirements from 2 August 2028.
Transparency is an engineering requirement
The Commission says the Act’s transparency rules apply from August 2026. Users may need to know that they are interacting with a machine, while certain AI-generated material must be identifiable or labelled.
Treat this as product behaviour, not footer copy. Decide where a disclosure appears, what it says, which output types trigger it, and how it survives export or syndication. Then test it. If generated text moves from your application into an email campaign or knowledge base, the disclosure requirement should not disappear because the content crossed a system boundary.
For coding-agent workflows, transparency also means traceability inside delivery: preserve the human approver, relevant prompts or task instructions, code review and test evidence. The goal is not surveillance of developers. It is being able to explain how a change reached production.
Australian privacy duties still apply
EU readiness does not replace Australian obligations. The OAIC describes the Australian Privacy Principles as the cornerstone of the Privacy Act framework for covered organisations. If personal information enters an AI workflow, map collection, use, disclosure, overseas handling, security and retention against the APPs.
In practice, use least-privilege service accounts for connected business systems, restrict retrieval to the user’s existing permissions, separate test and production data, and log consequential actions. Confirm whether prompts and outputs are retained or used for model training. A data-processing term in a contract is useful; configuration evidence is better.
Australia’s Voluntary AI Safety Standard is also a sensible local control baseline. One evidence pack can support multiple frameworks: system ownership, risk assessment, data governance, testing, human oversight, incident response and supplier review. Avoid parallel compliance projects that ask the same team for the same evidence in different templates.
What should an SME budget?
There is no honest flat price for AI Act readiness. Scope effort by lane:
- Inventory-only: owner time to map systems, vendors, data and geography.
- Controlled deployment: engineering time for evaluations, permissions, logging, disclosures and incident handling, plus contract review.
- Potential high-risk system: specialist European legal advice, deeper quality and risk management, technical documentation, monitoring and independent assurance where required.
The penalty figures explain why classification deserves care, but they should not become marketing theatre. The Commission’s FAQ lists thresholds up to €35 million or 7% of worldwide annual turnover for certain infringements, with lower maximum calculations for SMEs. Your practical objective is not to calculate a hypothetical maximum fine. It is to show reasonable, current control over the systems you actually operate.
A common implementation pattern
This is a pattern, not a claimed client case study. A small SaaS team begins with a two-hour register workshop involving product, engineering, operations and privacy ownership. It identifies one internal assistant, one customer-facing generator and one automated decision-support feature. Each receives a lane, an owner and a short evidence checklist.
The team fixes the clearest gaps first: excessive API permissions, no model-version record, missing customer disclosure and an undefined incident owner. Legal advice is reserved for the decision-support feature because its market and impact create genuine classification questions. This sequence prevents a broad compliance project from blocking low-risk work while keeping consequential AI out of production until it is understood.
The next practical step
Do not begin with a claim that every system is compliant. Begin with a register that can survive one hard question from a customer: “show us how this AI feature uses our data and who can override it.”
DevProStudio helps Australian businesses turn that question into working architecture, controls and delivery evidence. If you need to map an AI application or redesign a risky workflow, contact DevProStudio.
Frequently asked questions
Does the EU AI Act apply to Australian companies?
It can. An Australian company may fall into the Act’s chain when it places an AI system or output in the EU market, serves EU users, or participates as a provider, deployer, importer or distributor. Confirm the facts and obtain European legal advice where exposure is material.
Is using a compliant model provider enough?
No. The provider covers only part of the system. Your application adds data sources, instructions, permissions, user experience, decisions and downstream actions. You need evidence for the complete workflow and your own role.
What should go in an AI system register?
Record the purpose, owner, users, geography, supplier and model, input data, outputs, connected systems, decision impact, human oversight, retention, tests, incidents and review date. Link each entry to supporting evidence rather than expanding the register into a policy archive.
Should a small business hire a lawyer first?
Start by mapping the systems and data so legal advice is focused. Engage a suitably qualified European adviser before deploying a potentially high-risk or prohibited use case, or when your provider/deployer role and territorial exposure are unclear.