Gemini 4 Carbon: tallene og din egen test

Nøkkelpunkter per 29. oktober 2026:

Ingen vellykkede angrep på Gray Swan sin benchmark for indirekte prompt-injeksjon, der forgjengeren Argon slapp en liten, målbar andel gjennom (Google DeepMind, 2026).
Prisen etter introduksjonsperioden er 4 dollar per million input-tokens og 20 dollar per million output-tokens, med 95 prosent rabatt på cachede input (Google DeepMind, 2026).
Ingen leverandør vant alle fem tester da over 200 modeller ble målt i årets første kvartal, og ulike modeller ledet ulike oppgaver (layerlens.ai, 2026).
Utgivelsestakten doblet seg til 12 eller flere substansielle frontutgivelser i Q1 2026 mot 6 i kvartalet før, og presser modellvurdering ned på fire uker (digitalapplied.com, 2026).
Selvattestering holder ikke for høyrisikosystemer i Annex III: samsvarsvurdering skal gjøres av teknisk kontrollorgan etter Artikkel 43 (EU-kommisjonen).

Hva Gemini 4 Carbon er og hva Google har sagt

Google DeepMind presenterer Gemini 4 Carbon som selskapets sterkeste modell, med det de selv beskriver som state-of-the-art cybersikkerhet og langhorisont-kapabiliteter (Google DeepMind, 2026). Lanseringen skiller seg fra en vanlig modelloppdatering på to punkter. Tilgangen er begrenset fra start, og hovedargumentet er sikkerhet snarere enn generell intelligens. Det er en annen type salgsargument enn vi har sett på de fleste frontiermodeller de siste to årene.

For en norsk SMB som allerede bruker en frontiermodell til kundeservice, kodegenerering eller dokumentflyt, er spørsmålet ikke om tallene ser bra ut. De gjør de. Spørsmålet er om de sier noe presist om hvordan modellen oppfører seg i din drift, med dine data, dine integrasjoner og dine feilkostnader. Denne artikkelen går først gjennom hvert tall Google har oppgitt og hva det faktisk måler, og setter deretter opp en test du kan kjøre selv på to uker.

En frontiermodell med sikkerhet som hovedargument

Carbon er posisjonert mot cyberforsvar: å finne sårbarheter, utnytte dem i kontrollerte miljøer og skrive patcher. Google oppgir også at interne team har sett modellen kjøre i dager for å løse komplekse engineering-oppgaver (Google DeepMind, 2026). Det er en kapabilitetsbeskrivelse som peker mot agentisk bruk, altså systemer som handler over tid uten at et menneske godkjenner hvert steg.

Den retningen er verdt å merke seg for deg som kjøper. En modell som er bygget for å kjøre lenge og selvstendig, flytter risiko fra feil svar til feil handling. Et dårlig formulert kundesvar koster omdømme. En agent som sletter en tabell eller sender en e-post til feil mottaker koster penger og tillit. Vi har skrevet mer om hvor sikkerhet i AI-agenter faktisk svikter i praksis.

Begrenset tilgang først, bredere etter hvert

Modellen gjøres først tilgjengelig for et utvalg cyberforsvarere, deretter gradvis for flere partnere gjennom Fairwind-programmet (Google DeepMind, 2026). Det er samme mønster vi så da Anthropic offentliggjorde Claude Mythos Preview 14. april 2026, der utvikleren selv begrunnet begrenset offentlig tilgang med modellens cybersikkerhetskapabiliteter (EU-kommisjonen).

Praktisk betyr det at Carbon ikke er noe du kan bestemme deg for å bruke på mandag. Du kan ikke teste den selv før du står på en tilgangsliste, og du kan ikke basere en produksjonsplan på en modell du ikke har kjørt mot egne data. Staget utrulling er fornuftig sikkerhetspraksis, men det er også en tilgangsbegrensning du må planlegge rundt. For en bredere gjennomgang av valg av språkmodell er ventetiden godt brukt tid.

Tallene Google selv oppgir og hva de måler

Her er alle tallene fra Googles egen kunngjøring, samlet, med hva hvert tall faktisk måler. Tabellen er den viktigste i artikkelen, fordi den skiller mellom tall som er offentlig etterprøvbare benchmarker og tall som kommer fra Googles interne miljøer.

Tall	Hva det gjelder	Type måling
Null	Vellykkede angrep på Gray Swan sin benchmark for indirekte prompt-injeksjon	Ekstern benchmark, kjørt av leverandør
En liten, målbar andel	Samme benchmark for forgjengeren Argon	Sammenligningsgrunnlag
Sterkest av de tre cybertallene	SEC-bench Pro, å finne sårbarheter	Ekstern benchmark
Svakest av de tre cybertallene	ExploitGym, utnyttelse av sårbarheter	Ekstern benchmark
I mellomsjiktet	CWE-bench, patching	Ekstern benchmark
Null	Vellykket juks på Terminal-Bench 4.0	Ekstern benchmark
+89 elo til 1769	WebDev Arena, ender på fjerdeplass	Offentlig rangering, menneskelige preferanser
Over 2x	Forbedret suksessrate for sikker kodegenerering mot Argon	Leverandørens egen måling
Over 10x	Chrome-teamets patch-generering mot en annen labs modell	Internt Google-team
Nesten 80 prosent	Nedgang i varsler om høy-alvorlighets misalignment	Internt live-kodemiljø
26 og 29 prosent	Reduksjon i overreach og under-service	Intern måling
4 og 20 dollar	Pris per million input- og output-tokens etter introduksjonsperioden	Prisliste

Sårbarhetsjakt, utnyttelse og patching

De tre cybersikkerhetstallene gjelder tre ulike benchmarker: SEC-bench Pro for å finne sårbarheter, ExploitGym for utnyttelse og CWE-bench for patching (Google DeepMind, 2026). Legg merke til spredningen mellom dem. Modellen finner sårbarheter langt bedre enn den utnytter dem, og patcher også bedre enn den utnytter.

Det er informasjon du kan bruke. Hvis du vurderer Carbon til en konkret oppgave, er det tallet for den oppgaven som gjelder, ikke gjennomsnittet og ikke overskriften. En modell som er klart svakest på utnyttelsestesten, er ikke en modell du setter til å jobbe uten tilsyn i et produksjonsmiljø.

Koding, arena-score og langhorisont

På WebDev Arena oppgir Google en økning på +89 elopoeng til 1769, som gir en fjerdeplass (Google DeepMind, 2026). Det er et ærlig tall å publisere: en fjerdeplass er ikke en seier. Google oppgir også over 2x forbedring i å generere sikker kode sammenlignet med Argon, og at Chrome-teamet målte over 10x bedre patch-generering enn en annen labs frontiermodell.

Det siste tallet er det svakeste av dem, metodisk sett. Det er et internt Google-team som sammenligner mot en konkurrent som ikke er navngitt offentlig, uten at oppsettet er publisert og uten at noen utenfor kan kjøre testen om igjen. Et 10x-tall uten metodebeskrivelse er markedsføring, ikke måling.

Interne tall du ikke kan etterprøve

Tre tall kommer fra Googles egne live-kodemiljøer: nesten 80 prosent nedgang i varsler om misalignment med høy alvorlighetsgrad, 26 prosent reduksjon i overreach og 29 prosent reduksjon i under-service (Google DeepMind, 2026). Overreach betyr at modellen gjør mer enn den ble bedt om. Under-service betyr at den gjør mindre.

At Google i det hele tatt måler disse to feiltypene, og rapporterer dem separat, er godt arbeid. Men tallene er relative til Googles egen varslingsterskel, i Googles egen kodebase, med Googles egne oppgavetyper. De forteller deg at modellen oppfører seg bedre enn forgjengeren hos Google. De forteller deg ingenting om hvor ofte den vil overreach i din CRM-integrasjon.

Les også: Sikkerhet i AI-agenter svikter i 73 prosent av utrullingene. 73 prosent av AI-utrullinger har minst én kritisk sårbarhet, og bare 12 prosent tester systematisk.

Benchmark eller driftssikkerhet: hvorfor det ikke er samme sak

Dette er kjernen i artikkelen. Alura mener egenrapporterte benchmarktall er et utgangspunkt for en test, ikke et bevis på driftssikkerhet. Det er ikke en kritikk av Google spesielt. Det gjelder hver leverandør som publiserer egne tall, og det gjelder også tall som ser ut som fasit fordi de er null.

Forskjellen er enkel å formulere. En benchmark måler hvor ofte en modell løser en definert oppgave under definerte forhold. Driftssikkerhet handler om hva som skjer i systemet ditt når modellen tar feil, hvor ofte det skjer, hvem som oppdager det og hvor dyrt det blir.

Et nullresultat er en måling, ikke en garanti

Carbon oppgis å stanse alle angrepene i Gray Swan sin benchmark for indirekte prompt-injeksjon, mot en liten men målbar andel som slapp gjennom hos forgjengeren Argon (Google DeepMind, 2026). Det er et reelt framskritt. Men et nullresultat på et testsett betyr at ingen av angrepene i det settet lyktes, ikke at ingen angrep kan lykkes.

Angrepssett er statiske. Angripere er ikke. Når et sett blir offentlig kjent, blir det også et optimaliseringsmål, og nye angrepsklasser oppstår etter at settet ble laget. Null i dag er en god nyhet med en kort holdbarhet. Det samme gjelder juks på Terminal-Bench 4.0, der Google også oppgir null: et presist resultat på en presis test.

Prompt-injeksjon treffer systemet, ikke bare modellen

Indirekte prompt-injeksjon betyr at instruksjoner smugles inn via innhold modellen leser: et dokument, en nettside, en e-post, et støttebillett-vedlegg. Modellens motstandskraft er ett lag i forsvaret. De andre lagene er hvilke verktøy modellen har tilgang til, hvilke rettigheter de verktøyene har, og hva som logges.

Frontier-utviklere har konvergert mot tre operasjonelle lag: kapabilitetsfremkalling med avgrensede påstander, input- og output-sikkerhetsmekanismer, og kontrollert utrulling med logget tilgang (EU-kommisjonen). Poenget for deg: to av tre lag er noe du må bygge, uansett hvilken modell du velger. En modellbytte gir deg lag en. Den gir deg ikke lag to og tre.

Støyen i benchmarktall er større enn du tror

LayerLens målte en kjøring-til-kjøring-variasjon på 1,3 poeng på MATH-500, mens gapet mellom de fem beste modellene var 0,4 poeng (layerlens.ai, 2026). Med andre ord: støyen i målingen er større enn forskjellen mellom modellene. En rangering under slike forhold er ikke informasjon.

På kunnskapstester er toppmodellene så like at rangering ikke er meningsfull (layerlens.ai, 2026). Det betyr at «topp tre» på en mettet benchmark er en nyhetsoverskrift, ikke et beslutningsgrunnlag. Se etter oppgaver der modellene faktisk skiller seg, og se om de oppgavene ligner dine.

Fire spørsmål å stille før du bytter modell

Et modellbytte er en teknisk endring med forretningskonsekvenser. Disse fire spørsmålene tar en halvtime å besvare og sorterer de fleste beslutninger. Hvis du ikke kan svare på alle fire, har du ikke nok grunnlag ennå.

Spørsmål	Et svar som holder	Et svar som ikke holder
Hvilken oppgave skal løses, og hvordan måles den?	«Kategorisere innkommende support-saker, målt mot 400 ferdigkategoriserte saker fra i fjor.»	«Bli bedre på kundeservice.»
Hva koster et feilsvar?	«Feil kategori gir en dags forsinkelse. Feil prisopplysning kan utløse et krav.»	«Vi passer på at det ikke skjer.»
Hvor raskt kan du bytte tilbake?	«Leverandøren er bak et abstraksjonslag. Rulle tilbake tar en time.»	«Prompter og verktøykall er skrevet direkte mot ett API.»
Hvem eier evalueringen?	«Navngitt person, testsettet versjonsstyres, kjøres ved hver modelloppdatering.»	«Vi leser release notes fra leverandøren.»

Hvilken oppgave, målt hvordan

Den vanligste feilen er å evaluere «modellen» i stedet for oppgaven. Carbon er bygget mot cybersikkerhet og lange, selvstendige oppgaveløp (Google DeepMind, 2026). Hvis din oppgave er å trekke felt ut av fakturaer, sier cybersikkerhetstallene ingenting om hvor godt den gjør jobben din.

Skriv ned oppgaven i en setning, og målemetoden i en til. Hvis du ikke klarer å beskrive hva som er et riktig svar, kan du heller ikke måle om en ny modell er bedre. En oppgave uten målemetode er en mening, ikke et prosjekt.

Hva koster et feilsvar

Feilkostnaden bestemmer hvor mye evaluering som er forsvarlig. Et forslag til e-posttekst som et menneske leser før sending, tåler mye feil. En automatisk godkjenning av en kredittgrense tåler nesten ingen. Samme modell, helt ulike krav.

Her hjelper Googles skille mellom overreach og under-service. En modell som gjør for mye er farlig i agentiske oppsett med skriverettigheter. En modell som gjør for lite er bare irriterende. Kartlegg hvilken av de to feilene som koster deg mest, og mål den.

Hvor raskt kan du bytte tilbake

Alura mener at når utgivelsestakten øker, bør modellvalg være et bytteklart valg og ikke en flerårig binding. I praksis betyr det at leverandørvalget skal ligge bak et tynt abstraksjonslag i koden, at prompter og evalueringssett er versjonsstyrt utenfor leverandørens plattform, og at du vet hvor lang tid en tilbakerulling tar.

LayerLens anbefaler direkte å ikke låse seg til en leverandør (layerlens.ai, 2026). Det er lett å si og dyrt å ignorere. Kostnaden for fleksibilitet betaler du en gang, i arkitektur. Kostnaden for innlåsing betaler du hver gang markedet beveger seg.

Hvem eier evalueringen

Evaluering som ingen eier, blir ikke gjort. Sett et navn på det, ikke en avdeling. Personen skal eie testsettet, kjøre det ved hver modelloppdatering, og ha mandat til å si nei til et bytte.

Dette er også et samsvarspoeng. Hvis du senere må dokumentere at systemet oppfyller krav, er det din egen testhistorikk som er dokumentasjonen. Leverandørens blogginnlegg er ikke din dokumentasjon.

Egne testsett slår offentlige rangeringer

