As artificial intelligence works its way into engineering practice, regulators around the world are beginning to ask how its use should be controlled. It is an understandable concern. Fire engineering is a safety-critical discipline, and the decisions made by fire engineers shape buildings, protect occupants, and ultimately affect public safety. Any technology with the potential to influence those decisions deserves scrutiny.

There is a risk, though, that the scrutiny lands on the wrong target. Much of the current debate is about whether AI should be permitted, restricted, declared, monitored, or banned, as if the central regulatory problem were the presence of AI itself. We think the real problem lies elsewhere. The question is not whether AI was used. The question is whether the resulting engineering can be trusted. It is the narrower, regulatory version of a question we have explored more broadly: how should fire engineering integrate AI at all?

The reality of modern engineering practice

Engineering has always relied on tools. Calculators replaced manual arithmetic, spreadsheets replaced hand calculations, specialist software replaced tasks that were once done by hand, and computational models now perform analyses that would have been unthinkable a few decades ago. Each time a new tool arrived, professionals and regulators reasonably asked how it was being used, what assumptions it carried, and whether its outputs could be trusted. In a safety-critical field that scrutiny is exactly right, and artificial intelligence should be examined through the same lens rather than a special one.

In practice, AI is rapidly disappearing into the tools engineers already use. It may help generate a calculation, write a script, review a document, analyse data, explore alternatives, flag an inconsistency, or sharpen the wording of a report. Before long, drawing a clean line between AI-assisted engineering and everything else will be close to impossible, and more to the point it will be beside the point. What matters is not whether AI contributed to the process. What matters is whether the resulting engineering is transparent, defensible, and able to show that the intended safety objectives have been met.

Regulating the tool is unlikely to work

Picture a regulatory framework that requires engineers to declare whether AI was used in developing a design. What would that actually capture? Does it count if AI improved the wording of a report? If it generated a Python script? If it summarised a piece of guidance, or reviewed a draft fire strategy, or sat embedded inside a commercial software package the engineer barely thinks of as AI? The boundary dissolves almost as soon as you try to draw it.

Any rule built on the mere use of AI is likely to produce confusion, inconsistency, and paperwork while doing very little for safety. The problem was never that AI exists. The problem is whether engineering decisions remain competent, transparent, and defensible, and that is true whether or not a machine was involved.

The competent professional remains the control measure

Fire engineering is ultimately a professional activity, and whatever tools are involved, a competent engineer must be able to explain why a particular approach was selected, what assumptions underpin the analysis, what limitations apply, how uncertainty has been handled, why the conclusions are reasonable, and how the proposed measures achieve the intended safety objectives.

None of these responsibilities can be delegated to software. They cannot be delegated to artificial intelligence, and they certainly cannot be delegated to a disclaimer buried in a licence agreement. The responsibility stays with the engineer. For regulators, that is the principle worth protecting above all others. A submission should not become more acceptable because it avoided AI, nor less acceptable because it used it. What matters is whether the engineer can defend it.

What regulators should actually look for

If regulators want to encourage responsible use of AI, a handful of long-standing expectations matter more than any declaration about tools.

Assumptions should be explicit. Every fire engineering assessment rests on them, and AI does nothing to change that; if anything it raises the stakes, because a generated output can carry assumptions the engineer never consciously made. Uncertainty should be visible, because AI outputs tend to sound confident even where the underlying engineering is not, and a defensible analysis acknowledges uncertainty, bounds it, and quantifies it where it can. Limitations should be stated, since no method applies everywhere: an evacuation calculation valid for a small assembly space may be meaningless for a complex phased evacuation, and knowing where a method stops being appropriate is as important as knowing where it works. Robustness should be demonstrated rather than assumed, with sensitivity testing and alternative scenarios showing that the conclusions hold when conditions change rather than balancing on a single fragile input.

Above all, regulators should judge the quality of the engineering argument rather than the technology used to assemble it.

Defensibility has to be built into the tools

If defensibility is what regulators should be looking for, then it cannot be something an engineer bolts on at the end, after the analysis is finished and the report is being written. It has to be present in the tools themselves, because a tool that hides its method gives the engineer nothing to defend. A calculator that returns only a number cannot show a reviewer how that number was reached, and a model that conceals its assumptions cannot help anyone demonstrate that they were appropriate.

This is the premise behind OpenFire. Its methods are open, so a reviewer can take a result apart instead of accepting it on trust: the working is on show, the governing assumptions are spelled out, the conditions under which the method holds are stated, and the effect of each input can be tested directly. That is exactly the material an engineer needs when a building control body, a peer reviewer, or an approving authority asks how a conclusion was reached. Traceability is designed in rather than reconstructed afterwards, and that is what makes the output defensible. You can work through the open methods yourself at the OpenFire method catalogue, which is open to browse without an account.

The future is likely to involve more AI, not less

The integration of AI into engineering workflows is going to accelerate, because the benefits are real: better productivity, fewer repetitive tasks, faster exploration of alternatives, earlier detection of errors, and clearer communication of technical work. Many of these developments stand to improve practice. The goal should not be to hold them back. It should be to ensure that adoption strengthens professional standards rather than eroding them, which calls for a framework built on transparency, accountability, competence, and defensible judgement. Reassuringly, those are not new demands. They are the same things good regulators have always looked for.

A better question

Perhaps the most useful question a regulator can ask is not “Was AI used?” but “Can the engineer explain and defend the solution?” If the assumptions are clear, the limitations understood, the uncertainty properly bounded, and the safety objectives demonstrably met, then the involvement of AI becomes largely beside the point.

The public is not protected by the absence of technology. It is protected by competent professionals applying technology responsibly, and that is where regulation should keep its attention.