Can the grid model go to sales? Meter data, AI and unbundling in the multi-utility

The question in the multi-utility

On 21 September 2026 the Bundesnetzagentur published new rollout figures: 3,172,579 smart metering systems out of just over 54 million reported metering points, as of the end of June. That's 5.9 percent. Low against the target. But enough that in many grid areas quarter-hour values from households with heat pumps, wallboxes and batteries are arriving for the first time.

Whoever has these values builds models. Grid operations needs them for load and feed-in forecasts and for controlling devices under §14a EnWG, as we described for AI in grid state determination. Sales needs them too, for something else: a HEMS offer, a dynamic tariff, marketing flexibility. Since April 2026 platform vendors have been offering German municipal utilities ready-made white-label solutions for exactly that, and on 1 October 2026 the MiSpeL ruling takes effect, which resets the rules for storage running on a mix of grid power and subsidised solar power.

In a multi-utility (a German "Querverbund", where grid and retail sit under one roof) both projects often run on the same data platform, looked after by the same IT team. So the obvious question comes up: why train twice if the grid model already exists?

Short answer: because two different laws have a say. The MsbG asks what meter data is processed for. The EnWG asks who inside the company may see which information. You can satisfy the first and still fail the second.

What § 66 MsbG allows the grid operator

Forecasting models at the distribution system operator are explicitly covered by the law. § 66(1) MsbG allows the grid operator to process meter readings "exclusively" to the extent this is "strictly necessary" for one of nine purposes (our translation). Two words worth reading twice.

Three of the nine matter most for models. No. 3 covers safe operation, optimised planning and, by name, load and feed-in forecasts. No. 4 covers measures under §§ 13a and 14a EnWG, "in particular through dynamic control based on actual and forecast grid utilisation". No. 6 allows forecasts for the grid operator's difference and grid-loss balancing groups and better standard load profiles. There's no sales purpose on the list. There couldn't be; the provision governs the grid operator.

The deadlines sit in paragraph 3. Personal meter readings have to be deleted or anonymised as soon as the grid operator no longer needs them. At the latest, that is one year after the end of the calendar year of collection for Nos. 3 and 5 and three years for everything else, unless a Bundesnetzagentur ruling says otherwise.

For a forecasting model this means: if you want to train on several years of household time series, you need an anonymisation concept before the first training run. Afterwards it gets expensive.

§ 52(3) MsbG helps with the craft. It requires pseudonymisation wherever the purpose allows it and makes it mandatory when load and meter-reading profiles are sent to the distribution system operator for Nos. 3 and 4. As a route to anonymisation it names the aggregation of data from at least five connection users.

§ 70 MsbG: beyond that, only anonymous or with consent

§ 70 MsbG is a single sentence. Processing meter data or exchanging it beyond §§ 66 to 69 is "only permitted to the extent that no personal data is processed", without prejudice to consent under Article 6(1)(a) GDPR (our translation).

For handing grid data to sales, that leaves exactly two doors. Either the data no longer relates to a person, or the customer has consented. Both doors are narrower than they look.

Anonymity is hard to reach with quarter-hour values from a detached house with a heat pump. A load profile gives away presence, daily rhythm, appliances. An aggregate over five connection users in one street carries much less, and that is exactly what makes it less useful for sales. Consent, on the other hand, would have to be collected by the grid operator from customers its own sales unit may not even supply. More on that shortly, because this is where the Energy Industry Act comes in.

§ 6a EnWG: the second wall

Anonymous isn't unbundled. § 6a(1) EnWG obliges vertically integrated undertakings and grid operators to keep commercially sensitive information confidential that they obtain as grid operator. Paragraph 2, second sentence, spells it out for the multi-utility: towards other parts of the undertaking.

For data projects the rule is sharper than many utilities treat it day to day.

The de minimis threshold of 100,000 connected customers exempts only from legal and operational unbundling under § 7(2) and § 7a(7) EnWG. The Bundesnetzagentur's unbundling FAQ of November 2025 state that de minimis companies are "likewise fully" subject to informational unbundling (our translation). Even a grid department without its own legal entity counts as a grid operator there.

