When AI is the system

01 Everyone says AI

It has become easy to say that a product uses AI. That can mean almost anything. A chatbot in the corner. A search field that answers a little more cleverly than before. A button that summarises a report. All of this can be useful, but it says little about whether the system is actually built to understand the situation the user is in.

In fire safety, that difference is decisive.

A building is not a loose string of text.

It has history, use, drawings, technical installations, a fire safety concept, suppliers, roles, deviations and measures that must be seen together. When a user asks what applies, the best answer is not necessarily a neat explanation. It is often more important to know which document the answer is based on, who is responsible, what has been confirmed, what is missing, and what should be done next.

02 A layer on top, or built around understanding

This is where the distinction between an AI layer and an AI-native system becomes clear. An AI layer is placed on top of an existing product. It can read, write, explain and suggest. But if the rest of the system does not know what a deviation is, what a task is, which role the user has, or which professional basis governs, the AI quickly becomes a clever assistant without enough context.

An AI-native system starts somewhere else. It is built around information being understood, connected and used. The AI should not just answer. It should help FireHub understand the documentation, connect the information to the right context, find what is missing and suggest what should be followed up next, and show what must be confirmed by people or professionals. The OECD describes an AI system as a machine-based system that, from input, can generate for example recommendations, decisions or content that can influence digital or physical environments. It is a useful definition, but in the safety domain it is only the start of the question.

A general language model knows a lot about language, and it may well know the term fire safety concept. But it does not by itself know the specific building: which document governs, who is the owner and who is the user, and what the actual status is. FireHub is developing its own domain-specific AI for fire prevention and understanding roles.

03 A probable answer is not a fact

A document is documentation about reality.

It is not necessarily reality as it looks right now.

The documentationThe ground floor is drawn and described as commercial premises.

The building todayThe commercial premises have been converted and are used as flats.

The change of use has to be clarified

Clarification needed

The drawings show commercial premises on the ground floor. Today’s use is stated as flats. FireHub finds no documentation that clarifies whether the change of use is permitted.

Next step: Request the building case file and any permit for the change of use.

That someone has written that work was carried out is not necessarily the same as documented closure.

That information is missing does not necessarily mean the physical condition is missing.

And an AI finding a probable connection does not give it professional or legal authority.

That is why we use a simple principle:

Evidence before assertion.

Evidens før påstand.

Because when recommendations can influence how a building is followed up, the system needs more than good wording. It must distinguish between general advice and a concrete basis. It must know the difference between a routine that is documented, a routine that is merely assumed, and a routine that should have been followed up long ago. It must also make it clear when something is uncertain.

FireHub would rather show uncertainty than create false security.

What is unknown should stay unknown.

What needs clarifying should be visible as unresolved.

And when a professional assessment is needed, the technology should not pretend it can replace it.

04 FireHub does not approve buildings

That is why FireHub should not present itself as an AI that “approves” buildings. That would be the wrong direction. FireHub should instead be a system that makes the basis visible, organises the work and helps people make better decisions. The fire engineer's assessment, the fire safety concept, the documentation and the practical conditions in the building must keep their place. The AI should support this hierarchy, not pretend it does not exist.

FireHub suggests. People confirm.

What is suggested can be confirmed, corrected or rejected by the person responsible.

05 When the system doesn't know

It also changes the user experience. In traditional software, people have to learn where things are. In an AI-native system, they should be able to ask, explain, upload and confirm. The system should be able to say:

• This is what we have.Documented
• This is missing.Missing
• This is unclear.Unclear
• You should check this with a professional.Requires assessment
• This is the natural next step.Next step

For FireHub, AI is therefore not about making fire safety magical. It is about making it more traceable, more understandable and easier to follow up. In an industry where much of the responsibility lies with people who are not fire experts, that can be the difference between documentation merely existing, and documentation actually being used.