AI verktøyvalg starter ikke med modellen, det starter med dataene dine

Bjørnar Aassveen
1 day ago
4 min read

Det er lett å starte i feil ende når man snakker om AI i virksomheter.

“Vi trenger GPT‑4, Copilot, Claude eller X”.

Men det er ikke der diskusjonen bør begynne.

Satt på spissen:

Du kan bruke hvilken som helst modell, så lenge du bare lager vaffelrøre.

I det øyeblikket du begynner å bruke virksomhetsdata, er det ikke lenger et modellvalg.

Det er et governance og risikospørsmål.

I denne posten går jeg gjennom hvordan du faktisk kan angripe dette i praksis:

Hvordan finne ut hvilke AI-verktøy som er i bruk
Hvordan kartlegge hvilke data som finnes
Hvordan få på plass klassifisering og arv ned i datalagene

Start med realiteten: Du har allerede AI i organisasjonen

De fleste organisasjoner har ikke et “AI prosjekt”.

De har:

Brukere som tester tilfeldige tjenester
SaaS applikasjoner som bygger inn AI
Utviklere som kobler API-er mot modeller

Hvis du ikke har oversikt, er det ikke fordi det ikke brukes.

Hvordan få oversikt

Typisk første steg er å bruke det du allerede har:

Microsoft Defender for Cloud Apps / Defender for Cloud

Oppdager skytjenester og bruksmønstre
Kan identifisere AI relaterte tjenester (ChatGPT, Copilot, osv.)
Gir innsikt i dataflyt og risikoprofil

Poenget er ikke å få et perfekt bilde, men et overordnet blikk på hvor mange AI tjenester som finnes og hvordan de brukes i din organisasjon.

Neste steg: Hvilke data behandles egentlig?

Når du har et overblikk over alle AI tjenester som rører seg i din organisajon, er det veldig behagelig å kunne vite hvilke data som behandles i de ulike AI tjenestene.

Jeg mener dette er nøkkelen for å forstå behovet og bruken, vi kan ikke hopper direkte til “vi må ha policy” uten en data kartlegging, da blir policyene bare gjetting og ofte strengere enn de behøver å være fordi vi må "sikre alt, sånn i tilfelle". Det finnes mange verktøy og sikringstiltak allerede som hjelper deg godt på vei, men det viktigste sikringstiltaket er brukeropplæring, trening og adopsjon! Det er vanskelig å vurdere data om man ikke sitter å behandler dataen selv. Ofte er det egne ord og uttrykk, sjargong osv. i en avdeling eller funksjon som er vanskelig for verktøy å fange opp som sensitivt eller ei.

Verktøy som faktisk hjelper

Microsoft Purview Data Explorer

Gir oversikt over hvilke datatyper som finnes i M365
Identifiserer sensitive opplysninger (personnummer, kredittkort, osv.)
Lar deg analysere hvor data ligger

Sensitive Information Types (SIT)

Ferdige og egendefinerte mønstre for sensitiv data
Kan brukes både i analyse og policy enforcement

Eksempler:

Personopplysninger
Helseopplysninger
Interne vurderinger / beslutningsgrunnlag

Dette gir deg et faktisk bilde av:

Hvilke data som finnes
Hvor de ligger
Hvor de potensielt kan eksponeres via AI

Klassifisering: Der teorien møter praksis

Å vite hva dataene er, er en ting. Å gjøre det operasjonelt er noe helt annet.

Her trenger du en modell som:

Er forståelig for virksomheten
Kan implementeres teknisk
Gir reell effekt i verktøyene dine

Et praktisk rammeverk: TLP

DigDir har en fin veiledning og anbefaling om bruk av TLP til dataklassifisering: Steg 4: Vurdere tilgangsnivå | Digdir

allmenn tilgang («grønn»)
betinget tilgang («gul»)
ikke-allmenn tilgang («rød»)

Fordelen er enkelhet:

Lett å forklare
Lett å bruke i vurderinger
Kjent blant andre offentlige etater
Kan mappes mot tekniske kontroller

Der magien skjer: Arv ned i plattformen

Det som skiller fine PowerPoints fra faktisk kontroll, er arv.

Hvis klassifiseringen ikke følger dataene, så har du i praksis ikke klassifisering.

Hvordan få det til i M365

Sensitivity Labels i Microsoft Purview

Implementerer klassifisering teknisk
Kan:
- Merke dokumenter og e-post
- Kryptere innhold
- Styre deling

Typisk flyt:

Klassifisering definert (f.eks. TLP)
Oversatt til Sensitivity Labels
Automatisk eller manuelt tagging av data
Policyer knyttes til label (DLP, access, deling)
Arver med data videre (OneDrive, Teams, SharePoint, e-post)

Dette er nøkkelen i en AI kontekst: Når data brukes av AI verktøy internt (f.eks. Copilot), så følger klassifiseringen med. Dette gjør igjen at man ofte kan tillate bredere bruk av verktøyene, fordi man har kontroll på hvilke type data man mater de med.

Realiteten: Mye av dag til dag data produseres i M365

IT-miljøet bruker mange verktøy (SaaS, plattformer, spesialsystemer)
Data flyter på tvers av systemer
Integrasjoner kobler alt sammen

Men samtidig:

Sluttbrukere skriver dokumenter i Word
Samhandler i Teams
Lagrer i SharePoint og OneDrive
Sender e-post
Deler informasjon på tvers av organisasjonen

Og IT-folk er ikke noe unntak.

Konsekvensen er ganske enkel: En veldig stor andel av virksomhetsdataene dine ender opp i Microsoft 365, enten direkte eller indirekte.

Hva betyr dette for valg av AI-verktøy? Når du har gjort grunnarbeidet med å:

Kartlegge hvilke data du har
Forstå hvor de ligger
Få på plass klassifisering

…så endrer problemstillingen seg ganske fundamentalt.

Du går fra en “feature diskusjon” til en data og risikodiskusjon.

Fra:

“Hvilken modell er best?”

Til:

“Hvilke data kan dette verktøyet få tilgang til, og under hvilke betingelser?”

AI valg er egentlig ganske enkelt, når grunnarbeidet er gjort. Hvis du kun lager vaffelrøre, velg hva du vil. Men i det øyeblikket du bruker virksomhetsdata: Er det dataene som bestemmer, ikke modellen eller verktøyet.

Tenk så nydelig det hadde vært om vi faktisk klarte å mappe klassifisering til konkrete guardrails.

Altså ikke bare fine farger i en PDF som ingen leser, men faktiske krav som betyr noe i praksis. Selv om denne posten nevner verktøy og sikringstiltak linket til Microsoft porteføljen er det like relevant for andre tilbydere. I utgangspunktet spiller det ingen rolle om verktøyet du bruker heter Copilot, ChatGPT eller Claude så lenge spillereglene og guardrailsene er de samme.

For eksempel: