AI governance building blocks for energy utilities: roles, approval path and AI register

The eleven building blocks at a glance

The order is deliberate. Start with the policy and you write rules for systems you don't know. Start with the register and you have a list nobody owns. So the inventory comes first, with the roles right behind it.

Each building block has a purpose, minimum content, a legal basis and an accountable role. We split the pitfalls by size: a municipal utility with a few hundred staff, where data protection, information security and IT often sit with a handful of people or a service provider, and a larger utility with its own legal department, several legal entities and its own procurement.

Building block 1: Inventory and obligation check

The inventory answers two questions: which AI systems are running or on order, and what role does the company play for each one? Only then can you say which obligations apply.

There is more to count than IT has on its radar. AI sits in business applications whose vendors switch it on with an update, in the customer service tool, in applicant management, in the office suite. And in browser tabs nobody registered.

Minimum content:

• a list of all AI systems in production, in testing and in procurement, per legal entity
• the role for each system: provider or deployer (Art. 3(3) and (4) AI Act)
• a check against obligations that already apply: prohibited practices (Art. 5, since 2 February 2025), AI literacy (Art. 4), transparency (Art. 50, since 2 August 2026)
• a check against obligations with later dates: deployer obligations under Art. 26 for Annex III from 2 December 2027, for Annex I from 2 August 2028
• one gap per obligation, with an owner and a date

The concept of role is the first pitfall. A utility that buys access to a language model through an API, builds a chatbot on it and puts it into service under its own name is the provider of that chatbot, not just its deployer (Art. 3(3)). The disclosure duty under Art. 50(1) then sits with the utility itself.

At a municipal utility the gap is usually AI inside purchased software. A questionnaire to the five to ten most important software suppliers often yields more than an internal search, because the vendors know what is in their products.

At a larger utility the list is long but scattered: the grid company keeps its own inventory, and so do retail and generation, each in its own format. The work lies in merging them.

Accountable: the AI lead, together with business units and IT.

Building block 2: Roles and bodies

The AI Act requires neither an AI officer nor an AI board. The Commission says so explicitly in its questions and answers on Art. 4. You still need the roles, because someone has to classify, approve, follow up and report. Without a name, it doesn't happen.

Minimum content:

• AI lead: appointed by management, with a time budget and a deputy
• AI board: decides on approvals with elevated risk, meets as needed rather than monthly
• Business owner: one person per use case who owns it functionally and organises human oversight
• Interfaces: data protection officer, information security officer, legal, works council or staff council, procurement, IT
• Management: adopts the policy, decides escalations and the operating model

For high-risk systems a statutory role comes on top: deployers must assign human oversight to people with the necessary competence, training and authority (Art. 26(2)). Management's responsibility for risk management is already in German law, in § 5e EnWG for grid and plant operators and in § 38 BSIG for NIS2 entities. AI systems belong in there like any other IT system.

At a municipal utility the board is easily planned too big. Where the people involved talk every week anyway, it needs no rules of procedure of its own. A standing item in the existing IT or security committee is enough.

At a larger utility the question is where the board sits: group, grid company or both. Unbundling and critical-entity status apply per legal entity. A central approval for the grid company has to reflect that.

Accountable: management appoints, the AI lead coordinates.

Building block 3: Policy framework

An AI policy framework has two levels. At the top, an AI policy that rarely changes. Below it, work instructions that are allowed to change when a new tool arrives.

Minimum content of the AI policy:

• scope, terms, roles from building block 2
• a ban on the practices in Art. 5, explicitly including emotion recognition in the workplace (Art. 5(1)(f))
• a duty to register every use case before it goes live
• data principles: no personal data, metering data or trade secrets in services that are not approved
• references to process, register and training

Work instructions cover the specifics: which generative AI tools are approved and with which data, how AI-generated text published to inform the public is labelled (Art. 50(4)), and who checks outputs before they leave the building.

A policy on generative AI almost always touches co-determination. Under § 87(1) no. 6 of the German Works Constitution Act (BetrVG), the works council has a say on technical equipment capable of monitoring behaviour or performance. In 2024 the Hamburg labour court ruled in interim proceedings (24 BVGa 1/24) that permitting ChatGPT use via private accounts did not trigger co-determination. That can't be carried over to a tool the employer provides and logs itself.

