Andreea Pleşea, PhD, COO og medstifter af Druid AI – Interviewserie

Andreea Pleşea, PhD, COO og medstifter af Druid AI, er en teknologisk leder og iværksætter med næsten to årtiers erfaring inden for softwareudvikling, enterprise‑teknologi, kunstig intelligens, drift og kundesucces. Siden medstiftelsen af Druid AI har hun haft flere senior‑ledelsesroller i organisationen, herunder Chief Operating Officer, Chief Revenue Officer og Chief Customer Success Officer, hvilket har givet hende erfaring på både den tekniske og kommercielle side af skalering af en enterprise‑softwarevirksomhed. Før Druid AI tilbragte Pleşea næsten et årti hos TotalSoft, hvor hun gik fra .NET‑programmør til Software Development Manager og til sidst Charisma Business Applications Director, med ansvar for produktudvikling, implementering, teknisk support, løsningsarkitektur og P&L‑ansvar. Hendes akademiske baggrund omfatter også AI‑forskning ved University of Rome Tor Vergata, hvor hun arbejdede med universitetets Artificial Intelligence Research Group om teknologi til at udtrække og strukturere information fra ustrukturerede data. Hun sidder også i rådgivningsudvalget for Women in Tech Romania.

Druid AI er en enterprise‑AI‑virksomhed, der fokuserer på at bygge og orkestrere AI‑agenter, som kan automatisere komplekse forretningsprocesser på tværs af organisationer. Platformen kombinerer naturlig sprogforståelse, generativ AI, retrieval‑augmented generation (RAG), enterprise‑integrationer, workflow‑automatisering, analyse og governance, hvor Druid Conductor koordinerer flere specialiserede agenter og systemer mod forretningsresultater. Organisationer kan forbinde Druid‑agenter til systemer som ERP, CRM, ITSM og HR‑platforme, samtidig med at teknologien kan implementeres i cloud, hybrid, on‑premises eller air‑gapped miljøer. Virksomheden oplyser, at teknologien anvendes af mere end 300 enterprise‑kunder og understøttes af over 200 globale partnere, med anvendelsesområder der spænder fra medarbejdersupport, kundeservice, sundhedssektoren, videregående uddannelse til shared services.

Du medstiftede Druid AI i Bukarest i 2018 efter at have tilbragt næsten et årti hos TotalSoft, hvor du gik fra .NET‑udvikling til senior teknologi‑ og forretningsledelse. Hvad overbeviste dig dengang om, at samtale‑AI kunne blive et kerne‑lag i enterprise‑teknologi, og hvordan har den oprindelige vision udviklet sig, efterhånden som Druid er gået over til agentisk AI? 

Konvergensen mellem to forskellige veje – akademisk stringens og frontlinjens enterprise‑smerte – formede min tankegang, mens jeg tog min PhD. Men det var først, da Liviu Dragan, en yderst visionær leder, kom med idéen om at grundlægge Druid AI, at jeg indså, hvordan den forskning, jeg lavede, endelig kunne anvendes i praksis.

Mellem 2008 og 2011 fokuserede min PhD‑forskning på autonome AI‑agenter, der kommunikerer via semantiske web‑teknologier og ontologier, og undersøgte hvordan intelligente systemer kunne erstatte eller ligge oven på traditionel enterprise‑software. Kort tid efter afslørede arbejdet i ledelsen af enterprise‑teknologi en skarp virkelighed: vi bad medarbejderne om at håndtere uholdbar kompleksitet.

At udføre en enkelt rutineopgave betød at vide, hvilken applikation der skulle åbnes, hvor dataene befandt sig, hvilken politik der gjaldt, og hvem der ejede næste skridt. Samtidig blev messaging den dominerende grænseflade for menneskelig interaktion uden for kontoret.

Da vi grundlagde Druid AI i 2018, var vores vision enkel, men ambitiøs: give hver medarbejder og kunde en virtuel assistent, der kan orkestrere arbejde på tværs af hele virksomheden.

Næsten et årti senere har den kernevision ikke ændret sig – teknologien har blot indhentet den. Samtale‑AI handlede primært om intent‑genkendelse, retrieval og udløsning af statiske scripts. Agentisk AI flytter grænsen for delegation. Moderne agenter vurderer mål, samarbejder med specialiserede under‑agenter, navigerer i forskellige systemer og udfører komplekse, flertrins‑workflows autonomt.

