Procedure search
Switching orders and field procedures answered on site.
Field procedure search, outage reporting and compliance documentation for operators whose critical systems must stay isolated.
Utilities run critical infrastructure under strict separation rules. Private AI can work inside those boundaries, at the substation, the control room or the field truck, without new paths to the internet.
| Environments | Control centers, substations, field devices |
|---|---|
| Controls | NERC CIP-aligned access and change control |
| Deployment | On-premises, edge or air-gapped |
Switching orders and field procedures answered on site.
Event narratives drafted from logs and crew notes.
CIP documentation assembled from existing records.
Equipment histories and manuals searchable by crews.
Utilities hold decades of operating knowledge in switching procedures, equipment manuals, relay settings files, inspection records, outage logs and crew notes. Much of it lives on networks that are deliberately cut off from the internet. AI for utilities has to work inside those boundaries, or it cannot touch the information that matters most.
LLM.co builds private AI on open-weight models that run on hardware the utility controls. A system can sit in the corporate data center, in a control center environment or on an air-gapped network. It opens no new paths to the internet and makes no calls to an outside model provider.
Any system that reaches BES Cyber Systems or their information falls under the NERC CIP standards. That brings requirements for electronic security perimeters, access management, configuration change management, information protection and logging. NERC CIP AI is a short name for building AI so it fits those requirements from day one.
In practice, we classify each use case by the networks and data it touches before any build starts. Corporate use cases run on the IT side. Use cases that need BES Cyber System Information run on hardware inside the right zone, with access tied to your existing authorization records. Model and software updates arrive as signed bundles that go through your change and baseline process. The system is built to support your CIP program, and your compliance team decides how it is classified.
The strongest first projects sit close to work crews and compliance staff already do by hand.
Many utility use cases need answers where connectivity is poor. Smaller models can run on a ruggedized server in a substation or on a laptop in a truck, with a local copy of the approved procedures. Larger models run in the control center or data center on the OT network side. On-premises AI in each location follows the same identity, logging and update rules.
Systems in these environments read data and draft documents. They do not issue control commands to grid equipment. That boundary is set during scoping and enforced in the architecture.
For most AI for utilities projects, procedure search for one operating area is a sound first pilot. The documents are controlled, operators can judge answers quickly, and the evaluation set comes from questions crews have already asked. Compliance evidence assembly is another good start because the output goes to people who check it carefully.
Avoid any tool that requires uploading CIP-protected information to a vendor cloud. Avoid connecting a model directly to SCADA or EMS write paths. Avoid starting with use cases where the source documents are out of date, since the model will repeat what it reads.
Each utility has its own network zones, procedure formats and change process. Custom AI development lets the system match them. Work starts with a two-week discovery sprint, and a focused first system usually reaches production in eight to twelve weeks. You own the code, prompts, evaluation sets and any fine-tuned weights.
Identify which networks each use case may touch.
Tested with operators on historical events.
Edge or air-gapped, inside the right zone.
Signed updates through your change process.
Yes. The models are open-weight and run entirely on hardware you control, including air-gapped networks and edge servers at substations. Updates arrive as signed bundles that pass through your change management process. Nothing calls an outside model API.
Compliance belongs to the registered entity, so we build the system to support your CIP program. That means deployment inside the correct perimeter, access tied to your authorization records, baseline and change documentation, and full logging. Your compliance team decides how each component is classified.
No. The systems we build read records and draft documents for people to review. They do not write to SCADA, EMS or protection systems. That boundary is set during scoping and enforced in the architecture, so the model has no path to issue control commands.
Typical sources are controlled procedure libraries, equipment manuals, asset management and work order systems, OMS records, SCADA event exports, inspection reports and compliance records. We read through exports or existing interfaces approved by your security team.
Yes. Smaller models can run on a laptop or a ruggedized edge server with a local copy of approved documents. Crews get answers without a network connection. Usage logs sync back through your approved path when the device reconnects.
Yes. Procedure search, asset knowledge and compliance evidence apply to gas and water operations as well. The rules differ, such as pipeline safety or drinking water requirements, so we map the relevant obligations during scoping and build controls to support your program.
There are no per-seat or per-token fees. Cost comes from the build, which is quoted per phase after a fixed-fee discovery sprint, and from hardware or a dedicated cloud environment. We model both options during discovery so you can compare them.
Tell us the workflow and where the data lives. An engineer, not a salesperson, replies within one business day with a first take on architecture and cost.