At a municipally owned utility the BetrVG may not apply, depending on legal form; the state's staff representation law applies instead. Municipal enterprises and public-law institutions have a staff council. That changes deadlines and procedure.

At a larger utility the policy often sits with the group and the work instructions with the subsidiaries. That works as long as the subsidiaries don't keep their own, conflicting tool lists.

Accountable: the AI lead drafts, management approves.

Building block 4: Process from registration to decommissioning

Every use case takes the same path, pilot or production. For low risk the path can be short. It can't be missing.

1. Registration. The business unit describes purpose, data, provider and user group in a form that creates a register row directly.
2. Review. The AI lead classifies (building block 5) and brings in the interfaces the case touches: data protection for personal data, information security for new services or interfaces, the works or staff council for employee data, procurement for new contracts.
3. Approval. For minimal risk the AI lead approves. For transparency duties, personal data or high risk, the board decides, with conditions and a review date.
4. Change. New purpose, new model, new data source: the case goes back to review. A changed intended purpose can turn a deployer into a provider (Art. 25(1)).
5. Decommissioning. Switch off, delete data and logs after the retention period, close the register row rather than deleting it.

Step 4 is the one most easily forgotten. A vendor update that switches on a new AI feature is a change, even if nobody ordered anything.

At a municipal utility the process dies of bureaucracy if every office tool has to go to the board. A whitelist of approved standard tools with fixed data rules keeps the path clear for everything else.

At a larger utility AI registrations run in parallel with the architecture board, the data protection workflow and procurement approval. Four forms for one case is three too many. A single entry point that hands over to the other processes spares the business units the double work.

Accountable: the business owner registers, the AI lead runs the procedure, the board decides where risk is elevated.

Building block 5: Risk classification

Classification assigns each system to one of four tiers and gives the reasons. The reasons matter more than the result, because they are what a regulator reads later. A system can carry two tiers: a high-risk system with customer contact also has transparency duties.

For energy utilities, Annex III point 2 is the core question: AI used as a safety component in the management and operation of electricity, gas or heating supply. The Commission's draft guidelines of 19 May 2026 tie this to two conditions. The AI has to protect the physical integrity of the installation directly, and its operator has to be designated as a critical entity under the CER Directive, in Germany under the KRITIS umbrella act. Forecasting, efficiency and pure cybersecurity AI fall outside. The draft is not final. The details are in our article on Annex III and the draft guidelines.

That is why the register has its own field for the condition "critical entity checked". The same software can be high-risk at one grid operator and not at the one next door.

Two traps outside point 2. Emotion recognition as the AI Act defines it rests on biometric data (Art. 3(39)): sentiment analysis of text isn't emotion recognition, voice analysis can be. And HR software that ranks job applications with AI is high-risk under Annex III point 4, at a municipal utility as much as in a group.

The role is part of the classification. Under Art. 25(1), deployers become providers themselves if they put their name on a high-risk system, modify it substantially, or change a system's intended purpose so that it becomes high-risk. For a first assessment, the Bundesnetzagentur's AI service desk offers an online tool.

At a municipal utility critical-entity status is often unclear as long as the ordinance under the KRITIS umbrella act is missing. The field then stays "open", not "no".

At a larger utility several subsidiaries classify the same product differently. One shared rationale per product, supplemented by the use per entity, prevents that.

Accountable: the AI lead, with legal for borderline cases.

Building block 6: AI register

The AI register is the one list all other building blocks read from. Process, review dates, training records and the management report hang off it. The AI Act doesn't spell out a duty to keep such a register. Without one, though, the Art. 26 obligations are hard to evidence. The model is the record of processing activities under Art. 30 GDPR, which every company already keeps.

The fields are chosen so that each row answers the regulator's three questions: what, who, why classified this way. Each field definition can be linked individually.

At a municipal utility a spreadsheet is enough. A dedicated tool only pays off once the register has more than a few dozen rows or several entities write to it.

