Hvad er en AI-agent til virksomheden? Komplet guide til kategorien

Hvad er en AI-agent til virksomheden, og hvordan adskiller den sig fra chatbots?

En AI-agent til virksomheden er software, der kan forstå en opgave beskrevet i almindeligt sprog, selv planlægge hvordan den skal løses, og derefter udføre den ved at arbejde i virksomhedens systemer som CRM, økonomisystem, mail og dokumenter. Mens en chatbot svarer på spørgsmål og klassisk automatiseringsværktøj følger faste opskrifter, kan en AI-agent selv vurdere, slå op, sammenstille og handle.

En AI-agent til virksomheden er et stykke software, der kan forstå en opgave beskrevet i almindeligt sprog, selv planlægge hvordan opgaven skal løses, og derefter udføre den ved at arbejde i virksomhedens egne systemer — CRM, økonomisystem, mail, dokumenter og databaser. Hvor en chatbot svarer på spørgsmål, og et klassisk automatiseringsværktøj følger en fast opskrift, kan en AI-agent selv vurdere, slå op, sammenstille og handle. Det er forskellen på at have et opslagsværk og at have en medarbejder.

AI-agent til virksomheden er betegnelsen for en AI-drevet softwareassistent, der med adgang til virksomhedens data og systemer selvstændigt kan udføre flertrinsopgaver — fra at besvare kundehenvendelser med korrekt kontekst til at samle rapporter på tværs af systemer — inden for de rammer og tilladelser, virksomheden selv sætter.

Kategorien er ny, og begreberne flyder stadig. Derfor starter denne artikel med en ordentlig definition, forklarer hvordan en AI-agent adskiller sig fra de teknologier, de fleste virksomheder allerede kender — chatbots, RPA og almindelig SaaS — og gennemgår derefter, hvordan det fungerer i praksis, hvad det kan bruges til, hvornår det ikke giver mening, og hvordan man kommer i gang.

Hvad er en AI-agent til virksomheden — definitionen foldet ud

Ordet "agent" bruges i AI-verdenen om software, der ikke bare svarer, men handler. Tre egenskaber skal være til stede, før man meningsfuldt kan tale om en AI-agent i virksomhedssammenhæng:

1. Den forstår opgaver i naturligt sprog

En AI-agent bygger på en stor sprogmodel. Det betyder, at opgaven ikke skal oversættes til kode, regler eller flowdiagrammer, før agenten kan arbejde med den. "Find alle kunder, der ikke har svaret på vores tilbud fra sidste måned, og lav et udkast til en opfølgningsmail til hver" er en fuldt gyldig instruks. Det er den egenskab, der flytter automatisering fra IT-afdelingen ud til de medarbejdere, der faktisk kender opgaverne.

2. Den har adgang til virksomhedens systemer og data

En sprogmodel alene ved intet om jeres kunder, ordrer eller aftaler. Det, der gør en agent til en virksomheds-agent, er koblingen til virksomhedens egne systemer: CRM, ERP, mail, kalender, fildrev, databaser og fagsystemer. Koblingen sker typisk gennem såkaldte connectors — færdigbyggede integrationer til de gængse systemer. På Agent360-platformen findes der som eksempel 35+ connectors til virksomhedens systemer, så agenten kan slå op og handle dér, hvor arbejdet allerede foregår.

3. Den kan planlægge og udføre i flere trin

Det tredje kendetegn er selvstændighed inden for rammer. En agent, der får opgaven "lav ugens salgsrapport", skal selv kunne finde ud af: hent tallene fra CRM'et, sammenhold med sidste uge, formatér som dokument, og læg det klar til mødet. Den slags flertrinsarbejde — hvor næste skridt afhænger af, hvad det forrige viste — er netop det, som regelbaserede værktøjer ikke kan, og som definerer agent-kategorien.

Når alle tre egenskaber er til stede, taler nogle om, at virksomheden får et internalOS — et internt "styresystem" for virksomhedens viden og arbejdsgange, hvor agenter, data og processer bor samme sted, i stedet for at være spredt over snesevis af uafhængige cloud-værktøjer. Begrebet internalOS er ikke et produkt, men en måde at beskrive målet på: ét samlet lag, hvor virksomhedens AI arbejder på virksomhedens egne præmisser.

