Sector · Industrial, Energy and Infrastructure

Agentic transformation in Industrial, Energy and Infrastructure

Long asset cycles, distributed teams, and decisions that are expensive to reverse.

hydrogen business case underpinned at Anglo American: £40bn
regions made predictable at Yondr: UK, USA, Singapore: 3
running the Data, Simulation and DevOps teams behind the programme: 18 months

Work delivered at

The short answer

Industrial, energy and infrastructure organisations face the inverse of the retail problem: decisions are consequential and expensive to reverse, assets have decade-long lifecycles, and teams are distributed across continents and time zones. The binding constraints here are safety cases and OT security rather than conduct regulation. That means management of change under a functional safety regime, and the boundary between corporate IT and the control domain that the NIS Regulations, NIS2 and IEC 62443 exist to protect. Agentic value concentrates in engineering knowledge work, simulation and planning, not in operational decisioning. Tenhaw built and ran the digital teams behind Anglo American's £40bn hydrogen business case and made global delivery predictable at Yondr across the UK, US and Singapore.

Regulation in industrial, energy and infrastructure

The constraints that decide the sequence

Not the ones that sound good in a deck. These determine which workflows can move to agents at all, and in what order.

Decisions are expensive and slow to reverse

A wrong call on a capital project is not undone in a sprint. The human-in-the-loop boundary sits much further toward human judgement than in consumer businesses, and agentic value has to be found in the analysis that informs decisions rather than in the decisions themselves.

Teams are genuinely distributed

Engineering and delivery teams spread across three continents mean asynchronous working is a necessity rather than a preference. Agentic workflows that assume a synchronous team in one time zone do not survive contact with the operating reality.

Specialist knowledge is scarce and concentrated

Deep domain expertise sits with a small number of highly qualified people whose time is the actual constraint on the business. Agents that amplify that scarce expertise are worth far more than agents that automate abundant work.

Safety and environmental accountability are absolute

Anything adjacent to operational safety carries a governance burden that back-office automation does not, because the safety case is the argument that permits the asset to operate. This is usually a reason to start elsewhere rather than a problem to solve first.

Data residency, model risk and auditability are questions about us as much as about your estate. Our security and assurance position says what we hold today and what we do not.

Sequencing

Where agents land first, and where they should not

Both halves matter. A supplier who only shows you the left-hand column is selling you the second year of the programme as though it were the first.

Start here

Where the value is real and the risk is contained.

1Engineering knowledge retrieval across decades of technical documentation
2Simulation and scenario modelling, amplifying scarce specialist time
3Capital project reporting and consolidation across distributed programmes
4Compliance evidence gathering, where the audit trail is the deliverable
5Asynchronous delivery coordination across time zones

How that starts, at a published price

Agent-Readiness AuditFixed price · £30k–£90k · 6–8 weeks Agentic Proof of ConceptFixed price · £20k–£55k · 2–4 weeks

Real constraints

The things that will bite, and worth pricing in before you sign.

Nothing safety-adjacent moves without a full governance case first
Technical documentation is often unstructured, on-premise, or both
Specialist scepticism is high and is usually well-founded: earn it with evidence
Read-only by default across the IT and OT boundary, and no write path into the control domain without your OT security function designing it
Capital cycles mean the business case is measured in years, not quarters

Regulatory

Safety cases, OT security, and the frameworks procurement now asks about

The gating questions here are whether the system's behaviour can be argued for in a safety case, and what identity it holds when it asks to cross the boundary into the control domain.

Safety cases, ALARP and management of change

Operators of major hazard, energy and infrastructure assets: COMAH sites, offshore installations under the Safety Case Regulations, nuclear under the ONR, and anything carrying a functional safety case under IEC 61508 or 61511. The general duty under the Health and Safety at Work Act sits under all of it.

