NIST's AI Risk Management Framework is a voluntary resource supporting risk management across AI design, development, use and evaluation.[1] The public overview of ISO/IEC 42001 addresses establishing and continually improving an AI management system.[2] NIST's Generative Artificial Intelligence Profile adds perspectives specific to generative applications.[3] This report draws on them to discuss organisational methods, not to provide a compliance conclusion or evidence of certification for a particular application.

Governance in an energy company starts with knowing which activities use AI, what information it processes and how outputs influence work. A model inventory alone does not explain risk. The same model might summarise public material or analyse internal equipment information, with very different permissions, error consequences and review needs. The governance object should be the application and its purpose, connecting responsibilities and controls to real work rather than a technology name.

ZHICE recommends defining governance objectives as observable behaviour: unauthorised data do not enter processing; outputs outside the intended scope are not executed directly; significant changes receive appropriate validation; and exceptions are detected and handled. Specific objectives make control effectiveness assessable. Terms such as 'safe', 'trustworthy' and 'controllable' are difficult to translate into role actions or accountability after an incident unless they identify an object and supporting evidence.

Governance intensity should vary with consequences and permissions, rather than impose the same cost on every application. Low-impact information preparation may use simple registration and sampling; higher-impact assistance needs fuller validation; actions involving actual control or important commitments require strict authority and specialist assessment. Classification directs limited attention towards material risks while providing a clear route for bounded exploration, avoiding both excessively broad policy and a one-size-fits-all approach.

Registration should identify at least the business purpose, users, input data, model or supplier, output destination, callable tools and ultimate owner. Record whether use is an individual's temporary assistance, a shared departmental tool or an established business workflow. The purpose is not to maximise fields, but to make data flows, permissions and issues requiring further review visible to management.

The business owner is accountable for purpose, effects and usage boundaries; the technical owner for implementation and operating condition; data owners for authorisation and applicability; and control functions for risks and exceptions. An application owner cannot transfer all accountability to the model supplier or omit necessary controls on the grounds that users should exercise judgement. People may combine roles, but significant decisions must identify who proposes, reviews, approves and monitors.

The inventory should include uses outside formal procurement. Staff may process material with general tools, partners may use AI in their deliverables, and existing software may gain generative functions through upgrades. Provide a simple reporting and advice route, with clear rules on permitted inputs. When unassessed use is discovered, establish the actual data and impact before responding. Blocking a product name alone does not establish that the risk has disappeared.

Registration should change with the business. New users, wider data sources, a different output purpose or execution tools may make the original assessment insufficient. Define change triggers that staff can recognise, with the business owner deciding whether reassessment is required. Applications that lack an active owner or an explainable scope should not expand. When use ends, address accounts, data, interfaces and historical records as well.

Classification should consider error consequences, data sensitivity, output reach and autonomy together. A tool that drafts internal text and one that edits business records need different controls even if they share a model. Specify which applications may provide information, offer recommendations or propose actions for confirmation, and which functions must remain with people or existing control systems. Technical feasibility is not business authorisation.

Set hard boundaries for unacceptable behaviour, such as unapproved access to production-control interfaces or disclosure of restricted information to an unauthorised user. Low-risk scores on other dimensions cannot offset these boundaries. Residual risk can receive tiered approval and monitoring, with its basis, validity period and owner stated. If evidence is missing, narrow the purpose, add validation or defer release rather than rushing to assign an apparently complete risk level.

Classification should determine concrete controls. Lower-impact uses may emphasise guidance, permissions and sampling; moderate-impact uses add representative tests, citations and human review; higher-consequence uses require specialist analysis, independent checks, mandatory authority and verifiable rollback. The boundaries depend on the business and applicable requirements. A generic matrix is not a legal classification, and management categories cannot replace necessary professional safety judgement.

Application behaviour depends not only on the model but also on prompt templates, knowledge, retrieval settings, tool permissions and business rules. Recording the model name alone cannot explain different outputs. Maintain version records appropriate to the application, retaining critical configurations and reasons for change. Where an external service does not disclose all internal changes, record the available version information and service conditions, and use continued evaluation to detect behavioural shifts.

Start change management with impact analysis. Correcting an obvious document error does not need the same approval intensity as widening data access, adding tools or changing the model, but each needs an explanation of its effect. Select regression samples according to impact, test permissions and business boundaries, then decide whether to release. Emergency fixes can use a predefined accelerated process, with approval and retrospective review retained so the emergency route does not become a routine way around evaluation.

At release, define the observation period, owner and rollback conditions. Rollback must account for relationships among the model, knowledge, configuration and business state; restoring one software version may be insufficient. If the new version has already changed business records, assess whether they need correction. Pausing service also affects continuity, so prepare manual routes or alternative tools. The objective is to contain impact and restore work when problems occur, not to promise error-free technology.

Evaluation materials should allow an owner who did not develop the application to understand what it can and cannot do and why the current risk is accepted. Include at least purpose, representative samples, error categories, permission tests, human-review design and exception routes. An average accuracy score alone can conceal critical limitations or overstate capability through a sample dominated by easy tasks. Results must correspond to the actual scope of use.

