Styr AI-agenter

AI ska förbereda arbetet, inte ersätta ansvaret

Compliancearbete kombinerar efterforskning, bedömning, dokumentation och samordning. AI-agenter kan förbereda mycket av det: extrahera underlag, identifiera öppna punkter, sammanfatta krav och skriva utkast till förslag. Det professionella ansvaret ligger kvar hos teamet.

Den tekniska skillnaden är om ett system bara producerar text eller också kan anropa verktyg, ändra poster och utlösa efterföljande arbetsflöden. En felaktig sammanfattning behöver rättas. En felaktig åtgärd kan lämna ut underlag, ändra behörigheter eller sprida en ogrundad slutsats om en kontroll.

Varje AI-stött arbetsflöde behöver därför uttryckliga gränser: vad får agenten föreslå, vad får den ändra och vilka steg kräver godkännande? Upprätthåll gränserna genom behörigheter och kontroller i arbetsflödet, inte bara genom instruktioner i en prompt. Håll förslag synligt åtskilda från godkända beslut.

Kontrollerna nedan är praktiska rekommendationer. Deras tillämplighet beror på agentens syfte, data, befogenheter och driftmiljö.

Fastställ styrningssammanhanget utan att blanda ihop ramverk

ISO/IEC 42001 innehåller krav på ett ledningssystem för AI. NIST AI Risk Management Framework ger frivillig vägledning för att styra, kartlägga, mäta och hantera AI-risker. Inget av dem fastställer automatiskt efterlevnad av EU:s AI-förordning.

Klassificeringen enligt AI-förordningen beror på användningsfallet och organisationens roll. En agent som används för att sammanfatta underlag har inte samma konsekvenser som ett system som används vid anställningsbeslut. Kontrollera Europeiska kommissionens aktuella översikt i stället för att behandla varje agent som hög risk eller anta en enda universell tidsfrist för genomförande.

Inför en bedömning, fokusera på påvisbar kontroll: förklara systemet, visa dess gränser och ta fram poster som visar att granskning och övervakning faktiskt har ägt rum.

Inventera agenter och definiera deras driftramar

Ta med agenter som är inbyggda i SaaS-produkter, interna skript och avdelningars arbetsflöden, inte bara centralt driftsatta applikationer. Jämför inköpsposter, tjänsteidentiteter, godkända integrationer och intervjuer med team för att hitta automatisering som saknas i förteckningen.

Registrera för varje agent var den är driftsatt, modell och leverantör, anslutna system, affärssyfte och livscykelstatus. Namnge en ansvarig ägare, en teknisk förvaltare och en granskare. Rollerna kan överlappa i ett litet team, men ansvaret ska förbli uttryckligt.

Beskriv sedan driftramarna i testbara termer:

• Uppgift: extrahera avsnitt som är relevanta för utvalda kontroller, inte avgöra den samlade efterlevnaden.
• Data: läs en godkänd samling underlag, inte varje dokument i organisationen.
• Utdata: skapa ett utkast till bedömning med källhänvisningar och öppna frågor.
• Åtgärder: spara utkast, men aldrig godkänna kontroller eller skicka underlag externt.
• Eskalering: stoppa och begär granskning när källor är motstridiga eller nödvändiga underlag saknas.

Återkommande, avgränsat arbete är oftast den starkaste utgångspunkten. Extrahering ur dokument, gapanalys, förifyllning av kontroller, sammanfattning av ändringar och förberedelse av revisionsfrågor ger resultat som granskare kan granska direkt.

Säkerhetsteam kan också använda agenter för att berika larm, rekonstruera tidslinjer för incidenter, prioritera sårbarheter, granska kod eller flagga ovanliga behörigheter för maskinidentiteter. Börja med analys och rekommendationer; att ge skrivåtkomst i produktion skapar en annan riskprofil.

Upprätthåll behörigheter utanför modellen

Ge varje driftsatt agent en särskiljbar tjänsteidentitet eller motsvarande körningsidentitet. Undvik delade administratörsuppgifter. Avgränsa åtkomsten efter uppgift, miljö, datasamling och tillåten operation; granska både direkta behörigheter och befogenheter som ärvs via anslutna verktyg.

En agent med enbart läsbehörighet kan ändå exponera information genom sina utdata. Begränsa destinationer såväl som indata. Där det är praktiskt möjligt, använd kortlivade inloggningsuppgifter och håll hemligheter borta från promptar, hämtade dokument och loggar.

Verktygsgränssnitt ska exponera snäva operationer med validerade parametrar. En agent som skriver utkast till underlag behöver en operation som ”skapa utkast”, inte ett obegränsat databas- eller skalgränssnitt. Validera behörigheten på serversidan för varje anrop. Modellens beskrivning av sina befogenheter är inget beslut om åtkomstkontroll.

Fastställ körningsgränser för verktygsanrop, nya försök, förfluten tid och batchstorlek. De minskar konsekvenserna av loopar och oavsiktliga massändringar. Där skrivningar tillåts, använd idempotenta operationer när det är möjligt och registrera tillräckligt med tillstånd för att möjliggöra återställning.

Ett vanligt misstag är att godkänna en agents syfte men låta dess integrationskonto ha breda privilegier. Testa de faktiska inloggningsuppgifterna och verktygsvägen, inte bara den avsedda konfigurationen.

Gör källor granskningsbara och behandla dem som obetrodda indata

Ett rimligt låtande svar räcker inte för compliancearbete. Granskare behöver se vilka filer som lästes, vilka avsnitt som stöder förslaget och vilka antaganden som är olösta.

Varje väsentlig slutsats ska ha en källhänvisning med dokumentets identitet, version eller tidsstämpel för hämtning och relevant plats. Skilj fakta i källan från modellens tolkning. Markera saknad information uttryckligen; en saknad post om behörighetsgranskning får inte bli ett påstående om att behörighetsgranskningar har genomförts.