Interessen for området er ikke teoretisk. Ifølge Danmarks Statistik steg andelen af danske virksomheder med mindst ti ansatte, der bruger kunstig intelligens, fra 15 pct. i 2023 til 28 pct. i 2024 — næsten en fordobling på ét år. De fleste af de virksomheder bruger i dag AI til tekstproduktion og tekstanalyse; agent-laget, hvor AI'en også udfører arbejdet, er det naturlige næste skridt.

Hvordan adskiller en AI-agent sig fra en chatbot, RPA og almindelig SaaS?

Det er her, de fleste misforståelser opstår. "Har vi ikke allerede en chatbot?" og "vi har jo automatiseret med RPA" er rimelige indvendinger — men de tre teknologier løser forskellige problemer.

Chatbot: svarer, men handler ikke

En klassisk chatbot — også de moderne, sprogmodel-baserede — er bygget til samtale. Den kan besvare spørgsmål, ofte på baggrund af en videnbase, og den kan være glimrende til førstelinje-support. Men den stopper ved svaret. Den opretter ikke sagen i jeres system, opdaterer ikke kundekortet og følger ikke op tre dage senere. En chatbot er en grænseflade; en agent er en medarbejderfunktion. Mange virksomheder opdager i praksis, at deres chatbot genererer arbejde til mennesker ("jeg har oprettet en henvendelse til dig"), hvor en agent kunne have færdiggjort opgaven.

RPA: handler, men forstår ikke

RPA — Robotic Process Automation — er software-robotter, der efterligner museklik og tastetryk efter en fast opskrift: åbn skærmbillede, kopiér felt 3, indsæt i system B. RPA har været udbredt i store organisationer i årevis og er stærkt til stabile, ensartede processer i høj volumen. Svagheden er, at RPA er blind: Ændrer skærmbilledet sig, knækker robotten. Og RPA kan ikke håndtere variation — en faktura, der ser lidt anderledes ud, en mail formuleret på en ny måde, en undtagelse fra reglen. En AI-agent forstår indholdet og kan derfor håndtere netop den variation, der får RPA-projekter til at vokse i vedligehold.

Almindelig SaaS: et system mere, ikke et lag ovenpå

Standard SaaS-værktøjer — CRM, projektstyring, helpdesk — er databaser med brugerflader. De opbevarer information og strukturerer arbejdet, men udfører det ikke. Hvert nyt SaaS-værktøj er desuden endnu en silo: endnu et login, endnu et sted data bor, endnu en integration der skal vedligeholdes. En AI-agent er ikke et system mere i rækken — den er laget, der arbejder på tværs af de systemer, I allerede har. Hvis I vil have en grundigere gennemgang af, hvad automatisering i selve CRM-laget kan, har vi skrevet en samlet guide til hvad CRM-automatisering er.

Sammenligning af AI-agent, chatbot, RPA og almindelig SaaS på de dimensioner, der betyder noget i praksis

Dimension	AI-agent	Chatbot	RPA	Almindelig SaaS
Forstår naturligt sprog	Ja — opgaver beskrives på dansk	Ja — men kun i samtalen	Nej — kræver fast opskrift	Nej — kræver manuel betjening
Udfører flertrinsopgaver	Ja — planlægger selv trinnene	Nej — svarer kun	Ja — men kun foruddefinerede trin	Nej — mennesket udfører
Håndterer variation og undtagelser	Ja — forstår indholdet	Delvist — inden for videnbasen	Nej — knækker ved afvigelser	Ikke relevant
Arbejder på tværs af systemer	Ja — via connectors	Sjældent — typisk ét system	Ja — men skrøbeligt (skærmbilleder)	Nej — er selv et af systemerne
Typisk vedligehold	Lavt — instrukser justeres i sprog	Middel — videnbase skal plejes	Højt — opskrifter knækker ved ændringer	Middel — konfiguration og oprydning

Pointen med tabellen er ikke, at AI-agenten "vinder" på alle punkter — det gør den ikke i alle situationer, hvilket vi vender tilbage til i afsnittet om, hvornår en agent ikke giver mening. Pointen er, at de fire kategorier ikke er konkurrenter på samme hylde. En agent kan sagtens arbejde sammen med jeres eksisterende SaaS-systemer og endda overtage det, jeres RPA-robotter snubler i.

Hvordan virker det i praksis?

Teori er fint, men det afgørende spørgsmål er: hvordan ser det ud, fra en virksomhed beslutter sig, til medarbejderne faktisk bruger en agent i hverdagen? Forløbet falder typisk i fire faser.

Fase 1: Behovet beskrives på dansk

