AI Agents for Utilities Companies: Field Work and Compliance

AI agents for utilities companies are most useful as careful record-keepers around the operation, not as operators of it. They turn field reports into clean records, keep asset history findable, and assemble regulatory evidence with sources attached. Switching, dispatch and control-system actions stay with qualified people and the systems built for them.

Key takeaways

• The safest and most valuable first jobs for an agent in a utility are documentation jobs: field report cleanup, asset record reconciliation and evidence assembly.
• Operational control is a hard boundary. The agent holds no credentials into control systems and issues no commands that change the state of the network.
• Every statement the agent produces for a regulator or auditor should trace back to a source record a person can open.
• Field notes, vendor documents and customer messages are untrusted input. The agent treats them as data, never as instructions.
• Start with one role, one record type and one success measure you can observe, then widen only when the logs show the agent behaving as designed.

What can an AI agent do for a utility without touching operations?

A utility produces a steady stream of paperwork that sits next to the physical work: inspection notes, work order close-outs, photos, meter and asset updates, outage summaries, contractor submissions and compliance filings. Much of it is written in a hurry, by people in a truck or at a substation, and then re-keyed or chased by someone in the office days later.

That gap between the field and the record is where an agent helps. It reads what crews submit, compares it against the work order and the asset register, asks the crew a clarifying question when something is missing, and prepares a record for a human to approve. It can also answer internal questions such as which transformers on a feeder had a defect noted in the last inspection cycle, and show the source for each answer.

What it does not do is equally important. It does not open or close devices, change setpoints, reroute crews on its own authority, or declare an asset safe. Those decisions belong to authorized staff working in operational systems with their own safeguards. An agent that stays on the documentation side of that line still removes a great deal of friction, and it is far easier to approve, audit and trust.

How do field reports become reliable records?

Field reports fail in predictable ways. The asset identifier is abbreviated or wrong. The photo is attached to the wrong job. The note says "as discussed" without saying what was discussed. The finding is real, but nobody outside the crew knows it exists until an audit.

An agent can close these gaps at the moment of submission instead of weeks later. A workable pattern looks like this:

• The crew submits a note, photos and a work order reference through the channel they already use.
• The agent matches the note to the work order and the asset register, and flags any identifier that does not match.
• It extracts structured fields (asset, condition, defect type, action taken, follow-up needed) and keeps the original wording alongside them.
• It asks the crew one specific question if a required field is missing, rather than leaving a gap for the office.
• It drafts the record and routes it to the named reviewer, who approves, edits or rejects it.

Illustrative scenario: a crew closes a routine inspection and writes that a pole shows "some rot at the base, see photo." The agent finds the photo is attached, but the pole identifier in the note matches two assets on the same street. It asks the crew which one, records the answer, classifies the finding as a condition issue needing follow-up, and places it in the reviewer's queue with the photo and the original sentence. The reviewer decides on priority. The agent never assigns a repair deadline by itself.

The original wording matters. Structured fields are convenient for search and reporting, but the crew's own words are the evidence. Keep both, and make sure the structured version is always labeled as derived.

How should asset records be kept consistent?

Most utilities hold asset knowledge in several places: a work management system, a geographic record, maintenance spreadsheets, contractor reports and the memory of long-serving staff. These sources disagree, and the disagreement is rarely visible until someone needs a definitive answer.

An agent can act as a reconciliation layer. It reads from each source with read-only access, builds a per-asset history, and shows where records conflict instead of quietly picking a winner. The retrieval approach matters here: grounding answers in your own documents at query time, as described in this [overview of retrieval-augmented generation](https://aws.amazon.com/what-is/retrieval-augmented-generation/), keeps the agent tied to current records rather than to whatever it absorbed during training.

A useful asset history from the agent has a few properties:

• Each fact names its source record and the date that record was last updated.
• Conflicts are listed side by side, for example two different installation years in two systems.
• Gaps are stated plainly, such as no inspection record found for this asset in the retained files.
• Proposed corrections go to the record owner as a request, never written directly into the system of record.

The last point is the one most teams are tempted to relax. Resist it. An agent that edits the asset register on its own makes the register harder to trust, and the register is the foundation for everything downstream, including regulatory reporting. For teams that already manage nonconformances and audit preparation, the same discipline applies as in quality management: the agent prepares, a named person decides.

How does an agent support regulatory evidence?

Regulatory work in a utility is largely evidence work. Someone has to show that inspections were done at the required interval, that defects were followed up, that incidents were reported and that records were retained. The effort is rarely in the analysis. It is in finding, matching and formatting the proof.

An agent can assemble the file. Given a request such as the vegetation inspection evidence for a given area and period, it gathers the work orders, inspection records, photos and sign-offs, checks them against the obligation it was given, and produces a package with an index. For each item it states what the item proves and where it came from. For each obligation it cannot support, it says so.

Three rules keep this honest:

• The agent assembles and cross-checks evidence. It does not interpret the regulation or decide that the utility is compliant. A compliance owner does that.
• Obligations are supplied by people as explicit, versioned text. The agent does not infer requirements from memory.
• Every claim in a draft submission links to a source record. Unsupported sentences are marked, not smoothed over.

This is close to how an internal audit team works with evidence, samples and findings, and the same logic applies. The reviewer should be able to pick any line in the package and open the record behind it in a few seconds.

If your AI use touches public-facing or safety-relevant decisions, it is also worth mapping it against a recognized risk framework. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) offers a practical vocabulary for governing, mapping, measuring and managing those risks, and it gives compliance staff a shared reference point.

