Es begann wie so oft: Ein Kunde schreibt eine E-Mail mit fünf Themen, drei Rückfragen und zwei neuen Ideen. Im Ticketsystem landet das Ganze als unübersichtliches Sammelticket.

Was wäre, wenn ein lokales LLM diese Nachrichten automatisch zerlegt – direkt im eigenen Infrastrukturperimeter, ohne Cloud, ohne Datenabfluss?

Genau das habe ich umgesetzt. Und dieser Artikel zeigt, wie sich lokale KI ganz praktisch in reale Workflows integrieren lässt.

Vom Experiment zur produktiven Aufgabe

Im vorherigen Artikel „Local LLM – KI-Sprachmodelle ohne Cloud“ ging es primär um ein technisches Experiment: Was kann ein Sprachmodell lokal leisten? Wie fühlt sich Offline-Inferenz an? Wie viel Kontrolle gewinnt man zurück?

Dieser Folgeartikel beschreibt nun den konkreten Einsatz eines lokalen LLM in meinem Alltag:

• Ich betreibe Redmine als Ticketsystem zur Kundenkommunikation.
• Vor allem über die E-Mail-Schnittstelle entstehen häufig Sammeltickets, die mehrere Themen enthalten.
• Ziel war daher eine automatisierte Zerlegung dieser Nachrichten in strukturierte Einzeltickets.
• Und das ohne irgendeine Form von Datenübermittlung an externe Dienste.

Ein idealer Anwendungsfall für ein lokal betriebenes LLM, integriert in einen bestehenden Workflow.

Betriebsumgebung und Zielsetzung

Bevor es zur Implementierung geht, ein Blick auf die Umgebung.

Der Prototyp aus der Explorationsphase sollte in einen Container wandern. Nicht als Sicherheitsmaßnahme (Container-Isolation ist nun mal keine Härtung), sondern aus praktischen Gründen:

• Filesystem-Isolation – sauber getrennte Laufzeit ohne Seiteneffekte
• Ressourcenkontrolle – da sich das Modell den Home- bzw. Branch-Server mit anderen Diensten teilt
• Keine Echtzeit-Anforderungen – die Ticketverarbeitung kann problemlos asynchron und zeitversetzt laufen

Containerisierung ist hier also ein Betriebs- und Organisationsinstrument, kein Security-Feature. Sie sorgt dafür, dass die KI-Umgebung reproduzierbar, wartbar und klar abgegrenzt betrieben werden kann, ohne in die Infrastruktur anderer Komponenten hineinzureichen.

Anschließend soll ein Proof of Concept in Go entstehen, der sowohl die Redmine-API als auch die Ollama-API nutzt, um die gesamte Aufgabe Ende-zu-Ende abzubilden: Tickets einlesen, Beschreibung an das KI-Modell übergeben, Unteraufgaben extrahieren, Subtickets erzeugen und das Hauptticket automatisch weiter­schalten.

Ziel ist eine minimalistische, aber robuste Lösung, die zeigt, dass sich lokale KI mit vertretbarem Aufwand produktiv, nachvollziehbar und souverän in bestehende Workflows integrieren lässt.

Ollama Container-Build

Zunächst das Ollama-Repository klonen:

git clone https://github.com/ollama/ollama.git
cd ollama

Ein Dockerfile ist bereits enthalten – Build-Versuch:

ollama/ollama [ podman build -t ollama -f Dockerfile                                                    main ] 04:49
WARN[0000] missing "CGO_CFLAGS" build argument. Try adding "--build-arg CGO_CFLAGS=<VALUE>" to the command line
WARN[0000] missing "CGO_CXXFLAGS" build argument. Try adding "--build-arg CGO_CXXFLAGS=<VALUE>" to the command line
[1/21] STEP 1/7: FROM --platform=linux/amd64 rocm/dev-almalinux-8:6.3.3-complete AS base-amd64
Error: creating build container: short-name "rocm/dev-almalinux-8:6.3.3-complete" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"

Der Registry-Fehler ist leicht zu fixen:

sudo nano /etc/containers/registries.conf
unqualified-search-registries = ["docker.io"]

Warnungen zu CGO-Flags lassen sich durch explizite Nullwerte unterdrücken:

podman build -t ollama   -f Dockerfile   --build-arg TARGETARCH=amd64   --build-arg FLAVOR=amd64   --build-arg CGO_CFLAGS=""   --build-arg CGO_CXXFLAGS=""   .

Nach längerer Laufzeit:

Successfully tagged localhost/ollama:latest
e53dcbfcbecefedcffb00862e8202623de88b4d0f3e98823b0ab8914fec53a7b

Optionales Pushen in die eigene Registry:

podman tag e53dcbfcbece registry.ext.d2ux.net/ollama:latest
podman login registry.ext.d2ux.net
podman push registry.ext.d2ux.net/ollama:latest

Erprobung

