Andreea Pleşea, PhD, COO och medgrundare av Druid AI – Intervjuserie

Andreea Pleşea, PhD, COO och medgrundare av Druid AI, är en teknikchef och entreprenör med nästan två decennier av erfarenhet inom mjukvaruutveckling, företags‑teknik, artificiell intelligens, drift och kundframgång. Sedan hon medgrundade Druid AI har hon haft flera seniora ledarroller i organisationen, inklusive Chief Operating Officer, Chief Revenue Officer och Chief Customer Success Officer, vilket ger henne erfarenhet både på den tekniska och kommersiella sidan av att skala ett företag med företagsprogramvara. Före Druid AI tillbringade Pleşea nästan ett decennium på TotalSoft, där hon gick från .NET‑programmerare till Software Development Manager och så småningom Charisma Business Applications Director, med ansvar för produktutveckling, implementering, teknisk support, lösningsarkitektur och P&L‑ansvar. Hennes akademiska bakgrund inkluderar även AI‑forskning vid University of Rome Tor Vergata, där hon arbetade med universitetets Artificial Intelligence Research Group med teknik för att extrahera och strukturera information från ostrukturerad data. Hon sitter också i rådgivande styrelsen för Women in Tech Romania.

Druid AI är ett företags‑AI‑företag som fokuserar på att bygga och orkestrera AI‑agenter som kan automatisera komplexa affärsprocesser i organisationer. Plattformen kombinerar naturlig språkförståelse, generativ AI, retrieval‑augmented generation (RAG), företagsintegrationer, arbetsflödesautomatisering, analys och styrning, med Druid Conductor som koordinerar flera specialiserade agenter och system mot affärsresultat. Organisationer kan koppla Druid‑agenter till system som enterprise resource planning (ERP), customer relationship management (CRM), IT service management (ITSM) och HR‑plattformar, samtidigt som tekniken kan driftsättas i moln, hybrid, lokalt eller i luftgapade miljöer. Företaget uppger att tekniken används av mer än 300 företagskunder och stöds av över 200 globala partners, med tillämpningar inom medarbetarstöd, kundservice, sjukvård, högre utbildning och delade tjänster.

Du medgrundade Druid AI i Bukarest 2018 efter att ha tillbringat nästan ett decennium på TotalSoft, där du gick från .NET‑utveckling till senior teknisk och affärsledning. Vad övertygade dig då om att konversations‑AI kunde bli ett kärnlager i företags‑teknik, och hur har den ursprungliga visionen utvecklats när Druid har gått över till agent‑AI? 

Sammanflätningen av två olika spår – akademisk stringens och frontlinjens företagsproblem – formade mitt tankesätt under min doktorandtid. Men det var först när Liviu Dragan, en extremt visionär ledare, kom på idén att grunda Druid AI som jag insåg hur min forskning äntligen kunde tillämpas i verkligheten.

Mellan 2008 och 2011 fokuserade min doktorandforskning på autonoma AI‑agenter som kommunicerade via semantiska webbteknologier och ontologier, och undersökte hur intelligenta system kunde ersätta eller ligga ovanpå traditionell företagsprogramvara. Kort därefter, när jag arbetade i ledande roller inom företags‑teknik, konfronterades jag med en skarp verklighet: vi bad anställda hantera ohanterlig komplexitet.

Att slutföra en enda rutinuppgift innebar att veta vilken applikation som skulle öppnas, var data fanns, vilken policy som gällde och vem som ägde nästa steg. Samtidigt blev meddelandetjänster utanför kontoret det dominerande gränssnittet för mänsklig interaktion.

När vi grundade Druid AI 2018 var vår vision enkel men ambitiös: att ge varje anställd och kund en virtuell assistent som kan orkestrera arbete i hela företaget.

Snart ett decennium senare har den grundläggande visionen inte förändrats – tekniken har bara hunnit ikapp. Konversations‑AI handlade främst om avsiktsigenkänning, hämtning och att trigga statiska skript. Agent‑AI förändrar gränsen för delegation. Moderna agenter bedömer mål, samarbetar med specialiserade underagenter, navigerar bland olika system och utför komplexa, flerstegade arbetsflöden autonomt.

För oss är den nuvarande agent‑revolutionen inte ett strategiskt avsteg från konversations‑AI. Det är den naturliga förverkligandet av vårt grundläggande påstående: företags‑teknik måste bli enklare för människor så att de kan utföra sitt arbete, även när orkestreringen bakom scenen blir oändligt mer sofistikerad.

Större delen av AI‑industrin har fokuserat på att bygga allt kraftfullare grundmodeller, medan Druid AI har fokuserat på att koppla olika modeller till företagsdata, system och arbetsflöden. När modeller blir alltmer utbytbara, tror du att orkestrering kommer att bli en viktigare konkurrensfördel än själva den underliggande modellen?

På Druid AI är vårt kärnmål enkelt: att extrahera det extraordinära ur varje mänsklig interaktion genom att effektivt få jobbet gjort. Men när marknaden mognar flyttas nyckeln till att leverera detta värde bort från den underliggande teknikstacken.

Vi ser ett klassiskt mönster inom företags‑teknik: funktioner som tidigare var tidiga differentieringsfaktorer blir snabbt standardiserade. Idag är grundmodeller tillgängliga för alla aktörer. Företag kommer oundvikligen att implementera en hybridmatris av modeller som väljs utifrån specifik prestanda, kostnad, säkerhet eller regulatoriska krav. När intelligens blir en vara flyttas den strategiska stridszonen uppåt i stacken.

Idag är de svåraste problemen inom företags‑AI relaterade till exekveringskontext: styrning och åtkomst (vilken data AI får röra och under vilka policyer), agent‑routing (vilken specialiserad agent som ska hantera en given uppgift), systemintegration (hur flera transaktionssystem koordineras säkert), autonomi vs. kontroll (när kan en agent agera självständigt och när krävs mänskligt godkännande), samt auditabilitet (om ett arbetsflöde misslyckas, kan du rekonstruera beslutsspåret steg för steg).

Det är därför orkestrering har blivit det ultimata strategiska verktyget. Modeller skapar intelligens, men företag kräver pålitlig exekvering.

Druid AI är byggt för att fungera som det definitiva kontroll‑ och orkestreringslagret. Det förenar olika modeller på ett säkert sätt över företagsdata, arbetsflöden och människor. Avgörande är att det erbjuder ett referensramverk för att mäta exekveringseffektivitet och utvärdera verkliga affärsresultat.

På lång sikt kommer den vinnande frågan inte vara, “Vilken modell använder du?” Den kommer att vara, “Hur effektivt kan du omvandla rå intelligens till färdigt arbete för dina anställda och kunder?”

Druid Conductor kan samordna flera specialiserade agenter för kunskapshämtning, beslutslogik och systemåtgärder. Vad blir tekniskt svårt när ett företag går från en enda AI‑assistent som svarar på frågor till flera agenter som självständigt kan utföra flerstegade affärsprocesser?

Övergången från enkla konversationsgränssnitt till multi‑agent‑arkitekturer förändrar i grunden ingenjörsutmaningen. Du slutar hantera ett linjärt samtal och börjar hantera ett distribuerat beslut‑ och exekveringssystem.

Med en enda Q&A‑assistent är de grundläggande hindren avsiktsigenkänning, hämtning och svarsgenerering med hög precision. Multi‑agent‑ekosystem introducerar en helt annan klass av distribuerade system och frågor:

1. Vilken agent har befogenhet att agera, och hur förhindrar du domänavdrift?
2. Hur upprätthålls tillståndet när ansvar överlämnas mellan agenter?
3. Hur löses motsägelsefulla beslut mellan specialiserade agenter?
4. Hur ärver underagenter åtkomstbehörigheter dynamiskt och säkert?

Dessa utmaningar förvärras när de tillämpas på verklig företagsinfrastruktur. Ett enda arbetsflöde kan sträcka sig över ett CRM, ERP, identitetshanteringsplattform, ärendehanteringssystem och äldre databaser. Varje system opererar med skilda affärslogiker och felmodeller, men i slutändan måste dirigent‑agenten utföra jobbet korrekt.

