Updated 2026-11-01
Using Local LLMs to Support Infrastructure Operations #
Making AI explanations useful while distinguishing information handling from operational responsibility
Infrastructure operations involve understanding situations from many observations and checking whether a response is needed. An LLM can assist by explaining that information in a readable form.
BASTION supports configurations that use a local LLM. Rather than providing setup instructions for a particular model, this article introduces information handling, the relationship with detection and control, and the conditions to check before use.
1. Distinguishing observations from AI explanations #
Collected information and an explanation generated from it by AI are not the same thing. It is important for operators to be able to check the basis of an explanation.
Mistakes about counts, subjects or time periods can lead to an incorrect response even when an explanation is easy to read. Correctness is not judged solely by fluent wording; verified information is distinguished from interpretation.
2. Defining the information to process and the services to connect to #
Running inference locally and operating without any external communications are separate conditions. When notifications or integrations with external services are used, the configuration must be checked, including the destinations and the information to be sent.
Where a private-network requirement applies, the scope of processing, notifications and management is designed to meet it. These conditions, including the handling of customer information and credentials, are defined for each environment.
3. Distinguishing responsibility for explanations and control #
BASTION’s automated defense is governed by defined decision criteria and protective conditions. It should not be understood as a design that accepts LLM-generated text directly as instructions to block traffic or change settings.
Functions that handle improvement proposals also have an authorized scope and checks at the point of application. Explanations of a situation, proposed changes and actual application are each subject to review.
4. Checking operational status and gaps in observation #
Analysis may be insufficient when a model does not respond, collection has stopped or information is outdated. An absence of notifications alone does not establish that there is no problem.
In the configuration being used, the arrival of information, completion of processing and areas that cannot be verified are checked separately. Checking that the analysis function works and checking its actual defensive effectiveness are also separate tasks.
5. Distinguishing supported configurations from current operation #
We operate BASTION’s automated defense and bandwidth control in our own environment. Support for a configuration using a local LLM does not prove that the model is running continuously or that all processing stays within a private network.
The models, equipment and processing conditions described in the first edition reflected the setup at that time and are not treated as a current standard specification. The model, required resources, operating conditions and presence of external integrations are checked for each deployment configuration.
6. What to check before deployment #
The scope of application is defined after checking the target equipment and information, operator review methods, handling of downtime or missing observations, and impacts on legitimate business operations. Choosing a particular model alone does not necessarily deliver the same benefits in every environment.
Deployment design, integration and evaluation are quoted individually after confirming the scope and work involved. This public article provides an overview and does not disclose customer information or details of internal configurations.
We reviewed the original setup record and aligned it with the public explanation as of 2026-11, clarifying supported configurations, operational scope and points to consider during verification.
