Data governance for the AI era: residency, retention and audit trails

Most mid-sized organisations now have an AI policy. Far fewer could show a regulator which customer records went to which model last March, or prove that those copies have since been deleted. One attendee at an October data and AI leaders summit came away saying that most mid-market AI governance would not survive a regulator’s request.

This post covers the governance layer under the rest of the AI-Ready Data and Integration series. It deals with classification, Australian residency, vendor contracts, retention and audit evidence. The aim is a set of controls that fits on one page and that staff will follow.

Classify the data before you choose tools

Most organisations start by asking which AI sites employees are using. Practitioners discussing controls that work argue the primary question should be “what data were they about to send?”, and they name source code, credentials and customer PII as the categories to classify. That moves the control from a blocklist of domains onto the data.

Four tiers are enough for most mid-sized organisations:

• Public: published material and marketing copy. Any approved AI tool may use it.
• Internal: policies, meeting notes, internal documentation. Approved enterprise tools with no-training terms.
• Confidential: customer personal information, contracts, financials, source code. Only approved tools hosted in Australia, with every call logged through the gateway described below.
• Restricted: credentials and secrets, sensitive information as the Privacy Act defines it (health, for example), tax file numbers, board papers. No AI processing unless a specific system has been designed, reviewed and signed off for that data.

Attach the tier to systems and datasets so nobody has to label individual files. The CRM is Confidential, the HR system is Restricted and the intranet is Internal. A data owner signs off each assignment once, and any new integration inherits the tier of its source.

Residency: where the prompt goes

Under Australian Privacy Principle 8, if you disclose personal information to an overseas recipient you generally stay accountable for what that recipient does with it. If a prompt containing customer details goes to a model hosted overseas, it is likely to count as a cross-border disclosure, and your privacy policy and collection notices need to reflect that.

The major cloud providers host models in Australian regions. Residency is more than picking a region in a dropdown, though. Confirm that inference runs in Australia. Then check separately where the provider keeps prompt logs, abuse-monitoring copies and any cached content, because those can be stored in a different place from where the model runs.

This has a cost. New models can reach Australian regions some time after they launch in the United States. For Confidential data, you choose between waiting and using an older model that is available locally. We think that is usually an easy call, but write it down as a decision so it does not get remade each time a new model ships.

No-training guarantees belong in the contract

When a model has been trained on personal data, getting that data back out is very hard. A deletion request cannot reach into model weights, and commenters in one privacy discussion point out that a harm like a model memorising personal data is hard to unwind once training has happened. The only workable protection is to stop it happening, and that is a contract matter.

Consumer terms and enterprise terms from the same vendor often differ, and the free app on a staff member’s phone usually falls under consumer terms. For every AI vendor that may receive Internal or higher data, the contract should cover:

• No use of inputs or outputs to train or improve models, including by sub-processors.
• A stated retention period, in days, for prompts and outputs, abuse-monitoring copies included, and what happens to them when it ends.
• Named processing and storage regions, with notice before any change.
• A current list of sub-processors.
• Breach notification quick enough for you to finish a Notifiable Data Breaches assessment within the 30 days the scheme allows.
• Deletion on termination, with written confirmation, covering fine-tuned models and vector stores the vendor holds for you.

Retention: AI makes extra copies

APP 11.2 requires you to destroy or de-identify personal information you no longer need, subject to exceptions such as legal retention requirements. AI systems create copies that existing retention schedules rarely list:

• prompt and response logs, in the application and in the gateway
• chunks and embeddings in vector databases
• evaluation sets and test fixtures built from real records
• fine-tuning datasets
• vendor-side logs

Every copy should inherit the tier and retention period of its source. Deletion is where this most often breaks down. When a customer record is deleted from the CRM, its chunks in the vector index have to go as well. The simplest fix is to store the source record ID on every chunk and handle deletion as an event in the integration pipeline. Removing a record then becomes a query against the index, with no forensic search needed.

Audit trails that prove what reached which model

The most practical way to prove what data went where is to send every model call and every agent tool call through one gateway, and to issue no direct API credentials to anything else. Developers in the MCP community are building gateways that turn agent tool calls into audit-grade evidence, and the same pattern works for plain model calls. A record per call might look like this:

{
  "timestamp": "2026-10-19T09:42:11+11:00",
  "caller": "svc-case-summary",
  "user": "j.nguyen@example.com.au",
  "model": "provider/model-name@2026-08",
  "region": "australiaeast",
  "classification": "confidential",
  "source_records": ["crm:contact:48213", "crm:case:99102"],
  "tools_called": ["crm.read_case"],
  "prompt_sha256": "9f2c41...",
  "policy_decision": "allow",
  "policy_rule": "confidential-au-region-only",
  "human_review": { "reviewer": "a.smith", "at": "2026-10-19T10:05:00+11:00" }
}

For Confidential and Restricted data, log record IDs and a hash of the prompt instead of its full text. Otherwise the audit log becomes another copy of the data with weaker access controls. The trade-off is that a hash only proves what was sent if you can rebuild the prompt from the source records and the template version, so version your templates.

The policy_rule field matters. Commenters on the summit thread point to rule-based governance engines built on Cedar and Datalog, which decide from explicit rules and so produce an explainable trail. “Allowed under rule confidential-au-region-only” gives an auditor far more than “allowed”.

Where an AI output feeds a decision about a person, record who reviewed it and when. Practitioners are already asking how to evidence human review before an auditor asks, and capturing it at the time costs far less than rebuilding it later.

Controls that get followed

Practitioners report that blocking every AI domain fails because staff paste the same data into ChatGPT on their phones. An approved tool that does the job well enough removes most of the reason to work around policy.

For agents, one practitioner suggests securing the data instead of trying to track every agent. You will never have a complete list of agents, but each one needs a credential to reach the billing database. In the same thread, others describe blocking every exit path so an agent can read data but cannot send it anywhere without approval, and they prefer runtime controls that block over tools that only raise an alert.

The one-page version:

1. Four classification tiers, assigned to systems and signed off by data owners.
2. An approved tools list stating the highest tier each tool may receive.
3. The contract checklist above, applied to every AI vendor.
4. All model and agent calls go through the gateway, and nothing else gets AI API credentials.
5. Agents run on scoped service credentials that are read-only by default, with outbound paths blocked unless approved.
6. AI copies inherit the retention of their source, and deletions flow through to vector indexes.
7. Each quarter, pick five random gateway records and trace each one from source system to deletion.

What it costs and where it falls short

The gateway is real engineering work, and it sits on the critical path for every AI feature, so it needs production-grade monitoring and failover. The audit log holds sensitive metadata and needs its own access controls and retention period. Classifications drift as systems change, which is why the quarterly trace exists. An approved tool will reduce personal phone use without ending it. Keeping Confidential data in Australian regions will sometimes mean using a model a generation behind. For most mid-sized organisations these costs are smaller than the cost of failing to answer a regulator’s question about where customer data went.

PicNet builds production AI systems for Australian organisations, and governance controls like these are part of that work. If you are planning a first AI project, talk to us about what it could look like.