Andreea Pleşea, PhD, COO og medgründer av Druid AI – Intervjuserie

Andreea Pleşea, PhD, COO og medgründer av Druid AI, er en teknologileder og entreprenør med nesten to tiår erfaring innen programvareutvikling, bedrifts‑teknologi, kunstig intelligens, drift og kundesuksess. Siden hun medgründet Druid AI, har hun hatt flere seniorlederroller i organisasjonen, inkludert Chief Operating Officer, Chief Revenue Officer og Chief Customer Success Officer, noe som gir henne erfaring på både den tekniske og kommersielle siden av å skalere et bedriftsprogramvareselskap. Før Druid AI tilbrakte Pleşea nesten ti år i TotalSoft, hvor hun gikk fra .NET‑programmerer til Software Development Manager og til slutt Charisma Business Applications Director, med ansvar for produktutvikling, implementering, teknisk support, løsningsarkitektur og P&L‑ansvar. Hennes akademiske bakgrunn inkluderer også AI‑forskning ved University of Rome Tor Vergata, hvor hun samarbeidet med universitetets Artificial Intelligence Research Group om teknologi for å hente ut og strukturere informasjon fra ustrukturert data. Hun sitter også i rådgivende styre for Women in Tech Romania.

Druid AI er et bedrifts‑AI‑selskap som fokuserer på å bygge og orkestrere AI‑agenter som kan automatisere komplekse forretningsprosesser på tvers av organisasjoner. Plattformen kombinerer naturlig språkforståelse, generativ AI, retrieval‑augmented generation (RAG), bedriftsintegrasjoner, arbeidsflytautomatisering, analyse og styring, med Druid Conductor som koordinerer flere spesialiserte agenter og systemer mot forretningsmål. Organisasjoner kan koble Druid‑agentene til systemer som enterprise resource planning (ERP), customer relationship management (CRM), IT service management (ITSM) og HR‑plattformer, samtidig som teknologien kan distribueres i sky, hybrid, lokalt eller luft‑avkoblede miljøer. Selskapet oppgir at teknologien brukes av mer enn 300 bedriftskunder og støttes av over 200 globale partnere, med anvendelser innen medarbeiderstøtte, kundeservice, helsevesen, høyere utdanning og delte tjenester.

Du medgründet Druid AI i Bucuresti i 2018 etter å ha tilbrakt nesten ti år i TotalSoft, hvor du gikk fra .NET‑utvikling til senior teknologisk og forretningsledelse. Hva overbeviste deg den gangen om at samtale‑AI kunne bli et kjerne­lag i bedrifts­teknologi, og hvordan har den opprinnelige visjonen utviklet seg etter hvert som Druid har gått over til agent‑AI? 

Sammenkoblingen av to ulike veier – akademisk grundighet og frontlinjens bedriftsutfordringer – formet tankegangen min mens jeg gjorde min PhD. Men det var først da Liviu Dragan, en svært visjonær leder, kom på idéen om å grunnlegge Druid AI, at jeg innså hvordan forskningen min endelig kunne brukes i praksis.

Mellom 2008 og 2011 fokuserte PhD‑forskningen min på autonome AI‑agenter som kommuniserte via semantiske web‑teknologier og ontologier, og undersøkte hvordan intelligente systemer kunne erstatte eller ligge over tradisjonell bedriftsprogramvare. Kort tid etter ga arbeidet i ledelse av bedrifts‑teknologi meg innsikt i en hard realitet: vi ba ansatte håndtere en uholdbar kompleksitet.

Å fullføre en enkelt rutineoppgave betydde å vite hvilken applikasjon som skulle åpnes, hvor dataene lå, hvilken policy som gjaldt, og hvem som eide neste steg. Samtidig ble meldingssystemer utenfor kontoret den dominerende grensesnittet for menneskelig samhandling.

Da vi grunnla Druid AI i 2018, var vår visjon enkel, men ambisiøs: å gi hver ansatt og kunde en virtuell assistent som kunne orkestrere arbeid på tvers av hele virksomheten.

Nesten et tiår senere har ikke den kjerne­visjonen endret seg – teknologien har bare tatt igjen. Samtale‑AI handlet i hovedsak om intensjonsgjenkjenning, henting og aktivering av statiske skript. Agent‑AI flytter grensene for delegasjon. Moderne agenter vurderer mål, samarbeider med spesialiserte under‑agenter, navigerer i ulike systemer og utfører komplekse, flertrinns arbeidsflyter autonomt.