Om steg fyra i en sexstegsprocess misslyckas efter att tre system redan har utfört transaktionsändringar, bryts en grundläggande agent‑pipeline. Orkestreringslagret kan inte bara kasta ett generiskt fel. Det måste hantera tillstånd, utföra återställningar vid behov, avgöra om alternativ routing finns, eller elegant eskalera till mänsklig inblandning.

Äkta företags‑orkestrering är tillståndshantering, transaktionskonsistens, observabilitet, policy‑genomdrift och fel‑säker autonomi. Målet med denna underliggande komplexitet är enkelhet: att leverera en enda, friktionsfri interaktion där komplexa flersystemuppgifter enkelt blir utförda.

Druid AI har nu drivit mer än en miljard konversationer via tusentals distribuerade agenter. Vad har du på den skalan lärt dig om företags‑AI som skulle ha varit omöjligt att lära sig från pilotprojekt eller kontrollerade demonstrationer?

Produktion lär dig snabbt ödmjukhet.

En pilot är normalt en relativt kontrollerad miljö. Användningsfallet är definierat, data är relativt rena, användarna är kända och det finns vanligtvis ett projektteam som följer mycket noggrant.

Produktion beter sig inte alls så. Folk ställer samma fråga på tjugo olika sätt. De ändrar sig halvvägs genom en konversation. De ger ofullständig information. De byter språk eller ämne. De interagerar vid oväntade tidpunkter. Policyer förändras. API:er misslyckas. Backend‑system blir långsamma. Nya kantfall dyker upp som ingen tänkt på i den ursprungliga designen. En sak är säker: användarnas förväntning är att få jobbet gjort effektivt, sömlöst och på ett naturligt sätt. Oavsett om det är i text, men särskilt i röst, bör konversationen flyta naturligt utan fördröjning; den bör låta till viss del empatisk och utföra uppgiften samtidigt som den föreslår bästa alternativ och nästa steg om så behövs, eller hantera undantag och loopar mänskligt när det krävs.

Vissa av de mest värdefulla automatiseringarna kommer från att göra relativt vanliga saker exceptionellt väl och göra dem hundratusentals gånger: besvara en anställds fråga, kontrollera ett konto, omboka ett möte, lösa en IT‑förfrågan eller hämta rätt information från ett företagsystem. Det förändrade vårt sätt att tänka på AI‑värde.

Den andra lärdomen är att driftsättning bara är början på en lärandecykel. Du måste se vad användarna efterfrågar, vilka avsikter som växer, var konversationer misslyckas, var människor eskalerar, och ibland var den underliggande affärsprocessen själv måste förändras.

Och kanske den viktigaste lärdomen är att förtroende är operativt, eftersom företag litar på AI eftersom den över tid beter sig förutsägbart, undantag hanteras korrekt, beslut är synliga och organisationen behåller kontrollen.

Druids produktionsdata visar att ett relativt litet antal arbetsflöden kan stå för en stor del av den faktiska företags‑AI‑användningen. Indikerar detta att företag initialt bör fokusera AI‑investeringar på ett fåtal högvolymarbetsflöden snarare än att försöka en bred företagsomfattande transformation?

En av de tydligaste mönstren i vår produktionsdata är att efterfrågan tenderar att koncentreras. Inom finansiella tjänster, till exempel, står tre arbetsflödeskategorier för omkring 90 % av produktionsanvändningen. Inom högre utbildning är koncentrationen ännu högre. Det ger oss viktig insikt om hur företag bör tänka kring AI‑transformation. Vi har analyserat dessa insikter och tagit fram benchmark‑rapporter för högre utbildning, sjukvård och bankverksamhet, som möjliggör för våra partners och kunder att identifiera de processer som skulle driva effektivitet och hjälpa till att projicera hur människor kommer att interagera med agenter.

