Automatisering som sier fra når den knekker

Hva vi faktisk har bygget

Per 15. august 2026 har vi 278 scenarioer i plattformen vår, hvorav 198 er aktive.

Det er verdt å si hva det tallet ikke betyr. Det er ikke 278 kunder, og ikke 278 leveranser. Flere av dem hører til samme kjede, og en god del er bygget for våre egne prosjekter. Tabellen under grupperer dem etter hva de gjør, ikke etter hvilket prosjekt de tilhører — det siste er en opplysning om oss, ikke om hva vi kan.

En tidligere versjon av denne siden trakk fra «rene diagnoseverktøy» og oppga et lavere tall. Vi fant ikke igjen den avgrensningen i dataene — bare 12 av 278 scenarionavn inneholder diag, test, probe eller scratch — så fratrekket er fjernet i stedet for justert. Et tall vi ikke kan regne ut på nytt, har ingenting på en nettside å gjøre.

De fire tingene vi bygger oftest

1. Hente data som ikke ligger klart

Priser fra en konkurrent, produkter fra en PDF-katalog, kampanjer fra en kjedeavis. Data som finnes, men ikke i et format noen kan bruke. Vi har beskrevet hvordan dette faktisk går for seg — inkludert veiene som ikke førte fram — i artikkelen om å hente produktdata fra en nettside, og i den om produktdata ut av PDF-kataloger.

2. Overvåke noe som endrer seg

En leverandørside som får nye priser. Et register som oppdateres. En konkurrent som legger ut noe nytt. Poenget med overvåkning er ikke å hente alt hver gang, men å oppdage forskjellen — og bare varsle når det faktisk er en forskjell.

3. Verifisere mot en kilde

Et navn skal bli et organisasjonsnummer. En påstand skal sjekkes mot en kilde. Vi bygger dette som en port: forslaget går ikke videre før det er kontrollert, og kommer det ikke gjennom, sier systemet «funnet: nei» i stedet for å gjette.

4. AI der AI faktisk hjelper

Vi bruker språkmodeller til å lese, sortere og foreslå — ikke til å avgjøre. Der resultatet går ut til en kunde, går det gjennom en kontroll først. Vi har bygget kryssleverandør-dømming for det: teksten skrives av én modell og bedømmes av en annen fra en annen leverandør.

Og her er en ærlig detalj vi like gjerne kan si selv: den porten går bare når begge leverandørene svarer. Er forhåndsbetalt kreditt tom hos den ene, faller kontrollen tilbake til én leverandør — og da er den svakere enn den ser ut i et diagram. Derfor skal en slik port feile lukket og si fra, ikke stå åpen i stillhet.

Det er ikke en garanti. Vi har sett dommeren finne en ekte feil vi hadde oversett, og vi har sett dommeren regne riktig og deretter underkjenne sitt eget svar. Begge deler står beskrevet i artikkelen om hva du gjør når to modeller er uenige.

Her er grensen vår: vi selger ikke AI-produsert innhold som går rett ut uten at et menneske har lest det. Har du hørt at det er mulig, har du hørt fra noen som ikke har fått regningen for det ennå.

Slik jobber vi

1. Vi ser på oppgaven manuelt først

Hvis vi ikke kan gjøre den for hånd, kan vi ikke automatisere den. Første steg er alltid å gjøre jobben én gang selv, for å finne ut hvor unntakene er.

2. Vi bygger det minste som virker

Ett scenario som gjør én ting. Det er lettere å finne feilen i noe lite, og lettere for deg å se hva du betaler for.

3. Vi bygger inn stoppunktene

Hva skal skje når kilden er nede? Når svaret er tomt? Når det ser riktig ut, men er feil? Dette er den delen som tar tid, og det er den delen som avgjør om automatiseringen er verdt å ha. Vi har skrevet om hva som skjer når automatiseringen går i stå og om de fellene vi selv har gått i.

4. Du får den overlevert

Scenarioene ligger i din konto. Du kan se hver kjøring, hvert steg og hver feilmelding selv.

Hva vi ikke lover

Vi lover ikke at automatiseringen sparer deg et bestemt antall timer. Det tallet avhenger av hvordan dere jobber i dag, og vi har ikke målt det hos deg. Vi lover heller ikke at den aldri knekker — kilder endrer seg, og alt som er avhengig av noen andres system, arver deres endringer.

Vi lover at den sier fra når den knekker, i stedet for å levere tomme svar videre.