Samples should cover normal and boundary tasks: missing, conflicting or expired information; unsuitable equipment or contexts; and requests for unauthorised access or execution. For content such as prompt injection that may alter behaviour, test whether the system still respects its established permissions and business limits. Use controlled samples with appropriate isolation and authority. Risk testing should not expose real sensitive information to an unapproved service.

Human review needs practical capability. Reviewers require business knowledge, access to evidence, time to inspect and the authority to reject an output or require rework. Heavy workloads, interface cues and fluent answers can reduce review to mechanical confirmation. Sample actual review records to see whether critical fields, citations and limitations were checked, and correct problems through training and workload arrangements rather than adding another 'I have read this' box.

Evidence retention should be proportionate. Logs need enough detail for traceability while limiting repeated collection of sensitive inputs and personal information. Define contents, access roles, retention periods and deletion, distinguishing operational monitoring, business audit and model-improvement purposes. Potential future usefulness does not justify keeping every conversation indefinitely. Equally, storage savings should not remove the records needed to explain a critical decision. Retention must balance the management purpose and applicable requirements.

Post-release monitoring should observe actual risk, not only uptime. Track critical errors, attempts to exceed permissions, expired knowledge, human rework, abnormal tool use and complaints, with clear escalation criteria. Measures should retain usage scope and task mix so increased volume is not automatically interpreted as worse quality, or declining feedback as lower risk. Significant exceptions should be traceable to a specific version and business impact.

Response can follow detection, containment, analysis, recovery and review. First establish affected applications, users and data, then take necessary measures such as pausing a function, restricting permissions or switching to a manual route. Do not declare resolution before the cause is understood. Verify control effectiveness before restoration and assess whether related business records require correction. Responsible staff determine external communications and any required reporting under applicable requirements, avoiding circulation of unverified information.

Review should look beyond one prompt or output. Examine incorrect knowledge, gaps in permission design, inadequate evaluation samples, excessive staff workload and unrecognised supplier changes. Turn findings into tasks with owners and acceptance conditions, and check other applications for the same weakness. Recording an incident without changing knowledge, process or controls does not allow governance to learn from real operation.

Incident classification should consider downstream propagation. An incorrect explanation remaining in a private draft has a different scope from one copied into several reports or triggering subsequent workflows. Trace actual use after discovery, flag affected outputs for review where needed and confirm that corrections reach users. Include propagation in exercises rather than checking only that the original application has recovered. Restoring availability and removing business impact are separate states requiring separate confirmation.

When procuring AI, compare how the service actually operates, not only model performance. Establish how inputs are processed and retained, who can access them, how the service changes, how incidents are communicated and how data and records are treated after termination. Deployment models allocate responsibilities differently. Make the company's own controls explicit rather than equating either cloud use or local deployment with resolution of all risk.

Supplier changes and limitations belong in routine operations. Version changes, interface changes, service-region changes and discontinued functions can affect prior evaluation. Contracts and operating arrangements should cover information provision, notification, support and exit, with their practicality checked. Where a supplier cannot provide details, state the remaining uncertainty and reduce dependence through narrower use, independent tests or fallback routes. Approval materials should not assume those gaps do not exist.

Validate exit capability in advance. The company should be able to export required business records, knowledge and configuration, with usable formats and permissions, rather than lock every workflow into irreplaceable proprietary operations. Historical records must remain available for audit and investigation after a supplier change. Account closure, interface revocation and cache treatment belong in the exit checklist. A controlled sample can test migration without disrupting the live service, but it must establish that the route works.

Begin with a small set of applications with different risk characteristics and complete registration, classification, evaluation, release and an exception exercise for each. Test whether forms are understandable, responsibilities conflict, review materials are adequate and response actions are executable. Refine policy through actual work rather than trying to cover every possible situation in advance. Complex cases not yet encountered can retain principles and escalation routes without creating extensive unused approvals.

Management dashboards should focus on decisions: high-impact applications missing critical evidence, expiring exceptions, recurring problems, expanded permissions and services requiring retirement. Application counts, registration rates and training attendance can provide context but cannot alone establish controlled risk. Periodically sample complete cases from input and authority through output, business use and subsequent review to test whether the arrangements work in practice.

The result should be clear accountability: business owners can explain why AI is used; technical teams can describe how it operates; data owners can identify its evidence; control functions can inspect boundaries; and users know when to stop and ask for help. ZHICE recommends treating these capabilities as practical evidence of governance maturity. Governance creates value by allowing an organisation to explore new capability while retaining the ability to judge, correct and exit.

When extending policy, check that staff can easily obtain appropriate tools and assistance. If formal processes are too cumbersome while work requires quick handling of information, people may turn to external tools that are harder to govern. Provide clear permitted uses, convenient applications for access and responsive support, improving rules through actual feedback. Governance depends both on clear limits and on a usable compliant route; management review should assess the two together.