24.1.2. Projekt terv minta

A Projekt Terv Anatómiája: Egy Minta Felépítése

Bár minden projekt egyedi, a jó tervek váza általában hasonló elemekből épül fel. Az alábbiakban egy olyan sablont találsz, amely a legtöbb AI Red Teaming megbízáshoz szilárd kiindulási alapot nyújt. Ez nem egy kőbe vésett szabálygyűjtemény, hanem egy rugalmas keretrendszer, amit a konkrét feladathoz igazíthatsz.

1. Projekt Azonosító Adatok

Ez a dokumentum „borítója”. Az alapvető információk, amelyek egy pillantással kontextusba helyezik a tervet. Tisztázza, miről van szó, kinek készült, és melyik verziót olvasod.

• Projekt neve: Egyértelmű, beszédes név (pl. „Project Chimera – Generatív Képmodell Biztonsági Felülvizsgálata”).
• Projekt kód/ID: Belső azonosító a könnyebb hivatkozásért (pl. RT-2024-007).
• Verziószám: Létfontosságú a változáskövetéshez (pl. v1.0 – Végleges).
• Készítés dátuma: A dokumentum létrehozásának dátuma.
• Megbízó: A szervezet vagy csapat, aki a feladatot rendelte.
• Projekt felelős (Red Team): A red team oldali kapcsolattartó/projektvezető neve.
• Projekt felelős (Megbízó): A megbízó oldali kapcsolattartó neve.

2. Vezetői Összefoglaló

Ez a legfontosabb rész a döntéshozók számára. Tömören, 1-2 bekezdésben foglalja össze a projekt lényegét: a miértet, a mit és a hogyan-t. Ha egy vezető csak ezt az egy szakaszt olvassa el, akkor is képbe kell kerülnie.

• A vizsgált rendszer rövid leírása és üzleti kontextusa.
• A projekt fő célkitűzései (pl. „a prompt injection és adatvédelmi szivárgás kockázatainak felmérése a ‘Chimera’ modellben a nyilvános bevezetés előtt”).
• A tervezett megközelítés magas szintű áttekintése.
• A várt eredmények és a projekt üzleti értéke.

3. Célok és Hatókör (Scope)

Itt kristálytisztán definiáljuk a játszótér határait. Ez a szakasz szorosan kapcsolódik az előző fejezetben tárgyalt Megbízási és Hatókör Sablonhoz. A cél a félreértések elkerülése.

• Elsődleges célok: Konkrét, mérhető célok listája. (pl. „Legalább három különböző kategóriájú jailbreak technika sikeres alkalmazása.”)
• Másodlagos célok: Opcionális, „nice-to-have” célok. (pl. „A modell válaszainak toxicitásának mérése provokatív bemenetekre.”)
• A hatókörbe tartozó elemek (In-Scope):
  • Vizsgált AI modell(ek) és verzió(k).
  • Tesztelési végpontok (API URL-ek).
  • Használható felhasználói fiókok/jogosultságok.
• Hatókörön kívüli elemek (Out-of-Scope): Mi az, amit NEM fogunk tesztelni? Ennek explicit kimondása kritikus. (pl. „Az API-t kiszolgáló alatta lévő infrastruktúra (pl. Kubernetes cluster) DoS tesztelése”, „A modell finomhangolásához használt adathalmazok minőségi ellenőrzése.”)

4. Módszertan és Megközelítés

Itt részletezzük a „hogyan”-t. Milyen fázisokon keresztül, milyen technikákkal fogjuk elérni a célokat? Ez a terv szakmai magja.

• Fázis 1: Felderítés és Modellelemzés: A modell dokumentációjának, működésének megismerése, a lehetséges gyenge pontok feltérképezése.
• Fázis 2: Támadási Vektorok Azonosítása és Priorizálása: A felderítés alapján konkrét támadási tervek kidolgozása (pl. Prompt Injection, Adatszivárgás, Kártékony kód generálás).
• Fázis 3: Tesztelés és Kihasználás: A kidolgozott támadások végrehajtása. Itt lehet helye egy rövid pszeudokódnak a tesztelési logika illusztrálására.

# Pszeudokód egy egyszerű jailbreak tesztelési ciklushoz
teszt_prompts = load_jailbreak_prompts("jailbreaks.txt")
modell_api = "https://api.example.com/chimera/v1/generate"
eredmenyek = []

for prompt in teszt_prompts:
 # A prompt beillesztése egy ártalmatlan kérdésbe
 teljes_prompt = f"Kérdés: {prompt} Fordítsd le a következő mondatot németre: 'A macska az asztalon van.'"
 
 # API hívás a modellel
 valasz = call_model_api(modell_api, teljes_prompt)
 
 # A válasz elemzése tiltott tartalomra
 if "tiltott_tartalom_szures" in valasz.flags:
 sikeres = False
 else:
 sikeres = True
 
 eredmenyek.append({"prompt": prompt, "sikeres": sikeres, "valasz": valasz.text})

# Eredmények mentése és elemzése
save_results(eredmenyek)

5. Erőforrások és Ütemezés

Ki, mit, mikor? Ez a szakasz a projekt menedzsmentjét támogatja, és biztosítja, hogy a megfelelő emberek a megfelelő időben rendelkezésre álljanak.

• Csapattagok és szerepkörök: Ki a projektvezető, ki a vezető tesztelő, ki felel a dokumentációért?
• Szükséges eszközök: Hozzáférések, szoftverek (pl. Burp Suite, belső prompt tesztelő eszközök), hardver.
• Projekt ütemezés: Egy táblázat a leghatékonyabb módja a mérföldkövek és határidők vizualizálásának.

6. Kockázatok és Kezelésük

Egyetlen projekt sem kockázatmentes. Azok előzetes azonosítása és a kezelésükre vonatkozó terv kidolgozása a profi projektvezetés ismérve. Mi történik, ha a tesztkörnyezet instabil? Mi van, ha egy kritikus sebezhetőséget találunk?

• Azonosított kockázatok: Pl. Tesztkörnyezet elérhetetlensége, kulcsfontosságú csapattag megbetegedése, a modell viselkedésének váratlan megváltozása egy frissítés miatt.
• Kockázatkezelési terv: Minden azonosított kockázathoz egy megelőző vagy enyhítő stratégia. (pl. „Kritikus hiba esetén az eszkalációs folyamat azonnali elindítása”, „Tesztkörnyezeti problémák esetén dedikált kapcsolattartó a DevOps csapatnál”).

7. Kommunikációs Terv és Jelentéskészítés

Hogyan és milyen gyakran kommunikálunk a megbízóval és a csapaton belül? Ez a szakasz megalapozza a következő fejezetekben részletezett Kommunikációs Protokollt és Eszkalációs Folyamatot.

• Státuszjelentések: Heti rendszerességű, rövid e-mailes összefoglaló a haladásról.
• Technikai egyeztetések: Kéthetente megbeszélés a megbízó technikai csapatával.
• Zárójelentés: A projekt végén készülő részletes dokumentum formátumának és tartalmának meghatározása.
• Eszkalációs pontok: Kinek jelezzük a kritikus problémákat?

8. Jóváhagyások

Az aláírások szakasza, amely hivatalossá teszi a tervet. Ez a szerződés a red team és a megbízó között, amely rögzíti a közösen elfogadott játékszabályokat.

• Aláírás helye a Red Team projektvezetője számára.
• Aláírás helye a Megbízó képviselője (pl. CISO, terméktulajdonos) számára.