HORIZON-CL5-2027-02-D3-24: Operational AI for energy grids: control, trust and scale
Opening
3 December 2026
Deadline
Keywords
Grid AI
Operational validation
Federated learning
Edge computing
Digital energy spine
Frugal AI
Consumer empowerment
scalable models
Your microfluidic SME partner for Horizon Europe
We take care of microfluidic engineering, work on valorization and optimize the proposal with you
HORIZON-CL5-2027-02-D3-24: Large scale operational validation and upscaling of state-of-the-art (Generative) AI tools and models powering a next generation digital energy system
How should distributed grid AI resolve conflicting local decisions?
Distributed grid AI needs an explicit hierarchy of control permissions and electrical constraints. A battery, a building and a grid operator may pursue different objectives while sharing the same network capacity. Their proposed actions therefore need an agreed route for acceptance, correction or rejection. Hou and colleagues illustrate one technical safeguard: a safety layer that corrects reinforcement-learning actions for voltage regulation in simulated distribution networks. [1] HORIZON-CL5-2027-02-D3-24 brings this question of decision authority into operational validation, alongside the governance of a shared digital energy system.
Download the MIC Horizon Europe 2026/2027 Calls Calendar:
Discover more!
HORIZON-CL5-2027-02-D3-24 call facts and participation conditions
When is the opening and the deadline and what are the conditions to participate?
- Topic: HORIZON-CL5-2027-02-D3-24, within the Batteries and Energy call and the destination Sustainable, secure and competitive energy supply.
- Opening: 3 December 2026. Deadline: 31 March 2027, 17:00 Brussels local time. Single-stage; forthcoming.
- Action: Innovation Action (IA). Topic budget: €20 million, with around €10 million EU contribution per project and an indicative two projects. Different requested amounts remain possible.
- Maturity: activities are expected to reach technology readiness level (TRL) 7–8 by completion; activities may start at any TRL.
The General Annexes set the standard minimum of three independent beneficiary entities in three different countries: at least one in an EU Member State and at least two others in different Member States or Associated Countries. The maximum IA funding rate is 70%, with up to 100% for non-profit legal entities.
Topic-specific conditions matter. Entities established in an eligible country but directly or indirectly controlled by China or a legal entity established in China are ineligible under the stated control restriction. If satellite observation, positioning, navigation or related timing services are used, beneficiaries must use Copernicus and/or Galileo/EGNOS; additional services may also be used. The granting authority may object to ownership transfers or exclusive licensing of results for up to four years after the action. The Cluster 5 work programme and General Annexes provide the complete conditions.
From specialised AI to an operational digital energy system
The HORIZON-CL5-2027-02-D3-24 topic expects contributions to all four outcomes: secure and frugal AI for grid operations and consumer empowerment; an AI development environment integrated with the energy system’s digital spine; scaled edge and federated learning; and a governance framework with an operating model.
Proposals should validate specialised, open-source AI tools and models at demonstration sites and on operational grids. Functions include monitoring, balancing and forecasting, with market operations where relevant. Frugality includes energy, resources, data and cost. The digital spine is the shared digital infrastructure connecting these capabilities, including a digital twin and the functionality of the Common Reference Framework for energy-saving applications.
Learning should be demonstrated at edge nodes and federated across an agent-based architecture, including model downsizing, incremental learning and reinforcement learning. Different sites will not necessarily provide comparable data. Lu and colleagues examined this problem using household electricity records, evaluating federated domain separation in a virtual training environment. Their work supports testing client-specific performance; it does not establish operational grid readiness. [2]
Deliverables should follow Common European Energy Data Space principles and align with the Apply AI and Competitiveness Compass initiatives. Projects are expected to engage with European standards and open-source communities, use AI factories or gigafactories where relevant and possible, and participate actively in BRIDGE.
Build the demonstration around bounded control
A useful demonstration plan specifies what the AI may change, who authorises it and how control returns to an established fallback. The following are design recommendations for making the operational evidence interpretable.
- Define the service and baseline. Compare a proposed forecasting or control service with the operator’s existing method under matched demand, generation and network conditions. Record both benefit and constraint violations.
- Separate learning from permission to act. Specify allowed actions, timing limits and the conditions that trigger operator intervention. Test these boundaries before expanding autonomy.
- Exercise difficult conditions. Include missing measurements, delayed messages, changed topology and atypical demand. Replay and hardware-in-the-loop tests can prepare an operational trial, but the trial must still demonstrate the intended grid service.
- Measure the full computational service. Record inference and update energy, communication traffic, latency and equipment requirements. Evaluate model compression against the same task and acceptance criteria.
Retain model versions, input provenance, rejected actions and fallback events in the evidence record. A simulation study of a safety layer establishes behaviour under its model assumptions. [1] Operational deployment additionally needs the responsible operator to validate those assumptions and acceptance limits for the actual installation.
Connect operators, AI developers and consumer applications
Build the HORIZON-CL5-2027-02-D3-24 consortium around the operational interfaces needed to demonstrate the system. Grid operators provide network constraints, access arrangements and acceptance criteria. AI and edge-computing partners supply models, deployment software and update mechanisms. Cybersecurity and data-governance specialists address access controls and the trust relationships between participants.
Consumer-application developers, aggregators and relevant user representatives should help define how recommendations become usable actions. Include the consequences for comfort, service continuity and user control in the evaluation. The work programme does not prescribe an ideal consortium size or a fixed number of pilot sites for this topic.
For each interface, identify the data owner, technical maintainer and party authorised to change operating behaviour. Agree how model updates, incident handling and withdrawal of a participant affect the remaining system. These choices should feed the required governance framework and operating model.
Plan exploitation around a service that can be maintained after demonstration: reusable interfaces, clear software and model licences, support responsibilities and deployment costs. MIC’s consortium-partner approach covers project-specific technical contributions and relevant exploitation input; consortium leadership remains with the coordinator.
How should AI tools be validated in operational energy systems?
Validation should establish whether AI tools improve energy-system operations under realistic operating conditions. The topic covers open-source AI tools and models for grid monitoring, forecasting, balancing and consumer empowerment, with demonstrations involving operational electricity networks.
A useful evaluation would compare each tool with an established operational baseline. Depending on the application, relevant measures could include forecast accuracy, response time, computational demand and energy consumption. Testing across changing demand, renewable generation and data quality would help identify the conditions under which performance remains reliable.
The demonstrated AI development environment should integrate with the energy system’s shared digital infrastructure, including its digital twin and energy-saving consumer applications. Interoperability, data governance and secure operation should be assessed alongside model performance.
For learning at edge nodes and across federated systems, validation should examine communication requirements, resource use and coordination between distributed agents. The resulting evidence would support decisions about deployment, scaling and continued operation, with clear responsibilities for monitoring performance and managing model updates.
The MIC already brings its expertise in microfluidics to Horizon Europe:
H2020-NMBP-TR-IND-2020
Microfluidic platform to study the interaction of cancer cells with lymphatic tissue
H2020-LC-GD-2020-3
Toxicology assessment of pharmaceutical products on a placenta-on-chip model
About the author
Céleste Chidiac, PhD
Scientific writer and digital marketing specialist
Céleste Chidiac holds a doctorate in neuroscience and molecular biology from the University of Strasbourg. Since joining the Microfluidics Innovation Center in 2023, she has combined scientific writing with website management. For MIC’s Horizon Europe topic pages, she draws on her research background to explain scientific challenges and clarify funding priorities. Her writing helps prospective applicants understand each topic’s scope, expected outcomes and research directions.
FAQ — Reliable AI decisions across distributed energy systems
These questions explore model behaviour, data sharing and instrumentation choices that become important when AI moves between sites and into operation.
Are generative AI and reinforcement learning interchangeable?
No. Generative AI produces outputs such as text or synthetic scenarios; reinforcement learning learns a decision policy through rewards and interaction. A proposal should assign each method a concrete function. An assistant that explains an operating procedure and a controller that changes an asset’s setpoint need different evaluation criteria and permissions.
Why can a good average forecast hide problems at individual sites?
Errors are distributed unevenly. In Lu and colleagues’ household forecasting experiments, a comparator outperformed the proposed method for some households even though its average error was higher. [2] Report performance by site and operating condition, alongside the aggregate score, so improvements do not conceal a poorly served client.
Does keeping raw data local demonstrate that federated learning is private?
No. Local storage describes where raw records remain; it is not a complete privacy assessment. Define what model updates, identifiers and logs are exchanged, who can inspect them and which attacks are tested. Access control, retention and protection of the update channel should be evaluated explicitly.
How should a newly connected edge node enter the learning system?
Start with a defined admission procedure. Check data format, clock alignment, device identity and local operating limits before accepting updates. Evaluate the initial model on the node’s own data and specify how the system behaves while local evidence is limited. Participation in shared learning should not automatically grant authority to control equipment.
What should happen when communication between agents fails?
The affected asset should follow a predefined local operating policy appropriate to its function and network constraints. Specify how long information remains valid, which actions are suspended and how reconnection is handled. Test delayed, duplicated and missing messages; successful inference alone does not demonstrate correct coordination.
How can a smaller model be tested for real computational savings?
Compare the deployed services on the same hardware and workload. Measure energy per completed task, memory, latency, update frequency and communication overhead, while checking prediction or control quality. A smaller parameter count is useful engineering information, but the energy claim should come from the complete measured workload.
How should incremental model updates be accepted?
Treat an update as a new controlled release. Evaluate it on recent data and retained critical scenarios, compare it with the deployed version, and record the approval decision. Define rollback triggers and preserve a usable previous version. Improvements in one season or site should not erase previously verified behaviour elsewhere.
How can a sensor fault be distinguished from a change in model behaviour?
Check the measurement chain before attributing every anomaly to the AI model. In liquid-flow instrumentation, MIC’s inline flow sensor provides internal clogging and drift alerts alongside flow readings. For a relevant subsystem, those flags could support diagnosis. Electrical measurements require their own sensors, reference checks and grid-specific fault tests.
References
[1] Hou, S., Fu, A., Salazar Duque, E. M., Palensky, P., Chen, Q. and Vergara, P. P. DistFlow Safe Reinforcement Learning Algorithm for Voltage Magnitude Regulation in Distribution Networks. Journal of Modern Power Systems and Clean Energy. 2025;13(1):300–311. https://doi.org/10.35833/MPCE.2024.000253
[2] Lu, N., Liu, S., Wen, Q., Chen, Q., Sun, L. and Wang, Y. Federated Domain Separation for Distributed Forecasting of Non-IID Household Loads. IEEE Transactions on Smart Grid. 2024;15(4):4271–4283. https://doi.org/10.1109/TSG.2024.3367766