Alura mener et testsett bygget på virksomhetens egne data er mer verdt enn en topplassering på en offentlig benchmark. Begrunnelsen er ikke prinsipiell, den er praktisk: offentlige benchmarker måler oppgaver noen andre har definert, på data du ikke har, med feilkostnader som ikke er dine.

LayerLens kommer til samme konklusjon etter å ha testet over 200 modeller på sin plattform i årets første kvartal, og anbefaler å bygge testsett fra egne data (layerlens.ai, 2026). Det er verdt å merke at rapporten også er markedsføring for deres egen evalueringsplattform. Anbefalingen er likevel riktig, og den er gratis å følge.

Hvor mange eksempler trenger du

Anbefalingen fra LayerLens er 300 til 500 reelle eksempler i testsettet (layerlens.ai, 2026). Det er færre enn mange tror, og mer enn de tjue eksemplene folk vanligvis nøyer seg med. For en SMB som har kjørt kundeservice i noen år, finnes de eksemplene allerede i saksbehandlingssystemet.

Settet skal inneholde det som faktisk kommer inn, inkludert det stygge: ufullstendige henvendelser, feilstavet norsk, blandet norsk og engelsk, vedlegg som er bilder av tekst. Et testsett med bare pene eksempler måler noe du aldri møter i drift. Legg også inn noen bevisste angrepsforsøk, altså tekst som prøver å få modellen til å bryte sine egne instruksjoner.

Karakteren er ikke nok, veien dit teller

I en casestudie der seks modeller vurderte samme AI-arbeid, ga alle seks nesten identiske karakterer, mellom 90 og 100 av 100, men resonnerte helt ulikt om hvorfor (layerlens.ai, 2026). En av modellene brukte åtte undersøkelsessteg der andre tok færre. Samme sluttsvar, ulik vei.

Konsekvensen for testingen din: logg ikke bare om svaret var riktig, men hvor mange steg, hvilke verktøy og hvilke data modellen rørte underveis. I agentiske oppsett er veien dit der kostnaden og risikoen bor. To modeller med samme treffprosent kan ha helt ulik regning og helt ulik skadepotensial.

Mandag morgen: en pilot som gir svar på to uker

Dette er oppsettet vi anbefaler for en SMB som vurderer å bytte eller legge til en frontiermodell. Det krever en person på halv tid i to uker, og det gir et svar du kan forsvare i et ledermøte.

Dag	Aktivitet	Leveranse
1 til 2	Velg en oppgave. Skriv ned hva riktig svar er, og hva et feilsvar koster.	En A4-side
3 til 5	Hent 300 til 500 reelle eksempler fra driften. Legg inn angrepsforsøk og stygge tilfeller.	Versjonsstyrt testsett
5	Skriv beslutningsregelen: hva skal til for bytte, hva utløser nei.	Signert av eier
6 til 8	Kjør dagens modell og kandidaten mot samme sett. Logg svar, steg, verktøykall og tokenbruk.	Rådata
9	Blind manuell gjennomgang av uenighetene mellom modellene.	Feiltypeliste
10	Regn kostnad per oppgave fra faktisk tokenbruk, ikke fra listeprisen alene.	Kostnadsark
11 til 12	Beslutning mot regelen fra dag 5. Dokumenter hva som ble testet og hva som ikke ble det.	Beslutningsnotat

Uke 1: settet og beslutningsregelen

Beslutningsregelen skrives før du ser resultatene. Det er hele poenget. Hvis regelen skrives etterpå, tilpasser du den ubevisst til tallene du liker. En brukbar regel ser slik ut: kandidaten må være minst like god på vår viktigste feiltype, ikke merkbart dårligere på noen kategori, og tilbakerulling skal ta under en dag.

Testsettet skal ligge i ditt eget versjonskontrollsystem, ikke i en leverandørplattform. Når du kjører det om igjen seks uker senere, må det være nøyaktig samme sett. Ellers måler du to ting samtidig og vet ikke hvilket som endret seg.

Uke 2: kjør modellene mot hverandre

Kjør begge modellene mot samme sett, i samme uke, med samme prompter der det er mulig. Logg alt: svar, antall steg, verktøykall, input-tokens, output-tokens, cachetreff. Kostnadsarket ditt skal bygges fra faktisk tokenbruk, fordi en modell som bruker flere steg på samme oppgave kan være dyrere selv med lavere listepris.

Gå så gjennom uenighetene manuelt, blindt. Du trenger ikke lese alle svarene i settet. Du trenger å lese de tilfellene der modellene er uenige, fordi det er der signalet ligger. Sorter funnene i feiltyper, ikke i en prosentscore.

Hva piloten ikke svarer på

To uker gir deg treffsikkerhet, feiltyper og kostnad per oppgave. Det gir deg ikke stabilitet over tid, oppførsel under last, eller hvordan modellen håndterer angrep som ikke fins i settet ditt ennå. Vær ærlig om det i beslutningsnotatet.