Det finns en frestelse, särskilt på styrelsenivå, att börja med ett mycket brett krav: ”Ni MÅSTE använda AI annars hamnar vi efter.” Det operativa teamet måste då kämpa med att identifiera rätt uppgifter som agenter kan utföra samtidigt som de fruktar att förlora sina jobb. Så, vad är den rätta balansen och hur kan de anlita rätt AI‑agent för att göra jobbet TILLSAMMANS med dem samtidigt som de maximerar de KPI som styrelsen förväntar sig?

Börja där det finns potential att öka intäkter och/eller minska kostnader, saker som vanligtvis utförs upprepade gånger. Om tusentals kunder, anställda, studenter eller patienter upprepade gånger försöker uppnå samma resultat har du en mätbar grundlinje och en stark möjlighet att bevisa värde.

Men det finns en viktig distinktion: börja smalt, arkitektera brett.

De första användningsfallen kan koncentreras. Plattformen under dem bör kunna expandera över hela företaget. Du bevisar ekonomin, styrningsmodellen, integrationerna och mänskliga eskaleringsmekanismer på ett fåtal meningsfulla arbetsflöden. Därefter expanderar du till närliggande processer med den kunskap du har fått.

Volym bör inte vara det enda kriteriet. Ett låg‑frekvent arbetsflöde kan fortfarande vara extremt värdefullt om varje lyckad lösning innebär betydande finansiell eller operativ påverkan.

Allt eftersom företag i allt högre grad fokuserar på lyckad lösning snarare än att bara maximera andelen interaktioner som hanteras utan mänsklig inblandning, hur bör organisationer avgöra vilka beslut en AI‑agent kan fatta autonomt och var mänsklig eskalering bör förbli obligatorisk?

Druid AI har byggt ett utvärderingsramverk som omfattar 26 kriterier och säkerställer en objektiv bedömning av den agent‑baserade orkestreringen, från hur den byggdes till hur den får jobbet gjort.

Om en åtgärd är reversibel, relativt lågrisk, styrs av tydliga regler och stöds av pålitlig information, finns det ett starkt argument för autonomi. Att omboka ett möte med fördefinierade parametrar är mycket annorlunda än att fatta ett kliniskt beslut och kan verka enkelt. Men det finns många faktorer att beakta för att göra det effektivt: t.ex. om läkare B har en ledig tid men vill blockera den, bör AI‑agenten inte omboka en patients möte i den tidsluckan bara för att uppgiften är att maximera läkarens kalenderutnyttjande.

Det finns flera dimensioner jag skulle beakta: den finansiella eller mänskliga konsekvensen av ett fel, om åtgärden är reversibel, fullständigheten och kvaliteten på den tillgängliga informationen, regulatoriska krav och om genuint mänskligt omdöme eller empati krävs. Därefter designar du eskalering med avsikt.

Det är här jag anser att tidig AI‑automatisering var för förenklad. Målet blev ”att innehålla så många interaktioner som möjligt utan mänsklig inblandning.” Men i många processer är eskalering precis rätt resultat.

Därför föredrar jag att tänka i termer av styrd lösning snarare än ren innehållning.

Målet är att AI autonomt löser det arbete den bör lösa, känner igen situationer där den inte bör agera och involverar en person i processen med relevant kontext redan samlad.

När AI‑agenter kan hämta känslig information, uppdatera företagssystem och initiera verkliga åtgärder blir observabilitet och styrning mycket mer avgörande. Vad bör företag kunna granska av en agents resonemang, dataåtkomst och handlingar innan de litar på den i kritiska arbetsflöden?

Enligt Gartner‑riktlinjer har DRUID ett inbyggt utvärderingsramverk som analyserar agenter ur fem perspektiv: fel‑tolerans, risk, efterlevnad, observabilitet och avvikelse. Under dessa kategorier har vi totalt 26 komponenter. Varje komponent har en definition, ett artefakt du kan öppna och ett mått.

Vid utvärdering av en agent bör plattformen kunna rekonstruera hela kedjan från den ursprungliga användarförfrågan till den slutgiltiga systemåtgärden. Det innebär att veta vilken agent som hanterade förfrågan, vilken modell som användes, vilket sammanhang modellen fick, vilken företagsinformation som hämtades, vilka affärsregler eller policyer som tillämpades, varför en viss rutt eller åtgärd valdes och exakt vad som förändrades i de underliggande systemen. Tiotal av audit‑interaktioner spåras, analyseras och mäts.

