The International Energy Agency's Energy and AI report considers both AI's energy demand and its applications in the energy sector.[1] NIST's Generative Artificial Intelligence Profile addresses risk management across design, development, use and evaluation.[2] The public introduction to ISO/IEC 42001 emphasises an organisational system for managing AI over time.[3] These sources offer a framework for thinking. They do not replace testing the effectiveness and limits of a particular use case.

ZHICE recommends defining the starting point as an observable business problem. Can technical staff find the currently applicable procedure more quickly? Can commercial teams identify outstanding issues in a contract more completely? Can management combine multiple sources into a traceable explanation of business performance? Each problem must identify the user, inputs, outputs and ultimate decision owner. A goal such as 'build an enterprise large language model' offers little guidance on which data are needed or what should improve after launch.

The value hypothesis should cover the complete task, rather than generation speed alone. Faster drafting may not reduce total work if review takes substantially longer. More fluent answers may increase verification effort when sources are missing. Before a pilot, document how comparable work is completed manually, where time is spent, common errors and causes of rework. Then compare results within the same boundaries, including preparation, review, correction and subsequent use.

Be equally clear about outcomes that cannot yet be promised. Without a stable body of task samples, the organisation should avoid definitive figures for labour savings, fault reductions or financial gains. It can specify the improvements to investigate, the acceptance method and when an assessment will become credible. This preserves room to explore while giving management evidence on which to continue, adjust or stop, rather than forcing the team to justify an early promotional claim after the demonstration.

Good initial candidates typically have clear boundaries, relatively stable inputs, inspectable results and correctable errors. Examples include searching controlled documents, producing summaries with citations, structuring existing material and generating checklists subject to expert review. These are candidate application patterns, not an assumption that every company is ready to use them. Data permissions, document quality and actual workload still require validation.

Tasks involving operational control, safety procedures, material trades or external commitments require stronger evidence, authorisation and fallback arrangements. Good performance on general questions does not justify extending a model into activities where errors have serious consequences. Assess 'providing information', 'recommending an action' and 'executing an action' separately: the same subject carries different risks at each level. Permission to deploy a knowledge assistant does not establish permission to issue automated instructions.

Priorities should also reflect organisational readiness. A moderately valuable use case with clear data and workflows, and a business owner willing to participate in evaluation, may be a better starting point than an ambitious idea with unclear accountability. Where a promising application lacks supporting material, begin with knowledge governance and process clarification. Accepting that preparatory work as a distinct deliverable avoids attributing every problem to the model, or repeatedly changing technology while the underlying conditions remain inadequate.

Energy companies hold knowledge in operating procedures, policies, equipment documents, work orders and individual experience. A large collection is not necessarily ready for question answering. Versions may conflict; equipment models and locations may differ; historical experience may not fit current operating conditions. Preparation should establish which material is authoritative, which is reference material and which requires expert interpretation before deciding how to retrieve and present it. Uploading every file at once does not resolve these distinctions.

Each knowledge unit should retain its source, version, scope of applicability, validity period and owner. Retrieval should take users back to the precise location in the original document so they can inspect the basis and limitations of an answer. Conflicting or expired material should be flagged for the responsible owner, rather than concealed by fluent prose. Where material is missing, the system should state that evidence is insufficient, instead of using a similar document to generate an apparently complete but inapplicable conclusion.

Retrieval augmentation can help a model use company information. It cannot guarantee that all relevant evidence has been found or correctly understood. Evaluation should therefore examine retrieval and answering separately: were the relevant documents found, was the applicable version prioritised, do citations support individual statements, and were material limitations omitted? Locating failures within these stages helps the team decide whether to correct document structure, retrieval strategy, prompt design or the human review process.

Permissions must extend through the knowledge chain. A model's answer must not reveal document content that the user is not authorised to access. Citations, summaries, caches and exports must respect the same access boundaries. Particular attention is needed for knowledge shared across departments, shared accounts and cache updates following permission changes. Knowledge owners are responsible for content validity, information managers for access boundaries, and business owners for applicability. Together, they determine whether material is suitable for formal use.

A dependable application should not leave all judgement to the model. The input layer checks information and permissions; the knowledge layer supplies traceable evidence; the model layer summarises or generates; the business layer validates critical constraints; and the human layer handles matters requiring professional judgement. Technologies may differ between layers, but responsibilities must be explicit. Where precise calculation or fixed rules are needed, use verifiable calculation and rule-based capabilities and let the model explain their results, rather than deriving numbers solely through text generation.

Tool use requires especially clear boundaries. Reading information, creating a draft, editing a record and executing an operation are different permissions. Access to a question-answering service should not automatically confer the ability to modify business systems. Apply the minimum necessary authority and specify which actions require a preview, confirmation or secondary check. Changes to material business states should retain the operator, supporting inputs, execution result and rollback method. Test that repeated calls or network failures cannot cause duplicate effects.

The release design should also cover cases in which the system cannot answer or proceed. Model timeouts, missing evidence, insufficient permissions and failed validation should produce explicit statuses and guide users back to the existing workflow. Human takeover requires more than a button: someone must be available to receive the issue, with sufficient context and an agreed response time. Business operations should not depend on one model being permanently available. Critical workflows must remain executable when AI is paused.

Evaluation samples should reflect the actual distribution of tasks, including common and complex questions, conflicting information, missing evidence and unauthorised requests. Business experts should define acceptable results and unacceptable errors before selecting model-based and human assessment methods. Development samples should be appropriately separated from final acceptance samples, so teams do not repeatedly optimise for known questions. Where samples are limited, state the scope of the conclusion rather than presenting a few successful demonstrations as evidence of comprehensive capability.