For os er den nuværende agentiske revolution ikke et strategisk skift væk fra samtale‑AI. Det er den naturlige realisering af vores grundlæggende tese: enterprise‑teknologi skal blive enklere for mennesker, så de kan få arbejdet gjort, selvom orkestreringen bag kulissen bliver uendeligt mere sofistikeret.

Størstedelen af AI‑branchen har fokuseret på at bygge stadig mere kraftfulde grundmodeller, mens Druid AI har fokuseret på at forbinde forskellige modeller til enterprise‑data, systemer og workflows. Efterhånden som modeller bliver mere udskiftelige, tror du så, at orkestrering vil blive en vigtigere konkurrencefordel end selve den underliggende model?

Hos Druid AI er vores kernemission enkel: udtrække det ekstraordinære fra hver menneskelig interaktion ved effektivt at få arbejdet gjort. Men efterhånden som markedet modnes, flytter den vigtigste leverance sig væk fra den underliggende teknologistak.

Vi ser et klassisk mønster i enterprise‑teknologi: funktioner, der engang var tidlige differentieringspunkter, bliver hurtigt en vare. I dag er grundmodeller tilgængelige for alle aktører. Enterprise‑virksomheder vil uundgåeligt implementere en hybrid matrix af modeller, udvalgt efter specifikke præstations‑, omkostnings‑, sikkerheds‑ eller regulatoriske krav. Når intelligens bliver en vare, flytter den strategiske kampzone sig op i stakken.

I dag er de sværeste problemer i enterprise‑AI relateret til eksekveringskontekst: governance og adgang (hvilke data AI’en må røre, og under hvilke politikker), agentisk routing (hvilken specialiseret agent der skal håndtere en given opgave), systemintegration (hvordan flere transaktionelle systemer koordineres sikkert), autonomi vs. kontrol (hvornår kan en agent handle selvstændigt, og hvornår kræves menneskelig godkendelse), auditabilitet (hvis et workflow fejler, kan du rekonstruere beslutningskæden trin for trin).

Derfor er orkestrering blevet den ultimative strategiske løftestang. Modeller producerer intelligens, men enterprise‑virksomheder har brug for pålidelig eksekvering.

Druid AI er bygget til at fungere som dette definitive kontrol‑ og orkestreringslag. Det forbinder forskellige modeller sikkert på tværs af enterprise‑data, workflows og mennesker. Vigtigst er, at det leverer en reference‑ramme til at måle eksekveringseffektivitet og vurdere reelle forretningsresultater.

På længere sigt vil det afgørende spørgsmål ikke være, “Hvilken model bruger du?” Det vil være, “Hvor effektivt kan du omsætte rå intelligens til færdigt arbejde for dine medarbejdere og kunder?”

Druid Conductor kan koordinere flere specialiserede agenter inden for videns‑retrieval, beslutningslogik og systemhandlinger. Hvad bliver teknisk vanskeligt, når en virksomhed går fra en enkelt AI‑assistent, der svarer på spørgsmål, til flere agenter, der uafhængigt kan udføre flertrins forretningsprocesser?

Skiftet fra simple samtale‑grænseflader til multi‑agent‑arkitekturer ændrer grundlæggende ingeniørufordringen. Du stopper med at styre en lineær samtale og begynder at styre et distribueret beslutnings‑ og eksekveringssystem.

Med en enkelt Q&A‑assistent er de centrale hindringer intent‑genkendelse, retrieval og svar‑generering med høj nøjagtighed. Multi‑agent‑økosystemer introducerer en helt anden klasse af distribuerede systemer og spørgsmål:

1. Hvilken agent har myndighed til at handle, og hvordan forhindrer du domænedrift?
2. Hvordan vedligeholdes tilstanden, når ansvarsområder overdrages mellem agenter?
3. Hvordan forenes modstridende beslutninger mellem specialiserede agenter?
4. Hvordan arver under‑agenter adgangstilladelser dynamisk og sikkert?

Disse udfordringer forstærkes, når de anvendes i en virkelig enterprise‑infrastruktur. Et enkelt workflow kan spænde over et CRM, ERP, identitetsstyringsplatform, ticketsystem og ældre databaser. Hver opererer under forskellige forretningslogikker og fejltolerance, men i sidste ende skal conductor‑agenten få arbejdet gjort korrekt.