For oss er den nåværende agent‑revolusjonen ikke et strategisk avvik fra samtale‑AI. Det er den naturlige realiseringen av vårt grunnleggende prinsipp: bedrifts‑teknologi må bli enklere for mennesker slik at de får jobben gjort, selv om orkestreringen bak kulissene blir uendelig mer sofistikert.

Store deler av AI‑industrien har konsentrert seg om å bygge stadig kraftigere grunnmodeller, mens Druid AI har fokusert på å koble ulike modeller til bedriftsdata, systemer og arbeidsflyter. Etter hvert som modeller blir stadig mer utskiftbare, tror du at orkestrering vil bli en viktigere konkurransefordel enn selve den underliggende modellen?

Hos Druid AI er vårt kjerne­mål enkelt: å hente det ekstraordinære frem fra hver menneskelig interaksjon ved å effektivt få jobben gjort. Men etter hvert som markedet modnes, flytter nøkkelen til å levere den verdien seg bort fra den underliggende teknologiske stabelen.

Vi ser et klassisk mønster i bedrifts‑teknologi: funksjoner som tidligere var tidlige differensieringsfaktorer, blir raskt en vare. I dag er grunnmodeller tilgjengelige for alle aktører. Bedrifter vil uunngåelig distribuere en hybrid matrise av modeller valgt for spesifikk ytelse, kostnad, sikkerhet eller regulatoriske krav. Etter hvert som intelligens blir en vare, flytter den strategiske slagmarken seg oppover i stabelen.

I dag er de vanskeligste problemene innen bedrifts‑AI knyttet til utførelseskontekst: styring og tilgang (hvilke data AI‑en kan berøre, og under hvilke policyer), agent‑routing (hvilken spesialisert agent som skal håndtere en gitt oppgave), systemintegrasjon (hvordan flere transaksjonelle systemer kan koordineres trygt), autonomi vs. kontroll (når kan en agent handle uavhengig, og når kreves menneskelig godkjenning), og sporbarhet (hvis en arbeidsflyt feiler, kan du rekonstruere beslutningsløpet trinn for trinn).

Derfor har orkestrering blitt den ultimate strategiske løftestangen. Modeller produserer intelligens, men bedrifter krever pålitelig utførelse.

Druid AI er bygget for å fungere som dette definitive kontroll‑ og orkestreringslaget. Den kobler ulike modeller trygt over bedriftsdata, arbeidsflyter og mennesker. Avgjørende er at den gir et referanserammeverk for å måle utførelseseffektivitet og evaluere reelle forretningsresultater.

På lang sikt vil ikke det vinnende spørsmålet være, “Hvilken modell bruker du?” Det vil være, “Hvor effektivt kan du omgjøre rå intelligens til fullført arbeid for dine ansatte og kunder?”

Druid Conductor kan koordinere flere spesialiserte agenter innen kunnskapshenting, beslutningslogikk og systemhandlinger. Hva blir teknisk vanskelig når en bedrift går fra en enkelt AI‑assistent som svarer på spørsmål til flere agenter som uavhengig kan utføre flertrinns forretningsprosesser?

Overgangen fra enkle samtalegrensesnitt til multi‑agent‑arkitekturer endrer grunnleggende ingeniøroppgaven. Du slutter å håndtere en lineær samtale og begynner å administrere et distribuert beslutnings‑ og utførelsessystem.

Med en enkelt Q&A‑assistent er de viktigste hindringene intensjonsgjenkjenning, henting og svargenerering med høy nøyaktighet. Multi‑agent‑økosystemer introduserer en helt annen klasse av distribuerte systemer og spørsmål:

1. Hvilken agent har myndighet til å handle, og hvordan forhindrer du domene‑drift?
2. Hvordan opprettholdes tilstand når ansvars‑overleveringer skjer mellom agenter?
3. Hvordan forsones motstridende beslutninger mellom spesialiserte agenter?
4. Hvordan arver under‑agenter tilgangstillatelser dynamisk og trygt?

Disse utfordringene forsterkes når de anvendes på virkelige bedriftsinfrastrukturer. En enkelt arbeidsflyt kan omfatte et CRM, ERP, identitets‑administrasjonsplattform, ticketsystem og eldre databaser. Hver opererer under distinkt forretningslogikk og feilmoduser, men til slutt må konduktør‑agenten få jobben gjort riktig.

Hvis trinn fire i en seks‑trinns prosess feiler etter at tre systemer allerede har utført transaksjonsendringer, bryter en enkel agent‑pipeline sammen. Orkestreringslaget kan ikke bare kaste en generisk feil. Det må håndtere tilstand, utføre tilbakeføringer om nødvendig, fastslå om alternativ ruting finnes, eller elegant eskalere til menneskelig inngripen i løkken.

Sann bedrifts‑orkestrering er tilstandshåndtering, transaksjons‑konsistens, observabilitet, policy‑håndheving og feil‑sikker autonomi. Målet med denne underliggende kompleksiteten er enkelhet: å levere en enkelt, friksjonsfri interaksjon hvor komplekse fler‑systemsoppgaver rett og slett blir gjort.

Druid AI har nå drevet mer enn én milliard samtaler gjennom tusenvis av distribuerte agenter. På den skalaen, hva har du lært om bedrifts‑AI som ville vært umulig å lære fra pilotprosjekter eller kontrollerte demonstrasjoner?

Produksjon lærer deg ydmykhet raskt.

En pilot er normalt et relativt kontrollert miljø. Brukstilfellet er definert, dataene er rimelig rene, brukerne er kjente, og det er vanligvis et prosjektteam som følger nøye med.

Produksjon oppfører seg på ingen måte slik. Folk stiller det samme spørsmålet på tjue forskjellige måter. De endrer mening midt i en samtale. De gir ufullstendig informasjon. De bytter språk eller tema. De interagerer på uventede tidspunkter. Policyer endres. API‑er feiler. Backend‑systemer blir trege. Nye kant‑tilfeller dukker opp som ingen hadde tenkt på i det opprinnelige designet. En ting er sikkert: brukernes forventning er å få jobben gjort effektivt, sømløst og på en naturlig måte. Enten det er tekst, men spesielt tale, skal samtalen flyte naturlig, uten latens; den skal i noen grad virke empatisk, og utføre oppgaven samtidig som den foreslår de beste alternativene og neste steg, eller behandle unntak og løkker menneskelig når nødvendig.

Noe av den høyest verdifulle automatiseringen kommer fra å gjøre relativt vanlige oppgaver eksepsjonelt bra og gjøre dem hundretusener av ganger: svare på en ansatts spørsmål, sjekke en konto, ombooke en avtale, løse en IT‑forespørsel, eller hente riktig informasjon fra et bedriftsystem. Det endret måten vi tenker på AI‑verdi.

Den andre lærdommen er at igangkjøring bare er starten på en læringssyklus. Du må se hva brukerne etterspør, hvilke intensjoner som vokser, hvor samtaler feiler, hvor folk eskalerer, og noen ganger hvor den underliggende forretningsprosessen selv må endres.

Kanskje den viktigste lærdommen er at tillit er operasjonell, ettersom bedrifter stoler på AI fordi den over tid oppfører seg forutsigbart, unntak håndteres korrekt, beslutninger er synlige og organisasjonen forblir i kontroll.

Druids produksjonsdata antyder at et relativt lite antall arbeidsflyter kan stå for en stor del av den faktiske bedrifts‑AI‑bruken. Indikerer dette at selskaper i første omgang bør fokusere AI‑investeringer på noen få høy‑volum arbeidsflyter i stedet for å forsøke en bred, virksomhetsomfattende transformasjon?

Et av de tydeligste mønstrene i våre produksjonsdata er at etterspørselen har en tendens til å konsentreres. I finanssektoren, for eksempel, står tre arbeidsflytkategorier for rundt 90 % av produksjonsbruken. I høyere utdanning er konsentrasjonen enda høyere. Det forteller oss noe viktig om hvordan selskaper bør tenke på AI‑transformasjon. Vi har analysert disse innsiktene og laget benchmark‑rapporter for høyere utdanning, helsevesen og bank, som gjør det mulig for våre partnere og kunder å identifisere prosesser som vil drive effektivitet og hjelpe med å forutsi hvordan mennesker vil samhandle med agenter.