Identitet är lika viktigt. En AI‑agent bör aldrig bli en genväg runt företagsåtkomstkontrollen. Du måste veta vem som initierade förfrågan, vad den personen var auktoriserad att se eller göra, och om agenten höll sig exakt inom dessa gränser.

Med multi‑agent‑arkitekturer blir spårbarhet ännu viktigare. Vilken agent delegerade till en annan agent? Vilken information korsade den gränsen? Varifrån kom beslutet? Vilken komponent utförde faktiskt åtgärden? Och sedan finns operativ evidens: tidsstämplar, förtroendesignaler, exekveringsresultat, undantag, eskaleringshändelser och möjlighet att förstå eller återspela vad som hände.

Detta är en av de största förändringarna när vi går från konversations‑ till agent‑AI.

När AI bara svarar på en fråga är observabilitet användbart. När AI kan ändra en kundpost, trigga en betalning, uppdatera flera register eller initiera en affärsprocess blir observabilitet en del av kontrollarkitekturen.

Du har haft ett ovanligt brett spektrum av roller på Druid AI, från utveckling och drift till intäkter och kundframgång. Hur har direkt arbete med kunder format din syn på varför vissa företags‑AI‑implementeringar genererar mätbart värde medan andra fastnar i pilotläge?

Jag började min karriär som utvecklare, och likt många ingenjörer hade jag initialt en stark känsla att om tekniken var tillräckligt bra skulle dess värde vara uppenbart. Kunder lär dig mycket snabbt att så fungerar inte företags‑teknik.

En tekniskt sofistikerad implementering kan fortfarande skapa mycket lite värde om affärsproblemet inte är tillräckligt viktigt, om processägaren saknas, om integration behandlas som en eftertanke eller om ingen har kommit överens om vad framgång betyder. Kunder är extremt bra på att rensa bort teknik‑narrativet. De bryr sig inte om hur elegant något är arkitektoniskt om processen de ansvarar för inte har förbättrats.

När vi talar om implementationer i den skalan finns en affärsägare med ett verkligt problem att lösa. Det finns en mätbar volym, kostnad/intäkt eller friktion. AI är kopplat till de system där arbetet faktiskt sker. Och det finns en plan för antagande och kontinuerlig förbättring efter driftsättning. Pilotprojekt förblir ofta pilotprojekt eftersom de visar att tekniken fungerar utan att bevisa att driftmodellen fungerar. Därför tränar vi vår personal och våra partners att först förstå jobbet, inte de klick som användarna gör i systemen. ”Jobbet” betyder hela processen, hur de hanterar undantag, vad resultatet är, hur ofta undantag uppstår, vad som hindrar dem från att öka produktiviteten, hur lång tid det tar och vilken insats som krävs för att få en produktivitetsökning om jobbet inte automatiseras.

Min egen karriär har rört sig genom teknik, drift, försäljning, kundframgång och företagsbyggande, och jag ser nu den bredden som en av mina största fördelar. Teknik lär dig hur något fungerar. Försäljning lär dig varför någon betalar för det. Kundframgång lär dig om det fungerar i verkligheten. Drift lär dig om organisationen kan leverera det upprepade gånger och i skala.

På många sätt har Druid AI:s utveckling följt samma bana: från att bevisa att konversations‑AI kan fungera, till att bevisa att den kan skapa värde, till att bygga den infrastruktur som krävs för att göra intelligenta agenter pålitliga i företags‑skala.

Du har också varit involverad i Women in Tech Romania medan du byggde Druid till ett internationellt AI‑företag. Vilka ser du fortfarande som de största hindren för kvinnor att grunda och leda AI‑företag, och vad skulle på ett meningsfullt sätt öka deras representation på lednings‑ och grundarnivå? 

Ny data visar på ett slående gap i europeisk teknik: endast 5 % av AI‑startup‑företag grundas eller medgrundas av kvinnor, och bara hälften av dessa grundare har en PhD. Även om statistiken är tydlig kräver hanteringen av detta gap att man ser bortom traditionella berättelser om könsdiskriminering.

