AI-governance må ikke være en eftertanke

Abhishek Ranjan er CTO hos Apna og Blue Machines, hvor han er dybt involveret i at transformere både den menneskelige arbejdsstyrke og AI-arbejdsstyrken.

Vi satte os ned med ham for at tale om styring af AI-arbejdsgange. Her er, hvad han sagde.

Teknologi side om side med mennesker

Jeg hedder Abhishek Ranjan. Jeg er CTO hos Apna og Blue Machines. To meget forbundne, men samtidig forskellige verdener har formet min rejse frem til dette øjeblik med AI-transformation.

Hos Apna udvikler vi løsninger til den menneskelige arbejdsstyrke. Apna er en af Indiens hurtigst voksende enhjørningsvirksomheder med over 60 millioner brugere på platformen. På den skala følger vi Indiens arbejdsstyrke meget tæt. Vi ser millioner af mennesker, der leder efter bedre muligheder, arbejdsgivere, der forsøger at ansætte hurtigere, forskellige sprog, forskellige færdighedsniveauer samt varierende grader af digital adgang og selvtillid.

Hos Blue Machines udvikler vi løsninger til AI-arbejdsstyrken. Vi fokuserer på AI til virksomheders stemmekommunikation og registrerer millioner af minutter hver dag. Vi udvikler mere end blot bots, der besvarer spørgsmål. Vi udvikler AI-medarbejdere, der kan tale med kunder, forstå kontekst, modtage feedback, forbedre sig over tid og udføre reelle forretningsarbejdsgange.

Jeg har set teknologi hjælpe mennesker med at finde arbejde, udvikle sig og deltage i økonomien. Og nu ser jeg AI selv blive en ny slags arbejdsstyrke, der kan arbejde side om side med mennesker.

For mig handler dette øjeblik derfor ikke kun om at bruge AI til produktivitet eller skrive kode hurtigere. Det handler om at gentænke, hvordan virksomheder fungerer, og hvordan arbejdet i sig selv bliver udført.

Arkitekturen bag to meget forskellige virksomheder

Arkitekturen hos Apna er bygget som en stor markedspladsplatform. Vi har forbrugersystemer, arbejdsgiversystemer, dataplatforme, AI- og matchingsystemer, søgning, kommunikation, lag til bekæmpelse af svindel og opbygning af tillid samt nu også funktioner til AI-rekruttering og AI-forberedelse til jobsamtaler ovenpå. Implementeringsmodellen er cloud-first, yderst skalerbar og bygget til høj tilgængelighed, fordi millioner af brugere og tusindvis af virksomheder anvender platformen.

Ingeniørorganisationen har over 100 medarbejdere, der arbejder på tværs af produktudvikling, backend, frontend, mobil, data, AI, infrastruktur, sikkerhed og platformteams. Vi fokuserer ikke kun på at udvikle funktioner, men også på at bygge pålidelige systemer, der kan fungere i massiv skala.

Blue Machines er en anden type teknologiorganisation. Den fokuserer på AI til virksomheders stemmekommunikation og agentbaserede arbejdsgange. Vi udvikler AI-medarbejdere, der kan tale, ræsonnere, udføre handlinger, integrere med forretningssystemer og forbedre sig gennem feedback. I dag fungerer vi allerede i stor skala med millioner af AI-stemminutter registreret hver dag.

Blue Machines' arkitektur er mere realtidsbaseret og AI-orienteret. Den omfatter stemmeinfrastruktur, telefoni, tale-til-tekst, LLM-baseret ræsonnering, tekst-til-tale, orkestrering af arbejdsgange, integrationer, analyse, observerbarhed og evalueringssystemer. Produktkompleksiteten er høj, fordi AI til virksomheders stemmekommunikation skal fungere i produktion, i virkelige samtaler, med lav latenstid, høj nøjagtighed, sikkerhedsforanstaltninger til overholdelse af regler og tydelige forretningsresultater.

