The Notifiable Data Breaches (NDB) scheme has operated since 22 February 2018 under Part IIIC of the Privacy Act 1988 (Cth). It is not new, and it is not AI-specific. What has changed is the number of ways personal information now leaves an organisation, because AI tools have quietly widened every existing breach pathway at once.

This is a practical guide for the person who owns privacy or compliance: what the scheme actually requires, where AI use trips it, and what to have in place before an incident rather than during one.

What the NDB scheme requires

The scheme applies to APP entities: the agencies and organisations already covered by the Australian Privacy Principles. If you are subject to the Privacy Act, you are subject to the NDB scheme.

The obligation triggers on an eligible data breach. In the scheme's own terms, that is where there is unauthorised access to, unauthorised disclosure of, or loss of personal information that an entity holds, and a reasonable person would conclude the access, disclosure or loss would be likely to result in serious harm to any of the individuals to whom the information relates, and the entity has not been able to prevent that likely harm with remedial action.

When you suspect an eligible data breach may have occurred, you must carry out a reasonable and expeditious assessment, and the scheme expects that assessment to be completed within 30 days. If it is an eligible data breach, you must notify the Office of the Australian Information Commissioner and the affected individuals as soon as practicable, telling them what happened, what information was involved, and what they should do in response.

The OAIC publishes its Notifiable Data Breaches statistics twice a year, and across every report the two dominant causes are malicious or criminal attack and human error. AI sits directly on top of both.

Where AI trips the scheme

AI does not invent a new head of liability under the NDB scheme. It multiplies the ordinary ones.

Unauthorised disclosure: the paste problem

The most common AI-driven exposure is the simplest. A staff member pastes a customer list, a set of case notes, or a spreadsheet of personal information into a public chatbot to summarise or reformat it. That is a disclosure of personal information to a third party outside the organisation's control, and unlike an email to the wrong address it usually cannot be recalled. Whether any single paste rises to a notifiable breach depends on the serious-harm test, but the act itself is exactly the kind of unauthorised disclosure the scheme is built around.

The vendor breach that is legally yours

When an AI vendor, or an AI feature embedded in a SaaS product you use, suffers a breach that exposes personal information you are responsible for, the notification obligation does not sit with the vendor. It sits with you, the APP entity that holds the information. Contractual assurances from the vendor do not transfer the statutory duty. This is the same fourth-party exposure that operational-risk regulators have been pressing on, viewed through the privacy lens.

Loss and the widening attack surface

Every AI integration is another place personal information is copied, cached, logged, or transmitted, and therefore another place it can be accessed without authorisation or lost. AI-assisted phishing and social engineering also make the malicious-attack category, already the leading cause in the OAIC's figures, more effective.

Why shadow AI is a direct NDB exposure

The scheme's 30-day assessment clock assumes you can find out what happened. That assumption breaks when the tools involved are ones you did not know were in use.

If staff are using ungoverned AI tools, you cannot assess a suspected breach in them quickly, because you do not have visibility of what was entered, when, or by whom. You may not detect the breach at all. First-party data from organisations running our AI governance check shows how common this is: the large majority show signs of ungoverned AI use, and most report that confidential or personal information has probably or definitely gone into those tools. That is an unassessed NDB exposure sitting in plain sight.

This is the practical link between AI governance and privacy compliance. You cannot meet a 30-day breach-assessment obligation for a channel you have no inventory of.

What to have in place before an incident

The defensible position is unglamorous and entirely achievable:

  • An AI inventory. Know which AI tools are in use across the organisation, including the informal ones. You cannot govern, or assess a breach in, what you cannot see.
  • An acceptable-use directive. A clear, current instruction that personal and confidential information must not be entered into ungoverned AI tools, with sanctioned enterprise-grade alternatives that carry proper data-processing terms.
  • A breach-response plan that names AI channels. Your data breach response plan should treat AI tools as a first-class source of incidents, with a defined path to assess a suspected AI-related breach inside the 30-day window.
  • Vendor mapping. Know which of your AI and cloud vendors hold personal information you are responsible for, so that a vendor incident becomes a triaged notification decision rather than a scramble.

None of this requires new law or new tooling. It requires knowing where AI touches personal information before a regulator, an auditor, or an affected individual asks you to prove it.

The fastest way to see your own exposure is to map where AI meets personal information across the organisation. A free AI governance check will surface the shadow-AI and personal-information exposure that feeds directly into your NDB risk, in about fifteen minutes, with the answers staying in your browser.