razzfazz.ai - local matters

1. Einführung: Die Renaissance der lokalen Intelligenz

Wir leben in einer Ära der digitalen Paradoxien. Auf der einen Seite erleben wir durch generative künstliche Intelligenz (GenAI) einen technologischen Sprung, der in seiner Tragweite mit der Erfindung des Internets vergleichbar ist. Modelle werden größer, schneller und fähiger. Auf der anderen Seite zieht sich das regulatorische Netz enger. Der EU AI Act ist nicht länger ein fernes bürokratisches Gespenst, sondern gebundene Realität, die Unternehmen dazu zwingt, ihre KI-Strategien grundlegend zu überdenken. In der aktuellen Ausgabe der SEQIS Quality News 2025-2, die unter dem Titel „AI Act & Local AI – Wege in eine verantwortungsvolle Zukunft“ steht, wird dieser Spannungsbogen deutlich skizziert. Es geht nicht mehr nur darum, was technisch machbar ist, sondern was rechtlich zulässig, ethisch vertretbar und ökonomisch sinnvoll ist.

Als jemand, der die Software-Qualitätssicherung seit den frühen Tagen der agilen Bewegung begleitet hat – von den ersten Gehversuchen mit Testautomatisierung bis hin zu komplexen Continuous-Integration-Pipelines –, sehe ich Parallelen. Damals ging es darum, Silos zwischen Entwicklung und Betrieb aufzubrechen (DevOps). Heute müssen wir das Silo zwischen „mächtiger KI in der Cloud“ und „sicheren Daten on-premise“ aufbrechen. Die Antwort darauf lautet nicht, Daten blind in die Cloud zu schieben und auf Verschlüsselung zu hoffen. Die Antwort lautet: Die Intelligenz muss zu den Daten kommen.

Mit razzfazz.ai haben wir bei SEQIS eine Plattform geschaffen, die genau diese Philosophie verkörpert: „Enabling local AI“. Es ist ein Manifest für digitale Souveränität. Warum ist das gerade jetzt so kritisch? Weil die Technologie endlich so weit ist. Wir müssen nicht mehr wählen zwischen „dumm und lokal“ oder „schlau und Cloud“. Durch die Symbiose aus spezialisierter Hardware (Unified Memory Architecture) und hocheffizienten Open-Source-Modellen wie Magistral und Devstral von Mistral AI können wir Enterprise-Grade-Intelligence lokal betreiben. razzfazz.ai ist also keine eigene “KI” sondern eine lokale Hardware + Softwareplattform um beliebige Open Source KI-Modelle laufen lassen zu können.

Dieser Artikel ist ein technischer Deep Dive, eine Bestandsaufnahme der Möglichkeiten. Wir werden analysieren, warum lokale Hardware plötzlich wieder „sexy“ ist, wie Reasoning-Modelle die Testanalyse revolutionieren und wir werden zehn konkrete, implementierbare Use-Cases durchspielen, die zeigen, wie Entwicklung und Testing im Jahr 2026 funktionieren sollten.

 

2. Der technologische Unterbau: Hardware und Architektur

Um zu verstehen, warum lokale KI heute eine viable Alternative zu Cloudangeboten wie OpenAI oder Anthropic darstellt, müssen wir einen Blick unter die Haube werfen. Die traditionelle PC-Architektur war für KI-Workloads denkbar ungeeignet. Der Flaschenhals war immer der Datentransfer zwischen der CPU (Central Processing Unit) und der GPU (Graphics Processing Unit) über den PCIe-Bus.

 

2.1 Unified Memory: Der Gamechanger

Die razzfazz.ai Box setzt auf eine Architektur, die diesen Flaschenhals eliminiert: Unified Memory. In dieser Konfiguration teilen sich CPU und GPU denselben physischen Arbeitsspeicherpool. Dies hat massive Implikationen für die Inferenz von Large Language Models (LLMs):

