There is a pattern showing up in financial modeling that nobody predicted two years ago: experienced practitioners are using less AI than they were, not more.

Not because the tools got worse. Because the contracts changed. Engagement letters and NDAs increasingly carry a clause prohibiting confidential information from being entered into a generative AI system, and the practitioner who signed it now has a spreadsheet in one window, a chat interface in the other, and a rule against connecting them. The workaround is deliberately vague prompting: debug this formula, explain this accounting treatment, never a real number.

That is a real constraint and it deserves a real answer, not a reassurance. This article is about what those clauses actually prohibit, what actually happens to data you send to a model provider, and which workflows stay inside the line. Sources are linked throughout, because on this topic a confident claim without a citation is worth nothing.

First: read the clause. Three different prohibitions get called "no AI"

Practitioners tend to collapse three very different restrictions into one blanket "we can't use AI." They have different scopes and different remedies.

1. No training on our data. The most common formulation. It prohibits your data being used to improve a model, not the act of inference itself. This one is often already satisfied by the commercial terms of the provider you were going to use anyway.

2. No consumer-grade or publicly available tools. The second most common. Typical drafting: the recipient shall not input confidential information into any publicly-available or consumer-grade generative artificial intelligence or large language model. This restricts the tier, not the technology. A commercial API account under a data processing agreement is a different object from a personal Pro subscription, and the clause frequently says so.

3. No processing by any third party. The broadest. This one genuinely rules out any hosted model, and the only remaining paths are a local model or no model at all.

The distinction matters because the three clauses have different answers, and because the middle one is the most common while also being the one most often read as if it were the third. Before changing how you work, get the actual sentence in front of you and identify which of the three you are dealing with. If it is ambiguous, that ambiguity is a question for the client, not something to resolve by assuming the strictest reading.

Second: know what actually happens to the data

Most of the fear in this area is calibrated to a 2023 understanding of how these services worked. The terms have changed, they are public, and they are specific. What follows is what the providers themselves document, with the nuances that get lost in summary.

On the commercial tier, your data is not training the model. Anthropic's developer documentation states that retained data "is never used for model training without your express permission," and that inputs and outputs on the commercial API are deleted within 30 days by default (Anthropic, API and data retention). OpenAI documents that since 1 March 2023, data sent to its API "is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)," with abuse-monitoring logs retained up to 30 days (OpenAI, Data controls).

The consumer tier is a genuinely different product, and this is the one your clause is about. Under the consumer terms announced in August 2025, users on Claude Free, Pro and Max choose whether their chats are used to improve the model, with retention of five years if they allow it against the standard 30 days if they do not. That update explicitly does not apply to services under Anthropic's Commercial Terms, including API use (Anthropic, 2025). If you are working from a personal Pro subscription, you are on the tier the clause was drafted to catch. That is worth sitting with, because it is the single most common gap between what practitioners believe about their setup and what is true.

Zero data retention exists, and it is narrower than the name suggests. Under a ZDR arrangement, prompts and responses are not stored at rest after the response is returned. But the documentation lists what the arrangement does not cover: consumer plans, the Claude Teams and Enterprise product interfaces, Console and Workbench, Claude for Excel, Managed Agents, third-party integrations, and the models designated Covered Models, which require 30-day retention. A separate eligibility table puts further features outside it, among them code execution, the Files API, batch processing, the MCP connector and Agent Skills. The trap is that using one of those does not fail loudly: nothing blocks the request, and the documentation is explicit that using an ineligible feature "is a choice to step outside your ZDR arrangement for that specific data." ZDR is enabled per organization and arranged through sales, not toggled in settings (Anthropic, API and data retention).

Nothing is absolute. Anthropic documents that even with a ZDR or HIPAA arrangement, content flagged by automated trust and safety systems may be retained for up to two years. Any claim that data "never touches their servers" is false for every hosted model, and you should distrust any vendor who tells you otherwise.

The honest summary: on a commercial tier with a DPA, your data is processed, retained briefly, not trained on, and subject to documented exceptions. That is a materially different risk profile from a consumer subscription, and it is checkable rather than assumed.

Third: the obligation may exist even if the contract is silent

For US CPAs there is a second layer that does not depend on what the client's contract says.

The AICPA Confidential Client Information Rule (1.700.001) provides that a member in public practice shall not disclose confidential client information without the client's specific consent. Interpretation 1.700.040 addresses what happens when a third-party service provider is involved: before disclosing confidential client information to that provider, the member should either enter into a contractual agreement with the provider to maintain confidentiality and give reasonable assurance of appropriate procedures, or obtain specific consent from the client (Blatch, Journal of Accountancy, 2015 · Journal of Accountancy, 2024). The Code's word is "should", not "must", and the interpretation predates generative AI: it does not name it, which is precisely why it applies to it.

A hosted model provider is a third-party service provider on any plain reading, and the rule gives you two doors rather than one. The contractual door is a DPA with a commercial provider. The consent door is a conversation with your client. Neither of them is "stop using AI."

Silence in the engagement letter is not permission, and it is not prohibition either. It is an unanswered question, and the profession's own rule tells you how to answer it.

The four workflows that stay inside the line

Ranked from the most restrictive constraint to the least.

1. Never send client numbers at all: build the structure, populate offline

This is the one most people miss, and it is the one that works even under the broadest clause.

