AI in structural monitoring works well today in two roles: it detects statistical deviations from a channel's own measurement history and turns large data sets into clear commentary. It does not know structural capacity, it does not replace design thresholds or the engineer, and it does not take responsibility for the decision. Treat it as an assistant that points out where to look, not as an oracle.
In brief
- A statistical anomaly is a deviation from a channel's previous behaviour, not a safety assessment of the structure. Those two concepts must be separated in your mind and in your procedure.
- Z-score shows how many standard deviations a reading is away from the mean of the baseline window. It is simple and transparent, but it has known limits: seasonality, trend, autocorrelation.
- WARNING and ALARM thresholds come from the design and the engineer's assessment. AI can suggest whether thresholds are too tight or too loose, but it will not set them for you.
- Engineering reports (calibration debt, temperature compensation, 7/30-day risk, alarm tuning, data SLA) are deterministic statistics; a language model can at most describe and rank them - and that order is what separates a tool from an ornament.
- Evaluate an 'AI' vendor by asking what data it uses, how it explains the result, what it does with hallucinations, whether it can be turned off, and who is responsible for the decision.
For the last two years, almost every structural monitoring software offer has had the word "AI" somewhere in it. Some of that is a real feature, some is a new name for old statistics, and some is an unsupported promise. If you are specifying a system for an excavation or signing a bridge monitoring contract, your problem is concrete: you do not want to pay for an ornament nobody on the team will use, or reject something that would really save the engineer several hours a week. This text gives you criteria to settle that in one conversation with the vendor. If you need broader background, start with the complete guide to structural monitoring, then come back here for the analytics part.
Two things AI does well, and three it does not
Artificial intelligence in structural monitoring is a set of statistical methods and language models that automatically search measurement data, flag readings that deviate from the channel's previous behaviour, and describe them in natural language. That is the definition. The rest is a question of what this means in practice.
Does well: detects deviations from a channel's own history
Every measurement channel, whether column tilt, girder strain, or pore pressure in a piezometer, has its own history. Daily "breathing" from temperature, a weekly loading rhythm, slow drift. Statistics are good at answering the question: "Does what arrived today fit what this channel has done over the last 30 days?" People can answer it too, but not with 200 channels, every 15 minutes by default, or more often, all year. AI is not smarter than the engineer here. It is just tireless.
Does well: summarises and comments on large data sets
The second real benefit is language. A language model receives previously calculated statistics and writes a comment from them: which channels stand out, since when, by how much, and what to check first. For an engineer, it is a shortcut to the place where the assessment starts. For management, it is a paragraph that can be read without opening charts. We wrote separately about how to turn data into decision-maker language in the text on the monitoring report for management.
Does not: know structural capacity
A statistical model sees numbers, not the static scheme. It does not know that 2 mm of deflection on a 40 m span is nothing, while 2 mm of crack opening in the anchorage zone is a reason to pick up the phone. It does not know safety factors, concrete class, or that a heavy transport will enter the site next week. The designer knows all of that, and all of that is in the design thresholds.
Does not: replace design thresholds and the engineer
A warning threshold and an alarm threshold are engineering decisions, based on calculations, experience, and responsibility. AI can suggest a threshold correction because it sees that the current one generates ten alerts a week or has not triggered once in a year. It cannot set the threshold because it does not know the consequences of crossing it. More on where thresholds come from in the text on setting alarm thresholds.
Does not: take responsibility
Responsibility for technical inspections lies with the person holding the appropriate construction licence in the relevant specialty (Building Law, Article 62(4)), while the owner or manager is responsible for keeping the structure in proper condition and ensuring safe use (Article 61). No algorithm signs an inspection report, and none appears before building supervision. If a vendor suggests that "AI is watching the asset", ask who signs off on its conclusions.
| Task | Who does it well | AI role |
|---|---|---|
| Identify a channel that has behaved differently since yesterday than it did over the last month | Statistics (z-score, spike detection) | Primary - it does this automatically and without fatigue |
| Summarise a week of data from 150 channels in five paragraphs | Language model on calculated statistics | Primary - provided the numbers come from the platform, not from the model's "imagination" |
| Assess whether a deviation threatens the structure | Engineer with the design and thresholds | Supportive - provides context, does not assess |
| Set WARNING and ALARM thresholds | Designer / SHM engineer | Supportive - estimates how many events a given threshold will generate |
| Be responsible for the decision | Licensed professional, asset manager | None |
For you, the buying rule is simple: you pay for the first two rows of the table, and the last three stay with the team - and that is how it should be written in the offer.
A statistical anomaly is not a structural threat
A statistical anomaly is a reading or a series of readings that deviates from the previous distribution of values for a given channel by more than the accepted threshold allows as chance. A structural threat is a state in which the measured quantity approaches a value that is dangerous from the point of view of load-bearing capacity or serviceability. One can exist without the other. In both directions.
Three illustrative scenarios where z-score screams and the structure is fine:
A jump after calibration. The crew replaces the logger, enters new calibration coefficients, and the tilt reading jumps by 0.3 mrad in one quarter-hour. For statistics, this is a deviation of several dozen sigma. For the structure, nothing happened - the zero reference changed. If the platform does not record who changed the calibration and when, the anomaly looks like a failure. If there is a change log, the case is closed in a minute.
A heatwave. A vibrating wire sensor on a steel girder, the baseline window covered a cool May, and in June five days above 30 °C arrive. Strains move beyond everything the channel has "seen". That is not damage, it is the thermal expansion of steel - and that is exactly why vibrating wire sensors are measured together with temperature (more on this in the text about vibrating wire sensors). Without temperature compensation, the algorithm will generate anomalies with every change in weather.
A load change. In a warehouse hall, the tenant changes the racking layout and an additional permanent load appears on one slab bay. The strains in that bay move to a new, stable level. Statistically: an anomaly, because the distribution shifted. From an engineering point of view: check whether the new load remains within the design basis - but the change in level alone is not yet a threat.
And the opposite scenario, which is mentioned less often: a slow trend below the detection threshold. The column tilt increases by 0.01 mrad per day. Every reading stays within the distribution of the last 30 days, because the baseline window moves together with the trend. Z-score stays silent. After a year, that is 3.65 mrad - on a 10 m height, more than 36 mm of top displacement (illustrative numbers). Here, the absolute design threshold and the trend chart help, not deviation statistics.
| Situation (illustrative) | What z-score sees | What it means for the structure | Who closes the case |
|---|---|---|---|
| 0.3 mrad jump after calibration change | Anomaly, very high z | Nothing - the zero reference changed | Engineer, based on the change log |
| Strains in heat outside the baseline window | Anomaly on many channels at once | Thermal expansion | Temperature compensation + engineer |
| New permanent slab load level | Anomaly, then "new normal" | To be checked against the design | Engineer with the designer |
| 0.01 mrad/day drift for a year | No anomaly | Potentially important | Design threshold + trend chart |
The conclusion is simple: anomaly detection is an attention filter. It reduces the number of places you need to look at. It does not tell you what you will see there. If someone sells it to you as "threat detection", they have confused a filter with a judge.
Z-score in 200 words
Z-score is the number of standard deviations by which a given reading differs from the mean of a selected baseline window. Formula:
z = (x - μ) / σ
where x is the current reading, μ is the mean from the baseline window, and σ is the standard deviation from the same window. The baseline window is a slice of the channel history, for example the last 7, 30, or 90 days, from which μ and σ are calculated. A reading is considered an anomaly when |z| > k, where k is the adopted threshold, most often 2, 2.5, or 3.
Illustrative example. Let us assume a column tilt channel. 30-day window: μ = 1.20 mrad, σ = 0.05 mrad. Today a reading of x = 1.38 mrad arrives.
z = (1.38 - 1.20) / 0.05 = 3.6
With k = 3, that is an anomaly. Now change only the window: extend it to 90 days, which includes spring temperature swings, and σ rises to 0.12 mrad.
z = (1.38 - 1.20) / 0.12 = 1.5
The same reading, no anomaly. The choice of baseline window and threshold k changes the result more than the structure itself.
A robust variant replaces the mean with the median and σ with the median absolute deviation (MAD). A single spike then does not inflate the spread and does not mask subsequent deviations. The NIST/SEMATECH e-Handbook of Statistical Methods describes it as Modified Z-Score, alongside the Grubbs test for a single outlier.
Three limits to keep in mind:
- Seasonality. If the window does not cover a full cycle (day, season), σ is underestimated and every weather change becomes an anomaly. A window that is too long, in turn, blurs σ and lets real changes through.
- Trend. Z-score assumes stationarity: a constant mean. With slow drift, μ moves together with the data and the algorithm does not see the trend - it only sees jumps.
- Autocorrelation. Readings at the default 15-minute interval are not independent; adjacent values are strongly correlated. The effective number of independent samples is much smaller than 96 per day, and σ calculated "by hand" is often understated. In practice, that means more false anomalies than the threshold k would suggest.
Does this disqualify z-score? No. It disqualifies using z-score without awareness of these three things. Z-score has one feature that more complex models lack: every engineer can check the result on a calculator. That matters when you need to explain why the platform triggered.
Engineering reports: calibration debt, temperature compensation, 7/30-day risk, data SLA - where AI helps and where it only calculates
An engineering report in a monitoring platform is a set of analyses automatically calculated on project data, answering specific questions about the condition of the measurement installation and the behaviour of channels. Most of what offers call "AI" are precisely such reports - statistics calculated deterministically. A language model, if it takes part at all, describes and organises the finished numbers. That is good news: such a result can be checked.
Calibration debt is the deviation of the current channel value from the reference reading (zero), together with drift from the last 7 and 30 days, ranked from the channel that has "drifted" the most. Instead of the sentence "we need to visit the sensors one day", you get a list: which channels to check first and why. Drift can also explain strange anomalies - before suspecting the structure, make sure the sensor is not drifting. The decision to send a crew is made by the engineer, because that person knows the travel cost and the consequences of delay.
Temperature compensation is a comparison of the relationship between the channel value and temperature before and after compensation, calculated channel by channel on data from the selected window. This report removes most weather-related anomalies from the list: if the correlation with temperature disappears after compensation, the deviation was thermal; if something remains that temperature does not explain, that is where the engineer needs to look. Text commentary is useful here for one thing only: showing which channels the compensation works on and which it does not.
7/30-day risk is the channel trajectory over the weekly and monthly horizon, calculated with robust statistics (median and MAD instead of mean and σ, exponential smoothing, cumulative sums), which shows which channels are consistently moving away from their baseline level, rather than just jumping once. This is not a failure forecast. It is an answer to the question "where should I look this week", and that is all the AI comment should make of it. The engineer decides whether this is a reason to act or to observe.
Alarm tuning is a proposal for thresholds calculated from the channel history distribution (high percentiles) together with an estimate of how many events per week that threshold would generate. If a warning threshold wakes someone every second night for no reason, it will be ignored on the night when it matters. The proposal is statistical; a person approves it, because a threshold is a design decision.
Data SLA is the completeness of readings relative to the real channel cadence (the platform determines it from the intervals between samples): how many samples arrived, how many should have arrived, what gaps there were, and how long it has been since the last reading. It is the least "intelligent" and the most useful report. Without it, all the others are unreliable - a z-score calculated on a channel that has been silent for two weeks is worthless.
The common denominator: in each of these reports, the numbers come from the platform, and the comment only describes and organises them at most. If a vendor reverses that order - the model "evaluates" raw measurements and invents what is important on its own - that is not an engineering report, it is an essay.
Questions for an "AI" vendor
The list below was created with specification work and sales conversations in mind. You will find a broader platform selection checklist in the text on choosing a monitoring platform; here we focus on the "AI" part.
- What data does it calculate on? Raw readings, converted values, hourly aggregates? What is the baseline window, and can it be changed?
- What exactly is "AI", and what is statistics? Z-score, spike detection, and dead-channel detection are statistics. Text commentary is a language model. The vendor should be able to separate these in one sentence.
- How does it explain the result? Does each anomaly show the numbers (μ, σ, z, window), or only the label "anomaly"? A result that cannot be reproduced manually is not suitable for a report.
- What about hallucinations? A hallucination is a situation where the language model generates a statement not supported by the input data. The question is: does the model receive calculated statistics or raw measurements, and can each statement in the comment be pointed to in the data?
- What happens when the model is unavailable? Does the report appear in a version without commentary, or does the whole thing disappear?
- Who is responsible for the decision made on the basis of the AI comment? The answer should be: the engineer, and the platform is a tool. If the vendor suggests otherwise, ask for it in writing.
- Can it be turned off? If the team does not trust comments, it should be able to use the platform without them, with thresholds and alarms calculated deterministically.
- Do my data train someone else's models? Ask this of every vendor that uses a language model, and request a written answer: where the data are processed, whether they leave the platform vendor's infrastructure, who the model provider is, and what its policy says about training on customer data. Measurement data are usually not personal data, but alarm recipient contact details are, and their hosting requires a data processing agreement compliant with Article 28 of the GDPR.
- Can AI change a threshold or mute an alarm on its own? The correct answer: it can suggest, a human approves. Every change must be recorded in the change log with who and when.
- Is the AI comment part of the asset documentation? If so, who signs it and how is it versioned together with the configuration on which it was created?
A vendor who gives concrete answers to most of these questions treats AI as a tool. A vendor who answers "it is an advanced algorithm" treats AI as a slogan. These ten questions fit into one email; paste the answers into the specification, and then "AI" stops being a slogan and becomes a parameter that can be accepted.
What this looks like in Inclify
AI analysis in Inclify is an assistant, not an oracle. Per-channel statistics and anomaly detection are calculated by the platform database: z-score against the baseline window (up to 90 days), spike z-score, percentage change, and channels that have stopped changing. The language model receives only those calculated results - the project and device name, the scope, the number of channels in warning and critical status, and the list of anomalies with numbers - not the raw time series. On that basis, it writes a comment in Polish, a list of findings, and recommendations, with instructions to rely only on the input data. The vendor and language model are configured during deployment; without the model key, the analysis still appears, only in deterministic form, without commentary.
WARNING and ALARM thresholds, SMS and e-mail notifications, acknowledgement and time-limited muting of alarms operate independently of AI - this is the deterministic part of the platform. Engineering reports (calibration debt, temperature compensation, 7/30-day risk, alarm tuning, data SLA) are calculated from project data and are available next to the AI analysis; they do not need a language model to work. We do not promise failure prediction or "self-learning" asset guarding. We promise that the engineer will get to the place where the assessment starts faster. Details on the AI analysis in Inclify.
FAQ
Can AI replace alarm thresholds in structural monitoring?
No. WARNING and ALARM thresholds come from the design, calculations, and the engineer's responsibility - they are absolute values referenced to load-bearing capacity and serviceability. AI detects deviations relative to channel history, which is something else. It can suggest that thresholds are too tight or too loose, but it does not know the consequences of crossing them. Both mechanisms should work in parallel: thresholds as the hard boundary, anomalies as an attention filter.
What is z-score and how should it be interpreted in measurement data?
Z-score is the number of standard deviations by which a reading differs from the mean of the baseline window: z = (x - μ)/σ. A value of |z| above 2 to 3 is usually treated as an anomaly. Interpretation requires context: z-score does not know units, design thresholds, or the cause of the deviation. A high z after calibration changes or in heat does not mean a structural problem, and a low z during a slow trend does not mean safety.
Does an anomaly detected by AI mean a structural threat?
Not necessarily. A statistical anomaly means the channel behaves differently from the baseline window. The cause may be a calibration change, weather, a load change, sensor failure, or a real change in the structure. The engineer decides by combining the anomaly with temperature, the change log, design thresholds, and the trend chart. Treat an anomaly as a pointer to the place worth looking at first.
Where do false anomalies come from and how can they be reduced?
Most often from three sources: the baseline window does not cover a full seasonal cycle, readings are strongly autocorrelated (σ comes out understated), and there is no temperature compensation. What helps is matching the window to the channel behaviour, calculating anomalies on thermally compensated values, requiring the deviation to persist for several consecutive readings instead of reacting to a single point, and a data SLA report that excludes channels with gaps.
What about hallucinations in language models used in monitoring reports?
A hallucination is a statement generated by the model without support in the input data. The risk decreases when the model receives ready, calculated statistics instead of raw measurements, and every sentence in the comment has a data-backed reference. Ask the vendor about this architecture and what happens when the model is unavailable. Treat the AI comment as an assistant's note to be checked, not as a finding for the report.
Is AI analysis in structural monitoring a high-risk system under the AI Act?
The AI Act (EU Regulation 2024/1689, in force since 1 August 2024) classifies high-risk systems, among other things, according to Annex III. Monitoring the condition of buildings and engineering structures is not listed there - point 2 concerns safety components of critical digital infrastructure, road traffic, and water, gas, heat and energy supply. However, the classification must be assessed for the specific use case, and the application dates for high-risk provisions were pushed back in 2026.
Who is responsible for a decision made on the basis of an AI comment?
The person holding the appropriate construction licence who performs the technical inspection (Building Law, Article 62(4)), and the owner or manager who must keep the structure in proper condition and ensure its safe use (Article 61). Software is a tool, like a rangefinder or a spreadsheet. If a vendor suggests that AI "takes over" supervision, ask for that statement in writing. This text is not legal advice; consult a lawyer on responsibility matters.
Sources and further reading
- Building Law Act, Articles 61 and 62 (duties of the owner and manager, periodic inspections, and the persons authorised to carry them out) - isap.sejm.gov.pl.
- PN-EN 1997-1 Eurocode 7: Geotechnical design - observational method (the role of measurements and limit values in the design process) - sklep.pkn.pl.
- NIST/SEMATECH e-Handbook of Statistical Methods, section 1.3.5.17 "Detection of Outliers" (z-score, Modified Z-Score, Grubbs test) - https://www.itl.nist.gov/div898/handbook/eda/section3/eda35h.htm
- Regulation (EU) 2024/1689 of the European Parliament and of the Council on artificial intelligence (AI Act), Annex III - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2016/679 (GDPR), Article 28 - data processing agreement - https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Manufacturers' documentation for vibrating wire sensors on the influence of temperature on the reading and thermal correction coefficients - geokon.com.
- Related texts in the series: complete guide to structural monitoring, alarm thresholds, vibrating wire sensors, platform selection checklist, monitoring report for management, connecting existing loggers.
What next
The lowest entry threshold is a pilot on one asset, using data you already have, from your own sensors or from existing loggers (connection via HTTP/JSON usually takes a few days; we described how this works in the text on connecting existing loggers). You will see how z-score behaves on your channels, where temperature compensation removes false anomalies, and what the AI comment looks like next to the thresholds set by your engineer.
There is also a reason not to postpone this: statistics need a baseline window. Every week of data collected before the season you want to observe, in winter, before excavation, before an inspection, is a week in which the algorithm has something to calculate from instead of guessing. No promise that the algorithm will "watch over" the asset, only a promise that you will see faster what to look at.
Let us talk about an AI analysis pilot on your asset - we reply within 24 h.