Det er en fristelse, spesielt på styrenivå, å starte med et svært bredt krav: «Dere MÅ bruke AI ellers blir vi etterlatt». Operasjonsteamet må da slite med å identifisere de riktige oppgavene agentene kan utføre, samtidig som de frykter å miste sine egne jobber. Så, hva vil være den rette balansen, og hvordan kan de ansette den rette AI‑agenten som gjør jobben SAMMEN med dem mens de maksimerer KPI‑ene styret forventer?

Start der det er potensial for å øke inntektene og/eller redusere kostnader, ting folk vanligvis gjør gjentatte ganger. Hvis tusenvis av kunder, ansatte, studenter eller pasienter gjentatte ganger prøver å oppnå samme resultat, har du et målbare grunnlag og en sterk mulighet til å demonstrere verdi.

Men det er en viktig distinksjon: start smalt, arkitekt bredt.

De første bruksområdene kan konsentreres. Plattformen under dem bør kunne utvides på tvers av virksomheten. Du beviser økonomien, styringsmodellen, integrasjoner og menneskelige eskaleringsmekanismer på noen få meningsfulle arbeidsflyter. Deretter utvider du til tilstøtende prosesser ved å bruke det du har lært.

Volum bør ikke være det eneste kriteriet. En lav‑frekvens arbeidsflyt kan fortsatt være svært verdifull hvis hver vellykket løsning medfører betydelig økonomisk eller operasjonell påvirkning.

Etter hvert som bedrifter i økende grad fokuserer på vellykket løsning i stedet for bare å maksimere prosentandelen av interaksjoner håndtert uten mennesker, hvordan bør organisasjoner avgjøre hvilke beslutninger en AI‑agent kan ta autonomt og hvor menneskelig eskalering skal forbli obligatorisk?

Druid AI har bygget et evalueringsrammeverk som dekker 26 kriterier og sikrer en objektiv vurdering av den agent‑baserte orkestreringen fra hvordan den ble bygget til hvordan den får jobben gjort.

Hvis en handling er reversibel, relativt lav‑risiko, styrt av klare regler og støttet av pålitelig informasjon, er det et sterkt argument for autonomi. Å ombooke en avtale med forhåndsdefinerte parametere er svært forskjellig fra å ta en klinisk beslutning og kan virke enkelt. Men det bør ha mange elementer å vurdere for å bli gjort effektivt: f.eks. hvis lege B har en ledig tid, men han ønsker å reservere den, bør AI‑agenten ikke ombooke en pasients avtale i den timen bare fordi oppgaven er å maksimere legens kalenderdekning.

Det er flere dimensjoner jeg ville se på: den økonomiske eller menneskelige konsekvensen av en feil, om handlingen er reversibel, fullstendigheten og kvaliteten på tilgjengelig informasjon, regulatoriske krav, og om ekte menneskelig vurdering eller empati er nødvendig. Deretter designer du eskalering bevisst.

Dette er hvor jeg mener tidlig tenkning rundt AI‑automatisering var for enkel. Målet ble «å holde så mange interaksjoner som mulig uten å involvere et menneske». Men i mange prosesser er eskalering nettopp det riktige resultatet.

Derfor foretrekker jeg å tenke i termer av styrt løsning fremfor ren innestengning.

Målet er at AI skal autonomt løse det arbeidet den skal løse, gjenkjenne situasjoner der den ikke bør handle, og bringe en person inn i prosessen med relevant kontekst allerede samlet.

Når AI‑agenter kan hente sensitiv informasjon, oppdatere bedriftsystemer og igangsette handlinger i den virkelige verden, blir observabilitet og styring mye viktigere. Hva bør selskaper kunne revidere om en agents resonnering, data‑tilgang og handlinger før de stoler på den i kritiske arbeidsflyter?

I henhold til Gartner‑retningslinjer har DRUID et innebygd evalueringsrammeverk som analyserer agenter fra 5 vinkler: feil‑toleranse, risiko, etterlevelse, observabilitet og avvik. Under disse kategoriene har vi totalt 26 komponenter. Hver har en definisjon, et artefakt du kan åpne, og en måling.

Ved evaluering av en agent bør plattformen kunne rekonstruere hele kjeden fra den opprinnelige brukerforespørselen til den endelige handlingssystemet. Det innebærer å vite hvilken agent som håndterte forespørselen, hvilken modell som ble brukt, hvilken kontekst modellen mottok, hvilken bedriftsinformasjon som ble hentet, hvilke forretningsregler eller policyer som ble anvendt, hvorfor en bestemt rute eller handling ble valgt, og nøyaktig hva som endret seg i de underliggende systemene. Tiendedeler av reviderbare interaksjoner spores, analyseres og måles.