1. Kein Kopier-Overhead: Bei herkömmlichen Systemen müssen die Gewichte des neuronalen Netzes (die Model Weights) in den VRAM der Grafikkarte geladen werden. Ist das Modell zu groß für den VRAM (z.B. 24 GB bei einer Consumer RTX 4090), muss „Offloading“ betrieben werden – Teile des Modells werden auf den langsamen System-RAM ausgelagert, was die Performance dramatisch einbrechen lässt. Mit Unified Memory greift die GPU direkt auf den gesamten Speicher zu.
   
   
2. Kapazität für große Modelle: Die razzfazz.ai Box bietet bis zu 128 GB Unified Memory, wovon netto 96 GB exklusiv für KI-Modelle nutzbar sind. Das ermöglicht den Betrieb von Modellen, die weit über die Kapazitäten klassischer Desktop-GPUs hinausgehen. Wir können hier quantisierte Versionen von Modellen mit 70 Milliarden Parametern oder mehr laden, ohne Leistungseinbußen hinnehmen zu müssen.
   
   
3. Energieeffizienz: Ein oft unterschätzter Faktor, besonders im Hinblick auf ESG-Ziele (Environmental, Social, and Governance). Eine High-End-Server-GPU kann unter Last 400 bis 700 Watt verbrauchen. Ein Cluster davon benötigt eigene Klimatisierung. Die razzfazz.ai Hardware operiert in einem Bereich von 30 bis 300 Watt. Dies ist nicht nur gut für die Stromrechnung, sondern ermöglicht den Einsatz in normalen Büroumgebungen ohne dedizierten Serverraum.

In der folgenden Tabelle vergleichen wir die Architekturansätze, um die Positionierung der lokalen Lösung zu

Merkmal	Klassische Workstation + GPU	Cloud API (z.B. GPT-5)	razzfazz.ai Box (Local Unified Memory)
Speicherarchitektur	Getrennt (RAM + VRAM)	Opak / Verteilt	Unified (Shared RAM)
Max. Modellgröße	Begrenzt durch VRAM (z.B. 24 GB)	Sehr groß (Black Box)	Bis zu 96 GB (nutzbar)
Latenz	Niedrig (lokal)	Hoch (Netzwerkabhängig)	Sehr niedrig (lokal)
Datenschutz	Hoch (lokal)	Risiko (Drittanbieter)	Maximum (lokal + air-gapped möglich)
Energieverbrauch	Hoch (800W+)	Unbekannt (extern)	Effizient (30-300W)
Investitionsart	CAPEX (Hardware)	OPEX (Pay-per-Token)	CAPEX (einmalig)

 

2.2 Der Software-Stack: Orchestrierung der Intelligenz

Hardware ist nur so gut wie die Software, die sie steuert. Die razzfazz.ai Distribution basiert auf einem robusten Linux-Unterbau (Ubuntu 24.04 LTS) und integriert eine Suite von Open-Source-Tools, die nahtlos zusammenarbeiten.

• llama.cpp: Dies ist der Motor. Das Projekt hat die Demokratisierung von LLMs massiv vorangetrieben. Es ermöglicht die hocheffiziente Ausführung von GGUF-quantisierten Modellen auf Apple Silicon und anderen Unified-Memory-Architekturen. Durch Quantisierung (z.B. auf 4-bit oder 8-bit Integers) wird der Speicherbedarf massiv reduziert, bei vernachlässigbarem Qualitätsverlust.
  
  
• Workflow Automationen: Das Nervensystem. Während viele KI-Interaktionen noch über Chat-Fenster laufen, liegt die wahre Macht in der Automatisierung. Mittels unterschiedlicher open source Workflow Automationstools werden KI-Modelle in komplexe Abläufe eingebunden. Man kann es sich als „Klebstoff“ vorstellen, der die KI mit Jira, Git, Datenbanken oder E-Mail-Servern verbindet – und das alles lokal.
  
  
• Vektordatenbank (PostgreSQL + pgVector): Das Langzeitgedächtnis. Um RAG (Retrieval Augmented Generation) lokal umzusetzen, benötigen wir einen Speicher für semantische Embeddings. PostgreSQL läuft effizient auf der Box und ermöglicht es der KI, „Wissen“ firmeninterner Dokumente abzurufen, ohne dass das Modell neu trainiert werden muss.
  
  
• Open WebUI: Die Schnittstelle zum Menschen. Eine benutzerfreundliche Oberfläche, die sich wie ChatGPT anfühlt, aber vollständig lokal läuft und Multi-User-Support sowie Modell-Management bietet.

 

