The fastest way to get value from an AI tool in a finance function is also the fastest way to breach a confidentiality obligation. Open a chat window, paste the client's accounts, ask for an analysis, copy the answer into a working paper. It takes ninety seconds, it produces something useful, and in many cases it hands confidential financial information to a third party without authority, without a record and without anyone making a deliberate decision about it.

The technology is new. The obligation is unchanged. Professional confidentiality has always been about who receives information, and it does not distinguish between a person, a courier and a model provider. What has changed is how easy disclosure has become, and how invisible the transfer feels when it happens from a keyboard inside the office.

This guide sets out a practical framework for Australian accountants and finance teams. What data can go where, what a firm's AI policy needs to cover, when local and private inference is worth the effort, and what has to be recorded so that a number produced with AI assistance can still be defended.

The Obligation Follows the Data

Three separate regimes apply to client financial information in Australia, and they all point the same way.

The first is professional ethics. APES 110 Code of Ethics for Professional Accountants treats confidentiality as a fundamental principle. Information acquired through a professional relationship is not to be disclosed without proper authority, and the requirement applies to disclosure in any form. Using an external AI service to process client data is a disclosure of that data to the service provider, and the absence of a human reading it does not change what happened.

The second is the tax agent regime. The Code of Professional Conduct in the Tax Agent Services Act requires registered agents to keep client information confidential, again with no exception for new technology. A firm that sends client records to an unapproved service for convenience has a compliance question to answer regardless of the outcome.

The third is privacy law. The Privacy Act 1988 and the Australian Privacy Principles govern how personal information is handled, including how it may be used and disclosed and what happens when it is sent overseas. Client records routinely contain personal information, and under the notifiable data breaches scheme a serious breach carries reporting obligations to the Office of the Australian Information Commissioner and to affected individuals.

Read together, these rules produce a simple test. Before client information goes anywhere, someone at the firm should be able to answer who will hold it, under what terms, and whether the client would be surprised to learn about it. If those three answers are unclear, the data should not leave.

Data That Should Stay Inside the Firm

Some categories should be treated as off limits for consumer and general-purpose AI services without exception. The list below covers the material risks in a typical practice.

Unpublished financial results and forecasts are the clearest case. A set of accounts that has not been filed, a forecast that has not been shared with a lender, a valuation that is still being negotiated. This is material non-public information, and for listed-company clients the insider trading provisions of the Corporations Act make the point sharper than ethics alone.

Deal and transaction information belongs in the same category. A business that is being sold, an acquisition being considered, a term sheet under discussion, a due diligence file. These are the situations where a leak is most damaging and where the information is most sensitive, and they are also the situations where the temptation to paste documents into a chat window for a summary is highest.

Client identifying details are a separate problem from the financial content. Names, tax file numbers, bank account numbers, addresses and dates of birth are personal information with their own handling rules, and combining them with financial data makes the disclosure worse. A surprising amount of useful AI work can be done with those fields removed.

Anything received under a confidentiality agreement, express or implied, is off limits unless the terms allow it. So is information from a trust account, material from an incomplete audit or review, and correspondence with a client about a dispute, an ATO position or a legal matter.

The working rule behind all of these is that the sensitivity of the information matters more than the convenience of the task. A summary that would have taken twenty minutes is not worth a disclosure that took two seconds.

Data That Is Usually Fine, With Conditions

The other half of the framework matters just as much, because a policy that bans everything produces no adoption and drives the same work into unmonitored personal accounts.

Generic and public information is straightforward. Published financial statements, public market data, industry benchmarks, tax rates, ATO guidance, accounting standards, spreadsheet functions and formula syntax. None of this discloses anything to anyone who could not obtain it themselves.

Internal information that belongs to the firm carries lower risk. Templates with no client figures, a firm's own methodology documents, an internal checklist, a training example built with invented numbers. Using an AI tool to improve your own process documentation is not a client disclosure.

De-identified and synthetic data is the most useful middle ground. A client's revenue pattern with the name, the exact figures and the identifying industry specifics removed can often carry the full analytical point. So can a worked example built from round numbers. Where a task genuinely requires the shape of real data, rebuilding it as a representative example usually preserves the learning and removes the exposure.

Aggregate and statistical views can also be acceptable when the sample is large enough that no individual client is identifiable, though this is where care is needed. Averages over a small client base often identify the clients through arithmetic.

For anything that genuinely needs real client data and cannot be anonymised, the answer is a documented service with terms that fit the purpose, which brings the question to vendor arrangements.

Why Vendor Terms Differ

The single most common misunderstanding in this area is that all AI services are equivalent. The differences between them are contractual.

Consumer chat products are typically offered under terms that allow submitted content to be used to improve the service, with retention policies that vary and often no enterprise data processing agreement. That is a reasonable arrangement for the company's own use case and an unsuitable one for client financial information.

Business and enterprise agreements are the opposite. The standard commitments are that submitted data is not used to train the provider's models, that retention is limited or configurable, that access controls and audit logs exist, and that the provider's obligations flow through to sub-processors. Those commitments are the difference between a tool a firm can use on client work and one it cannot.

