An AI assistant for network intelligence that runs entirely inside the customer environment. No topology data, no configurations, no operational context leaves the site. The assistant works with local models grounded in a live digital twin, log data and other systems, retrieving exactly the data each task needs.
Why on-premises matters for network AI
Network topologies, running configurations, host inventories, naming conventions and change history all carry security relevance. In critical or regulated environments, sending that data to an external AI service is often simply not an option. A practical AI assistant therefore has to run locally, with targeted tool access, not a blanket upload of the network to a cloud.
Sovereignty first
All inference stays on site. No cloud dependency is required for the assistant to work.
Grounding over guessing
Answers are built from the digital twin, log data and structured tooling, not from generic training data.
Open and extensible
New sources (logs, monitoring, ticketing) can be added without replacing the core stack.
Conference presentation
BSI IT-Sicherheitskongress · 15–16 April 2026
The architecture and design rationale behind this work were presented by Dr. Tim Senn as a conference paper and talk at the German Federal Office for Information Security (BSI).
Four layers make up the stack. The assistant orchestrates tool calls through the Model Context Protocol (MCP), keeping the local model focused on the data that matters for each question, and it runs on tested, open-source LLM models rather than a proprietary black box.
The inference engine and local model routing. Every model runs on the customer's own hardware: a dual-node cluster handles load balancing and task-based model selection.
Inference engine
Ollama
Local inference
Load balancer
Request distribution
Model router
Task-based selection
Local models
Qwen 3
Primary reasoning
GLM-4
Multi-task
Custom
Fine-tuned models
Layer 03Model Context Protocol (MCP)14 active tools
The tool layer connecting the models to data sources, so the model retrieves facts rather than inventing them. Fourteen tools are active today across network and log analytics, with extensions planned.
Network Explorer MCP · active
get_devices
Device queries
analyze_network
Topology & STP analysis
extract_config
Config sections
detect_changes
Change detection
assess_network
Security & reliability report
get_network_stats
Statistics overview
Log Analytics MCP · active
query
Log queries
hits
Log volume over time
stats_query
Aggregated statistics
streams
Active log streams
facets
Field value distribution
field_names
Discover log fields
Planned extensions
Monitoring MCP
Metrics, alerting
Ansible MCP
Config automation
Ticketing MCP
Incident management
Docs MCP
Knowledge base
Layer 04Data sourcesgrounding
What the tools actually read: a live digital twin, a log analytics engine, the customer's own design resources, and existing operational systems.
Network Explorer
Topology
Devices & neighbours
Configs
Running configurations
Snapshots
Historical states
Hosts
End devices & MACs
VLANs
Segmentation data
Routing
Routes & protocols
Custom resources
Design handbook
Network standards
Templates
Device configs
Naming convention
Hostnames & VLANs
IP address plan
Subnet allocation
Log analytics engine
Syslog
UDP/TCP receiver
Log storage
Indexed log data
Query engine
Full-text search
Streams
Per-device log streams
Other integrations
Monitoring system
Metrics & alerts
SIEM
Security events
IDS / IPS
Intrusion detection
Ansible
Automation
ServiceNow
ITSM
What you can ask
The assistant handles both project-grade analysis and day-to-day troubleshooting, all through natural-language queries against live network and log data, not a fixed dashboard.
Security & compliance
Do an overall security assessment
Review the segmentation of my network
Check port-security config across all switches
Topology & config
What devices are on the same VLAN as 10.1.5.22?
What changed in the last 24 hours?
Compare configs with last month's snapshot
Log analytics
Show me error logs from the last hour
Which devices are logging the most errors?
Correlate OSPF neighbour flaps with config changes
A security assessment in the assistant: the answer is built from an MCP tool call against the live digital twin, not from training data
On-premises hardware
The inference stack does not need a data centre. It runs on compact, high-performance mini PCs with integrated AI accelerators, energy-efficient devices deployed alongside the existing infrastructure. A dual-node cluster handles load balancing and model routing, and for the strictest requirements the whole thing can run fully air-gapped.
The dual-node on-premises deployment: the entire inference stack, on-site, no cloud required
Key capabilities
AI that knows your network
Not a generic chatbot: the assistant is grounded in a live digital twin with real topology, configuration and host data.
Two practical modes
Project-grade security assessments, and day-to-day operational troubleshooting and root-cause analysis.
Extensible through MCP
Logs, monitoring, automation and ticketing can be integrated without replacing the core stack.
No cloud dependency
All inference and orchestration runs inside the customer environment; nothing is sent to an external API.
Frequently asked
Which LLM models are suitable for local network analysis?
We have tested numerous models and variants, and recommend Qwen 3 and GLM-4 for production use. Both are strong at structured outputs and reliable tool-calling, which is critical for interacting with the network digital twin. NVIDIA Nemotron is also showing promising results.
What hardware is needed for the local AI stack?
The stack runs on compact, high-performance mini PCs with integrated AI accelerators and a dedicated GPU, energy-efficient devices that can be deployed alongside existing infrastructure. An Apple Mac Studio with an M-series chip is also an interesting option, thanks to its high unified-memory capacity.
How does this differ from cloud AI solutions?
No network data leaves the site. The LLM operates on a live digital twin (topology, configurations, logs) via MCP. There is no training on customer data and no API calls to external services, so sensitive information never reaches an external API and cannot be unintentionally disclosed.
What are the benefits of local deployment?
Data sovereignty and privacy: all data stays within the organisation's control, reducing third-party breach and leakage risk and making compliance with GDPR and NIS2 easier.
Infrastructure control: the organisation manages the whole stack: GPUs, networking, software updates.
Air-gapped capability: for extreme requirements, models can run fully disconnected from the internet.
Protection of intellectual property: proprietary models and RAG data stay in-house.
What surrounding systems are supported?
The system works with configuration and operational data from network devices, log data, IPAM data and other sources. The MCP-based architecture makes it straightforward to integrate any additional system that exposes an API: monitoring platforms, ticketing systems or automation solutions.
How are hallucinations prevented?
The LLM is grounded on real device data via MCP tools: it queries configurations, topology and logs rather than generating answers from training data. Responses include traceable evidence: concrete device names, ports and timestamps.
Can the system run without a GPU?
Yes. CPU-only inference is possible with quantised models (GGUF / Q4), but response times increase significantly. For production use, a GPU or a system with an integrated AI accelerator is recommended.
