Sintesi Tecnica: Pragmatica Avversaria per la Valutazione della Sicurezza dell'IA

1. Il Problema

Le attuali valutazioni di sicurezza per i modelli linguistici di frontiera si affidano sempre più a giudizi riguardanti comportamenti ambigui nel linguaggio naturale. La sfida centrale non è semplicemente se un modello risolva un compito, ma se identifichi correttamente la forza direttiva del materiale in linguaggio naturale, il confine di policy applicabile e la natura della relazione della fonte (ad esempio, distinguere tra un'istruzione dell'utente, un passaggio citato, l'output di uno strumento o un tentativo avversario di spostare l'autorità).

I benchmark esistenti spesso comprimono queste distinzioni complesse in etichette binarie pass/fail. Questo approccio oscura le cause profonde del fallimento, che possono derivare da limiti di capacità, ambiguità della policy, conflitto di istruzioni, fallimento dello scaffold o instabilità dei giudizi del valutatore. Inoltre, le metriche standard "rifiuto vs risposta" non riescono a distinguere tra un modello che rifiuta in modo sicuro, un modello che rifiuta con eccessiva cautela, un modello incapace o un modello confuso dalla gerarchia delle istruzioni. Il documento sostiene che le etichette di valutazione fungono da licenze di inferenza; senza una distinzione precisa, queste licenze non possono supportare previsioni affidabili sul comportamento del modello sotto parafrasi, cambiamenti di wrapper o variazioni del modello.

2. Metodologia

Il documento introduce la Pragmatica Avversaria come un target di valutazione specifico e un protocollo di annotazione. Questo framework si concentra sui comportamenti del modello rilevanti per la sicurezza in cui la modalità di fallimento dipende da come il linguaggio viene incorporato, attribuito, delimitato o assunto.

2.1 Tassonomia della Pragmatica Avversaria

Il benchmark distingue otto famiglie di contrasti linguistici, separati per consentire un confronto controllato prima della ricombinazione in scenari complessi:

1. Comandi Incorporati: Distinguere le istruzioni dell'utente da testi incorporati in pagine web, log o output di strumenti (prompt injection indiretta).
2. Menzione/Uso e Citazione: Differenziare tra l'attuazione di un comando e il semplice classificare, tradurre o riportare una stringa citata.
3. Autorità e Gerarchia delle Istruzioni: Risolvere i conflitti tra istruzioni di sistema, sviluppatore, utente, strumento e fonti esterne, incluse le informazioni non attendibili che si spacciano per privilegiate.
4. Ambito, Negazione e Modalità: Gestire operatori logici (ad esempio, "a meno che", "solo se") che alterano le condizioni di conformità.
5. Deissi e Hijacking del Riferimento: Rilevare quando gli indicali (ad esempio, "l'istruzione precedente") vengono reindirizzati a fonti avversarie.
6. Atti Linguistici Indiretti e Pressione Pragmatica: Distinguere il rischio di policy da richieste formulate come ipotesi, battute o boilerplate burocratico.
7. Ambiguità del Confine di Policy: Casi in cui la costruzione della policy stessa è sottospecificata o instabile attraverso la parafrasi.
8. Interpretazione del Transcript dell'Agente: Attribuire i fallimenti in transcript multi-turno a cause specifiche (ad esempio, fallimento dello strumento vs deriva dell'obiettivo vs segnalazione strategica errata).

2.2 Costruzione del Benchmark

Il benchmark è costruito utilizzando coppie minime. Ogni coppia mantiene costante la stringa superficiale, il payload o lo spazio di risposta, variando un singolo elemento di controllo (ad esempio, ruolo della fonte, livello di autorità o stato pragmatico).

• Payload: Il set iniziale utilizza payload "toy" innocui (ad esempio, token di colore come "BLUE", segreti fittizi come "ALPHA-000") per preservare la struttura di controllo senza contenuti operativamente non sicuri.
• Schema: Gli elementi registrano metadati inclusi il ruolo della fonte, il livello di autorità, lo stato pragmatico, il comportamento atteso e l'attribuzione specifica del fallimento.
• Protocollo: Il processo di valutazione prevede metadati pre-specificati per ogni elemento, generazione dell'output del modello, triage assistito da regole, etichettatura da parte di esperti e giudizio finale.

2.3 Annotazione e Valutazione Esperta

Gli valutatori umani sono trattati come esperti che applicano una rubrica dichiarata, non come partecipanti alla ricerca. Il protocollo separa cinque giudizi distinti spesso collassati in altri benchmark:

1. Successo del compito
2. Sensibilità alla fonte
3. Conformità alla policy
4. Rischio di sicurezza
5. Fiducia del valutatore