Two further questions decide most real cases. Where is the data processed and stored, and does that location change the privacy position for Australian clients? And can the firm obtain a record of what was submitted, by whom and when, if a client or a regulator asks? A service that cannot answer the second question is difficult to use on a deliverable that may be reviewed.

One useful reference point is Andrew Ng, the AI researcher who co-founded Coursera and led the founding Google Brain team. In an interview published in August 2026, he was unusually specific about how his own organisation handles the question. Hyperscaler terms are trusted for routine work. Material non-public information is kept off third-party AI entirely, regardless of vendor guarantees. Where the information is genuinely sensitive, the work runs in an environment the organisation controls. Firms that adopt roughly that structure, trusting properly contracted services for ordinary tasks and refusing to send the sensitive material anywhere, will avoid most of the failures that matter.

What a Firm's AI Policy Should Actually Contain

A policy that lives only as a principle is not actionable at the keyboard, which is where the decisions get made. The document needs to be specific enough that a graduate accountant can apply it without asking.

At a minimum it should cover the following. A named list of approved tools, distinguishing those permitted for client work from those permitted only for internal and generic tasks, and a separate list of prohibited services. A data classification that matches the categories above, written in plain terms, with examples staff will recognise from their own files. The conditions under which client data may be used in an approved service, including the requirement to remove identifying fields where the task allows it.

Then the operational rules. Who approves a new tool, and what evidence that approval requires. What has to be recorded for each deliverable that used AI assistance, so that a reviewer can see which tool produced what. A short incident procedure covering what a person does in the first hour if client information is disclosed in error, including who is notified internally and when a client or regulator notification is considered. Whether clients are told that AI tools are used in delivery, and what the firm says when a client questionnaire asks about it.

Finally, the policy needs an owner and a review date. Vendor terms, model defaults and data residency arrangements change far more often than policy documents are revised. A policy written once in 2026 and never revisited will be describing a product set and a set of contractual terms that no longer exist within a year.

When Local and Private Inference Is Worth It

For a small firm, running models locally is usually unnecessary. For firms doing deal work or handling genuinely sensitive engagements, it is the option that removes the disclosure question entirely.

The practical distinction is between three arrangements. Using a hosted service with contractual protections, where the data leaves the firm's premises but is governed by terms that fit the purpose. Running the model inside a private cloud environment the firm controls, which keeps data within a defined boundary. And running an open-source model on hardware the firm holds, which means nothing leaves at all.

Banks and large financial institutions typically sit in the middle category for client data, for exactly the reason you would expect. The work needs to happen on the data, and the data cannot sit in a shared environment, so the model runs where the data already is.

The trade-offs are real. Local and private deployments require hardware or cloud infrastructure, someone to maintain them, and acceptance that an open-source model running on modest hardware is usually less capable than the best hosted alternatives. That last point matters for finance work, where the failure mode is a confident wrong answer rather than a missing one. The sensible split is to use the strongest hosted tools for generic and de-identified work and to accept a more limited local setup for the genuinely sensitive tasks.

Audit Trails and Professional Reliance

The final question is the one that shows up later, usually at the worst moment. If a number in a deliverable was produced with AI assistance, and the client or a lender challenges it two years from now, what does the firm have to show?

The professional standard does not change because a tool was involved. Someone qualified remains accountable for the output, which means the record needs to support that accountability. Which assumptions were used. Where the underlying data came from. What checks were run on the result. Who reviewed it and what they changed. Whether an AI tool was used to draft or summarise, and if so which one.

That record is cheap to keep when the process produces it, and impossible to rebuild later. It is also the reason the useful architecture in this space separates the drafting layer from the computing layer. A model can draft and explain. Deterministic code can compute and reconcile. A professional reviews and signs off. Each layer leaves its own trace, and the trace is what makes the output defensible.

Two practical implications follow. First, a firm should be able to produce, on request, the chain from source data to final number including any AI step, because that is the same chain an independent reviewer would want. Second, any tool adopted for client work should be assessed on whether it makes that chain easier or harder to reconstruct. A tool that produces an answer with no visibility into how is a step backwards even when the answer is correct.

A Workable Starting Position

The framework reduces to a short set of decisions that a firm can make this week.

Classify data into what may be shared with an approved service, what must be de-identified first, and what never leaves. Choose one or two business-grade services with training exclusion and reasonable retention terms, and make them the sanctioned path. Write down the categories in language staff will recognise, with examples. Require a record of AI use on any deliverable that goes to a client or a lender. Nominate an owner and set a review date. Then treat the sensitive work, the deals and the unpublished results, as a category where the answer is either a controlled environment or no AI at all.

None of that requires a technology project. It requires a decision about what information the firm is willing to hand to someone else, made deliberately, and written down so that the next person does not have to guess.

Related reading

• Using AI in Excel for Business Data Analysis
• Excel for Due Diligence: Building a Deal Review Workbook
• Why ChatGPT isn't replacing Accountants anytime soon