Hvis trin fire i en seks‑trins proces fejler efter at tre systemer allerede har udført transaktionelle ændringer, bryder en basal agentisk pipeline sammen. Orkestreringslaget kan ikke blot kaste en generisk fejl. Det skal håndtere tilstand, udføre rollback‑handlinger om nødvendigt, afgøre om alternativ routing findes, eller elegant eskalere til menneskelig indgriben i loopet.

Ægte enterprise‑orkestrering er tilstandsstyring, transaktionel konsistens, observabilitet, politik‑gennemførelse og fejlsikker autonomi. Målet med denne underliggende kompleksitet er enkelhed: at levere en enkelt, gnidningsfri interaktion, hvor komplekse multi‑system‑opgaver blot bliver udført.

Druid AI har nu håndteret mere end en milliard samtaler på tværs af tusindvis af implementerede agenter. På den skala, hvad har du lært om enterprise‑AI, som ville have været umuligt at lære fra piloter eller kontrollerede demonstrationer?

Produktion lærer dig ydmyghed hurtigt.

En pilot er normalt et relativt kontrolleret miljø. Use‑casen er defineret, dataene er rimeligt rene, brugerne er kendte, og der er typisk et projektteam, der holder nøje øje.

Produktion fungerer slet ikke sådan. Folk stiller det samme spørgsmål på tyve forskellige måder. De skifter mening midt i en samtale. De giver ufuldstændige oplysninger. De skifter sprog eller emne. De interagerer på uventede tidspunkter. Politik ændres. API’er fejler. Backend‑systemer bliver langsomme. Nye edge‑cases dukker op, som ingen havde tænkt på i det oprindelige design. Én ting er sikkert: brugernes forventning er at få arbejdet gjort effektivt, sømløst og på en naturlig måde. Uanset om det er tekst, men især stemme, skal samtalen flyde naturligt uden latency; den skal i nogen grad virke empatisk og udføre opgaven, mens den foreslår de bedste muligheder og næste skridt, eller håndtere undtagelser og loops menneskeligt, når det er nødvendigt.

Nogle af de mest værdifulde automatiseringer kommer fra at gøre relativt almindelige ting exceptionelt godt og gøre dem hundredtusinder af gange: besvare en medarbejders spørgsmål, tjekke en konto, omlægge en aftale, løse en IT‑forespørgsel eller hente den rette information fra et enterprise‑system. Det ændrede vores opfattelse af AI‑værdi.

Den anden lektie er, at go‑live kun er begyndelsen på en læringscyklus. Du skal se, hvad brugerne efterspørger, hvilke intentioner der vokser, hvor samtaler fejler, hvor folk eskalerer, og nogle gange hvor den underliggende forretningsproces selv skal ændres.

Og måske den vigtigste lektie er, at tillid er operationel, da enterprise‑virksomheder stoler på AI, fordi den over tid opfører sig forudsigeligt, undtagelser håndteres korrekt, beslutninger er synlige, og organisationen forbliver i kontrol.

Druids produktionsdata viser, at et relativt lille antal workflows kan stå for en stor del af den faktiske enterprise‑AI‑brug. Indikerer dette, at virksomheder i første omgang bør fokusere AI‑investeringer på et håndfuld høj‑volumen workflows i stedet for at forsøge en bred enterprise‑omfattende transformation?

Et af de tydeligste mønstre i vores produktionsdata er, at efterspørgslen har en tendens til at koncentrere sig. I finanssektoren udgør for eksempel tre workflow‑kategorier omkring 90 % af produktionsbrugen. I videregående uddannelse er koncentrationen endnu højere. Det fortæller os noget vigtigt om, hvordan virksomheder bør tænke på AI‑transformation. Vi har analyseret disse indsigter og udarbejdet benchmark‑rapporter for videregående uddannelse, sundhedssektoren og bankvæsen, som gør det muligt for vores partnere og kunder at identificere de processer, der vil drive effektivitet, og hjælpe med at forudsige, hvordan mennesker vil interagere med agenter.

Der er en fristelse, især på bestyrelsesniveau, for at starte med en meget bred efterspørgsel: “I SKAL bruge AI, ellers bliver vi efterladt.” Det operationelle team skal så kæmpe for at identificere de rette opgaver, som agenter kan udføre, samtidig med at de frygter at miste deres egne jobs. Så hvad er den rette balance, og hvordan kan de ansætte den rette AI‑agent til at udføre arbejdet SAMMEN med dem, mens de maksimerer de KPI‑er, som bestyrelsen forventer?

Start hvor der er potentiale for at øge omsætning og/eller reducere omkostninger – ting folk typisk udfører gentagne gange. Hvis tusindvis af kunder, medarbejdere, studerende eller patienter gentagne gange forsøger at opnå det samme resultat, har du et målbart grundlag og en stærk mulighed for at demonstrere værdi.

Men der er en vigtig sondring: start snævert, design bredt.

De første use‑cases kan koncentreres. Platformen under dem skal kunne udvides på tværs af virksomheden. Du beviser økonomi, governance‑model, integrationer og menneskelig eskaleringsmekanisme på et håndfuld meningsfulde workflows. Derefter udvider du til tilstødende processer ved at bygge på det, du har lært.

Volumen bør ikke være det eneste kriterium. Et lav‑frekvent workflow kan stadig være ekstremt værdifuldt, hvis hver succesfuld løsning medfører betydelig økonomisk eller operationel indvirkning.

Efterhånden som enterprise‑virksomheder i stigende grad fokuserer på succesfulde løsninger frem for blot at maksimere procentdelen af interaktioner, der håndteres uden mennesker, hvordan skal organisationer bestemme, hvilke beslutninger en AI‑agent kan træffe autonomt, og hvor menneskelig eskalation skal forblive obligatorisk?

Druid AI har bygget et evaluerings‑framework, der dækker 26 kriterier og sikrer en objektiv vurdering af den agentiske orkestrering fra design til udførelse.

Hvis en handling er reversibel, relativt lav‑risiko, styret af klare regler og understøttet af pålidelig information, er der et stærkt argument for autonomi. At omlægge en aftale med foruddefinerede parametre er meget anderledes end at træffe en klinisk beslutning og kan synes simpelt. Men der skal overvejes mange elementer for at gøre det effektivt: fx hvis læge B har en ledig tid, men han ønsker at blokere den, bør AI‑agenten ikke blot omlægge en patients aftale i den tid, blot fordi opgaven er at maksimere lægens kalenderdækning.

Der er flere dimensioner, jeg ville kigge på: de finansielle eller menneskelige konsekvenser af en fejl, om handlingen er reversibel, hvor komplet og kvaliteten af den tilgængelige information er, regulatoriske krav, og om ægte menneskelig dømmekraft eller empati er påkrævet. Så designer du eskalation bevidst.

Det er her, jeg mener, at tidlig tænkning omkring AI‑automatisering var for simpel. Målet blev “indfange så mange interaktioner som muligt uden at involvere et menneske.” Men i mange processer er eskalation netop den rigtige løsning.

Derfor foretrækker jeg at tænke i termer af styret løsning frem for ren indfangning.

Målet er, at AI autonomt løser det arbejde, den skal løse, genkender situationer, hvor den ikke bør handle, og bringer en person ind i processen med den relevante kontekst allerede samlet.

Når AI‑agenter kan hente følsomme oplysninger, opdatere enterprise‑systemer og igangsætte handlinger i den virkelige verden, bliver observabilitet og governance meget mere afgørende. Hvad skal virksomheder kunne auditere om en agents begrundelse, dataadgang og handlinger, før de stoler på den i mission‑kritiske workflows?

Efter Gartner‑retningslinjer har DRUID et indbygget evaluerings‑framework, der analyserer agenter ud fra fem vinkler: fejl‑tolerance, risiko, compliance, observabilitet og afvigelse. Under disse kategorier har vi i alt 26 komponenter. Hver har en definition, et artefakt, du kan åbne, og en måling.

Ved evaluering af en agent skal platformen kunne rekonstruere den komplette kæde fra den oprindelige brugerforespørgsel til den endelige handling. Det betyder at vide, hvilken agent der håndterede forespørgslen, hvilken model der blev brugt, hvilken kontekst modellen modtog, hvilken enterprise‑information der blev hentet, hvilke forretningsregler eller politikker der blev anvendt, hvorfor en bestemt rute eller handling blev valgt, og præcis hvad der ændrede sig i de underliggende systemer. Tiendedels‑interaktioner spores, analyseres og måles.

