Legacy-systemer automatiseret med AI-agent

AgentCore Browser Tool giver en AI-agent adgang til en rigtig, isoleret browserinstans i skyen, som agenten selv styrer. Agenten navigerer, udfylder felter, klikker og læser skærmindhold, akkurat som en medarbejder ville gøre det i det gamle ERP-system, den forældede sagsbehandlingsportal eller ordreregistreringen, ingen af dem tilgængelige via moderne API. Det betyder, at man ikke behøver at bygge en ny integration eller vente på, at leverandøren en dag åbner et API. Agenten "læser" grænsefladen visuelt og strukturelt, akkurat som et menneske ville, og handler ud fra det.

For virksomheder med tunge legacy-installationer, banker med core banking-systemer fra halvfemserne, forsyningsselskaber med SCADA-frontends, det offentlige med sagsbehandlingssystemer, der aldrig blev moderniseret, er det her praktisk relevant. Man slipper for det kostbare og risikable projekt at udskifte selve systemet, og kan i stedet lægge et automatiseringslag ovenpå.

Det centrale sikkerhedsprincip er, at hver agentsession kører i sin egen isolerede browserinstans, adskilt fra andre sessioner og fra virksomhedens øvrige infrastruktur. Sessionen får kun de rettigheder, den konkrete opgave kræver, og lukkes ned, når opgaven er færdig. Det minimerer angrebsfladen markant sammenlignet med at give en agent bredere, vedvarende adgang til et netværk.

Det er en vigtig detalje for virksomheder, der er nervøse for at give AI-agenter fri adgang til produktionssystemer. Isolationen betyder, at en fejlende eller kompromitteret agentsession ikke automatisk giver adgang til andre dele af infrastrukturen. Kombineret med finmasket rettighedsstyring kan man begrænse, hvad agenten reelt kan nå at gøre skade med, selv i et scenarie hvor noget går galt.

Hele processen logges, hver handling agenten udfører i browseren, hvert klik og hver indtastning, gemmes som et sporbart forløb. Det gør det muligt at gennemgå, hvad agenten faktisk gjorde, i modsætning til traditionel automatisering, hvor man ofte kun ser resultatet og ikke vejen dertil.

For brancher med compliance-krav, finans, sundhed, forsyning, er det afgørende. Man kan ikke bare stole blindt på en agent i et kritisk system. Arkitekturen lægger op til, at mennesker sætter grænserne for, hvad agenten må gøre autonomt, og hvor der kræves godkendelse, før en handling udføres. Det er ikke en sort boks, der arbejder i baggrunden, det er et system, hvor man kan gå tilbage og se præcis, hvad der skete, og hvorfor.

Den praktiske vej starter typisk med en enkelt, afgrænset arbejdsgang, for eksempel dataudtræk fra et gammelt system eller en simpel formularudfyldning, der ellers krævede manuel indtastning. Man tester agenten i det isolerede miljø, gennemgår audit-sporet og justerer rettigheder og grænser, før man skalerer til flere arbejdsgange.

Første gang jeg satte en agent til at røre et system, den ikke havde rørt før, gjorde jeg opgaven bevidst kedelig: hente ét felt fra én formular, intet andet, med adgang der blev lukket, i det øjeblik opgaven var færdig. Ikke fordi det var imponerende, men fordi det var det eneste, jeg kunne stå inde for at forlade uden opsyn. Den samme snævre grænse, én opgave, én afgrænset adgang, er det, jeg leder efter, når jeg læser AWS' arkitektur: om isolationen og rettighederne er skåret lige så stramt til, før man overhovedet taler om at skalere.

Det reelle skifte her er ikke, at AI kan "se" en skærm, det har været muligt i nogen tid. Det er, at AWS pakker isolation, rettighedsstyring og fuld sporbarhed sammen i en referencearkitektur, der gør det forsvarligt at sætte en agent til at arbejde i et produktionssystem, man aldrig ville turde åbne for ukontrolleret automatisering.

For virksomheder, der har skubbet en dyr systemudskiftning foran sig år efter år, fordi det gamle system "bare virker", giver det en ny mulighed: automatisere arbejdet omkring systemet, uden at skulle udskifte selve systemet. Det er ikke en løsning på alt, men det fjerner en reel barriere for dem, der sidder fast med et system, ingen tør røre.