Model example

AI for an electrical contractor

How a mid-sized trade business with ten staff can equip its three AI-relevant roles — management, site management, back office. Three roles, three configurations, one coherent architecture.

Every architecture starts with an inventory. An electrical contractor with ten staff — typical split: one owner-master, two site or project leads, one or two back-office people, five fitters on sites, possibly an apprentice. Three of these roles benefit directly from tools — with very different requirements.

What we show here is not a report on a specific client, but a model example: what a clean configuration in a business of this size and profile would look like. The obvious reflex „a Pro license for everyone" burns both money and — and still does not cover the right .

Inventory — what already runs today

Before anything is configured, we capture what already exists in the business — software, data, unofficial tools, compliance duties:

Line-of-business software — job management, inventory, accounting (often DATEV-connected), photo documentation, measurement app
Unofficial shadow AI — almost always individual employees already use ChatGPT, Gemini or similar privately. First question: what already runs through which accounts today?
Data inventory — which personal data arises where (customers, employees, suppliers)? Which is particularly sensitive?
Template stacks — standard quotes, maintenance confirmations, fault reports, connection protocols. Precisely these repetitions are the RAG potential — and at the same time what costs the back office hours every day
Compliance duties — GDPR, sector-specific rules (TREMOD / energy efficiency for larger installations), since February 2026 additionally AI literacy per Art. 4 AI Act

From this inventory the roles that need emerge — and those that do not. The five fitters on sites, for example, do not have their own tool; they send voice notes and photos to the site management app, where workflows turn them into defect reports and material lists.

Three roles, three configurations

Each role gets the tool that matches its volume, data sensitivity and mobility — not what is currently hyped.

Role 1

Owner / management

Tasks

Strategy, large quotes, customer communication, reports for banks and chambers

Volume

Few but high-value requests — estimated 5–15 longer sessions per week

Data sensitivity

Medium — strategy sketches, calculation key figures, copy; rarely personal data in detail

Tool mix

Frontier model (Claude or GPT of the current generation) in the browser or mobile app, run via a vendor with DPA and EU region
No own RAG system — context is supplied via file upload or copy-paste (quote drafts, chamber letters, bank templates)
Embedded in the mail workflow for dictations, draft replies and translations

Why this choice

Quality beats effort. Frontier models are clearly superior to local ones for strategic copy, calculation estimates and report formulations. The low volume easily justifies the cloud cost — a personal Pro license or an account is enough.

Role 2

Project and site management

Tasks

Measurements on site, photo documentation, defect reports, material orders, technical research (VDE standards, datasheets), customer emails

Volume

Daily use, high transaction volume — many short queries, often on the move

Data sensitivity

High — customer locations, connection configurations, material prices, suppliers

Tool mix

Frontier model via DPA cloud for mobile / tablet — quick answers on the move, customer email drafts
In-house RAG knowledge base (e.g. Obsidian as source, local embedding via Ollama, vector store ChromaDB, hybrid search with BM25 + RRF fusion): VDE standards, in-house standard clauses, connection diagrams, supplier datasheets — queryable in natural language
OCR for delivery notes and handwritten notes, embedded in n8n workflows
MCP tools with read access to the line-of-business software (job status, stock) — no write rights without human approval

Why this choice

Data flow split by sensitivity. Customer copy and general research go into the cloud (quality matters, no personal data in plain text). Sector knowledge stays local — standards are public, but the connection diagrams, supplier prices and standard clauses are internal assets that do not belong in third-party training data.

Role 3

Office / back office

Tasks

Writing quotes and invoices, scheduling, maintaining service contracts, incident hotline, classifying inbound emails and routing them internally

Volume

Continuous processing — highest transaction volume in the business, estimated 150–250 mail and document items per week

Data sensitivity

Very high — customer master data, contracts, receivables, maintenance histories

Tool mix

