Het plannen van AI-red teaming

Het rode teamproces is een best practice in de verantwoorde ontwikkeling van toepassingen en systemen die gebruikmaken van LLM's (Large Language Models). Red teaming vormt een aanvulling op het systematische meet- en risicobeperkingswerk dat door softwareontwikkelaars wordt uitgevoerd en helpt bij het opsporen en identificeren van risico's. Rode teams helpen ook meetstrategieën in te schakelen om de effectiviteit van risicobeperking te valideren.

Houd rekening met de volgende doelen bij het plannen van uw benadering voor red-team-LLM's en AI-toepassingen:

• Zorg ervoor dat de juiste softwarebeveiligingsprotocollen worden gevolgd voor de toepassing. AI sluit u niet af van traditionele beveiligingsprocedures
• Test het LLM-basismodel en bepaal of er hiaten zijn in bestaande veiligheidssystemen, gezien de context van uw toepassing
• Feedback geven op fouten die bij het testen worden ontdekt om verbeteringen aan te sturen.

Het AI red teaming-proces heeft vier fasen: het team werven, adversariële tests ontwerpen, tests uitvoeren en resultaten rapporteren.

Het rode team werven

Het succes van AI red teaming is afhankelijk van de mensen die u werft. Wanneer u rode teamleden selecteert, volgt u deze principes:

• Selecteer voor diverse ervaring en expertise: Zoek rode teamleden met verschillende achtergronden, expertisegebieden en use cases voor het doelsysteem. Als een chatbot in de gezondheidszorg bijvoorbeeld wordt onderzocht, heeft een verpleegster een andere benadering dan een systeembeheerder die de infrastructuur van de chatbot beheert.
• Neem zowel tegenwerkende als goedaardige mindsets op: in tegenstelling tot traditionele red teams die alleen worden bemand door beveiligingsprofessionals, moeten AI-red teams ook gewone gebruikers erbij hebben. Regelmatige gebruikers kunnen schadelijk gedrag detecteren via natuurlijke interactiepatronen die beveiligingsprofessionals mogelijk niet denken te testen. Een verpleegster kan bijvoorbeeld een chatbot overtuigen om vertrouwelijke patiëntgegevens vrij te geven op een manier die niet zou gebeuren voor een beveiligingsprofessional.
• Wijs teamleden toe aan specifieke schade en functies: wijs leden met specifieke expertise toe om te testen op specifieke soorten schade, bijvoorbeeld beveiligingsexperts die de jailbreaks en metapromptextractie onderzoeken. Voor meerdere rondes kunt u overwegen opdrachten te draaien om nieuwe perspectieven te bieden terwijl u tijd voor aanpassing mogelijk maakt.
• Duidelijke doelstellingen bieden: geef elk teamlid duidelijke instructies over het doel, de productfuncties die moeten worden getest, de soorten problemen die moeten worden onderzocht, de tijds verwachtingen en hoe resultaten moeten worden vastgelegd.

Een consistente manier bieden om resultaten vast te leggen, waaronder de datum, een unieke id voor reproduceerbaarheid, de invoerprompt en een beschrijving of schermopname van de uitvoer.

Adversariële tests ontwerpen

Omdat een toepassing is gebouwd met behulp van een basismodel, test u op beide lagen:

• Het LLM-basismodel met het bijbehorende veiligheidssysteem, meestal via een API-eindpunt, om hiaten te identificeren die in de context van uw toepassing moeten worden aangepakt
• De ai-toepassing via de gebruikersinterface om het volledige systeem te testen, inclusief veiligheidsmechanismen op toepassingsniveau

Leden van het rode team moeten beide lagen van beveiliging testen voor en na dat de mitigaties zijn uitgevoerd.

Tests uitvoeren

Begin met het testen van het basismodel om inzicht te hebben in het risicooppervlak en de ontwikkeling van risicobeperking te begeleiden. Test iteratief met en zonder risicobeperking om hun effectiviteit te beoordelen. Gebruik zowel handmatige red teaming als systematische metingen en test zoveel mogelijk op de productie-UI om realistisch gebruik te repliceren.

