Local AI for Notaries: §18/§26a BNotO, §203 and the RAG Path

AI in the notary's office without risking confidentiality? We build local, §203-compliant AI on your hardware - see AI for notaries and AI for confidentiality professionals, or book an initial consultation.

Drafting deeds and contracts, researching land-register and register law, checking submitted drafts - AI can save a lot of time in the notary's office. The problem is not the AI but where the data flows. Party data may not leave the office. As a holder of a public office, the notary is subject to particularly strict confidentiality - so cloud AI is hard to reconcile with it.

The good news: with §26a BNotO there is a clear, legal path. It runs through a contractually bound provider - most cleanly through local AI that never leaves the office. This article frames the legal situation, shows the permitted operating models, and explains how we build a RAG pipeline on your deed and register knowledge.

Table of contents

• The legal situation in 2026: §18 and §26a BNotO
• Why cloud AI becomes a risk for notaries
• Operating models for notary AI
• The RAG pipeline: components step by step
• Connecting multiple knowledge sources securely
• How we work at WZ-IT
• Further guides

The legal situation in 2026: §18 and §26a BNotO

Notarial confidentiality is anchored in §18 BNotO and criminally sanctioned via §203 StGB. Because the notary exercises a public office, a particularly strict standard applies.

For the use of external IT, the profession-specific norm §26a BNotO applies. It permits engaging services but ties this to clear conditions:

• Careful selection of the provider and termination in case of violations.
• Contract in text form (§126b BGB) with a confidentiality obligation and a warning about the criminal consequences, plus a restriction to the information required for the service.
• Clear rules on engaging subprocessors, who must also be bound.

The DPA under Art. 28 GDPR only governs data protection, not the criminally sanctioned confidentiality - §18/§26a BNotO and §203 StGB apply additionally. From 2 August 2026, transparency obligations of the EU AI Act for deployers also apply (as of June 2026, European Commission). This article is general information and not legal advice.

Why cloud AI becomes a risk for notaries

Cloud AI with party data is particularly sensitive in a public office:

1. The subprocessor chain. An AI provider itself uses subprocessors (Azure, AWS, and others). Each would have to be bound in text form under §26a BNotO - not practically feasible.
2. The CLOUD Act. US providers are subject to the US CLOUD Act; an EU region does not protect as long as a US parent company stands behind it - hard to reconcile with the strict standard of a public office.
3. Training on your data. Many consumer AI services process inputs further - a clear breach for party data.

With local AI in the office most of this chain disappears: the data does not leave the notary's office. Because we retain maintenance access, we remain a participating person - which is why we supply the §26a/§203 contract package for the build and maintenance phase.

Operating models for notary AI

We implement three models - with a clear link to our services:

• On-premise appliance (AI Cube). A turnkey AI box in the office. Open WebUI, Ollama/vLLM and local models are pre-installed; ideal for single and small notary offices. The data stays in-house.
• Dedicated GPU server or LLM hosting. For larger offices with more users. OpenAI-compatible API for integration into the notary software.
• Managed fallback. If you do not want to operate your own hardware, you can have AI run in our EU infrastructure - with a short, controllable provider chain.

In all models only open-source building blocks are used (no vendor lock-in), and the §26a/§203 contract package is standard. More on the cross-industry framework under AI for confidentiality professionals.

The RAG pipeline: components step by step

The real value comes not from a bare language model but from Retrieval-Augmented Generation (RAG): the AI answers questions from your template collection and register law instead of from generic training knowledge - with source references. This is how we build the pipeline (more under Custom RAG):

1. Ingestion. Documents are read in (deed templates, cases, legal sources) and normalised.
2. Chunking. Content is split into meaningful sections - for legal texts oriented around sections and structure.
3. Embeddings + vector database. Each section is translated into a vector and stored in a vector database (Qdrant) - with access metadata.
4. Retrieval and re-ranking. For a query, the most relevant sections are retrieved and sorted by re-ranking.
5. Generation. A local model (Ollama or vLLM) formulates the answer - based solely on the retrieved passages, with source references.
6. Observability and quality. With Langfuse we measure quality and make answers traceable.

We run exactly this stack ourselves: our AI offer finder on wz-it.com is a production RAG system on Qdrant, LiteLLM/Mistral and Langfuse.

Connecting multiple knowledge sources securely

We connect multiple knowledge sources into the same RAG pipeline - with enforced access rights:

• Internal template collection. Deed and contract templates as a basis for consistent drafts.
• Case documentation. Connection to your notary software for research in the case context.
• Register and notarisation law. Where permitted by licence, as a RAG source.

Party data stays local. Through access rights and payload filters in the vector database, every query only sees the sources it is allowed to see - a mandatory requirement in a public office.

How we work at WZ-IT

We deliver notary AI as a lifecycle, not as a device purchase:

1. Advise and design. Workshop, sizing, data classification and the §26a/§203 contract framework - before any hardware enters the office.
2. Build and integrate. On-premise setup, RAG on your template collection with access control, integration into the notary software, confidentiality obligation plus DPA.
3. Operate and maintain (optional). Updates, monitoring, model upgrades and RAG curation as a contract - or you operate it yourself after handover and training.

The operational contract texts are drafted by qualified professionals; this article does not replace case-specific legal advice.

Further guides

• AI for notaries - the solution page with use cases and hardware options.
• AI for confidentiality professionals - the cross-industry §203 framework (also for lawyers and tax advisors).
• Custom RAG - how we build RAG pipelines end to end.
• AI hub - local AI infrastructure, LLM hosting and RAG at a glance.

Ready for AI that protects the parties involved? We build it locally, §26a/§203-compliant, and operate it on request. Book your initial consultation now.

Sources

• §18 BNotO (duty of confidentiality)
• §26a BNotO (engaging service providers)
• §203 StGB (violation of private secrets)
• European Commission: Regulatory framework on AI (EU AI Act)