Hos Blue Machines byggede et kerneteam på fire ingeniører en distribueret platform til stemmeorkestrering på få uger. Vi har også et meget kompetent forskningsteam, der arbejder indgående med AI til stemmekommunikation, evaluering af agenter, ræsonnering, latenstid, flersprogede systemer og forbedring af agenter over tid. Denne forskningsmæssige dybde er vigtig, fordi AI til virksomheders stemmekommunikation ikke kan løses alene ved at sætte modeller sammen. Det kræver stærk produktudvikling, stærk systemudvikling og stærk anvendt AI-forskning.

Overordnet set befinder den teknologiorganisation, jeg leder, sig i krydsfeltet mellem platforme i stor skala og AI-orienterede systemer.

Sådan forbedrer velforvaltet AI softwarelivscyklussen

Det seneste år har AI ændret den måde, vi udvikler, tester og udgiver teknologi på.

Tidligere var vores udgivelsesproces mere traditionel. Ingeniører byggede funktioner, oprettede PR'er, gennemgik peer reviews, kørte testcases og sendte dem derefter gennem den sædvanlige implementeringspipeline. Det fungerede, men hastigheden afhang af menneskelige reviewcyklusser, manuel QA og teamets tillid til udgivelsen.

Efterhånden som AI-assisteret kodning blev en større del af udviklingen, tog vi det til os – og indså hurtigt, at forbedringer i hastigheden alene ikke var nok. AI kan hjælpe ingeniører med at skrive kode hurtigere, men medmindre styringen forbedres, kan det også skabe flere skjulte fejl, oversete kanttilfælde eller dårlige abstraktioner.

Derfor ændrede vi driftsmodellen.

1. Vi tilføjede et AI-assisteret PR-reviewlag. Hver PR blev kontrolleret for risikabel logik, manglende kanttilfælde, brud på API-kontrakter, sikkerhedsproblemer, migrationsrisici og utilstrækkelig testdækning før menneskelig gennemgang. Det reducerede de åbenlyse fejl, før reviewet fandt sted.
2. Vi styrkede CI-gates. En ændring kunne ikke fortsætte alene, fordi koden så fin ud. Den skulle bestå enhedstests, integrationstests, linting, sikkerhedstjek, API-kontrakttests og regressionssuiter for det berørte produktområde.
3. Vi opbyggede stærkere regressionspakker til kritiske arbejdsgange. Det omfattede for eksempel testcases for virkelige brugerscenarier, kanttilfælde, flersproget adfærd, fejlhåndtering og forretningsresultater.
4. Vi ændrede styringen af prompts. Mere om det om et øjeblik.
5. Vi gjorde canary-udgivelser obligatoriske for højrisikoområder. I stedet for at udgive til alle udgiver vi til en lille procentdel af trafikken, overvåger fejl, latenstid, konvertering, frafald, agentkvalitet og kundeimpact og fremmer derefter udgivelsen eller ruller den tilbage.
6. Vi tilføjede bedre observerbarhed. Når noget gik i stykker, ville vi vide præcis, hvilken kodeversion, promptversion, model, arbejdsgang eller afhængighed der var årsag til det.

Effekten har været meget tydelig. Vores udgivelseshastighed steg markant. Teams, der tidligere leverede større, samlede udgivelser, går nu over til mindre og hyppigere udgivelser. På nogle områder steg udgivelsesfrekvensen næsten 2x til 3x, fordi kontrollerne er mere automatiserede, og tilliden er større. Og det er sådan, et team på fire byggede en distribueret, kompleks platform på få uger.

Antallet af produktionsproblemer faldt også, fordi hver udgivelse er mindre, bedre testet og nemmere at rulle tilbage. Vi ser et betydeligt fald i produktionsfejl, især dér hvor automatiseret regressionstest og canary-udgivelser nu er obligatoriske. I dag ligger antallet af fejl næsten 40 % under det oprindelige udgangspunkt.

