What is Private AI?
Why accountants and lawyers
need on-premise AI

Why cloud AI doesn't fit accountants and lawyers

The SaaS architecture works in many use cases. In professions bound by professional secrecy - accountants, tax advisors, attorneys-at-law (radca prawny), advocates (adwokat), doctors - it introduces, however, four concrete risks that are difficult to address through a contract alone.

GDPR Article 32 and the duty of "appropriate measures"

Regulation (EU) 2016/679 (GDPR; Polish term: RODO) requires the data controller, in Article 32, to apply "appropriate technical and organisational measures", including in transfers to third countries. UODO (the Polish Data Protection Authority) has consistently shown in its 2024-2026 communications that what the regulator asks for is not buzzwords but a documented risk analysis. In decision DKN.5131.3.2025 the authority required the controller to demonstrate whether it had carried out the risk analysis necessary to assess whether the incident had resulted in a breach of the rights or freedoms of natural persons (orzeczenia.uodo.gov.pl).

Schrems II: SCCs alone are not enough

The Schrems II judgment in case C-311/18 was handed down on 16 July 2020. The Court of Justice of the European Union upheld Standard Contractual Clauses (SCCs) in principle, but invalidated Privacy Shield and confirmed the "essentially equivalent" protection test for transfers outside the European Economic Area. The practical conclusion: a contract is not enough if the law of the third country allows public authorities excessive access to the data (curia.europa.eu).

"The protection afforded by that mechanism must, in practice, be actionable."

DPF 2023: who is NOT on the list

The EU-US Data Privacy Framework entered into force at the level of EU implementing decision 2023/1795 on 10 July 2023. The European Commission found that the United States ensures an adequate level of protection - but only for organisations formally certified under the DPF (eur-lex.europa.eu).

The public DPF list confirms the presence of Google LLC (/participant/5780) and Microsoft Corporation (/participant/6474). However - based on research as of 1 May 2026 - we were not able to confirm official DPF entries for OpenAI or Anthropic. This does not prove the absence of any transfer basis whatsoever, but it means that you should not automatically attribute "DPF-certified" status to them without a fresh, separate check.

CLOUD Act and FISA 702: US law still applies

The CLOUD Act (2018) and FISA section 702 set out mechanisms by which US national security authorities may obtain data from entities subject to US jurisdiction. From a GDPR perspective the key point is this: the DPF and SCCs regulate the transfer, but they do not switch off US law applicable to the American provider. This is the main argument for on-premise for customers who want to minimise transfer risk and the risk of access by third-country authorities as much as possible.

Audit trail and vendor lock-in

Two smaller but real risks remain. First, the audit trail in cloud AI is limited. The customer typically does not have full control over query logs, nor over which model versions were used to produce which answer. For an UODO auditor, an inspection by KIRP (the Polish Bar Council of Legal Advisors) or NRA (the Polish Bar Association), or an internal compliance procedure, that means no deterministic audit trail. Second - vendor lock-in. Pricing changes unilaterally, the terms of service change unilaterally, and the model you worked with yesterday may behave differently today after a quiet update on the provider's side.

UODO has signalled these risks in its 2024-2026 decisions. The most prominent publicly confirmed case: a fine of nearly PLN 1.5 million against a medical company on 13 August 2024, after a hacker attack in which "unauthorised persons gained access to the data of patients and employees of the company" (uodo.gov.pl). This is not a case against AI - it is a case against insufficient technical and organisational measures, which apply to any pipeline processing sensitive data.

The operational conclusion. The "EU data centre but US-headquartered provider" model is operationally safer than vanilla SaaS, but it does not deliver as hard a position as a true on-prem deployment based on the customer's own infrastructure. This conclusion follows from the logic of Schrems II and the US legal regime - it is not a literal quotation from the regulation but a compliance interpretation that you will encounter in the communications of UODO, CNIL, and the EDPB.

Trade-offs of the local model

Local AI has four real trade-offs that there is no point hiding. You buy privacy and control at the cost of certain limitations.

Model size vs SOTA

BezChmury 11B has 11 billion parameters. It is not GPT-4 or Claude Opus, whose estimates place them at 1-2 trillion parameters. A smaller model means lower scores on general benchmarks like MMLU. On the other hand, in specialist tasks (KSeF Q&A, FA(3) validation, KSeF error code 440 diagnosis), the difference between 11B and 1T disappears, because what decides the outcome is the quality of the knowledge base (RAG), not the raw model size. This is a conscious trade-off: you give up a slice of SOTA in exchange for privacy and Polish-language quality.

Learning curve

