Du har haft et godt møde om AI. Tavlen er fuld af idéer, og alle kan se mulighederne. Men mandag morgen er arbejdet stadig det samme: Ingen ved, hvilken opgave der skal ændres, hvem der kontrollerer AI'ens svar, eller hvordan I afgør, om forsøget virker.

For en mindre virksomhed er det dyre problem ikke nødvendigvis konsulentens timer. Det er at købe aktivitet uden et brugbart arbejdsprodukt: en inspirationsworkshop, en promptsamling eller en teknisk demonstration, som ikke bliver en del af hverdagen.

En AI-konsulent bør derfor bedømmes på konkrete leverancer. Efter et afgrænset forløb skal virksomheden kunne se, hvad der er bygget, hvordan det testes, hvornår det stopper, og hvem der har ansvaret.

Kort svar: Hvad bør en AI-konsulent konkret levere?

Til en mindre virksomhed bør en afgrænset AI-leverance som minimum indeholde:

  1. ét præcist problem og et tydeligt scope;
  2. en beskrivelse af arbejdsgangen før ændringen;
  3. en begrundet beslutning om AI, klassisk automation eller ingen automation;
  4. en testbar arbejdsgang med input, instruktion og output;
  5. kontrolpunkter, ansvar og stopregel;
  6. et dokumenteret testforløb med fejl og observationer;
  7. en enkel aflevering og anbefaling: stop, fortsæt eller implementér mere.

Ikke alle opgaver kræver alle integrationer fra første dag. Men et tilbud bør gøre det tydeligt, om du køber afklaring, undervisning, en pilot eller implementering. De fire ting er ikke det samme.

1. Ét problem — ikke en lang liste over AI-idéer

Første leverance er en afgrænsning, som en ejer kan godkende.

“Vi vil bruge AI i administrationen” er ikke et problem. “Vi vil teste, om indgående servicehenvendelser kan blive til faktuelt korrekte svarudkast, som en medarbejder godkender” er langt tættere på.

Afgrænsningen bør beskrive:

  • hvilken tilbagevendende opgave der undersøges;
  • hvem der udfører den i dag;
  • hvilket input opgaven starter med;
  • hvilket output der skal være klar til hvem;
  • hvad der udtrykkeligt ligger uden for forløbet;
  • hvem der ejer beslutningen i virksomheden.

Hvis konsulenten ikke kan gøre problemet konkret, er det for tidligt at vælge model, værktøj eller integration.

2. Et ærligt billede af arbejdsgangen før AI

En løsning kan kun vurderes, hvis udgangspunktet er kendt. Konsulenten bør derfor kortlægge den nuværende arbejdsgang i et format, som virksomheden kan genkende.

Det behøver ikke være en stor procesrapport. For én opgave er det ofte nok at vise:

  1. hvor inputtet kommer fra;
  2. hvilke valg medarbejderen træffer;
  3. hvilke kilder der bruges;
  4. hvor fejl eller ventetid typisk opstår;
  5. hvilket system eller dokument outputtet ender i;
  6. hvem der godkender det.

Kortlægningen kan også afsløre, at problemet slet ikke er manglende AI. Måske mangler der bare en standardskabelon, én ansvarlig eller et fast sted til godkendte oplysninger.

3. En begrundet beslutning om løsningsformen

En AI-konsulent bør kunne anbefale andet end AI.

Bed om en kort beslutning mellem mindst tre muligheder:

  • Manuel skabelon: når variationen er lille, og en person hurtigt kan udfylde faste felter.
  • Klassisk automation: når processen følger stabile hvis-så-regler og identiske systemtrin.
  • Generativ AI: når inputtet varierer, og opgaven kræver fortolkning, sortering eller et tekstudkast, som kan kontrolleres.

Den bedste løsning kan også være en kombination. AI kan eksempelvis foreslå en kategori eller en kladde, mens klassisk automation flytter det godkendte output videre. Men delene bør testes hver for sig, før de kobles sammen.

Denne beslutning beskytter virksomheden mod at købe en kompliceret AI-løsning til et problem, som en fast regel kunne løse mere stabilt.

4. En arbejdsgang, der kan testes fra input til output

En god prompt kan være en del af leverancen. Den er ikke hele leverancen.

Den testbare arbejdsgang bør vise:

  • Input: Hvilke oplysninger og kilder må bruges?
  • Instruktion: Hvad skal AI gøre, og hvad må den ikke gøre?
  • AI-kladde: Hvilket format skal forslaget have?
  • Menneskelig kontrol: Hvem sammenholder kladden med kilderne?
  • Output: Hvor placeres det godkendte resultat?
  • Stopregel: Hvornår må flowet ikke fortsætte?

Tag opfølgning efter et kundemøde som eksempel. Rå noter kan blive til et forslag med beslutning, handling, ansvarlig og tidspunkt. Men AI må ikke selv gøre en løs idé til en kundeaftale. Den praktiske metode er beskrevet i guiden fra mødenoter til ansvar og næste skridt.