Udgangspunktet er ikke et teknisk kravdokument, men en beskrivelse af det arbejde, der i dag tager tid: "Vores bogholder bruger hver mandag to timer på at afstemme indbetalinger mod fakturaer." "Kundeservice svarer på de samme ti spørgsmål igen og igen, men skal hver gang slå kundens ordrehistorik op først." "Salgschefen vil have en ugentlig oversigt, som i dag klippes sammen manuelt fra tre systemer."

Fordi agenten bygger på en sprogmodel, er den beskrivelse i sig selv det halve af specifikationen. Der er ingen oversættelse til flowdiagrammer eller kode som forudsætning — de medarbejdere, der kender opgaven bedst, kan formulere den direkte.

Fase 2: Løsningen co-skabes

Herefter bygges løsningen i samarbejde — det, man kan kalde co-skabelse. Virksomheden bidrager med domæneviden: hvilke systemer er involveret, hvad er en god og en dårlig løsning af opgaven, hvor går grænserne for, hvad agenten må gøre selv, og hvornår skal et menneske godkende. Platformssiden bidrager med selve agent-opsætningen: adgange via connectors, instrukser, sikkerhedsrammer og test.

Co-skabelsen er vigtig af en grund, som ofte undervurderes: en agent, der er sat op uden virksomhedens egen viden, svarer generisk og handler forkert i kanttilfældene. Det er i mødet mellem virksomhedens "sådan gør vi faktisk her" og platformens "sådan sættes det sikkert op", at en brugbar agent opstår. På Agent360 — en dansk platform, der samler dette som "virksomhedens AI-platform i én IDE" — foregår den proces i ét samlet miljø, hvor agenten, dens instrukser og dens adgange kan ses og justeres ét sted. Selve AI-agenten bygger på Claude, Anthropics sprogmodel, via Claude Code.

Fase 3: Løsningen kører i virksomhedens egen instans

Når agenten er bygget og testet, skal den køre et sted — og hvor er ikke en detalje. I Agent360-modellen får hver virksomhed sin egen instans med sin egen database. Der er ingen delt multi-tenant-data på tværs af kunder, og instansen kan self-hostes, hvis virksomheden ønsker at køre den på egen infrastruktur. Det er den arkitektur, der gør dataejerskabet reelt — mere om det i næste afsnit.

Nye funktioner og færdige agent-løsninger installeres via en app-model med et kurateret registry: I installerer det, I skal bruge, ind i jeres egen instans, i stedet for at logge ind i endnu en leverandørs delte cloud. Og licensmodellen er værd at kende som beslutningskriterie: Agent360 er fair source — ægte open source efter 2 år. Det betyder i praksis, at koden ikke er en sort boks, man er låst fast til for altid.

Fase 4: Medarbejderne bruger den i hverdagen

Den sidste fase er den vigtigste og den, flest projekter glemmer at planlægge for: hverdagsbrug. En agent skaber først værdi, når den er dér, hvor arbejdet foregår — ikke i endnu en fane, medarbejderne skal huske at åbne. I praksis betyder det, at agenten besvarer opgaver, hvor de opstår: den forbereder svar-udkast i kundeservicekøen, lægger den færdige rapport i den kanal, hvor mødet forberedes, og svarer på opslag ("hvad har vi aftalt med kunde X?") uden at medarbejderen skal jonglere fem systemer.

Et sundt tegn på en vellykket indførelse er, at medarbejderne holder op med at tale om "AI-projektet" og bare taler om, hvordan opgaven løses nu. Det modsatte tegn — at agenten står ubrugt, mens folk arbejder som før — skyldes næsten altid, at fase 1 og 2 blev sprunget over, og at løsningen derfor ikke matcher det faktiske arbejde.

Egen instans og dataejerskab: GDPR i praksis

For danske virksomheder er databeskyttelse ikke et appendiks til AI-diskussionen — det er ofte selve gatekeeping-spørgsmålet, før et projekt overhovedet kan godkendes. Og med god grund: en AI-agent med adgang til CRM, mail og dokumenter behandler i sagens natur personoplysninger.

Hvorfor arkitekturen afgør GDPR-samtalen

GDPR-vurderingen af en AI-løsning bliver væsentligt enklere, når man kan svare klart på tre spørgsmål: Hvor ligger data? Hvem har adgang? Og blandes vores data med andres? Det er her, forskellen på delt multi-tenant-cloud og egen instans bliver konkret:

• Egen instans, egen database: Virksomhedens data ligger i en database, der kun rummer virksomhedens data. Der er ikke noget delt datalag på tværs af kunder, hvor en fejlkonfiguration kan eksponere jeres oplysninger for andre.
• Self-host som mulighed: Virksomheder med skærpede krav — eller en dataansvarlig, der ønsker fuld kontrol — kan køre instansen på egen infrastruktur. Så er svaret på "hvor ligger data?" bogstaveligt: hos os selv.
• Gennemsigtighed i koden: Fair source-modellen (ægte open source efter 2 år) betyder, at det på sigt kan efterprøves, hvad softwaren faktisk gør med data — i modsætning til lukkede tjenester, hvor man må nøjes med leverandørens ord.

Ingen arkitektur fritager for det juridiske hjemmearbejde: der skal stadig være behandlingsgrundlag, databehandleraftaler hvor det er relevant, og en konsekvensanalyse ved højrisiko-behandling. Datatilsynet har en samlet indgang til vejledning om kunstig intelligens og databeskyttelse, inklusive skabeloner til konsekvensanalyser og en regulatorisk sandkasse, hvor virksomheder kan få vejledning om GDPR og AI-forordningen.

AI-forordningen kommer oveni

Ud over GDPR skal danske virksomheder forholde sig til EU's AI-forordning (AI Act), der arbejder med en risikobaseret tilgang: jo større risiko et AI-system udgør for sikkerhed og rettigheder, desto skrappere krav. Ifølge EU-Kommissionen finder forordningen fuld anvendelse fra den 2. august 2026, mens dele af reglerne allerede er trådt i kraft. Langt de fleste hverdagsanvendelser af AI-agenter — kundeservice-udkast, rapporter, dataopslag — falder i de lave risikokategorier, men virksomheder, der bruger AI i fx rekruttering eller kreditvurdering, skal være særligt opmærksomme. Vi har skrevet en dedikeret gennemgang af, hvad EU's AI-forordning betyder for danske virksomheder.

Den korte version af hele afsnittet: dataejerskab er ikke en marketingfrase, men et arkitekturvalg. Spørg enhver leverandør: egen instans eller delt cloud? Self-host muligt eller ej? Kan koden efterprøves? Svarene afgør, hvor svær jeres GDPR- og AI Act-compliance bliver.

Hvad kan en AI-agent bruges til? Konkrete hverdagseksempler

Kategorien bliver først rigtig forståelig gennem eksempler. Her er fire anvendelser, der går igen på tværs af brancher — bevidst valgt som hverdagsopgaver, ikke science fiction.

Kundeservice-svar med kontekst

Den klassiske første anvendelse. Agenten læser den indkomne henvendelse, slår kunden op i CRM og ordresystem, og skriver et udkast til svar, der tager højde for kundens faktiske historik — hvad de har købt, hvad de tidligere har spurgt om, hvad der er aftalt. Medarbejderen godkender, justerer eller omskriver. Forskellen fra en chatbot er netop konteksten: svaret bygger på virksomhedens egne data om netop denne kunde, ikke på en generisk videnbase. Og forskellen fra fuld automatisering er mennesket i loopet — agenten forbereder, medarbejderen beslutter. Hvordan AI mere bredt kan løfte arbejdet efter salget, har vi samlet i vores guide til AI i customer success.

Dataopslag på tværs af systemer

"Hvad har vi aftalt med kunde X?" er i mange virksomheder et spørgsmål, der kræver opslag i CRM, mailarkiv, tilbudsdokumenter og måske økonomisystemet — fem minutter her, ti minutter der, mange gange om dagen, ganget med alle medarbejdere. En agent med connectors til de relevante systemer kan besvare spørgsmålet samlet: seneste aftale, åbne tilbud, betalingsstatus, seneste korrespondance. Det lyder udramatisk, men det er ofte den anvendelse, medarbejderne ender med at bruge mest, fordi den fjerner hverdagens mest irriterende friktion.

Rapporter, der samler sig selv

Ugerapporten, månedsrapporten, bestyrelsesbilaget: tilbagevendende dokumenter, hvor selve indsamlingen og formateringen tager tid, mens den egentlige værdi ligger i vurderingen. En agent kan trække tallene fra kildesystemerne, stille dem op i det aftalte format og aflevere et udkast — hvorefter mennesket bruger sin tid på at vurdere og beslutte i stedet for at klippe-klistre. Kvaliteten afhænger dog direkte af datakvaliteten i kildesystemerne; en agent, der rapporterer på et rodet CRM, producerer velformaterede fejl. Derfor hænger denne anvendelse tæt sammen med CRM-datahygiejne — oprydningen er ofte det reelle første skridt.