AI alene giver hastighed. AI med styring giver hastighed og kvalitet.

Hvorfor prompts skal behandles som kode

Abhishek deler

For AI-systemer begyndte vi også at behandle prompts som kode…Det har været en vigtig forbedring. Vi ved, hvilken prompt der var aktiv, hvad der blev ændret, hvad der blev forbedret, og om kundeudfaldet blev bedre.

For AI-systemer begyndte vi også at behandle prompts som kode.

Vi versionsstyrer, gennemgår, tester og fremmer nu prompts på tværs af miljøer og ruller dem ud i etaper. Prompts behandles ikke længere som små konfigurationsopdateringer. De gennemgår testsamtaler, kanttilfælde, flersprogede kontroller, latenstjek, compliancekontroller og kontroller af forretningsresultater.

Vi kan først udgive en ny prompt eller agentarbejdsgang til en lille procentdel af trafikken, observere resultaterne og derefter fremme den, hvis målingerne ser bedre ud.

Det har været en vigtig forbedring. Tidligere var det svært at vide, om en promptændring forbedrede agenten eller blot ændrede dens adfærd. Nu kan vi sammenligne versioner mere objektivt. Vi ved, hvilken prompt der var aktiv, hvad der blev ændret, hvad der blev forbedret, og om kundeudfaldet blev bedre.

Den større ændring er, at hele teknologisystemet blev mere automatiseret, mere målbart og bedre styret.

En agentisk udgivelsesarbejdsgang for softwareudvikling

Vi bruger en agentisk udgivelsesarbejdsgang for softwareudvikling, hvor mennesker er involveret på centrale tidspunkter.

Denne arbejdsgang fungerer ikke for alle udgivelser. Ved meget komplekse platformændringer, dybtgående arkitekturændringer eller følsomme systemer bruger vi stadig en mere traditionel, menneskestyret proces. Men for nogle produktområder, især arbejdsgange i hurtig udvikling, er den blevet standardmåden at bygge på.

Her er arbejdsgangen:

1. Processen starter, når et produktkrav eller et teknisk problem ankommer. En AI-planlægningsagent læser kravet, opdeler det i opgaver, identificerer afhængigheder, markerer risikoområder og foreslår en implementeringsplan. Ingeniøren gennemgår planen, korrigerer antagelser og beslutter den endelige fremgangsmåde.
2. Derefter genererer en kodningsagent kode, refaktorerer moduler, skriver standardkode og opretter enheds- og integrationstests. En review-agent kontrollerer PR'en for risikabel logik, manglende grænsetilfælde, sikkerhedsproblemer, brud på API-kontrakter og mangler i testdækningen.
3. Dernæst opretter en testagent regressionsscenarier og validerer grænsetilfælde. For AI-arbejdsgange kører den også promptevalueringer, samtaletests, flersprogede kontroller, latenstjek og kontroller af forretningsresultater.
4. Udgivelsesagenten anbefaler derefter, om ændringen er sikker til canary-udrulning, baseret på testresultater, påvirkningsområde, tidligere fejl og parathed med hensyn til observerbarhed. Mennesker godkender dog stadig kritiske udrulninger, især hvis ændringen påvirker omsætning, kundeoplevelse, sikkerhed eller kerneinfrastruktur.
5. Når ændringen er udgivet, holder overvågningsagenten øje med fejl, latenstid, konvertering, frafald, agentkvalitet og kundepåvirkning. Hvis noget ser forkert ud, anbefaler den en tilbageførsel, opretter en hændelse, opsummerer logfiler og udarbejder et første RCA-udkast.

Denne arbejdsgang er agentbaseret, men ikke blindt autonom. AI-agenter planlægger, koder, gennemgår, tester, udgiver, overvåger og opsummerer. Mennesker godkender, udfordrer, prioriterer og ejer den endelige beslutning.

