De fleste AI-demoer ser fantastiske ud.
En chatbot opsummerer en politik. En model forklarer en kontrol. Nogen stiller et spørgsmål om ISO 27001, og svaret dukker op med det samme.
Så begynder enterprise-spørgsmålene.
Hvor blev data af? Hvilken model behandlede dem? Blev prompten logget? Kan vi bevise, hvem der havde adgang? Kan AI'en kun læse data, eller kan den også ændre ting? Hvad sker der, når compliance-teamet vil bruge AI, men jura, sikkerhed og IT allerede har godkendt en anden AI-opsætning?
Det er her, mange AI-funktioner bryder sammen. Ikke fordi modellen er dårlig, men fordi arkitekturen er forkert til enterprise-brug.
Derfor mener vi, at MCP, Model Context Protocol, er et så vigtigt skridt fremad.
MCP giver platforme en struktureret måde at forbinde AI til forretningssystemer, værktøjer og data. Endnu vigtigere er det, at forbindelsen kan ske uden at tvinge hver kunde ind i den samme AI-udbyder, det samme dataflow eller den samme governance-model.
For virksomheder betyder det noget.
Medbring din egen AI bør være standarden
Virksomheder indfører ikke AI i et vakuum. De har indkøbsregler, databehandleraftaler, sikkerhedsgennemgange, interne AI-politikker, godkendte leverandører, logningskrav og nogle gange strenge krav til dataopbevaring.
Så når en softwareleverandør tilføjer "AI" ved at hardkode én ekstern modeludbyder, tvinges kunden ofte ud i et akavet valg: acceptere en ny AI-leverandør og alt det governance-arbejde, der følger med, eller deaktivere funktionen helt.
Sådan bør enterprise-AI ikke fungere.
Med MCP er den bedre model Bring Your Own AI.
Hvis en organisation allerede har godkendt en bestemt LLM, deployment-model, region, opbevaringspolitik og overvågningsopsætning, bør platformen respektere det. Kunden bør kunne forbinde det AI-miljø, de allerede har tillid til, i stedet for at sende compliance-data gennem en model, leverandøren har valgt.
Det er især vigtigt i GRC- og sikkerhedsarbejde. Compliance-platforme indeholder følsomt materiale: risici, kontroller, politikker, revisionsdokumentation, leverandøroplysninger, udbedringsplaner, internt ejerskab og nogle gange oplysninger om kunder eller medarbejdere.
De data bør ikke flytte sig et uventet sted hen, bare fordi nogen vil have hjælp til at udforme en kontrolbeskrivelse.
Datakontrol er ikke en detalje
Mange AI-samtaler behandler datahåndtering som en juridisk fodnote. I enterprise-compliance er det helt centralt.
Hvis et team beder AI om at opsummere revisionsdokumentation, sammenligne kontroller eller forklare mangler i forhold til en ramme, kan prompten indeholde meget følsomme operationelle oplysninger. Selv outputtet kan afsløre interne svagheder eller udbedringsprioriteter.
For nogle organisationer er det fuldt acceptabelt at bruge en hostet tredjepartsmodel. For andre rejser det spørgsmål om behandlingssted, underdatabehandlere, opbevaring, adgang og regulatoriske forpligtelser.
MCP muliggør en anden arkitektur: AI'en kan køre gennem organisationens egen godkendte opsætning, mens platformen kun eksponerer de værktøjer og den kontekst, brugeren har adgang til.
Den skelnen er afgørende.
Platformen behøver ikke at blive kundens undtagelse fra AI-governance. Kunden bevarer kontrollen over modellen, infrastrukturen og politikkerne omkring den.
AI bør ikke skabe en ny brugsskat
Der er også et praktisk adoptionsproblem: omkostninger.
Hvis enhver nyttig AI-handling skaber token-angst eller en separat leverandørregning, vil folk tøve med at bruge den. Det er et problem, fordi AI er mest værdifuld i compliance, når den bliver en del af det daglige arbejde.
Et compliance-team bør kunne bede om hjælp til at forstå et krav, udforme en opgave, opsummere dokumentation, sammenligne en kontrol med en ramme eller forberede sig til en revision uden at spekulere på, om de bruger af et separat AI-budget.
Når virksomheden medbringer sin egen AI, passer brugen ind i organisationens eksisterende infrastruktur, plan og omkostningsmodel. Der kan stadig være interne AI-omkostninger, naturligvis, men de styres af kunden og er ikke skjult i et platformsspecifikt AI-tillæg.
Det gør adoption lettere og mere forudsigelig.
Sådan implementerede vi MCP i ArbaGRC
Hos Arba Security byggede vi ArbaGRC ud fra en simpel idé: compliance bør blive til operationelt arbejde, ikke statisk dokumentation.
Krav bliver til opgaver. Opgaver får ejere. Dokumentation indsamles. Fremdrift følges. Revisionsparathed bliver synlig. Rammer som ISO 27001, NIS2, CIS 18, NIST og andre bliver til håndterbare daglige arbejdsgange.
Da vi tilføjede AI-funktioner, ønskede vi ikke, at AI skulle blive en genvej uden om governance. Vi ønskede, at den skulle understøtte governance.
Derfor implementerede vi MCP i ArbaGRC.
Gennem MCP kan organisationer forbinde deres egen godkendte AI til platformen. AI'en kan assistere med compliance-arbejde, samtidig med at den respekterer virksomhedens eksisterende AI-beslutninger, datagrænser og sikkerhedsmodel.
Men den vigtigste del er ikke bare at forbinde AI. Det er at styre, hvad AI'en kan tilgå, og hvad den kan gøre.
ArbaGRC understøtter granulær adgangskontrol for både funktioner og data. Det betyder, at AI-assisterede arbejdsgange følger den samme tilladelseslogik som brugeren og organisationen. AI får ikke automatisk fuld adgang, bare fordi den er forbundet.
Nogle brugere må måske kun læse bestemte data. I så fald kan AI hjælpe med at opsummere, forklare eller hente information, men den kan ikke ændre poster. Andre brugere har måske læse- og skriverettigheder, hvilket lader AI hjælpe med at oprette opgaver, opdatere dokumentation, foreslå forbedringer eller understøtte udbedringsarbejdsgange.
Den adskillelse betyder noget.
I compliance er "AI kan læse dette" og "AI kan ændre dette" helt forskellige risikoniveauer. At behandle dem ens ville være uansvarligt.
Pointen er ikke AI overalt
Målet er ikke at tilføje AI for at tilføje AI.
Målet er at gøre AI nyttig i enterprise-compliance uden at svække de kontroller, som compliance afhænger af.
MCP er med til at gøre det muligt. Det lader organisationer medbringe deres egen AI, holde data under deres egen governance, undgå platformsspecifikke AI-omkostningsoverraskelser og anvende granulær adgangskontrol på AI-assisteret arbejde.
Det er forskellen mellem en imponerende AI-demo og en enterprise-klar AI-arkitektur.
For GRC betyder den forskel noget.