Automatiske arbejdsgange med dømmekraft

Den fjerde kategori er arbejdsgange, hvor der indgår et element af vurdering, som klassisk automatisering ikke kan håndtere: indgående mails, der skal sorteres og videresendes til rette person med et resumé; leads, der skal beriges med offentligt tilgængelige oplysninger og oprettes korrekt i CRM; opfølgninger, der skal formuleres forskelligt alt efter kundens situation. Det er her, agenter overtager terræn fra både manuelt arbejde og skrøbelige RPA-opskrifter. En samlet gennemgang af mulighederne på salgssiden findes i vores komplette guide til automatisering af salgsprocesser.

Fællesnævneren for alle fire: agenten fjerner ikke fagligheden — den fjerner transporten af information mellem systemer og mennesker. Beslutningerne bliver hos medarbejderne; slæbearbejdet flytter til agenten.

Hvornår giver en AI-agent IKKE mening?

En troværdig guide skal også tegne grænsen. Der er situationer, hvor en AI-agent er det forkerte svar — eller det rigtige svar på det forkerte tidspunkt.

Når processen er fuldt regelbaseret og stabil

Hvis en opgave kan beskrives fuldstændigt med faste regler, aldrig varierer og kører i høj volumen — ren dataoverførsel mellem to systemer med fast format, for eksempel — er en klassisk integration eller et simpelt script både billigere, hurtigere og lettere at fejlfinde. AI-agentens styrke er dømmekraft og variation; er der ingen af delene i opgaven, betaler man for en egenskab, man ikke bruger.

Når fejlomkostningen er høj og kontrol umulig

Opgaver, hvor en enkelt fejl er dyr eller irreversibel — udbetalinger, sletning af data, juridisk bindende svar — bør ikke overlades til en agent uden menneskelig godkendelse i loopet. Det betyder ikke, at agenten er ubrugelig dér; den kan forberede og indstille. Men "fuldautomatisk" er det forkerte ambitionsniveau, og en leverandør, der lover andet, skal man være skeptisk over for.

Når grunddata er kaos

En agent forstærker det datagrundlag, den står på. Er CRM'et fyldt med dubletter, forældede kontakter og tomme felter, vil agentens svar og rapporter afspejle det. I den situation er det rigtige første projekt ikke en agent, men oprydning og struktur — eventuelt med agenten som oprydningsværktøj, men med det som eksplicit mål.

Når organisationen ikke er med

Teknologien er den lette del. Hvis ingen i virksomheden ejer løsningen, hvis medarbejderne oplever den som overvågning frem for aflastning, eller hvis ledelsen forventer, at "AI fikser det" uden at nogen definerer det, ender selv en teknisk vellykket agent ubrugt. Signalet at holde øje med: kan I formulere præcist, hvilken opgave agenten skal overtage, og hvem der bliver glad, når den gør det? Kan I ikke, er I ikke klar endnu.

Når det reelle behov er noget andet

Nogle gange er den ærlige konklusion, at behovet dækkes bedre af noget enklere: et standard SaaS-værktøj, en integration, en ændret arbejdsgang. En god leverandør — og en god intern projektejer — siger det højt i stedet for at bygge en agent, fordi agenter er det, alle taler om.

Sådan kommer I i gang

Til sidst det praktiske: hvordan bevæger en virksomhed sig fra nysgerrighed til en agent i drift uden at fare vild? Erfaringen peger på en rækkefølge i fem trin.

Trin 1: Vælg én konkret, tilbagevendende opgave

Ikke "vi vil have AI i virksomheden", men "vores kundeservice bruger anslået en formiddag om ugen på at slå ordrestatus op manuelt". Den bedste første opgave er tilbagevendende (så gevinsten gentager sig), afgrænset (så succes kan vurderes) og lav-risiko (så en fejl ikke er dyr). Undgå at starte med den mest komplekse proces i huset — den kan blive projekt nummer tre.

Trin 2: Beskriv opgaven, som den faktisk udføres

Sæt den medarbejder, der udfører opgaven i dag, til at beskrive den: hvilke systemer, hvilke undtagelser, hvad er et godt resultat, hvad er et dårligt. Denne beskrivelse på almindeligt dansk er fundamentet for co-skabelsen — og øvelsen afslører i sig selv ofte, at opgaven rummer mere dømmekraft (eller mindre) end antaget.

