Når AI blir blokkert: svaret ble tomt, og ingen merket det

En rapportjobb hos oss — bygget av oss, drevet av AI, overvåket av oss — leverte tomme resultater i lang tid før noen oppdaget det.

Den kjørte som den skulle. Den svarte hver gang. Ingen feilmelding, ingen rød logg, ingen varsling. Rapporten kom, og den var tom, og en tom rapport ser ut som et stille marked.

Da vi til slutt gravde i den, var det ikke én feil, men tre som lå oppå hverandre: den spurte om en periode som var hardkodet inn og hadde løpt fra oss, den rapporterte et tegn-antall som om det var et antall rader, og den pekte på feil domene av to vi eier.

Ingen av de tre er avanserte feil. Alle tre er usynlige.

Det er denne artikkelen: hva som skjer når en automatisering møter en vegg, og hvorfor den som er dårligst på å si fra, gjør mest skade.

---

Har dere en jobb som «går fint» uten at noen sjekker? Vi ser gjerne over den. Be om en gjennomgang — du får svaret uansett. Vil du høre historiene først, les videre.

Slik vurderer vi hendelsene under

Alt som står under er ting vi har gått i selv. Ikke eksempler fra en lærebok, ikke andres havarirapporter.

Vi driver en del automatisering for egen regning — innholdsproduksjon, datainnhenting, verifisering — og det har den fordelen at vi får ta konsekvensene av våre egne snarveier før en kunde gjør det. De fire hendelsene lenger nede er hentet derfra.

Hva du bør vekte dette som:

• Fire hendelser er fire hendelser. Det er ikke en studie, og vi presenterer det ikke som et representativt utvalg
• Systemene er våre egne. Vi kan derfor si nøyaktig hva som skjedde, men vi kan ikke påstå at det er slik hos alle
• Vi er ikke nøytrale. Vi selger automatisering. Artikkelen argumenterer likevel for å bygge inn flere steder der maskinen stopper — noe som gjør leveransene våre langsommere og kjedeligere, ikke mer imponerende
• Ingen av feilene under ble oppdaget av systemet selv. Alle ble oppdaget av en person som ble mistenksom

Det siste punktet er egentlig hele artikkelen.

Metodene endrer seg, og modellene bak dem enda raskere. Artikkelen gjennomgås derfor på nytt når metodene eller modellene endrer seg. Sist gjennomgått 14. august 2026.

Skrevet av Svein Tore Olsen, daglig leder i Ebizapple.

---

Problemet er ikke at maskinen tar feil

La oss slå fast noe med en gang, for det er lett å lese denne artikkelen som en advarsel mot AI. Det er den ikke.

En automatisering som feiler høylytt er et lite problem. Den stopper, noen får beskjed, noen fikser den. Kostnaden er tiden det tok.

En automatisering som feiler stille er et helt annet dyr. Den fortsetter å levere. En AI blokkert av en kvotegrense, en endret kilde eller en manglende tilgang leverer tomme eller gale svar med nøyaktig samme selvtillit som riktige — i samme format, til samme tid. Og fordi den fortsetter, bygger det seg opp beslutninger på toppen av den.

Skillet er ikke mellom riktig og galt. Skillet går mellom systemer som vet at de er blokkert, og systemer som ikke vet det.

Det er også der de praktiske grenser for kunstig intelligens går. Ikke i hva modellen kan resonnere seg frem til, men i om systemet rundt den oppdager at forutsetningene har røket.

Et system som kan si «jeg vet ikke» er mer verdt enn ett som alltid svarer. Det er en ubehagelig påstand å selge inn, fordi den som alltid svarer demonstrerer bedre.

---

Fire ganger vi ble lurt av vårt eget system

1. Rapporten som var tom, og så riktig ut

Den vi startet med. Tre feil på én gang:

Hardkodede datoer. Jobben ba om et tidsrom som var skrevet inn med faste datoer da den ble laget. Den var riktig den dagen. Etter noen uker spurte den om en periode som lå bak oss, og fikk høflig svar om at det ikke var noe der. Ingen feil — bare ingen data. Rettelsen var å regne datoene ut fra dagens dato hver gang jobben kjører, slik at vinduet flytter seg av seg selv.

Et tegn-antall som utga seg for å være et rad-antall. Et sted i kjeden ble radene slått sammen til én tekstblokk. Å måle lengden på den blokken gir antall tegn. Tallet så helt rimelig ut, og det er det verste med det. Et tall som er hundre ganger for stort blir oppdaget. Et tall som er plausibelt, blir stående.