Det gir deg heller ikke svar på latens i rushtid eller hva som skjer når leverandøren endrer modellen bak samme navn. Dokumenter hva du ikke testet. Det er den delen av notatet som gjør deg i stand til å ta neste beslutning raskt.

Markedet i 2026 har ingen vinner på alle oppgaver

Hovedfunnet i LayerLens' Q1-rapport er at ingen AI-leverandør vant alle fem tester, og at ulike modeller ledet ulike tester (layerlens.ai, 2026). Det er ikke et overgangsfenomen, det er markedets struktur. Spesialisering slår universell overlegenhet.

Oppgavetype	Modell som leder	Ledelse
Feilretting	Claude Opus 4.6	6,3 poeng, men utenfor topp 25 på matematikk
Programmering	Grok 4 Fast	7,3 poeng
Systemadministrasjon	Gemini 3 Pro	2,5 poeng
Kunnskapstester	Ingen meningsfull leder	0,4 poeng mellom topp fem på MATH-500
Cybersikkerhet	Gemini 4 Carbon ifølge Google	Sterkeste av Googles tre egne cybertall, på SEC-bench Pro

Ulike modeller leder ulike oppgaver

Mønsteret er tydeligst hos Claude Opus 4.6, som leder feilretting med 6,3 poeng men faller utenfor topp 25 på matematikk (layerlens.ai, 2026). Det er samme modell, to helt ulike plasseringer. Hvem som er «best» avhenger fullstendig av hva du spør om.

På kodetester er det Qwen 3.5 som leder LiveCodeBench v6 og MiniMax M2.5 som leder SWE-bench Verified (layerlens.ai, 2026), mens Nemotron 3 Super 120B oppgis et godt stykke lavere på SWE-Bench Verified i en annen rapport (digitalapplied.com, 2026). Tallene er ikke direkte sammenlignbare på tvers av rapporter, og det er nettopp problemet med å handle etter andres benchmarker. Vi har samlet et bredere bilde av valg av språkmodell for norske bedrifter.

Bruk følger ikke intelligens

Et av de mest lærerike funnene i markedsdataene: MiMo V2 Pro har et ukentlig tokenvolum på 4,79 billioner tokens på OpenRouter, hvorav 2,05 billioner er kodetokens (digitalapplied.com, 2026). Folk velger ikke nødvendigvis den smarteste modellen. De velger den som er billig nok, rask nok og god nok til oppgaven.

Samme rapport viser at Xiaomi gikk fra null til å eie 21,1 prosent av OpenRouters tokenvolum på fire måneder. Markedsandeler i dette markedet flytter seg i kvartaler, ikke i år. Og på pris finner du modeller som Gemini 3.1 Flash-Lite til omtrent 0,25 dollar per million ord (layerlens.ai, 2026), som for mange oppgaver er mer enn godt nok. Rabattert kapasitet er en reell strategi, slik vi har beskrevet for Gemini 3.7 Flash.

Les også: Det Lovable lærer norske SMB-er om interne apper og sikkerhet. Lovable har passert 500 millioner dollar i årlig inntekt og bygger en million apper i uken.

Kostnadsbildet for en norsk SMB

Prisen for Carbon etter introduksjonsperioden er 4 dollar per million input-tokens og 20 dollar per million output-tokens, med 95 prosent rabatt på cachede input-tokens (Google DeepMind, 2026). Det er prisen som gjelder etter introduksjonsperioden, altså er prisøkningen noe som kommer, ikke noe som gjelder nå.

Det viktige i de to tallene er forholdet mellom dem. Output koster vesentlig mer per token enn input. For en modell som er bygget for lange, selvstendige oppgaveløp, der mye av arbeidet er generert tekst og mange mellomsteg, er det output-siden som avgjør regningen. En agent som resonnerer i flere steg produserer mye output du aldri ser.

Listeprisen er en av flere poster

Post	Hva som driver den	Hva du kan gjøre
Input-tokens	4 dollar per million. Kontekst, dokumenter, systemprompt.	Cache det som gjentas. Kutt kontekst du ikke bruker.
Output-tokens	20 dollar per million. Svar og mellomsteg i agentiske løp.	Sett tak på steg. Mål faktisk forbruk per oppgave.
Cachede input	95 prosent rabatt mot ordinær inputpris.	Strukturer prompter så den stabile delen kommer først.
Evaluering	Testsett, kjøringer, manuell gjennomgang.	3 til 5 prosent av totalt AI-forbruk.
Integrasjon og tilsyn	Logging, rettighetsstyring, menneskelig kontroll.	Bygges en gang, gjenbrukes på tvers av modeller.
Reserve	Uventet bytte, prisendring, ny modell.	10 til 15 prosent av årlig AI-budsjett uforpliktet.

Tabellen er bevisst uten kronebeløp. Et realistisk anslag for din virksomhet kan bare komme fra måling av faktisk tokenbruk på dine egne oppgaver, og det får du ut av piloten i forrige seksjon. Alle kostnadsanslag som ikke er bygget på målt tokenbruk, er gjetning.