At a larger utility there is usually already an application inventory in the architecture tool and a record of processing in data protection. The AI register belongs next to them as a view, not as a third list with its own master data.

Accountable: the AI lead keeps it, business owners maintain their rows.

Download the AI register template

The template contains the 23 fields above and one fictitious example row. The XLSX version has drop-down lists for the fixed values and a second sheet with the field definitions and a link back to this page. The CSV version is comma-separated and UTF-8 encoded.

Free to use and adapt, no registration. The example row is invented. The template is a working aid, not a check of whether a system meets the obligations of the AI Act.

Building block 7: Operation and monitoring

After approval comes the work most often underestimated. For high-risk systems, Art. 26 makes it an explicit deployer duty from 2 December 2027. For all other systems it's good practice, because models change and data drifts.

Minimum content for high-risk systems under Art. 26:

• use in line with the provider's instructions for use, with technical and organisational measures (para. 1)
• human oversight by competent, trained people with the necessary authority (para. 2, with Art. 14)
• input data that is relevant and sufficiently representative for the intended purpose, to the extent the deployer controls it (para. 4)
• monitoring of operation; where there is a risk, inform the provider or distributor and the market surveillance authority and suspend use; for a serious incident, inform the provider first without delay, then the importer or distributor and the authority (para. 5)
• keep automatically generated logs for at least six months, to the extent they are under the deployer's control (para. 6)
• before putting a system into service at the workplace, inform workers' representatives and the affected workers (para. 7)

Para. 7 is a duty to inform, not a co-determination right. Co-determination comes from the BetrVG or state staff representation law and runs alongside. Since 2021 the BetrVG names AI explicitly: in § 80(3) (experts), § 90(1) no. 3 (information at the planning stage) and § 95(2a) (selection guidelines).

The fundamental rights impact assessment under Art. 27 does not apply to Annex III point 2. For other high-risk systems, such as in recruitment, it can apply if the company counts as a private entity providing public services. Whether a municipal utility does is a legal question.

At a municipal utility much runs as cloud software, and the logs sit with the vendor. Whether the deployer "controls" them is decided by the contract (building block 9), not by the technology.

At a larger utility operations monitoring measures availability and response times. A forecasting model that runs stably and gets steadily worse doesn't show up there.

Accountable: the business owner for oversight and results, IT operations for logs and availability.

Building block 8: AI literacy

Art. 4 has applied since 2 February 2025 and covers every energy utility that uses any AI at all, whatever the risk tier. Since 27 July 2026, Regulation (EU) 2026/1744 has softened it: providers and deployers take measures to support the development of AI literacy. The text no longer demands a specific level per person. Nor a certificate, the Commission writes in its questions and answers. Since 2 August 2026 national authorities supervise compliance, in Germany generally the Bundesnetzagentur.

Softer doesn't mean gone. If you can't show any measure, you've missed the softer duty too. And for oversight staff on high-risk systems, Art. 26(2) is unchanged.

Minimum content, by audience:

• all staff with access to generative AI: how it works, its limits, data rules, labelling
• business owners: classification, process, oversight, handling errors
• oversight staff on high-risk systems: the specific system, its instructions for use, how to intervene and switch off
• management: the obligations, liability, reporting
• a record per person and measure, linked in the register through the "training completed" field

At a municipal utility a one-hour basic training for everyone is quickly done. Easily overlooked is the second tier for the few people who actually oversee a system.

At a larger utility training runs through the learning platform and the completion rate looks good. Whether the control room treats an AI system in grid operation differently from an office tool, the rate doesn't tell you.

Accountable: HR development with the AI lead.

Building block 9: Procurement and contracts

Most AI systems at an energy utility are bought in. What the provider has to deliver so the deployer can meet its obligations belongs in the tender and the contract, not in renegotiation.

Minimum content:

• a statement from the provider on whether the system contains AI and how they classify it, with reasons
• for high risk: instructions for use under Art. 13, conformity assessment and CE marking as provider obligations under Art. 16
• access to logs for at least six months, storage location, export
• notice of new AI features before rollout, with a right to switch them off
• incident reporting channels in both directions
• data use: no training on customer or metering data without explicit agreement