I grunden är entreprenörskap en individuell strävan som formas av personlighet, risktolerans, personliga prioriteringar och karriärval. Istället för att se detta enbart som ett socialt hinder måste vi undersöka den praktiska pipeline genom vilken grundare formas.

Medan flickor statistiskt sett är mindre dragna till tekniska discipliner tidigt, uppstår ett mycket mer betydelsefullt och mindre diskuterat hinder senare i företagskarriärer: exponering för fullt affärsansvar.

Kvinnor excellerar ofta som världsledande tekniska specialister och funktionella ledare. Färre övergår dock till roller med direkt intäktsansvar, P&L‑hantering, kommersiella beslut och övergripande företagsstrategi. Detta är exakt de operativa muskler som krävs för att grunda och skala ett företag inom företags‑teknik.

Min egen bana från mjukvaruutveckling till VD var inte en rak linje, utan en serie övergångar över ledarskap, drift, kommersiell genomförande och slutligen företagsbyggande. I miljöer som det rumänska utbildningssystemet, där praktisk ekonomisk utbildning och entreprenörsträning saknades för alla oavsett kön, var lärandet att navigera affärsrisk ett steg‑för‑steg‑exponeringsförlopp.

För att övervinna detta gap krävs också att man avskaffar en vanlig myt: idén att tekniskt ledarskap kräver absolut behärskning innan man tar steget framåt. I den snabba AI‑eran har ingen alla svar. De avgörande ledarskapsegenskaperna idag är nyfikenhet, kontinuerligt lärande och förtroendet att ta itu med komplexa problem innan resultatet är garanterat.

För att se fler kvinnor leda teknikföretag måste vi bredda tillgången till kommersiella nätverk, lyfta fram synliga förebilder och aktivt uppmuntra erfarna talanger att kliva ur funktionella silos, ta P&L‑ansvar och omfamna riskerna med affärsägande.

Framåt, vad tror du kommer att skilja de företags‑AI‑plattformar som blir djupt integrerade i affärsverksamheter från de många AI‑produkter som i slutändan har svårt att gå längre än experimentering?

Gränsen kommer att vara om de kan gå från intelligens till pålitlig exekvering.

Att generera ett imponerande svar blir redan relativt enkelt. Att fungera pålitligt inom ett stort företag är en annan historia.

De plattformar som blir integrerade i affärsverksamheter måste kunna ansluta säkert till befintliga system snarare än att be företag att ersätta allt de redan använder. De måste kunna fungera över olika modeller och teknologier.

De kommer att behöva orkestrering som kan samordna agenter, arbetsflöden och mänskliga beslut. Och de kommer att behöva identitet, styrning, observabilitet och kontroll inbyggda i arkitekturen snarare än tillagda i efterhand.

Men det finns ett annat krav som jag tror kommer att skilja experiment från infrastruktur i allt högre grad: pålitlighet under ofullständiga förhållanden. En demonstration visar vad ett AI‑system kan göra när allt fungerar, men ett företag vill veta vad som händer när något inte fungerar.

Vad händer när data är ofullständig? När ett API misslyckas? När två policyer står i konflikt? När förtroendet är lågt? När en användare begär något som de inte är auktoriserade att göra?

Om en agent presterar briljant 90 % av tiden men beter sig oförutsägbart de återstående 10 % kan du inte ge den ansvar för ett kritiskt affärsprocess.

Under de senaste åren har den dominerande frågan varit: ”Vad kan den här modellen göra?”

Företagsfrågan blir: ”Hur kan jag få detta arbete gjort effektivt?”

De AI‑plattformar som blir djupt integrerade i organisationer kommer att vara de som kan svara på den andra frågan övertygande: tekniskt, operativt och ekonomiskt. Det var i slutändan den möjlighet vi såg när vi startade Druid AI: att göra intelligens till en del av hur arbetet självt utförs.

Tack för det fantastiska intervjun, läsare som vill lära sig mer bör besöka Druid AI.