Observabilitet for AI-funktioner: fra black box til revisionsspor

En AI-funktion uden observabilitet er ikke bare svær at debugge. Den er en forpligtelse.

Ikke i metaforisk forstand. I juridisk forstand. EU AI Act artikel 15 stiller krav til nøjagtighed, robusthed og cybersikkerhed for højrisiko-AI-systemer — og det centrale instrument til at opfylde disse krav er logging og audit trails. En funktion, der ikke logger hvad den gør, hvem den gør det for, og hvad output var, kan ikke dokumentere compliance.

Men det er ikke kun compliance, der driver behovet. Det er driftsrealiteten. AI-systemer fejler anderledes end traditionel software. De fejler blødt — de giver forkerte svar i stedet for at kaste exceptions. Uden traces ved du ikke, hvornår det sker, hvorfor det sker, eller om det sker systematisk for en bestemt brugergruppe, på bestemte input-typer, eller ved bestemte tidspunkter på dagen.

Observabilitet for AI er ikke en nice-to-have. Det er grundlaget for at drive AI-features ansvarligt.

Hvad observabilitet er (og hvad det ikke er)

Observabilitet for AI-funktioner er ikke application performance monitoring. Det er ikke bare "er request-tiden under 2 sekunder?" Det er en struktureret registrering af:

Hvad modellen fik — prompt-tekst, system-instructions, kontekst-data, antal tokens.

Hvad modellen svarede — output-tekst, structured output, eventuelle tool-calls, antal output-tokens.

Hvad det kostede — input-tokens, output-tokens, cached tokens, estimeret pris.

Hvornår det skete — timestamp, latency, model-version, prompt-version.

Hvem det vedrørte — bruger-ID (hashed), workspace-ID, feature-ID.

Om det lykkedes — success/failure, fejlkode, model-confidence (hvor tilgængeligt).

Tilsammen udgør dette et revisionsspor. Det gør det muligt at besvare spørgsmålene: "Hvad sagde systemet til bruger X om emne Y den dag?" og "Er der et mønster i de fejlede kald i den seneste uge?" og "Er model-confidence faldet siden vi ændrede prompt-versionen?"

Et AI-system uden traces er en black box. En black box kan ikke auditeres. Noget, der ikke kan auditeres, kan ikke reguleres. I AI Act's optik er dette ikke et teknisk valg — det er et compliance-spørgsmål.

Trace-strukturen: functionId, tokens, latency

Den praktiske implementering starter med at definere en konsistent trace-struktur på tværs af alle AI-kald i systemet.

Mindstemønsteret bruger fem felter:

await generateText({
  model: models.fast,
  messages: [...],
  experimental_telemetry: {
    isEnabled: true,
    functionId: "capability.enrich.v2",  // semantisk ID, ikke system-ID
    metadata: {
      workspaceId: ctx.workspaceId,
      userId: hash(ctx.userId),           // aldrig klar-tekst bruger-ID
      promptVersion: "v2.3.1",            // semantisk versionering
      inputType: "capability-description",
    },
  },
})

functionId er det vigtigste felt. Det er det, der gør det muligt at gruppere traces på tværs af kald og identificere mønstre. Brug semantiske navne, ikke system-IDs: capability.enrich.v2 fortæller mere end ai_call_4892.

Versioner i promptVersion er kritiske til at korrelere output-kvalitetsændringer med prompt-ændringer. Uden dem er det umuligt at svare på: "Hvornår begyndte output at ændre sig, og hvad var det, vi ændrede?"

Et vigtigt sikkerhedsmæssigt punkt: log aldrig bruger-ID i klar tekst. Hash det. Det er persondata, og det skal behandles derefter — selv i interne systemer.

ADR-0001 metadata-felterne i praksis

For systemer, der gemmer AI-output i en database, er trace-loggen kun halvdelen af historien. Den anden halvdel er de metadata-felter, der gemmes direkte på AI-genererede records.

