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?"

ADR-0001 metadata-felterne i praksis

ADR-0001 (Spekirs datamodelafdeling) definerer et sæt obligatoriske felter for alle tabeller, der gemmer AI-output. Disse felter er ikke bureaukrati — de er revisionssporets datadel.

For et output-register (eksempel: capability-beschrivelse genereret af AI) ser feltstrukturen sådan ud:

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-beschrivelse 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?"

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.

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.

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] Langfuse, "AI Observability & Analytics", tilgængeligt på langfuse.com/docs (besøgt 2026-04-23).

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