What it requires of an agent: A safety case is an argument, supported by evidence, that risks are reduced so far as is reasonably practicable. It rests on the behaviour of the system being characterised, which is a demanding bar for anything whose output is not reproducible. Any change to a safety-related system triggers management of change and reassessment, and a supplier updating a model is a change whether or not anyone in your organisation initiated it.
Where programmes fall down: The boundary gets crossed by drift, not by decision. A tool arrives as decision support, becomes the thing operators actually rely on, and no management-of-change assessment was ever triggered because nothing in the control system changed. The second pattern is a safety argument written against a fixed model that is then updated on the supplier's release schedule rather than yours.
What our method does about it: We keep agents on the analysis side of the boundary by design, and we make the boundary explicit rather than assumed, so that crossing it has to be somebody's decision. Where a workflow informs a safety-relevant judgement we require the management-of-change gate before the pilot, with pinned model versions and change control your safety function owns. Usually this is a reason to start somewhere else entirely: there is more value in engineering knowledge retrieval than in anything adjacent to the safety case, and it is available years earlier.

Where our evidence stops: Tenhaw employs no safety engineers. We do not write, assess or sign safety cases, and we would treat any supplier who offered to as a warning sign. Our contribution is stopping a programme drifting across the line without noticing, and knowing when to stop and bring your safety function in.

Primary sourcesControl of Major Accident Hazards Regulations 2015 HSE, COMAH guidance for duty holders

OT security, NIS and NIS2

Operators of essential services under the UK NIS Regulations, assessed by competent authorities against the NCSC's Cyber Assessment Framework, and EU operations in scope of NIS2, which since October 2024 has widened the sectors covered, placed accountability on management bodies and added supply chain security and fast incident reporting. IEC 62443 is the standard your OT engineering colleagues will quote back at you.

What it requires of an agent: Manage the risk, protect against attack, detect events, minimise impact, and report significant incidents inside tight windows. In OT terms most of that rests on segmentation: the boundary between corporate IT and the control domain exists precisely to stop things reaching across it. An agent is a new actor asking to cross, and the questions are what identity it holds, what it can read, and whether it can write anything at all.
Where programmes fall down: A pilot pulls historian data to a cloud model endpoint by a route the security function never approved, because the pilot was scoped as analytics rather than as an integration. Or the agent runs on a shared service account with standing privileges wider than any human's, which leaves the framework outcome on privileged access unanswerable and makes the logs useless, because agent activity cannot be told apart from human activity after the fact.
What our method does about it: We ask what identity an agent holds and what it can reach before we ask what it can do. Read-only by default, no write path into the control domain unless your OT security function designs it, dedicated non-human identities with a tested revocation path rather than shared accounts, and pilots run against mocked services or synthetic data so the hardest approval is not needed during the fastest-moving phase of the work.

Where our evidence stops: We do not perform OT penetration testing and we do not certify anything to IEC 62443. We design so your security function can approve, and we expect specialists to do specialist work. What Tenhaw holds as a supplier is published on the security page.

Primary sourcesThe Network and Information Systems Regulations 2018 NCSC, Cyber Assessment Framework European Commission, NIS2 Directive IEC 62443-4-2:2019, technical security requirements for IACS components

Assurance frameworks: ISO/IEC 42001 and the NIST AI RMF

Global industrial groups, particularly those with US operations or US customers, and anyone whose procurement function has started asking suppliers how they govern AI.

What it requires of an agent: Neither is law. ISO/IEC 42001 is a certifiable management system for AI. The NIST AI Risk Management Framework is a voluntary structure organised around four functions, govern, map, measure and manage, with a generative AI profile alongside it. Their value is a shared vocabulary and a defensible record when a customer, an insurer or a board asks how AI risk is managed. The EU AI Act is where voluntary turns into obligation for anyone placing systems on the EU market. Its prohibitions have applied since 2 February 2025 and its general-purpose model rules since 2 August 2025, while the high-risk obligations were deferred by the 2026 AI omnibus to 2 December 2027 for stand-alone systems and 2 August 2028 where the AI sits inside a regulated product.
Where programmes fall down: The framework gets adopted as a document. A policy exists, a register exists, and neither is connected to what engineering actually does, so the gap between the stated control and the running system widens quietly until an audit finds it. Frameworks fail as paperwork and work as controls.
What our method does about it: We map what gets built to the functions rather than the other way round: an AI inventory generated from the systems themselves, evaluation results kept as records with the runs that produced them, and ownership recorded where the work happens. If you are heading for ISO/IEC 42001 certification, doing this during the build costs a fraction of doing it as a remediation programme afterwards.