Identitet er like viktig. En AI‑agent bør aldri bli en snarvei rundt bedrifts‑tilgangskontrollen. Du må vite hvem som initierte forespørselen, hva den personen var autorisert til å se eller gjøre, og om agenten holdt seg innen nøyaktig de grensene.

Med multi‑agent‑arkitekturer blir sporbarhet enda viktigere. Hvilken agent delegert til en annen agent? Hvilken informasjon krysset den grensen? Hvor oppsto beslutningen? Hvilken komponent utførte handlingen? Og så er det operasjonelle bevis: tidsstempler, tillits‑signal, utførelsesresultater, unntak, eskalerings‑hendelser og evnen til å forstå eller gjenskape hva som skjedde.

Dette er en av de største endringene når vi går fra samtale‑AI til agent‑AI.

Når AI bare svarer på et spørsmål, er observabilitet nyttig. Når AI kan endre en kundepost, utløse en betaling, oppdatere flere registreringssystemer eller igangsette en forretningsprosess, blir observabilitet en del av kontrollarkitekturen.

Du har hatt en usedvanlig bred rolleportefølje i Druid AI, fra utvikling, drift, inntekter til kundesuksess. Hvordan har direkte arbeid med kunder påvirket ditt syn på hvorfor noen bedrifts‑AI‑implementeringer genererer målbar verdi mens andre forblir fast i pilotmodus?

Jeg startet karrieren som utvikler, og som mange ingeniører hadde jeg i begynnelsen en sterk instinkt om at hvis teknologien var god nok, burde verdien være tydelig. Kunder lærer deg svært raskt at dette ikke er hvordan bedrifts‑teknologi fungerer.

En teknisk sofistikert implementering kan fortsatt skape svært lite verdi hvis forretningsproblemet ikke er viktig nok, hvis prosesseieren er fraværende, hvis integrasjon behandles som en ettertanke, eller hvis ingen har blitt enige om hva suksess betyr. Kunder er ekstremt flinke til å fjerne teknologinarrativet. De bryr seg ikke om hvor elegant noe er arkitektonisk hvis prosessen de er ansvarlige for ikke har blitt forbedret.

Når vi snakker om implementeringer i den skalaen, finnes det en forretningsansvarlig med et reelt problem å løse. Det er et målbare volum, kostnad/inntekt eller friksjon. AI‑en er koblet til systemene hvor arbeidet faktisk skjer. Og det finnes en plan for adopsjon og kontinuerlig forbedring etter igangkjøring. Pilotprosjekter forblir ofte pilotprosjekter fordi de beviser at teknologien fungerer uten å bevise at driftsmodellen fungerer. Derfor trener vi, når vi løser et AI‑prosjekt, vårt personale og partnere til først å forstå jobben, ikke klikkene brukerne gjør i systemene. «Jobben» betyr hele prosessen, hvordan de håndterer unntak, hva utfallet er, hvor ofte unntak oppstår, hva som hindrer dem i å øke produktiviteten, hvor lang tid det tar og hvilken innsats som kreves for å oppnå en produktivitetsøkning dersom jobben ikke blir automatisert.

Min egen karriere har beveget seg gjennom teknologi, drift, salg, kundesuksess og selskap‑bygging, og jeg ser nå dette brede spekteret som en av mine største fordeler. Teknologi lærer deg hvordan noe fungerer. Salg lærer deg hvorfor noen vil betale for det. Kundesuksess lærer deg om det fungerer i den virkelige verden. Drift lærer deg om organisasjonen kan levere det gjentatte ganger og i skala.

På mange måter har Druid AI sin utvikling fulgt samme vei: fra å bevise at samtale‑AI kan fungere, til å bevise at den kan skape verdi, til å bygge infrastrukturen som kreves for å gjøre intelligente agenter pålitelige i bedrifts‑skala.

Du har også vært involvert i Women in Tech Romania mens du bygde Druid til et internasjonalt AI‑selskap. Hvor ser du fortsatt de største barrierene for kvinner som grunnlegger og leder AI‑selskaper, og hva vil meningsfullt øke deres representasjon på leder‑ og grunnleggernivå? 

