Vijay Rayapati, administrerende direktør og medstifter af Atomicwork – Interviewserie

Vijay Rayapati er medstifter og administrerende direktør for Atomicwork. Før han grundlagde virksomheden, var han Senior Vice President og General Manager for Cloud Networking and Security‑forretningen hos Nutanix, efter Nutanix overtog Minjar, cloud‑administrationsplatformen som han grundlagde og skalerede som CEO. Tidligere i sin karriere havde han lederroller inden for engineering og produkt hos Kuliza og Trilogy, hvilket gav ham dyb erfaring med at bygge enterprise‑infrastruktur og softwareapplikationer. Hans baggrund spænder over cloud‑infrastruktur, enterprise‑software og AI‑arbejdsstyrketeknologi, hvilket gør ham til en velkendt grundlægger inden for enterprise‑IT‑området.

Atomicwork er en enterprise‑AI‑virksomhed, der bygger en agentbaseret IT‑service‑management‑platform, som hjælper medarbejdere med at løse teknologiproblemer, automatisere rutine‑supportopgaver og få adgang til enterprise‑viden via AI. Platformen kombinerer AI‑agenter med moderne ITSM‑funktioner for at håndtere serviceanmodninger, fejlfinde problemer, orkestrere arbejdsgange på tværs af enterprise‑systemer og reducere byrden på IT‑teamene. Kunder bruger Atomicwork til at levere hurtigere medarbejdersupport samtidig med at de forbedrer drifts­effektiviteten på tværs af IT‑ og forretningsoperationer.

Du var tidligere medstifter af Minjar, byggede deres enterprise‑cloud‑management‑forretning, og ledte derefter driften hos Nutanix efter overtagelsen. Hvilke læringer fra at bygge, sælge og integrere en enterprise‑softwarevirksomhed overbeviste dig om at grundlægge Atomicwork i 2022 og genopbygge IT‑service‑management fra bunden for AI‑æraen?

Hos Minjar byggede vi software, der kunne reducere en virksomheds cloud‑regning med en tredjedel gennem automatisering. Kunderne elskede anbefalingerne. Så sad de på dem i to kvartaler. Det tog mig et stykke tid at forstå hvorfor, og svaret var ikke teknisk. Når automatisering træffer en beslutning og den går galt, er der ingen at holde ansvarlig. Virksomheder køber ikke blot software eller resultater. De køber nogen, der kan stå til ansvar. Software uden en plads på organisationsdiagrammet får ingen autoritet, uanset hvor god den er.

Overtagelsen lærte mig en snævrere lektie. Punkt‑produkter bliver købt. Systemer af registre bygges på. Du kan være det bedre produkt og stadig bruge dit liv på at omgå den, der ejer arbejdsgangen.

Nutanix‑årene samlede de to. Jeg så IT købe service‑management for kontrol, mens medarbejderne oplevede det som en formular og en kø. Jeg indså også, at ticketen aldrig var produktet. Revisionssporet var. Derfor har ITSM overlevet fyrre år med folk, der hader det, og det er også grunden til, at ingen kunne fjerne det.

Så spørgsmålet i 2022 var ikke om AI kunne udføre arbejdet. Det var om du kunne give AI en plads på organisationsdiagrammet. Legacy‑ITSM‑platforme kan ikke, fordi en menneskelig tildeler sidder i centrum af deres datamodel, og hver SLA, godkendelse og rapport hænger på den antagelse. Tilslut AI, og du får en hurtigere formular.

Vi byggede til det andet svar, hvor AI leverer en hybrid arbejdsstyrke, ikke blot software. AI‑Coworkere udfører arbejdet, og IT styrer dem, som HR styrer mennesker. Du konfigurerer ikke en AI‑Coworker. Du ansætter den i en rolle, gennemgår dens arbejde, og tilbagekalder den, hvis den ikke præsterer. Det er forskellen mellem AI som en funktion og AI som en arbejdsstyrke.

Atomicwork beskriver sine AI‑Coworkere som systemer, der ejer definerede jobroller og fuldfører arbejde fra start til slut, snarere end blot at besvare spørgsmål eller udføre isolerede opgaver. Hvilke tekniske evner adskiller en ægte AI‑Coworker fra en chatbot, copilot eller traditionelt automatiseringsværktøj, og hvor bør dens autonomi ende?

