AI w monitoringu konstrukcji działa dziś dobrze w dwóch rolach: wykrywa odchylenia statystyczne od własnej historii kanału pomiarowego i streszcza duże zbiory danych w czytelny komentarz. Nie zna nośności konstrukcji, nie zastępuje progów projektowych ani inżyniera i nie bierze odpowiedzialności za decyzję. Traktuj ją jak asystenta, który wskazuje, na co patrzeć, a nie jak wyrocznię.
W skrócie
- Anomalia statystyczna to odchylenie od dotychczasowego zachowania kanału, a nie ocena bezpieczeństwa konstrukcji. Te dwa pojęcia trzeba rozdzielać w głowie i w procedurze.
- Z-score mówi, o ile odchyleń standardowych odczyt odbiega od średniej z okna bazowego. Jest prosty i przejrzysty, ale ma znane ograniczenia: sezonowość, trend, autokorelację.
- Progi WARNING i ALARM wynikają z projektu i z oceny inżyniera. AI może podpowiedzieć, czy progi są za ciasne lub za luźne, ale nie ustali ich za Ciebie.
- Raporty inżynierskie (dług kalibracji, kompensacja temperatury, ryzyko 7/30 dni, strojenie alarmów, SLA danych) to statystyka liczona deterministycznie; model językowy może je co najwyżej opisać i uszeregować – i ta kolejność odróżnia narzędzie od ozdoby.
- Dostawcę „z AI” oceniaj po tym, na jakich danych liczy, jak tłumaczy wynik, co robi z halucynacjami, czy da się to wyłączyć i kto odpowiada za decyzję.
Od dwóch lat prawie każda oferta oprogramowania do monitoringu konstrukcji ma gdzieś słowo „AI”. Część z tego to realna funkcja, część to nowa nazwa dla starej statystyki, a część to obietnica bez pokrycia. Jeśli specyfikujesz system na wykop albo podpisujesz umowę na monitoring mostu, Twój problem jest konkretny: boisz się zapłacić za ozdobę, której nikt w zespole nie będzie używał – albo odrzucić coś, co realnie zdjęłoby z inżyniera kilka godzin tygodniowo. Ten tekst daje kryteria, żeby rozstrzygnąć to w jednej rozmowie z dostawcą. Jeśli potrzebujesz szerszego tła, zacznij od kompletnego przewodnika po monitoringu konstrukcji, a tu wracaj po część o analityce.
Dwie rzeczy, które AI robi dobrze, i trzy, których nie robi
Sztuczna inteligencja w monitoringu konstrukcji to zestaw metod statystycznych i modeli językowych, które automatycznie przeszukują dane pomiarowe, wskazują odczyty odstające od dotychczasowego zachowania kanału i opisują je w języku naturalnym. Tyle definicja. Reszta to pytanie, co z tego wynika w praktyce.
Robi dobrze: wykrywa odchylenia od własnej historii kanału
Każdy kanał pomiarowy – pochylenie filara, odkształcenie w dźwigarze, ciśnienie porowe w piezometrze – ma swoją historię. Dobowe „oddychanie” od temperatury, tygodniowy rytm obciążenia, powolny dryf. Statystyka radzi sobie z pytaniem „czy to, co przyszło dziś, pasuje do tego, co ten kanał robił przez ostatnie 30 dni?”. Człowiek też sobie radzi, ale nie przy 200 kanałach, domyślnie co 15 minut lub częściej, przez cały rok. AI nie jest tu mądrzejsza od inżyniera. Jest tylko niezmordowana.
Robi dobrze: streszcza i komentuje duże zbiory danych
Drugi realny pożytek to język. Model językowy dostaje policzone wcześniej statystyki i pisze z nich komentarz: które kanały odstają, od kiedy, o ile, co sprawdzić najpierw. Dla inżyniera to skrót do miejsca, od którego zaczyna swoją ocenę. Dla zarządu to akapit, który można przeczytać bez otwierania wykresów. O tym, jak przełożyć dane na język decydenta, pisaliśmy osobno w tekście o raporcie z monitoringu dla zarządu.
Nie robi: nie zna nośności konstrukcji
Model statystyczny widzi liczby, nie widzi schematu statycznego. Nie wie, że 2 mm ugięcia na przęśle 40 m to nic, a 2 mm rozwarcia rysy w strefie zakotwienia to powód do telefonu. Nie zna współczynników bezpieczeństwa, klasy betonu ani tego, że w przyszłym tygodniu na obiekt wjedzie ciężki transport. To wszystko wie projektant i to wszystko jest w progach projektowych.
Nie robi: nie zastępuje progów projektowych i inżyniera
Próg ostrzegawczy i próg alarmowy to decyzja inżynierska, oparta na obliczeniach, doświadczeniu i odpowiedzialności. AI może zaproponować korektę progu, bo widzi, że obecny generuje dziesięć alertów tygodniowo albo nie zadziałał ani razu od roku. Nie może ustalić progu, bo nie zna konsekwencji jego przekroczenia. Szerzej o tym, skąd biorą się progi, w tekście o ustawianiu progów alarmowych.
Nie robi: nie bierze odpowiedzialności
Za kontrolę stanu technicznego odpowiada osoba z uprawnieniami budowlanymi w odpowiedniej specjalności (Prawo budowlane art. 62 ust. 4), a za utrzymanie obiektu w należytym stanie i jego bezpieczne użytkowanie – właściciel lub zarządca (art. 61). Żaden algorytm nie podpisze protokołu kontroli i żaden nie stanie przed nadzorem budowlanym. Jeśli dostawca sugeruje, że „AI pilnuje obiektu”, zapytaj, kto podpisuje się pod jej wnioskami.
| Zadanie | Kto robi to dobrze | Rola AI |
|---|---|---|
| Wskazać kanał, który od wczoraj zachowuje się inaczej niż przez ostatni miesiąc | Statystyka (z-score, detekcja skoków) | Główna – robi to automatycznie i bez zmęczenia |
| Streścić tydzień danych ze 150 kanałów w pięć akapitów | Model językowy na policzonych statystykach | Główna – pod warunkiem, że liczby pochodzą z platformy, nie z „wyobraźni” modelu |
| Ocenić, czy odchylenie zagraża konstrukcji | Inżynier z projektem i progami | Pomocnicza – podsuwa kontekst, nie ocenia |
| Ustalić progi WARNING i ALARM | Projektant / inżynier SHM | Pomocnicza – szacuje, ile zdarzeń wygeneruje dany próg |
| Odpowiadać za decyzję | Osoba z uprawnieniami, zarządca | Żadna |
Dla Ciebie wynika z tego prosta zasada zakupowa: płacisz za dwa pierwsze wiersze tabeli, a trzy ostatnie zostają w zespole – i tak powinno być napisane w ofercie.
Anomalia statystyczna to nie zagrożenie konstrukcji
Anomalia statystyczna to odczyt lub ciąg odczytów, które odbiegają od dotychczasowego rozkładu wartości danego kanału bardziej, niż przyjęty próg uznaje za przypadek. Zagrożenie konstrukcji to stan, w którym wielkość mierzona zbliża się do wartości niebezpiecznej z punktu widzenia nośności lub użytkowalności. Jedno może istnieć bez drugiego. I to w obie strony.
Trzy ilustracyjne scenariusze, w których z-score krzyczy, a konstrukcja ma się dobrze:
Skok po kalibracji. Ekipa wymienia rejestrator, wpisuje nowe współczynniki kalibracyjne, odczyt pochylenia przeskakuje o 0,3 mrad w ciągu jednego kwadransa. Dla statystyki to odchylenie rzędu kilkudziesięciu sigm. Dla konstrukcji nic się nie wydarzyło – zmieniło się zero odniesienia. Jeśli w platformie nie ma zapisu, kto i kiedy zmienił kalibrację, anomalia wygląda jak awaria. Jeśli jest dziennik zmian, sprawa zamyka się w minutę.
Fala upałów. Czujnik strunowy na stalowym dźwigarze, okno bazowe obejmowało chłodny maj, a w czerwcu przychodzi pięć dni z temperaturą powyżej 30 °C. Odkształcenia wychodzą poza wszystko, co kanał „widział”. To nie jest uszkodzenie, to rozszerzalność termiczna stali – i dokładnie dlatego czujniki strunowe mierzy się razem z temperaturą (więcej o tym w tekście o czujnikach strunowych). Bez kompensacji temperatury algorytm będzie generował anomalie przy każdej zmianie pogody.
Zmiana obciążenia. W hali magazynowej najemca zmienia układ regałów i na jednym polu stropu pojawia się stałe dodatkowe obciążenie. Odkształcenia w tym polu przesuwają się na nowy, stabilny poziom. Statystycznie: anomalia, bo rozkład się przesunął. Inżyniersko: trzeba sprawdzić, czy nowe obciążenie mieści się w projektowym – ale sama zmiana poziomu nie jest jeszcze zagrożeniem.
I scenariusz odwrotny, o którym mówi się rzadziej: powolny trend poniżej progu detekcji. Pochylenie filara rośnie o 0,01 mrad dziennie. Każdy kolejny odczyt mieści się w rozkładzie ostatnich 30 dni, bo okno bazowe „przesuwa się” razem z trendem. Z-score milczy. Po roku to 3,65 mrad – na 10 m wysokości ponad 36 mm przemieszczenia wierzchołka (liczby ilustracyjne). Tu ratuje próg bezwzględny z projektu i wykres trendu, nie statystyka odchyleń.
| Sytuacja (ilustracyjnie) | Co widzi z-score | Co to znaczy dla konstrukcji | Kto zamyka temat |
|---|---|---|---|
| Skok o 0,3 mrad po zmianie kalibracji | Anomalia, bardzo wysokie z | Nic – zmieniło się zero odniesienia | Inżynier, na podstawie dziennika zmian |
| Odkształcenia w upale poza oknem bazowym | Anomalia na wielu kanałach naraz | Rozszerzalność termiczna | Kompensacja temperatury + inżynier |
| Nowy stały poziom obciążenia stropu | Anomalia, potem „nowa normalność” | Do sprawdzenia względem projektu | Inżynier z projektantem |
| Dryf 0,01 mrad/dzień przez rok | Brak anomalii | Potencjalnie istotne | Próg projektowy + wykres trendu |
Wniosek jest prosty: detekcja anomalii to filtr uwagi. Zmniejsza liczbę miejsc, na które musisz spojrzeć. Nie mówi, co tam zobaczysz. Jeśli ktoś sprzedaje Ci ją jako „wykrywanie zagrożeń”, pomylił filtr z sędzią.
Z-score w 200 słowach
Z-score to liczba odchyleń standardowych, o jaką dany odczyt odbiega od średniej z wybranego okna bazowego. Wzór:
z = (x − μ) / σ
gdzie x to bieżący odczyt, μ to średnia z okna bazowego, a σ to odchylenie standardowe z tego samego okna. Okno bazowe to przedział historii kanału (np. ostatnie 7, 30 lub 90 dni), z którego liczy się μ i σ. Odczyt uznaje się za anomalię, gdy |z| > k, gdzie k to przyjęty próg – najczęściej 2, 2,5 lub 3.
Przykład ilustracyjny. Przyjmijmy kanał pochylenia filara. Okno 30 dni: μ = 1,20 mrad, σ = 0,05 mrad. Dziś przychodzi odczyt x = 1,38 mrad.
z = (1,38 − 1,20) / 0,05 = 3,6
Przy k = 3 to anomalia. Teraz zmieńmy tylko okno: wydłużamy do 90 dni, które obejmują wiosenne wahania temperatury, i σ rośnie do 0,12 mrad.
z = (1,38 − 1,20) / 0,12 = 1,5
Ten sam odczyt, żadnej anomalii. Wybór okna bazowego i progu k zmienia wynik bardziej niż sama konstrukcja.
Odmiana odporna zamienia średnią na medianę, a σ na medianowe odchylenie bezwzględne (MAD). Pojedynczy skok nie „rozdmuchuje” wtedy rozrzutu i nie maskuje kolejnych odchyleń. NIST/SEMATECH e-Handbook of Statistical Methods opisuje ją jako Modified Z-Score, obok testu Grubbsa dla pojedynczej wartości odstającej.
Trzy ograniczenia, o których trzeba pamiętać:
- Sezonowość. Jeśli okno nie obejmuje pełnego cyklu (doba, pora roku), σ jest niedoszacowane i każda zmiana pogody staje się anomalią. Okno zbyt długie z kolei „rozmywa” σ i przepuszcza realne zmiany.
- Trend. Z-score zakłada stacjonarność: stałą średnią. Przy powolnym dryfie μ przesuwa się razem z danymi i algorytm nie widzi trendu – widzi tylko skoki.
- Autokorelacja. Odczyty w domyślnym interwale 15 minut nie są od siebie niezależne; sąsiednie wartości są silnie skorelowane. Efektywna liczba niezależnych próbek jest znacznie mniejsza niż 96 na dobę, a σ policzone „na piechotę” bywa zaniżone. W praktyce oznacza to więcej fałszywych anomalii, niż sugerowałby próg k.
Czy to dyskwalifikuje z-score? Nie. To dyskwalifikuje używanie z-score bez świadomości tych trzech rzeczy. Z-score ma jedną cechę, której brakuje bardziej złożonym modelom: każdy inżynier jest w stanie sprawdzić wynik na kalkulatorze. To ma znaczenie, kiedy trzeba komuś wytłumaczyć, dlaczego platforma się odezwała.
Raporty inżynierskie: dług kalibracji, kompensacja temperatury, ryzyko 7/30 dni, SLA danych – gdzie AI pomaga, a gdzie tylko liczy
Raport inżynierski w platformie monitoringu to zestaw analiz liczonych automatycznie na danych projektu, które odpowiadają na konkretne pytania o stan instalacji pomiarowej i zachowanie kanałów. Większość tego, co w ofertach nazywa się „AI”, to właśnie takie raporty – statystyka policzona deterministycznie. Model językowy, jeśli w ogóle bierze w tym udział, opisuje i porządkuje gotowe liczby. To dobra wiadomość: taki wynik da się sprawdzić.
Dług kalibracji to odchylenie bieżącej wartości kanału od odczytu referencyjnego (zera) razem z dryfem z ostatnich 7 i 30 dni, uszeregowane od kanału, który „odjechał” najbardziej. Zamiast zdania „kiedyś trzeba objechać czujniki” dostajesz listę: które kanały sprawdzić najpierw i dlaczego. Dryf bywa też tłumaczeniem dziwnych anomalii – zanim podejrzysz konstrukcję, upewnij się, że nie ucieka czujnik. Decyzję o wyjeździe ekipy podejmuje inżynier, bo to on zna koszt dojazdu i konsekwencje zwłoki.
Kompensacja temperatury to porównanie zależności wartości kanału od temperatury przed kompensacją i po niej, liczone tor po torze na danych z wybranego okna. Ten raport zdejmuje większość anomalii „pogodowych” z listy: jeśli po kompensacji korelacja z temperaturą znika, odchylenie było termiczne; jeśli zostaje coś, czego temperatura nie tłumaczy, to jest miejsce na inżyniera. Komentarz tekstowy przydaje się tu do jednego: wskazania, na których torach kompensacja działa, a na których nie.
Ryzyko 7/30 dni to trajektoria kanału w horyzoncie tygodnia i miesiąca liczona odpornymi statystykami (mediana i MAD zamiast średniej i σ, wygładzanie wykładnicze, sumy skumulowane), która pokazuje, które kanały konsekwentnie oddalają się od swojego poziomu bazowego, a nie jedynie raz „podskoczyły”. To nie jest przepowiednia awarii. To odpowiedź na pytanie „gdzie patrzeć w tym tygodniu” – i tyle powinien z niej zrobić komentarz AI. Inżynier decyduje, czy to powód do działania, czy do obserwacji.
Strojenie alarmów to propozycja progów wyliczona z rozkładu historii kanału (wysokie percentyle) razem z szacunkiem, ile zdarzeń tygodniowo taki próg wygeneruje. Jeśli próg ostrzegawczy budzi kogoś co drugą noc bez powodu, zostanie zignorowany w noc, w którą ma znaczenie. Propozycja jest statystyczna; zatwierdza ją człowiek, bo próg to decyzja projektowa.
SLA danych to kompletność odczytów względem rzeczywistej kadencji kanału (platforma wyznacza ją z odstępów między próbkami): ile próbek przyszło, ile powinno, jakie były luki i ile minęło od ostatniego odczytu. To najmniej „inteligentny” i najbardziej użyteczny raport. Bez niego wszystkie pozostałe są niewiarygodne – z-score liczony na kanale, który przez dwa tygodnie milczał, jest bezwartościowy.
Wspólny mianownik: w każdym z tych raportów liczby pochodzą z platformy, a komentarz je co najwyżej opisuje i porządkuje. Jeśli dostawca odwraca tę kolejność – model „ocenia” surowe pomiary i sam wymyśla, co jest ważne – to nie jest raport inżynierski, tylko esej.
Pytania do dostawcy „z AI”
Poniższa lista powstała z myślą o specyfikacji i o rozmowie handlowej. Szerszą checklistę wyboru platformy znajdziesz w tekście o wyborze platformy monitoringu; tu skupiamy się na części „AI”.
- Na jakich danych liczy? Na surowych odczytach, na wartościach przeliczonych, na agregatach godzinowych? Jakie okno bazowe i czy da się je zmienić?
- Co dokładnie jest „AI”, a co statystyką? Z-score, detekcja skoków i martwych kanałów to statystyka. Komentarz tekstowy to model językowy. Dostawca powinien umieć to rozdzielić w jednym zdaniu.
- Jak tłumaczy wynik? Czy przy każdej anomalii widać liczby (μ, σ, z, okno), czy tylko etykietę „anomalia”? Wynik, którego nie da się odtworzyć ręcznie, nie nadaje się do protokołu.
- Co z halucynacjami? Halucynacja to sytuacja, w której model językowy generuje stwierdzenie niepoparte danymi wejściowymi. Pytanie brzmi: czy model dostaje policzone statystyki, czy surowe pomiary, i czy każde stwierdzenie w komentarzu da się wskazać palcem w danych?
- Co się dzieje, gdy model jest niedostępny? Czy raport powstaje w wersji bez komentarza, czy znika cały?
- Kto odpowiada za decyzję podjętą na podstawie komentarza AI? Odpowiedź powinna brzmieć: inżynier, a platforma jest narzędziem. Jeśli dostawca sugeruje coś innego, poproś o to na piśmie.
- Czy da się to wyłączyć? Jeśli zespół nie ufa komentarzom, powinien móc korzystać z platformy bez nich, z progami i alarmami liczonymi deterministycznie.
- Czy moje dane trenują cudze modele? Zadaj to pytanie każdemu dostawcy, który używa modelu językowego, i poproś o odpowiedź na piśmie: gdzie dane są przetwarzane, czy opuszczają infrastrukturę dostawcy platformy, kto jest dostawcą modelu i co mówi jego polityka o uczeniu na danych klientów. Dane pomiarowe zwykle nie są danymi osobowymi, ale kontakty odbiorców alarmów już tak – ich hosting wymaga umowy powierzenia zgodnej z art. 28 RODO.
- Czy AI może samodzielnie zmienić próg lub wyciszyć alarm? Prawidłowa odpowiedź: może zaproponować, człowiek zatwierdza. Każda zmiana ma zostać w dzienniku zmian z informacją, kto i kiedy.
- Czy komentarz AI jest częścią dokumentacji obiektu? Jeśli tak – kto go podpisuje i jak jest wersjonowany razem z konfiguracją, na której powstał?
Dostawca, który na większość z tych pytań odpowiada konkretnie, traktuje AI jak narzędzie. Dostawca, który odpowiada „to zaawansowany algorytm”, traktuje AI jak hasło. Te dziesięć pytań mieści się w jednym e-mailu; odpowiedzi wklej do specyfikacji – wtedy „AI” przestaje być hasłem, a staje się parametrem, który da się odebrać.
Jak to wygląda w Inclify
Analiza AI w Inclify to asystent, nie wyrocznia. Statystyki per kanał i wykrywanie anomalii liczy baza danych platformy: z-score względem okna bazowego (do 90 dni), z-score skoku, procent zmiany i kanały, które przestały się zmieniać. Model językowy dostaje wyłącznie te policzone wyniki – nazwę projektu i urządzeń, zakres, liczby kanałów w stanie ostrzegawczym i krytycznym, listę anomalii z liczbami – nie surowe szeregi czasowe. Na tej podstawie pisze po polsku komentarz, listę ustaleń i rekomendacje, z instrukcją, żeby opierać się wyłącznie na danych z wejścia. Dostawcę i model językowy ustala się w konfiguracji wdrożenia; bez klucza do modelu analiza nadal powstaje, tylko w wersji deterministycznej, bez komentarza.
Progi WARNING i ALARM, powiadomienia SMS i e-mail, potwierdzanie i wyciszanie alarmów z terminem działają niezależnie od AI – to deterministyczna część platformy. Raporty inżynierskie (dług kalibracji, kompensacja temperatury, ryzyko 7/30 dni, strojenie alarmów, SLA danych) są liczone z danych projektu i dostępne obok analizy AI; nie potrzebują modelu językowego, żeby działać. Nie obiecujemy predykcji awarii ani „samouczącego się” pilnowania obiektu. Obiecujemy, że inżynier szybciej trafi do miejsca, od którego zaczyna się jego ocena. Szczegóły na stronie analiza AI w Inclify.
FAQ
Czy AI może zastąpić progi alarmowe w monitoringu konstrukcji?
Nie. Progi WARNING i ALARM wynikają z projektu, obliczeń i odpowiedzialności inżyniera – są wartościami bezwzględnymi odniesionymi do nośności i użytkowalności. AI wykrywa odchylenia względem historii kanału, czyli coś innego. Może podpowiedzieć, że progi są za ciasne lub za luźne, ale nie zna konsekwencji przekroczenia. Oba mechanizmy powinny działać równolegle: progi jako twarda granica, anomalie jako filtr uwagi.
Co to jest z-score i jak go interpretować w danych pomiarowych?
Z-score to liczba odchyleń standardowych, o jaką odczyt odbiega od średniej z okna bazowego: z = (x − μ)/σ. Wartość |z| powyżej 2–3 zwykle uznaje się za anomalię. Interpretacja wymaga kontekstu: z-score nie zna jednostek, progów projektowych ani przyczyny odchylenia. Wysokie z po zmianie kalibracji lub w upale nie oznacza problemu konstrukcyjnego, a niskie z przy powolnym trendzie nie oznacza bezpieczeństwa.
Czy anomalia wykryta przez AI oznacza zagrożenie konstrukcji?
Nie musi. Anomalia statystyczna oznacza, że kanał zachowuje się inaczej niż w oknie bazowym. Przyczyną może być zmiana kalibracji, pogoda, zmiana obciążenia, awaria czujnika albo realna zmiana w konstrukcji. Rozstrzyga inżynier, zestawiając anomalię z temperaturą, dziennikiem zmian, progami projektowymi i wykresem trendu. Traktuj anomalię jak wskazanie miejsca, na które warto spojrzeć najpierw.
Skąd się biorą fałszywe anomalie i jak je ograniczyć?
Najczęściej z trzech źródeł: okno bazowe nie obejmuje pełnego cyklu sezonowego, odczyty są silnie autokorelowane (σ wychodzi zaniżone), brak kompensacji temperatury. Pomaga dobór okna do charakteru kanału, liczenie anomalii na wartościach skompensowanych termicznie, wymaganie utrzymania odchylenia przez kilka kolejnych odczytów zamiast reagowania na pojedynczy punkt oraz raport SLA danych, który wyklucza kanały z lukami.
Co z halucynacjami modeli językowych w raportach z monitoringu?
Halucynacja to stwierdzenie wygenerowane przez model bez pokrycia w danych wejściowych. Ryzyko maleje, gdy model dostaje gotowe, policzone statystyki zamiast surowych pomiarów, a każde zdanie komentarza ma wskazany dowód z danych. Pytaj dostawcę o tę architekturę i o to, co się dzieje, gdy model jest niedostępny. Komentarz AI traktuj jak notatkę asystenta do sprawdzenia, nie jak ustalenie do protokołu.
Czy analiza AI w monitoringu konstrukcji to system wysokiego ryzyka według AI Act?
AI Act (rozporządzenie UE 2024/1689, w mocy od 1 sierpnia 2024 r.) klasyfikuje systemy wysokiego ryzyka m.in. według załącznika III. Monitoring stanu konstrukcji budynków i obiektów inżynierskich nie jest tam wymieniony – pkt 2 dotyczy elementów bezpieczeństwa krytycznej infrastruktury cyfrowej, ruchu drogowego oraz dostaw wody, gazu, ciepła i energii. Klasyfikację trzeba jednak ocenić dla konkretnego zastosowania, a terminy stosowania przepisów o wysokim ryzyku były w 2026 r. przesuwane.
Kto odpowiada za decyzję podjętą na podstawie komentarza AI?
Osoba z uprawnieniami budowlanymi, która przeprowadza kontrolę stanu technicznego (Prawo budowlane art. 62 ust. 4), oraz właściciel lub zarządca, który ma utrzymywać obiekt w należytym stanie i zapewnić jego bezpieczne użytkowanie (art. 61). Oprogramowanie jest narzędziem, tak jak dalmierz czy arkusz kalkulacyjny. Jeśli dostawca sugeruje, że AI „przejmuje” nadzór, poproś o tę deklarację na piśmie. Ten tekst nie jest poradą prawną; w sprawach odpowiedzialności skonsultuj się z prawnikiem.
Źródła i dalsza lektura
- Ustawa Prawo budowlane, art. 61 i 62 (obowiązki właściciela i zarządcy, kontrole okresowe i osoby uprawnione do ich przeprowadzania) – isap.sejm.gov.pl.
- PN-EN 1997-1 Eurokod 7: Projektowanie geotechniczne – metoda obserwacyjna (rola pomiarów i wartości granicznych w procesie projektowania) – sklep.pkn.pl.
- NIST/SEMATECH e-Handbook of Statistical Methods, sekcja 1.3.5.17 „Detection of Outliers” (z-score, Modified Z-Score, test Grubbsa) – https://www.itl.nist.gov/div898/handbook/eda/section3/eda35h.htm
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 w sprawie sztucznej inteligencji (AI Act), załącznik III – https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Rozporządzenie (UE) 2016/679 (RODO), art. 28 – umowa powierzenia przetwarzania – https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Dokumentacja producentów czujników strunowych o wpływie temperatury na odczyt i współczynnikach korekcji termicznej – geokon.com.
- Powiązane teksty w serii: kompletny przewodnik po monitoringu konstrukcji, progi alarmowe, czujniki strunowe, checklista wyboru platformy, raport z monitoringu dla zarządu, podłączenie istniejących rejestratorów.
Co dalej
Najniższy próg wejścia to pilot na jednym obiekcie, na danych, które już masz – z własnych czujników albo z istniejących rejestratorów (podłączenie przez HTTP/JSON trwa zwykle kilka dni; jak to wygląda, opisaliśmy w tekście o podłączaniu istniejących rejestratorów). Zobaczysz, jak z-score zachowuje się na Twoich kanałach, gdzie kompensacja temperatury zdejmuje fałszywe anomalie i jak wygląda komentarz AI obok progów, które ustalił Twój inżynier.
Jest też powód, żeby nie odkładać tego na później: statystyka potrzebuje okna bazowego. Każdy tydzień danych zebranych przed sezonem, który chcesz obserwować – zimą, przed wykopem, przed przeglądem – to tydzień, w którym algorytm ma z czego liczyć, zamiast zgadywać. Bez obietnic, że algorytm „upilnuje” obiekt – z obietnicą, że szybciej zobaczysz, na co patrzeć.
Porozmawiajmy o pilocie analizy AI na Twoim obiekcie – odpowiadamy w 24 h.