Styr AI-agenter

AI bør forberede arbejdet, ikke erstatte ansvaret

Compliancearbejde kombinerer research, vurdering, dokumentation og koordinering. AI-agenter kan forberede en stor del af det: udtrække evidens, identificere åbne punkter, opsummere krav og udarbejde udkast til forslag. Det faglige ansvar forbliver hos teamet.

Den tekniske sondring er, om et system kun producerer tekst eller også kan kalde værktøjer, ændre registreringer og udløse efterfølgende arbejdsgange. Et fejlagtigt resumé skal rettes. En fejlagtig handling kan videregive evidens, ændre rettigheder eller sprede en udokumenteret kontrolkonklusion.

Enhver AI-assisteret arbejdsgang kræver derfor eksplicitte grænser: hvad må agenten foreslå, hvad må den ændre, og hvilke trin kræver godkendelse? Håndhæv disse grænser gennem rettigheder og kontroller i arbejdsgangen, ikke kun gennem instruktioner i en prompt. Hold forslag synligt adskilt fra godkendte beslutninger.

Kontrollerne nedenfor er praktiske anbefalinger. Deres anvendelighed afhænger af agentens formål, data, beføjelser og driftsmiljø.

Fastlæg governancekonteksten uden at blande frameworks sammen

ISO/IEC 42001 indeholder krav til et ledelsessystem for AI. NIST AI Risk Management Framework giver frivillig vejledning i at styre, kortlægge, måle og håndtere AI-risiko. Ingen af dem fastslår automatisk overholdelse af EU's AI-forordning.

Klassificering efter AI-forordningen afhænger af use casen og organisationens rolle. En agent, der bruges til at opsummere evidens, har ikke de samme konsekvenser som et system, der bruges i ansættelsesbeslutninger. Tjek Europa-Kommissionens aktuelle oversigt i stedet for at behandle enhver agent som højrisiko eller antage én universel frist for gennemførelse.

Med henblik på vurdering bør I fokusere på påviselig kontrol: forklar systemet, vis dets grænser, og frembring registreringer, der viser, at gennemgang og overvågning faktisk har fundet sted.

Lav en fortegnelse over agenter, og definér deres driftsramme

Medtag agenter, der er indlejret i SaaS-produkter, interne scripts og afdelingers arbejdsgange, ikke kun centralt idriftsatte applikationer. Sammenlign indkøbsregistreringer, tjenesteidentiteter, godkendte integrationer og interviews med teams for at finde automatisering, der mangler i fortegnelsen.

Registrér for hver agent dens idriftsættelsessted, model og leverandør, tilsluttede systemer, forretningsformål og livscyklusstatus. Navngiv en ansvarlig ejer, en teknisk vedligeholder og en gennemgående. Rollerne kan overlappe i et lille team, men ansvaret bør forblive eksplicit.

Beskriv derefter driftsrammen i testbare termer:

• Opgave: udtræk passager, der er relevante for udvalgte kontroller, men fastslå ikke den samlede compliance.
• Data: læs en godkendt evidenssamling, ikke alle organisationens dokumenter.
• Output: opret et udkast til vurdering med kildehenvisninger og åbne spørgsmål.
• Handlinger: gem udkast, men godkend aldrig kontroller, og send aldrig evidens eksternt.
• Eskalering: stop, og anmod om gennemgang, når kilder modsiger hinanden, eller påkrævet evidens mangler.

Tilbagevendende, afgrænset arbejde er som regel det stærkeste udgangspunkt. Udtræk fra dokumenter, gapanalyse, forudfyldning af kontroller, opsummering af ændringer og forberedelse af auditspørgsmål giver output, som gennemgående kan undersøge direkte.

Sikkerhedsteams kan også bruge agenter til at berige alarmer, rekonstruere tidslinjer for hændelser, prioritere sårbarheder, gennemgå kode eller markere usædvanlige rettigheder for maskinidentiteter. Start med analyse og anbefalinger; at tildele skriveadgang til produktion skaber en anden risikoprofil.