A financial model is two things stacked together: a structure (the logic, the formula relationships, the timeline, the ordering of a debt waterfall, the shape of a three-statement build) and data (this client's actuals, this deal's assumptions). Confidentiality attaches to the data. It does not attach to the fact that interest expense is a function of average debt balance.

So you can do the expensive part with AI on a structure that contains no client information, using placeholder or synthetic figures, then populate the real numbers in a separate step that no model ever sees. The AI does the work you actually wanted help with, which is the architecture and the formula logic, and the confidential figures never leave your environment.

This is not a trick and it does not need a vendor. You can do it with a blank workbook. It does require a tool where structure and data are genuinely separable, because in a normal spreadsheet the logic and the numbers live in the same cells and there is no clean line to cut along.

2. Move to a commercial tier and paper it

If the clause targets consumer-grade tools, the remedy is to stop using a consumer tool. A commercial API account or an enterprise agreement with a DPA, plus ZDR if your use case qualifies for it, addresses the substance of most clauses in this family, and it happens to be exactly the contractual-agreement limb of AICPA 1.700.040.

Read the exclusion list before you rely on it. If your workflow depends on file uploads, code execution or a hosted connector, check whether those specific features are inside your arrangement.

3. Ask for consent, specifically

The most underused path. Practitioners assume the answer is no and never ask.

A specific request works better than a general one: name the tool, name the tier, name what data would be sent, name the retention and training terms, and offer the alternative. Clients who would refuse "can I use AI on your file" quite often approve "I would use a commercial account under a data processing agreement with no training on your data and 30-day retention, for the model structure only." You have also just created a written record, which is the thing your professional obligation actually wants.

4. Run a local model

If the clause prohibits any third-party processing, a model running on your own hardware is the only remaining option that keeps AI in the workflow. The trade is real: local open-weight models are meaningfully behind frontier models on multi-step numerical reasoning, and financial reasoning is one of the areas where the gap shows. For structural work, boilerplate and formula debugging on a straightforward build, they are usable today. For a complex model, they are not a substitute.

Most practitioners in finance do not know this is even possible. It is worth two hours of your time to find out where the ceiling is for your own work, rather than assuming it either solves everything or nothing.

What not to do: the quiet regression

The most common response to a restrictive clause is none of the four above. It is to keep using the same consumer tool, and simply be vaguer about it. Paste less. Describe the problem in general terms. Rename the client.

This is the worst available option, and it is worth naming clearly.

It does not actually achieve compliance, because "less confidential information" is not "no confidential information," and a pasted formula from a live client model with the numbers changed is still derived from confidential material. It removes the audit trail, because the work is now happening in a chat window nobody can reconstruct. And it degrades your output, because you have deprived the model of the context it needed while keeping every risk that mattered.

It also has a measurable cousin. In one analysis of 22.4 million enterprise AI prompts and uploads, financial data (projections, investment analysis, sales pipeline) was the single largest category of sensitive information detected, at 16.6% of all exposures (Harmonic Security, 2025, vendor telemetry rather than a representative panel). The vagueness strategy is how most of that happens: not deliberate exfiltration, just practitioners who believed they were being careful enough.

Pick a real path. An informal one is not a path.

Where a model layer helps, and where it does not

Full disclosure of the obvious: we build Layerz, a workspace that holds a financial model as structure separate from data, which Claude drives from the outside through MCP. So take the following with the appropriate suspicion, and note what it does not claim.

It does not make you compliant. If you point an AI at a model that contains your client's real numbers, those numbers go to the model provider exactly as they would from any other tool, and no architecture changes that. Anyone telling you otherwise is selling you something.

What separating structure from data does change is that workflow #1 above stops being a discipline you have to maintain by hand and becomes the default shape of the work. The logic, the dependencies and the timeline are one object. The values are another. You can hand the first to an AI and keep the second out of scope, then export a clean Excel file and populate it where the confidentiality obligation lives. That is a narrow claim, and it is the only one worth making.

The related question of whether the tool itself introduces new exposure, through dynamic code execution on files you did not author, is a different problem covered in AI and Confidential Financial Data: What Actually Happens to Your Numbers.

The checklist

On the contract:

  • Get the actual clause in front of you. Which of the three prohibitions is it?
  • If it is ambiguous, it is a client question, not an assumption.

On your setup:

  • Which tier are you on? Consumer subscription or commercial account with a DPA?
  • If you rely on ZDR, have you checked your specific features against the exclusion list?
  • Would you be able to describe your data flow to the client in three sentences? If not, you do not yet know what it is.

On the work:

  • Which parts of this engagement need real numbers, and which are structural?
  • Can the structural part be done on a model that contains no client data?
  • Is there a record of what the AI touched, or only a chat history?

The bottom line

A clause prohibiting confidential data in a generative AI system is not a prohibition on using AI. It is a constraint on which data, on which tier, and with whose consent. Practitioners who read it as a total ban give up most of the value while frequently retaining the actual exposure, because the vagueness workaround is not compliance.

The most durable answer is also the least technological: keep the confidential figures out of the part of the work you delegate. That was good practice before any of this existed. The tooling question is only whether your tools let you draw the line cleanly, or force you to hold it in your head.

Related: AI and Confidential Financial Data · Shadow IT in Finance · AI Financial Model Risk and Governance: Statistics