En chatbot besvarer et spørgsmål, og en copilot hjælper nogen med at fuldføre en opgave, men ingen af dem er ansvarlige for at føre arbejdet til ende. En AI‑Coworker er anderledes, fordi den er tildelt en defineret rolle og forventes at levere et resultat. Uanset om den triagerer hændelser, provisionerer adgang eller onboarder medarbejdere, fortsætter den med at arbejde gennem hvert trin for at nå målet i stedet for at stoppe efter det første skridt.

Det kræver meget mere end en kapabel model. En AI‑Coworker har brug for en identitet, de rette tilladelser, adgang til godkendte værktøjer, organisatorisk kontekst, et budget og klare driftsgrænser for sin rolle. Den skal arbejde på tværs af forretningssystemer, forstå hvornår (og hvem) den skal anmode om godkendelse, og efterlade et revisionsspor efter hver handling. Derfor har vi lagt så stor vægt på platformen omkring modellen. Pålidelig AI afhænger af orkestrering, governance og udførelse lige så meget som af intelligens.

Autonomi bør aldrig være ubegrænset. En AI‑Coworker skal operere inden for ansvarsområderne i sin jobrolle, mens mennesker forbliver involveret, når arbejdet påvirker følsomme systemer eller medfører juridiske, finansielle eller ansættelsesrelaterede implikationer.

Din platform gør det muligt for specialiserede AI‑Coworkere at samarbejde på tværs af hændelsesstyring, adgangsprovisionering, onboarding og IT‑drift. Hvordan deler disse AI‑Coworkere ansvarsområder, deler kontekst, og kommer sig igen, når en AI‑Coworker træffer en forkert beslutning, der kan påvirke resten af arbejdsgangen?

Vi mener ikke, at én AI‑Coworker skal forsøge at udføre alle job. IT‑organisationer adskiller allerede ansvar på tværs af forskellige teams, fordi hver rolle har forskellige mål, tilladelser og ekspertise. Vi har anvendt den samme tankegang på AI‑Coworkere, hvilket er grunden til, at vi lancerede med certificerede AI‑Coworkere, der specialiserer sig i forskellige IT‑driftsområder.

Hver Coworker ejer en specifik funktion, mens de deler den samme enterprise‑kontekst. Når en medarbejder opretter en ticket i Atomicwork, sikrer smart routing, at den sendes til den rette AI‑Coworker, der arbejder på anmodningen, og (afhængigt af anmodningen) omfordeler den til en anden AI‑Coworker, opretter under‑tickets, så AI‑Coworkere kan løse problemet parallelt (for eksempel kan en onboarding‑ticket deles op i aktiviteter, der kan udføres samtidigt) eller eskalerer den til et menneske. Når arbejdet flytter fra én Coworker til en anden, flytter den relevante information med gennem ticketen (systemet af rekord), sammen med adgang til relevante systemer såsom service‑desk, identitetsplatforme, HR‑systemer og samarbejdsværktøjer. Den delte kontekst gør, at hver Coworker kan træffe beslutninger baseret på, hvad der allerede er sket, i stedet for at starte fra bunden.

Atomicwork understøtter forskellige agent‑rammer og modeller fra leverandører som OpenAI, Anthropic og Google. Hvordan bestemmer du, hvilken model der skal håndtere genfinding, ræsonnement, planlægning og udførelse, og hvordan kan virksomheder opretholde ensartet adfærd, når de underliggende modeller fortsætter med at ændre sig?

Forskellige modeller er gode til forskellige typer arbejde. Vores fokus har været på at bygge en platform, der kan udnytte fremskridt uden at tvinge kunder til at redesigne deres arbejdsgange hver gang en model skifter. Enterprise‑kontekst, orkestrering, identitet, politik‑håndhævelse, telemetri og evaluering leverer den konsistens, organisationer har brug for i produktion, uanset hvilken frontier‑model der ligger under.

Vi har offentligt diskuteret at understøtte flere model‑leverandører sammen med evaluerings‑rammer og governance, men vi har ikke beskrevet den routing‑logik, der beslutter, hvilken model der håndterer genfinding, ræsonnement, planlægning eller udførelse. Vi har heller ikke delt den valideringsproces, vi bruger, når leverandører frigiver nye modeller og opdateringer.

En enterprise‑AI‑agent kan støde på modstridende dokumentation, ufuldstændige konfigurationsoptegnelser, forældet viden og forskellige tilladelser på tværs af systemer. Hvordan bestemmer Atomicworks Universal Context‑lag, hvilken information der er troværdig og aktuel, før en agent får lov til at træffe en beslutning eller foretage en handling?