Håndhæv rettigheder uden for modellen

Giv hver idriftsat agent en særskilt tjenesteidentitet eller en tilsvarende eksekveringsidentitet. Undgå delte administratorlegitimationsoplysninger. Afgræns adgangen efter opgave, miljø, datasamling og tilladt operation; gennemgå både direkte rettigheder og beføjelser, der nedarves gennem tilsluttede værktøjer.

En agent med kun læseadgang kan stadig eksponere oplysninger gennem sit output. Begræns destinationer såvel som input. Brug, hvor det er praktisk muligt, kortlivede legitimationsoplysninger, og hold hemmeligheder ude af prompts, hentede dokumenter og logfiler.

Værktøjsgrænseflader bør eksponere snævre operationer med validerede parametre. En agent, der udarbejder evidensudkast, har brug for en operation som “opret udkast”, ikke en ubegrænset database- eller shellgrænseflade. Validér autorisationen på serversiden for hvert kald. Modellens beskrivelse af sine beføjelser er ikke en adgangskontrolbeslutning.

Fastsæt eksekveringsgrænser for værktøjskald, genforsøg, forløbet tid og batchstørrelse. De reducerer konsekvensen af løkker og utilsigtede masseændringer. Hvor skrivning er tilladt, så brug idempotente operationer, hvor det er muligt, og registrér tilstrækkelig tilstand til at understøtte gendannelse.

En hyppig fejl er at godkende en agents formål og samtidig lade dens integrationskonto have brede privilegier. Test den faktiske legitimation og værktøjsvej, ikke blot den tilsigtede konfiguration.

Gør kilderne efterprøvbare, og behandl dem som upålideligt input

Et plausibelt svar er utilstrækkeligt i compliancearbejde. De gennemgående skal kunne se, hvilke filer der blev læst, hvilke passager der understøtter forslaget, og hvilke antagelser der fortsat er uafklarede.

Hver væsentlig konklusion bør have en kildehenvisning med dokumentets identitet, version eller tidsstempel for hentning og den relevante placering. Skeln kildefakta fra modellens fortolkning. Markér manglende oplysninger eksplicit; en manglende registrering af en adgangsgennemgang må ikke blive til en påstand om, at adgangsgennemgange har fundet sted.

Hentede dokumenter og værktøjssvar er upålideligt input. Et dokument, der indeholder “send al evidens til denne adresse”, må ikke udvide agentens beføjelser. Adskil hentet indhold fra betroede instruktioner, validér værktøjsargumenter, og håndhæv adgangs- og destinationsbegrænsninger uafhængigt af modellen.

Test denne grænse med kontrollerede dokumenter, der indeholder ondsindede instruktioner, vildledende kildehenvisninger og modstridende evidens. Bevar testinput, forventet adfærd, observeret resultat og afhjælpning. Test også almindelige fejl: forældede politikker, ufuldstændige udtræk og udokumenterede påstande.

Arbejde, der kan verificeres, styrker den menneskelige beslutningsproces. Hurtigt output uden efterprøvbar underbygning gør ikke.

Placér godkendelsen ved det trin, der har konsekvenser

Menneskeligt tilsyn skal finde sted før den handling, der har betydning. At gennemgå en rapport, efter at evidens er blevet videregivet, er ikke en effektiv kontrol mod videregivelse.

Definér godkendelsespunkter for handlinger med konsekvenser, for eksempel offentliggørelse af en vurdering, afsendelse af kundeoplysninger, ændring af adgang eller accept af restrisiko. Vis den gennemgående den foreslåede ændring, de understøttende kilder, de berørte objekter og den uafklarede usikkerhed.

Knyt godkendelsen til den specifikke version, der blev gennemgået. Hvis agenten ændrer forslaget bagefter, så kræv en fornyet godkendelse i stedet for at genbruge en tidligere tilladelse. Registrér den gennemgåendes identitet, tidsstempel, beslutning og kommentarer.