Tapping the smart meter data at the default metering operator instead of at the grid doesn't get you around the wall. According to the regulators' joint interpretation principles from 2018, informational unbundling covers the entire grid business including the default metering point operator, for conventional meters and smart metering systems alike.

The notion of information reaches furthest. The FAQ mainly mean grid customer information, plus "conclusions drawn from data of grid customers" and information "that results from looking at all customer information together" (our translation). A company also obtains information when it "generates it itself". Among the areas with particular potential for discrimination, the FAQ list grid connections, grid use and capacity forecasts.

There are exceptions: information obviously without economic relevance, the grid customer's consent to non-discriminatory disclosure, and a legal duty to disclose. The catch is the word non-discriminatory. Whatever your own sales unit gets, third-party suppliers have to get on equal terms, with the same scope, content and timing.

A grid model used exclusively by your own sales team is the opposite of what the provision wants.

Is a trained model information?

This is where the safe ground ends. The data is regulated. The forecasts a model produces are too, more or less, because a load forecast per local grid is grid information. But the model itself, meaning architecture, training code and the learned weights? As far as our research goes, there is no ruling, no court decision and no statement from a regulator on it.

Two readings face each other, and both can point to texts that already exist.

The broad reading rests on that sentence. The regulators wrote it about top management, which may not pass grid information on to sales. A model that has learned from a grid area's load profiles when which street draws how much is then simply processed grid information in a very dense form. The conclusions travel with the weights. Whoever holds the model can query them at any time.

The tool reading rests on two other passages. The legislator explicitly permitted anonymous processing in § 70 MsbG. And the same FAQ call a shared IT infrastructure for sales and grid "fundamentally unobjectionable" (our translation) as long as the data is logically separated. An algorithm trained on anonymous aggregates that no longer contains customer values would, on this reading, be a tool rather than information. Architecture and code even more so.

Data protection law already knows the same question and hasn't answered it across the board. The EDPB asks for a case-by-case assessment: a model only counts as anonymous if personal data can neither be extracted from it directly nor obtained through queries, in each case with no more than insignificant likelihood. That's a GDPR statement, not one about § 6a. It does show how the tool reading would be tested, though. Not with a label, but with evidence.

We won't settle this dispute. We can't, and it isn't our role. What interests us is a practical consequence: while the question is open, every utility that uses a grid model in sales carries the risk of the broad reading. That should be a conscious decision by management, talked through with the compliance officer for non-discrimination beforehand. Not one a data science team makes on the side when moving a notebook.

What sales may do on its own

Sales doesn't need the grid model. It has its own route to meter data, and that route is legally cleaner.

§ 50(1) MsbG permits processing data from smart metering systems if the connection user has consented or it is needed to perform a contract with them. Paragraph 2 lists purposes that fit the sales plan closely: marketing energy and flexibility (No. 8), implementing variable tariffs under § 41a EnWG including price and tariff signals for appliances and storage (No. 10), and value-added services at the connection user's request (No. 13).

The supplier as such is kept on a short lead by § 69 MsbG: billing, switching supplier or tariff, forecasting energy volumes. A HEMS with flexibility marketing goes further. So it needs a contract with the customer, consent, or both, and the data arrives through the channels every supplier has: from the metering operator on request and from the device at the customer's home.

That means two models. One in grid operations, trained on grid data for grid purposes. One in sales, trained on data from its own customers who agreed. The sales model's customer base is smaller and differently distributed. It isn't quite double the cost, though, because methods and tooling can be shared. The data can't.

Whether sales wants to afford that is a business question. The German trade paper ZfK wrote in May 2026 that a HEMS doesn't pay on its own, only together with a dynamic tariff, procurement optimisation, direct marketing and flexibility revenue. The numbers and the question of who owns the customer interface are covered in our piece on HEMS and virtual power plants at municipal utilities.

Shared services, IT providers and access rights

