Responsible AI,
from principles to practice.

Overview

An AI system can produce a plausible answer and still take the wrong action. In a utility workflow, a recommendation may refer to the wrong asset, rely on an expired procedure, or reach a reviewer without the evidence needed to challenge it. Responsibility must therefore be designed into the path from information to action.

IBM describes responsible AI as a lifecycle practice that joins people, processes, tools, and governance. Its account emphasizes transparency, fairness and human value alignment, robustness, and privacy. It also calls for human oversight and clear accountability. [1]

This paper asks a practical question: what evidence should an organization require before an AI agent is allowed to affect real work? We propose a control framework for energy and utilities that connects a system’s purpose, permitted actions, evaluation, and continuing oversight.

Principles into controls

A principle becomes useful when a team can name the decision it changes, the person responsible, and the evidence that demonstrates it. The table below is our proposed translation of responsible AI concerns into reviewable workflow controls.

These controls should apply to the complete system. A reliable model cannot compensate for a connector with excessive permissions or a review interface that hides uncertainty. OWASP identifies excessive functionality, permissions, and autonomy as causes of excessive agency in LLM applications. [4]

The control framework

We propose making the action record the unit of accountability. It should allow a reviewer to reconstruct what the system was asked to do, what it relied on, what it was permitted to do, and what happened. This is a design proposal; it does not establish that a particular agent is safe.

01 / Define the operating boundary

Write a short specification before selecting a model: the task, the people affected, the accepted output, the authorized sources, and the actions outside scope. Separate preparing information, recommending a decision, and executing a change. Each requires a different permission boundary.

For example, an agent that assembles a maintenance package may read approved asset records and draft a work order. Permission to draft does not imply permission to schedule a crew, change an equipment setting, or close an inspection.

02 / Bind claims to evidence

Attach references to the claims that matter to the decision. Preserve document versions and distinguish missing evidence from negative evidence. If the record is incomplete, the useful output may be a request for clarification rather than a confident recommendation.

03 / Check authority at the action

Validate the requested operation in the system that executes it. Bind human approval to the specific action and current inputs; a changed asset, recipient, or quantity should invalidate an earlier approval. An instruction inside a retrieved document must not acquire the authority of the user or the workflow owner.

04 / Make intervention real

A reviewer needs the proposed action, material evidence, uncertainty, and the ability to reject or revise it. The operating team needs a way to suspend the workflow and recover from partial execution. Record both the intended action and the executor’s actual response.

A utility workflow

Consider an agent preparing an inspection follow-up package. Its approved task is to assemble records and draft a work order for a planner. The examples below are fictional and show how the same workflow should respond when its evidence or authority changes.

This example illustrates a design boundary. It does not validate live field operations or establish readiness for control of utility equipment. Such uses require their own engineering assurance and operating authority.

Evaluation methodology

NIST’s AI RMF 1.0 organizes risk management through four interconnected functions: Govern, Map, Measure, and Manage. Its Core connects context and accountability with evaluation and risk treatment. [2] We use that structure to propose the following evaluation protocol.

Build cases around decisions

Reserve evaluation cases before tuning the workflow. Include routine tasks, incomplete records, contradictory documents, unauthorized requests, and tool failures. Reconstruct the information available at the time of each case; later outcomes should not leak into the inputs.

Predefine acceptance and failure

Have domain reviewers decide which errors permit correction and which require rejection. Judge the final artifact and the actions taken, including whether the system escalated when it should. Record all attempts, not only the most convincing answer.

Evaluate variation, not just averages

Report sample sizes and uncertainty. Break out results by task difficulty, source completeness, and relevant affected groups when appropriate data can be used responsibly. Repeat representative cases to reveal unstable behavior. A small test with no observed serious failures provides limited evidence about rare events.

NIST’s Generative AI Profile identifies risks including confabulation, data privacy, information integrity, and human–AI configuration. [3] Use a risk inventory to choose adversarial and failure cases rather than assuming a generic accuracy score covers the workflow.

Deployment & oversight

Deployment should be a documented decision about a defined configuration. Record the model, prompts, tool versions, data sources, permissions, review process, unresolved risks, and the person accepting responsibility for the release.

Define pause conditions before launch: a successful unauthorized action, an unresolved pattern of unsupported recommendations, or a breakdown in review coverage. Assign an incident owner and make the manual fallback usable. Monitoring should track the real outcome of the work, not only service availability.

Human review also needs evaluation. If reviewers cannot inspect sources or lack time to challenge the output, an approval button may add little protection. Observe review effort and corrections, sample completed cases, and keep a route for affected people to raise concerns.

Conclusion

Responsible AI becomes an operating practice when an organization can explain the purpose of a system, constrain its authority, examine its evidence, and intervene when it fails.

Every consequential action should have a boundary, an evidence trail, and an accountable owner.

For energy and utilities, the next useful step is a bounded workflow with a clear acceptance test. Establish what the agent may do, what it must show, and who can stop it. Then use observed evidence to decide whether to revise, expand, or stop.

To discuss applying this approach to a workflow, get in touch with Corvana.