Where is the line on operational control?

The boundary between documentation and operations should be written down, not assumed. A decision guide helps teams place each proposed task on the correct side.

Use these questions for any task you consider giving the agent:

• Does the task change the physical or electronic state of the network, a device or a control system? If yes, it stays with authorized staff and existing systems.
• Could a wrong output cause a safety event before a human sees it? If yes, the agent may only prepare information for a person, and the person acts.
• Is the output a record, a summary, a draft or a question? If yes, it is a good candidate, with a named reviewer.
• Can the action be reversed easily and is it visible in a log? If not, require explicit approval before it happens.
• Does the task need data the agent should not see, such as credentials or customer personal data beyond what the job requires? If yes, narrow the scope or leave the task out.

Then enforce the answers technically rather than by instruction alone. Give the agent its own identity with the narrowest permissions the role needs, read-only wherever possible, and no network path to operational systems. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) on least privilege and deny-by-default applies directly. A prompt that says "never operate equipment" is a request. A missing credential is a boundary.

Input handling is the second half of this. Crew notes, contractor PDFs, emails and web forms can contain text that reads like an instruction. The agent must treat all of it as content to analyze, never as commands to follow. The [OWASP prompt injection prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) describes the defensive patterns, including separating instructions from data and limiting what tools the agent can call.

How do you start, step by step?

A first deployment should be small enough to evaluate honestly. This sequence works for most utilities:

• Pick one role with a clear owner, for example field report intake for one inspection program.
• List the sources it may read and the records it may draft. Mark everything else as out of scope.
• Define approval boundaries: which outputs need review, who reviews, and what the agent does when the reviewer is unavailable.
• Give the agent its own account with read-only access first, and add write access to drafts only, never to the system of record.
• Set one observable success criterion, such as the share of submitted reports that reach the reviewer complete, judged on a sample you pick in advance.
• Run in shadow mode, where the agent drafts and people continue the current process, and compare the outputs.
• Turn on logging for every read, draft, question and handoff, so incidents can be reconstructed. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) is a good starting point for what to capture.
• Review the logs and the failures on a regular schedule before widening scope to another program or record type.

Field-heavy businesses outside utilities have worked through similar patterns, and two are worth reading for contrast: field reports and supplier orders in agribusiness and maintenance and compliance in fleet management.

Be Human's managed approach follows this shape. We define one useful role with you, along with the memory and tools it needs, the approval boundaries and the success criterion. We then implement the agent with its own identity and scoped permissions, and operate it with monitoring, recurring evaluations, integration maintenance, permission review and incident response. Improvements are made in a controlled way, so the agent stays under your team's control as the work evolves.

If you are weighing where an agent could take on documentation work in your utility, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent control or switch utility equipment? It should not. Operational control belongs to authorized staff using purpose-built systems with their own safeguards, and the agent should have no credentials or network path to those systems. Its value is in the records, reports and evidence around the work.

Is it safe to let an agent read field reports and customer messages? Yes, if you treat that content as untrusted input. The agent should analyze the text without following instructions found inside it, and its tool access should be narrow enough that a manipulated message cannot cause harm. Logging and periodic review of its behavior add a second layer of protection.

How do we keep regulators and auditors comfortable with agent-prepared evidence? Make every claim traceable to a source record and keep a named person accountable for the final submission. The agent assembles and cross-checks, while the compliance owner interprets the obligation and signs off. A clear log of what the agent read and drafted lets you explain the process if anyone asks.

What should the first project be? Choose a documentation task with a clear owner and a visible backlog, such as completing and matching inspection reports to work orders. It carries low operational risk, it is easy to sample and judge, and it builds the permissions, logging and review habits that later projects will depend on.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.