Byggets kontrollsløyfer kan ikke digitaliseres bort 

Men når diskusjonen handler om å «kaste», «skrote» eller «droppe» SD-anlegget, mener jeg vi starter i feil ende. 

For hva er det egentlig vi skal fjerne? 

Er det visualiseringen? Alarmhåndteringen? Historikken? Analysen? Den overordnede styringen? Eller den lokale automasjonen som faktisk regulerer temperatur, luftmengder, trykk og vann? 

Det er først når vi svarer på dette at diskusjonen blir interessant. 

Spørsmålet er ikke om vi kan skrote SD-anlegget. Spørsmålet er hvilke funksjoner vi flytter, hvilke avhengigheter vi introduserer – og hva som skjer når de svikter. 

Hva mener vi egentlig med SD-anlegget? 

Begrepet SD-anlegg brukes ofte som om det beskriver én bestemt teknisk løsning. I praksis brukes det om alt fra visualisering og alarmhåndtering til historikk, overordnet styring og integrasjoner mot andre systemer. 

Det gjør debatten vanskelig. 

Tradisjonelt skiller vi gjerne mellom feltet med sensorer og aktuatorer, automasjonsnivået med regulatorer og lokal logikk, og administrasjonsnivået der informasjon samles, visualiseres og brukes til overordnet styring. 

Grensene er ikke absolutte, og moderne løsninger utfordrer dem. Det er heller ikke noe mål i seg selv å bevare denne lagdelingen akkurat slik den har vært. 

Men funksjonene forsvinner ikke fordi vi endrer teknologien eller navnet på systemet. 

Temperatur skal fortsatt reguleres. Luft skal flyttes. Vann skal sirkulere. Ventiler skal åpne og lukke. Frostsikring skal fungere. 

Derfor bør det første spørsmålet når noen vil «droppe SD-anlegget» være: 

Hvilket lag er det egentlig vi skal erstatte – og hvilke funksjoner skal alternativet overta? 

Å erstatte visualisering, historikk og analyse med en moderne skyplattform er én diskusjon. Å flytte grunnleggende regulerings- og beskyttelsesfunksjoner ut av den lokale automasjonen er en helt annen. 

Kontrollsløyfene består 

Teknologien i og rundt byggene utvikler seg raskt. 

Vi har fått batteridrevne sensorer, trådløs kommunikasjon, IoT-enheter og komponenter som gjør det langt enklere å instrumentere eksisterende bygg. Vi kan samle inn mer data, etablere nye funksjoner raskere og analysere sammenhenger som tidligere var vanskelige å oppdage. 

Dette tilfører betydelig verdi. 

Men de grunnleggende fysikalske behovene og prinsippene for regulering består. En tilstand må registreres, en respons må beregnes og en fysisk handling må utføres. 

Selve reguleringsprinsippet er uavhengig av om kommunikasjonen er trådløs eller kablet. Arkitekturvalget er det ikke. 

Responstid, tilgjengelighet, batterilevetid, vedlikeholdsbehov og konsekvensen av kommunikasjonsbrudd må fortsatt vurderes. 

Et ventilasjonsaggregat skal fungere en kald januardag om ti år. En varmesentral skal starte igjen etter en strømstans. Frostsikringen skal fungere selv om forbindelsen til en skytjeneste er borte. 

Det betyr ikke at alle funksjoner må ligge lokalt. 

Analyse, optimalisering, prognoser og overordnede settpunkter kan med stor fordel komme fra tjenester utenfor den lokale automasjonen. 

Det interessante er hva som skjer når disse tjenestene forsvinner. 

En energirapport som uteblir fordi en skytjeneste er utilgjengelig noen timer, er irriterende. Et analyseverktøy som mangler oppdaterte data i samme periode, er vanligvis håndterbart. 

Dersom frostbeskyttelsen av et varmebatteri slutter å fungere fordi en ekstern tjeneste er utilgjengelig, har vi en helt annen situasjon. 

Konsekvensen av feil må være med på å bestemme hvor funksjonen plasseres og hvilke avhengigheter vi aksepterer. 

Funksjoner med høy konsekvens ved bortfall bør derfor ha en definert driftsform dersom kommunikasjonen med overordnede tjenester forsvinner. Det kan være sikker stopp, videre drift innenfor lokale grenser eller kontrollert degradert drift. 

Det er ikke et argument mot sky, trådløse sensorer eller PropTech. 

Det er et argument for arkitektur. 

Finner AI noe nytt – eller noe vi burde ha funnet allerede? 

Kunstig intelligens kommer til å få en viktig rolle i byggdriften. 

AI kan analysere store datamengder, finne sammenhenger på tvers av systemer, oppdage gradvise avvik og hjelpe driftspersonell med å prioritere informasjon. Det er lett å se verdien av dette i store bygningsporteføljer med enorme mengder tekniske data. 

