Du har tallene. De ligger i et datavarehus, og for å få svar må noen skrive en spørring. Nå kan en AI-assistent gjøre den biten, hvis du setter rammene riktig. Dette er mønsteret, det som går galt når rammene mangler, og hva det krever av dere.
Et datavarehus er en samling tabeller der bedriften har samlet tall fra mange systemer. En spørring er en instruks som henter tall derfra, ofte skrevet i språket SQL. Mønsteret her er at en AI-assistent får lesetilgang gjennom en kobling, skriver spørringa for deg, og leverer tallet med spørringa synlig.
Dette er et generelt mønster, ikke en beskrivelse av et bestemt sted. Eksempelet er konstruert, og ingen tall, tabeller eller systemer fra noen virkelig bedrift er med.
Koblingen heter ofte MCP, forkortet fra Model Context Protocol. Det er en åpen standard for å koble AI-programmer til eksterne systemer, som databaser, filer og verktøy. Du kan lese mer om den i begrepssida om MCP og connectors. Poenget her er at koblingen er det eneste stedet assistenten kommer inn i dataene, og at den som bygger koblingen bestemmer hva som er mulig gjennom den. Ordet assistent bruker jeg om en AI som kan kjøre spørringer gjennom koblingen. Det er en enkel agent: den gjør verktøykall, og dere bestemmer hvilke.
Enkle tellinger og oppdelinger går fort: antall per måned, de ti største, to perioder mot hverandre. Du kan følge opp i samme samtale. «Del det på region» er en setning, ikke en bestilling. Den som kan SQL får et utkast å rette i stedet for et blankt ark. Tida flyttes fra å skrive spørringa til å kontrollere den, og det er riktig sted å bruke den. Jeg har ikke målt hvor mye tid det sparer. Det er hva en pilot bør måle: tid fra spørsmål til kontrollert svar, før og etter.
Det som går galt, går sjelden galt med feilmelding. Det er det som gjør det farlig.
Et datavarehus har ofte flere tabeller som ser like ut: en for bestillinger, en for leveranser, en for fakturaer og noen som er gamle kopier. Assistenten velger den med det mest passende navnet, og det er ikke alltid den riktige.
«Kunde», «aktiv», «levert» og «omsetning» betyr ulike ting avhengig av hvem du spør i bedriften. Assistenten velger én tolkning og sier ikke fra at den valgte.
Skriver den en spørring uten å ha sett skjemaet, bruker den navn som høres riktige ut. Noen ganger finnes de ikke, og du får en feilmelding, som er den snille utgaven. Verre er det når en kolonne med nesten samme navn finnes og betyr noe annet.
Den farligste feilen gir et rundt, pent tall i et ryddig svar. Kobler spørringa sammen to tabeller feil, kan den telle samme rad flere ganger. Det kommer ingen feilmelding. Tallet er bare for høyt.
Det avhenger av hva «levert» betyr. Skjemaet har tre datoer: bestilt, sendt og fakturert. Det godkjente nøkkeltallet «leverte enheter» er definert med sendt-datoen, så jeg har kjørt definisjonen slik den står: 1 240.
Antakelser: kalenderåret 2025, kansellerte ordrer er ikke med. Spørringa under er selve definisjonen, så du kan sjekke den.
SELECT sum(antall) FROM leveranser WHERE sendt_dato BETWEEN '2025-01-01' AND '2025-12-31' AND status <> 'kansellert'
Seks ting skiller en assistent du kan stole på fra en du må dobbeltsjekke hver gang. Alle seks handler om å begrense, ikke om å gjøre modellen smartere.
Be assistenten liste tabeller og kolonner, og si hvilke den vil bruke og hvorfor. Da ser du feil tabell før den har telt noe.
Finnes det et definert nøkkeltall for «leverte enheter», skal assistenten bruke det og ikke lage sitt eget. Da eier noen definisjonen, og alle får samme tall.
Et svar uten spørring er en påstand. Et svar med spørring kan kontrolleres av noen som kan lese den, og kan oversettes av assistenten for de som ikke kan.
Koblingen skal ikke kunne skrive, slette eller endre. Det løses i koblingen, ikke ved å be modellen om å la være.
Assistenten skal se det du ser, ikke mer. Da gjelder reglene bedriften allerede har for hvem som får se hva, i stedet for en ny samling regler ingen har overblikk over. Det krever at hver bruker logger inn mot kilden selv. En delt nøkkel gir assistenten det nøkkelen ser, ikke det du ser, og det er ikke en innstilling du bare slår på.
Hold tabeller med personopplysninger utenfor, eller gi bare aggregerte visninger. Det er enklere å la være å gi tilgang enn å rydde opp etterpå.
Merk at tre av de seks er låser og ikke instrukser: bare lesing, egne rettigheter og ingen personopplysninger. En instruks til modellen er en oppfordring. En rettighet i systemet er en sperre.
Det er ikke bare en kobling. Det er folk som eier noe, og noen som holder det i gang etter at demoen er over.
Én som eier tallene og definisjonene. Én som bygger og driver koblingen, enten det er IT, en konsulent eller leverandøren av datavarehuset. Én som godkjenner hvilke tabeller assistenten får se. Og de som bruker den og kontrollerer svarene.
Jeg har ikke en målt tid å gi deg. Den varierer med hvor ryddige definisjonene er, og det er dem og tilgangene som tar tid, ikke selve koblingen. Regn med uker, ikke dager, og mål det i piloten. Det er et anslag, ikke noe jeg har målt.
Koblingen må vedlikeholdes. Test jevnlig at den fortsatt bare kan lese og fortsatt bruker brukerens egne rettigheter, også etter en oppdatering. Hold definisjonene oppdatert. Følg kostnaden når flere begynner å spørre, se hva det koster. Spørsmål og svar lagres et sted, og noen eier det stedet.
Før dere går videre: en eier per definisjon, en test som kjøres jevnlig, en plan for hva som skjer når et tall viser seg å være feil, og et tak på kostnaden. Mangler ett av dem, er det fortsatt en pilot.
Første steg i morgen: skriv ned definisjonen av ett tall dere ofte spør om, og hvem som eier den. Klarer dere ikke det, er det ikke koblingen som er flaskehalsen.
Du trenger ikke kunne SQL for å stille disse. Du trenger bare å kreve svar på dem.
Kan du ikke få svar på de tre første, bør du vente med å starte. Det er billigere å bruke en uke på definisjonene enn å bruke et kvartal på å finne ut hvorfor tallene ikke stemmer.
Du trenger ikke et datavarehus for å prøve disiplinen. Har du en liten tabell du har lov til å dele, kan du lime den inn i en vanlig samtale og be om dette først.
Jeg skal stille deg spørsmål om data. Før du svarer: 1. List tabellene og kolonnene du ser. 2. Si hvilke du vil bruke, og hvorfor. 3. Si hvilke definisjoner du antar, for eksempel hva «aktiv» betyr. 4. Vis spørringa du kjører. 5. Si hvordan jeg kan kontrollere svaret mot en kilde jeg stoler på. Er du usikker på en kolonne eller en definisjon, spør meg før du gjetter. Første spørsmål: [skriv spørsmålet ditt her]
Oppdatert oktober 2026. Siden beskriver et generelt mønster og ikke et bestemt system eller en bestemt bedrift. Eksempelet med leveranser er konstruert. MCP som åpen standard: modelcontextprotocol.io, lest oktober 2026.