Why energy companies need a different AI partner than other sectors
The challenges in energy are specific. Grid operators work with historian systems such as OSIsoft PI, with SCADA connections, and with OT networks that are separate from the IT layer. Energy traders calculate imbalance positions and forecast curves in real time. Installation companies schedule outage engineers based on data spread across multiple systems. A generic AI implementor accustomed to CRM automation or marketing AI will quickly get stuck here. Not because the technology is lacking, but because the domain knowledge needed to make the right assumptions is absent. Netbeheer Nederland has eight members and hundreds of regional customers, with investment obligations through 2040 that will only increase in the years ahead. This means the pressure to deploy AI effectively is growing, while the complexity of the underlying systems remains high.
Type 1: large systems integrators
Large SIs, such as the well-known consultancies and systems integrators, have broad AI capabilities and understand the energy sector at a high level. They typically work with existing platforms, build integrations, and provide project teams that can scale quickly. The advantage is coverage: they can support both the IT side and the OT side, and they have references at comparable organizations. The disadvantage is that domain expertise at the detail level often sits with the subcontractor, not the core team. Projects run long, cost a great deal, and the delivered code or configuration is rarely owned by the client. For large, multi-year transformation programs at national grid operators, this may be the right choice. For a mid-sized regional network company or an installation company, the overhead is generally too heavy.
Type 2: domain SaaS vendors for energy
There are SaaS vendors that build specifically for the energy market: platforms for forecasting, outage management, and capacity planning. They know the sector, speak the language, and have data integrations partly ready out of the box. The advantage is speed: you implement a proven product, not custom software. The disadvantage is that the standard is the standard. As soon as your process deviates from what the platform supports, you are locked in. Lock-in is real: your data sits in the platform, the product roadmap is set by the vendor, and cancelling costs more than the annual licence. For commodity processes, such as a standard outage notification system or a simple forecasting module, SaaS is a solid choice. For processes that represent a competitive advantage or that deviate significantly from the market standard, caution is warranted.
Type 3: custom builders and AI worker specialists
The third category builds to specification: either a completely new core system that replaces existing software, or AI workers that run on top of existing systems and take over specific tasks. This type of partner is suitable when the challenge is domain-specific and no standard package fits. Think of an energy trader who wants to consolidate and enrich imbalance position data from multiple sources, or a grid operator who wants to convert historian data into actionable outage forecasts without building a multi-year data platform. The advantage is ownership: the client receives the code, the data, and the system. No lock-in, no licence that increases every year. The disadvantage is that quality depends heavily on the domain knowledge of the builder. A custom builder without experience in OT integrations or energy balance logic will make the same mistakes as a generic AI implementor.
When do you choose which type of AI implementation partner for your energy company?
Use this checklist to determine which type of partner fits. Choose a large SI if: the programme spans multiple years, the scope is organisation-wide, and you need a consistent counterpart at board level. Choose a domain SaaS vendor if: the process is a commodity, the market standard is sufficient for your situation, and you want to start quickly without build risk. Choose a custom builder if: the process is specific to your organisation, you want to own the code and data, the existing system is not being replaced but enriched, or you want a working AI worker in weeks rather than months. With every party, ask three questions: Who owns the code when the project is complete? Does the partner have demonstrable experience with historian data, OT integrations, or energy balance logic? And who manages the system if the vendor no longer exists or shifts priorities three years from now?
What Bonsai does for energy companies and grid operators
Bonsai is a Software Operating Partner, not a consultancy. We build domain-specific AI software that runs in operations: either a completely new core system via the Bonsai AI Digital Twin, or AI Workers that run on top of existing systems and automate specific tasks. We build until it runs in production. The client owns the code, the data, and the system. For energy companies, that means: we take OT/IT integration seriously, we understand the limitations of historian data, and we build working systems, not reports. We work with milestones and go/no-go moments, so you are never locked into a multi-year trajectory without results.