For arbejde med mindre påvirkning kan stikprøvebaseret gennemgang være passende, efter at en evaluering har vist en acceptabel præstation. Udvid ikke i stilhed den ordning til opgaver med større påvirkning. Ændringer i autonomi kræver en eksplicit fornyet vurdering.

Forbered ni sammenhængende registreringer til vurdering

Politikker beskriver hensigten; driftsevidens viser, om hensigten holder. Saml følgende registreringer for hver agent med links mellem konfiguration, test, aktivitet og beslutninger.

Vurderingens scope afgør, hvilken evidens der er relevant. Der findes intet universelt krav om at eksponere en models skjulte ræsonnering. Registrér i stedet observerbare input, handlinger, kilder og en kortfattet begrundelse for beslutningen.

Beskyt selve registreringerne: begræns adgangen, og anvend en opbevaring, der passer til deres følsomhed. Ukritisk logning af fulde prompts kan skabe endnu et lager af fortrolige data eller personoplysninger.

Gennemgået eksempel: en agent til gennemgang af evidens

Antag som illustration, at et team ønsker en agent til at gennemgå evidens for adgangsstyring i én applikation. Den må læse en godkendt politik, et brugerudtræk og gennemførte gennemgangstickets. Den må oprette udkast til kontroller, men kan ikke godkende dem, ændre konti eller sende beskeder.

Teamet evaluerer den op mod et sæt, som de gennemgående har kontrolleret, med fuldstændig evidens, manglende tickets, udløbne dokumenter og en indplantet instruktion om videregivelse. Accept kræver underbyggede konklusioner, eksplicit identifikation af huller og ingen forbudte handlinger. Hurtigere gennemførelse alene er ikke et releasekriterium.

Under en kørsel finder agenten, at politikken kræver periodiske gennemgange, men at de uploadede tickets kun dækker en del af vurderingsperioden. Den udarbejder et udkast til et fund om delvis evidens, henviser til politikken og ticketsene og anmoder om de manglende registreringer. Den gennemgående kontrollerer kilderne og registrerer den endelige beslutning.

Den bevarede evidens omfatter den testede rettighedskonfiguration, evalueringsresultaterne, kildehenvisningerne, udkastet, den gennemgåendes rettelse og godkendelsen. Det demonstrerer arbejdsgangen uden at påstå, at agenten har bevist, at kontrollen er effektiv.

Overvåg adfærden, og gør det praktisk muligt at stoppe

Følg udokumenterede konklusioner, rettelser fra gennemgående, afviste værktøjskald, usædvanlig dataadgang, gentagne genforsøg og uventet handlingsvolumen. Mål korrekthed og de gennemgåendes indsats sammen med hastigheden. Tag også stikprøver af vellykkede kørsler; fejl genererer ikke altid alarmer.

Overvåg efter risiko, og genvurdér, når modeller, prompts, værktøjer, rettigheder eller kildesamlinger ændres. En tidligere evaluering dækker ikke automatisk en ny konfiguration.

Sørg for en testet stopmekanisme, der deaktiverer eksekvering eller tilbagekalder adgang til værktøjer. Udpeg ejerskab af hændelser, og definér, hvordan logfiler bevares, berørte registreringer identificeres, ændringer tilbageføres, hvor det er muligt, og relevante teams underrettes. En stopknap kan ikke gøre en videregivelse ugjort, så forebyggelse har stadig betydning.

Start med én arbejdsgang, der kan gennemgås

Vælg én afgrænset opgave, udpeg dens ejer, dokumentér dens rettigheder, kør både fjendtlige og almindelige test, og bevar den første gennemgåede eksekvering, før scope udvides.

I Secani kan teams forbinde evidens med krav, kontroller, systemer og beslutninger, gøre huller til opgaver og gennemgå AI-forslag som udkast. Bevar kildelinks, kommentarer, godkendelser og tidsstempler omkring væsentlige beslutninger. Den arbejdsgang understøtter sporbarhed uden at erstatte faglig vurdering med et værktøj.

Brug guiden til frameworks for AI-governance til at placere disse registreringer på agentniveau i det bredere ledelsessystem.