3. Die Modelle: Magistral und Devstral

Die Hardware stellt die Arena, aber die Modelle sind die Athleten. Wir konzentrieren uns in diesem Artikel auf zwei spezifische europäische Modelle von Mistral AI, die für Entwicklung und Testing besonders relevant sind: Magistral und Devstral. Beide repräsentieren den neuesten Stand der Open-Weights-Forschung und sind für den lokalen Betrieb optimiert.

 

3.1 Magistral: Der Analyst mit Tiefgang (Reasoning Model)

„Magistral“ markiert einen Paradigmenwechsel bei Mistral AI. Es ist das erste dedizierte Reasoning-Modell des Unternehmens. Anders als klassische LLMs, die primär darauf trainiert sind, statistisch wahrscheinliche Wortfolgen zu generieren, wurde Magistral darauf optimiert, Probleme durch eine „Kette von Gedanken“ (Chain-of-Thought, CoT) zu lösen.

Was bedeutet „Reasoning“ technisch? Wenn Sie Magistral eine komplexe Frage stellen, antwortet es nicht sofort. Es generiert zunächst einen internen Monolog (oft sichtbar in <think> Tags), in dem es das Problem zerlegt, Hypothesen aufstellt, diese prüft und erst dann das Endergebnis formuliert. Dieser Prozess ähnelt dem „System 2“ Denken nach Daniel Kahneman – langsam, logisch, berechnend.

Leistungsdaten und Architektur:

• Größe: Magistral Small ist ein 24B (24B = 24 billions, 24 Milliarden) Parameter Modell. Das ist der „Sweet Spot“ für lokale Inferenz auf unserer Hardware. Es ist klein genug, um schnell zu sein, aber groß genug für komplexe Logik.
  
  
• Kontext: Es unterstützt ein Kontextfenster von 128k Token. Das bedeutet, es kann hunderte Seiten Dokumentation oder umfangreiche Code-Dateien im Arbeitsspeicher halten und in seine Überlegungen einbeziehen.
  
  
• Benchmarks: Auf dem AIME2024 Benchmark (Mathematik und Logik) erreicht die Medium-Variante Scores von über 73%, was eine massive Steigerung gegenüber nicht-reasoning Modellen darstellt.
  
  
• Anwendungsgebiet: Software-Architektur, Requirements Engineering, logische Prüfung von Testfällen, komplexe Datenanalyse.

Ein interessantes Feature ist die Geschwindigkeit bei einfachen Aufgaben: Durch „Flash Answers“ kann das Modell bei weniger komplexen Anfragen extrem schnell antworten, skaliert aber bei Bedarf seine Rechenzeit für tiefere Analysen hoch.

 

3.2 Devstral: Der Agentische Entwickler (Coding Model)

Während Magistral der Denker ist, ist Devstral der Macher. Es wurde spezifisch für Software Engineering Aufgaben trainiert und verfeinert. Es ist nicht einfach nur eine Autovervollständigung; es ist für „Agentic Workflows“ konzipiert.

Der Unterschied zu klassischen Code-Modellen:

Frühere Modelle wie CodeLlama waren gut darin, eine Funktion zu vervollständigen. Devstral hingegen versteht den Kontext eines gesamten Projekts. Es wurde in Zusammenarbeit mit All Hands AI entwickelt und darauf trainiert, wie ein Entwickler zu agieren: Es kann Dateien lesen, Änderungen planen, Code editieren und Shell-Befehle ausführen (in einer gesicherten Sandbox).

Spezifikationen:

• Spezialisierung: Es basiert auf Mistral Small 3.1, wobei der Vision-Encoder entfernt wurde, um sich rein auf Text und Code zu konzentrieren.
  
  
• Performance: Im SWE-Bench Verified, dem Goldstandard für automatisches Software-Engineering, erreicht Devstral einen Score von 46.8%. Zum Vergleich: GPT-4o mini liegt bei ca. 23.6%. Das bedeutet, Devstral löst fast die Hälfte aller realen GitHub-Issues autonom korrekt – ein Wert, der für ein Modell dieser Größe (24B) sensationell ist.
  
  
• Tokenizer: Es nutzt den Tekken-Tokenizer mit einem Vokabular von 131k, was besonders effizient für Source Code ist (weniger Token pro Codezeile = mehr Kontext im Speicher).

