Process CRE Deal Documents with AI: Compliance for Different Doc Types
A CRE deal pack is not one perimeter - it is a stack. Borrower documents under the APPs, provider data under subscriber contracts (Cotality and Archistar now name AI directly), and bureau reports under Part IIIA. What public AI tools sit outside, and what works in practice.
3 Categories for using CRE Deal Documents with AI
Part of the series: How to use AI with client documents in Australian real estate finance
General information, not legal advice. Current as at June 2026. Some of the analysis below is a reasoned reading of how Australian privacy law, the Credit Reporting Code, and standard subscriber-agreement terms interact when client data is pasted into a public AI tool. The application of these rules to AI use has not been settled by a court. Confirm anything load-bearing with your own privacy and contract counsel.
A broker drops a borrower's deal pack into Claude to get a first pass on the numbers. 20 minutes later they have a clean structured summary of the files, a per file understanding and financial details and a list of entities and individuals referenced in the documents. The instinct is to call it a win.
The question you never asked is where did the AI process the data, because it just travelled across the world. So what laws cover it, and what terms you agreed to when the documents in that pack originally landed on your desk. Because a data room is not one uniform thing. It is a stack of documents that come from different people, organisations, and research, under different terms and policies, with different rules about where they can go next.
This piece walks through what is actually in the pile, what each layer carries with it, and where the sharper edges sit.
What lands in the inbox of a CRE Finance deal
Three broad categories. They look the same in a folder; they behave very differently in law and contract.
Borrower-supplied documents. Contracts, financials, tax returns, bank statements, lease schedules, entity documents, the borrower's own valuation if they commissioned one, director financials, guarantor declarations. Anything the borrower or broker handed to you directly.
Third-party-information-provider documents. Credit reports from information providers such as Equifax, Experian. Property data from Cotality (CoreLogic), Archistar, or LandChecker. Title searches, ASIC company extracts, QS and independent valuation reports. Anything you obtained by paying a provider for information.
Individual identity documents. Drivers licences, passports and Medicare cards collected for VOI under the AML/CTF regime.
One pile to the broker. Three different perimeters in law.
Borrower-supplied documents: the Australian Privacy Principles
Borrower-direct documents that identify individuals (the director on the financials, the guarantor on the bank statements, the agent on the lease) are "personal information" under the Privacy Act 1988 (Cth) and are governed by the Australian Privacy Principles. Financial information is not on the closed list of "sensitive information" in the Act, but the full APP regime still applies.
The APPs that bite hardest when documents go into a public AI tool:
APP 5 requires you to notify individuals about the collection and its purposes, including whether their information is likely to be disclosed overseas. If Claude is connected to your inbox and reading every attachment from every counterparty, individuals named in those attachments have not been notified and probably did not consent.
APP 6 limits use of personal information to the purpose it was collected for. A guarantor's financial statement collected to assess credit was not collected to train, or be inferred by, a US-hosted general-purpose AI tool.
APP 8 governs cross-border disclosure. The moment you paste, upload or pipe personal information to a US-hosted AI tool you have disclosed it to an overseas recipient. Section 16C of the Act makes you accountable for the overseas recipient's handling of that information as if you had handled it yourself. A vendor breach, a prompt-injection extraction, a retention error, a subpoena on the other side all land back on your file.
APP 11 requires reasonable steps to protect personal information. Sending it to a tool you cannot audit, whose data retention you cannot verify, whose access controls you do not own and whose subprocessors you do not control is hard to reconcile with "reasonable steps". The OAIC's October 2024 guidance on commercially available AI products sets this expectation directly.
The statutory tort for serious invasion of privacy, in force from 10 June 2025, adds a separate route: every individual on the file now has a direct right to sue you, in their own name, with damages capped at the defamation cap, regardless of whether the OAIC ever takes an interest.
Information-provider documents: the contract layer
This is the layer most teams overlook, and it bites independently of the privacy regime.
When you subscribe to a credit bureau, a property data platform or any other paid information provider, you sign a subscriber or service agreement. The terms vary by provider, but the spine is consistent: information is supplied for a specific purpose, must not be re-sold or re-packaged, cannot be turned into derived products or analytics, cannot be transferred offshore without specific consent, and is subject to audit rights at your expense.
Two of the major property data providers in Australian CRE now go further and call AI out by name.
Cotality (formerly CoreLogic) prohibits AI use directly. Their current Terms and Conditions, clause A3.1(c), say users must not:
"input or upload the Cotality Services or Product Data or any portion thereof to any artificial intelligence (AI) platforms or large language models (LLMs)."
This is not "no derived analytics" inferred from a purpose-limitation clause. AI and LLMs are named. Dropping a Cotality property report into Claude or ChatGPT is a contractual breach on its face.
Archistar goes further again. Section 3.3(5)(xix) of their terms reads:
"Unless explicitly agreed otherwise by Archistar and the user in a signed written agreement or amendment, the user must not directly or indirectly use any of the information contained in the website or platform as (a) input into or to train any artificial intelligence or machine learning model or system, or (b) as input into, to calculate, to update or to tune any AVM (automated valuation model)."
Two things to notice. First, Archistar covers both training inputs and inference inputs - "summarise this for me" is caught, not only "train your model on this." Second, the AVM call-out matters for CRE. Even if a firm runs its own private AI internally and never touches a public LLM, feeding Archistar data into a custom valuation model is independently caught.
Equifax and Experian (which completed its $820M acquisition of illion in October 2024) operate under subscriber agreements that are not publicly inspectable, so the precise wording varies and the AI-specific language depends on which version of each agreement applies. The general purpose-limitation, no-re-use and offshore-restriction architecture is consistent across the bureaus' public-facing reseller and access-seeker terms; the addition of an explicit AI ban in line with Cotality and Archistar is the direction the industry is moving.
There is a permitted path - and the providers are starting to sell it. Cotality has launched a Cotality MCP Server, a paid product that connects their property data directly to AI models including Claude and ChatGPT through the Model Context Protocol. The legal contrast is exact: pasting a Cotality PDF into Claude is the prohibited activity at clause A3.1(c); using the Cotality MCP integration is the permitted path because it sits under a separate commercial arrangement with terms that contemplate AI use. Expect more providers to follow.
The consequence of a subscriber-terms breach is not always a regulator letter. It is more often loss of provider access, with the contractual liability that goes with it, and any cyber or PI insurer made aware that a contractually prohibited activity was the proximate cause of an incident.
Credit bureau data carries one extra layer
For data obtained from a credit reporting body specifically (Equifax, Experian following its acquisition of illion, TaleFin in their bureau capacity), Part IIIA of the Privacy Act sits over the top of everything above.
Important caveat: Part IIIA is mostly a consumer credit regime. Most CRE lending is commercial. A company or SPV is not a "consumer" and has no standing under Part IIIA in its own right. If the only data on file ever touched the borrowing entity itself, Part IIIA never enters.
What pulls it in is the people behind the deal. The director's consumer credit file you pull from Equifax to size up the principal. The guarantor's repayment history you check before signing them off. The bureau report on the director you keep on file for the duration of the facility. Those are individual consumer records, and they bring Part IIIA into the file even though the deal itself is commercial. Treat any bureau check on an individual director or guarantor as inside the regime.
What that actually means
Once a director's or guarantor's bureau report lands in your hands, three things tighten compared to the borrower-supplied document layer.
1. The "reasonable steps" cushion is gone. It is a closed list of permitted uses.
The APP regime works on a flexible "reasonable steps" standard. Part IIIA does not. Section 21G(1) says a credit provider holding bureau data must not use or disclose it, full stop, and section 21G(3) gives you a closed list of the things you are allowed to do with it. It is a locked door with a named set of keys, not a judgement call.
The one key that might fit "I want AI to summarise this" is the gateway for "processing an application for credit or managing credit." That gateway is narrow. A general-purpose AI summarisation step does not naturally fit unless the use is genuinely confined to processing that specific credit application.
2. The standard cross-border rule is switched off. A stricter one takes its place.
For borrower-supplied documents, APP 8 governs cross-border disclosure and offers a couple of escape valves: a "substantially similar law" shortcut (if the destination country has comparable privacy law), and a consent override (if the individual agrees).
For bureau data, APP 8 is switched off entirely (section 21G(7)). The replacement is section 21NA, and it is harder. You must take reasonable steps to ensure no breach before disclosing to a recipient without an "Australian link". Any breach by the offshore recipient is deemed to be your breach. And neither of the APP 8 escape valves is available - no "substantially similar law" shortcut, no general consent override.
In practical terms: putting a director's bureau report into a US-hosted AI tool (offshore, no Australian link) does not have a clean route through.
3. The Credit Reporting Code 2025 adds retention and destruction obligations on top.
The current Code commenced on 25 March 2025, replacing the 2014 Code. It layers active retention and destruction obligations onto the data once you hold it. Pasting it into a tool with retention you cannot control runs across this from a different angle.
Putting it together
Stack the three layers and the picture is straightforward: a director's consumer credit file pasted into a public US-hosted AI tool is hard to fit inside Part IIIA's permitted-use list, hard to clear its stricter cross-border test, and inconsistent with the standard subscriber agreement from the bureau that supplied it. Three layers, one paste.
This is a reasoned reading, not a position that has been tested in court. The safer reading - and the one a careful legal team will take - is that bureau reports on individuals stay inside the perimeter.
A word on APRA-regulated firms
Most readers of this piece will be in non-bank CRE lending, private credit, debt brokerage or fund management, and most will not be APRA-regulated. The paragraph below is for those who are: ADIs, insurers, and RSE licensees in the broader group, or anyone in the deal who is.
APRA's prudential standards CPS 234 (information security), CPS 230 (operational risk management) and CPS 220 (risk management) treat AI use the same as any other technology or third-party arrangement: it sits inside the operational risk framework, information security controls apply to it, and third-party AI vendors are third-party arrangements under CPS 230. The targeted CPS 230 amendments commence 1 July 2026, which makes third-party AI relationships especially live for anyone leaning on an external model. APRA's April 2026 letter to industry on AI governance is the clearest current signal of the standard regulators expect, even for firms that fall outside APRA's direct remit; ASIC's REP 798 and the licensee obligation to act efficiently, honestly and fairly carry the equivalent expectation across the rest of the system.
What works in practice
One operating pattern covers all three perimeters above without having to think about them deal by deal.
Keep deal documents inside an AI tool you actually control. In practice that means:
A written contract with the vendor, not click-through consumer terms on ChatGPT.com or Claude.ai
Hosted in Australia, or operated by an Australian entity
Your firm's own tenancy, not a pool shared with other customers
No training on your inputs - the model does not learn from what you feed it
No retention beyond the job - documents are not kept on the vendor's servers after the work is done
Every use is logged so the file can be audited later
Onshore is cleanest because the cross-border rules never engage in the first place. That single arrangement:
Closes the APP 8 cross-border issue for borrower-supplied documents, makes APP 11 defensible and makes APP 5 collection-notice disclosure honest.
Keeps you inside the purpose-limited, no-offshore, no-derived-analytics lanes that data-provider subscriber agreements run on.
Avoids triggering s21NA on any director or guarantor bureau file that sits in the deal.
Gives you the recordkeeping the private credit reforms now expect, and the documentation the 10 December 2026 automated decision-making obligation will need.
This is the case for sovereign AI sitting under the rest of the playbook. It is also why we build it the way we do.
The bottom line
A CRE deal pack is not a standard list of document, it is a stack of overlapping confidential information. Borrower-supplied documents carry APP obligations. Provider-supplied documents carry contractual obligations that are usually stricter than the APPs. Credit bureau data on a director or guarantor carries a Part IIIA overlay on top. APRA-regulated firms have prudential standards stacked over all of it.
A public, US-hosted AI tool sits outside every one of those perimeters at the same time. A contractually bound, onshore, controlled AI deployment sits inside all of them. The question is not whether the AI can do the work, but where the documents are while it does.
Want to see where you stand? Run through the checklist for using AI legally in Australia - the privacy obligations, the cross-border tripwire, the data-provider contractual layer, and the bureau overlay, mapped to the actual workflows on your desk.
This article is general information about Australian privacy and credit reporting law and standard subscriber-agreement terms. It is not legal or compliance advice. Confirm your obligations with your own advisers before relying on it.
Vanillah
We build simply satisfying software.