Feil domene. Vi eier to nettsteder med nesten samme navn. Jobben hentet tall fra det ene, mens arbeidet foregikk på det andre. Ett tegn i en adresse.

Ingen av de tre utløste en feilmelding, fordi ingen av dem er feil teknisk sett. Å spørre om en tom periode er et lovlig spørsmål. Å telle tegn er en lovlig operasjon. Å be om data for et domene du faktisk eier er lovlig. Systemet gjorde nøyaktig som det ble bedt om.

Lærdommen: en jobb som kan returnere ingenting, må skille mellom «ingenting skjedde» og «jeg fikk ikke tak i noe». Det er to helt ulike tilstander som ser identiske ut i en tom rapport.

2. Porten som sluttet å dømme

Vi har en verifiseringsport som skal kontrollere innhold før det publiseres. Den ba to uavhengige AI-modeller fra to ulike leverandører vurdere det samme, og krevde at begge var enige før noe gikk gjennom.

Så tok forhåndsbetalingen hos den ene leverandøren slutt. Kallet svarte med [429] Your prepayment credits are depleted.

Det var en høylytt feil, isolert sett. Kjøringene stoppet. Problemet var at ingenting nedstrøms ropte: produksjonen ga null resultater, og null resultater utløste ingen alarm. Det gikk drøye døgnet før noen så at det hadde stått stille.

Verre var det som skjedde da vi bygde en reserveløsning. Første forsøk brukte en feilhåndtering som ganske enkelt ignorerer feilen. Den ble godtatt uten protest — og droppet hele arbeidspakken, slik at alt som skulle skjedd etterpå aldri kjørte. Resultatet var en kjøring som rapporterte suksess og ikke hadde gjort noe som helst.

Vi byttet til en variant som lar kjeden fortsette med tomt svar fra den døde modulen, og lot porten falle tilbake på én dommer i stedet for to — med et spor i loggen som sier at det var det som skjedde.

Lærdommen: en degradert port er ikke det samme som en åpen port, men den blir det hvis ingen får vite at den er degradert. Skriv degraderingen inn i resultatet, ikke bare i loggen.

3. Dommeren som motsa sin egen mellomregning

Denne er den merkeligste, og den er verdt å bruke tid på.

En AI-dommer skulle kontrollere regnestykkene i en artikkel vi hadde skrevet. Ett av dem var en forskjell på 39,75 kroner per ordre, ganget med 1 200 ordrer i året.

Dommeren regnet det ut: 47 700.

Deretter erklærte den at 47 700 var feil.

Den motsa altså sin egen mellomregning, i samme svar, uten å registrere motsetningen. Og den gjorde det med samme rolige tone som når den har rett.

Dette er ikke et argument for at modeller er ubrukelige til kontroll. Vi bruker dem fortsatt til nettopp det. Det er et argument for hvordan man bruker dem:

• Regnestykker skal ikke dømmes av en språkmodell. De skal regnes ut av kode, og sammenlignes tall mot tall.
• En dommer skal ikke sitte alene. To uavhengige modeller som er enige, er et helt annet signal enn én som er sikker.
• Uenighet skal flagges, ikke midles. Der to dommere er uenige, ligger som regel den interessante saken. Å ta gjennomsnittet av dem er å kaste bort informasjonen.
• Slå av tilfeldigheten der du kan. Vi oppdaget at samme spørsmål kunne gi to avvisninger og en godkjenning på tre forsøk. En dommer som ikke gir samme svar på samme input, er ikke en port. Den er en terning.

4. Måleinstrumentet som var i stykker

Den siste er min favoritt, fordi den er så pinlig.

Vi kjørte et revisjonsskript over en samling artikler for å sjekke strukturen deres. Skriptet rapporterte «h1: 4» for hver eneste artikkel — fire hovedoverskrifter i hvert dokument, der det skal være nøyaktig én.

Fire, hver gang, i alle filene. Vi begynte å lure på hva slags mal som hadde produsert det.

Feilen lå i skriptet. Det skilte dokumentets metadata fra brødteksten på en litt for enkel måte, og fanget derfor opp kommentarlinjene i metadataen som om de var overskrifter. Det var nøyaktig fire slike kommentarer i hver fil.

Artiklene var riktige hele veien. Det var måleren som var i stykker.

Lærdommen, og den generaliserer bredt: når et måleresultat er identisk på tvers av alle enheter du måler, er den vanligste forklaringen at du måler måleren. Ekte data varierer. Perfekt konsistens er et varselsignal, ikke et kvalitetstegn.

