∀ krav ∃ bevis

Evidence Factory: make governance compile

Konteksten

100+ autonome produktteam
Både tilbyder og bruker av KI-systemer
EUs KI-forordning krever dokumentasjon, sporbarhet og bevis for hvert høyrisikosystem

Hvordan sikrer vi etterlevelse uten å bli en flaskehals?

Det vi vet

Vi er ikke gode på etterlevelse eller tverrgående arbeid
Vi mangler tilbakemeldingsløkker
Status er ofte en fortelling, ikke et faktum

4.4 Innebygd kontrollerbarhet og sporbarhet

Det er fakta som gjelder, ikke fortellinger. Vi bygger styringen inn i arbeidsprosessene og systemene våre, slik at vi kan sjekke kvaliteten med data, ikke bare beskrive det i ettertid. Status skal kunne testes: Hvis vi påstår at alt er i orden, må vi kunne bevise det, og dataene må kunne motbevise oss.

• Faktabasert, testbar styring: Vi gjør kravene og kontrollene konkrete med tydelige kriterier og indikatorer. For hvert krav definerer vi nøyaktig hva som skal til for at det er oppfylt, og hva som regnes som et avvik.

• Innebygd og automatisert bevisføring: Spor og bevis skal oppstå løpende i verktøyene vi bruker, ikke som manuelt etterarbeid.

• Sporbarhet med integritet: Vi kan følge beslutninger og kontroller tilbake til kilden: Hvem gjorde hva, når, hvorfor og i hvilken sammenheng? Kritiske spor skal være teknisk låst mot omskriving.

Vi har sett dette mønsteret før

Universell utforming

Krav fra EUs WAD → God praksis på Aksel → Etterlevelse i designsystem-komponenter

KI-styring

Krav fra KI-forordningen → Governance-kode + policy → Etterlevelse i CI

Make governance compile.

Gjør styringskrav til noe som kan kompileres, testes og verifiseres.

Arkitektur — to lag

Alle bokser er klikkbare lenker til kildekoden

Hva er en governance-input?

{
  "schema_version": "1",
  "title": "Intended purpose",
  "body": "Low-risk proof-of-concept. Synthetic
           data only. Outputs are advisory/draft
           only; human review required."
}

governance/intended-purpose.json — Strukturert. Versjonskontrollert. Ikke et Word-dokument.

→ Se filen på GitHub

Hva er en policy?

required := {
  "eval.json",
  "model/model.joblib",
  "governance/intended-purpose.json",
  "governance/human-oversight.json",
  "governance/data-governance.json",
  "governance/risk-notes.json",
  "governance/traceability.json",
}

deny contains msg if {
  some p in required
  not (p in files)
  msg := sprintf("missing required file: %s", [p])
}

Hvis en påkrevd fil mangler, feiler bygget med en tydelig feilmelding.

→ Se policy-filen

CI-pipelinen

Train

→

Evaluate

→

SBOM

→

Sårbarhetsskann

→

Monter bevisene

→

Policy-gate

→

Signer

Hver merge til main produserer en signert bevispakke.

→ Se siste CI-kjøring

Resultatet — kvitteringen

{
  "files": [
    {"path": "eval.json",
     "sha256": "a1b2c3...", "bytes": 1842},
    {"path": "governance/intended-purpose.json",
     "sha256": "d4e5f6...", "bytes": 147},
    ...
  ],
  "git_sha": "230bb2f...",
  "ci_run_url": "https://github.com/.../runs/..."
}

Innholdsadressert. SHA-256-hasher. Git-referanse. CI-kjøringslenke. Hvert krav kan verifiseres.

Når noe mangler

FAIL - evidence/manifest.json - evidence - missing required file: governance/human-oversight.json

«Status skal kunne testes.» Feilen er tydelig, handlingsbar, og blokkerer utsendelse.

Not speedbumps. Not guardrails.
Banking.

Hva betyr dette i praksis?

👩‍🔬 Dataforskere

Du skriver train.py. CI gjør resten. Ingen nye skjemaer.

⚖️ Jurister

Strukturert, versjonert, maskinverifisert dokumentasjon. Ikke narrativer.

🚀 Ledelse

Etterlevelse som infrastruktur, ikke prosjekt. Alltid klar for revisjon.

Hva dette er — og ikke er

✓ Er

Proof-of-concept kjerne
Implementasjon av designprinsipp 4.4
Fungerende CI-pipeline
Overførbart mønster

✗ Er ikke

Ferdig plattform
Full etterlevelse av KI-forordningen
Produksjonskode
Erstatning for faglig vurdering

Veien videre

Steg 1

Eksistens

Finnes bevisene?

Vi er her ✓

→

Steg 2

Struktur

Riktig skjema og format?

Neste →

→

Steg 3

Koherens

Henger bevisene sammen?

→

Steg 4

Forankret validitet

Stemmer påstandene
med virkeligheten?

Hvert steg bygger på det forrige. Vanskelighetsgraden øker mot høyre.

Diskusjon

Ka syns dokk?

Hvordan passer dette inn i arbeidsflyten til et ekte produktteam?

Mesteparten av KI-en vår bruker eksterne LLM-er via API — hvordan dekker vi den flyten?

Hva skal til for å pilotere dette?

Designprinsipper (referanse)

🔗 Innholdsadressert

📜 Kun tillegg (append-only)

🔁 Reproduserbar

⚖️ Policy-som-kode

🔍 Reviderbar

🚫 Feil raskt og tydelig

Disse prinsippene er innebygd i arkitekturen, ikke bare dokumentert.