Open WebUI self-hosted with RBAC per employee and a complete audit log
Local language model (e.g. Ollama with Gemma 4 / 26B) for German standard business correspondence
n8n workflows for recurring operations: receipt capture (OCR → accounting export), dunning triggers, email classification and routing (complaint / inquiry / incident)
RAG system with maintenance contracts, customer files and history notes — back office can check in natural language what last happened with which customer
Complete sealing: no token, no file leaves the self-hosted server; no cloud API in the pipeline

Why this choice

This is where most data-sensitive operations run — customer master data, contracts, dunning. not as ideology, but because these data belong neither through a US cloud nor through model training. Bonus: the volume would quickly make per-seat licenses more expensive than a one-off setup with + + on a mid-sized server.

Architecture bracket — who talks to whom

Three roles does not mean three isolated islands. The connecting element is a cleanly separated data-flow architecture: cloud for what may be processed publicly or anonymised, for everything with personal data or business secrets.

Cloud (with DPA)

Frontier model, EU region

Used by management (strategy, reports) and site management (mobile mail drafts, general research). Personal data is anonymised before input or not put into the prompt at all.

Self-hosted (server in DE)

Open WebUI + Ollama + n8n + RAG

Back-office workflows, with sector knowledge, pipeline, engine. Can run on a mid-sized in Germany or in your own server room, as you prefer.

Line-of-business software

ERP / accounting / job management

Stays where it is. Integration via or tools with the minimum necessary read / write rights — no replication into another database.

Mobile devices

App + VPN to the self-hosted backend

Fitters and site management use the photo / voice app on site, which accesses the server via VPN and consults the cloud additionally depending on .

Which local models come into question

For the back office, several open-source models are tested against typical tasks — German business correspondence, classification of inbound mails, simple instructions for . Current findings from such comparisons (as of 2026):

Model	Verdict	Reasoning
Gemma 4 (Google)	Winner for German standard texts	Clean German output, stable JSON for n8n pipelines, good Markdown
Llama (Meta)	Rejected	Token leaks — control characters in the output that would have to be filtered out in the workflows due to idempotency duty
Qwen (Alibaba)	Rejected	Similar issue with control tokens, plus weaker on German business correspondence
Mistral	Solid, but weaker	Good general quality, but German business correspondence sounds wooden; suitable as a backup model

Important: local models still lag frontier cloud models in quality. They fit clearly scoped tasks (classification, German standard correspondence, document extraction). They are not a replacement for Claude or GPT when it comes to demanding copy or complex reasoning — but the lever for and cost control on recurring routines.

What deliberately does NOT run locally

Legal and standards research with source attribution

Local models hallucinate on paragraphs and dates. Instead of a model, use Perplexity, a search or the VDE database directly.

Strategic or promotional copy with high quality expectations

Frontier cloud models deliver clearly better results on these tasks — and the low volume justifies the cost.

Code for own script or workflow adjustments

Claude or GPT in their coding variants — locally with the code quality is too weak for productive changes.

Profiling of employees or customers

On principle, no scoring tasks by a language model — Art. 22 GDPR is very restrictive here, and the does not pay off at this business size.

Compliance bracket

Three configurations means three data flows — and each must be documented and compliant. What runs along in the model example:

GDPR

DPA with cloud vendors (EU region), review documented, recorded

Record of Processing

Records of processing activities cover both the cloud routes (management, site management) and the pipeline (back office, )

AI Act Art. 4

training for all employees, refreshed annually, integrated into onboarding

Data segregation

Documented which data pools stay local and which go into which cloud — including escalation path for new

What runs after setup

An setup is not a project end, but ongoing operation. Three things belong with it permanently:

Observability

telemetry via executions, Telegram alert on failures, over all access

Update discipline

Half-yearly model reviews, prompts curated in a shared , new employees introduced to tools during onboarding

Scaling

Further workflows (photo for electricity meters, switchboard documentation, maintenance reports) can be added in the same architecture — without a new setup

Ready for the next step?

Free intro call, no strings attached. In 30 minutes you'll know whether and how AI can help your business.

Book a call Check eligibility