I keep coming back to one paragraph in every tax software contract I’ve ever signed. The exact wording varies, but the meaning is always the same:
“We may update, modify, or amend these terms at any time. We will provide notice of material changes by email or in-product notification. Continued use of the service after the effective date of changes constitutes acceptance.”
That paragraph is the structural fact most preparers miss when they evaluate a tax software vendor. The promises in the privacy policy aren’t permanent. They’re a snapshot. Thirty days from now, the vendor can quietly amend any clause — data sharing, retention, third-party use, training data exclusions — and the change becomes binding the moment the firm’s contract auto-renews.
This isn’t a hypothetical. It’s what tax software companies do, every quarter, to every customer. Most preparers don’t read the change emails. The ones who do usually accept the changes because the cost of migrating is higher than the cost of accepting. Vendors know this. The system runs on the asymmetry.
There’s an alternative. And in 2026, every tax firm is going to have to choose between the two — most without realizing they are.
The two privacy architectures
Tax software in 2026 falls into one of two architectural patterns when it comes to privacy. The names are bad — both choices market themselves as “secure” or “compliant” or “your data, your control.” But the structures underneath are completely different.
Privacy by policy. This is the dominant pattern. The firm uploads documents to vendor-operated infrastructure. The vendor processes the documents on its servers, stores extracted data in its database, retains audit logs in its environment, and provides the firm a contractual commitment about how that data will be handled. The firm’s privacy depends entirely on the vendor honoring the contract. The contract can be amended.
Privacy by architecture. This is the alternative. The firm’s tax content lives in infrastructure the firm controls — typically the firm’s own Google Workspace. The software comes to the data: it processes inside the firm’s environment, writes results back to the firm’s own files, and gives the vendor access only to authentication metadata and audit trails — never the tax content itself. The firm’s privacy depends on where the data physically resides. The architecture can only be changed by a deliberate engineering rewrite, not by a quarterly contract amendment.
Both architectures are functional. Both meet the legal bar of “encrypted at rest, encrypted in transit, accessed only by authorized parties.” Both can be described in marketing as “secure tax automation.” The difference is who has structural access to the firm’s clients’ data while the software runs.
That difference is invisible at the marketing layer and load-bearing everywhere else.
Why the difference matters more in 2026
A few years ago, this distinction was academic. Most firms used the privacy-by-policy default and didn’t think about it. Three forces have changed that.
Taxpayer awareness is rising. The general public has spent the last decade learning that “their data” is a different thing than they thought. Apple’s privacy campaigns, the European GDPR cycle, the steady drumbeat of breach disclosures — these have produced a more sophisticated taxpayer who knows enough to ask their preparer where their W-2 is going. Most preparers can’t answer in technical detail. That gap is becoming embarrassing.
Regulatory attention is sharpening. IRC §7216, on the books for decades, has been enforced lightly. The enforcement posture is changing. State Boards of Accountancy are paying closer attention to data-handling practices. State attorneys general are paying closer attention to AI tax tools. The regulatory pressure is moving from “what did the contract say?” to “what did the architecture actually do?”
Professional liability insurers are paying attention. Underwriters writing E&O policies for tax preparers are starting to ask about data-handling architecture in their underwriting questionnaires. A firm that can document its data lives in its own infrastructure underwrites cleaner than a firm whose data lives somewhere it can’t describe.
Each of these forces compounds the others. Each compounds the cost, to the firm, of a privacy commitment that depends on a contract that can be amended.
What changes when a firm chooses privacy by architecture
I run a small practice in Phoenix. Over the last twelve months, I switched the data-handling story of my practice from privacy-by-policy to privacy-by-architecture. A few things changed that I didn’t anticipate.
The data conversation with clients got shorter. When a client asks where their data lives, the answer is one sentence: “It lives in our firm’s own Google Workspace, encrypted at rest, governed by access policies we control. The software vendor never sees your tax content.” That’s it. No deferral to a third-party policy. No careful re-reading of a vendor contract. The architecture answers the question.
The audit trail story got cleaner. Every document approval is logged with my user ID, a timestamp, and the action taken. The audit log lives in the firm’s infrastructure — which means in the rare case I ever have to defend a return to the IRS or a state board, the evidence trail is something I can produce directly, not request from a vendor’s API.
The vendor-relationship cost dropped. I don’t track contract updates as carefully because the contractual commitments matter less. The vendor still has commitments to me — license terms, uptime, support — but those are operational concerns, not privacy concerns. Privacy stopped being a vendor-relationship problem and became a system-administration problem.
The conversation with peers shifted. When other preparers ask me about my workflow, they expect to hear about features. What I actually talk about is who owns the data while the software is running. That’s the conversation I think the industry is moving toward — privacy-by-architecture firms have a different answer to give than privacy-by-policy firms, and clients are starting to notice the difference.
What architectural privacy doesn’t promise
I want to be careful about what I’m claiming, because the AI tax era is full of overclaims and I’d rather under-promise than over-sell.
Architectural privacy doesn’t mean the vendor sees zero data. Sophicor — the tool I use and the tool I built — stores authentication tokens, user metadata, and audit log entries on Sophicor’s infrastructure. Without those, the system couldn’t authenticate users or generate the audit trail. The boundary is precise: tax content stays with the firm. Operational metadata lives in the vendor’s secure backend.
Architectural privacy doesn’t mean the data is uncopyable. A firm with administrative access to its own data can still mishandle that data. A USB stick with client information is just as risky in a private-cloud firm as in a shared-cloud firm. The architecture changes the structural assumption; it doesn’t eliminate human error.
Architectural privacy doesn’t mean AI is doing less work. Sophia, the document intelligence layer in Sophicor, reads W-2s, 1099s, K-1s, 1098s, and proposes field values. AI is doing meaningful work. What’s different is that every extracted field is reviewed by a human preparer before it becomes part of a return — AI as co-pilot, not auto-pilot. The “verification before automation” posture is what makes the AI safe.
These caveats are important because the architectural shift is real and meaningful, and I don’t want to oversell it. The point isn’t that privacy-by-architecture is magic. The point is that it’s structurally different from privacy-by-policy in ways that compound across years and across the regulatory pressure curve.
What every firm will have to decide in 2026
If I’m right that the two architectures are converging into a binary choice every firm is going to have to make, the question is when each firm has to make it. Three signals to watch for inside your own practice:
A client asks where their data lives. This is the first signal. Until 2024 it was almost never asked. In 2025 it started showing up. In 2026 it’s getting more frequent. The first time it happens to your firm is the moment the privacy-by-policy answer becomes a liability.
Your underwriter asks about architecture on the next renewal. When the E&O renewal questionnaire starts asking which tax software you use and how it handles data, the privacy-by-architecture firms have a one-page answer and the privacy-by-policy firms have a vendor’s privacy PDF. The underwriter notices the difference. The premium difference follows.
Your tax software vendor sends a privacy-policy update you don’t like. The third signal is the most familiar. The email arrives. The change has been made unilaterally. You can accept, negotiate (rarely), migrate (expensive), or archive and hope it doesn’t matter. The privacy-by-architecture firm doesn’t get this email — its privacy isn’t governed by a policy that can change.
When one of these three signals shows up in your practice, the choice between architectures stops being abstract. The firms that have already made it are positioned. The firms that haven’t are reacting.
The structural conclusion
Architecture is harder to change than policy. That’s the entire point.
A firm choosing tax software in 2026 is choosing between two structural commitments about its clients’ data. One commitment is enforced by contract — and contract language has a quarterly amendment cycle. The other commitment is enforced by where the data physically resides — and physical residency requires a deliberate engineering rewrite to change.
The first kind of commitment is renewable. The second kind is structural. The firm that wants its privacy story to outlast the next vendor-policy email picks the structural one.
When a client asks me where their data lives, my answer doesn’t depend on what some vendor’s lawyers decided last quarter. It depends on where I put the data when I designed the system. That’s architecture. That’s the choice every tax firm is making in 2026, whether they realize it or not.
The taxpayer’s data should never leave the firm that prepared it. That’s the principle. Privacy by architecture is what it looks like in code.
— Yatin Miglani
Enrolled Agent · Phoenix, Arizona
Founder, Sophicor · sophicor.com