Trin 3: Afklar data- og adgangsspørgsmålene tidligt

Hvilke data skal agenten kunne læse, og hvilke skal den kunne skrive i? Hvor skal løsningen køre — leverandørens egen instans-model eller self-host? Hvem godkender agentens handlinger i starten? Tag GDPR-spørgsmålene her, ikke til sidst; brug eventuelt Datatilsynets AI-vejledningsmateriale som tjekliste for jeres egen vurdering.

Trin 4: Kør en afgrænset pilot med mennesker i loopet

Lad agenten forberede, mens medarbejdere godkender — og mål på noget konkret: tid sparet, svartid, kvalitet af udkast, antal gange agenten måtte rettes. En pilot på få uger med ét team giver mere læring end måneder af planlægning. Justér instrukserne løbende; det er netop styrken ved sprogbaserede agenter, at justering ikke kræver et udviklingsprojekt.

Trin 5: Udvid dér, hvor medarbejderne trækker

Når den første agent virker, kommer de næste ønsker typisk af sig selv — "kan den også…?" er det sundeste signal i et agent-projekt. Udvid efter træk fra organisationen frem for tryk fra et roadmap. Og genbesøg undervejs grænserne fra forrige afsnit: hver ny opgave skal bestå samme test som den første.

Virksomheder, der følger den rækkefølge, undgår de to klassiske fælder: pilot-kirkegården (mange forsøg, intet i drift, fordi opgaverne var for store) og big bang-projektet (ét kæmpe projekt, der aldrig lander, fordi alt skulle med fra start).

Ofte stillede spørgsmål om AI-agenter til virksomheden

Hvad er forskellen på en AI-agent og ChatGPT?

ChatGPT er en generel samtale-AI uden adgang til jeres virksomheds systemer og data. En AI-agent til virksomheden bygger på samme type sprogmodel-teknologi, men er koblet til jeres egne systemer via connectors, arbejder inden for rammer I selv sætter, og kan udføre flertrinsopgaver — ikke kun svare på spørgsmål.

Kræver en AI-agent, at vi udskifter vores nuværende systemer?

Nej — det er netop pointen, at den ikke gør. En AI-agent arbejder ovenpå de systemer, I allerede har (CRM, økonomisystem, mail, dokumenter), via integrationer. Den er et lag på tværs, ikke endnu et system, der skal erstatte noget.

Er en AI-agent GDPR-lovlig?

Ja, når den indføres rigtigt. Det afgørende er arkitekturen (hvor ligger data, blandes de med andres?), adgangsstyringen og det juridiske grundlag — behandlingshjemmel, databehandleraftaler og eventuelt en konsekvensanalyse. En egen instans med egen database, eventuelt self-hostet, gør vurderingen væsentligt enklere. Datatilsynet har samlet vejledning om AI og databeskyttelse.

Hvad betyder "internalOS"?

internalOS er en betegnelse for idéen om et internt "styresystem" for virksomheden: ét samlet lag, hvor AI-agenter, virksomhedens data og arbejdsgange bor sammen, i stedet for at være spredt over mange uafhængige cloud-værktøjer. Det er en beskrivelse af målet med en virksomheds-AI-platform — ikke et bestemt produkt.

Erstatter en AI-agent medarbejdere?

I praksis flytter den opgaver snarere end stillinger. Agenten overtager transporten af information — opslag, sortering, udkast, formatering — mens vurdering og beslutning bliver hos medarbejderne. De vellykkede indførelser handler om at give fagligheden mere tid, ikke om at fjerne den.

Hvor lang tid tager det at komme i gang?

Det afhænger af opgavens kompleksitet og af, hvor hurtigt data- og adgangsspørgsmålene kan afklares. En afgrænset pilot på én konkret opgave med mennesker i godkender-rollen kan typisk stå på benene på uger snarere end måneder — forudsat at opgaven er velbeskrevet, og de nødvendige systemadgange er på plads.

Hvad er "fair source", og hvorfor betyder det noget?

Fair source er en licensmodel, hvor koden bliver ægte open source efter 2 år. For en virksomhed betyder det gennemsigtighed og en exit-mulighed: softwaren er ikke en permanent lukket sort boks, og afhængigheden af leverandøren er tidsbegrænset i licensens konstruktion. Det er et relevant kriterie, når man vælger platform til noget så centralt som virksomhedens data og arbejdsgange.