Artikler · Drift og governance · 8 min. læsning
Fra AI-prototype til drift: hvad skal være på plads, før løsningen går live?
En AI-demo kan være bygget på to dage. Det betyder ikke, at virksomheden bør være afhængig af den på mandag. Ofte virker demoen så godt, at en kollega begynder at bruge den til rigtigt arbejde, før nogen har besluttet det.
Af Martin Egesø · Udgivet
Kort svar
Fra AI-prototype til drift kræver, at løsningen får en ejer, et formål, afgrænsede brugere, kendte data og leverandører, styret adgang, menneskelig kontrol, en plan for fejl og hændelser, dokumentation, træning og et review med måling af værdi. En POC viser, at noget kan lade sig gøre. En pilot viser, at det virker for få brugere. Først drift kræver, at alt det er på plads.
I artiklen 9 afsnit
- Hvad er forskellen på POC, pilot og drift?
- Hvad sker der, hvis en prototype bliver kritisk, uden at den er klar?
- Hvordan kommer I fra demo til drift?
- Go-live-tjekken: hvad skal være på plads?
- Før og efter: en AI-assistent til kundemails
- Hvorfor har en løsning brug for et sted, hvor drift og governance kan leve?
- Hvornår skal I vente med at gå live?
- Hvad kan I gøre nu?
- Ofte stillede spørgsmål
Det vigtigste
- En POC, en pilot og drift er tre forskellige ting med forskellige krav. En demo, der virker, er ikke det samme som en løsning, virksomheden kan afhænge af.
- Før go-live skal 15 punkter være på plads: ejer, formål, brugere, data, leverandører, adgang, integrationer, menneskelig kontrol, fejl, sikkerhed, dokumentation, træning, hændelser, review og måling af værdi.
- Uden ejer, support, dokumentation, fallback og ændringsstyring bliver en prototype en skjult afhængighed.
- Efter go-live fortsætter spørgsmålene. Drift og governance har brug for et fast sted at leve, ikke kun i hovedet på den, der byggede løsningen.
- Vent med at gå live, hvis ejer, data eller kontrol mangler.
Hvad er forskellen på POC, pilot og drift?
De tre begreber bliver ofte blandet sammen. Her er min forklaring, ikke en standard:
- POC (proof of concept): et hurtigt forsøg, der viser, at noget kan lade sig gøre.
- Pilot: en afgrænset test med rigtige brugere og rigtigt arbejde i en aftalt periode.
- Produktion eller drift: en løsning, virksomheden afhænger af i hverdagen, med ejer, support og opfølgning.
| Fase | Formål | Brugere | Data | Ansvar |
|---|---|---|---|---|
| POC | Vise, at det kan lade sig gøre | Udvikleren og få testere | Eksempeldata, helst uden kundedata | Den, der bygger den |
| Pilot | Vise, at det virker i hverdagen | En udvalgt gruppe | Rigtige data, afgrænset | Navngiven ejer og en aftalt periode |
| Drift | Levere en løsning, virksomheden afhænger af | Alle, der skal bruge den | Rigtige data, med aftaler på plads | Ejer, stedfortræder, support og review |
Faldgruben er springet fra POC til drift uden en pilot. Så får en løsning, der blev bygget til at imponere, pludselig lov til at levere. Det gælder al software, ikke kun AI. Se hvad der skal leve videre efter launch.
Hvad sker der, hvis en prototype bliver kritisk, uden at den er klar?
En prototype, der bliver kritisk uden at være klar, mangler typisk fem ting:
- Ejer. Ingen er ansvarlig. Den, der byggede den, har andre opgaver eller er skiftet job.
- Support. Når den går i stykker, ved brugerne ikke, hvem de skal spørge.
- Dokumentation. Ingen andre kan forstå, hvordan den virker, hvilke data den bruger, og hvorfor den svarer, som den gør.
- Fallback. Der er ingen plan for, hvordan arbejdet gøres, når løsningen ikke virker.
- Ændringsstyring. En leverandør ændrer en model, et system opdateres, og svarene ændrer sig uden en beslutning.
Konsekvensen er sjældent dramatisk. Den er praktisk: kunder får svar, ingen har kontrolleret, ingen kan svare på, hvem der besluttede at bruge løsningen, og viden om den sidder hos én person.
Hvordan kommer I fra demo til drift?
Modellen har fem trin: Forstå → Byg → Test → Sæt i drift → Bevar overblikket. Den er min egen måde at strukturere vejen på. Hvert trin hører sammen med nogle af de 15 punkter:
- Forstå: formål, brugere og ejer. Hvilket problem løses, for hvem, og hvem er ansvarlig? Har I ikke valgt løsning endnu, hjælper artiklerne om at købe, tilpasse eller bygge og om AI-agent, automatisering eller integration.
- Byg: data, leverandører, adgang og integrationer. Hvad bruger den, hvem leverer, hvem har adgang, og hvad er den koblet til?
- Test: menneskelig kontrol, fejl og sikkerhed. Hvor læser et menneske resultatet, hvad sker der ved fejl, og hvem kan se data?
- Sæt i drift: dokumentation, træning og hændelser. Kan andre drive den, og ved brugerne, hvad den kan og ikke kan?
- Bevar overblikket: review og måling af værdi. Hvornår vurderes den igen, og giver den den værdi, der var tanken?
Go-live-tjekken: hvad skal være på plads?
Go-live-tjekken samler de 15 punkter i fire områder. Gå dem igennem for jeres løsning, og markér de punkter, hvor svaret er "nej" eller "ved ikke".
Ansvar
| Punkt | Spørgsmål | Klar, når |
|---|---|---|
| Ejer | Hvem er ansvarlig for løsningen, og hvem er stedfortræder? Se hvem der ejer et AI-system | En navngiven person og en stedfortræder |
| Formål | Hvilket problem løser den, og hvad bruges den ikke til? | Formål og grænser er skrevet ned |
| Brugere | Hvem må bruge den, og hvad ved de om den? | Brugere eller roller er listet |
Data og adgang
| Punkt | Spørgsmål | Klar, når |
|---|---|---|
| Data | Hvilke data bruger den, og hvor kommer de fra? | Datatyper er skrevet ned, og persondata er vurderet |
| Leverandører | Hvem leverer modeller, værktøjer og hosting, og hvilke aftaler gælder? | Leverandører og vilkår er registreret og læst |
| Adgang | Hvem og hvad har adgang til hvad? | Kun nødvendig adgang, som kan fjernes |
| Integrationer | Hvilke systemer er den koblet til, og hvem ejer forbindelserne? | Forbindelser er beskrevet, se hvornår en integration giver mening |
Kontrol
| Punkt | Spørgsmål | Klar, når |
|---|---|---|
| Menneskelig kontrol | Hvor læser et menneske resultatet, før det bruges? | Kontrolpunkter er aftalt og afprøvet |
| Fejl | Hvad gør brugeren, når svaret er forkert, og hvordan meldes det? | Fejl kan meldes, og der er en fallback, fx den manuelle arbejdsgang |
| Sikkerhed | Hvem kan se data, og hvad sker der, hvis en konto bliver misbrugt? | Spørgsmålene er besvaret af den, der har ansvaret for it-sikkerhed |
Drift
| Punkt | Spørgsmål | Klar, når |
|---|---|---|
| Dokumentation | Kan en anden forstå og drive løsningen? Se hvad I skal dokumentere, når I bygger selv. | Opsætning, data, regler og kontakter er beskrevet |
| Træning | Ved brugerne, hvad den kan og ikke kan? Se artikel 4 | Brugerne har fået vejledning og kender reglerne |
| Hændelser | Hvad er en hændelse, hvem får besked, og hvor registreres den? Se hvad I gør, når AI laver en fejl | Der er en procedure, og ejeren kender den |
| Review | Hvornår vurderes løsningen næste gang? | Dato og ansvarlig er sat |
| Måling af værdi | Hvordan ser I, om den giver værdi? Se hvad manuel administration koster | Mål og måling er sat fra pilotens start |
Indgår der persondata, kan en hændelse være et brud på persondatasikkerheden. Brud skal anmeldes til Datatilsynet uden unødig forsinkelse og om muligt senest 72 timer efter, at I er blevet opmærksomme på det, medmindre det er usandsynligt, at bruddet indebærer en risiko for de berørte personer (GDPR, artikel 33). Derfor skal hændelsesproceduren være klar, før I går live. Se også ChatGPT og GDPR. Jeg er ikke jurist, og en konkret vurdering er en juridisk opgave.
Før og efter: en AI-assistent til kundemails
Et tænkt eksempel
En medarbejder bygger på to dage en AI-assistent, der foreslår svar på kundemails. Demoen virker, og kolleger begynder at bruge den. Tabellen viser forskellen mellem demoen og en driftsløsning.
| Område | Som demo | Som driftsløsning |
|---|---|---|
| Ejer | Den, der byggede den | Navngiven ejer og stedfortræder |
| Data | Rigtige kundemails som eksempel, uden vurdering | Kun nødvendige data, vurderet og dokumenteret |
| Leverandør | Den konto, der var hurtigst at oprette | Erhvervsaftale, hvor vilkårene er læst og registreret |
| Kontrol | Svar bliver nogle gange sendt direkte | Et menneske læser hvert svar, før det sendes |
| Fejl og fallback | Ingen plan | Fejl kan meldes, og den manuelle arbejdsgang er beskrevet |
| Review og værdi | Ingen | Fast dato og måling af fx svartid |
Hvorfor har en løsning brug for et sted, hvor drift og governance kan leve?
Go-live er ikke slutningen. Efter den dag kommer spørgsmålene igen: En kunde spørger, hvilke AI-værktøjer I bruger. En leverandør ændrer sine vilkår. En ny kollega spørger, hvem der ejer løsningen. Et review glemmes. Hvis svarene bor i hovedet på den, der byggede løsningen, eller i en mail, forsvinder de, når personen gør.
Det er her, SPOR er mere end en sidebemærkning. SPOR er et sted, hvor drift og governance kan leve, så de ikke afhænger af en person. Ud fra det, SPOR-siden beskriver, samler SPOR:
- et register over systemer og AI-værktøjer med formål, ansvarlig, pris og aftaler
- en AI Audit, der tjekker et nyt værktøj, før det tages i brug, og gør mangler til opgaver med en ansvarlig og en frist
- risiko pr. system og dataflowet vist som diagram
- en medarbejderportal med regler, vejledninger og træning
- hændelser, som registreres, så fristen kan ses
- krav og status med bevis og en ledelsesrapport, der kan gemmes som PDF
SPOR overvåger ikke selve løsningen, måler ikke værdien, yder ikke support og bygger ikke noget. SPOR afgør heller ikke, om en løsning er lovlig, og er hverken certificering eller garanti for, at alle krav er opfyldt. Når jeg bygger en løsning, kan SPOR være dokumentationslaget omkring den, så ejer, beslutning, data og review kan findes igen. Se SPOR og det enkle setup for AI governance.
Hvornår skal I vente med at gå live?
Vent, hvis nogen af disse forhold gælder:
- Ingen ejer. Ingen er ansvarlig, og ingen er stedfortræder.
- Data er uklare. I ved ikke, hvilke data løsningen bruger, eller om der indgår persondata, som ikke er vurderet.
- Ingen fallback. Hvis løsningen går ned, kan arbejdet ikke gøres på en anden måde.
- Resultater bruges uden kontrol. Ingen læser svarene, før de bruges.
- Vilkår er ikke læst. I har ikke tjekket, hvad leverandøren må gøre med data.
Vurderer løsningen mennesker, fx ansøgere eller medarbejdere, bør I tjekke, om den er højrisiko efter AI-forordningen. Datoer for de øvrige regler står i tidslinjen for AI-forordningen. Det er ikke en juridisk vurdering.
Hvad kan I gøre nu?
Gør dette, før en demo bliver til noget, virksomheden afhænger af:
- Navngiv en ejer og en stedfortræder.
- Afgør, om løsningen er en POC, en pilot eller i drift. Vær ærlig.
- Gå go-live-tjekken igennem, og markér de punkter, hvor svaret er "nej" eller "ved ikke".
- Sæt først en dato for go-live, når de røde punkter er ryddet.
Kort sagt: En demo viser, hvad der er muligt. Drift kræver, at nogen ejer, kontrollerer og følger op. Har I en demo, der skal blive til noget, så send den, så kigger vi på, hvad der mangler.
Næste skridt: Skriv ned, hvad I skal kunne dokumentere om løsningen. Læs Hvad skal I dokumentere, når I bygger jeres egen AI-løsning?.
Ofte stillede spørgsmål
Kan en POC gå direkte i drift?
Det bør den ikke. En POC viser, at noget kan lade sig gøre, ofte med eksempeldata og uden ejer, kontrol og dokumentation. Gå via en pilot med afgrænsede brugere og rigtige data, og gå først i drift, når go-live-tjekken er bestået.
Hvor lang tid skal en pilot vare?
Der er ingen fast længde. Aftal en periode og et mål, før piloten starter, så I kan afgøre, om løsningen skal i drift, ændres eller stoppes.
Hvem skal eje en AI-løsning?
En navngiven person, der kan træffe beslutninger om løsningen og er ansvarlig for, at den bliver fulgt op. Udpeg også en stedfortræder, så løsningen ikke afhænger af én person.
Skal alle AI-løsninger have en fallback?
Min anbefaling er ja, hvis nogen afhænger af løsningen. En fallback er den måde, arbejdet gøres på, når løsningen ikke virker, fx den manuelle arbejdsgang. Skriv den ned, og test den. Det er god praksis og ikke et lovkrav.
Om forfatteren
Martin Egesø er rådgiver og udvikler. Han hjælper virksomheder med at få mere ud af deres systemer og AI-værktøjer og bygger nye løsninger, når standarden ikke passer, med styr på brug, data og ansvar. Han driver MLE Gruppo ApS i Randers.
Mere om MartinArtiklen er generel vejledning og ikke juridisk rådgivning. Udgivet .