---

Vil dere vite om deres egne jobber sier fra når de svikter? Vi går gjennom oppsettet og peker på de stille punktene. Bestill en gjennomgang.

---

Hvorfor stille feil overlever så lenge

Fire hendelser, ett mønster: ingen av dem brøt noen regel.

Det er dette som gjør stille feil seiglivet. En automatisering er bygget av lovlige operasjoner. Å hente en tom periode, telle tegn, spørre feil domene, ignorere en feil, godta én dommers svar — alt sammen er handlinger systemet er ment å kunne gjøre. Ingenting krasjer, fordi ingenting er ulovlig.

Og så kommer det som forsterker alt: overvåkingen ser som regel etter feil, ikke etter fravær.

En typisk oppfølging spør «har noe feilet?». Den spør sjelden «har det kommet noe?». En jobb som kjører hver natt og produserer null rader hver natt, ser i loggen ut som en jobb som kjører fint.

De to nederste radene er dyre. Det er der beslutninger tas på feil grunnlag, og det er der ingen leter, fordi ingenting ser galt ut.

---

Slik bygger vi stoppunkter, ikke bare flyt

En automatisering tegnes som en flyt: dette skjer, så dette, så dette. Det er den tegningen som er problemet. Den har ingen naturlig plass til «og her stopper vi og spør».

Vi bygger derfor stoppunkt inn som en egen del av jobben, ikke som noe man legger på etterpå. Fire varianter dekker det meste:

Terskelen. Et resultat under et visst nivå går ikke videre. Null rader er ikke en gyldig leveranse — det er en hendelse som skal varsles. Det samme gjelder mistenkelig runde tall og resultater som er identiske med gårsdagens.

Konfidensen. Alt maskinen produserer får et nivå festet på seg, og lav konfidens rutes til gjennomgang i stedet for videre i kjeden. Vi gjør det samme i uttrekk fra kataloger og prislister, beskrevet i gjennomgangen av PDF-katalog og bildematching: hvert produkt får et konfidensnivå og lander i en liste merket «til gjennomgang», ikke rett inn i systemet.

Uenigheten. To uavhengige vurderinger av det samme. Er de enige, går det videre. Er de uenige, stopper det og blir sett på av et menneske. Det er den eneste porten vi har som fanger feil begge modellene ikke gjør samtidig.

Det harde svaret. Der det er mulig, skal det uskarpe ende i noe som kan slås opp. Et organisasjonsnummer, et artikkelnummer, en HTTP-status. Å bekrefte at en side svarer 200 er en billigere og bedre sjekk enn å be en modell vurdere om lenken virker.

Og over alle fire, den regelen vi bruker mest: et resultat skal bære med seg hvordan det ble til. Ble den ene dommeren hoppet over? Ble bildekoblingen gjettet? Da skal det stå i raden, ikke i en logg ingen åpner.

---

Der mennesket legger brikken

Nå til den delen som er lettest å underselge, fordi den ikke ser ut som teknologi.

Vi kartla en gang en produktkatalog og prøvde å fremkalle en bestemt nettverksforespørsel automatisk. Nettstedet blokkerte den automatiske nettleseren vår. Vi kom ikke videre — det er beskrevet i sin helhet i gjennomgangen av de fem veiene og de fire blindveiene.

Kunden åpnet nettverksfanen i sin egen nettleser, bladde på siden, og limte inn forespørselen som faktisk gikk ut. Ett minutt.

Det er ikke en historie om at automatisering er overvurdert. Det er en historie om arbeidsdeling. Maskinen hadde gjort de nittini prosentene som var kjedelige og tok tid. Mennesket gjorde den ene tingen maskinen fysisk ikke kom til.

Problemet er ikke at det finnes slike punkter. Problemet er når systemet ikke vet at det står ved ett. Da lager det et svar i stedet, og et svar laget for å fylle et hull ser akkurat ut som et svar hentet fra en kilde.

Så det vi bygger etter nå:

1. Maskinen tar volumet. Alt som er repetitivt, målbart og kjedelig.
2. Maskinen stopper ved reell blokkering. Ikke gjetter, ikke improviserer, ikke leverer noe som ligner.
3. Mennesket tar de få tingene igjen. Med usikkerheten synlig, slik at oppmerksomheten går dit den hører hjemme.

Det er ikke en nødløsning i påvente av bedre modeller. Det er arbeidsdelingen, og den er verdt å designe med vilje.