Zusammen bilden Magistral und Devstral ein unschlagbares Team: Der eine plant und prüft (Magistral), der andere führt aus und implementiert (Devstral).

 

4. Zehn Use-Cases für Entwicklung und Testing

Theorie ist gut, Praxis ist besser. Wie setzen wir diese PS auf die Straße? Im Folgenden skizziere ich zehn detaillierte Use-Cases, die wir bei SEQIS nutzen und die mit der razzfazz.ai Box umsetzbar sind. Jeder Use-Case nutzt die spezifischen Stärken von Magistral (Reasoning) oder Devstral (Coding) und die Orchestrierung durch Workflow Automation.

 

Use-Case 1: Der Requirements-Architekt (Modell: Magistral)

Herausforderung:

Anforderungen in der Softwareentwicklung sind oft unpräzise. Lastenhefte bestehen aus Prosatext, E-Mails und Meeting-Notizen. Die Überführung in formale Modelle (wie UML) ist ein manueller, fehleranfälliger Prozess. Missverständnisse hier führen zu den teuersten Fehlern später im Projekt.

Die Lösung mit lokaler AI:

Wir nutzen Magistral, um unstrukturierte Anforderungen in formale Diagramme zu übersetzen.

1. Input: Der Nutzer lädt ein PDF-Lastenheft oder kopiert Text in das Open WebUI.
   
   
2. Reasoning-Prozess: Ein automatisierter Workflow übergibt den Text an Magistral mit dem System-Prompt: „Analysiere diesen Text auf Akteure, Use Cases und Ablauflogik. Identifiziere logische Lücken (z.B. fehlende Fehlerbehandlung).“
   
   
3. Generierung: Magistral generiert validen Code für PlantUML oder Mermaid (z.B. für ein Aktivitätsdiagramm). Dank seiner Reasoning-Fähigkeit kann es implizite Annahmen explizit machen (z.B. „Wenn der User nicht eingeloggt ist, muss er zum Login geleitet werden“, auch wenn das im Text fehlt).
   
   
4. Visualisierung: Mittels Workflow Automation wird der PlantUML-Code direkt in eine Grafik gerendert und diese zusammen mit einer Liste der identifizierten Lücken zurückgeliefert.
   
   

Mehrwert:

Standardisierung der Dokumentation und Qualitätssicherung der Anforderungen bevor eine Zeile Code geschrieben wird („Shift Left“). Da Anforderungen oft sensible Geschäfts

 

Use-Case 2: Der Gnadenlose Test-Designer (Modell: Magistral)

Herausforderung:

Testfallerstellung ist oft eine monotone Arbeit. Tester neigen dazu, den „Happy Path“ zu testen und Randfälle zu übersehen. Kombinatorische Explosionen (z.B. bei komplexen Formularen) überfordern menschliche Tester oft.

Die Lösung mit lokaler AI:

Der „Testing Buddy“ nutzt Magistrals logische Tiefe.

1. Input: Eine User Story oder die Ergebnisse aus Use-Case 1.
   
   
2. Analyse: Magistral wendet formale Testmethoden an, wie Äquivalenzklassenbildung und Grenzwertanalyse. Es „denkt“ sich Szenarien aus, die das System brechen könnten (Destructive Testing).
   
   
3. Workflow:
   - Magistral identifiziert alle Eingabefelder.
   - Es generiert Testdaten für Grenzwerte (z.B. Alter 17, 18, 120, -1).
   - Es erstellt eine Testmatrix.
   
   
4. Über die Workflow Automation werden diese Testfälle direkt in das Format von Jira Xray oder Tricentis Tosca konvertiert und via API in das Testmanagement-Tool importiert.
   
   

Mehrwert:

