Kategorie: Für IT-Verantwortliche

⛵ Ich spreche hier nicht zu Laien. Ich spreche zu Leuten, die Cloud-Lock-in aus eigener Erfahrung kennen, die schon einmal eine Migrations-Nachkalkulation gemacht haben und die wissen, was ein API-Breaking-Change mitten im Produktivbetrieb bedeutet.
Ihr seid die Zielgruppe, die meine Architektur-Entscheidungen versteht – ohne dass ich sie erklären muss. Deshalb rede ich hier anders als in den Artikeln für Ärzte und Anwälte. Kein Berufsrecht, keine Paragraphen. Architektur, Deployment, Compliance-Druck, Schatten-KI.
Fangen wir mit dem Problem an, das ihr gerade habt.
Das Schatten-KI-Problem landet auf eurem Tisch
Über 60 Prozent der Mitarbeiter nutzen bei der Arbeit generative KI-Tools – und automatisieren so auf eigene Faust an der IT-Abteilung und Sicherheitsbeauftragten vorbei. Das ist keine Schätzung. Das ist die dokumentierte Realität in deutschen Unternehmen 2025/2026.
Die Konsequenz kennt ihr: Daten fließen in Systeme, die ihr nicht kontrolliert. Über Browser-Interaktionen, die ihr nicht erfasst. In Modelle, die auf Servern laufen, auf die ihr keinen Zugriff habt. Mit Datenschutzerklärungen, die sich ändern können.
Das ist kein Compliance-Problem der Fachabteilung. Das ist ein IT-Sicherheitsproblem, das auf eurem Tisch landet – spätestens beim nächsten Audit.
Die klassische Antwort der IT ist Verbote. Blockieren, einschränken, schulen. Das funktioniert für drei Wochen. Dann suchen die Mitarbeiter einen anderen Weg, weil das Werkzeug ihren Arbeitsalltag produktiver macht und sie das nicht aufgeben wollen.
Die bessere Antwort ist ein kontrolliertes Angebot. Ein KI-System, das ihr selbst bereitstellt, das ihr vollständig kontrolliert und das kein Daten nach außen sendet.
Fleet Navigator ist genau das.
Die Architektur-Entscheidung: lokal statt Cloud
Ich bin Entwickler. Ich erkläre keine Architektur-Entscheidungen mit Marketing-Sprache, sondern mit dem, was technisch passiert.
Fleet Navigator besteht aus drei Schichten, die zusammen eine vollständige Desktop-Erfahrung ergeben.
Die Tauri-Hülle ist das, was der Nutzer zuerst sieht: ein nativer Splash-Screen beim Start, während im Hintergrund alle Dienste geordnet hochfahren. Beim Beenden erscheint ein Shutdown-Splash, während die Dienste sauber heruntergefahren werden. Kein Terminal-Fenster, kein Browser-Tab – das Gefühl einer echten Anwendung. Der Unterschied zur klassischen Desktop-App: Die Logik steckt nicht in der Tauri-Hülle, sondern im Go-Backend. Tauri ist die Verpackung, die das für den Nutzer unsichtbar macht.
Das Go-Backend ist der eigentliche Motor. Es läuft als ein einziger Prozess auf dem lokalen Rechner oder Server, liefert auf Port 2025 sowohl die REST-API als auch das eingebettete Vue.js-Frontend aus. Kein Kubernetes-Cluster, kein Container-Orchestrator, keine externe Abhängigkeit.
Lokale KI-Modelle im GGUF-Format werden über llama.cpp inferiert – auf NVIDIA via CUDA, AMD und Intel via Vulkan, Apple Silicon via Metal. Die Modelle liegen lokal in ~/.fleet-navigator/models/. Sie verlassen das Gerät nicht.
Netzwerkverkehr nach außen: null. Keine Telemetrie, keine API-Calls, keine Update-Pings ohne explizite Nutzeraktion. Das ist keine Vertragszusage das ist die Architektur.
Für einen IT-Leiter bedeutet das: Du weißt genau, was dieses System tut. Du kannst es in der Firewall isolieren. Du kannst es auditieren. Du kannst den Netzwerkverkehr mit einem Packet-Sniffer verifizieren. Kein Cloud-Dienst der Welt gibt dir diese Kontrolle.
Deployment: eine Binary, ein Dienst
Das ist der Teil, den Administratoren lieben oder der sie skeptisch macht je nachdem, wie oft sie schon komplexe Deployments bereut haben.
Fleet Navigator ist eine einzige ausführbare Datei. Kein Installer, keine Abhängigkeiten, kein Runtime-Environment außer dem Betriebssystem selbst.
# Linux-Deployment in drei Schritten
wget https://fleet-data.de/download/fleet-navigator-linux-amd64
chmod +x fleet-navigator-linux-amd64
./fleet-navigator-linux-amd64
Für den produktiven Betrieb gibt es eine fertige systemd-Unit:
[Unit]
Description=Fleet Navigator
After=network.target
[Service]
ExecStart=/opt/fleet-navigator/fleet-navigator-linux-amd64
Restart=always
User=fleet
[Install]
WantedBy=multi-user.target
Die Binary ist für Linux amd64, Linux arm64, Windows amd64, macOS Intel und macOS Apple Silicon verfügbar – kompiliert aus demselben Go-Codebase, ohne plattformspezifische Abhängigkeiten. Dateigröße: rund 36 MB.
Alle Daten liegen in ~/.fleet-navigator/ in SQLite-Datenbanken im WAL-Modus. Backup ist ein cp -r ~/.fleet-navigator/ /backup/. Migration ist dasselbe. Kein Datenbankserver, kein Migrationsscript, kein ORM-Mapping das beim Update bricht.
API-First: Integration in bestehende Systeme
Fleet Navigator stellt über 100 REST-Endpunkte bereit. Das System ist von Anfang an als integrierbares Backend konzipiert, nicht als Insellösung.
Authentifizierung via JWT-Token mit konfigurierbarer Ablaufzeit. CSRF-Schutz auf allen zustandsändernden Anfragen. Rate-Limiting auf Login-Endpunkten. Security Headers out of the box.
Die Chat-API nutzt Server-Sent Events für Echtzeit-Streaming:
POST /api/chat/:id/send → SSE-Stream
POST /api/chat/:id/abort → Laufende Anfrage abbrechen
GET /api/system/status → Health-Check
Fleet Mates ermöglichen die verschlüsselte Verbindung externer Anwendungen – andere Fleet-Navigator-Instanzen, Mail-Clients, Browser-Automationen oder eigene Tools. Das Pairing-Protokoll nutzt Ed25519 für Authentifizierung und X25519 für den Schlüsselaustausch. Kommunikation läuft über AES-256-GCM. Ende-zu-Ende-verschlüsselt, verifizierbar, ohne Cloud-Relay.
Für IT-Architekten bedeutet das: Fleet Navigator kann als KI-Backend in bestehende Unternehmensanwendungen integriert werden, ohne dass Daten das interne Netz verlassen.
NIS2, EU AI Act und Schatten-KI-Haftung
Mit dem Inkrafttreten der NIS2-Richtlinie zum 6. Dezember 2025 ohne jegliche Übergangsfristen steigen die Anforderungen an Informations- und IT-Sicherheit deutlich. Unternehmen müssen systematisches Risikomanagement nachweisen – und zwar jetzt, nicht nach einer Schonfrist.
Schatten-KI ist in diesem Kontext kein Kavaliersdelikt mehr. Fragmentierte IT-Stacks, isolierte Zugriffsrechte und unkontrollierte KI-Nutzung sind 2026 mehr denn je ein Geschäfts- und Haftungsrisiko – nicht zuletzt für die Chefetage.
Fleet Navigator löst dieses Problem strukturell: Wenn das Unternehmen selbst ein KI-System betreibt, das keine Daten nach außen sendet, gibt es keine Schatten-KI-Problematik. Mitarbeiter nutzen das bereitgestellte System. IT behält die Kontrolle. Audit-Trail liegt lokal vor.
Zum EU AI Act: Fleet Navigator fällt als lokal betriebenes Werkzeug ohne autonome Entscheidungsfunktion in die Kategorie minimales Risiko. Keine Konformitätsbewertung, keine Registrierungspflicht. Auch reine Nutzer haben Pflichten: geschultes Aufsichtspersonal, Protokollierung für mindestens sechs Monate und die Sicherung relevanter Eingabedaten. Diese Anforderungen sind mit Fleet Navigator erfüllbar – alle Daten liegen lokal, Logs in ~/.fleet-navigator/logs/, vollständige Kontrolle beim Betreiber.
ISO 27001 und Cloud-KI – der unterschätzte Audit-Aufwand
Viele IT-Leiter denken: „Unser Cloud-KI-Anbieter hat ISO 27001. Damit sind wir abgesichert.“
Das ist ein Irrtum. Und er kostet beim nächsten Audit Zeit und Geld.
ISO 27001 zertifiziert einen Anbieter für seine eigenen Prozesse – nicht für eure. Ihr seid als Betreiber eigenständig verantwortlich. Die Zertifizierung des Anbieters erleichtert euren Audit, ersetzt ihn aber nicht.
Was konkret auf euren Tisch kommt, wenn ihr Cloud-KI einbindet:
Annex A.5.19 – Lieferantenbeziehungen. Jeder Cloud-KI-Anbieter wird zum Lieferanten im Sinne des Standards. Das bedeutet: Risikoanalyse vor der Einführung, schriftliche Vereinbarungen über Sicherheitsanforderungen, regelmäßige Überprüfung. Pro KI-Tool eine separate Analyse. Wer drei verschiedene Cloud-KI-Systeme im Haus hat ChatGPT, Copilot, ein Fachanbieter – hat dreimal diesen Aufwand. Und bei jeder Änderung des Anbieters, jeder Akquisition, jeder neuen Nutzungsbedingung muss die Analyse wiederholt werden.
Annex A.5.23 – Cloud-Dienste. Diese Kontrolle ist explizit für Cloud-Dienste gedacht und verlangt Richtlinien für Auswahl, Nutzung, Verwaltung und Beendigung. Das klingt handhabbar bis man die Sub-Processor-Kette ausleuchtet. Ein Cloud-KI-Anbieter mit EU-Hosting nutzt oft US-amerikanische Infrastruktur für bestimmte Komponenten. OpenAI nutzt Microsoft Azure. Wer steckt hinter Azure in welcher Region? Das müsst ihr für den Audit dokumentieren.
Annex A.8.10 – Löschung von Informationen. ISO 27001 verlangt nachweisbare Löschung. Bei Cloud-KI ist die Standardantwort der Anbieter: „Wir löschen die Daten nach X Tagen.“ Ob das wirklich passiert und wie es nachgewiesen werden kann das ist die Frage, die der Auditor stellt. Wer keine befriedigende Antwort hat, bekommt ein Finding.
Das CLOUD Act Problem im ISO-Kontext. US-Behörden können unter dem CLOUD Act Daten von US-Unternehmen anfordern unabhängig vom Serverstandort. Das ist ein Restrisiko, das in der Risikobehandlung dokumentiert werden muss. Nicht als Showstopper, aber als offenes Risiko mit Behandlungsmaßnahme. Was ist die Behandlungsmaßnahme? Meist: akzeptieren und dokumentieren. Das ist formal korrekt aber es bleibt ein offenes Risiko in eurem ISMS.
Schatten-KI als ISO-Finding. Wenn Mitarbeiter Cloud-KI-Tools ohne IT-Freigabe nutzen, ist das im ISO-27001-Kontext ein klares Finding fehlende Kontrolle über Lieferantenbeziehungen, fehlende Datenschutzmaßnahmen, fehlende Risikoanalyse. Ein Re-Audit nach einem solchen Finding kostet zwischen 5.000 und 15.000 Euro. Besser: das Problem vorher lösen.
Wie Fleet Navigator das vereinfacht.
Fleet Navigator ist kein Cloud-Dienst. Es gibt keinen Lieferanten im Sinne von Annex A.5.19. Es gibt keinen Cloud-Dienst im Sinne von Annex A.5.23. Es gibt keine Sub-Processor-Kette. Es gibt keine CLOUD-Act-Exposition.
Für die Risikoanalyse bedeutet das: ein lokales System, bekannte Angriffsfläche, vollständige Kontrolle. Löschung ist nachweisbar ein rm -rf ~/.fleet-navigator/ mit Dokumentation. Keine offenen Anbieterrisiken im ISMS.
Das macht Fleet Navigator nicht zu einer ISO-27001-Lösung. Aber es macht den ISO-27001-Audit erheblich schlanker als jede Cloud-KI-Alternative.
Digitale Souveränität ist kein politisches Narrativ
Ich höre das Argument oft: „Digitale Souveränität ist ein deutsches Politikthema, kein technisches Problem.“
Falsch.
Seit dem Schrems-II-Urteil 2020 und den Folgedebatten um das EU-US Data Privacy Framework ist die Übertragung personenbezogener Daten in die USA nur mit zusätzlichen technischen und organisatorischen Maßnahmen zulässig. Das Data Privacy Framework von 2023 hat die Situation formal stabilisiert, steht aber unter Dauerbeobachtung.
Der US CLOUD Act ist keine hypothetische Bedrohung. Er gibt US-Behörden das Recht, auf Daten von US-Unternehmen zuzugreifen unabhängig vom physischen Serverstandort. Wer Unternehmensdaten in einem Cloud-KI-System verarbeitet, das einem US-Unternehmen gehört, hat dieses Risiko in seiner Architektur.
Fleet Navigator hat dieses Risiko nicht. Es gibt keinen US-Anbieter in der Kette. Es gibt keinen Anbieter überhaupt nur eine Binary auf eurem Server.
Laut einer EuroCloud-Umfrage sehen 45 Prozent der Mitglieder Souveränität als Top-Trend Nummer eins für 2026, noch vor künstlicher Intelligenz. Das ist kein Zufall. Das ist die Reaktion auf eine Risikolage, die sich in den letzten Jahren konkretisiert hat.
Multi-GPU, VRAM-Management, Watchdog
Für die Kollegen, die das technisch evaluieren: Ein paar Details zur Infrastruktur.
Fleet Navigator verteilt Last automatisch auf verfügbare GPUs. Der Haupt-Chat-Server läuft auf GPU 0, ein optionaler Coder-Server auf GPU 1, Embedding-Generierung läuft CPU-seitig auf Port 2027. Apple Silicon profitiert durch Unified Memory ohne separate VRAM-Grenze.
Vier VRAM-Strategien sind konfigurierbar: Smart Swap (Standard), Always Clear, Smart Offload und Manual. Smart Swap gibt VRAM nur bei Bedarf frei das ist in den meisten Szenarien die richtige Wahl.
Der Watchdog überwacht den llama-server mit Health-Checks alle fünf Sekunden. Bei transienten Fehlern (Segmentation Fault, Timeout) startet er automatisch neu mit exponentiellem Backoff bis maximal 60 Sekunden. Bei permanenten Fehlern (Out-of-Memory, korruptes Modell, fehlende Datei) stoppt er sofort und zeigt eine klare Fehlermeldung.
Server-Zustände sind explizit: StateOff → StateStarting → StateRunning → StateStopping → StateOff. Graceful Shutdown via SIGTERM mit 5 Sekunden Wartezeit vor SIGKILL, danach 3 Sekunden VRAM-Freigabe.
Was Fleet Navigator nicht ist
Ich sage das direkt, weil ich glaube, dass IT-Leute Produktversprechen skeptisch begegnen – zu Recht.
Fleet Navigator ist kein Enterprise-KI-Cluster. Für hunderte parallele Nutzer mit Hochverfügbarkeitsanforderungen ist es nicht konzipiert. Es ist ein Werkzeug für kleine Büros und Kanzleien bis etwa zehn aktive Nutzer ist es ausgelegt.
Es ist auch kein vollständiges Knowledge-Management-System. Es hat keine Versionierung von Dokumenten, keine Rechteverwaltung auf Dokumentenebene, keine Audit-Trails auf Benutzerebene im Enterprise-Sinne.
Und es ist kein Ersatz für eine KI-Governance-Strategie. Es ist ein Baustein darin der Baustein, der kontrollierte lokale KI-Nutzung für Fachanwender ermöglicht, ohne die IT-Abteilung aus der Kontrolle zu drängen.
⛵ Zum Abschluss
Ich habe Fleet Navigator nicht für IT-Leiter gebaut. Aber ich habe es so gebaut, wie ich es als IT-Leiter haben wollen würde.
Eine Binary. Bekannte Ports. Kein externer Traffic. Vollständige Kontrolle über Daten und Konfiguration. Integrationsfähig über REST. Deploybar ohne Abhängigkeiten. Auditierbar ohne externe Logs.
Das Schatten-KI-Problem löst sich nicht durch Verbote. Es löst sich durch ein besseres Angebot. Fleet Navigator ist dieses Angebot – für Organisationen, die KI produktiv einsetzen wollen, ohne die Kontrolle über ihre Daten abzugeben.
Fleet Navigator Light ist kostenlos. Keine Lizenzkosten, keine API-Gebühren, keine Cloud.
Nur euer Server. Und ein Werkzeug, das das respektiert.
⛵ fleet-data.de
Franz-Martin Herstell ist CTO und Gründer von Fleet Data & Systems Consulting. Er entwickelt seit über 40 Jahren Software – von Mainframes bis zu modernen KI-Systemen. Fleet Navigator ist sein bisher persönlichstes Projekt.
Quellen und weiterführende Links
NIS2 und Compliance
- NIS2-Umsetzungsgesetz – Bundesamt für Sicherheit in der Informationstechnik – BSI
- Neue EU-Vorgaben 2026: Herausforderungen für den Mittelstand – Creditreform, 2026
- Cybersecurity 2026 – Compliance-Trends – Proliance, Dezember 2025
Digitale Souveränität und Cloud-Strategie
- Digitale Souveränität 2026: Cloud-Strategie für deutsche Unternehmen – Interlake, März 2026
- Reshoring 2026: Cloud-Lieferkette im Mittelstand neu denken – Cloud Magazin, April 2026
ISO 27001 und KI
- KI & ISO 27001: Neue Wege zur sicheren Compliance – rz10.de, Juli 2025
- ChatGPT für eine ISO 27001-Zertifizierung verwenden: Eine gute Idee? – GRASP GRC, Oktober 2025
- ISO 27001 Annex A Controls – Übersicht – DataGuard
EU AI Act
- KI-Governance für KMU: Der Weg zur AI-Act-Compliance – Kopexa, März 2026