Et AI-output, der gemmes uden metadata, er en sort boks i jeres datamodel. I kan se, at en capability-beskrivelse er genereret af AI. I kan ikke se hvornår, med hvilken model, med hvilken prompt-version eller med hvilken confidence.

Et minimum-sæt af metadata-felter:

ai_model_version      text        -- "claude-sonnet-4-6-2026-01"
ai_prompt_version     text        -- "v2.3.1"
ai_confidence         numeric(3,2) -- 0.00 til 1.00
ai_classified_at      timestamptz  -- hvornår blev det genereret
ai_needs_review       boolean      -- flagget til menneskelig gennemgang
ai_trace_id           text         -- Langfuse trace ID
ai_input_tokens       integer      -- faktisk token-forbrug
ai_output_tokens      integer      -- faktisk token-forbrug
ai_cached_tokens      integer      -- tokens læst fra cache
ai_cost_usd           numeric(10,6) -- estimeret cost

Disse felter gør det muligt at:

Besvare audit-spørgsmål: "Hvad var model-versionen, da denne capability-beskrivelse blev genereret, og hvilken prompt-version brugte vi?"

Identificere forældede output: "Hvilke capabilities har AI-output genereret med en model-version ældre end 6 måneder?"

Estimere costs per workspace eller per feature: "Hvad koster capability-enrichment os pr. workspace pr. måned?"

Knytte database-records til Langfuse-traces via ai_trace_id: "Vis mig den fulde trace for denne record."

EU AI Act artikel 15 i praksis

Artikel 15 i EU AI Act stiller tre krav til højrisiko-AI-systemer: nøjagtighed, robusthed og cybersikkerhed. Hvad betyder det operationelt?

Nøjagtighed: Systemet skal producere output, der er korrekt i forhold til dets formål med en defineret fejlrate. Det kræver, at du løbende måler output-kvalitet — ikke bare ved launch, men over tid. Uden traces kan du ikke måle.

Robusthed: Systemet skal håndtere fejlscenarier uden at producere farlige outputs. Det kræver, at du kan identificere, hvornår systemet producerer uventet output, og hvad de specifikke input-karakteristika var. Uden traces kan du ikke identificere mønstre.

Cybersikkerhed: Systemet skal beskyttes mod prompt injection og adversarial inputs. Det kræver at logge inputs, der er markant anderledes end forventede mønstre. Uden input-logging kan du ikke opdage angrebsmønstre.

Artikel 15 er ikke et krav om at implementere et bestemt system. Det er et krav om at have kontrol over systemets opførsel. Observabilitet er det instrument, der giver dig den kontrol.

Hertil kommer artikel 12 — transparenskrav. Artikel 12 kræver, at højrisiko-AI-systemer logger tilstrækkelig information til at kunne identificere hvornår, af hvem og under hvilke omstændigheder systemet producerede et givent output. Det er præcis det, et godt trace-system leverer.

Hash-chain som tamper-evident audit trail

For systemer med strenge compliance-krav er det ikke tilstrækkeligt at have traces — de skal også kunne bevise, at de ikke er blevet manipuleret efterfølgende.

Et hash-chain-mønster løser dette:

Hvert AI-output i databasen beregner en SHA-256 hash af de centrale felter (id, model, value, classified_at) plus hash'en fra den forrige record. Det skaber en ubrydelig kæde: hvis én record ændres, er alle efterfølgende records' hashes ugyldige.

Dette er ikke et krav for de fleste systemer. Men for systemer, der understøtter GDPR DSAR-svar, regulatoriske indberetninger eller andre kritiske processer, er det en stærk garanti — og en relativt simpel at implementere.

Implementeringsplan: fire skridt

Observabilitet for AI-funktioner kan implementeres progressivt. Ikke alt på én gang.

Trin 1 — Basis-telemetri: Aktiver experimental_telemetry på alle generateText/streamText kald med konsistente functionId-navne. Hvis du bruger Langfuse, er det tilstrækkeligt til at starte med at se traces i Langfuse-konsollen.