For providers of high-risk systems, EN 18286 on quality management has existed since July 2026. According to CEN-CENELEC JTC 21, it has been cited in the Official Journal since 14 October 2026 by Commission Implementing Decision (EU) 2026/2274, the first harmonised standard under the AI Act. For the quality management requirements of Art. 17 it therefore gives a presumption of conformity. A deployer can ask in procurement whether the provider works to it. It isn't proof that the delivered system meets every requirement.

There is a template for the clauses: the EU model contractual clauses for the procurement of AI (MCC-AI), published by the Community of Practice on Public Procurement of AI, current version dated 5 March 2025. There's a full version for high-risk systems and a light version for everything else. They are written for public buyers, and many municipal utilities award contracts under procurement law themselves as utilities-sector contracting entities. They aren't binding, and they predate the Digital Omnibus.

At a municipal utility contracts are often the standard terms of large software houses. There's no bargaining power. Joint requirements through cooperations or purchasing groups help more than negotiating alone.

At a larger utility procurement knows the requirements. Orders by credit card or through a cloud marketplace bypass it, though. Building block 4 has to catch that.

Accountable: procurement, with legal and IT.

Building block 10: Reporting to management

Management doesn't need register extracts. It needs one page per quarter.

Minimum content:

• number of systems per tier and legal entity, with the change on the previous quarter
• open classifications, especially "critical entity open"
• overdue reviews and approvals with conditions
• incidents and reports
• training status per audience
• changes in the law with dates, for instance from the deadline calendar

For grid and plant operators, § 5e EnWG obliges management to implement the IT security catalogue and to oversee its implementation; § 38 BSIG requires the same for risk management at NIS2 entities. An AI report that feeds into the existing ISMS report uses that channel instead of building a second one.

At a municipal utility a report seems unnecessary, because management is close to everything anyway. Until the regulator's first enquiry.

At a larger utility there are many reports, and the AI report risks becoming the sixth traffic-light slide. One metric that moves is worth more than twenty that stay green.

Accountable: the AI lead.

Building block 11: Operating model

Who does the work once the project is over? There are three possible answers, and in every case the obligations stay with the deployer.

The decision goes to management as a paper, with the effort in person-days and the risks of each model. And with a clear answer on who is accountable. It can be revisited after a year. Without a decision, the project becomes the operating model.

Accountable: management.

ISO/IEC 42001, ISMS and GDPR: where the building blocks connect

None of the building blocks needs a new management system. Each needs a place in the existing ones.

ISO/IEC 42001:2023 is the management system standard for AI. It covers building blocks 2 to 7 in the familiar structure of context, leadership, planning, operation and improvement. Certification is possible. It isn't a harmonised standard under the AI Act, so a certificate doesn't show that the regulation is met.

ISO/IEC 27001 has long been mandatory for German grid operators, with certification, through the IT security catalogue under § 5c EnWG. If you already keep assets, risks and suppliers there, AI systems go into the same lists. Since the German NIS2 implementation act entered into force on 6 December 2025, risk management under § 30 BSIG applies to far more entities. The BSIG has no AI section. AI systems fall under the general measures. For systems using language models, the BSI has published its own guidance, including "Generative AI Models: Opportunities and Risks for Industry and Authorities".

GDPR: where personal data is processed, Art. 35 on data protection impact assessments applies. Deployers of high-risk systems use the provider's information under Art. 13 AI Act for it (Art. 26(9)). The German data protection conference (DSK) has published guidance on AI and data protection (May 2024) and on generative AI with RAG (October 2025). Readings from smart metering systems are additionally subject to purpose limitation under the German Metering Point Operation Act (MsbG).

That's also the answer on effort. A utility with a certified ISMS and a maintained record of processing builds less from scratch than the list of eleven building blocks suggests.

Sources

Frequently asked questions on AI governance

More on AI

How we build these blocks with energy utilities and take them into operation is described under AI governance for energy utilities. Which use cases exist and how they fit under the AI Act is shown on the AI use case map for energy utilities. The guide to the EU AI Act for energy utilities explains the regulation's obligations in detail, and the dates are in the deadline calendar. All articles are collected in the topic field AI in the energy industry.