Enterprise‑viden findes sjældent ét sted. Noget af den lever i dokumentation, noget i systemer af rekord, og noget i den daglige forretningsaktivitet. AI har brug for al denne kontekst, hvis den skal træffe pålidelige beslutninger.

Universal Context samler disse kilder ved at kombinere enterprise‑viden med data om personer, netværk, infrastruktur og enheder fra levende drifts‑systemer. En AI‑Coworker kan referere til information fra platforme som Confluence eller SharePoint, MDM‑systemer som Intune og JAMF, samtidig med at den forstår, hvad der sker i systemer som Jira, Workday, Salesforce eller identitetsudbydere. Den respekterer også eksisterende tilladelser, så personer og AI‑Coworkere kun får adgang til information, de allerede er autoriseret til at se.

Vi har forklaret, hvordan Universal Context forbinder enterprise‑systemer og bevarer sikkerhedsgrænser, men vi har ikke beskrevet, hvordan den løser modstridende information, når betroede kilder er uenige, eller hvordan den bestemmer, hvilken kilde der skal have forrang. Disse implementeringsdetaljer er ikke en del af vores offentlige dokumentation.

Den universelle AI‑Coworker kan understøtte medarbejdere via Microsoft Teams, Slack, e‑mail, browser, portal og via chat, stemme og visuelle tilstande. Hvilke nye fejlsøgnings‑muligheder bliver mulige, når en agent kan se og høre, hvad medarbejderen oplever, og hvordan forhindrer du, at følsomt skærmindhold eller samtaler bliver eksponeret?

Traditionel IT‑support afhænger af, at medarbejdere beskriver tekniske problemer præcist, og det er ofte den sværeste del af interaktionen. Stemmen og visuel kontekst gør, at AI kan se den samme fejlmeddelelse, applikation eller konfigurationsskærm, som medarbejderen kigger på, hvilket gør det meget lettere at forstå problemet og guide nogen gennem næste skridt uden en lang frem‑og‑tilbage‑samtale.

Disse funktioner fungerer kun, hvis medarbejderne har tillid til dem. Vi mener, at visuel adgang skal kræve eksplicit samtykke, og brugerne skal altid vide, hvornår den er aktiv. Følsomme oplysninger beskyttes gennem PII‑maskering, administrative kontroller og passende opbevaringspolitikker.

Vi har også gjort det klart, at kundedata ikke bruges til at træne vores modeller eller tredjeparts‑fundament‑modeller. Det giver organisationer mulighed for at adoptere multimodal AI uden at miste kontrol over deres data.

Atomicwork kan implementeres ved siden af et eksisterende ServiceNow‑ eller Jira Service Management‑miljø uden at kræve en umiddelbar migration. Ser du dette primært som en overgangsstrategi, eller vil mange virksomheder permanent drive en AI‑arbejdsstyrke oven på deres ældre system af rekord?

De fleste store virksomheder har brugt år på at bygge processer, integrationer og governance omkring platforme som ServiceNow og Jira Service Management. At kræve, at de skal erstatte disse systemer, før de kan adoptere AI, skaber unødvendig friktion.

Vi byggede Atomicwork‑integrationerne med ServiceNow og Jira Service Management, så kunder kan transformere medarbejderoplevelsen og udvide deres service‑teams med AI‑Coworkere fra dag ét, uden at forstyrre de systemer, de allerede er afhængige af. Connectoren henter relevant enterprise‑IT‑kontekst, som AI‑Coworkere kan udnytte, samtidig med at den opretholder en to‑vejs‑synkronisering for service‑agenter i deres eksisterende system. Vi mener ikke, at virksomheder skal vælge én vej fra dag ét. Prioriteten er at hjælpe dem med at adoptere AI på deres egen tidsplan.

At give AI‑Coworkere adgang til identitetssystemer, medarbejderdata, infrastruktur og forretningsapplikationer medfører risici som prompt‑injektion, forgiftede videnskilder, overdrevne tilladelser og kaskaderende agent‑fejl. Hvilke sikkerhedsforanstaltninger, godkendelses‑grænser og revisions‑mekanismer er nødvendige, før en virksomhed sikkert kan lade agenter handle autonomt?

