APP 11.2 reaches the data your AI vendor holds: the Australian obligation to destroy what you no longer need.
Important takeaways.
- APP 11.2 of the Privacy Act requires an APP entity that no longer needs personal information for any permitted purpose to take reasonable steps to destroy or de-identify it. The obligation is not limited to data on the entity's own systems.
- 'Holds' extends beyond physical possession. The OAIC's APP 11 guidelines state it covers any record the entity has the right or power to deal with, with outsourced storage as the worked example, so personal information sitting in an AI vendor's store is held by the fund.
- For data on a third party's hardware, the OAIC says reasonable steps include instructing the third party to irretrievably destroy it and verifying that this occurred, across all copies including archives and backups.
- From 13 May 2025 a US federal court ordered OpenAI to preserve and segregate all output log data that would otherwise have been deleted, expressly including deletions requested by users under privacy laws. The ongoing obligation ended as of 26 September 2025.
- When the order ended, logs already preserved stayed preserved, with a carve-out for requests originating in the EEA, Switzerland and the UK. Australia was not carved out, so Australian users' logs from that window remain under litigation hold in the United States.
- The APP 11.2 retention exception covers orders requiring the entity itself to retain information. A foreign order binding the vendor does not switch off the fund's obligation; it makes documented instruction, attempted verification and the vendor's written position the reasonable steps that remain.
Inside most funds, the data deletion question ends at the fund's own systems: the DMS is tidied, the mailbox policy runs, the file server archive has a schedule. The Privacy Act does not stop there. APP 11.2 requires an APP entity to take reasonable steps to destroy or de-identify personal information it no longer needs, and "holds" reaches records a vendor stores on the fund's behalf. For a credit fund using AI, that includes prompts, uploads and outputs sitting in an AI provider's retention window.
This guide answers the question for Australia. The mechanism it describes, a court in one country pinning data that a deletion policy said would disappear, is not jurisdiction-bound at all, and that is rather the point.
What APP 11.2 requires, and how far "holds" reaches.
Under APP 11.2 of the Privacy Act, an APP entity that holds personal information it no longer needs for any purpose permitted under the APPs must take such steps as are reasonable in the circumstances to destroy the information or ensure it is de-identified, unless the information is a Commonwealth record or the entity is required by or under an Australian law, or a court/tribunal order, to retain it. APP 11.3, which applies to information held from 11 December 2024, adds that those steps include technical and organisational measures.
"Holds" is defined in s 6(1): an entity holds personal information if it has possession or control of a record containing it. The OAIC's APP 11 guidelines are explicit that this extends beyond physical possession to any record the entity has the right or power to deal with, and the worked example is an entity that outsources storage to a third party while keeping the right to access and amend the data. On that reading, the personal information a fund's staff put into an AI tool, guarantor and director details in a credit paper, borrower contacts in a reporting pack, sits in a record the fund holds even though the store belongs to the vendor.
The OAIC's worked example is cloud storage.
The guidelines then say what reasonable steps look like when the record lives on someone else's hardware. Three passages carry the weight.
- An organisation must take reasonable steps to destroy or de-identify all copies it holds of the personal information, including copies that have been archived or held as backups.
- Where information is held on a third party's hardware, such as cloud storage, and the organisation has instructed the third party to irretrievably destroy it, reasonable steps include verifying that this has occurred. The same applies to de-identification.
- Where irretrievable destruction is not possible, the organisation should put the information beyond use: unable and unwilling to use or disclose it, no access for anyone else, surrounded by security controls, with a commitment to destroy it when destruction becomes possible.
Read against an AI stack, this is more demanding than it first looks. A vendor's published retention window does part of the work, but the obligation belongs to the fund, and so does the verification. Which features store what, and for how long, varies by endpoint and product on the same platform; our guide to what zero data retention actually covers walks through those clocks. A retention page is a starting point. It is not a record that destruction happened.
A US court held data that users had asked to delete.
On 13 May 2025, a magistrate judge in the Southern District of New York directed OpenAI to preserve and segregate all output log data that would otherwise be deleted, in the copyright litigation brought by The New York Times and other news plaintiffs. The order expressly covered data that would have been deleted at a user's request or because of privacy laws and regulations. For the next four and a half months, deletion mechanics that users and customers relied on did not run as described.
The ongoing obligation ended by stipulated order as of 26 September 2025. The end of it is as instructive as the start. Output logs already preserved stayed preserved, with one carve-out: logs corresponding to user requests originating from within the European Economic Area, Switzerland or the United Kingdom were released. Australia was not mentioned. Output logs from Australian users captured during that window remain in segregated tables in the United States, under litigation hold, whatever any retention page said.
Nothing here turns on OpenAI in particular. Any AI vendor of scale should be assumed to be, or to become, a litigant somewhere, and a discovery order in a foreign court can override its deletion mechanics for as long as the order runs. The mechanism has one clean corollary: data a vendor never stored cannot be pinned. What the arrangement covering your workflow actually stores is therefore the first question, not an afterthought.
The retention exception is narrower than funds hope.
APP 11.2 switches off where the entity is required by or under an Australian law, or a court/tribunal order, to retain the information. The words to notice are "the entity". A preservation order binding your vendor in a foreign court is not an order requiring the fund to retain anything. It does not relieve the fund of its obligation; it makes the vendor unable to complete the destruction the fund instructs.
The standard is reasonable steps, not strict liability, and that is where the position lands. A fund that has instructed destruction, sought verification, and recorded the vendor's written position, including a litigation hold the vendor cannot lift, has taken the steps reasonably open to it and can show its regulator exactly that. A fund that never asked cannot. The difference between those two funds is not what the vendor did. It is what the fund can produce.
What to put in place before anyone asks.
- A destruction map, per vendor surface. For each AI feature in use: what it stores, the documented retention period, who can trigger deletion, and what confirmation comes back. This is the destruction-side twin of the retention questions in the zero data retention guide.
- Contract terms that name it. Destruction on request and on exit, with verification, and the position of the vendor's own subprocessors. If the vendor cannot verify destruction, get that in writing too; it is what "beyond use" documentation is built from.
- A record of each instruction. Date, scope, confirmation received, or the vendor's stated inability and why. APP 11 asks for reasonable steps; records are how reasonable steps are demonstrated after the fact.
- A trigger tied to need, not to storage limits. The obligation runs from the moment the information is no longer needed for a permitted purpose, which is a decision about your workflows, not your vendor's disk.
The uncomfortable honesty in all of this is that where AI use grew tool by tool, nobody can produce the map. Where AI runs through a single layer that records which workflow sent what to which endpoint, the same questions are answered by reading the fund's own records, and the fund's answer to a regulator, an LP or its own board starts from evidence rather than a vendor's marketing page. The transparency obligations arriving in December make that capability more valuable again; see our guide to the automated decision-making disclosure rules commencing 10 December 2026.
Primary sources: the Privacy Act 1988 (Cth), s 6(1) and Schedule 1, APP 11, the OAIC APP 11 guidelines, the 13 May 2025 preservation order and the stipulated termination order filed 9 October 2025 in In re: OpenAI, Inc. Copyright Infringement Litigation. This guide is general information, not legal advice. It states the position as at the date above; check the current compilation and orders before relying on either.
Questions this guide answers.
Does APP 11.2 apply to personal information stored by our AI vendor?
Yes, where the fund holds it. Under s 6(1) of the Privacy Act an entity holds personal information if it has possession or control of a record containing it, and the OAIC's guidelines read that to include records the entity has the right or power to deal with, such as data in outsourced or cloud storage the entity can access or delete. Prompts, uploads and outputs containing personal information in an AI vendor's retention store fit that description, so the destruction obligation reaches them once the fund no longer needs the information for a permitted purpose.
What are reasonable steps to destroy personal information a vendor holds?
The OAIC's guidance is specific: instruct the third party to irretrievably destroy the information and take steps to verify that this has occurred, covering all copies including archives and backups. Where irretrievable destruction is not possible, the information should be put beyond use: not used or disclosed, inaccessible to others, surrounded by security controls, with a commitment to destroy it when possible. In practice this means a record of each instruction, the confirmation received, or the vendor's written explanation of why it cannot comply.
Can a foreign court stop our AI vendor deleting our data?
It has happened. On 13 May 2025 the US court hearing the New York Times copyright litigation ordered OpenAI to preserve and segregate all output log data that would otherwise have been deleted, including deletions users had requested under privacy laws. The ongoing obligation ended as of 26 September 2025, and the already-preserved logs were kept except those from the EEA, Switzerland and the UK. Australia had no carve-out. The order bound the vendor, not its customers, so an Australian fund's APP 11.2 obligation continued alongside a vendor that could not comply with deletion instructions for that data.
Does a vendor retention window satisfy APP 11.2?
It helps, but it is not the whole answer. Retention periods differ by feature on the same platform, deletion on schedule is not verification, and a litigation hold can suspend the published mechanics entirely. APP 11.2 also runs from when the fund no longer needs the information, which can be earlier than any retention window ends. The fund needs its own record of what each AI surface stores, who instructed destruction and when, and what came back.
Working with Levercon.
Levercon builds the AI operating system for credit funds: Fund OS connects a fund's own data into a knowledge layer, and Custom Agents run repetitive work across origination and monitoring. To talk to us, email info@levercon.ai.
This guide is general information, not advice. Factual claims that rely on public sources link to those sources in the text. Practical guidance also draws on patterns Levercon observes across Australian credit funds. No client is named and no figure is attributed to one. Written by Levercon, reviewed before publication and revised in place as the facts change.