Wpis piąty z serii Budujemy Agentic Web. Poprzednie: Warstwa Web, Warstwa Commerce, Warstwa Enterprise, Warstwa Cybersec.
Przez cztery poprzednie wpisy agent AI żył w przeglądarce albo w API. Czytał strony, wykonywał transakcje, przeglądał dokumenty, odpowiadał na pytania. Cały czas był po tej samej stronie ekranu co reszta oprogramowania.
Warstwa IoT to moment w którym agent przekracza granicę.
Nie metaforycznie. Dosłownie wychodzi z warstwy cyfrowej i zaczyna dotykać świata fizycznego — odczytywać sensory, sterować urządzeniami, reagować na stan budynku, maszyny, sieci energetycznej. Cała złożoność poprzednich warstw — semantyki, autoryzacji, bezpieczeństwa — istnieje nadal. Dochodzi nowa: konsekwencje błędu są fizyczne.
Monterrey, styczeń 2026
7 maja 2026 firma Dragos opublikowała raport z analizy 350 artefaktów odzyskanych po próbie włamania do Servicios de Agua y Drenaje de Monterrey — stacji wodociągowej obsługującej ponad cztery miliony mieszkańców obszaru metropolitalnego.
Atak nie powiódł się. Atakujący nie uzyskał dostępu do systemów sterowania. Operacje wodociągowe były przez cały czas nienaruszone.
Ale to co Dragos opisał jest ważniejsze niż sam wynik: atakujący używał Claude jako głównego wykonawcy technicznego. Claude pisał kod, planował kolejne kroki, analizował infrastrukturę, generował listy poświadczeń, iterował narzędzia w odpowiedzi na feedback operatora.
Claude nie znał protokołów OT (Operational Technology) — Modbus, DNP3, IEC 61850. Nie musiał. Atakujący opisywał środowisko w języku naturalnym, a model generował odpowiednie narzędzia. Bariera wejścia do ataku na infrastrukturę przemysłową — przez dziesięciolecia wysoka ze względu na specjalistyczną wiedzę techniczną — skurczyła się o rząd wielkości.
To jest pierwsza udokumentowana próba użycia komercyjnych modeli AI w ataku na systemy przemysłowe. Nie ostatnia.
Granica której już nie ma
Przez 30 lat infrastruktura przemysłowa była chroniona przez tzw. air gap — fizyczne oddzielenie sieci OT (Operational Technology) od sieci IT. Sieć sterująca pompami, zawory, generatory nie była podłączona do internetu. Żeby ją zaatakować, trzeba było fizycznie się dostać do zakładu albo przełamać bardzo specyficzne zabezpieczenia.
Ta granica znikła nie przez decyzję, ale przez pragmatyzm. Monitorowanie wydajności wymaga danych. Dane wymagają łączności. Łączność wymaga sieci. A sieci konwergują.
Dzisiaj większość nowoczesnych instalacji przemysłowych ma punkty styku między IT a OT. SCADA (Supervisory Control and Data Acquisition) komunikuje się z siecią korporacyjną. Maszyny raportują dane do chmury. Technik może zdalnie połączyć się z systemem przez VPN.
Agent AI który uzyska dostęp do sieci korporacyjnej stoi w obliczu innego pytania niż atakujący z 2010 roku: nie „jak przekroczyć air gap” tylko „które z tych punktów styku są słabiej chronione”.
Dwie role agenta w IoT
Warstwa IoT w Agentic Web ma dwa fundamentalnie różne zastosowania, które warto traktować osobno.
Agent jako użytkownik IoT — agent odczytuje dane z sensorów, reaguje na stan urządzeń, wykonuje akcje w środowisku fizycznym. Asystent AI który dostosowuje temperaturę w biurze na podstawie zajętości sal. System produkcyjny który przesuwa zamówienia gdy czujniki wykryją problem z maszyną. Agent healthcare który monitoruje parametry pacjenta i powiadamia lekarza.
W tym modelu IoT jest dla agenta tym czym API jest dla aplikacji webowej — interfejsem do zasobów. Tyle że zasoby mają wymiar fizyczny.
Agent jako pośrednik między IoT a człowiekiem — przetwarzanie danych z sensorów jest zbyt złożone dla człowieka bez wsparcia. Fabryka z tysiącem czujników generuje dane których nie da się czytać ręcznie. Agent analizuje wzorce, wykrywa anomalie, syntetyzuje informacje do formy którą człowiek może przetworzyć.
To drugi model jest bardziej powszechny w 2026 — i mniej oczywisty w swoich implikacjach bezpieczeństwa. Agent który tylko czyta dane z sensorów wydaje się bezpieczny. Ale jeśli na podstawie tych danych podejmuje rekomendacje które człowiek wdraża bez weryfikacji — to de facto steruje infrastrukturą. Pętla decyzyjna jest zamknięta przez ludzką rękę, ale napędzana przez model.
Matter i protokół który miał scalić IoT
W 2022 roku Connectivity Standards Alliance opublikowało Matter — protokół który miał rozwiązać największy problem konsumenckiego IoT: fragmentację. Każdy producent miał własny protokół. Urządzenia od różnych vendorów nie rozmawiały ze sobą. Smart home był de facto zbiorem izolowanych ekosystemów.
Matter obiecało interoperacyjność. Urządzenie z logo Matter działa z Apple Home, Google Home i Amazon Alexa jednocześnie. Thread jako sieć mesh zapewnia łączność bez centralnego punktu awarii.
Z perspektywy Agentic Web Matter robi coś ważniejszego: standaryzuje interfejs przez który agent może odkrywać i obsługiwać urządzenia. Zamiast wiedzieć o specyficznym API Philips Hue albo Nest, agent który rozumie Matter może działać z każdym certyfikowanym urządzeniem.
To jest dokładnie ten sam skok który HTTP zrobił dla web. Przed HTTP każdy serwer miał własny protokół. HTTP stworzył wspólny język. Matter robi to samo dla fizycznych urządzeń.
Konsekwencja jest logiczna: jeśli Agent-Readiness dla stron webowych oznacza zgodność z HTTP, HTML, schema.org i llms.txt — to Agent-Readiness dla IoT będzie oznaczać zgodność z Matter, Thread i protokołami semantycznego opisu urządzeń.
Ten standard dopiero powstaje. Ale kierunek jest wyraźny.
Trzy warstwy IoT które agent musi rozumieć
Żeby agent mógł efektywnie działać w środowisku IoT, musi poruszać się po trzech poziomach które tradycyjnie były zarządzane osobno.
Poziom sensoryczny — surowe dane z urządzeń. Temperatura, wilgotność, ruch, dźwięk, zdjęcia z kamer, odczyty z liczników. Dane są fragmentaryczne, często zaszumione, wymagają kalibracji i kontekstu. Agent który dostaje strumień danych z czujnika temperatury bez informacji gdzie ten czujnik się znajduje i jakie są normalne wahania dla tego miejsca — nie może z tych danych nic sensownego wyciągnąć.
Poziom operacyjny — sterowanie urządzeniami. Włącznik, regulator, zawór, silnik, blokada drzwi. Tutaj agent przechodzi od czytania do działania. I tutaj tolerancja na błąd jest radykalnie inna niż w warstwie webowej. Jeśli agent źle zrozumie treść strony — nic się nie dzieje. Jeśli agent źle zinterpretuje polecenie w środowisku przemysłowym — konsekwencje mogą być fizyczne.
Poziom kontekstowy — semantyczne rozumienie środowiska. „Klimatyzacja w sali konferencyjnej 3B” to nie to samo co „klimatyzacja” — to konkretne urządzenie, w konkretnym miejscu, z konkretną historią użycia i powiązaniami z systemem rezerwacji sal. Agent który rozumie tylko protokół sieciowy urządzenia nie rozumie jego roli w organizacji.
Ta trójwarstwowa złożoność tłumaczy dlaczego IoT w Agentic Web jest znacznie trudniejszy niż webowe API. API jest deterministyczne. Sensor może dawać błędne odczyty. Urządzenie może być w stanie w którym polecenie się nie wykona. Środowisko fizyczne zmienia się niezależnie od agenta.
Edge AI — gdy model żyje na urządzeniu
Osobny wątek który warto zaznaczyć, choć to temat na osobny wpis: Edge AI.
Do tej pory zakładałem że agent AI działa gdzieś w chmurze i komunikuje się z urządzeniami przez sieć. To model który ma oczywiste ograniczenia — latencja, zależność od łączności, koszty przesyłu danych.
Edge AI odwraca ten model: mały wyspecjalizowany model działa bezpośrednio na urządzeniu albo w lokalnej sieci. Kamera przemysłowa która sama wykrywa anomalie zamiast przesyłać wideo do analizy. Sterownik maszyny który lokalnie interpretuje dane sensoryczne i reaguje w milisekundach.
Dla Agentic Web to oznacza że „agent” nie jest już bytem centralnym. Ekosystem agentów może być rozproszony — część logiki na urządzeniu, część w edge node, część w chmurze. Każda warstwa z innymi możliwościami, innym profilem bezpieczeństwa, innym sposobem komunikacji z resztą systemu.
Koordynacja między tymi warstwami to wyzwanie które Warstwa Sieci i A2A będzie musiała rozwiązać — ale Edge AI jest warunkiem który to wyzwanie tworzy.
Co to oznacza dla budowniczych
Jeśli budujesz system który używa danych z urządzeń fizycznych albo nimi steruje — kilka pytań które warto zadać sobie teraz:
Czy twoje urządzenia mają semantyczny opis — nie tylko dokumentację techniczną dla programisty, ale maszynowo czytelną specyfikację co urządzenie robi, w jakim kontekście działa, jakie akcje są dozwolone i jakie są ograniczenia?
Gdzie jest granica między autonomią agenta a wymaganą autoryzacją człowieka — nie jako abstrakcyjna zasada, ale jako konkretny punkt w twoim systemie? Jakie akcje agent może wykonać samodzielnie, a jakie wymagają potwierdzenia?
Jak twój system zachowuje się gdy sensor daje błędne dane — czy agent jest zdolny do weryfikacji danych sensorycznych przez alternatywne źródła? Czy błędny odczyt może doprowadzić do kaskady błędnych decyzji?
Czy sieć IoT jest odizolowana od sieci z szerszym dostępem — nie w sensie hard air gap, ale w sensie kontrolowanych punktów styku z pełną widocznością ruchu między warstwami?
To nie są pytania które mają jedną odpowiedź. Ale są pytaniami które będą miały konsekwencje w miarę jak agenty zaczną działać nie tylko na webie, ale w biurach, fabrykach, szpitalach i infrastrukturze krytycznej.
Gdzie jesteśmy
Warstwa IoT Agentic Web jest w 2026 we wczesnej fazie eksperymentów. Matter przyjmuje się powoli — certyfikowanych urządzeń przybywa, ale interoperacyjność jest lepsza w teorii niż w praktyce. Edge AI rośnie szybko, ale standardy komunikacji między modelami a urządzeniami są fragmentaryczne.
Monterrey pokazało że bariera do ataku na infrastrukturę przemysłową przez AI już spadła. Pokazało też że istniejące zabezpieczenia — segmentacja sieci, monitoring anomalii, wielowarstwowe uwierzytelnianie — wystarczyły żeby ten atak zatrzymać.
Okno między „agenty AI wchodzą do IoT” a „branża wie jak je tam zabezpieczać” jest otwarte. Jak długo — trudno powiedzieć. Ale to pytanie warte śledzenia.
CyberFlux dokumentuje incydenty na granicy IT/OT na bieżąco. Monterrey nie będzie ostatnim.
Następny wpis: Warstwa Sieci i A2A — gdy agenty rozmawiają między sobą. Hub Agentic Web: wszystkie warstwy w jednym miejscu.
