Start with the uncomfortable part
Fire engineering is a life-safety discipline in which the failure mode is people dying and the regulatory direction of travel is towards more personal accountability, not less. Any claim about AI in this field has to be assessed against that, so it is worth being blunt about the limitation first.
A general-purpose language model asked a fire engineering question will produce a fluent answer. It will cite clause numbers. Some of those clause numbers will be wrong, some will be from a superseded edition, and the answer will read identically in both cases. That is not a bug that better prompting fixes; it is what the technology does when it is used ungrounded.
In a discipline where an uncited number in a strategy is a defect, an incorrectly cited number is worse than no answer at all, because it survives review by looking right.
Where it genuinely works
The useful applications share a property: the AI is doing retrieval, structuring or comparison against a source that exists, and a competent person can verify the output quickly.
1. Retrieval with citation
Finding the provision that governs a specific situation, across documents that run to hundreds of pages each, in seconds rather than twenty minutes. This is the highest-value, lowest-risk application, provided every answer carries the clause and edition so it can be checked in one click.
2. Drafting to a structure
A fire strategy has a shape. Much of the text between the judgements is standard: describing the building, setting out the design basis, recording assumptions, presenting derivations. Drafting that from a model and a brief removes hours of typing without removing any decision.
3. Consistency checking
This is where machines are simply better than people. A strategy states an occupancy in section 4 and sizes a stair in section 7 on a different number. A drawing shows a 60-minute compartment wall where the schedule says 90. A departure appears in the drawings and not in the schedule. Humans miss these because they read documents linearly and the two facts are ninety pages apart. Software does not.
4. Completeness checking against a known list
Does the package address every one of B1 to B5? Are all four process documents present for Gateway 2? Is every departure justified? These are checklist operations against a defined list, and the reason they matter is that administrative incompleteness, not engineering error, is the most common Gateway 2 failure.
5. Reviewing incoming work
Checking someone else's strategy is slow and unbillable, and gets compressed. A first-pass machine review that lists the gaps, and lets the engineer spend their time on the ones that matter, changes the economics of doing it properly.
Where it must not be used
| Task | Why not |
|---|---|
| Deciding whether a departure is acceptable | This is a judgement about acceptable risk in a specific building for specific occupants. It is the essence of what a competent person is for, and it is not delegable to software. |
| Ungrounded numerical answers | A language model does not calculate; it predicts text. Numbers must come from an implemented, tested method with the working shown, not from the model's memory of what such numbers look like. |
| Anything relying on a document it has not been given | Standards are copyrighted and are revised. A model's recollection of BS 9999 is a recollection of a mixture of editions. Ground it in the document you are actually designing to, or do not ask. |
| Signing anything | Obvious, but worth stating. The competence regime attaches to a person. No output from any tool changes who is accountable. |
| Site-specific risk that is not in the documents | The client's real operational intent, the neighbouring building's condition, the contractor's actual quality of fire stopping. None of it is in the file. |
The distinction that matters: grounded versus generative
If you take one thing from this page, take this. There are two fundamentally different ways to build an AI tool for a regulated technical discipline.
- Generative. Ask the model, take its answer. Fast to build, impressive in a demo, and unusable for anything you have to sign, because the failure mode is a confident wrong answer that is indistinguishable from a right one.
- Grounded. Retrieve the relevant provisions from an actual corpus, constrain the model to answer from what was retrieved, cite the clause and edition on every statement, compute numbers with implemented methods rather than with the model, and make an uncited claim an error rather than a stylistic choice.
The second is slower to build and less impressive to demonstrate. It is the only one that belongs anywhere near a fire strategy.
How to evaluate any tool in this space, in one question. Ask it something the guidance genuinely does not answer. A grounded tool says the guidance is silent and explains what would be needed to resolve it. A generative one invents a clause number. That single test tells you more than any feature list.
Competence, liability and the regulatory position
Nothing about the Building Safety Act regime contemplates a machine as a dutyholder. Competence declarations name people. Mandatory occurrence reports are made by organisations. A safety case report is signed by an accountable person.
The practical implication is that AI use in fire engineering has to be structured so that a competent person can verify the output, which in turn means the output has to be verifiable: cited, derived, and traceable. A tool that produces good answers you cannot check is professionally useless even when the answers are right, because you cannot demonstrate that you checked.
It also means AI use belongs in the golden thread. If a tool contributed to a design decision, the version of the tool, the date, and the editions relied upon are part of the record.
Where this is actually going
The interesting near-term change is not automated design. It is that reviewing becomes cheap. When a competent second opinion on a 200-page strategy costs an hour instead of two days, it starts happening on every project rather than on the ones with a budget for it. Given that the most common failures in this field are inconsistency and incompleteness rather than incorrect engineering, that is where the safety gain is.
That is the case for AI in fire engineering, and it is a narrower and more defensible case than the one usually made.
Last reviewed 25 July 2026 against the editions named above. Standards are revised; check the current published edition before relying on anything here in a design.