Identitet er lige så vigtigt. En AI‑agent bør aldrig blive en genvej omkring enterprise‑adgangskontrol. Du skal vide, hvem der initierede forespørgslen, hvad den person var autoriseret til at se eller gøre, og om agenten forblev inden for netop disse grænser.

Med multi‑agent‑arkitekturer bliver sporbarhed endnu vigtigere. Hvilken agent delegerede til en anden agent? Hvilke informationer krydsede den grænse? Hvor stammede beslutningen fra? Hvilken komponent udførte faktisk handlingen? Og så er der operationelle beviser: tidsstempler, tillidssignaler, eksekveringsresultater, undtagelser, eskalerings‑hændelser og evnen til at forstå eller genafspille, hvad der skete.

Dette er en af de største ændringer, når vi bevæger os fra samtale‑AI til agentisk AI.

Når AI kun svarer på et spørgsmål, er observabilitet nyttig. Når AI kan ændre en kunderecord, udløse en betaling, opdatere flere systemer eller starte en forretningsproces, bliver observabilitet en del af kontrol‑arkitekturen.

Du har haft en usædvanligt bred vifte af roller i Druid AI, fra udvikling og drift til indtjening og kundesucces. Hvordan har arbejdet direkte med kunder formet din opfattelse af, hvorfor nogle enterprise‑AI‑implementeringer skaber målbar værdi, mens andre forbliver fastlåst i pilot‑fasen?

Jeg startede min karriere som udvikler, og ligesom mange ingeniører havde jeg i starten en stærk intuition om, at hvis teknologien var god nok, så skulle værdien være åbenlys. Kunder lærer dig hurtigt, at så fungerer enterprise‑teknologi ikke.

En teknisk sofistikeret implementering kan stadig skabe meget lidt værdi, hvis forretningsproblemet ikke er vigtigt nok, hvis proces‑ejeren er fraværende, hvis integrationen betragtes som en eftertanke, eller hvis ingen har aftalt, hvad succes betyder. Kunder er ekstremt dygtige til at skrælle teknologinarrativet væk. De er ligeglade med, hvor elegant noget er arkitektonisk, hvis den proces, de er ansvarlige for, ikke er forbedret.

Når vi taler om implementeringer i den skala, er der en forretnings‑ejere med et reelt problem, der skal løses. Der er et målbart volumen, omkostning/indtægt eller friktion. AI’en er forbundet til de systemer, hvor arbejdet faktisk foregår. Og der er en plan for adoption og løbende forbedring efter go‑live. Piloter forbliver ofte piloter, fordi de beviser, at teknologien virker, uden at bevise, at driftsmodellen virker. Derfor træner vi, når vi løser et AI‑projekt, vores medarbejdere og partnere først i at forstå jobbet, ikke klik‑handlingerne i systemerne. “Jobbet” betyder hele processen, hvordan de håndterer undtagelser, hvad resultatet er, hvor ofte undtagelser forekommer, hvad der forhindrer produktivitetsforbedring, hvor lang tid det tager, og hvilken indsats der kræves for at opnå en produktivitetsstigning, hvis jobbet ikke ville blive automatiseret.

Min egen karriere har bevæget sig gennem teknologi, drift, salg, kundesucces og virksomhedsskabelse, og jeg ser nu denne bredde som en af mine største fordele. Teknologi lærer dig, hvordan noget fungerer. Salg lærer dig, hvorfor nogen vil betale for det. Kundesucces lærer dig, om det virker i den virkelige verden. Drift lærer dig, om organisationen kan levere det gentagne gange og i skala.

I mange henseender har Druid AI’s udvikling fulgt den samme vej: fra at bevise, at samtale‑AI kunne fungere, til at bevise, at den kunne skabe værdi, til at bygge den infrastruktur, der gør intelligente agenter pålidelige i enterprise‑skala.

Du har også været involveret i Women in Tech Romania, mens du byggede Druid til en international AI‑virksomhed. Hvor ser du stadig de største barrierer for kvinder, der grundlægger og leder AI‑virksomheder, og hvad vil væsentligt øge deres repræsentation på leder‑ og grundlæggerniveau? 

Nyere data fremhæver et markant gab i europæisk tech: kun 5 % af AI‑startups er grundlagt eller med‑grundlagt af kvinder, og kun halvdelen af disse grundlæggere har en PhD. Selvom tallene er skarpe, kræver det at adressere denne ubalance, at man ser ud over de traditionelle fortællinger om kønsdiskrimination.

