En AI- og dataplattform er en plattform, ikke to prosjekter
AI og dataplattform
AI trenger kontekst. Ikke en lengre prompt, men en modell av driften: hvilke anleggsdeler som finnes, hvordan de henger sammen, og hva hver måling betyr. Den konteksten ligger i en kunnskapsgraf. Har dere en? Eller må dere bygge en? Uansett er dataplattformen stedet den bygges, og AI er grunnen til at det endelig er verdt å bygge den.
To halvdeler av en jobb, og ingen av dem virker alene
AI uten dataplattformen
En agent svarer ut fra det den når. Pek den mot fire systemer med fire stavemåter av samme pumpe, og den velger en, med stor selvtillit. Demoen imponerer, og det tredje svaret er feil.
Dataplattformen uten AI
Ti år med målinger, ryddig lagret, er et arkiv. Spørsmålene står fortsatt i kø bak den ene ingeniøren som vet hvilken kobling som må skrives, og de fleste av dem blir aldri stilt.
En plattform, ett bilde
Modellen ingeniørene deres ser, er modellen agentene leser, gjennom samme dør og under samme regler. Hvert svar, fra begge, kan vise hvor det kom fra.
Datahalvdelen
Alt driften produserer, i en modell
Tidsserier, hendelser, dokumenter og postene i forretningssystemene beskriver alle det samme anlegget, og i dag beskriver de det med ulike ord. Den operasjonelle dataplattformen kopierer dem ut over standardprotokoller, uten å røre systemene de kom fra, og legger dem inn mot en modell av driften: hvilken anleggsdel, hvilken prosess, hvilket øyeblikk. Å få dataene inn pleide å være den dyre delen. Det er det ikke lenger.
En agent kan ikke ha mer rett enn dataene den fikk.
Konteksten
Modellen er det agenten faktisk leser
Den som leser en trend, vet allerede at TT-1183 sitter på utløpet av P-204, og at P-204 mater linje 3. En agent vet ingenting av dette med mindre det er skrevet ned. AI trenger kontekst, og konteksten ligger i kunnskapsgrafen deres: hvert signal, hver hendelse og hvert dokument festet til anleggsdelen det beskriver, og anleggsdelene koblet til hverandre slik anlegget faktisk henger sammen. Et spørsmål følger reelle relasjoner, så svaret kommer med veien dit, og veien er resonnementet.
Anleggsdeler, ikke tagger
Agenten spør om en pumpe, ikke om et taggnavn. Modellen vet hvilke signaler som hører til den, i hvilke enheter, og hvilken av de fire stavemåtene som er den riktige.
Relasjoner, ikke koblinger
Oppstrøms, nedstrøms, del av, målt av. Relasjonene finnes før spørsmålet stilles, så svaret er en vandring, ikke en kobling over fem tabeller som bare en person kan skrive.
Kvittering på hvert svar
Hvert svar kan spores tilbake gjennom modellen til råsignalene det kom fra, med kvalitetsflaggene intakt. Revisoren og ingeniørene deres ser samme spor.
AI trenger kontekst. Konteksten ligger i kunnskapsgrafen deres.
Spørsmålet å stille først
Har dere en kunnskapsgraf? Eller må dere bygge en?
Enhver AI-plan for et anlegg koker ned til dette spørsmålet, og det stilles sjelden høyt. Grafen er der konteksten ligger, så den som svarer på det, avgjør hvor langt agentene kan se. Det finnes tre ærlige svar, og ingen av dem er en blindvei.
Dere har en
Ta den med. Plattformens modell er en ontologi og en graf, så en eksisterende graf legges inn i den i stedet for å bygges på nytt, og agentene leser den via MCP fra første dag. Det som som regel trenger arbeid, er å holde den oppdatert, og det gjør flytene etter hvert som dataene lander.
Dere må bygge en
Begynn med det som allerede finnes: tagglisten, anleggshierarkiet i ERP-systemet, P&ID-ene, navnekonvensjonen alle følger halvveis. Plattformen bygger grafen etter hvert som dataene frigjøres inn i den, og agentene lager utkast til relasjonene som et menneske så bekrefter. Det er uker med modellering, ikke en migrering.
Dere er ikke sikre
Da har dere deler av en: et vedlikeholdshierarki, et regneark noen holder i orden, et dokumentarkiv med en mappe per enhet. Det er en start, ikke et hull. Product Discovery finner hvilke deler den første agenten trenger, og modellerer bare dem.
Dere trenger ikke hele anlegget modellert. Dere trenger den delen den første oppgaven berører.
AI-halvdelen
Agentene kobler seg på via MCP, under deres regler
Plattformen snakker MCP, den åpne standarden AI-assistenter bruker for å nå systemene rundt seg, så assistenten teamet allerede bruker, en agent dere bygger med SDK-ene, eller en vi bygger sammen med dere, kobler seg på på samme måte. Hver forespørsel bærer identiteten bak den, menneske eller agent, og policyer avgjør hva den identiteten får lese, hva den får endre og hvor den må stoppe og spørre. Agenten ser nøyaktig det personen den jobber for får se, og et avslag logges på samme måte som et svar.
En dør for mennesker og agenter. Bytt modelleverandør i morgen; ingenting annet endres.
Det den gjør hele dagen
Fra spørsmål til arbeidsordre, med et menneske i sløyfen
Arbeidet agentene tar over først, er det som gjentar seg: samme tall slått opp, samme post flyttet mellom systemer, samme rapport skrevet hver mandag. Med modellen leser agenten forespørselen, finner det den trenger og lager utkast til svaret, rapporten eller arbeidsordren. Et menneske godkjenner. Alt som endrer en post eller flytter penger, venter på godkjenning, og det agenten skrev, lander med opphav festet til seg, så arbeidet kan gjennomgås som en kollegas og reverseres når gjennomgangen sier nei. Product Discovery er måten vi finner den første oppgaven som er verdt å gi fra seg.
Den lager utkast, et menneske bestemmer
Godkjenningsporter står foran alt som endrer en post, sender en melding eller flytter penger. Agentens fart ligger i utkastet; skjønnet blir hos folkene deres.
Repeterende arbeid først
Oppslag, avstemminger, skiftrapporter, det tiende svaret på samme spørsmål denne måneden. Kjedelig med vilje: det er der timene ligger, og der en agent kan etterprøves.
Reversibelt fra starten
Alt en agent skriver, bærer med seg hvem som skrev det og hva det bygde på. Når en gjennomgang sier nei, blir endringen gjort om i stedet for diskutert.
Der den kjører
På deres servere, i vårt datasenter, eller i et lukket nett
Konteksten agentene deres jobber ut fra, er den mest sensitive beskrivelsen av driften som finnes. Den trenger ikke forlate miljøet deres. Plattformen er åpen kildekode under AGPL-3.0, kjører på maskinvare dere allerede eier, og når dere heller ikke vil drifte den selv, kjører vi den på maskinvare vi eier i Stavanger, under norsk lov. Det tekniske bildet sier nøyaktig hva den er bygget av.
Selvdriftet
Deres sky, deres servere eller et nett uten internettilgang. Koden er deres å lese under AGPL-3.0, og driftsbelastningen er reell og sagt rett ut på forhånd.
Driftet av oss, i Norge
Maskinvare vi eier og opererer i Stavanger, underlagt norsk lov. Ingen global skyleverandør i kjeden, og ingen jurisdiksjon dere ikke selv har valgt.
Hvilken som helst modelleverandør
MCP er en åpen standard, så assistenten og modellen bak den er deres å velge og å bytte. Plattformen holder konteksten; modellen er en leverandør.
Etter bransje
Samme plattform, spurt bransje for bransje
Argumentet over er generelt. Spørsmålene er det ikke: en pumpe, et fartøy, en merd, en rampe, et kulelager og en turbin har hver sine data, sitt eget vokabular og sin egen første oppgave som er verdt å gi til en agent. Hver side under svarer på spørsmålet slik den bransjen stiller det, og sier rett ut hvor AI ikke hjelper ennå.
Olje og gass
Prosessdata, arbeidsordrer, inspeksjonsrapporter og daglige rapporter, gått gjennom som en modell av anlegget.
Les svaretMaritim næring
Fartøytelemetri, middagsrapporter, vedlikehold og klassedokumentasjon på tvers av flåten, med opphav på hvert tall.
Les svaretOppdrett
Merdsensorer, fôringslogger, registre og utstyret på fôrflåten for hver lokalitet, i en modell en rapport kan skrives fra.
Les svaretLager og transport
Lager- og transportdata, telematikk og rampehendelser, slik at et avvik forklarer seg selv før en planlegger ser på det.
Les svaretMaskiningeniører
Tegninger, vedlikeholdshistorikk og tilstandsovervåking for utstyret du har ansvar for, spurt med vanlige ord.
Les svaretEnergibransjen
Signaler fra aggregater, transformatorer og stasjoner, tilsig og vær, utfallsrapporter og rapportering, i en modell av kraftverket og nettet.
Les svaretHva en AI- og dataplattform ikke er
Det er ikke en chatbot skrudd fast på et dashbord, og det er ikke en erstatning for kontrollsystemene eller prosessdatabasen, som skal bli nøyaktig der de er. Det er laget over dem som sier hva en anleggsdel er, hvordan målingene henger sammen med den, og hvem som får se hva. Å legge til det laget er mindre enn en migrering, og i motsetning til en migrering kan det gjøres om. Der modellen har hull, finner agenten dem først, og det er det nyttigste den gjør den første måneden.
Vanlige spørsmål
Spurt og besvart
Hva er en AI- og dataplattform?
En plattform som lagrer driftens tidsserier, hendelser, dokumenter og forretningsposter mot en sammenhengende modell av anleggsdeler og prosesser, og gir AI-agenter styrt tilgang til den modellen gjennom en åpen standard som MCP. Datahalvdelen gjør AI-en til å stole på; AI-halvdelen er grunnen til at dataene endelig blir brukt.
Hvorfor trenger en AI-agent en dataplattform?
Fordi AI trenger kontekst, og en agent ikke er bedre enn det den kan se. Pekt mot råsystemer må den gjette hvilken av flere anleggslister som er den riktige, hvilken enhet en måling er i og hvilken pumpe en tagg viser til, og den gjetter med stor selvtillit. En dataplattform holder den konteksten som en vedlikeholdt kunnskapsgraf, så agenten slår opp i stedet.
Kan vi bruke vår egen AI-assistent eller modelleverandør?
Ja. Plattformen snakker MCP, den åpne standarden AI-assistenter bruker for å nå eksterne systemer, så assistenten teamet allerede bruker kobler seg rett på, og agenter dere bygger med SDK-ene kobler seg på på samme måte. Fordi det er en standard, kan modelleverandøren byttes uten å bygge om noe.
Forlater driftsdataene våre miljøet vårt?
Det trenger de ikke. Plattformen er åpen kildekode under AGPL-3.0 og kjører i deres sky, på deres egne servere eller i et lukket nett. Vil dere heller slippe å drifte den, kjører vi den på maskinvare vi eier i Stavanger, under norsk lov, uten noen global skyleverandør i kjeden.
Må vi ha en kunnskapsgraf før vi kan bruke AI-agenter?
Dere trenger den delen av en som den første oppgaven berører, ikke hele anlegget. Finnes det en graf, legges den inn i plattformens modell, og agentene leser den fra første dag. Hvis ikke, bygger plattformen den etter hvert som dataene frigjøres inn, med utgangspunkt i tagglisten, anleggshierarkiet og navnekonvensjonene dere allerede har, der agentene lager utkast til relasjoner og et menneske bekrefter dem. Product Discovery er et to ukers oppdrag bygget for å finne den første oppgaven og den delen av grafen den trenger.
Begynn med oppgaven, ikke plattformen
Fortell oss hvilken jobb dere ville gitt fra dere først, og hva den kjører på i dag. Vi sier ærlig fra om en agent kan gjøre den nå, og hvordan dataene må se ut før den kan.