Quality assessment must go beyond whether an answer is satisfactory. Assess factual accuracy, support from citations, completeness of critical limitations, practical usability and whether the application respects situations in which it should not answer. Errors with serious consequences may warrant their own release-blocking criteria; they cannot be offset by high scores on many simple questions. Where expert judgement is required, record disagreements and establish explainable assessment rules rather than treating individual preferences as a common standard.

Business impact should be measured across the complete task: preparing material, using the application, verifying outputs, making corrections and delivering the result. Comparisons should account for task difficulty and user proficiency, and retain failed or abandoned tasks rather than counting successful use alone. Staff feedback should identify specific friction, such as hard-to-find citations, overlong answers or repeated uploads. A satisfaction questionnaire alone is insufficient grounds for expanding deployment.

Every change to the model, knowledge base or prompt template should trigger regression evaluation proportionate to the change. Improvement on one task type does not establish that other tasks have avoided deterioration. Release notes should record what changed, what was tested, known limitations and the rollback version. Acceptance is complete only when the business owner understands the evidence and remaining risks. Technical performance tests cannot replace that owner's confirmation.

Evaluation should also test whether structured outputs are usable. A single inconsistency in units, time periods, equipment identifiers or missing-value treatment can distort downstream analysis. Results intended for another system should be checked for field format, permitted ranges and business relationships, while distinguishing generated content from original data. An output corrected by a person must not subsequently be counted as an unassisted model success. Retaining the differences before and after correction reveals how much professional support the application actually requires.

AI training should teach staff not only how to ask questions, but how to inspect answers, recognise limitations and report problems. Position the system as a supporting stage in the workflow. Specify which outputs may be used as drafts, which require professional review and which must not be used for actual operations. The interface should show sources and status, without using an overly authoritative presentation that suggests every answer has been confirmed by an expert.

Human review needs an executable checklist. Technical answers may require checks of equipment model, operating conditions and document version; contract assistance may require comparison with original wording, exceptions and missing information; business analysis may require checks of data definitions, time periods and reasoning. Reviewers must have the evidence and authority to reject an output. Otherwise, 'human in the loop' can become a ceremonial confirmation click. As task volumes grow, review capacity must be reassessed.

The feedback loop should distinguish content errors, retrieval failures, permission issues and mismatches with the workflow. Users should be able to flag specific passages and their practical effects so the operations team can prioritise fixes, rather than collecting general opinions while continuing to add features. Recurring issues may justify narrowing the scope or suspending a capability. Allowing users to reject unsuitable outputs is part of building trust, not a signal that adoption has failed.

Model invocation charges are only one part of AI application cost. Knowledge preparation, data permissions, system integration, evaluation, human review, monitoring and ongoing updates all require resources. Compare options using the same task volumes, quality requirements and service scope. Distinguish costs that rise with use from those arising from fixed operational responsibilities. Comparing the price per call alone cannot determine whether an internally built, purchased or hybrid solution is more economical.

The business owner should own the value objective; the product or operations team should maintain the user experience; the technology team should manage models and integration; knowledge owners should maintain content; and the relevant control functions should check boundaries. Each responsibility needs a deputy and a working cadence. Once the application is in routine use, adding departments, widening data access or granting execution permissions should be assessed as business changes, rather than treated as ordinary account provisioning.

Operational dashboards should help managers decide whether to invest further or adjust scope. Alongside usage, track successfully completed tasks, manual rework, critical errors, expired knowledge and service incidents. Low use may reflect poor use-case selection, inadequate information or an inconvenient entry point; interviews are needed to interpret it. Use cases that persistently fail to demonstrate value should be allowed to contract or close. Preserve the learning and reusable components rather than letting sunk investment drive continued expansion.

Cost assessment should also consider knowledge growth and staff handover after the pilot. New material requires review, old material must be retired, and someone must maintain applicability judgements after experts leave. If these activities depend on temporary project-team effort, quality may deteriorate after launch. Before expansion, confirm operating resources, the knowledge-update cadence and issue-response arrangements. Include independent operation after handover in acceptance, so the project becomes a service with continuing ownership.

Initiation should produce a use-case definition, accountability boundaries and an evaluation baseline. Validation should establish controlled knowledge, representative samples and a working process. Limited release should record actual use, errors and human workload. Expansion should then test organisational and technical capacity. Each stage needs criteria for continuing, adjusting or stopping. The purpose of staging is to reduce uncertainty, not to burden a simple use case with excessive approvals.

Expansion cannot consist of copying an interface. A new business area may use different terminology, authoritative documents and responsibility arrangements that existing samples do not cover. Identify which access-control, evaluation and operating components are reusable, then validate the new knowledge and business rules. A change in supplier or model also requires checks of data-processing scope, historical traceability and output behaviour. The company should retain the ability to explain decisions and exit the arrangement, rather than becoming tied to one demonstration or technology label.

Management can test readiness to expand through four questions: is there comparable evidence of business outcomes; is there a response path for critical errors; does continuing operation have an owner; and can the work still be completed if the service is paused? Where answers are unclear, strengthen the relevant capability before expansion. In ZHICE's view, energy AI creates value by repeatedly completing real tasks within explicit boundaries and earning users' trust through accumulating evidence, rather than moving directly from a pilot label to a promise of scale.