In practice, unbundling isn't decided in the statute. It's decided in the permission concept. The Bundesnetzagentur doesn't demand separate data centres. Its FAQ call a shared IT infrastructure permissible if the data is logically separated and access rules prevent cross-divisional viewing. Physical separation, they add, does bring legal certainty.

Data platforms make exactly that hard. A shared data lake, a shared feature store, a shared model registry: each is a place where grid data and sales data sit side by side, and the team running the platform sees both. For shared services the FAQ call for unambiguous contractual agreements, special access rights to electronically processed data and work instructions. The same goes for external IT providers, who in the regulators' view take on the duties themselves once they come into contact with sensitive information.

One set-up the FAQ call inadmissible outright: grid and competitive units jointly commissioning the same service provider for a customer service. If you plan to bring in one external vendor under a joint contract for both grid forecasting and a sales HEMS, have that checked first.

At a multi-utility in northern Germany we have been supporting the grid portfolio of around 40 initiatives since 2024. From there, unbundling is rarely the obstacle projects treat it as. The obstacle is that nobody knows which copy of a dataset sits where. A model registry in which every model has an owner, a § 66 purpose and a data source solves more than any debate on principles.

The EU AI Act on the side

The AI Act is a side issue for this question. Worth placing anyway. The European Commission's draft guidelines on classifying high-risk AI of 19 May 2026 list, among the examples outside the high-risk case, a system that forecasts energy demand to optimise the grid where the safety functions run separately, and an imbalance forecast supervised by a human.

Good news for forecasting models with human oversight. But the draft isn't final, and it deals with product safety, not data flows. A model can be uncritical under the AI Act and still not be allowed into sales. Which AI at a utility counts as high-risk under the draft is covered in our article on AI Act Annex III after the draft guidelines.

Where it can go wrong

What about the deletion deadlines? They don't get along with training data. A forecasting model improves with every winter it has seen. § 66(3) MsbG, however, lets personal values for forecasts under No. 3 stay for no longer than one year after the end of the collection year. Aggregate or anonymise too late and you either lose history or pick up a problem.

Models multiply. A data scientist copies a trained model into another environment for a test, a provider keeps a snapshot, a slide deck shows a forecast per street. Each of those copies is a possible disclosure, and hardly any of them lands in a registry.

It's also unclear how many customers will actually consent. A sales model that only learns from consenting HEMS customers sees a small, tech-savvy group. Whether that is enough for a usable forecast will only show in operation.

How grid operators use flexibility for the grid first and for the market second is described in our piece on grid-serving flexibility under §14c EnWG. The data flow there points the same way: out of the grid only what applies to everyone on equal terms.

What utilities should clarify now

Before a model moves to sales or a sales project asks for grid data, six things are worth settling. They are not the same size.

Six points before any data moves

1. Inventory data by purpose

   For every dataset from smart metering systems, record which number of § 66(1) MsbG it is collected for and when paragraph 3 requires deletion or anonymisation. Without this table, every further discussion is guesswork.

2. Anonymise before training

   Take aggregation over at least five connection users under § 52(3) MsbG as the floor and test whether it is enough for the model.

3. Keep a model registry with owners

   Every model gets an owner (grid or sales), a purpose, a data source and a list of the environments where it lives. Test copies count. If you already keep an AI inventory, attach the registry to it.

4. Cut access rights in the platform

   Separate data spaces for grid and sales on the same platform, access roles for the operations team, confidentiality clauses in shared-service and vendor contracts. And no joint commissioning of the same provider by grid and sales.

5. Build the consent model in sales

   Design the contract and consent for HEMS, dynamic tariff and flexibility marketing under § 50 MsbG so that sales gets its data on its own legal basis. That's the route that doesn't depend on the open legal question.

6. Document the open question as open

   If you want to use a grid model in sales, put the question to the compliance officer and legal counsel and let management decide. In writing.

Start with the inventory and the legal question usually shrinks. Many sales ideas don't need grid data at all, just clean customer data with consent. How to get master data in shape for that is covered in our piece on master data quality in market communication.

Further reading

Frequently asked questions