AI agents in market communication: what may run without approval
Since 1 January 2026, section 20a of the German Energy Industry Act (EnWG) requires the technical supplier switch to be completed within 24 hours, and since 1 October version 1.1 of the APERAK handbook applies. Agents that read rejections, draft corrections and send messages are no longer a technical feat. What suppliers, grid operators and metering point operators still have to settle is something else: where the human approval sits, who answers for a wrongly sent message and what has to go into the log.
An AI agent in German energy market communication is a system that reads incoming EDIFACT messages and APERAK error messages, assigns them to an error type and a check identifier (Prüfidentifikator), and proposes corrections or sends them itself; it concerns suppliers, grid operators and metering point operators, who have had to complete supplier switches within 24 hours since 1 January 2026 (section 20a EnWG). How much an agent may do without human approval should be tiered by error type and external effect: reading and assigning automatically, assignment and master data errors only as a proposal, pure format errors in the utility's own messages with sampling, and terminations, deregistrations, cancellations and changes of assignment never automatically. Responsibility stays with the market role: under section 20a(4) EnWG the supplier or grid operator bears the burden of proving it is not responsible for a delayed switch. Under the EU AI Act such an agent is usually not a high-risk system, but liability, data protection and IT security still call for governance.
Where an agent works in market communication
A supplier sends a registration for a supply start at 9:12. At 9:40 the APERAK comes back: error code Z29, a required field for this use case is missing. From here nothing runs by itself. Someone has to find out which field, locate the value in the utility's own system and send a new message.
No language model wrote that APERAK at 9:40. On the recipient's side, the AHB check is a rulebook: load the check template, compare mandatory fields, report the result. A deterministic checker does that in seconds, and that's where it belongs. An agent sits on the other side, where people today read rejections, hunt for causes, write follow-up emails and keep deadlines in view.
Germany's Federal Network Agency (BNetzA) wants that automation. It designed the 24-hour switch so that powers of attorney are normally not sent, explaining that it wants "to continue to enable the greatest possible automation of the processes required for a supplier switch" (our translation). Vendors already sell AI layers over UTILMD, MSCONS and APERAK that classify error codes and propose fixes. Almost all of them describe a human who approves the exceptions. Their performance figures come from the vendors themselves.
And the utilities? According to a PwC study reported by ZfK on 13 April 2026, 61 percent of those that have introduced AI are still at an experimental stage. How exception-handling models get out of the pilot is covered in our article on AI for exception cases in market communication and metering. This one is about the step after that: an agent that doesn't just sort, but has write access.
LFW24 and the response deadlines
It's tight enough for an agent to save real time. It's also tight enough for an agent's mistake to reach the customer immediately. Since 1 January 2026, section 20a(2) sentence 4 EnWG has required the technical supplier switch to be completed within 24 hours and to be possible on every working day. Under BNetzA ruling BK6-22-024, a working day is any day that isn't a Saturday, a Sunday or a public holiday.
| Deadline | For what | Source |
|---|---|---|
| 24 hours | technical process of the supplier switch, on every working day | Section 20a(2) sentence 4 EnWG |
| 45 minutes | APERAK on UTILMD and ORDERS, electricity | APERAK handbook 1.1, sec. 2.4.1 |
| Sunday 12:00 | APERAK on UTILMD and ORDERS received on a Saturday | APERAK handbook 1.1, sec. 2.4.1 |
| next working day 12:00 | APERAK on all other electricity message types, errors in follow-up processes in gas | APERAK handbook 1.1, sec. 2.3.1 and 2.4.1 |
| 3 working days | APERAK on errors in initial processes, gas | APERAK handbook 1.1, sec. 2.3.1 |
| 2 hours | answer to the assignment request | BK6-22-024 |
One rule in the APERAK handbook turns these deadlines into an argument for speed on the sender's side. A justifiably rejected business transaction is treated as "not received" by the recipient. A corrected resend starts the deadlines again from the new sending date. Every hour between rejection and resend is an hour lost to the customer who wants to switch.
Two dates shift the error picture. Since 1 October 2026, new versions of 13 message types have applied under BNetzA notice no. 56, together with version 4.0 of the overview of check identifiers; what actually went live is set out in our article on notice no. 56. On 1 April 2027 the next release follows under notice no. 58. Around each format change, market partners have to tolerate deviations from the APERAK deadlines, for the October change from 30 September 18:00 to 2 October 00:00.
For an agent, that means its knowledge of error patterns goes stale twice a year, on schedule. How the 24-hour switch rebuilt the processes overall is explained in our article on the 24-hour supplier switch.
Four approval levels
How much an agent may do alone depends on the error type and the effect outside the company. Not on the model's hit rate. A 98 percent hit rate sounds good until the other two percent turn out to be deregistrations.
Conveniently, the APERAK brings its own classification. The handbook distinguishes four error types: AHB errors, assignment errors (ZO), object property errors (OE) and takeover errors (ÜN). Only the first is pure form, a date in the wrong format or a missing mandatory field. With the other three, the transaction doesn't match what the recipient knows about the market location, the contract or the preceding transaction. The cause usually sits in master data, and nobody should correct master data on a hunch. Why master data is the real bottleneck is explained in our article on master data quality in market communication.
Level 0 can always run: read, assign, route to the right team, compute the deadline. Nothing leaves the building. Level 1 is the default for assignment, object property and takeover errors, where the agent submits a draft with its reasoning and a person decides and sends. At level 2 the agent sends itself, but only after a click, for corrections that change content. Level 3 lets it send alone. That only fits AHB errors in the utility's own messages where the correct value is unambiguous in its own system, such as Z35, "format not observed". A sample is checked afterwards.
Below all levels runs a line. Terminations, deregistrations, cancellations and changes of assignment are never sent by an agent without a person, however confident the model is. These messages change who supplies a customer, or whether the customer is supplied at all. A second message doesn't simply undo that.
A detail from the APERAK handbook that agent builders should know: the check identifier "serves exclusively to carry out the AHB check. Any further use of the check identifier beyond the AHB check is not permitted" (our translation). An agent may read it to match a rejection to the right check template. Its approval logic should hang on the error type and the content of the transaction, not on the number.
What about the days around a format change? Then every agent goes back to level 1 for a while. We consider that the single most important rule, because new error patterns show up exactly when the model hasn't seen them yet.
Who is liable when the agent sends
The market role. An agent isn't a market participant, and neither is its vendor. The APERAK handbook phrases the sender's duty without regard to who or what produced the file: the sender is "responsible for a plausible, correct in content and syntax, and completely filled transmission file" (our translation). If the recipient reports errors, the sender has to fix them "without culpable delay" and remains bound by the process and response deadlines.
For supplier switches, statute adds to that. If a switch runs past the deadline, the final customer can claim damages under section 20a(4) EnWG from the supplier or grid operator responsible for the delay. The second sentence is the one that matters: the supplier or grid operator "bears the burden of proof that it is not responsible for the delay" (our translation). On top of that sits supervision. BNetzA can order compliance with section 20a EnWG and BK6-22-024 under section 65 EnWG and enforce it with penalty payments of up to 10 million euros (section 94 EnWG).
| Role | Where an agent helps | Where approval stays |
|---|---|---|
| Supplier | matching rejections of a registration, filling in missing data from its own system, drafting the customer confirmation under section 20a(1) EnWG | termination with the previous supplier, deregistration, anything that promises the customer a supply date |
| Distribution system operator | pre-sorting exception emails from suppliers, preparing answers to assignment requests, watching deadlines | changes to market location and assignment, cancellations, rejections that affect the supply start |
| Metering point operator | evaluating APERAKs on MSCONS, fixing format errors in its own meter data messages | substitute values and corrections of readings that feed into a bill |
With agents, the burden of proof becomes a question for the technology. Anyone who has to show they weren't responsible for a delay needs a timestamp and a traceable decision for every step, including the ones that ran at three in the morning with nobody watching. Without that, the utility goes into a dispute empty-handed.
With a bought-in agent this belongs in the contract: who owns the logs and decision history, how fast does the vendor hand them over in a dispute, and who may change thresholds? This is a general assessment by role, not a review of your individual case.
What belongs in the log
Every step the agent takes has to be reconstructable later: what came in, what it made of it, who approved, what went out and when. You need that for two reasons that have nothing to do with the AI Act.
- receipt with timestamp, message type, check identifier, error code and a reference to the rejected transaction
- the agent's proposal with its reasoning and approval level
- model version, rule version and the version of the format specification it was checked against
- name or role of the person who approved, and when
- time of sending and the market partner's reply
First, the burden of proof under section 20a(4) EnWG. Second, the next release: the clerks' decisions after 1 April 2027 are the material from which the agent learns the new error patterns. Fail to record them with their reasons and you start from scratch every six months.
For how long? The AI Act requires deployers to keep automatically generated logs for at least six months, under Article 26(6), though only for high-risk systems. As a floor, the figure still works. Data protection sets the ceiling: a UTILMD carries customer names and addresses, and a log that mirrors them needs a deletion concept like any other copy.
The log isn't an appendix for the supervisor. It's the evidence that section 20a(4) EnWG demands from suppliers and grid operators, and the training material for the next format change.
AI Act: usually not high-risk, governance anyway
An agent in market communication is an AI system. Article 3(1) of the AI Regulation defines one as a system "designed to operate with varying levels of autonomy". That's precisely what an agent is for.
High-risk it isn't, at least not automatically. Annex III point 2 covers AI systems intended to be used as safety components in the operation of critical infrastructure, including electricity and gas supply. Correcting messages between a supplier and a grid operator protects no installation. According to McCann FitzGerald's analysis, the Commission's draft guidelines of May 2026 expressly exclude systems that merely support or optimise, and also require the operator to be designated a critical entity. The draft isn't final. How typical utility use cases are classified is covered in our article on Annex III and the Commission's guidelines.
What applies anyway is limited, but not zero.
- AI literacy under Article 4, since 2 February 2025. Weakened by the Digital Omnibus: deployers take measures to support the development of their staff's AI literacy. Whoever approves agent proposals needs to know when not to trust one.
- Transparency under Article 50, since 2 August 2026, where a system interacts directly with natural persons. If the agent writes exception emails to clerks at the market partner or confirmations to customers, the question is on the table. A utility that builds the agent itself and puts it into service under its own name may count as a provider under Article 3(3) and owe the labelling.
- Supervision. Since 29 July 2026, BNetzA has been the market surveillance authority for AI under the KI-MIG. The same authority writes the rules of market communication through its Ruling Chamber 6. What that means for utilities is covered in our article on AI supervision by BNetzA.
The tougher requirements come from elsewhere. On 6 November 2025 Germany's Federal Office for Information Security (BSI) published a guide on attacks against language models. It describes indirect prompt injection, meaning instructions that reach the system through third-party content. For a market communication agent, that's the exception emails from market partners: free text from outside that it's supposed to read. As countermeasures the BSI names least privilege for the application and human confirmation of critical actions; its own example is a user confirming or blocking an email dispatch initiated by the model.
So the classification relieves a utility of high-risk duties, not of the work. Almost everything an agent with write access needs in terms of governance comes from the EnWG, BNetzA rulings, the GDPR and IT security law. How we set up approval paths, roles and AI registers at utilities is described on our page AI governance for utilities; more articles are collected in the topic AI in the energy industry.
Where it can go wrong: speed against safeguards
Two federal authorities pull in different directions here, and both have put it in writing.
BNetzA wants speed. In ruling BK6-22-024 of 21 March 2024 it declined to have powers of attorney routinely sent to the grid operator, in order "to continue to enable the greatest possible automation of the processes required for a supplier switch and thus to ensure processing suitable for mass business" (our translation). It rejected MVV's objection that two hours for the assignment request were very ambitious: lowering the requirement for individual market participants was "not conceivable".
BSI wants safeguards. Its guide of 6 November 2025 states that "currently there is no single bullet proof solution for mitigating evasion attacks". Even market leaders using several layers of mitigation, it adds, struggle to defend against them reliably. Hence the human confirmation before critical actions.
The Federation of German Consumer Organisations (vzbv) had warned in the same proceedings that shorter switching processes leave less time to act against contracts signed without the customer's consent. And the ruling chamber itself held back from shortening a deadline for billing data at once, because the "concern that the greater time pressure could lead to more errors" prevailed. It hasn't given up on the goal: "a shortening will therefore be examined in follow-up proceedings" (our translation).
What to do now
Order matters more than the model: measure first, then fix the levels, then grant rights, and only then let it send.
Five steps before the first automatic send
-
Count rejections by error type
For four weeks, record every incoming APERAK as an AHB, assignment, object property or takeover error, with the time until the resend. Without that distribution no level can be justified.
-
Put the level for each error type in writing
One sentence per error type in the process description, signed off by the head of market communication.
-
Cut write access narrowly
At the market communication gateway, the agent gets only the rights its highest approved level needs. Message types for termination, deregistration and cancellation stay technically blocked, not just by policy. It reads emails from market partners without taking instructions from them.
-
Log and kill switch before the first send
Decide who may lower the level and who may switch the agent off, and test both once. Check that the log can actually reconstruct a missed deadline.
-
Plan for 1 April 2027
Two weeks before and after the next format change, everything runs at level 1. Then widen the sample, measure the error rate after approval and only then move back up. Add the entry in the internal AI register and training for everyone who approves.
How we take agents from a prototype on a utility's own exception data into regular operation is described on our page AI for utilities.
Further reading
Frequently asked questions
An AI system that reads incoming EDIFACT messages and APERAK error messages, assigns them to an error type and a check identifier, and derives the next steps: drafting a correction, writing an exception email to the market partner, watching a deadline or sending a corrected message itself. The AHB check with its 45-minute APERAK is done by a rule-based checker instead.
In electricity, the recipient of a UTILMD or ORDERS message has to report the result of the processability check by APERAK no later than 45 minutes after receipt, or by Sunday 12:00 if it arrived on a Saturday. For all other message types the deadline is 12:00 on the next working day. This is set out in APERAK application handbook 1.1, binding since 1 October 2026.
No law or ruling forbids it. Responsibility stays with the market role that sends: under the APERAK handbook the sender is responsible for a plausible, correct and complete transmission file. We recommend tiering sending rights by error type and never sending terminations, deregistrations, cancellations or changes of assignment automatically.
Usually not. Annex III point 2 only covers AI systems used as safety components in operating critical infrastructure. The Commission's draft guidelines of May 2026, not yet final, expressly exclude systems that merely support or optimise. AI literacy under Article 4 and, where the agent communicates directly with people, the transparency duty under Article 50 still apply.
Under section 20a(4) EnWG the final customer can claim damages from the supplier or grid operator responsible for the delay. The supplier or grid operator bears the burden of proving it is not responsible. Using an agent does not change that. Whether liability arises in a specific case is a question for the legal department.
For each case: receipt with timestamp, message type, check identifier and error code, the agent's proposal, model and rule version, who approved it, when it was sent and what the market partner replied. The log is evidence for the burden of proof under section 20a(4) EnWG and training material after the next format change.
Let's collaborate
One contact, a team behind it
Thirty minutes on what you're working on, whether grid, metering, market processes, IT architecture or AI. Afterwards you'll know how we'd approach it and who would sit at the table.
Energy and measurement technology since 2010 · innobu GmbH since 2014 · Based in Schleswig-Holstein, Germany
Whoever pitches also delivers: whoever leads the first call stays your contact right through to the steering committee, with established partners in the project. Direct: info@innobu.com