Private Cloud vs. Shared Cloud for Tax Firms Every AI extraction tool reads your client's W-2 somewhere. Whose server it sits on decides your liability, your §7216 posture, and the answer you can give a client.

If you run a tax firm, you've almost certainly been pitched an AI document-extraction tool in the last year. The decks all look alike. The accuracy claims all sound alike. And underneath every one of them sits a question almost nobody in the room asks: when your client's W-2 is being read by the AI, whose server is it sitting on?

That single question decides more than it looks like it does. It decides your liability exposure. It decides your compliance posture under §7216. And it decides whether you can make good, in plain language, on the data-security promise you make every client who signs an engagement letter. So it's worth pulling apart what the answer actually is — not in marketing terms, but in operational ones.

The two arrangements, defined plainly

Strip away the branding and there are two architectures a tool can have.

In a shared-cloud arrangement, your clients' documents are processed on the vendor's servers. When you upload a W-2, that file — and everything in it — leaves your environment and travels to the vendor's infrastructure. The AI reads it there. The data rests there during processing. The vendor holds the encryption keys, the access logs, and the security perimeter. Most tools on the market work this way, because it's the easiest and fastest thing to build. That isn't a scandal. But it carries consequences a firm owner should understand before signing.

In a private-cloud arrangement, the processing engine runs inside infrastructure you already control. For most firms that means your own Google Workspace tenant — an account you already pay for and already govern. The AI runs in your environment. The documents never leave the cloud account you already control. Same idea, opposite plumbing.

This is not a preference between two flavors of the same service. It's an architectural difference with direct legal and operational consequences, and the clearest place to see them is §7216.

Why it matters: the §7216 question

§7216 governs the disclosure and use of tax return information, and the obligation doesn't stop at your door — it extends to anyone you share that information with. When you send a client's W-2 to a shared-cloud vendor for processing, you are disclosing tax return information to a third party. That's permissible with the right consent. The uncomfortable part is that many firms' engagement letters and consent forms don't actually describe this specific use, so the consent on file may not cover the thing that's happening.

There's a second, larger issue underneath the first. Once a vendor is processing your clients' data on its servers, that vendor becomes a custodian of it. If they suffer a breach, your clients don't call the vendor — they call you, because your name is on the engagement letter. A breach at your vendor isn't the vendor's client problem. It's your client-relationship problem.

Private-cloud architecture changes the shape of that risk. When the processing happens inside your own environment, there is no third-party custody to worry about. The vendor never holds the data. Your existing security policies, encryption standards, and access controls govern it from the first byte to the last. Your §7216 posture stops depending on whether a vendor's terms cover the disclosure, because the disclosure to a third party never happens.

The most sensitive field on the return

Think about the Social Security number for a second, because it concentrates the whole issue. It's the single most sensitive element in a tax document, every W-2 has one, and a 500-return firm handles thousands of them a season.

On a shared-cloud platform, those numbers travel to the vendor's servers along with everything else. The vendor may encrypt them well — but they hold the keys, and the data exists in their environment, however briefly, during extraction. The concern isn't that any particular vendor is careless. It's that once the data leaves your environment, you have no visibility into or control over what happens to it. Keeping the most sensitive identifier your firm touches inside the environment you already govern isn't a feature to be marketed. It's an architectural choice that removes an entire category of exposure instead of promising to manage it.

What it changes day to day

Beyond liability, the distinction shows up in two concrete places.

The first is the conversation across the desk. When a client asks where their data goes, a shared-cloud firm has to explain that it goes to a third-party vendor and then reassure them about that vendor. A private-cloud firm can say something simpler and truer: it goes into our own secure Workspace environment, and we control it from intake to output. For a business owner, a high-net-worth client, or anyone who's lived through identity theft, that is a materially different answer — and it's one sentence, not a paragraph.

The second is pricing, and it follows from the architecture rather than from anybody's generosity. A tool that runs compute on its own servers for every return has a real per-return cost, so it tends to charge per return or per document and pass that cost to you. A tool that installs once and runs inside your Workspace, on infrastructure you already pay for, has a marginal cost per additional return that approaches zero — which is why flat licensing comes naturally to private cloud and is structurally hard for a per-transaction model to match. At 500 returns, the difference between a flat license and a per-return fee is not a rounding error; it's a line item.

What to ask before you commit

If you're evaluating a tool, or want to know which side of this line your current one sits on, a handful of direct questions settle it. Where exactly are my client documents processed — on your servers, or inside my own cloud environment? Who holds the encryption keys during processing? If your infrastructure is breached, what is my firm's exposure? Does using your platform require §7216 consent from my clients, and do you supply the documentation for it? And can you produce a current SOC 2 Type II report on request? A vendor that can answer those plainly and specifically is telling you something. A vendor that can't is telling you something too — the evasion is the answer.

The bottom line

Private cloud and shared cloud aren't two tiers of the same product. They're different architectures, with different liability profiles, different pricing logic, and different answers to the question your clients are increasingly going to ask. The market is moving fast, and most of what's being sold right now is shared cloud, because shared cloud is easier to build and easier to scale. Private cloud asks for more architectural discipline and a deeper fit with the firm's own infrastructure.

But for a firm that takes data stewardship seriously — and any firm signing engagement letters with real clients should — the architecture question isn't a technical footnote. It's a business decision, and it's one you get to make on purpose instead of inheriting by default. Your data stays in your cloud, not the vendor's. That isn't a slogan. It's the whole premise.