Bevor ein KI-Modell in den realen Workflow kommt, sollte es zuerst grundlegend erprobt werden. Dabei geht es weniger um Inhalte, sondern um das Verständnis der Schnittstellen, das Testen der Funktionsfähigkeit und das Sammeln erster Erfahrungen. So lässt sich früh einschätzen, wie stabil die API ist, wie sich verschiedene Modelle verhalten und welche Performance die eigene Hardware liefert. Erst danach lohnt sich der Blick auf Details wie Qualität, Geschwindigkeit oder konkrete Einsatzszenarien.

Teststart des API-Containers:

podman run -p 11434:11434 -it registry.ext.d2ux.net/ollama

Herunterladen eines Modelles:

curl http://localhost:11434/api/pull -d '{
  "name": "phi3"
}'

Erster Ticketsplitting-Test:

curl http://localhost:11434/api/generate -d '{
  "model": "phi3",
  "stream": false,
  "prompt": "Erfasse die Einzelaufgaben dieser Email und gib sie als Stichpunkte aus: ..."
}'

Verschiedene Modelle testen

Modelle haben unterschiedliche Anzahlen an Parametern, was sich – neben den eigentlichen Gewichten – spürbar auf die Verarbeitungsdauer und die Qualität der Ergebnisse auswirkt. Größere Modelle liefern in der Regel bessere Zerlegungen und verstehen Kontext tiefer, benötigen dafür aber deutlich mehr CPU-Ressourcen. Kleinere Modelle reagieren schneller, sind aber weniger präzise oder übersehen implizite Aufgaben. Auf Basis meiner Tests ergibt sich folgende relative und zum Teil subjektive Einschätzung:

Idee & Spezifikation: Der Taskbot

Beispielaufruf

Um den Taskbot auszuführen, müssen lediglich die Zugangsdaten für Redmine gesetzt und die gewünschte Verarbeitung konfiguriert werden. Der Bot liest anschließend alle passenden Tickets ein, extrahiert die Aufgaben mithilfe des lokalen KI-Modells und legt automatisch die entsprechenden Untertickets an.

export REDMINE_URL="https://redmine.example.com"
export REDMINE_TOKEN="1234567890abcdef"

./taskbot \
  -project=inbox \
  -from-status-id=1 \
  -to-status-id=2 \
  -ollama-url="http://192.168.2.250:11434" \
  -ollama-model="qwen2.5:3b-instruct-q4_K_M"

Der Aufruf filtert alle neuen Tickets (Status-ID 1) aus dem Projekt inbox, übergibt deren Beschreibung an das KI-Modell und erstellt für jede erkannte Aufgabe ein eigenes Subticket. Sobald die Zerlegung abgeschlossen ist, wird das Hauptticket automatisch in den Status in Bearbeitung (Status-ID 2) überführt.

Performancebewertung

Für diesen Anwendungsfall kommt ein klassischer Multi-Role-Standardserver zum Einsatz – konkret ein HP MicroServer in der Ausführung, wie er in vielen kleinen Standorten, Filialen und Edge-Umgebungen üblich ist. Solche Systeme laufen häufig als All-in-One-Server für Dateiablage, Containerlaufzeit und leichte Automatisierungsaufgaben – und eignen sich daher gut als Referenzplattform für eine rein lokale KI-Verarbeitung.

Hardwarebasis:

• Intel Xeon E-2314
• 16 GB RAM
• SSD-Speicher

Risikoanalyse

Die von mir in Ollama getesteten Modelle sind ausschließlich GGUF-Modelle. Damit entfällt ein wesentlicher Teil der üblichen Risiken, die bei Cloud- oder Remote-KI auftreten – insbesondere der mögliche Abfluss sensibler Daten. Die Verarbeitung läuft vollständig lokal, und die Modelle selbst besitzen keine Funktionen, um Informationen nach außen zu übertragen.

Was bleibt, sind zwei überschaubare Risikobereiche: Zum einen das inhaltliche Verhalten des Modells. Sprachmodelle können Aufgaben falsch interpretieren, unklare Passagen übersehen oder gelegentlich Halluzinationen erzeugen. Für den Anwendungsfall der Taskzerlegung ist das Risiko jedoch gut kontrollierbar, da die KI lediglich strukturierende Vorschläge erzeugt und keine sicherheits- oder prozesskritischen Entscheidungen trifft.

Zum anderen besteht das Risiko einer kompromittierten Supply Chain. Modelle sollten daher nur aus vertrauenswürdigen Quellen geladen und per Hash geprüft werden. Nutzt man ausschließlich offizielle Repositories wie Ollama, HuggingFace oder ModelScope, und verzichtet auf Modelle aus intransparenten Quellen, lässt sich dieses Risiko weitgehend minimieren.

Durch den lokal isolierten Betrieb – Modell, Verarbeitung und Taskbot im selben Sicherheitsperimeter – entsteht insgesamt ein sehr hohes Schutzniveau, das für den beschriebenen Einsatzzweck mehr als ausreichend ist.

Fazit

Ein realer, praktischer Nutzen zeigt sich sofort:

• Tickets werden automatisch strukturiert
• bessere Priorisierung und Transparenz
• sauberere Bearbeitungsketten
• keine externen Datenflüsse
• souveräne, vollständig lokale KI-Nutzung

Lokale KI funktioniert — einfach, sicher, souverän.