Hvor Claude Code og Cursor udmærker sig

Mine foretrukne værktøjer er Claude Code og Cursor, afhængigt af arbejdsgangen.

Cursor udmærker sig, når ingeniører ønsker AI dybt integreret i deres IDE til daglig kodning, refaktorering, forståelse af kodebasen og hurtigere implementering.

Claude Code er ekstremt nyttig til mere agentbaserede opgaver: forståelse af større kodebaser, ændringer på tværs af flere filer, generering af tests, fejlrettelser og iteration på samme måde som en teknisk samarbejdspartner.

Hvorfor AI skaber løftestang, mens mennesker udøver dømmekraft

Vi er nu i høj grad afhængige af AI til alt, der forbedrer hastighed, dækning eller konsistens, men ikke til opgaver, der kræver dømmekraft, ansvarlighed eller langsigtede afvejninger.

AI hjælper os for eksempel nu med kodereview, generering af testtilfælde, regressionsdækning, dokumentation, fejlfinding, loganalyse og endda indledende hændelseshåndtering. Den kan hurtigt identificere risikable kodeforløb, manglende grænsetilfælde, mulige sikkerhedsproblemer eller mønstre i produktionsfejl. I AI-systemer hjælper den os også med at sammenligne promptversioner, evaluere samtaler og forstå, hvor en agent fejler.

Men de endelige beslutninger træffes af mennesker. Her er nogle få eksempler:

• Arkitekturvalg skal forblive menneskelige, fordi de indebærer afvejninger omkring skala, omkostninger, pålidelighed, teamets kompetencer og produktets langsigtede retning.
• En RCA fra ende til ende kan understøttes af AI, men mennesker skal stadig forbinde punkterne, validere hypotesen og beslutte løsningen.
• Prioritering af opgavekøen forbliver menneskelig, fordi det kræver kundekontekst, forretningsstrategi og dømmekraft til at afgøre, hvad der virkelig betyder noget.
• Sikkerhedsgennemgange bruger AI, men ekspertvurdering er nødvendig. AI kan markere problemer, men den kan også skabe falske positiver eller overse risici, der afhænger af forretningskonteksten. Mennesker bevarer ejerskabet, fordi risikoen og ansvaret er for stort.

Eksempler fra den virkelige verden på AI-fejl i teknisk dømmekraft

Her er et par eksempler på betydningen af menneskelig dømmekraft.

Det første tilfælde involverede latenstoppe på millisekundniveau i vores talepipeline. AI kommenterede korrekt på problemet og identificerede, at latenstid i én sti kunne blive et problem. Men den kode, den foreslog, var forkert. Den så ren ud, men ville have skabt en anden flaskehals under belastning. En menneskelig ingeniør trådte til, forstod kørselsadfærden og løste det korrekt.

Et andet eksempel opstod under fejlsøgning i produktionen. Flere efterfølgende systemer fejlede, og AI blev ved med at analysere disse systemer uafhængigt og foreslå optimeringer. Men vi vidste allerede, at det egentlige problem var en forudgående afhængighed, som fejlede først. AI forvekslede synlige fejl med den grundlæggende årsag.

Det er her, AI stadig har problemer. Den kan læse logfiler, opsummere sporingsdata, foreslå løsninger og gøre fejlsøgning hurtigere. Men i komplekse distribuerede systemer kan den overse kausalitet, timing og kontekst på systemniveau.

Hvorfor hold bliver mindre med større bredde

AI har ændret rekrutteringsprofilen mere end organisationsdiagrammet.

Tidligere rekrutterede vi efter smallere funktionel dybde: serverudvikling, klientudvikling, QA, DevOps, data osv. De kompetencer er stadig vigtige, men nu sætter jeg større pris på ingeniører, der kan arbejde på tværs af hele stakken, bruge AI i dybden og gå fra problem til produktion med langt mindre vejledning.

