AI-agenter i virksomheden: hvor de virker, og hvor de ikke gør

AI-agenter kan løse opgaver i flere trin på egen hånd: læse en mail, slå op i jeres systemer, skrive et udkast og foreslå næste skridt. En agent er god til arbejde med mange små skridt og få faste regler. Den er dårlig til alt, der ikke må gå galt. Her er, hvor AI-agenter virker i en virksomhed, hvor de ikke gør, og hvordan I kommer sikkert i gang.

Det vigtigste først

• En agent er en sprogmodel, der planlægger og kalder værktøjer i flere trin. Ikke en chatbot og ikke en fast automatisering.
• Gode kandidater er processer med mange trin, få faste regler og plads til, at et menneske tjekker resultatet.
• Hvor reglerne er faste, eller fejl ikke kan rulles tilbage, er almindelig automatisering billigere og sikrere.
• Det store arbejde er data og integrationer til ERP og CRM, ikke selve modellen.
• Start med én proces, hvor agenten skriver udkast og et menneske godkender. Udvid først, når tallene holder.

Hvad en AI-agent er, og hvad den ikke er

En chatbot svarer på spørgsmål. En automatisering følger en fast opskrift: når A sker, gør B. En agent ligger imellem. Den får et mål, vælger selv, hvilke værktøjer den skal bruge, ser på resultatet og beslutter næste skridt.

Værktøjerne er helt almindelige: et opslag i kundedatabasen, en søgning i sager, et kald til lagerstatus, et udkast til en mail. Sprogmodellen styrer rækkefølgen. Jeres systemer leverer fakta og udfører handlingerne.

Har I læst om at tilføje AI til eksisterende software, er forskellen denne: der løser AI ét afgrænset trin. En agent binder flere trin sammen og vælger selv vejen. Det giver mere værdi, men også flere steder, hvor det kan gå galt.

Hvor AI-agenter passer

De bedste opgaver har tre ting til fælles. De består af flere trin. Reglerne er løse nok til, at et skøn er nødvendigt. Og et forkert resultat bliver opdaget, før det skader. Det er dem, vi starter med i AI-projekter. Fire typiske eksempler:

• Sagsbehandling og udkast. Agenten læser en henvendelse, finder kunden og tidligere sager, vurderer hastighed og skriver et svarudkast til medarbejderen.
• Ordrer fra mail. Kunder sender bestillinger som fri tekst eller PDF. Agenten finder varenumre, tjekker priser og lager og lægger en kladdeordre i ERP til godkendelse.
• Intern viden med opslag. En medarbejder spørger om en kunde eller en leverance. Agenten søger i dokumenter og slår op i CRM og ERP og samler svaret med kilder.
• IT- og servicedesk. Agenten sorterer sager, stiller de manglende spørgsmål, finder kendte løsninger og klarer de simple ting, fx at nulstille en adgang efter godkendelse.

Hvor en agent er det forkerte valg

En sprogmodel er ikke deterministisk. Samme input kan give to forskellige svar. Det er fint til et udkast, men ikke til en momsberegning.

Er reglerne faste og kendte, så skriv dem som kode. En almindelig integration eller automatisering er billigere at køre, hurtigere og lettere at teste. Det gælder fx bogføring efter faste konti, prisberegning og godkendelsesflows med klare grænser.

Det samme gælder handlinger, der ikke kan rulles tilbage: udbetalinger, sletning af data, ændringer i kontrakter. Dér kan en agent forberede beslutningen, men et menneske skal tage den. Ofte er svaret en blanding: fast kode til reglerne, en agent til skønnet.

Rettigheder: mindst mulig adgang

En agent må kun kunne det, opgaven kræver. Giv den sin egen bruger med egne rettigheder, ikke en administratorkonto eller en medarbejders login. Så kan I se, hvad agenten har gjort, og lukke for den igen.

• Læs før skriv. Start med læseadgang. Skriveadgang gives værktøj for værktøj, når I har set, hvordan agenten opfører sig.
• Godkendelse på handlinger. Alt, der ændrer data, sender noget ud eller flytter penge, går gennem et menneske, indtil I har tal for, at det kan undværes.
• Snævre værktøjer. Et værktøj, der hedder “opret kladdeordre”, er sikrere end et, der hedder “kør SQL”.
• Behandl input som data. En mail kan indeholde tekst, der prøver at give agenten nye ordrer. Den må aldrig give agenten flere rettigheder.

Data og integrationer er det egentlige arbejde

En agent er aldrig bedre end de værktøjer, den får. Skal den slå op i lager eller oprette en ordre, kræver det stabile API’er til jeres systemer. Mangler de, er det første projekt ofte API-udvikling, ikke AI.

Hos mange virksomheder ligger data i Business Central eller Dynamics CRM. Begge har API’er, men felter, rettigheder og forretningsregler skal kortlægges, før en agent får lov at bruge dem.

Husk også pris og tid. Hver opgave koster et antal modelkald, og en agent med mange trin kan tage sekunder eller minutter. Mål prisen pr. opgave og svartiden fra starten. Det er ofte dér, det afgøres, om en agent kan betale sig.

Test, logning og regler

Byg et testsæt, før I bygger agenten. Saml rigtige eksempler fra processen med det svar, en erfaren medarbejder ville give. Kør agenten mod dem ved hver ændring af prompt, model eller værktøjer. Uden testsæt ved I ikke, om en ændring gjorde det bedre eller værre.

Log hvert trin: hvad agenten fik, hvilke værktøjer den kaldte, hvad den fik tilbage, og hvad den foreslog. Uden loggen kan I ikke finde fejlen.

Persondata kræver det samme som altid efter GDPR: et formål, en databehandleraftale og styr på, hvor data behandles. Vælg en løsning, hvor data bliver i EU, hvis I behandler personoplysninger. EU’s AI-forordning stiller krav om gennemsigtighed, fx at folk ved, når de taler med en AI. Find ud af, hvilken risikokategori jeres brug falder i, før I går i drift.

Ofte stillede spørgsmål

Hvor I skal starte

Vælg én proces med mange trin og en klar ejer. Mål, hvordan den kører i dag. Byg agenten, så den kun skriver udkast og forslag, og lad en medarbejder godkende alt. Følg godkendelsesraten og fejlene. Giv agenten mere selvstændighed ét værktøj ad gangen, når tallene viser, at det holder. Vi hjælper fra procesvalg til drift som en del af vores AI-udvikling.

Har I en proces, der kunne passe til en agent? Skriv til os eller book et møde, så kigger vi på den sammen med jer.