Installing local AI in 2024 required Python, CUDA, and command-line skills. In 2026 it is much simpler - Ollama and LM Studio ship with one-click installers. Applications like BezChmury go even further: a single DMG (Mac) or EXE (Windows) file, one click, done. In practice an accounting firm still needs IT support for the first deployment (firewall, permissions, licence distribution), but this is an hour of work rather than a week.

Update cycle

Cloud AI updates itself - overnight, without your knowledge. That is convenient, but it also means that the model you worked with yesterday may behave differently today. The local model is the opposite. You update it manually, when SpeakLeash releases BezChmury 11B v3.1 or v3.2. In the BezChmury model, updates are bundled into an annual Update Pack - a one-off purchase of the application plus an optional yearly package of updates to the SSoT knowledge base and the model itself.

Training data cutoff

Every LLM has a training data cutoff. After that date the model does not know about events or legal changes "from memory". The solution is not continuous retraining - it is too expensive. Instead, we use RAG: the local SSoT fact base is updated without the need to retrain the model itself. When KSeF changed on 1 February 2026 (FA(3) becoming the mandatory schema), all that was required was to add a few dozen facts to the SSoT - BezChmury 11B did not have to be reworked.

"Do wszystkich faktur ustrukturyzowanych wystawianych od 1 lutego 2026 r. stosuje się strukturę logiczną FA(3)."

Working translation: "All structured invoices issued from 1 February 2026 use the FA(3) logical schema."

Practical example - Anna analyses an invoice

Anna runs an accounting firm serving 50 clients. She receives, from one of them, an invoice rejected by KSeF (Poland's National e-Invoice System) - error code 440 "Duplicate invoice". The client phones to ask why the invoice did not go through and how to fix it.

Workflow with local AI (BezChmury)

1. Anna opens BezChmury - the desktop application that runs without an internet connection. The whole chat session stays on her laptop.
2. She asks: "What does KSeF code 440 mean and how do I fix it?" The query classifier recognises this as an error code lookup and routes it to the relevant SSoT collection.
3. The local engine (BezChmury 11B + RAG) generates an answer with a deterministic citation: "code 440 is a duplicate invoice detected by KSeF based on the seller's tax ID, the invoice number (P_2), and the invoice type; uniqueness is checked 10 years back". Source citation: KSeF 2.0 Manual, Part II.
4. Anna receives a concrete fix: "apply an idempotency key on tax ID + P_2 + XML hash and check whether the client's archive contains an invoice with the same number from the previous 10 years".
5. The audit log is saved locally: question, SSoT source, timestamp, query hash - ready for later replay and inspection.

Time to a correct answer: 2-3 minutes. Time for the alternative process (looking through the Ministry of Finance brochure, asking a colleague, calling the help line): 30-45 minutes. These figures are illustrative - a more rigorous market-wide benchmark would require a measured pricing of manual KSeF processing, for which the industry description of "an accounting firm with 50 NIPs" mentions 3-4 hours per day without automation (drukarkaksef.pl).

The key in this scenario is not just the speed. The key is the source citation. Anna can hand the client not only the fix but also the basis for it: "Ministry of Finance manual, Part II, the chapter on duplicates". The client knows where the answer comes from. If, a year later, KIRP or UODO ask why the firm advised this particular fix, Anna has the citation in her archive. A chatbot without an audit trail cannot give you that.

The second critical element of the scene: none of the client's data left Anna's device. The invoice number, the client's tax ID, the XML fragment - all of it stayed in the RAM of her laptop, was processed by the local model, and was written to the local audit log. Had Anna used ChatGPT, the same dialogue would have generated an HTTPS request to OpenAI's servers in the United States, with session metadata, an account token, and the full query context. From the perspective of GDPR Article 32 that is a material step - or rather its absence.

On numbers: we do not publish "an average saving of 40 hours per month" as a hard product promise. The figures floating around in industry mentions (3-4 hours per day on manual KSeF logistics for a firm with 50 NIPs, falling to 30-45 minutes with the right tool) come from a single vendor's marketing copy, not from a representative market study. In our hard communication BezChmury stays cautious - we show the mechanism, not magic percentages.

A full description of this scenario is available in the Anna case study.

Local AI is not hype. It is a compliance architecture.

If you run an accounting firm, a law firm, or a compliance department, the question is no longer "should we use AI" but "which AI does not send my client's data outside Poland". BezChmury is our answer. The Polish BezChmury 11B v3 model, a local SSoT knowledge base, deterministic citations, full offline operation, a one-off purchase. Your client's data stays where it should - on your hardware.