---
title: "Dette kan ikke sendes uten bevis"
canonical: "https://nordvec.com/no/blog/copy-that-cannot-ship-without-proof"
lang: "no"
claims: "https://nordvec.com/api/trust/claims"
---

# Dette kan ikke sendes uten bevis

Source: https://nordvec.com/no/blog/copy-that-cannot-ship-without-proof

This file is rendered from the same message catalogue as the page, at request time; the HTML page is the canonical document. Statements about the processing chain are bound to the claim record at https://nordvec.com/api/trust/claims, which says which of them the register currently supports.

Rasmus Kjær Damgaard, Grunnlegger · Publisert 7. september 2026

Denne artikkelen ble produsert med AI‑assistanse og gjennomgått av en person. Rasmus Kjær Damgaard har redaksjonelt ansvar for innholdet.

Denne oversettelsen er laget fra den engelske originalen med AI‑behandling i Frankrike og er ikke gjennomgått av en person. Rasmus Kjær Damgaard har redaksjonelt ansvar for den engelske versjonen, som er den offisielle versjonen. [Les den engelske originalen](https://nordvec.com/blog/copy-that-cannot-ship-without-proof)

Hver samsvarspåstand på dette nettstedet blir sjekket mot vårt eget underprosessorregister før den kan legges inn. Her er mekanismen, hva den avviser, og hva vi ærlig talt ikke kan bevise.



**TL;DR:** Markedsføringspåstander driver bort fra virkeligheten, og ingen legger merke til det før en revisor eller en myndighet gjør det. På dette nettstedet kan en setning som hevder noe faktabasert om hvor data behandles, hvem som kan pålegge tilgang, om det krysser en grense, eller om en modell trent på det ikke kan publiseres med mindre et maskinsjekket predikat underbygger det. Dette innlegget forklarer mekanismen, viser tre påstander den for øyeblikket nekter oss å fremme, nevner en reell påstand den fanget opp, og beskriver hva den ikke kan bevise.

## Problemet er avvik – og avviket er en juridisk risiko [#problemet-er-avvik--og-avviket-er-en-juridisk-risiko]

En påstand på en leverandørs nettside skrives én gang og blir deretter stående. Faktaene bak den endrer seg: en underleverandør legges til, en region skiftes, en sertifisering utløper. Setningen blir stående. I månedsvis hevder siden noe som selskapets egne registre allerede motsier, og avviket er usynlig fordi de to lever i forskjellige systemer, redigert av forskjellige personer.

For en europeisk selger er dette ikke bare et troverdighetsproblem. I henhold til direktivet om urimelig handelspraksis (2005/29/EF), artikkel 12, kan en myndighet kreve at en næringsdrivende dokumenterer en faktapåstand, og kan behandle manglende bevis som bevis på at påstanden er usann. Bevisbyrden ligger hos dere, og det trengs ingen søksmål for å utløse den. EU AI Act legger til en egen transparensplikt: artikkel 50(1) krever at en person blir informert når de samhandler med et AI-system. En påstandsoverflate som overdriver hva dere kan dokumentere, er nøyaktig det begge reglene er skrevet for å fange opp.

## Mekanismen: påstand, predikat, register, portvakt [#mekanismen-påstand-predikat-register-portvakt]

Designet er enkelt. Et register knytter hver kunderettet påstand til et predikat, og predikatet evalueres mot fakta som teksten ikke kan endre: underleverandørregisteret og tillitsbildet, begge generert fra kilde. Predikater er avgrenset etter lag, fordi en frase som "EU-hostet" egentlig er flere påstander i én: lagring, forespørselsvei og telemetri kan hver ha forskjellige svar, og å blande dem sammen er hvordan en sann påstand om én ting blir en usann påstand om en annen.

Portvakten, `bun run check:claims`, håndhever deretter fire ting i én gjennomgang. En påstand hvis predikat er usant, må ikke vises i teksten, på noe språk. Enhver streng som gir et løfte om oppholdssted, jurisdiksjon, overføring eller trening, må være deklarert, slik at neste absolutte påstand ikke kan legges til stille. Ingen slik påstand kan leve utenfor den oversettbare meldingskatalogen, der den ville unngå alle andre kontroller. Og en påstand som er rettet opp på engelsk, må ikke forbli aktiv i de andre 22 språkene: rørledningen oversetter bare når noen kjører den, så en rettelse som kun gjelder engelsk, ville la den gamle påstanden stå i alle andre språk. Den siste sjekken er paritetskontrollen, og det er den de fleste systemer glemmer.

Den siste delen fjerner redigeringssteget helt for de mest risikoutsatte feltene. I stedet for å skrive en oppholdsfrase manuelt inn i en metabeskrivelse eller et manifest – og håpe at en gjennomgang fanger den – tar disse feltene imot et token som løses opp til et registergenerert fragment, og fragmentet rendres bare så lenge predikatet holder. En setning registeret ikke kan underbygge, har ikke noe fragment å sette inn, så den kan ikke skrives. Oppdagelse fanger én formulering om gangen; generering lukker hele klassen.

## Hva den nekter [#hva-den-nekter]

Den beste måten å stole på en portvakt på, er å se den si nei. Tre påstander er deklarert i dag som registeret for øyeblikket ikke lar oss publisere, og portvakten rapporterer hver av dem som blokkert ved hvert kjøring:

* En påstand om at deres vilkår som forbyr modellleverandører å trene på kundedata, er kontraktuelt videreført gjennom alle lag. Dere ønsker det; registeret dokumenterer det ennå ikke, så det forblir upublisert.
* En påstand om at plattformen allerede oppfyller hele EU AI Act. Korpuset registrerer status per forpliktelse, og ikke alle er oppfylt, så den totaliserende versjonen blir avslått.
* En påstand om jurisdiksjonen til modellforsyningskjeden, som trenger et predikat om selskapsregistrering snarere enn om hvor en forespørsel kjøres, og som ennå ikke holder.

Dette er ikke forglemmelser. Det er påstander dere gjerne ville ha gjort, men ikke gjør, fordi disiplinen er mer verdt enn setningen.

Den har også fanget opp en reell sak. 27. juli 2026 landet portvakten (commit `3b7a4bffd`), og i løpet av en dag tvang den frem en rettelse som gjennomgangsprosessen hadde oversett: landingssidens hovedtekst hevdet datalokalitet uten noe i registeret bak seg (commit `a8d94d4a3`), og paritetssjekken krevde deretter at den korrigerte ordlyden ble overført til alle 22 andre språk, ikke bare engelsk. Påstandene som overlevde, er de spesifikke og verifiserbare: generering kjøres i Frankrike, innbedding i Berlin, dokumenter i Irland og Nürnberg, hver vist på [tillitssiden](/trust) med sin overføringsgrunnlag.

## Hva den ikke kan bevise, sagt tydelig [#hva-den-ikke-kan-bevise-sagt-tydelig]

En portvakt som overdriver sin egen evne, er akkurat det den finnes for å forhindre. Derfor er her dens grenser. Den beviser at hver publisert påstand samsvarer med registeret. Den beviser ikke at registeret beskriver verden korrekt, selv om en egen portvakt holder registeret opp mot koden. Den kan ikke verifisere at et benchmark-tall er reelt, eller at et sitert artikkelnummer er det riktige; det er vurderingsspørsmål en regulær uttrykk ikke kan nå. Det den fjerner, er den spesifikke, tilbakevendende feilen der en påstand som var sann ved lansering, stille blir usann – og ingen følger med på filen. Å få påstanden riktig i utgangspunktet, er fortsatt en persons jobb.

## Slik gjør dere det samme [#slik-gjør-dere-det-samme]

Mønsteret lar seg overføre, og ingen av delene er eksotiske. Oppretthold et maskinlesbart register over fakta deres påstander avhenger av, generert fra kilde i stedet for vedlikeholdt manuelt. Gi hver påstand et predikat registeret kan motbevise, avgrenset så snevert at én delsystems sannhet ikke kan stå i stedet for en annens. Kjør en pre-commit-portvakt som evaluerer hver påstand på alle språk dere leverer, og la et usant predikat feile bygget. Deretter, for feltene der en tilfeldig absolutt påstand gjør mest skade, genererer dere påstandsteksten fra registeret i stedet for å skrive den.

Resultatet er ikke høyere volum i teksten. Det er tekst en motstridende leser kan sjekke – og for en europeisk kjøper som vurderer en sikkerhetsleverandør, er det den eneste typen som konverterer.


## Ofte stilte spørsmål

### Hva sjekker egentlig påstandskontrollen?

Den leser hver deklarerte påstand om behandlingskjeden, evaluerer predikatet mot underprosessorregisteret og tillitsbildet, og feiler bygget hvis en påstand med usant predikat vises i teksten på ett av de 23 språkene. Den kjører som en pre-commit-hook og igjen i CI.

### Hvorfor sjekke registeret i stedet for bare å gjennomgå teksten?

En menneskelig gjennomgang beviser tilstanden den dagen den kjøres, og ingenting etter det. Registeret blir regenerert fra kilde og kontrollert i begge retninger, så å binde setningen til registeret betyr at setningen ikke kan overleve faktumet den hviler på. Når en leverandør endres, feiler påstanden som avhang av den ved neste commit.

### Beviser kontrollen at påstandene våre er sanne?

Nei, og det står det også. Den beviser at hver publiserte påstand samsvarer med registeret; den kan ikke verifisere at et benchmark-tall er reelt eller at et sitert artikkelnummer er riktig. Det forblir menneskelig skjønn. Kontrollen fjerner feilmodusen der en sann-ved-lansering-påstand stille glir over til å bli usann, ikke behovet for å få påstanden riktig i utgangspunktet.

### Kan vi gjenbruke dette mønsteret?

Ja. Delene er et maskinlesbart register over fakta som en enkelt sannhetskilde, et predikat per påstand som registeret kan motbevise, en pre-commit-kontroll som evaluerer alle språkversjoner, og generering av påstandsstrenger fra registeret i stedet for å skrive dem manuelt. Hver del er liten; disiplinen ligger i å koble dem sammen.

[Alle artikler](/no/blog)
