Dataprodukter som fundament for AI
Emneknagger: #dataprodukter, #AI-klare data, #agentic BI, #semantisk lag, #data governance
Hvorfor analytics-klar ikke er det samme som AI-klar, og hva som må på plass.
AI endrer hvem som bruker dataene
Et dataprodukt har historisk hatt én type bruker: et menneske med kontekst. En analytiker som vet at “ordre” ekskluderer testkunder, at “aktiv kunde” har en spesiell definisjon i Q3-rapporten, og at det var en kjent feil i pipeline 12.-14. mars.
Denne brukergruppen er i ferd med å bli en minoritet.
LLM-agenter leser dokumentasjonen deres som autoritativ. De har ingen kollega å spørre, ingen Slack-historikk å bla gjennom, og ingen magefølelse for hva som er feil. Manglende beskrivelser fylles med modellens egne slutninger. Ingen feilmeldinger, bare feil som vokser seg stadig større.
Tristan Handy (dbt Labs) har spådd at agent-initierte spørringer vil bli mer vanlige enn menneskelige innen 12 måneder. Selv om tallet er optimistisk, peker retningen mot at porteføljen dere bygger nå skal tjene en brukergruppe som i dag ikke er hovedkonsumenten.
Analytics-klar er ikke det samme som AI-klar
To ulike dimensjoner, to ulike investeringer:
| Analytics-klar | AI-klar | |
|---|---|---|
| Struktur | Stjerne-skjema, pre-aggregert | Semantisk rik, kontekstuell |
| Oppdatering | Daglig oppdatering holder | Hyppig oppdatering foretrukket |
| Metadata | Valgfritt, hjelper analytikeren | Obligatorisk - er konteksten |
| Granularitet | Aggregert | Fullt detaljnivå med kontekst |
| Forretningsregler | I hodet til analytikeren | Eksplisitt kodet |
De fleste norske dataplattformer er bygd for det første, ikke det andre. Det betyr ikke at dere må bygge alt om. Det betyr at dere må vite hvilke dataprodukter som må bli AI-klare, og investere i å bygge kontekst for disse.
Innhenting vs resonnering
David Effiong (Data Cult) skiller mellom to ulike krav:
- Innhenting: får vi riktig tall fra riktig sted? Løses av dataplattformen pluss et rent semantisk lag. De fleste moderne teknologi-stacks er gode her.
- Resonnering: vet AI hva tallene betyr, når de kan stoles på, og hva de ikke må forveksles med? Dette løses med kontekstlaget, og de færreste har bygget noe her ennå.
Et AI-system kan hente churn_rate for forrige kvartal. Men for å svare på hvorfor, trenger AI definisjonen, vite om definisjonen nylig endret seg, ha oversikt over kjente datakvalitetsproblemer, og eventuelle eksterne faktorer. Uten dette produserer det alltid et svar - men ikke nødvendigvis et riktig svar.
“Tenk på det semantiske laget som en kontrakt mellom teamet ditt og AI-agenten. Den kontrakten må være langt mer fullstendig enn da hovedkonsumenten var et menneske.” - David Effiong
Det mest effektive tiltaket: dokumentere det teamet vet
Et kontrollert eksperiment fra Data Cult (Opeyemi Fabiyi, 2026) testet 13 forretningsspørsmål mot en AI-agent og la til ett kontekstlag om gangen, uten å bytte modell:
| Iterasjon | Nøyaktighet |
|---|---|
| Råkilder, ingen kontekst | 0% |
| Modellert tabell, ingen berikelse | 0% |
| + rike kolonnebeskrivelser | 15% |
| + forretningsregler | 77% |
| + metrikker, eksempler, evaluering | 92% |
Modellen ble aldri byttet. Hele forbedringen kom fra konteksten. Den største forbedringen kom fra å skrive ned forretningsregler som levde i hodene til analytikerne.
Et felt slot_status med verdiene Open og Filled fikk agenten til å filtrere på slot_status = 'Available', en verdi som ikke finnes i dataene. Spørringen returnerte null. Ingen feil. Et galt svar, som var vanskelig å oppdage. En beskrivelse som forklarte at Open betyr tilgjengelig, løste det umiddelbart.
Ni dimensjoner for AI-modenhet
Modern Data 101 (Camila Barreto Lima) har utviklet et 9-dimensjoners rammeverk for å vurdere AI-modenheten til enkelt-dataprodukter. Det utvider de praktiske kravene fra kapittel 1 til 7:
| # | Dimensjon | Spørsmålet AI-agenten ikke kan stille selv |
|---|---|---|
| 1 | Discoverability | Er produktet søkbart i en katalog? |
| 2 | Addressability | Har det en stabil identifikator som ikke endres? |
| 3 | Trustworthiness | Er kvalitet og freshness dokumentert? |
| 4 | Self-describingness | Kan en konsument forstå produktet uten å spørre noen? |
| 5 | Interoperability | Kan det konsumeres på tvers av systemer uten skreddersøm? |
| 6 | Security | Er tilgangskontroll designet og integrert i løsningen, og ikke hektet på? |
| 7 | Value | Hvem bruker dette til hva? |
| 8 | Autonomy | Eies det av et domene-team uten sentralisert flaskehals? |
| 9 | Understandability | Forstår konsumenten hva de faktisk får, inkludert begrensninger? |
To dimensjoner er spesielt kritiske for AI-konsum: Understandability (agenten kan ikke spørre en kollega) og Trustworthiness (agenten gir ingen feilmelding for utdaterte data - bare gale svar levert med selvsikkerhet).
Forhåndssjekk før agentbasert analyse
Et dataprodukt med lav score på 1, 2 og 9 (ikke synlig, ingen stabil identifikator, uklar semantikk) gir inkonsistente AI-resultater. Bruk matrisen til å rangere porteføljen og prioritere innsats:
- Lav Discoverability og Trustworthiness blokkerer steget mot dataprodukter.
- Lav Self-describingness og Understandability blokkerer steget mot agentbasert analyse.
Modenhetsmatrisen henter samme spørsmål inn i en strukturert form, som lar dere velge hvilke produkter som skal AI-modnes.
Hva dette betyr for dere som bygger
Dere trenger ikke gjøre om alt. Disse tre tiltakene gir best kost/nytte i en AI-verden:
| Tiltak | Hva det betyr i praksis | Effekt |
|---|---|---|
| Kolonnebeskrivelser med betydning | “Open betyr at slottet er tilgjengelig for booking”, ikke “varchar(20)” | Det mest effektive tiltaket i Fabiyi-eksperimentet |
| Forretningsregler eksplisitt kodet | Standardfiltre, kjente unntak, definisjoner som varierer mellom domener - det en ny analytiker lærer i måned 1 | +62 prosentpoeng nøyaktighet i samme eksperiment |
| Kontekstlag versjonert som kode | Når en metrikk-definisjon endres, endres dokumentasjonen med den | Forhindrer at foreldet dokumentasjon genererer feil i stor skala uten at noen ser det |
Disse er ikke nye dataprodukter. De er det dere allerede gjør i kapittel 1 til 7, gjort tydelig nok til at en agent kan lese det.
Neste steg er å håndtere endringer i et produkt som flere - inkludert agenter - bygger på: Endring og utfasing.
