Executive Summary
In short:
- From 10 December, organisations will be required, under new Australian Privacy Principles (APPs) 1.7–1.9, to include information about automated decision-making in their privacy policies.
- The legal drafting is the easy part. The hard part is finding out which of your systems make, or heavily influence, decisions about people, and what personal information they use.
- Scattered databases, unmapped integrations and inconsistent records are what make that discovery slow. They are engineering problems, and they need engineering answers: data engineering, database development, data cleansing and migration, and integration mapping.
- This guide gives you a ten-step checklist, a working timeline back from the deadline, and advice on choosing a delivery partner (including how to spot the "AI cowboy").
What's next?
At the time of writing you have about ten weeks. This month, list every system that scores, filters, approves, prices or prioritises people, then take that list to your legal adviser and a technical partner.
You Can't Disclose What You Can't See
Ask most executives whether their business uses automated decision-making, and the answer is usually "no".
Ask their operations team, and a different list appears. There is the loan pre-screening rule, the recruitment filter, the fraud flag, the customer-priority score, the pricing engine, and the AI tool someone connected to the CRM last quarter.
From 10 December 2026, the Privacy Act requires businesses covered by the Australian Privacy Principles (APP entities) to say so in their privacy policy. If your data sits in disconnected systems, that is a harder sentence to write than it sounds.
Why Ten Weeks Is Tighter Than It Looks
Most businesses assume this is a quick policy edit. Four realities suggest otherwise.
1. The scope is broad. The OAIC's Issues Paper, released on 18 May 2026, treats "computer program" as covering pre-programmed rule-based processes, machine learning, everyday business software, apps, word processing tools and generative AI chatbots. That is wider than "AI".
2. Human review may not get you out of scope. The obligation captures not only fully automated decisions but also scenarios where a computer program recommends or guides a human decision-maker, provided the program's role is both "substantially" and "directly" related to the decision.
3. Enforcement tools exist. The OAIC's powers to issue infringement notices and compliance notices apply to a failure to have a privacy policy that meets APP 1.7, and civil penalties can also apply. A statutory tort for serious invasions of privacy has also applied since June 2025.
4. The regulator's guidance may arrive late. The OAIC intended to release guidance by September 2026. Law firm commentary warns that the limited time between the expected release of the guidance and the deadline means delaying action until after the guidance puts meeting the deadline at risk. Check the OAIC website for the current status.
The real risk is not that your policy is missing a paragraph. It is that the paragraph you publish doesn't match what your systems actually do.
What the ADM Obligation Actually Requires
What is the ADM transparency obligation?
It is a disclosure duty. It does not ban automated decisions, and it does not (unlike the European GDPR) give people a general right to opt out of them. Australia's regime is transparency-based, whereas the GDPR is rights-based.
When does it apply? Three criteria must all be met. The entity must have arranged for a computer program to make, or substantially assist with, a decision. The decision must reasonably be expected to significantly affect an individual's rights or interests. Personal information must also be used in the program's operation.
What must your privacy policy say? Disclosure must cover the kinds of personal information used, the kinds of decisions made solely by the program, and the kinds of decisions where the program does something substantially and directly related to making the decision.
What is outside the net? The Explanatory Memorandum indicates that word processing and basic calculation tools are generally not substantially and directly related to making a decision. A spreadsheet that adds numbers is different from a scoring model that ranks applicants.
Where does the OAIC look for the line? In its Issues Paper, the OAIC asked for views on factors such as the degree of reliance on the output, the likelihood of human override, whether the output is advisory or determinative, explainability, and how the tool is integrated into the workflow. Notably, the OAIC has also flagged third-party ADM as a focus area.
Is Your Business in Scope? Practical Examples
The following systems are worth reviewing. Whether each one is caught is a legal question, so treat this as a prompt for your inventory, not a conclusion.
- Finance and lending: pre-approval rules, credit or affordability scoring, fraud flags.
- HR and recruitment: CV screening, shortlisting, rostering, performance scoring.
- Customer operations: ticket or call prioritisation, churn or eligibility scoring.
- Pricing and insurance: dynamic pricing, underwriting rules, claims triage.
- AI tools: chatbots, copilots and embedded AI features inside software you already licence.
The 10-Step Data Engineering Checklist
Steps 2 to 8 are where data engineering, database development, data cleansing and migration, and integration do the heavy lifting.
Step 1: Confirm your obligations (legal)
Ask your privacy lawyer whether you are an APP entity and which decisions may be in scope. Small business exemptions and reform proposals are still moving, so don't assume.
Step 2: Inventory every automated decision
List each system, rule, model or workflow that scores, ranks, approves, declines, prices or prioritises people. Include spreadsheets, macros, no-code automations and vendor tools. Assign a business owner to each entry.
Step 3: Map the data flows
For each entry, record which personal information goes in, where it originates, where the output goes, and who sees it. This data engineering discovery produces lineage documentation your legal team can rely on, and it gives you the "kinds of personal information used" the policy must describe.
Step 4: Audit your integrations
Modern businesses run on connections. Identify every integration, API, middleware layer and third-party AI service that touches personal information, including tools staff connected without IT involvement. This matters because the OAIC has acknowledged that the line between arranging for automated decision-making and merely operating it is unclear in complex supply chains. Our API and direct integration and enterprise application integration work often starts with exactly this kind of mapping.
Step 5: Cleanse and standardise your data
Duplicate, outdated or inconsistent records make decisions harder to explain and errors harder to trace. Data cleansing also lets you identify personal information you hold but no longer need. Less unnecessary data means a smaller footprint to describe and defend.
Step 6: Consolidate or migrate only where justified
Legacy platforms that can't show what data a decision used are a genuine risk. Data migration to a governed platform can create a single, traceable source of truth, but migration is not always the answer. Migrate what the business case supports, and test thoroughly. A rushed migration in the final weeks can create more risk than it removes.
Step 7: Build explainability into your databases
Good database development makes decisions reconstructable. Add decision logging, timestamps, versioned business rules, and audit trails. If someone asks how a decision was reached six months ago, your database should be able to answer. Our database development team designs for this from the start.
Step 8: Assign ownership and control access
Every decision system and dataset needs a named owner. Apply role-based access, and make sure someone is accountable for keeping records accurate.
Step 9: Give legal accurate facts
Hand your inventory and data flow maps to your legal team. They write the disclosure; your engineers confirm it is technically true. One caution from law firm commentary: hedging by over-disclosing backfires, because the more information included to hedge against non-compliance, the less comprehensible the policy becomes to the individuals it is designed to protect.
Step 10: Monitor and re-review
The obligation is not a one-off. Add a change process so any new tool that introduces or expands automated decisioning triggers a privacy review before release. Schedule a quarterly check that your policy still matches your systems.
A Realistic Timeline to 10 December
| Weeks |
Focus |
Output |
| 1–2 |
Discovery and inventory |
Register of automated decisions and systems |
| 3–4 |
Data flow and integration mapping |
Lineage maps and third-party list |
| 5–7 |
Cleansing, database and logging changes |
Cleaner data and audit trail for priority systems |
| 8 |
Legal review |
Draft privacy policy update |
| 9–10 |
Testing, sign-off and publication |
Updated policy live before 10 December |
Complex environments may not finish everything in ten weeks. If so, prioritise the highest-impact decisions first, document a plan for the rest, and be honest about what has and hasn't been covered. No provider can guarantee legal compliance by a deadline, and you should be wary of anyone who does.
Beware the "AI Cowboy": The Hidden Cost of Cheap AI App Builders
AI app builders have made it possible to produce a working prototype in an afternoon. For a demo or an internal experiment, that can be genuinely useful. The trouble starts when a prototype quietly becomes a production system that touches customer or employee data.
We call the risk the "AI cowboy": someone who generates an app quickly, hands it over, and moves on. Not every builder fits this description, but the pattern is common enough to be worth knowing.
Nobody can explain it. If the person who prompted the app can't say what data it uses, how it reaches outcomes, or which external services receive that data, you can't accurately describe it in a privacy policy.
Personal information may leave the building. Generated apps frequently call third-party AI services. Under the new obligation, that is precisely what you need to know.
There's no handover. When the app breaks, or the builder disappears, your team inherits code nobody understands.
There's no audit trail. Without decision logs, you can't reconstruct why an outcome occurred.
Security and maintenance are afterthoughts. Generated code still needs review, testing and ongoing support.
The cheapest option is rarely the cheapest once you count rework, risk and dependency. The key difference is knowledge transfer. A cheap builder gives you an app. A good partner gives you an app and the understanding to run, maintain, extend and explain it. C9 builds knowledge transfer into how we work, through documentation, walkthroughs and handover, so your team isn't locked into a black box.
Why C9 Is Different From the Hundreds of Other Developers
Australia has no shortage of developers. What separates one from another is how they work, who's behind the work, and what you're left with afterwards.
- A blended hybrid offshore and inshore team. You get local project leadership and communication, backed by a broader delivery team.
- Knowledge transfer, not dependency. We document and hand over what we build so you're never held hostage by it.
- Multiple resources, not a single point of failure. If one person is unavailable, your project doesn't stall.
- Depth and track record. C9 has operated for more than 18 years, across 350+ projects, 45+ services and 100+ technologies.
- Breadth under one roof. Database development, integration, custom software, LLM integration and data engineering and ongoing managed services are all available from one team, so your data, integrations and applications are designed together.
A question worth asking any provider, ours included, is where your data will be handled. The Privacy Act does not require data to stay in Australia, but most Australian regimes, including the Privacy Act and the Security of Critical Infrastructure Act, require organisations to manage risks associated with offshore storage, cross-border disclosure and third-party providers. A good partner will discuss this openly during scoping.
Staff Augmentation Options: Flexible Ways to Add Capacity
Not every business needs a fully outsourced project. If you have an internal team but lack capacity or specialist skills, staff augmentation lets you add people directly to your workstream. Details are on our Working with us page.
| Model |
Best for |
Commitment |
| Minimum term (3–6 months) |
Defined outcomes such as migration, cleansing, integration or platform builds |
Deeper continuity, lower ramp-up waste |
| Monthly rolling contract |
Short bursts, uncertain scope, temporary cover |
Maximum flexibility, less continuity |
| Part-time or fractional |
Ongoing support, maintenance, reviews |
Lighter and scalable |
More than a single developer. Augmentation with C9 isn't limited to one person. Depending on your needs, you can bring in an integrated team with complementary skills, such as database, integration and development capability, working together under coordinated delivery.
A remote-first model. C9 does not hire in-house local staff in Australia for augmentation. Team members work remotely, so you should not expect someone to arrive at your office for a nine-to-five day. Communication runs through agreed channels, scheduled check-ins and defined overlap hours.
Why a 3–6 Month Minimum Term Is Usually the Better Choice
A monthly contract is genuinely useful for short, well-defined needs. For data work, though, a 3–6 month minimum term usually delivers a better result, for six reasons.
- Ramp-up isn't free. Learning your systems, data quirks and business rules takes time. A longer term means more of the engagement is productive.
- Continuity protects quality. The people who do the discovery are the same people who build, so fewer details are lost between phases.
- Knowledge transfer needs time. Documentation and handover are best done properly, not squeezed into a final week.
- Budgets are predictable. A fixed-term engagement is easier to plan, approve and track.
- Teams work better together. A stable team communicates faster than a rotating one.
- Realistic scope. Cleansing, migration and integration rarely finish in four weeks.
If your need really is short and well defined, say so and we'll tell you honestly whether a monthly arrangement suits.
Frequently Asked Questions
What is the ADM deadline in Australia?
10 December 2026. From that date, APP entities must include information about qualifying automated decision-making in their privacy policies.
Does the obligation ban automated decision-making?
No. It is a transparency requirement. It requires disclosure, not cessation.
If a human approves the final decision, are we exempt?
Not automatically. The obligation can apply where a program's role is substantially and directly related to the decision, even if a person makes the final call. Get legal advice on your specific systems.
Can C9 guarantee our compliance by 10 December?
No provider can, and be cautious of anyone who says otherwise. C9 can help with the engineering work: mapping data flows, cleansing data, building audit trails and documenting integrations, so your legal team has accurate facts.
What is staff augmentation?
It means adding skilled external people to your existing team for a defined engagement, instead of hiring permanently or outsourcing a whole project.
Will C9 staff work in our office?
No. C9 augmentation team members work remotely. There is no expectation of on-site nine-to-five attendance, and collaboration happens through scheduled meetings and agreed channels.
Do we get just one developer?
Not necessarily. You can add a single specialist or an integrated team, depending on the work.
What is the minimum contract length?
Our preferred option is a 3–6 month minimum term, which suits most data engineering work. Monthly contracts are available for shorter or uncertain needs.
What happens to the knowledge when the engagement ends?
Knowledge transfer is part of how we work. You receive documentation and handover so your team understands what was built.
Get the Facts Straight First
The ADM obligation is fundamentally about honesty: saying accurately how your systems use personal information to influence decisions about people. Businesses that already understand their data will find it manageable. Those with scattered, undocumented systems face a discovery problem before they face a drafting problem.
The sequence matters. Confirm your obligations, inventory your decisions, map your data, cleanse it, make it explainable, then let your legal team write the disclosure. Doing this well leaves you with more than a compliant policy. You end up with cleaner data, clearer systems and better foundations for any AI you adopt next. We explore related foundations in our post on medallion architecture and AI-ready data pipelines.
Also keep watching the horizon. Further privacy reform is on the way, with a second tranche of proposals under consideration, and one law firm summary describes an exposure draft proposing 40 further changes. Data you can trace and explain will help under any of them.
What's next?
Book a short discovery conversation this month. Bring your list of systems that influence decisions about people, and leave with a clearer view of what to map, cleanse or rebuild first.
Not Sure Where Your Automated Decisions Live? Let's Map Them.
C9 combines a blended offshore and inshore team with genuine knowledge transfer, so you understand what's built and stay in control of it. We can help with data engineering, database development, data cleansing and migration, and integration, working alongside your legal adviser.
Discuss Your Business Challenge →
Or explore our Data Cleansing & Migration and Database Development services.
This article provides general information only and does not constitute legal advice. Obligations vary by organisation. Seek independent legal advice before making decisions about your privacy policy or compliance.
Sources and References
Regulator
Legal analysis
Broader context
AI Transparency Notice
This article was produced with the assistance of artificial intelligence tools, including research and content drafting. All content has been reviewed and approved by C9 prior to publication.