Konsulenten bør aflevere instruktionen og inputformatet i en navngivet version. Ellers kan virksomheden ikke se, hvad der blev testet, eller rulle tilbage, hvis en senere ændring gør resultatet dårligere.

5. Kontrolpunkter, ansvar og stopregel

“Et menneske kigger på det” er for uklart. Leverancen bør beskrive kontrollen så konkret, at en medarbejder kan udføre den ens hver gang.

Ved et svarudkast kan kontrollen eksempelvis være:

  • stemmer navn, dato, beløb og reference med kilden?
  • er alle påstande understøttet af godkendt materiale?
  • indeholder teksten et løfte, som ingen har godkendt?
  • er intern information fjernet fra den eksterne tekst?
  • er tone og modtager korrekt?

Stopreglen angiver, hvornår AI ikke må færdiggøre opgaven. Det kan være ved manglende kilder, modstridende oplysninger, klager, betalinger, juridiske spørgsmål eller personoplysninger uden et afklaret datascope.

Digitaliseringsstyrelsen beskriver ansvarlig brug af generativ AI som et ledelsesansvar og anbefaler, at virksomheden tager stilling til formål, retningslinjer og organisatoriske rammer. Det betyder i praksis, at ansvar ikke kan afleveres til værktøjet eller konsulenten.

6. En reel test — ikke kun en demonstration

En demonstration viser, at noget kan se rigtigt ud én gang. En test viser, hvordan arbejdsgangen opfører sig på aftalte eksempler.

Den første test kan med fordel bruge syntetiske data: realistiske, men opdigtede navne, henvendelser og sagsdetaljer. Datatilsynet anbefaler, at virksomheder har organisatoriske rammer for brug af AI-værktøjer og forholder sig til, hvilke oplysninger medarbejdere indtaster.

En lille testrapport bør som minimum vise:

  • hvilke eksempler der blev brugt;
  • hvilken version af instruktionen der blev testet;
  • hvilket output der kom;
  • hvilke fejl eller usikkerheder der blev fundet;
  • om kontrollen fangede dem;
  • hvilke ændringer testen førte til;
  • hvad der stadig ikke er afklaret.

Kvalitet kommer før påstået tidsgevinst. Hvis kladden ikke er korrekt, komplet og nem at kontrollere, er det for tidligt at regne på besparelser eller koble automatisk afsendelse på.

7. Aflevering, så virksomheden ikke bliver afhængig af konsulenten

Efter forløbet skal virksomheden kunne forstå og bruge det aftalte arbejdsprodukt. En enkel aflevering bør samle:

  • problem, scope og ejer;
  • arbejdsgangen i få trin;
  • inputskabelon og instruktion med versionsnummer;
  • kontrolpunkter og stopregel;
  • testmateriale og kendte begrænsninger;
  • kort vejledning til brugeren;
  • beslutninger om data, adgang og eventuelle værktøjer;
  • anbefalet næste skridt.

Bed også om at få skelnet mellem det, virksomheden selv får udleveret, og det, der bliver hos leverandøren. Hvis løsningen kræver løbende drift, bør ansvar, ændringer, adgang, omkostninger og exit beskrives, før den bliver kritisk for hverdagen.

Aflevering er ikke det samme som, at alt skal være fuldt automatiseret. En kontrolleret, manuel pilot kan være den rigtige leverance, hvis formålet er at lære sikkert.

Workshop, kursus, pilot eller implementering?

Alle fire formater kan være relevante. Problemet opstår, når navnet skjuler leverancen.

Workshop

God til at afklare problem, muligheder, risici og prioritet. Aftal, om outputtet er et beslutningsnotat, et proceskort eller et prioriteret pilotbrief. En workshop er ikke en implementeret arbejdsgang, medmindre noget faktisk er bygget og testet.

Kursus

Godt, når medarbejdernes kompetencer er problemet. Aftal læringsmål, øvelser og hvilke opgaver deltagerne skal kunne udføre bagefter. Et promptkursus løser ikke automatisk et uklart workflow eller manglende dataansvar.

Pilot

God, når én arbejdsgang skal afprøves med begrænset risiko. Piloten bør have testeksempler, kontrolpunkter, stopregel og en dato for beslutningen om at stoppe eller fortsætte.

Implementering

Relevant, når en afprøvet arbejdsgang skal forankres hos brugere og eventuelt forbindes med systemer. Her bør tilbuddet også beskrive træning, ændringsstyring, drift, adgang, databehandling og fejlretning.

Hvornår er AI ikke den bedste løsning?

AI bør ikke være standardvalget, bare fordi leverandøren er AI-konsulent.

Når reglerne er faste

Hvis opgaven altid følger samme felter og samme beslutningslogik, vil en skabelon eller regelbaseret automation ofte være enklere at teste og lettere at forudsige.