I sin kerne er iværksætteri en individuel bestræbelse, formet af personlighed, risikotolerance, personlige prioriteter og karrierevalg. I stedet for kun at betragte dette som en social barriere, skal vi undersøge den praktiske pipeline, hvorigennem grundlæggere formes.

Selvom piger statistisk set er mindre tiltrukket af tekniske discipliner tidligt, dukker en langt mere betydningsfuld og mindre diskuteret barriere op senere i corporate‑karrieren: eksponering for fuldt forretningsansvar.

Kvinder udmærker sig ofte som verdensklasse tekniske specialister og funktionelle ledere. Færre skifter dog ind i roller med direkte indtægtsansvar, P&L‑styring, kommercielle beslutninger og overordnet corporate‑strategi. Disse er netop de operationelle muskler, der kræves for at grundlægge og skalere en enterprise‑teknologivirksomhed.

Min egen vej fra softwareudvikling til CEO var ikke en lineær linje, men en række overgange gennem ledelse, drift, kommerciel eksekvering og til sidst virksomhedsskabelse. I miljøer som det rumænske uddannelsessystem, hvor praktisk finansiel undervisning og iværksættertræning manglede for alle uanset køn, var læringen om at navigere forretningsrisiko en trin‑for‑trin‑proces med eksponering.

At overvinde dette gab kræver også at nedbryde en udbredt myte: idéen om, at teknologisk ledelse kræver fuldstændig mestring, før man træder frem. I den hastigt bevægende AI‑æra har ingen alle svar. De afgørende lederegenskaber i dag er nysgerrighed, kontinuerlig læring og selvtillid til at tackle komplekse problemer, før resultatet er garanteret.

For at se flere kvinder lede teknologivirksomheder, skal vi udvide adgangen til kommercielle netværk, fremme synlige rollemodeller og aktivt opfordre erfarent talent til at træde ud af funktionelle siloer, påtage sig P&L‑ansvar og omfavne risiciene ved forretningsansvar.

Ser du fremad, hvad tror du vil adskille de enterprise‑AI‑platforme, der bliver dybt integreret i forretningsdrift, fra de mange AI‑produkter, der i sidste ende kæmper med at komme videre end eksperimentering?

Den afgørende sondring vil være, om de kan gå fra intelligens til pålidelig eksekvering.

At generere et imponerende svar bliver allerede relativt let. At fungere pålideligt inden for en stor virksomhed er en anden historie.

Platforme, der bliver indlejret i forretningsdrift, skal kunne forbinde sikkert til eksisterende systemer i stedet for at kræve, at virksomheder erstatter alt, hvad de allerede bruger. De skal kunne arbejde på tværs af forskellige modeller og teknologier.

De skal have orkestrering, der kan koordinere agenter, workflows og menneskelige beslutninger. Og de skal have identitet, governance, observabilitet og kontrol indbygget i arkitekturen i stedet for tilføjet senere.

Men der er et andet krav, som jeg tror vil adskille eksperimenter fra infrastruktur i stigende grad: pålidelighed under uperfekte forhold. En demonstration viser, hvad et AI‑system kan gøre, når alt fungerer, men en enterprise vil vide, hvad der sker, når noget går galt.

Hvad sker der, når data er ufuldstændige? Når et API fejler? Når to politikker er i konflikt? Når tilliden er lav? Når en bruger beder om noget, de ikke har ret til?

Hvis en agent performer strålende 90 % af tiden, men opfører sig uforudsigeligt i de resterende 10 %, kan du ikke give den ansvar for en mission‑kritisk proces.

I de sidste år har det dominerende spørgsmål været: “Hvad kan denne model gøre?”

Enterprise‑spørgsmålet bliver: “Hvordan kan jeg få dette arbejde gjort effektivt?”

De AI‑platforme, der bliver dybt indlejret i organisationer, vil være dem, der kan besvare det andet spørgsmål overbevisende: teknisk, operationelt og økonomisk. Det er i sidste ende den mulighed, vi så, da vi startede Druid AI: at gøre intelligens til en del af, hvordan arbejdet selv bliver udført.

Tak for det fantastiske interview, læsere der ønsker at lære mere, bør besøge Druid AI.