Caching flytter regnestykket mer enn prisforhandling

Rabatten på cachede input-tokens er den største enkeltposten du kan påvirke selv (Google DeepMind, 2026). For typiske SMB-oppgaver er store deler av konteksten identisk fra kall til kall: systeminstruksjoner, produktkatalog, prisliste, retningslinjer. Den delen bør treffe cachen hver gang.

Det krever at du strukturerer prompten så det stabile ligger først og det variable sist. Det er en time med arbeid som gir varig effekt på regningen. Til sammenligning gir leverandørforhandling for en SMB med moderat volum sjelden noe.

Evaluering som egen budsjettpost

Alura mener du bør sette av en del av AI-budsjettet til evaluering før du øker forbruket på selve modellen. Anbefalingen fra markedet er konkret: 3 til 5 prosent av totalt AI-forbruk til evalueringsinfrastruktur, og 10 til 15 prosent av årlig AI-budsjett som uforpliktet reserve (digitalapplied.com, 2026).

Reserven er det leddet folk hopper over. Den finansierer et bytte du ikke hadde planlagt, en prisendring du ikke kontrollerer, eller en ny modell som gjør samme oppgave vesentlig billigere. Et AI-budsjett som er fullt forpliktet i januar, kan ikke reagere på et marked som flytter seg i kvartaler.

AI Act og kravet om uavhengig vurdering

Her blir skillet mellom egenrapportering og uavhengig verifisering et juridisk spørsmål, ikke bare et metodisk. AI Act krever at samsvarsvurdering for høyrisikosystemer i Annex III utføres av teknisk kontrollorgan etter Artikkel 43, mot forpliktelsene i Artikkel 9 til 15 (EU-kommisjonen).

Merk hvem dette treffer. Modellen i seg selv er ikke et Annex III-system. Det er bruken som avgjør: setter du en frontiermodell til å screene jobbsøkere, vurdere kredittverdighet eller styre kritisk infrastruktur, er det ditt system som havner i høyrisikokategorien, og det er du som må kunne dokumentere samsvar.

Artikkel 43 utelukker selvattestering

Formuleringen er tydelig: selvattestering fra leverandøren er nettopp det Artikkel 43 utelukker for Annex III-systemer (EU-kommisjonen). Googles blogginnlegg om Carbon er selvattestering. Det er ikke en kritikk, det er en sjangerbeskrivelse. Alle leverandører publiserer sine egne tall.

Praktisk konsekvens: leverandørens benchmarktall kan ikke være ryggraden i din samsvarsdokumentasjon for et høyrisikosystem. Dine egne tester, dine egne logger og dine egne risikovurderinger er det regulator kan be om. Det er en god grunn til å bygge testsettet uansett hva du konkluderer om modellvalget.

Fristene og hva som kan flytte seg

Innlegget på EUs Futurium-plattform oppgir august 2026 som frist for Artikkel 5 og august 2027 for Annex III-systemer, mens forfatteren i en kommentar viser til desember 2027 som ny frist for høyrisikoregimet etter Digital Omnibus (EU-kommisjonen). Den siste datoen står i et kommentarfelt, ikke i en rettsakt, så behandle den som et signal om bevegelse og ikke som en fastsatt dato.

Lærdommen for en norsk SMB er ikke datoene. Det er at fristene flytter seg, og at bevisbyrden ikke gjør det. Uansett når kravene slår inn, er det dokumentasjonen du har bygget underveis som avgjør hvor dyrt samsvar blir. Bygger du den etterpå, blir det et prosjekt. Bygger du den mens du tester, blir det et biprodukt.

Verifiserbarhet er fortsatt et uløst problem

De tre operasjonelle lagene frontier-utviklere har konvergert mot, er ikke uavhengig verifiserbare, fordi de er avhengige av utviklerens egen infrastruktur og egne logger (EU-kommisjonen). Det er ikke en påstand om uredelighet. Det er en strukturell observasjon: du kan ikke etterprøve et tall som bare finnes i andres logger.

Forslaget i innlegget, Zero-Knowledge Audit Protocol, skal legge et verifiserbarhetslag oppå de eksisterende uten å gi noen part tilgang til modell, treningsdata eller personopplysninger. Forfatteren oppgir at omtrent 70 prosent av den kryptografiske stakken finnes som produksjonsklare open-source-biblioteker, og anslår omtrent sju måneder gjenstående ingeniørarbeid for et kjerneteam.

Samtidig er forbeholdene store, og forfatteren er åpen om dem: protokollen eksisterer ikke som et fungerende produksjonssystem, ingen prototype er bygget, den er ikke uavhengig fagfellevurdert, og alle tekniske påstander i den offentlige dokumentasjonen er selvattesterte. For en modell på størrelse med LLaMA-13B måles bevisgenerering for en enkelt inferens i timer snarere enn sekunder på nåværende hardware. Et forslag om verifiserbarhet som selv er selvattestert, illustrerer problemet det prøver å løse.