Massive Zeitersparnis und eine höhere Testabdeckung durch systematische, KI-gestützte Analyse. Die Daten

 

Use-Case 3: Legacy Code Refactoring & Modernisierung (Modell: Devstral)

Herausforderung:

Viele Unternehmen sitzen auf „Legacy Code“ – funktionierende, aber veraltete Software (z.B. Java 6, alter PHP-Code), die niemand mehr anfassen will. Das Wissen darüber ist oft mit Mitarbeitern in Pension gegangen.

Die Lösung mit lokaler AI:

Devstral nutzt sein riesiges Kontextfenster (128k), um ganze Dateien oder Module zu verstehen.

1. Kontext: Wir laden den Quellcode einer alten Komponente in den Kontext von Devstral.
   
   
2. Agentic Task: Der Prompt lautet: „Analysiere diesen Code. Erkläre die Business-Logik. Schlage ein Refactoring auf moderne Standards (z.B. Java 21 Records, Streams) vor. Behalte die Logik bei.“
   
   
3. Iterativer Prozess: Devstral schreibt den Code um. Da es agentisch agiert, kann es auch Unit-Tests für den alten Code schreiben, um sicherzustellen, dass der neue Code dasselbe tut (Regressionstesting).
   
   
4. Output: Ein Diff-File oder ein direkter Commit-Vorschlag im lokalen GitLab.
   
   

Mehrwert:

Risikominimierung bei der Modernisierung. Da Legacy-Code oft tiefes Firmen-Know-how enthält, darf dieser keinesfalls in öffentliche Cloud-

 

Use-Case 4: Synthetische Testdaten-Generierung (DSGVO-konform) (Modell: Magistral)

Herausforderung:

Für Tests werden realistische Daten benötigt. Produktionsdaten zu anonymisieren ist aufwendig und birgt Re-Identifikationsrisiken. Einfache Zufallsgeneratoren erzeugen oft fachlichen Unsinn (z.B. PLZ passt nicht zum Ort).

Die Lösung mit razzfazz.ai:

Magistral generiert semantisch korrekte, synthetische Daten.

1. Modellierung: Wir definieren das Datenschema (z.B. JSON-Struktur für einen „Versicherungsnehmer“).
   
   
2. Logik-Injektion: Wir geben Magistral Regeln: „Erzeuge 50 Datensätze für Kunden aus Österreich. Wenn Bundesland = Wien, dann muss die PLZ mit 1 beginnen. Das Geburtsdatum muss zum Status ‚Pensionist‘ passen.“
   
   
3. Reasoning: Magistral nutzt seine Logik-Fähigkeiten, um diese Abhängigkeiten einzuhalten (etwas, woran einfachere Modelle oft scheitern).
   
   
4. Persistenz: Die Workflow Automation schreibt die generierten Daten direkt in die lokale PostgreSQL-Datenbank der Box, von wo aus sie in Testumgebungen injiziert werden können.
   
   

Mehrwert:

100% DSGVO-Compliance, da keine echten Daten berührt werden, bei gleichzeitig hoher fachlicher Qualität der Testdaten.

 

Use-Case 5: Der Autonome Bug-Hunter (Modell: Devstral)

Herausforderung:

Bugs zu finden, die nur unter bestimmten Bedingungen auftreten (z.B. Race Conditions), ist extrem schwierig. Statische Codeanalyse findet Syntaxfehler, aber keine logischen Probleme im Ablauf.

Die Lösung mit razzfazz.ai:

Ein lokaler Agent, der Git-Commits überwacht.

1. Trigger: Ein Entwickler pusht Code. Die Workflow Automation detektiert den Change.
   
   
2. Analyse: Devstral liest die Änderungen (Diff) und die betroffenen Dateien im Volltext.
   
   
3. Reasoning: Devstral sucht nach logischen Fehlern: „In Zeile 50 wird auf user zugegriffen, aber user könnte null sein, wenn die Datenbankabfrage in Zeile 40 fehlschlägt. Es fehlt ein Null-Check.“.
   
   
4. Report: Der Agent postet diesen Hinweis als Kommentar direkt in den Merge Request im lokalen Git-Server.
   
   

Mehrwert:

Ein „Pair Programmer“, der nie schläft und jeden Commit reviewt. Die Fehlererkennung passiert bevor der Code

 

Use-Case 6: Self-Healing Unit Tests (Modell: Devstral)

Herausforderung:

Code ändert sich, Tests brechen. Die Wartung von Unit Tests ist oft teurer als die Entwicklung der Features selbst.

Die Lösung mit razzfazz.ai:

Devstrals Fähigkeiten im Bereich „Agentic Coding“.

1. Szenario: Ein Build schlägt fehl, weil ein Unit Test rot ist.
   
   
2. Diagnose: Die Workflow Automation fängt den Fehler aus der CI/CD-Pipeline (z.B. Jenkins) ab und sendet den Stack Trace sowie den geänderten Code an Devstral.
   
   
3. Fix: Devstral analysiert, warum der Test fehlschlägt. War es eine beabsichtigte Änderung der Logik? Dann muss der Test angepasst werden. War es ein Bug? Dann muss der Code gefixt werden.
   
   
4. Aktion: Devstral schlägt den korrigierten Code vor. In einer fortgeschrittenen Ausbaustufe kann der Agent den Fix lokal ausführen, die Tests erneut laufen lassen und bei Erfolg den Fix committen.
   
   

Mehrwert:

Drastische Reduktion der Wartungsaufwände für Testsuiten und stabilere

 

Use-Case 7: Intelligente Log-Analyse und Root Cause Analysis (Modell: Magistral)

Herausforderung:

Wenn in der Produktion oder im Testsystem etwas schiefgeht, müssen Ops-Teams oft Gigabytes an Logfiles durchwühlen. Die Korrelation von Fehlern über verschiedene Microservices hinweg ist für Menschen schwer.

Die Lösung mit razzfazz.ai:

Magistral als forensischer Analyst.

1. Ingest: Relevante Log-Ausschnitte (z.B. die 5 Minuten rund um einen Crash) werden an die razzfazz.ai Box übermittelt.
   
   
2. Analyse: Magistral korreliert Zeitstempel und Fehlermeldungen. Es erkennt Muster: „Der Timeout im Payment-Service (14:00:01) verursachte die NullPointerException im Order-Service (14:00:02).“.
   
   
3. Erklärung: Das Modell generiert eine Zusammenfassung in natürlicher Sprache für das Ops-Team: „Ursache ist wahrscheinlich eine Überlastung der Datenbank X. Empfohlene Maßnahme: Connection Pool prüfen.“
   
   

Mehrwert:

Signifikante Reduktion der MTTR (Mean Time To Repair). Das Wissen aus den Logs verlässt dabei nie das

 

Use-Case 8: Automatisierte Dokumentationspflege (Modell: Devstral)

Herausforderung:

Code-Dokumentation ist fast immer veraltet. Niemand aktualisiert gerne das Wiki oder die Swagger-Definitionen nach einer Code-Änderung.

Die Lösung mit razzfazz.ai:

Ein „Documentation Buddy“, der den Codebestand überwacht.

1. Scan: Devstral iteriert regelmäßig über das Repository.
   
   
2. Vergleich: Es vergleicht den Code mit der existierenden Dokumentation (z.B. Markdown-Files oder Docstrings).
   
   
3. Update: Bei Abweichungen generiert Devstral aktualisierte Beschreibungen der Klassen, Methoden und API-Endpunkte. Es kann sogar Diagramme (siehe Use-Case 1) aktualisieren.
   
   
4. Commit: Die aktualisierte Doku wird als Pull Request eingereicht.
   
   

Mehrwert:

Die Dokumentation ist immer „live“ und synchron mit dem Code. Das Onboarding neuer Entwickler wird

 

Use-Case 9: Der Agile Ticket-Assistent (Agile Buddy)

Herausforderung:

In Dailies wird viel besprochen, aber wenig dokumentiert. „Machst du noch schnell das Ticket für den Bug im Login?“ – und dann wird es vergessen oder nur rudimentär („Login geht nicht“) angelegt.

Die Lösung mit razzfazz.ai:

Der Agile Buddy, integriert in den Kommunikationsfluss.

