Ein KI-Assistent für Netzwerk-Intelligenz, der vollständig in der Kundenumgebung läuft. Keine Topologiedaten, keine Konfigurationen, kein operativer Kontext verlässt den Standort. Der Assistent arbeitet mit lokalen Modellen, basierend auf einem Live-Digital-Twin, Log-Daten und weiteren Systemen, und ruft genau die Daten ab, die jede Aufgabe benötigt.
Warum On-Premises für Netzwerk-KI wichtig ist
Netzwerktopologien, laufende Konfigurationen, Host-Inventare, Namenskonventionen und Änderungshistorien sind allesamt sicherheitsrelevant. In kritischen oder regulierten Umgebungen ist das Senden dieser Daten an einen externen KI-Dienst oft schlicht keine Option. Ein praxistauglicher KI-Assistent muss daher lokal laufen, mit gezieltem Tool-Zugriff, statt das Netzwerk pauschal in eine Cloud hochzuladen.
Souveränität zuerst
Die gesamte Inferenz bleibt vor Ort. Für den Betrieb des Assistenten ist keine Cloud-Abhängigkeit erforderlich.
Verankerung statt Raten
Antworten entstehen aus dem Digital Twin, aus Log-Daten und strukturierten Werkzeugen, nicht aus generischen Trainingsdaten.
Offen und erweiterbar
Neue Quellen (Logs, Monitoring, Ticketing) lassen sich hinzufügen, ohne den Kern-Stack zu ersetzen.
Konferenzpräsentation
BSI IT-Sicherheitskongress · 15.–16. April 2026
Die Architektur und die Designentscheidungen hinter dieser Arbeit wurden von Dr. Tim Senn als Konferenzbeitrag und Vortrag beim Bundesamt für Sicherheit in der Informationstechnik (BSI) präsentiert.
Vier Ebenen bilden den Stack. Der Assistent orchestriert Tool-Aufrufe über das Model Context Protocol (MCP) und hält das lokale Modell auf den Daten fokussiert, die für jede Frage relevant sind. Er läuft auf getesteten Open-Source-LLMs statt auf einer proprietären Blackbox.
Die dem Nutzer zugewandte Ebene: wie Netzwerk- und SOC-Teams Fragen stellen, und die Orchestrierung, die aus einer Frage einen Plan von Tool-Aufrufen macht.
Interface
Chat-Interface
Abfragen in natürlicher Sprache
Web-Client
Browserbasiertes UI
API-Zugang
Programmatische Integration
Kerndienste
KI-Agent
Query-Orchestrierung
Kontextmanager
State Handling
Layer 02On-Premises-LLM-HandlerDual-Node-Cluster, vor Ort
Die Inferenz-Engine und das lokale Modell-Routing. Jedes Modell läuft auf der eigenen Hardware des Kunden: ein Dual-Node-Cluster übernimmt Load Balancing und aufgabenbasierte Modellauswahl.
Die Tool-Ebene, die die Modelle mit Datenquellen verbindet, sodass das Modell Fakten abruft, statt sie zu erfinden. Vierzehn Tools sind heute aktiv, über Netzwerk- und Log Analytics hinweg, mit geplanten Erweiterungen.
Network Explorer MCP · aktiv
get_devices
Geräteabfragen
analyze_network
Topologie- & STP-Analyse
extract_config
Konfigurationsabschnitte
detect_changes
Änderungserkennung
assess_network
Security- & Zuverlässigkeitsbericht
get_network_stats
Statistikübersicht
Log Analytics MCP · aktiv
query
Log-Abfragen
hits
Log-Volumen über Zeit
stats_query
Aggregierte Statistiken
streams
Aktive Log-Streams
facets
Feldwert-Verteilung
field_names
Log-Felder entdecken
Geplante Erweiterungen
Monitoring MCP
Metriken, Alerting
Ansible MCP
Konfigurations-Automatisierung
Ticketing MCP
Incident-Management
Docs MCP
Wissensdatenbank
Layer 04DatenquellenVerankerung
Was die Tools tatsächlich auslesen: einen Live-Digital-Twin, eine Log-Analytics-Engine, die eigenen Design-Ressourcen des Kunden und bestehende operative Systeme.
Network Explorer
Topologie
Geräte & Nachbarn
Configs
Laufende Konfigurationen
Snapshots
Historische Zustände
Hosts
Endgeräte & MACs
VLANs
Segmentierungsdaten
Routing
Routen & Protokolle
Eigene Ressourcen
Design-Handbuch
Netzwerkstandards
Templates
Gerätekonfigurationen
Namenskonvention
Hostnamen & VLANs
IP-Adressplan
Subnetz-Zuweisung
Log-Analytics-Engine
Syslog
UDP/TCP-Receiver
Log-Speicher
Indizierte Log-Daten
Query-Engine
Volltextsuche
Streams
Log-Streams pro Gerät
Weitere Integrationen
Monitoring-System
Metriken & Alerts
SIEM
Security-Events
IDS / IPS
Intrusion Detection
Ansible
Automatisierung
ServiceNow
ITSM
Was Sie fragen können
Der Assistent bewältigt sowohl vollwertige Analysen als auch tägliches Troubleshooting, alles über Abfragen in natürlicher Sprache gegen Live-Netzwerk- und Log-Daten, nicht über ein festes Dashboard.
Sicherheit & Compliance
Mach ein Security Assessment des gesamten Netzwerks
Überprüfe die Segmentierung meines Netzwerks
Prüfe die Port-Security-Konfiguration aller Switches
Topologie & Konfiguration
Welche Geräte sind im selben VLAN wie 10.1.5.22?
Was hat sich in den letzten 24 Stunden geändert?
Vergleiche Konfigurationen mit dem Snapshot vom letzten Monat
Log-Analyse
Zeige mir Fehler-Logs der letzten Stunde
Welche Geräte protokollieren die meisten Fehler?
Korreliere OSPF-Neighbor-Flaps mit Konfigurationsänderungen
Ein Security Assessment im Assistenten: die Antwort entsteht aus einem MCP-Tool-Aufruf gegen den Live-Digital-Twin, nicht aus Trainingsdaten
On-Premises-Hardware
Der Inferenz-Stack braucht kein Rechenzentrum. Er läuft auf kompakten, leistungsstarken Mini-PCs mit integrierten AI-Beschleunigern, energieeffiziente Geräte, die neben der bestehenden Infrastruktur betrieben werden. Ein Dual-Node-Cluster übernimmt Load Balancing und Modell-Routing, und für höchste Anforderungen lässt sich das Ganze vollständig air-gapped betreiben.
Das Dual-Node-On-Premises-Deployment: der gesamte Inferenz-Stack, vor Ort, ohne Cloud
Kernfähigkeiten
KI, die Ihr Netzwerk kennt
Kein generischer Chatbot: der Assistent ist in einem Live-Digital-Twin verankert, mit realen Topologie-, Konfigurations- und Host-Daten.
Zwei praktische Modi
Vollwertige Security Assessments sowie tägliches operatives Troubleshooting und Ursachenanalyse.
Erweiterbar durch MCP
Logs, Monitoring, Automatisierung und Ticketing lassen sich integrieren, ohne den Kern-Stack zu ersetzen.
Keine Cloud-Abhängigkeit
Die gesamte Inferenz und Orchestrierung läuft innerhalb der Kundenumgebung; nichts wird an eine externe API gesendet.
Häufig gefragt
Welche LLM-Modelle eignen sich für die lokale Netzwerkanalyse?
Wir haben zahlreiche Modelle und Varianten getestet und können Qwen 3 und GLM-4 für den produktiven Einsatz empfehlen. Beide beherrschen strukturierte Ausgaben und zuverlässiges Tool-Calling, was für die Interaktion mit dem Netzwerk-Digital-Twin entscheidend ist. NVIDIA Nemotron zeigt ebenfalls vielversprechende Ergebnisse.
Welche Hardware wird für den lokalen AI Stack benötigt?
Der Stack läuft auf kompakten, leistungsstarken Mini-PCs mit integrierten AI-Beschleunigern und dedizierter GPU, energieeffiziente Geräte, die sich neben bestehender Infrastruktur betreiben lassen. Auch ein Apple Mac Studio mit M-Serie-Chip ist eine interessante Option, dank seiner hohen Unified-Memory-Kapazität.
Wie unterscheidet sich das von Cloud-KI-Lösungen?
Keine Netzwerkdaten verlassen den Standort. Das LLM arbeitet über MCP auf einem Live-Digital-Twin (Topologie, Konfigurationen, Logs). Es findet kein Training auf Kundendaten statt und es werden keine API-Aufrufe an externe Dienste gesendet, sodass sensible Informationen nie an eine externe API gelangen und nicht unbeabsichtigt offengelegt werden können.
Was sind die Vorteile einer lokalen Bereitstellung?
Datensouveränität und Datenschutz: alle Daten verbleiben unter der Kontrolle der Organisation, was das Risiko von Datenlecks bei Drittanbietern reduziert und die Einhaltung von DSGVO und NIS2 erleichtert.
Kontrolle über die Infrastruktur: die Organisation verwaltet den gesamten Stack: GPUs, Netzwerk, Software-Updates.
Air-Gapped-Fähigkeit: für extreme Anforderungen können die Modelle vollständig vom Internet getrennt betrieben werden.
Schutz des geistigen Eigentums: proprietäre Modelle und RAG-Daten verbleiben im Unternehmen.
Welche Umsysteme werden unterstützt?
Das System arbeitet mit Konfigurations- und Betriebsdaten von Netzwerkgeräten, mit Log-Daten, IPAM-Daten und weiteren Quellen. Die MCP-basierte Architektur macht es unkompliziert, jedes weitere System anzubinden, das eine API bereitstellt: Monitoring-Plattformen, Ticketing-Systeme oder Automatisierungslösungen.
Wie werden Halluzinationen verhindert?
Das LLM wird über MCP-Tools auf reale Gerätedaten gestützt: es fragt Konfigurationen, Topologie und Logs ab, statt Antworten aus Trainingsdaten zu generieren. Antworten enthalten nachvollziehbare Belege: konkrete Gerätenamen, Ports und Zeitstempel.
Kann das System auch ohne GPU betrieben werden?
Ja. CPU-only-Inferenz ist mit quantisierten Modellen (GGUF / Q4) möglich, allerdings steigen die Antwortzeiten deutlich. Für den produktiven Einsatz wird eine GPU oder ein System mit integriertem AI-Beschleuniger empfohlen.