Men når AI trekkes frem fordi teknologien oppdager feil som tidligere har gått under radaren, bør vi samtidig stille et litt ubehagelig spørsmål: 

Var dette feil som krevde kunstig intelligens for å oppdage, eller kunne et godt prosjektert automasjons- og SD-anlegg med riktig programmering, alarmstrategi og oppfølging ha funnet dem allerede? 

Forskjellen er viktig. 

Et godt automasjonsanlegg kan allerede oppdage mye gjennom grenseverdier, tidsforsinkelser, plausibilitetskontroll, sekvenskontroll og sammenstilling av signaler. En ventil som ikke gir forventet respons, eller en pumpe som går uten forventet temperatur- eller trykkendring, kan oppdages uten kunstig intelligens. 

Det krever god instrumentering, programmering, alarmstrategi og oppfølging. 

AI kan tilføre noe annet. Teknologien kan analysere historikk på tvers av systemer og bygg, oppdage gradvise endringer og finne mønstre som det ville vært urimelig å programmere eksplisitt. 

Men vi bør være forsiktige med å omtale enhver feil AI oppdager som dokumentasjon på at tradisjonell automasjon er utilstrekkelig. 

I det ene tilfellet tilfører AI en ny kapasitet. I det andre bruker vi ny teknologi til å kompensere for mangler lenger ned i arkitekturen. 

Det bør vi klare å skille mellom. 

Fra å analysere til å handle 

Det er likevel ikke AI-analysen jeg mener er den mest interessante utviklingen. 

Det virkelig interessante skjer når teknologien går fra å analysere til å handle. 

Tradisjonelle SD-anlegg har aldri bare vært observerende. De har lenge kunnet endre settpunkter og tidsprogrammer, starte og stoppe anlegg og utføre overordnede styringsfunksjoner. 

Men påvirkningen har i stor grad vært avgrenset til den tekniske infrastrukturen systemet var bygget for å håndtere. Denne avgrensningen er i ferd med å bli mindre tydelig. 

Moderne plattformer kobles til FDVU-systemer, arbeidsordresystemer, dokumentlagre, energisystemer og andre tekniske og administrative løsninger. Samtidig får vi AI-agenter som ikke bare analyserer informasjon, men som kan utføre handlinger på vegne av brukeren. 

Da endrer risikoen karakter. 

En agent som leser temperaturer, energidata og alarmer representerer én type risiko. En agent som analyserer informasjonen og foreslår et tiltak, representerer noe mer. En agent som selv kan opprette arbeidsordre, endre ansvarlig eller skrive til andre systemer, representerer noe helt annet. 

Vi bør derfor skille mellom tre nivåer: 

Lese. Foreslå. Handle. 

Jo lenger mot handling vi beveger oss, desto viktigere blir spørsmålene om tilgang, godkjenning, sporbarhet og konsekvens. 

Det avgjørende er ikke hvor intelligent agenten er, men hvor stor myndighet vi gir den. 

Hvem ga agenten nøklene? 

NemiTek beskrev nylig hvordan en AI-agent hos KLP Eiendom, gjennom en API-nøkkel med omfattende rettigheter, begynte å oppdatere saker, endre ansvarlig og skrive tekst i FDV-systemet. 

Det er lett å lese dette som en interessant historie om en AI-agent som gjorde noe uventet. Jeg mener den viktigste lærdommen ligger et annet sted. 

Agenten hadde mulighet til å gjøre det. 

Det kan ha eksistert andre tekniske eller organisatoriske begrensninger som ikke er omtalt i artikkelen. Men det vi vet, er interessant nok: En agent som var ment brukt i en testsituasjon, gjorde reelle endringer i produksjonsmiljøet gjennom en API-nøkkel med omfattende rettigheter. 

Når en digital tjeneste får skrivetilgang i et produksjonsmiljø, holder det ikke å spørre om teknologien fungerer etter hensikten. Vi må også spørre hva den kan gjøre når den ikke gjør det. 

Hvilke handlinger kunne agenten utføre? Hva krevde godkjenning? Og hvordan var skillet mellom test og produksjon etablert? 

Dette er ikke detaljer som kan ryddes opp i etter at teknologien er satt i drift. De er en del av arkitekturen og styringsmodellen rundt løsningen. 

For konsekvensen kunne vært større enn noen feiloppdaterte saker. 

Når en agent får skriveadgang til flere systemer, kan én feil analyse i prinsippet bli til mange feil handlinger. Og en agent kan utføre disse handlingene langt raskere enn et menneske rekker å oppdage og reagere på dem. 

I dette tilfellet handlet det om endringer i et administrativt system. Artikkelen dokumenterer ikke at agenten hadde tilgang til automasjon, settpunkter, alarmer eller tekniske kommandoer. 