Where our evidence stops: Tenhaw is not certified to ISO/IEC 42001. It is under assessment, and the security page says exactly where we are with it and with everything else. We are not a certification body or an auditor, and where you need a certified auditor, you need a certified auditor.

Primary sourcesNIST AI Risk Management Framework European Commission, AI Act regulatory framework and application dates

Tenhaw builds agentic systems and the operating models around them, and works alongside the risk, compliance, legal and actuarial functions who own the interpretation of these regimes. Our security and assurance position states what we hold today and what is still in progress.

Evidence

What we have done here

Named clients where we have permission to name them, and the evidence basis stated on every one.

18 months

£40bn

business case underpinned

Standing up the delivery engine behind a £40bn hydrogen business case

Read the case study

6 months

regions: UK, USA, Singapore

Turning erratic global delivery into something the business could plan around

Read the case study

Industrial, Energy and Infrastructure: your questions

Where do industrial businesses get value from AI agents?

In engineering knowledge work rather than operational decisioning: retrieval across decades of technical documentation, simulation and scenario modelling that amplifies scarce specialist time, capital project reporting across distributed programmes, and compliance evidence gathering. Operational decisions in industrial settings are usually too consequential and too hard to reverse for early agentic autonomy.

Can an AI agent be part of a safety case?

Not comfortably, and it is the wrong place to start. A safety case argues, with evidence, that risks are reduced so far as is reasonably practicable, and that argument depends on the behaviour of the system being characterised. A system whose output is not reproducible is difficult to argue for, and a model your supplier updates on their release schedule breaks the argument silently. The realistic pattern is to keep agents on the analysis side of the boundary, make the boundary explicit so that crossing it is somebody's decision rather than a drift, require a management-of-change gate before a pilot touches anything safety-relevant, and pin model versions under change control your safety function owns. Tenhaw employs no safety engineers and does not write or assess safety cases.

Does NIS2 apply to AI systems in industrial operations?

NIS2 does not regulate AI as such. It regulates the security and resilience of the entities in scope, and since October 2024 it has covered more sectors, put accountability on management bodies and added supply chain security and fast incident reporting. An agent inside an operator's estate is in scope the way any other system is, and in OT the specific question is segmentation: the boundary between corporate IT and the control domain exists to stop things reaching across it, and an agent is a new actor asking to cross. UK operators of essential services face the same questions through the NIS Regulations and the NCSC's Cyber Assessment Framework, with IEC 62443 as the engineering standard underneath. Design answers first: what identity does the agent hold, what can it read, and can it write anything at all.

What do ISO/IEC 42001 and the NIST AI RMF actually require?

ISO/IEC 42001 is a certifiable management system for AI: policy, roles, risk assessment, controls and evidence that they operate. The NIST AI Risk Management Framework is voluntary and organised around four functions, govern, map, measure and manage, with a generative AI profile alongside it. Neither is law, and both are increasingly what procurement and insurers ask about. The failure mode is adopting either as a document rather than as controls, so the register and the running system drift apart. Building the inventory, the evaluation records and the ownership trail during delivery costs a fraction of reconstructing them in a remediation programme. Tenhaw is not certified to ISO/IEC 42001. It is under assessment, and the security page says where that stands.

How do you run agentic transformation across distributed engineering teams?

By designing for asynchronous operation from the start. Tenhaw ran exactly this at Anglo American across the UK, Australia and the USA, building an agile blueprint lightweight enough that specialists onboarded fast, throughput data feeding simulation, and outcome-based milestones rather than project plans, so progress remained legible without synchronous coordination.

Has Tenhaw worked in heavy industry?

Yes. Tenhaw set up and ran the Data, Simulation and DevOps teams behind Anglo American's hydrogen-powered mining programme, work that underpinned a £40bn business case and spun out as First Mode. Tenhaw also made global delivery predictable at Yondr across data centre operations in the UK, US and Singapore.

The constraints differ more than the technology does

Thirty minutes on Industrial, Energy and Infrastructure, with James Rooney

We'll be specific about what applies in your sector and what does not, and you'll leave with a rough scope whether you engage us or not.

30 minutesWith James personallyNo obligation

See the proof first

Most organisations start with a fixed-price Agent-Readiness Audit · £30k–£90k · 6–8 weeks