Your data, your jurisdiction, your pipeline.

Voss & Hartmann, a 42-person tax firm in Amsterdam. Q3 VAT filing season: 38 clients, deadline October 31. Client files and ledgers live only on the Karma Box sitting in the firm's own server room — 5 avatars reside on this one machine. The files never leave it; only the results come back.

Where each task runs is your call

The 5 on-box avatars deliver, in one day: a Q3 VAT filing draft for one client, a reverse-charge check on a €18,400 cross-border freight invoice, a volume of an annual audit workpaper — none of it ever crossing the server-room threshold. The 4 cloud avatars handle a summary of new EU VAT rules and a reply to a website visitor — public, generic matters. One invisible line separates the two: client data doesn't cross it.

The internet drops. Work on the box keeps shipping.

09:40 to 11:10: the internet is down for 90 minutes. The on-box avatars run on local models against local data, no internet dependency — 10:02 a filing draft is delivered, 10:21 a payroll reconciliation flags 2 discrepancies, 10:38 a batch of 47 R&D credit documents is filed, 10:55 a review passes. The two cloud-dependent tasks — a regulation summary, a visitor reply — are honestly marked "waiting for the network" and resume automatically at 11:10. Nothing claims to be done when it isn't.

Every step is auditable, down to the minute

The audit log spells out, line by line, who did what and whether you were asked: 09:12 — read a client ledger (read-only, local only); 10:02 — generate a filing draft (by policy); 11:30 — submit a filing to the tax authority (approved by a named partner); 14:05 — wants to send a reminder email to 6 clients under the firm's name (pending your approval); 15:20 — wants to delete 12 expired workpapers (pending your approval). Sending anything externally, deleting, spending money — always asks first.

Client files live only on the machine in your own server room. Nothing leaves — only the results come back.

Why local-first isn't optional for finance

Most industries weigh cloud AI against convenience and cost. Finance and tax firms face a different-shaped problem: once a client's ledgers, contracts, and identity information leave a machine the firm directly controls, no matter how carefully a vendor's privacy terms are written, the firm has given up direct control over that data — a breach becomes harder to attribute responsibility for, and switching vendors later means the firm no longer fully controls how historical data gets migrated or destroyed. Voss & Hartmann keeps 5 avatars resident on its own Karma Box not out of technical conservatism, but because sovereignty over client data — who can access it, where it lives, when it's destroyed — is itself part of the professional commitment made to the client. That commitment can't be outsourced to any third party's terms of service.

How to draw the line between "must stay local" and "can go to the cloud"

Not every task needs the same level of caution. Voss & Hartmann uses one simple test: does this touch a specific client's ledger, original contract, or identity information? If yes, it goes to a resident on-box avatar regardless of how complex or simple the task is. If no — regulatory research, general Q&A, website visitor replies — it can go to a cloud avatar for lower latency and stronger model capability. Once that line is drawn, it should be written into policy rather than judged case by case each time, which is also why "which machine ran this task" is itself a checkable compliance item in the audit log, not just an implementation detail.

Four steps to a local-first workflow

1. Inventory what actually counts as sensitive. Client ledgers, original contracts, identity documents are clearly sensitive; industry rule updates, public tax tables, internal training material usually aren't. Write that boundary down explicitly rather than judging it case by case on instinct. 2. Route every sensitive task to the on-box avatars, no exceptions. Even something as small as "check if this contract has an unusual clause" should run locally if it touches a specific client's original file — never route it to the cloud just because the task feels minor. 3. Run a real outage drill. Confirm in advance that the on-box avatars can independently complete core work — filing drafts, reconciliation — with no internet at all, rather than discovering mid-outage that some step quietly depended on the cloud. 4. Build approval gates into the system, not just the policy document. Submitting a filing externally, sending an email, deleting historical files — these should be system-enforced to require human approval, not left to an internal rule that merely asks the avatars to comply voluntarily.

How to tell whether this workflow is actually reliable

Don't just check "is it fast on a normal day." The real test is what happens during an incident: whether the completion rate for core on-box tasks holds steady during an outage (that's the entire point of a local-first architecture); audit-log completeness (spot-check a few actions — can you trace a complete chain of basis and approval in one pass, or does it need manual reconstruction); actual turnaround time on approval gates (if "pending approval" items routinely sit for hours untouched, the bottleneck is the approval process itself, not the technical architecture); and cross-validation accuracy on multi-subsidiary, multi-jurisdiction work, where consolidated reporting is most prone to subtle errors.

Common mistakes

The most common mistake is reading "local-first" as "never touch the cloud at all," which gives up the cloud's stronger capability and lower cost for genuinely public information — local-first is about where the data-sovereignty boundary sits, not a purity test on technology choice; public, non-sensitive tasks can go to the cloud without issue. A second mistake is treating an outage drill as a one-time certification rather than a recurring check — system upgrades and new task types can quietly introduce new cloud dependencies that need periodic re-validation. A third is setting approval gates too broadly, so genuinely urgent tasks get stuck in the same queue as routine ones — approval should focus on irreversible or externally-facing actions (sending, deleting, spending), not require a human nod for everything.

Frequently asked questions

Are on-box avatars weaker than cloud models? On general knowledge breadth, local models usually trail the strongest cloud models. But reconciliation, verification, and filing work depends on precise rule execution, not broad general knowledge — local models handle this fine, while avoiding the risk of data leaving the premises entirely. How does this work across multiple branch offices? Each branch holding its own client data can run its own Karma Box, with avatars resident on the machine that generates the data locally — rather than centralizing everything to one location for processing. Can the audit log be altered after the fact? Operational records should be kept as a read-only audit trail, with no deletion or edit path exposed through normal business workflow. Retention periods required by financial regulation should follow local regulatory rules.

What the firm learned, one quarter in

After Q3 VAT season wrapped, Voss & Hartmann reviewed the quarter: the 5 resident avatars had produced first-draft filings for 31 of 38 clients; the remaining 7 had legacy accounting issues that still needed a partner to step in from scratch — a ratio the firm flagged as next quarter's cleanup priority rather than something to wave away. The 90-minute outage was the quarter's only network interruption, but the retrospective turned up something unexpected: the two cloud-dependent avatars resumed automatically once the network came back, but one of them missed a follow-up question a client had emailed in during the outage — it had only checked for new messages once, at the moment connectivity returned, rather than continuously. That detail went into the firm's internal ops checklist afterward: any network-dependent avatar needs a human to manually confirm nothing was missed after an outage resolves, rather than assuming "back online" means "nothing slipped through." The audit log got used for real exactly once that quarter — a client questioned the timeline on a particular filing, and the firm pulled the complete chain of custody in minutes, including exactly who approved submission and when. That had never happened before, and the firm realized it was precisely the kind of certainty the local-first architecture was built to buy in the first place.

Before relying on a local-first workflow for actual client filings and audit deliverables, run a full outage drill and a sample audit check first — confirm core-task completion rate without network access and audit-log completeness both meet the firm's internal standard, then roll out to all client ledgers.