Electric Utility AI: Grid Operations Safety Governance

Electric utilities want AI in outage response, switching-plan review, field-note summarization, and reliability analysis because those are high-friction workflows with expensive operational delays. The risk is that an assistant that looks helpful in a control-room workflow can blur the line between analysis and action. In a utility context, that line matters. Summarizing an incident report is one thing. Suggesting a relay override or exposing detailed substation identifiers to a broad model route is something else entirely.

Keeptrusts helps utilities keep those boundaries explicit. The practical pattern is to treat grid-operations AI as a governed route: require identity, filter sensitive grid markers, restrict which providers may receive the traffic, and force high-risk output into review rather than letting it flow directly to operators. That matches the documented Keeptrusts controls for Energy & Utilities, Data Routing Policy, DLP Filter, and Safety Filter.

Use this page when

• You are rolling out AI for outage triage, switching-plan review, grid-maintenance summaries, or operator handoff notes.
• You need to protect BES, substation, relay, or feeder identifiers from reaching routes that do not meet your declared handling requirements.
• You want a practical pattern that separates advisory analysis from any instruction that could affect safety or control-room behavior.

Primary audience

• Primary: Technical Leaders
• Secondary: Technical Engineers, AI Agents

The problem

Utilities rarely fail at AI governance because they lack policy names. They fail because the production workflow collapses too many sensitivities into one route. The same assistant gets used for storm communications, relay-event interpretation, and maintenance questions. A field supervisor asks for a concise summary. An operator asks whether a switching step can be skipped. A contractor pastes a work order containing detailed asset identifiers. The application sees all three as text. The utility should not.

That creates three distinct risks. First, sensitive infrastructure details can move to an upstream provider without the utility deliberately approving the handling boundary. Second, keyword-level safety hazards can slip into requests or responses, such as content that looks like “disable emergency shutdown” or “override safety interlock.” Third, teams lose evidence discipline. If governance is spread across prompt templates and app code, compliance staff end up reconstructing what happened after the fact instead of reviewing one decision stream.

For utilities, the core issue is not whether AI exists in operations. It is whether the route enforces the same distinctions your operating model already uses: planning versus control, broad-read staff versus privileged operations roles, and low-sensitivity service work versus critical infrastructure detail.

The solution

The most durable pattern is to treat grid AI as a route with layered controls instead of a feature embedded in one application.

Start with rbac so every request carries an authenticated user and role. That will not validate the operator's certification on its own, but it does force identity and makes route segmentation possible. Next, apply dlp-filter with utility-specific patterns for relay IDs, feeder identifiers, substation codes, and internal codenames. That is the content boundary.

Then add safety-filter for phrases that should never appear in an AI interaction for this route, such as instructions to bypass shutdowns, tamper with protection systems, or disable interlocks. Because safety-filter is keyword-based and explicit, utilities can review the exact block list with operations and safety teams instead of outsourcing the decision to a black-box classifier.

Finally, use data-routing-policy so the provider pool itself reflects the handling boundary. If a route is meant for zero-retention, no-training, local-only processing, the provider metadata has to say that. When no compliant provider is available, block instead of silently downgrading the control. Include audit-logger in the chain so the decision stream records audit logging as an active control, then use exports for evidence through Export Workflows and broader audit preparation via Pass Compliance Audits.

Implementation

This example defines a grid-operations review lane that keeps critical routes on provider targets with strict declared handling metadata and blocks dangerous instruction patterns.

pack:
  name: electric-utility-grid-review
  version: 1.0.0
  enabled: true

providers:
  targets:
    - id: local-grid-zdr
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        allow_internet_egress: false
        local_only_processing: true

  routing:
    strategy: ordered

policies:
  chain:
    - rbac
    - dlp-filter
    - safety-filter
    - data-routing-policy
    - audit-logger

policy:
  rbac:
    deny_if_missing:
      - X-User-ID
      - X-User-Role
    require_auth: true

  dlp-filter:
    detect_patterns:
      - '\\bSUB-[A-Z]{2}[0-9]{3,5}\\b'
      - '\\bRELAY-[0-9]{4,8}\\b'
      - '\\bFEEDER-[A-Z0-9]{4,10}\\b'
    blocked_terms:
      - BES Cyber System Information
      - switching authority sheet
    action: block

  safety-filter:
    mode: critical_infrastructure
    block_if:
      - override safety interlock
      - disable emergency shutdown
      - bypass relay protection
    action: block
    fuzzy_matching: true
    max_distance: 1

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    require_in_memory_only: true
    allow_internet_egress: false
    local_only_processing: true
    on_no_compliant_provider: block
    log_provider_selection: true

  audit-logger: {}

Utilities can validate the route before rollout with kt policy lint, then monitor decisions and export evidence for review. That is a better operating posture than relying on application developers to remember which requests are acceptable in a grid context.

Results and impact

The main benefit is not just fewer dangerous prompts. It is clearer operational separation. Planning, summarization, and reliability-analysis traffic can move faster because the route is well defined, while safety-sensitive instructions are blocked or redirected before anyone starts treating AI output like operational authority.

Utilities also get better reviewability. When the same gateway chain enforces identity, DLP patterns, provider handling constraints, and safety terms, operations and compliance teams can inspect one stream of decisions instead of auditing five separate applications. That makes storm-event retrospectives, control reviews, and audit preparation faster and less ambiguous.

In practice, this means fewer accidental provider-boundary mistakes, fewer unsafe outputs reaching operators, and less argument about which system is responsible for the control.

Key takeaways

• Grid-operations AI should be governed as a route, not treated as a general-purpose assistant.
• Use DLP Filter for utility-specific asset identifiers and internal codenames.
• Use Safety Filter to block explicit high-risk phrases tied to critical infrastructure operations.
• Use Data Routing Policy so provider eligibility matches the route's declared handling boundary.
• Treat Audit Logger as an audit marker in the chain, then rely on exports and observability for evidence.

Next steps

• Energy & Utilities
• Critical Infrastructure
• Data Routing Policy
• DLP Filter
• Safety Filter
• Centralize AI Observability