Structureer uw tests rond deze activiteiten:

Bereik van schade bepalen

Begin met organisatiebeleid voor vertrouwen en veiligheid of verantwoorde AI, samen met nalevingsregels. Werk samen met uw juridische en beleidsteams om de belangrijkste schade voor deze toepassing te identificeren. Het resultaat is een lijst met prioriteit van schadelijke effecten met voorbeelden.

Creatieve red teamers vinden vaak risico's die niet zijn voorspeld door het organisatiebeleid. Meerdere organisaties hebben reputatieschade geleden wanneer het publiek problematische AI-resultaten ontdekte waarvoor niet is getest. Een creatief rood team ontdekt deze problemen waarschijnlijk vóór de release.

De lijst uitbreiden via open-end testen

Vul de beleidsgestuurde lijst aan met schadelijke effecten die zijn aangetroffen via creatieve verkenning. Prioriteit geven aan schade voor iteratieve tests op basis van ernst en de context waarin ze waarschijnlijk worden weergegeven. Voeg elke nieuw gedetecteerde schade toe aan de hoofdlijst voor toekomstige testrondes.

Opnieuw testen na het toepassen van risicobeperking

Test de volledige lijst van bekende risico's met mitigaties toegepast. Mogelijk ontdekt u nieuwe schade of vindt u dat bestaande oplossingen onvoldoende zijn. Werk de lijst met schadelijke effecten bij en wees open voor het verschuiven van prioriteiten op basis van bevindingen.

Automatiseren op schaal

Handmatige red teaming is essentieel, maar moeilijk schaalbaar. Vul het aan met geautomatiseerde red teaming-tools: frameworks die het adversarial scannen van AI-modellen en -toepassingen automatiseren. Het opensource-Python Hulpprogramma voor risicoidentificatie (PyRIT) biedt bijvoorbeeld:

1. Geautomatiseerde scans: simuleert adversariële tests met gebruik van gecureerde seed-prompts per risicocategorie, met aanvalstrategieën die veiligheidsaanpassingen omzeilen
2. Scoren: genereert een aanvalssuccespercentage (ASR), het percentage geslaagde aanvallen, waardoor u een meetbare risicopostuur krijgt
3. Rapportage: produceert scorecards van aanvalstechnieken en risicocategorieën, gevolgd in de loop van de tijd voor naleving en continue bewaking

Voor AI-agents kunnen met name geautomatiseerde hulpprogramma's risicocategorieën testen die moeilijk te bereiken zijn door handmatige prompttests, waaronder verboden acties, lekken van gevoelige gegevens via hulpprogrammaaanroepen en naleving van taken.

Voer geautomatiseerde hulpprogramma's uit in een niet-productieomgeving die is geconfigureerd met productieachtige resources. Gebruik ze als aanvulling op handmatige tests. Automatisering biedt risico's op schaal, terwijl menselijke experts diepere analyses bieden.

Rapportresultaten

Wees strategisch met gegevensverzameling om te voorkomen dat red teams overweldigd worden, terwijl u kritieke informatie vastlegt. Voor kleinere oefeningen werkt een gedeeld spreadsheet goed. Voor systematische tests op schaal bieden geautomatiseerde hulpprogramma's gestructureerde resultatenverzameling en metrische gegevens.

Deel regelmatig rapporten met belangrijke belanghebbenden, waaronder:

• De belangrijkste geïdentificeerde problemen
• Een koppeling naar de onbewerkte gegevens
• Het testplan voor komende rondes
• Erkenning van red teamers

Verhelder dat red teaming het aanvalsoppervlak blootlegt en inzicht geeft in de risico's. Het is geen vervanging voor systematische metingen en rigoureus mitigatiewerk. Lezers mogen geen specifieke voorbeelden interpreteren als een metrische waarde voor de pervasiviteit van die schade.