When a team says there is no PII, the privacy question is not over. It may not even have started.
“No PII” sounds like an answer. In many data, security and AI conversations, it is treated like one: the dataset has no obvious identifiers, the system risk looks manageable, and privacy quietly moves out of the centre of the discussion.
PII is useful inside the frame it came from. It helps technical and security teams identify information that needs protection in systems. But it is not the legal test for whether privacy obligations apply in Australia, Europe or many other jurisdictions, and treating it as if it is can make an organisation sound more certain than it has any right to be.
The issue is what happens next. A technical label starts carrying a legal conclusion, and the organisation may stop asking the privacy question at the moment it should be asking it more carefully.
The Label Is Not The Legal Test
PII and personal data are not interchangeable concepts.
PII is an information-security term closely associated with US technical and government frameworks, including NIST. It has practical value in that setting because security teams need a workable way to identify and protect information in systems.
Personal data, and the Australian concept of personal information, do different work. They come from privacy law. They ask whether information is about a person, identifies a person, or can reasonably identify a person, depending on the regime. That legal frame determines whether obligations arise. An internal security label can sit beside that analysis, but it cannot replace it.
Teams often say there is no PII honestly. They may mean there is no name, address, passport number, Medicare number, account number or other familiar identifier in the dataset. They may also mean the data has been tokenised, aggregated, masked, transformed or separated from a direct identity field.
All of that may matter for security and risk reduction, but the legal question still has to be asked on its own terms.
The law does not follow the organisation’s internal label. It asks what the information is, what it can reveal, how it is used, what it can be connected with, and whether it is about people in the relevant legal sense. A security classification can help manage the dataset. It cannot do the privacy analysis by implication.
AI Makes The Shortcut Worse
AI and advanced analytics make the distinction harder to ignore because useful datasets often sit outside the narrow mental model of PII.
Teams can work with behavioural patterns, transaction histories, service interactions, device signals, location patterns, inferred traits and combinations of attributes without ever touching the identifiers they associate with PII. The data may still concern people in the legal sense that matters.
Once that data trains a model, shapes an output, ranks cases, triggers an intervention or influences how a person is treated, privacy is part of the use case.
“No PII” should create a pause, not comfort. Which legal frame is being used? Is the dataset personal information under the Privacy Act, personal data under the GDPR, or something else under the relevant regime? Does the use create inferences about people, or affect access, service, monitoring, escalation, pricing, eligibility, employment or treatment?
Security controls still matter, but they answer a different question. They may tell the organisation how well the dataset is protected; they do not answer lawful basis, purpose limitation, proportionality, transparency, secondary use or automated decision-making consequences.
An organisation can know how to protect a dataset and still misunderstand what it is legally allowed to do with it.
What Executives Should Not Let Pass
Boards and executives should not take “no PII” as a risk conclusion.
They should hear it as a clue about which frame the organisation is using. If the discussion stops there, the organisation may be governing the dataset as a security object rather than as information that carries legal meaning, social consequence and decision impact.
That distinction changes the shape of AI governance. Most consumer-facing AI use cases, and many enterprise ones, are still about people. Training data may reflect human behaviour, preferences, communications, transactions, vulnerability signals, workplace activity or service patterns. Outputs may shape experiences, interventions, opportunities, restrictions or decisions.
Regulators do not always need a wholly new theory of AI harm to act. Existing privacy law already gives them a frame when the issue is personal data or personal information.
This is the gap I would be looking for: whether the organisation is governing the legal use of information, or only protecting a narrower class of data inside systems.
Keep The Concepts Honest
A mature organisation does not need to choose between the security label and the legal test. It just needs to stop pretending they do the same job.
PII has value in the context it was built for. It helps security teams identify information that requires protection. Personal data and personal information do different work because they determine when data use attracts legal obligation and regulatory scrutiny.
The organisation needs both concepts, but it cannot afford to confuse one for the other.
For AI programs, the work is not complicated in theory, but it is uncomfortable in practice: teams need enough legal and privacy literacy to recognise when a dataset is about people, even if it does not look like the identifiers they are used to protecting. Without that literacy, organisations will keep telling themselves the privacy issue is absent when it has only been described in the wrong language.
The language matters because it shows which question the organisation thinks it has already answered.
If management is still using PII as the end of the privacy conversation, the board should assume the organisation may be approving AI use cases with the privacy question only half-asked.