Når opgaven sker sjældent

En manuel proces kan være billigere og mere robust, hvis opgaven kun opstår få gange, og opsætning, kontrol og vedligeholdelse vil fylde mere end selve arbejdet.

Når fejlkonsekvensen er høj

AI bør ikke træffe den endelige beslutning om eksempelvis betaling, bindende tilbud, personale, jura eller andre forhold med stor konsekvens. En fagperson skal eje vurderingen. EU-Kommissionen beskriver AI-reglerne som risikobaserede; kontrolniveauet bør derfor følge den konkrete anvendelse og dens konsekvenser.

Når data og ansvar ikke er afklaret

Hvis ingen ved, hvilke oplysninger der må bruges, hvem der kontrollerer resultatet, eller hvilken kilde der er gældende, er næste skridt afklaring — ikke automation. Dataminimering, rigtighed og sikkerhed er fortsat relevante, når der behandles personoplysninger.

Når processen allerede kan løses enklere

Ved få kundemøder kan en fast 10-minutters rutine være bedre end et nyt system. Se eksemplet på opfølgning efter kundemøde med eller uden AI.

Tjek tilbuddet, før du siger ja

Brug denne korte liste på det konkrete tilbud:

  1. Er problemet beskrevet som én arbejdsopgave?
  2. Kan du se, om du køber workshop, kursus, pilot eller implementering?
  3. Står der præcist, hvilke dokumenter og arbejdsgange du får?
  4. Er ikke-AI-alternativet vurderet?
  5. Er input, output og ansvar tydelige?
  6. Findes der testeksempler og acceptkriterier?
  7. Er stopregel og menneskelig kontrol beskrevet?
  8. Er datascope og brug af virkelige oplysninger afklaret?
  9. Får du versioner, vejledning og kendte begrænsninger udleveret?
  10. Ender forløbet med beslutningen stop, fortsæt selv eller gå videre?

Hvis tilbuddet primært beskriver teknologi, møder og muligheder, men ikke arbejdsprodukter og kontrol, så bed om et skarpere scope før køb.

En afgrænset standardleverance

I Rafen Start vælges én konkret arbejdsopgave. Leverancen omfatter en versionsstyret AI-arbejdsgang, inputskabelon, instruktion, kontrolpunkter, stopregel, syntetisk test og en afgrænset prøveplan. Den omfatter ikke integrationer, automatisk afsendelse eller kundedata før et godkendt datascope.

Hvis behovet allerede omfatter flere afprøvede arbejdsgange, brugertræning og en begrænset virkelig afprøvning, hører det i stedet til et implementeringsforløb. Forskellen skal være synlig før start.

Som et konkret eksempel på en afgrænset rolle kan du læse hvad en AI-mødemakker er — og ikke er.

Næste skridt: Se, hvordan én afgrænset AI-leverance kan starte — og vurder først, om opgaven kræver AI, klassisk automation eller en enklere manuel løsning.

FAQ

Hvad er forskellen på AI-rådgivning og AI-implementering?

AI-rådgivning kan ende med en analyse, prioritering eller plan. Implementering betyder, at en aftalt arbejdsgang bliver bygget, afprøvet, tilpasset og gjort klar til brug inden for et defineret scope. Tilbuddet bør navngive de konkrete outputs, så forskellen ikke kun ligger i overskriften.

Er en workshop spild af penge?

Nej. En workshop kan være den rigtige start, hvis problemet er uklart, og det aftalte output er en prioriteret beslutning eller et pilotbrief. Den er utilstrækkelig, hvis du forventer en fungerende arbejdsgang, men kun får idéer og slides.

Skal en AI-konsulent love en tidsbesparelse?

Nej. Før en afgrænset test er en bestemt besparelse en hypotese, ikke et dokumenteret resultat. Start med at måle korrekthed, anvendelighed, kontroltid og fejltyper. Derefter kan virksomheden vurdere den faktiske effekt.

Hvem har ansvaret for AI'ens output?

Virksomheden skal placere et tydeligt fagligt og ledelsesmæssigt ansvar. Konsulenten kan bygge kontrolpunkter og dokumentere begrænsninger, men værktøjet kan ikke eje beslutningen. Eksternt materiale bør godkendes af en ansvarlig person før brug eller afsendelse.

Skal den første pilot bruge vores egne kundedata?

Ikke nødvendigvis. En første test kan ofte gennemføres med syntetiske eksempler. Virkelige kunde- eller medarbejderoplysninger bør først bruges, når formål, værktøj, adgang, aftaler, sikkerhed og datagrundlag er konkret vurderet.

Hvornår er klassisk automation bedre end AI?

Når opgaven følger stabile regler med entydige input og handlinger. Klassisk automation er ofte mere forudsigelig til faste systemtrin. Generativ AI er mere relevant, når varieret tekst eller dokumenter skal fortolkes og omsættes til et forslag, som et menneske kan kontrollere.

Kilder