Trin 2 — Metadata-felt i datamodellen: Tilføj ai_model_version, ai_prompt_version, ai_classified_at og ai_needs_review til tabeller, der gemmer AI-output. Disse fire felter alene giver dig mulighed for at identificere forældet output og audit-trail.

Trin 3 — Token-tracking: Tilføj ai_input_tokens, ai_output_tokens, ai_cached_tokens og ai_cost_usd til datamodellen. Brug disse til per-workspace cost tracking og til at identificere kald med uventede token-forbrug.

Trin 4 — AI-review flag: Implementér et mønster, der sætter ai_needs_review = true baseret på regler (lav confidence, kort output, token-forbrug over grænseværdi). Byg en review-queue, der eksponerer disse til en menneskelig reviewer.

Hvert trin tilfører observabilitet, der kan bruges uafhængigt af de andre.

Hvad observabilitet ikke løser

Det er vigtigt at afgrænse, hvad observabilitet er et instrument til, og hvad der kræver andre tiltag.

Observabilitet viser, hvad der skete. Det fortæller dig ikke, om det var det rigtige at gøre. En model, der systematisk giver lave confidence-scores på en bestemt input-type, viser sig i traces — men traces fortæller ikke, om det er et prompt-problem, et model-problem eller et data-problem.

Traces er et diagnostisk instrument, ikke en løsning i sig selv. De reducerer den tid, det tager at stille den rigtige diagnose — men diagnosen kræver stadig menneskelig fortolkning.

Observabilitet er heller ikke en erstatning for evaluering. Det fortæller dig, hvad der skete i produktion — det fortæller ikke, om systemets output er korrekt i alle mulige input-rum. Det kræver en struktureret eval-suite med golden datasets.

Observabilitet som grundlag for evaluering

Der er en vigtig sondring mellem observabilitet og evaluering, som mange teams overser.

Observabilitet fanger, hvad der sker i produktion — de faktiske kald, outputs og fejl fra ægte brugere med ægte inputs. Det er ukontrolleret og repræsentativt.

Evaluering tester, hvad systemet gør på et defineret sæt af input — din golden dataset med forventede outputs. Det er kontrolleret og reproducerbart.

De to hænger tæt sammen: produktions-traces fra observabilitet er den bedste kilde til at identificere nye testcases til din eval-suite. Kald, der scorede lavt på confidence, kald der fik klager, kald der brugte markant flere tokens end forventet — de er kandidater til at indgå i golden datasættet og forbedre din prompte og routing fremadrettet.

Observabilitet uden evaluering er reaktivt. Evaluering uden observabilitet er urealistisk. Tilsammen giver de dig kontrol over, hvad AI-systemet faktisk gør.

Hvad gøres i morgen

Observabilitet er en investering med afkast fra dag 1. Tre skridt for at komme i gang:

Uge 1: Aktiver experimental_telemetry på alle eksisterende AI-kald. Definer et konsistent functionId-navngivningsskema. Verificér, at traces vises i Langfuse.

Uge 2: Tilføj ai_model_version, ai_prompt_version og ai_classified_at til de tabeller i databasen, der gemmer AI-output. Start med de vigtigste features.

Uge 3: Implementér ai_needs_review-flaget med én simpel regel (eksempel: ai_confidence < 0.7). Byg en minimal review-liste, der eksponerer flagget output.

Byg det i trin. Men start i dag. Hvert kald uden trace er en mulighed for at diagnosticere og lære, der er tabt.

Referencer

[1] Europa-Parlamentets og Rådets forordning (EU) 2024/1689 om kunstig intelligens (AI Act), Artikel 15 — Nøjagtighed, robusthed og cybersikkerhed, officielt tilgængeligt på eur-lex.europa.eu.

[2] Artikel 12 (EU) 2024/1689 — Registreringspligt og logging af højrisiko AI-systemer, eur-lex.europa.eu.

[3] Langfuse, "AI Observability & Analytics", tilgængeligt på langfuse.com/docs (besøgt 2026-04-23).

[4] Anthropic, "Usage Metadata and Caching Statistics", tilgængeligt på docs.anthropic.com/en/api/messages (besøgt 2026-04-23).