Men prinsippet blir langt mer alvorlig dersom den samme tilgangsmodellen brukes mot systemer med større konsekvens ved feil. 

Hva skjer dersom en agent med tilsvarende tilgang kan endre settpunkter eller tidsprogrammer, kvittere alarmer eller sende kommandoer til tekniske anlegg? 

Det var ikke det som skjedde hos KLP. 

Men KLP-eksemplet viser hvorfor vi bør stille disse spørsmålene før det skjer et annet sted. 

Det betyr ikke at AI-agenter aldri bør få slike rettigheter. Men terskelen for autonom handling må stå i forhold til konsekvensen dersom agenten tar feil. 

Prinsippet om minste privilegium bør derfor være utgangspunktet. En agent skal ha de konkrete rettighetene som er nødvendige for oppgaven – og ikke mer. 

Men minste privilegium løser bare halve problemet. 

Det forteller oss hva agenten får lov til å gjøre. 

Vi må også vite hva vi gjør når den allerede har gjort noe den ikke burde. 

Har agenten en angreknapp? 

En agent kan utføre mange handlinger på svært kort tid. Dersom den først har misforstått oppgaven, datagrunnlaget eller miljøet den arbeider i, kan én feil beslutning bli til mange feil handlinger før noen rekker å reagere. 

Da holder det ikke bare å kunne stoppe agenten. Vi må også vite hva den har gjort. 

Handlingene må kunne spores. Endringer må kunne identifiseres. Og der det er mulig, bør de kunne reverseres. 

Kall det gjerne en angreknapp. 

Teknisk kan det handle om logging, versjonering, godkjenningsmekanismer, rollback eller muligheten til raskt å trekke tilbake tilganger. 

Prinsippet er viktigere enn begrepet: 

Når digitale tjenester får større handlingsrom, må vi ikke bare kontrollere hva de får gjøre. Vi må også kunne håndtere konsekvensene når de gjør feil. 

En feil i ett system trenger heller ikke lenger å bli værende der. En agent kan lese informasjon fra ett system, trekke en feil konklusjon og utføre handlinger i et annet. 

Jo flere systemer den får påvirke, desto større blir konsekvensradiusen. 

Den egentlige diskusjonen 

Debatten om fremtidens bygg har brukt mye tid på spørsmålet om vi kan skrote SD-anlegget. 

Samtidig har mye av den faglige diskusjonen allerede landet på at lokal grunnstyring kan bestå selv om visualisering, analyse og overordnede funksjoner flyttes eller erstattes. 

Likevel består et grunnleggende problem: 

Vi bruker fortsatt begrepet SD-anlegg om svært forskjellige ting. 

For noen betyr det brukergrensesnittet. For andre betyr det toppsystemet. For andre igjen omfatter begrepet store deler av automasjonsarkitekturen. 

Da blir også påstanden om å «droppe SD-anlegget» tilsvarende uklar. 

Derfor bør vi stille et mer presist spørsmål: 

Hvilke funksjoner flytter vi, hvilke avhengigheter introduserer vi – og hvilken myndighet gir vi teknologien? 

Det siste blir særlig viktig når AI går fra å analysere til å handle. 

Da er ikke spørsmålet lenger bare om analysen er god. Det handler om hvilke systemer agenten kan påvirke, hvilke handlinger den kan utføre og hvor langt konsekvensene kan spre seg dersom den tar feil. 

KLP-eksemplet er interessant nettopp fordi konsekvensene denne gangen var begrensede. Agenten gjorde reelle endringer i et produksjonsmiljø gjennom en API-nøkkel med omfattende rettigheter, selv om hensikten var å arbeide i et testmiljø. 

Det gikk ikke utover reguleringen av et ventilasjonsaggregat eller en varmesentral. 

Men neste gang vet vi ikke hvilket system som ligger på den andre siden av API-et. 

Det er derfor vi bør stille spørsmålene nå. 

Dette er ikke et argument mot PropTech, sky eller kunstig intelligens. Vi bør utfordre proprietære løsninger, åpne dataene våre og bruke ny teknologi der den gir verdi. 

Men vi bør slutte å diskutere teknologien som om valget står mellom gammelt og nytt. 

Under plattformene, API-ene, analyseverktøyene og AI-agentene finnes fortsatt den samme fysiske virkeligheten. 

Temperatur skal reguleres. Luft skal flyttes. Vann skal sirkulere. Tekniske anlegg skal håndtere at kommunikasjon forsvinner, tjenester feiler og analyser tar feil. 

Teknologien kan endres. Plattformene kan erstattes. Arkitekturen kan moderniseres. 

Men jo mer myndighet vi gir teknologien, desto viktigere blir det å forstå hva som skjer når den tar feil. 

Det ansvaret kan ikke digitaliseres bort.