---

Skal du automatisere dette?

Under står regelen vi bruker selv, før vi bygger noe som skal kjøre uten tilsyn. Flere av radene ender i «ikke automatiser det». De er med nettopp derfor.

Legg merke til den nest siste raden. Den er ikke ment som en spissformulering. Den er den vanligste grunnen til at vi anbefaler folk å la være.

---

Det korte svaret

Om du bare skal ta med deg én ting:

Bygg systemer som kan si «jeg vet ikke».

Det er ikke det samme som å bygge systemer som er forsiktige. En forsiktig automatisering gjør lite. En automatisering med stoppunkter gjør mye — og slutter å gjøre det i det øyeblikket forutsetningene ryker, høyt nok til at noen hører det.

Det høres ut som en teknisk detalj. Det er en holdning, og den er gjenkjennelig i alt vi bygger: fra hvordan vi setter opp dynamiske nettsider med en datakilde bak, til hvorfor vi bygger komponenter før sider og hvorfor vi ikke lover en ytelsesscore vi ikke kontrollerer.

Den dyreste feilen er sjelden den som stopper alt. Det er den som fortsetter.

---

Spørsmål om automatisering som stopper

Hvorfor merker ingen at en automatisering har stoppet?

Fordi overvåking som regel ser etter feil, ikke etter fravær. En jobb som kjører hver natt og produserer null rader, ser i loggen ut som en jobb som kjører fint. Løsningen er å varsle på et tomt resultat, ikke bare på en feilmelding.

Kan man stole på at en AI sier fra når den tar feil?

Nei, ikke alene. En AI blokkert av noe utenfor seg selv merker det sjelden. Vi har sett en dommer regne ut et riktig svar og deretter erklære at det var feil, i samme svar. Vi har også sett samme spørsmål gi ulikt utfall på gjentatte forsøk. Bruk to uavhengige modeller, flagg uenighet i stedet for å midle den, og legg regnestykker til kode.

Hva er et stoppunkt i en automatisering?

Et sted der jobben med vilje nekter å gå videre: for få resultater, for lav konfidens, uenighet mellom to kontroller, eller en verdi som ikke lar seg slå opp. Poenget er at det er bygget inn på forhånd, ikke lagt til etter at noe gikk galt.

Bør et menneske godkjenne det AI-en gjør?

Ikke alt — det ville fjerne gevinsten. Men grensetilfellene, ja. En fagperson som får seksti flaggede rader i stedet for tusen sider, bruker oppmerksomheten der den betyr noe. Det er arbeidsdeling, ikke mistillit.

Blir det ikke bare tregere med mennesker inni?

Litt tregere, ja. Sammenlign likevel med alternativet: en jobb som leverte tomt i ukevis før noen så det. Tiden du sparer på å droppe kontrollpunkter, betaler du tilbake med renter den dagen noe har vært galt lenge.

Hvordan oppdager man at måleinstrumentet er ødelagt?

Se etter mistenkelig perfekt konsistens. Får alle enhetene nøyaktig samme resultat, er den vanligste forklaringen at du måler måleren og ikke enhetene. Ekte data varierer alltid litt.

---

Videre lesing om automatisering som stopper

• Fem feller i Make — de samme stille feilene, sett fra scenarioets side
• Fem sider het «start her» — en agent åpner hver økt fra null, og avslører dermed hva strukturen forutsetter
• Når to AI-modeller er uenige — uenighet som stoppunkt i stedet for støy
• Produktdata ut av en PDF-katalog — konfidensnivå, bildematching og kø til gjennomgang
• Hente produktdata fra en nettside — der mennesket løste på ett minutt det maskinen ikke kom til
• Hvorfor vi ikke lover deg en score på 99 — om løfter som avhenger av andre
• Nivågradering av kataloger: N1 til N5 — anslå vanskelighetsgraden før du bygger
• Betalingsløsning for nettbutikk — der stille feil koster penger direkte
• PayPal, Stripe og kort i WooCommerce — hvorfor webhooks må verifiseres
• Én mal, ett datasett, én port — porten som verken publiserer eller skryter
• Automatisering av arbeidsprosesser — hva vi faktisk bygger
• WordPress-nettsider — grunnmuren under det hele
• Alle artikler i bloggen

Har dere jobber som kjører uten at noen egentlig sjekker dem? Vi går gjerne gjennom oppsettet og peker på de stille punktene — ta kontakt, eller les om automatisering og dynamiske nettsider.