De bedste ingeniører skriver ikke bare kode længere. De designer arbejdsgange, bruger AI til implementering, genererer tests, gennemgår output, fejlsøger hurtigere og tænker over kvaliteten af udgivelser.

Derfor er barren for rekruttering flyttet mod ingeniører med stort ejerskab og god dømmekraft. Personer, der kan stille de rigtige spørgsmål, verificere AI-output, forstå systemer i dybden og selvstændigt levere.

Det har også reduceret behovet for store hold på nogle områder. Et mindre hold med stærk AI-udnyttelse kan nu udføre arbejde, som tidligere krævede langt flere personer.

Hvorfor AI gør det sværere at oplære nye ingeniører

Abhishek deler

Jeg mener ikke, at det er løsningen at forbyde AI eller tvinge folk til at kode, som om det var 2010. Det ville være forkert. Men jeg mener heller ikke, at vi fuldt ud har løst, hvordan man opbygger dyb ingeniørmæssig dømmekraft, når AI udfører så meget af det indledende arbejde. Indtil videre er mit bedste svar at gøre forståelsen synlig.

Hvordan oplærer vi nye ingeniører i AI-æraen? Jeg har endnu ikke et perfekt svar.

Da vi begyndte, hjalp IDE'er os. Derefter hjalp Google os. Så hjalp Stack Overflow os. Men i alle disse faser var man stadig nødt til at kæmpe sig gennem problemet. Man skulle forstå svaret, tilpasse det, fejlfinde det og lære, hvorfor det virkede.

Med AI og vibe-kodning kan vi springe denne kamp over. En ny ingeniør kan generere fungerende kode uden reelt at forstå systemet, afvejningerne eller fejlscenarierne. Det bekymrer mig.

Jeg mener ikke, at det er løsningen at forbyde AI eller tvinge folk til at kode, som om det var 2010. Det ville være forkert. Men jeg mener heller ikke, at vi fuldt ud har løst, hvordan man opbygger dyb ingeniørmæssig dømmekraft, når AI udfører så meget af det indledende arbejde.

Indtil videre er mit bedste svar at gøre forståelsen synlig. Ingeniører bør kunne forklare, hvorfor koden virker, hvor den kan fejle, hvilke tests der er vigtige, hvad der sker i stor skala, og hvordan de ville fejlfinde den i produktionen.

Sådan håndterer du tokenforbrug

Omkostninger har også været en udfordring ved AI.

Tokenforbrug virker harmløst i begyndelsen, men når AI først indgår i kodning, gennemgange, test, fejlsøgning og agentiske arbejdsgange, kan omkostningerne vokse meget hurtigt.

Derfor skal vi nu måle ROI efter arbejdsgang og bruge smartere orkestrering. Ikke alle opgaver kræver den dyreste model.

Fremtiden handler om at bruge den rigtige model til den rigtige opgave.

Hvorfor CTO'er skal handle hurtigt — med kontrol

Her er mit råd: Byg hurtigt. Eksperimentér hurtigt. Integrér AI i reelle arbejdsgange inden for ingeniørarbejde, produktudvikling, support, salg, drift og interne processer. Lad være med at lade, som om det ikke virker. Det virker, nogle gange overraskende godt.

Men bliv ikke blindt troende. AI er kraftfuld, men det er ikke magi. Du har brug for kontrol, styring, test, observerbarhed og tydeligt ejerskab. Ellers skaber du bare hurtigere kaos.

Den rigtige indstilling er hverken “AI vil erstatte alt” eller “AI er overvurderet”. Den rigtige indstilling er “hvordan bruger jeg dette til at gøre min organisation 10 gange mere kapabel?”

Følg med

Følg med hos Abhishek Ranjan på LinkedIn. Og se også hans Hacktivate-nyhedsbrev.

Flere ekspertinterviews kommer i CTO-klubben!