1. Input: Ein Entwickler spricht eine kurze Notiz in die mobile App des Open WebUI oder schreibt einen schnellen Satz in den Chat: „Hey Jira, Bug im Checkout-Prozess. Wenn man als Gast bestellt und PayPal wählt, kommt ein 500er Fehler.“
   
   
2. Processing: Die Box nutzt Speech-to-Text (falls Audio) und dann Magistral zur Strukturierung.
   
   
3. Enrichment: Magistral fragt fehlende Infos ab oder ergänzt Kontext (z.B. Browser-Version, Priority). Es formuliert eine professionelle Fehlerbeschreibung mit „Steps to Reproduce“.
   
   
4. Action: Über die Workflow Automation wird das Ticket via Jira-API erstellt und dem richtigen Team zugewiesen.
   
   

Mehrwert:

Senkung der Hürde für saubere Do

 

Use-Case 10: Lokaler RAG-Knowledge-Bot für Tester (Magistral + PostgreSQL + pgVector)

Herausforderung:

Tester müssen oft wissen: „Wie war das nochmal mit der Storno-Logik bei Tarif X?“ Die Antwort steht irgendwo in 500 PDFs im SharePoint.

Die Lösung mit razzfazz.ai:

Ein lokales RAG-System (Retrieval Augmented Generation).

1. Indizierung: Alle Fachkonzepte, Wikis und alten Testpläne werden von der Box eingelesen, in Vektoren umgewandelt und in der lokalen PostgreSQL-Datenbank gespeichert.
   
   
2. Query: Der Tester fragt im Chat: „Wie verhält sich das System bei Storno nach 14 Tagen?“
   
   
3. Retrieval & Generation: Die Workflow Automation sucht die relevanten Textstellen in PostgreSQL. Magistral erhält diese als Kontext und formuliert eine präzise Antwort inklusive Quellenangabe („Laut Fachkonzept V2.3, Seite 45...“).
   
   

Mehrwert:

Das gesamte Firmenwissen ist sofort und im Dialog verfügbar. Da kein Dokument das Haus verlässt (anders als bei ChatGPT Uploads), bleibt das IP (Intellectual Property) geschützt.

 

5. Implementierung: Die Workflow Automation Architektur

Wie setzen wir diese Use-Cases technisch zusammen? Das Herzstück der Orchestrierung auf der
razzfazz.ai Box ist die Workflow Automation mit unterschiedlichen Werkzeugen. Im Gegensatz zu Cloud-Diensten wie Zapier oder n8n läuft diese hier lokal im Docker-Container, direkt neben dem KI-Modell.

Ein typischer Workflow (z.B. für den Bug-Hunter, Use-Case 5) folgt einem klaren Muster, das wir als „Agentic Pattern“ bezeichnen können:

1. Trigger Node: Horcht auf Ereignisse (Webhook von GitLab, Dateiänderung, Zeitplan).
   
   
2. Data Fetching: Holt die notwendigen Daten (Code, Logs, Text).
   
   
3. AI Agent Node / Chain: Hier passiert die Magie. Wir nutzen den „Basic LLM Chain“ Node oder spezialisierte Agenten-Knoten. Dieser Knoten kommuniziert über http://localhost:9090 mit dem llama.cpp Server.

Wichtig: Wir konfigurieren hier Parameter wie temperature (niedrig für Code/Logik, höher für kreative Texte) und den Sys

 

1. Tool Use: Der Agent kann entscheiden, Tools aufzurufen. In der Workflow Automation können wir dem Agenten „Tools“ bereitstellen, z.B. „Calculator“, „Database Query“ oder „Git Commit“. Devstral ist besonders gut darin, zu erkennen, wann es welches Tool nutzen muss.
   
   
2. Output Parser: Die Antwort der KI (oft JSON) wird geparst und validiert.
   
   
3. Action Node: Das Ergebnis wird verarbeitet (Jira Ticket erstellen, E-Mail senden, Datei speichern).
   
   

Visuelle Metapher für den Bericht:

Stellen Sie sich die Workflow Automation wie eine digitale Fertigungsstraße vor. Die Rohstoffe (Daten) kommen rein, Roboterarme (Nodes) bearbeiten sie. Aber an einer Station sitzt jetzt kein starrer Roboter mehr, sondern ein intelligenter Handwerker (das KI-Modell), der Entscheidungen trifft, Qualitätskontrollen durchführt und improvisieren kann, wenn das Werkstück leicht von der Norm abweicht. Das ist der Unterschied zwischen klassischer Automatisierung und KI-Agenten.

 

6. Strategische Einordnung: Cloud vs. Local im Kostenvergleich

Ein häufiges Gegenargument gegen lokale KI sind die Anschaffungskosten (CAPEX). „Die Cloud ist doch billiger, ich zahle nur, was ich nutze.“ Das ist ein Trugschluss, besonders bei „Reasoning“-Modellen und agentischen Workflows.

1. Token-Ökonomie: Reasoning-Modelle wie Magistral oder OpenAI o1 generieren massive Mengen an „internen Gedanken-Tokens“. In der Cloud bezahlen Sie für jeden dieser Gedanken. Ein einziger komplexer Refactoring-Task kann tausende Input- und zehntausende Output-Tokens verbrauchen. Bei täglicher Nutzung durch ein Entwicklerteam summieren sich diese OPEX (Operational Expenditures) enorm.
   
   
2. Flatrate-Effekt: Die razzfazz.ai Box ist eine Einmalinvestition. Ob Sie das Modell 10-mal oder 10.000-mal am Tag fragen, kostet dasselbe (abgesehen vom Strom). Das fördert Experimentierfreude. Entwickler zögern nicht, die KI zu nutzen, weil „das Budget knapp ist“.
   
   
3. Latenz: Für Agenten, die viele kleine Schritte hintereinander ausführen (Schleifen), addiert sich die Netzwerklatenz der Cloud. Lokal erfolgt der Aufruf im Millisekundenbereich über localhost.

 

7. Fazit: Local matters.

Der Titel dieses Artikels ist Programm. „Local matters“ ist nicht nur eine technologische Aussage, es ist eine Haltung. Der EU AI Act hat Risikoklassen definiert und fordert Transparenz und Governance. Viele Unternehmen sehen das als Bürde. Wir bei SEQIS sehen es als Chance.

Lösungen wie die razzfazz.ai Box beweisen, dass Compliance kein Innovationshemmer sein muss. Im Gegenteil: Indem wir die KI lokal betreiben, gewinnen wir Freiheiten zurück, die wir in der Cloud längst aufgegeben hatten.

• Wir können Magistral nutzen, um unsere geheimsten Geschäftsstrategien zu analysieren.
  
  
• Wir können Devstral auf unseren wertvollsten Asset – unseren Source Code – loslassen.
  
  
• Wir können Systeme bauen, die tief in unsere IT-Landschaft integriert sind, ohne Firewalls zu durchlöchern.

 

Kostenfaktor	Cloud AI (z.B. GPT-4 API)	Local AI (razzfazz.ai Box)
Reasoning (Denkzeit)	Teuer (wird per Token abgerechnet)	Kostenlos (inkludiert)
Code-Scan (großer Kontext)	Sehr teuer (großer Input-Kontext)	Kostenlos
Wiederkehrende Tasks	Linear steigende Kosten	Fixkosten (Amortisation)
Datentransfer	Kosten + Sicherheitsrisiko	Kein Transfer, keine Kosten

 

Die Zukunft der KI ist hybrid, aber das Herzstück – die Verarbeitung sensibler Daten und intellektuellen Eigentums – muss lokal liegen. Unified Memory Hardware, Open-Source-Modelle und intelligente Orchestrierung mittels der Workflow Automation machen dies heute möglich.

Ich lade Sie ein: Warten Sie nicht darauf, dass die Cloud sicher wird. Holen Sie sich die Sicherheit ins Haus. Experimentieren Sie. Bauen Sie Ihren ersten lokalen Agenten. Lassen Sie uns gemeinsam die Zukunft der Softwarequalität gestalten – effizient, souverän und lokal.

Ihr Alexander Vukovic SEQIS Founder & Chief Evangelist