Utgivelsestakten tvinger kortere vurderingssykluser

Frontier Model Release Velocity Index oppgir 12 eller flere substansielle frontutgivelser i Q1 2026 mot 6 i Q4 2025, og prognostiserer 14 til 18 utgivelser i Q2 i basisscenarioet (digitalapplied.com, 2026). Indeksen er utgiverens egen konstruksjon, så behandle nivået som en indikasjon. Retningen bekreftes uavhengig av LayerLens, som rapporterer ni betydelige modellutgivelser på omtrent seks uker (layerlens.ai, 2026).

Konsentrasjonen er like påfallende som volumet. Alibaba slapp sju distinkte Qwen-varianter mellom 23. januar og 2. april 2026, altså flere utgivelser fra samme leverandør i løpet av et kvartal (digitalapplied.com, 2026).

Fra halvårlig til fire uker

Byråer som tidligere kjørte seks måneders modellvurderinger, tvinges nå over på en fire ukers kadens (digitalapplied.com, 2026). Antall modeller testet hos LayerLens forteller samme historie fra en annen vinkel: 25 unike modeller i Q3 2025, 83 i Q4, og 44 i de første 2,5 månedene av Q1 2026 (layerlens.ai, 2026).

En fire ukers syklus er bare mulig hvis evalueringen er automatisert. Manuell gjennomgang av flere hundre eksempler hver måned skjer ikke i en SMB. Det som skjer, er at du kjører settet automatisk, ser på differansen mot forrige kjøring, og leser manuelt bare der modellene er uenige.

Bytteklart i stedet for bundet

Med denne takten er en treårig leverandørbinding et veddemål på at markedet står stille. Det gjør det ikke. Alternativet er ikke å bytte hele tiden, men å gjøre bytte billig: abstraksjonslag i koden, versjonsstyrt testsett, og en uforpliktet budsjettreserve.

Produktgrensene flytter seg samtidig som modellene gjør det, og det styrker argumentet for å holde arkitekturen løs der den møter leverandøren. Hvis du vil se Googles plattformbilde samlet, har vi en gjennomgang av Gemini-plattformen.

Vanlige feil når virksomheter velger frontiermodell

Dette er feilene vi ser oftest når en SMB bytter modell. De er alle lette å unngå, og alle dyre å oppdage i produksjon.

Å lese overskriften i stedet for tallene

«Stanset alle angrep» og «null vellykkede angrep på Gray Swan sin benchmark for indirekte prompt-injeksjon» er ikke samme utsagn. Det andre er presist og etterprøvbart i prinsippet. Det første er en generalisering av det andre. Når et tall gjelder en navngitt test, skriv ned testens navn sammen med tallet. Da ser du selv hvor smalt det er.

Pass også på kildekvaliteten. Pressedekning av en lansering er i praksis en videreformidling av leverandørens tall, ofte uten egen testing. En kort notis som gjentar at modellen presterer bedre enn konkurrentene på enkelte benchmarker, gir deg ikke mer grunnlag enn kunngjøringen selv.

Å bytte modell uten å bytte testsett

Mange bytter modell og gjenbruker promptene uendret. Prompter er modellspesifikke. En instruksjon som fungerte godt på en modell kan gi overreach eller under-service på en annen, og du kan dermed måle promptens tilpasning snarere enn modellens evne.

Kjør derfor minst en runde med lett prompt-tilpasning for begge modeller før du konkluderer. Ellers risikerer du å forkaste en bedre modell fordi den trengte en annen formulering.

Å stole på en benchmark som er mettet

Når toppmodellene ligger tett oppunder taket på samme test, er testen ferdig som beslutningsverktøy (layerlens.ai, 2026). Rangeringen måler da i hovedsak støy. Se etter tester der spredningen er stor nok til å være reell, og enda bedre: lag testen selv.

Dette er også grunnen til at en modell kan lede en liste og ligge langt nede på en annen uten at noe er galt med målingene. Metning og spesialisering gir rangeringer som ser motstridende ut men begge er riktige.

Å behandle agentisk bruk som en chat

Googles oppgitte reduksjoner i overreach og under-service peker på at agentiske feil er noe leverandørene nå måler eksplisitt (Google DeepMind, 2026). En modell som kjører i dager uten tilsyn, trenger andre kontroller enn en chatbot: begrensede rettigheter, revisjonsspor, og en grense for hva den kan gjøre uten godkjenning.

Her ligger den største praktiske risikoen for en SMB. Interne verktøy bygget raskt får ofte for brede rettigheter, et mønster vi har beskrevet i gjennomgangen av hva interne apper og sikkerhet krever. Modellvalg løser ikke et rettighetsproblem.

Vanlige spørsmål om Gemini 4 Carbon