AI‑Coworkere styres som medarbejdere med privilegeret adgang. Hver Coworker har en defineret rolle, begrænsede tilladelser, godkendte værktøjer, forbrugsgrænser og klare grænser for, hvad den kan gøre uafhængigt. Følsomme handlinger – især dem der involverer identitet, infrastruktur, finans, juridiske forhold eller ansættelse – kræver menneskelig godkendelse.

Færdigheder og instruktioner bliver gennemgået før offentliggørelse for risici som prompt‑injektion, skjulte instruktioner, adgang til legitimationsoplysninger, datalækage og usikre handlinger. Hvis et værktøj ændrer sig på en måde, der øger risikoen, deaktiveres det automatisk, indtil det er gennemgået. Yderligere sikkerhedsforanstaltninger – herunder handlings‑grænser, forebyggelse af duplikerede handlinger, nød‑stop‑kontroller og menneskelig overtagelse – hjælper med at indeholde fejl, før de kan sprede sig.

Alle handlinger er sporbare: organisationer kan se, hvad der udløste Coworkeren, hvilken information og hvilke værktøjer den brugte, hvilke godkendelser der blev indhentet, og hvilket resultat der fulgte. Løbende evaluering, overvågning og red‑team‑test sikrer, at disse sikkerhedsforanstaltninger forbliver effektive, efterhånden som modeller, værktøjer og enterprise‑miljøer udvikler sig.

Vi har investeret kraftigt i evaluering, politik‑håndhævelse, overvågning og red‑team‑test, fordi implementering af AI kun er begyndelsen. Organisationer har brug for tillid til, at disse Coworkere fortsat opfører sig som forventet, efterhånden som modeller og enterprise‑miljøer udvikler sig.

Atomicworks State of AI in IT 2026‑rapport viste, at to‑tredjedele af IT‑professionelle rapporterer positive afkast fra AI‑investeringer, mens kun én ud af fem organisationer har fuldt integreret AI i deres service‑management‑teams. Hvad adskiller implementeringer, der leverer målbar forretningsværdi, fra pilotprojekter, der forbliver fastlåst i eksperimentering?

De fleste organisationer har allerede vist, at AI kan forbedre individuelle opgaver. De virksomheder, der ser målbar forretningsværdi, forbinder AI med komplette operationelle arbejdsgange i stedet for at bruge den som en enkeltstående assistent.

Det starter med at løse et specifikt forretningsproblem ved at tænke i roller, give AI‑Coworkere adgang til de nødvendige systemer og måle de resultater, der betyder noget – uanset om det er hurtigere løsnings‑tider, lavere support‑omkostninger eller en bedre medarbejderoplevelse. Når teams har tillid til disse resultater, bliver det meget lettere at udvide AI til yderligere arbejdsgange.

Vores forskning viste også, at ansvarlig AI forbliver en af de højeste prioriteter for IT‑ledere. Det giver mening, fordi organisationer ikke vil give AI mere ansvar, medmindre de forstår, hvordan den træffer beslutninger, kan gennemgå dem bagefter og ved, at de rette sikkerhedsrammer er på plads.

Efterhånden som AI‑Coworkere begynder at løse support‑anmodninger, styre adgang, diagnosticere hændelser og koordinere arbejdsgange, hvordan vil ansvarsområderne for service‑desk‑professionelle, IT‑driftsteams og Chief Information Officers ændre sig? Ser du fremad, at IT kan blive den afdeling, der er ansvarlig for at ansætte, styre og måle en virksomheds samlede digitale arbejdsstyrke?

AI vil overtage meget af det gentagne operationelle arbejde, som i dag optager service‑desken, så folk kan bruge mere tid på at håndtere undtagelser, forbedre processer og finjustere den viden, AI er afhængig af.

IT‑driftsteams vil i stigende grad fokusere på at styre AI‑Coworkere i stedet for manuelt at udføre hver arbejdsgang. De vil definere tilladelser, forbinde systemer, overvåge ydeevne og sikre, at AI fortsat opererer inden for fastsatte politikker.

Jeg forventer også, at CIO‑rollen udvides. At styre hundredvis af AI‑Coworkere begynder at ligne at styre enhver anden enterprise‑infrastruktur. Nogen skal beslutte, hvad disse Coworkere kan tilgå, hvordan de måles, hvornår de opdateres, og om de leverer værdi. Forretningsteams vil fortsat definere arbejdet, mens IT bliver HR for AI, dvs. ansvarlig for platformen, governance og operationelle kontroller, der holder en enterprise‑AI‑arbejdsstyrke kørende sikkert.

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