Nyere data viser et påfallende gap i europeisk teknologi: kun 5 % av AI‑oppstartsselskaper er grunnlagt eller medgrunnlagt av kvinner, og bare halvparten av disse grunnleggerne har en PhD. Selv om statistikken er tydelig, krever håndtering av dette skjevheten å se utover tradisjonelle fortellinger om kjønnsdiskriminering.

I kjernen er entreprenørskap en individuell streben formet av personlighet, risikotoleranse, personlige prioriteringer og karrierevalg. I stedet for å se dette kun som en sosial barriere, må vi undersøke den praktiske rørledningen gjennom hvilken grunnleggere blir skapt.

Selv om jenter statistisk sett er mindre tiltrukket av tekniske disipliner tidlig, dukker en langt mer betydningsfull og mindre diskutert barriere opp senere i bedriftskarrierer: eksponering for fullt forretningsansvar.

Kvinner utmerker seg ofte som verdensklasse tekniske spesialister og funksjonelle ledere. Færre går imidlertid over i roller med direkte inntektsansvar, P&L‑styring, kommersiell beslutningstaking og overordnet bedriftsstrategi. Dette er nettopp de operative musklene som kreves for å grunnlegge og skalere et bedrifts‑teknologiselskap.

Min egen bane fra programvareutvikling til administrerende direktør var ikke en lineær linje, men en rekke overganger gjennom ledelse, drift, kommersiell gjennomføring og til slutt selskap‑bygging. I miljøer som det rumenske utdanningssystemet, hvor praktisk økonomi‑utdanning og entreprenør‑trening manglet for alle uavhengig av kjønn, var læringen om å navigere forretningsrisiko en trinn‑for‑trinn‑prosess med eksponering.

Å overvinne dette gapet krever også å rive ned en vanlig myte: idéen om at teknologiledelse krever absolutt mestring før man trår frem. I en æra med raskt utviklende AI har ingen alle svar. De definerende lederegenskapene i dag er nysgjerrighet, kontinuerlig læring og selvtilliten til å takle komplekse problemer før resultatet er garantert.

For å se flere kvinner lede teknologiselskaper, må vi utvide tilgangen til kommersielle nettverk, fremme synlige rollemodeller, og aktivt oppmuntre erfarne talenter til å gå ut av funksjonelle siloer, ta P&L‑ansvar og omfavne risikoen ved forretningsansvar.

Ser vi fremover, hva tror du vil skille de bedrifts‑AI‑plattformene som blir dypt integrert i forretningsdriften fra de mange AI‑produktene som til slutt sliter med å gå utover eksperimentering?

Skillelinjen vil være om de kan gå fra intelligens til pålitelig utførelse.

Å generere et imponerende svar blir allerede relativt enkelt. Å operere pålitelig innen en stor bedrift er en annen historie.

Plattformene som blir integrert i forretningsdriften, må kunne koble seg sikkert til eksisterende systemer i stedet for å be selskaper om å erstatte alt de allerede bruker. De må kunne fungere på tvers av ulike modeller og teknologier.

De vil trenge orkestrering som kan koordinere agenter, arbeidsflyter og menneskelige beslutninger. Og de vil trenge identitet, styring, observabilitet og kontroll innlemmet i arkitekturen i stedet for lagt til etterpå.

Men det er et annet krav som jeg tror vil skille eksperimenter fra infrastruktur i økende grad: pålitelighet under uperfekte forhold. En demonstrasjon viser hva et AI‑system kan gjøre når alt fungerer, men en bedrift vil vite hva som skjer når noe ikke gjør det.

Hva skjer når dataene er ufullstendige? Når et API feiler? Når to policyer er i konflikt? Når tilliten er lav? Når en bruker ber om noe de ikke har autorisasjon til?

Hvis en agent presterer strålende 90 % av tiden, men oppfører seg uforutsigbart i de resterende 10 %, kan du ikke gi den ansvar for en kritisk prosess.

De siste årene har det dominerende spørsmålet vært: «Hva kan denne modellen gjøre?»

Bedrifts‑spørsmålet blir: «Hvordan kan jeg få dette arbeidet gjort effektivt?»

AI‑plattformene som blir dypt integrert i organisasjoner, vil være de som kan svare på det andre spørsmålet overbevisende: teknisk, operasjonelt og økonomisk. Det er i bunn og grunn den muligheten vi så da vi startet Druid AI: å gjøre intelligens til en del av hvordan arbeidet i seg selv blir gjort.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Druid AI.