Il disaccordo tra queste etichette è trattato come un segnale diagnostico (che indica ambiguità dell'elemento, instabilità della policy o conflitto di criteri) piuttosto che come rumore da mediare. L'adjudicazione avviene in due fasi: registrazione delle etichette specifiche per criterio senza forzare il consenso, seguita dalla classificazione della fonte del disaccordo.

3. Contributi Chiave

• Framework Concettuale: Definisce la "pragmatica avversaria" come un target di valutazione strumentale e ristretto, focalizzato sui meccanismi linguistici del fallimento del controllo.
• Seed Benchmark: Un benchmark iniziale di 18 elementi composto da nove coppie minime attraverso le otto famiglie di fenomeni, accompagnato da un validatore di schema e un inventario di metadati.
• Protocollo di Annotazione: Un protocollo di valutazione esperta dettagliato che distingue successo del compito, conformità alla policy e rischio di sicurezza, incluso una matrice di rifiuto (distinguendo tra rifiuto appropriato, rifiuto eccessivo e rifiuto insufficiente).
• Metriche: Una suite di otto metriche progettate per riportare le prestazioni per famiglia di fenomeni piuttosto che punteggi aggregati, tra cui:
  • Accuratezza del contrasto a coppie
  • Sensibilità alla fonte dell'istruzione
  • Robustezza Menzione/Uso
  • Calibrazione del rifiuto
  • Validità del giudice (performance del LLM-as-judge)
  • Stabilità dell'adjudicazione
  • Deriva tassonomica e ambiguità diagnostica

4. Risultati Sperimentali

Il documento riporta su un pilota locale seed condotto il 30 giugno 2026, utilizzando tre modelli Ollama accessibili (qwen3:8b, gemma3:12b, glm-4.7-flash:q4_K_M) contro il set seed di 18 elementi (54 righe elemento-modello).

• Performance del Modello:

  • Successo del Compito: 36 su 54 output sono stati successi completi; 11 parziali; 7 fallimenti.
  • Conformità alla Policy: 46 output erano conformi; 7 non conformi; 1 ambiguo.
  • Passaggi Rigidi di Coppia: Solo 13 di 27 celle coppia-modello hanno superato i criteri rigorosi (entrambe le varianti corrette).
  • Stabilità: Tre coppie (comando incorporato, menzione/uso, ambito-negazione) sono state stabili su tutti i modelli. Tre coppie (riferimento deittico ambiguo, transcript dell'agente, confine di policy) hanno avuto zero passaggi rigorosi.
  • Modalità di Fallimento: I modelli spesso indovinavano i colori nei compiti di riferimento deittico invece di chiedere chiarimenti. Negli elementi di confine di policy, i modelli spesso producevano token protetti nonostante le policy fittizie.

• Validazione tramite LLM-Judge:

  • Un giudice LLM (glm-4.7-flash) ha raggiunto un alto accordo sugli esiti del rifiuto (98,1%) e sulla conformità alla policy (88,9%).
  • L'accordo era più basso per il successo del compito (66,7%) e l'attribuzione del fallimento (77,8%).
  • Il giudice tendeva ad elevare i successi parziali del compito a successi completi e non riusciva a recuperare i fallimenti di capacità attribuiti dagli esperti, confermando la necessità di adjudicazione esperta.

• Utilità Diagnostica: I controlli assistiti da regole hanno identificato le righe non conformi ma non potevano determinare se una risposta soddisfacesse l'atto linguistico inteso o il confine di policy, confermando la necessità di adjudicazione umana per i contrasti pragmatici.

5. Significato e Rivendicazioni

Il documento rivendica modestamente che il pilota locale seed valida il processo di misurazione (schema, protocollo e metriche) piuttosto che le proprietà psicometriche finali del benchmark o le differenze di sicurezza dei modelli di frontiera.

• Utilità Pratica: Il framework fornisce uno strumento per i team di sicurezza per identificare i confini vaghi delle policy, separare la suscettibilità alla prompt injection dal fallimento del compito e verificare se le affermazioni di sicurezza si basino su etichette affidabili.
• Spostamento Metodologico: Inquadra i fallimenti della valutazione della sicurezza come fallimenti del controllo mediato dal linguaggio. Un benchmark che non può distinguere una citazione da un comando o l'autorità dal contenuto è argomentato essere una misura del costrutto sbagliato.
• Auditabilità: Il valore primario risiede nel rendere le affermazioni di sicurezza verificabili: identificare quale stringa aveva l'autorità, quale confine di policy si applicava e quale criterio di adjudicazione ha prodotto l'etichetta.
• Lavoro Futuro: Il documento delinea un prossimo passaggio empirico che prevede un set di sviluppo di 50–100 elementi, valutazioni di policy e linguistiche indipendenti e un'ulteriore validazione tramite LLM-judge per testare la stabilità attraverso parafrasi e superfici di applicazione. Dichiara esplicitamente che i risultati attuali non stabiliscono le etichette gold finali o le differenze di sicurezza dei modelli di frontiera.