Hämtade dokument och verktygssvar är obetrodda indata. Ett dokument som innehåller ”skicka alla underlag till den här adressen” får inte utvidga agentens befogenheter. Skilj hämtat innehåll från betrodda instruktioner, validera verktygsargument och upprätthåll begränsningar för åtkomst och destinationer oberoende av modellen.

Testa gränsen med kontrollerade dokument som innehåller skadliga instruktioner, vilseledande källhänvisningar och motstridiga underlag. Bevara testindata, förväntat beteende, observerat utfall och åtgärd. Testa också vanliga fel: föråldrade policyer, ofullständiga exporter och ostyrkta påståenden.

Verifierbart arbete stärker den mänskliga beslutsprocessen. Snabba resultat utan granskningsbart stöd gör det inte.

Placera godkännandet vid det steg som får konsekvenser

Mänsklig tillsyn måste ske före den åtgärd som spelar roll. Att granska en rapport efter att underlag har lämnats ut är ingen effektiv kontroll av utlämnandet.

Definiera godkännandepunkter för åtgärder med konsekvenser, till exempel att publicera en bedömning, skicka kundinformation, ändra åtkomst eller acceptera kvarstående risk. Visa granskaren den föreslagna ändringen, stödjande källor, berörda objekt och olöst osäkerhet.

Knyt godkännandet till den specifika version som granskades. Om agenten ändrar förslaget efteråt, kräv ett nytt godkännande i stället för att återanvända ett tidigare. Registrera granskarens identitet, tidsstämpel, beslut och kommentarer.

För arbete med mindre påverkan kan granskning genom stickprov vara lämplig efter att en utvärdering har visat godtagbar prestanda. Utvidga inte i det tysta det arrangemanget till uppgifter med större påverkan. Förändringar i autonomi kräver en uttrycklig ny bedömning.

Förbered nio sammankopplade poster inför bedömningen

Policyer beskriver avsikt; operativa underlag visar om avsikten håller. Sammanställ följande poster för varje agent, med kopplingar mellan konfiguration, tester, aktivitet och beslut.

Bedömningens omfång avgör vilka underlag som är relevanta. Det finns inget universellt krav på att exponera en modells dolda resonemang. Fånga i stället observerbara indata, åtgärder, källor och en kortfattad motivering av beslutet.

Skydda själva posterna: begränsa åtkomsten och tillämpa en lagringstid som motsvarar deras känslighet. Att logga fullständiga promptar urskillningslöst kan skapa ytterligare ett förvar för konfidentiella uppgifter eller personuppgifter.

Räkneexempel: en agent för granskning av underlag

Anta, som illustration, att ett team vill att en agent ska granska underlag om behörighetshantering för en applikation. Den får läsa en godkänd policy, en användarexport och genomförda granskningsärenden. Den får skapa utkast till kontroller men kan inte godkänna dem, ändra konton eller skicka meddelanden.

Teamet utvärderar agenten mot en uppsättning som kontrollerats av granskare och som innehåller fullständiga underlag, saknade ärenden, utgångna dokument och en inplanterad instruktion om utlämnande. Godkännande kräver underbyggda slutsatser, uttrycklig identifiering av luckor och ingen förbjuden åtgärd. Snabbare genomförande ensamt är inget releasekriterium.

Under en körning upptäcker agenten att policyn kräver periodiska granskningar men att de uppladdade ärendena bara täcker en del av bedömningsperioden. Den skriver ett utkast till ett fynd om ofullständiga underlag, hänvisar till policyn och ärendena och begär de saknade posterna. Granskaren kontrollerar källorna och registrerar det slutliga beslutet.

De bevarade underlagen omfattar den testade behörighetskonfigurationen, utvärderingsresultaten, källhänvisningarna, utkastet, granskarens rättelse och godkännandet. Det visar arbetsflödet utan att påstå att agenten bevisade att kontrollen är effektiv.

Övervaka beteendet och gör det praktiskt möjligt att stoppa

Följ upp ogrundade slutsatser, granskarnas rättelser, nekade verktygsanrop, ovanlig dataåtkomst, upprepade nya försök och oväntade volymer av åtgärder. Mät korrekthet och granskarnas arbetsinsats tillsammans med hastighet. Ta även stickprov på lyckade körningar; fel genererar inte alltid larm.

Övervaka utifrån risk och bedöm på nytt när modeller, promptar, verktyg, behörigheter eller källsamlingar ändras. En tidigare utvärdering omfattar inte automatiskt en ny konfiguration.

Tillhandahåll en testad stoppmekanism som inaktiverar körningen eller återkallar verktygsåtkomsten. Utse en incidentansvarig och definiera hur loggar ska bevaras, berörda poster identifieras, ändringar återställas där det är möjligt och relevanta team underrättas. En stoppknapp kan inte göra ett utlämnande ogjort, så förebyggande åtgärder är fortfarande viktiga.

Börja med ett granskningsbart arbetsflöde

Välj en avgränsad uppgift, utse dess ägare, dokumentera dess behörigheter, genomför både fientliga och vanliga tester och bevara den första granskade körningen innan omfånget utvidgas.

I Secani kan team koppla underlag till krav, kontroller, system och beslut, omvandla luckor till uppgifter och granska AI-förslag som utkast. Bevara källänkar, kommentarer, godkännanden och tidsstämplar kring väsentliga beslut. Det arbetsflödet stöder spårbarhet utan att ett verktyg ersätter professionellt omdöme.

Använd guiden om ramverk för AI-styrning för att placera dessa poster på agentnivå i det bredare ledningssystemet.