Spørsmålene under er de vi får oftest fra ledere og produktansvarlige som leser en lanseringsnyhet og skal bestemme om den angår dem.

Betyr et nullresultat at modellen ikke kan angripes?

Nei. Det betyr at ingen av angrepene i Gray Swan sitt sett for indirekte prompt-injeksjon lyktes, mens en liten andel slapp gjennom hos forgjengeren Argon (Google DeepMind, 2026). Et testsett er endelig og statisk. Nye angrepsklasser oppstår etter at settet er laget, og offentlige sett blir også optimaliseringsmål. Behandle tallet som sterkt bevis på forbedring og svakt bevis på framtidig sikkerhet.

Kan vi bruke Carbon nå?

Ikke fritt. Modellen gjøres først tilgjengelig for et utvalg cyberforsvarere, deretter gradvis for flere partnere via Fairwind-programmet (Google DeepMind, 2026). For de fleste norske SMB-er er dette noe du planlegger for, ikke noe du setter i drift denne måneden. Bruk ventetiden til å bygge testsettet, så er du klar den dagen tilgangen kommer.

Hva kommer dette til å koste oss?

Etter introduksjonsperioden er prisen 4 dollar per million input-tokens og 20 dollar per million output-tokens, med kraftig rabatt på cachede input (Google DeepMind, 2026). Hva det blir for deg avhenger av antall oppgaver, kontekststørrelse, hvor mye du får cachet og hvor mange mellomsteg modellen bruker. Den eneste pålitelige veien til et tall er å måle faktisk tokenbruk på dine egne oppgaver.

Vi bruker Claude eller GPT i dag. Bør vi bytte?

Bare hvis oppgaven din er den Carbon er sterkest på, og bare hvis du har målt det selv. Ingen leverandør vant alle fem tester i LayerLens' Q1-gjennomgang, og Claude Opus 4.6 leder for eksempel feilretting mens den faller utenfor topp 25 på matematikk (layerlens.ai, 2026). Et bytte koster prompt-tilpasning, ny testing og ny dokumentasjon. Gevinsten må være større enn den kostnaden på din oppgave, ikke på en benchmark.

Holder Googles tall som dokumentasjon mot AI Act?

Nei, ikke alene. For høyrisikosystemer i Annex III skal samsvarsvurdering gjøres av teknisk kontrollorgan etter Artikkel 43, og selvattestering fra leverandøren er nettopp det bestemmelsen utelukker (EU-kommisjonen). Leverandørens tall er et inngangsargument. Din egen testhistorikk, dine logger og din risikovurdering er dokumentasjonen.

Oppsummering og neste steg

Gemini 4 Carbon er en reell forbedring på et område som betyr mye: ingen vellykkede angrep på Gray Swan sin benchmark der forgjengeren slapp noen gjennom, toppscore blant Googles egne cybertall på SEC-bench Pro for å finne sårbarheter, og målte reduksjoner i både overreach og under-service (Google DeepMind, 2026). Tallene er publisert av Google, om Google, med Googles oppsett. Det gjør dem ikke feil. Det gjør dem til en hypotese du kan teste.

Markedet rundt lanseringen gir tre faste punkter du kan planlegge etter. Ingen leverandør leder alle oppgaver, og spesialisering er regelen (layerlens.ai, 2026). Utgivelsestakten har doblet seg og presser vurdering ned til fire uker (digitalapplied.com, 2026). Og regulatorisk kan du ikke lene deg på leverandørens egne påstander for høyrisikobruk (EU-kommisjonen).

Neste steg er kort. Velg en oppgave. Hent 300 til 500 reelle eksempler fra driften og versjonsstyr dem. Skriv beslutningsregelen før du ser tall. Kjør dagens modell mot kandidaten på samme sett i samme uke, og regn kostnad fra faktisk tokenbruk. Sett av 3 til 5 prosent av AI-forbruket til evaluering og hold 10 til 15 prosent av budsjettet uforpliktet (digitalapplied.com, 2026). Da er neste lansering en mulighet du kan vurdere på fjorten dager, ikke en nyhet du må ta stilling til uten grunnlag.

I Alura bygger vi AI-infrastruktur for norske virksomheter, fra dataplattformer til agentiske systemer i produksjon. Vi er ikke en SaaS-leverandør. Vi er håndverkere som setter sammen byggesteinene som faktisk fungerer for din situasjon.

Bestill en arkitektur-samtale: vi går gjennom din nåværende infrastruktur, identifiserer integrasjonspunkter, og foreslår en pragmatisk vei videre. Uforpliktende, 45 minutter.

Kilder

Google DeepMind (2026). Introducing Gemini 4 Carbon
layerlens.ai (2026). Frontier AI Models 2026: 200+ Tested, No Winner
digitalapplied.com (2026). Frontier Model Release Velocity Index 2026 Q2 Report
EU-kommisjonen. After Mythos: Why Frontier AI Conformity Assessment Requires a Cryptographic Layer | Futurium