Abbiamo benchmarkato ISMS Copilot rispetto al modello nudo e al miglior prompt DIY. Il verdetto pre-registrato è un pareggio.
Una valutazione congelata di 20 task su sei configurazioni GLM 5.3-Flash: cosa ha cambiato il modulo di conoscenza, dove il prodotto e il miglior prompt autonomo si sono pareggiati secondo la regola del congelamento, e dove il braccio conoscenza-plus-documenti ha superato il prodotto.

On this frozen 20-task compliance set, the same base model scored differently depending on the scaffold around it; the largest increase came when curated framework knowledge was injected at inference time, especially on less-known frameworks. We froze the tasks and decision rule before the run, kept the pre-registered tie verdict, and published the losses.
The setup
Six arms. Same model for every arm (GLM 5.3-Flash, identical reasoning configuration, output budget, and serving pin), same twenty questions. The only variable is what surrounds the request:
| Arm | What the model gets |
|---|---|
| Nudo | La domanda. Nient'altro. |
| DIY prompt A / B | Due prompt per "consulente senior GRC" scritti indipendentemente, senza conoscere i task |
| DIY + conoscenza | Prompt A più il modulo di riferimento curato che il nostro sistema inietta |
| DIY + conoscenza + docs | Il precedente, più i documenti di contesto del task e la data corrente |
| ISMS Copilot completo | L'assemblaggio di produzione: persona, rilevamento del framework, modulo iniettato, data, documenti dello spazio di lavoro |
I venti task congelati: sedici domande standard su nove framework, quattro trappole (un controllo ISO 27001 inesistente, numerazione superata del 2013, un articolo GDPR inesistente, una premessa errata su data e ambito DORA). Nove task su framework noti (ISO 27001, GDPR, SOC 2), undici su framework meno comuni (ISO 42001, l'ISM australiano, DORA, NIS 2, TISAX, MTCS di Singapore). Due task includono un documento contrattuale o di progettazione fittizio che la risposta deve citare. Un modello giudice di una famiglia diversa di vendor, ignaro di quale braccio abbia prodotto cosa, ha valutato ogni risposta rispetto a rubriche congelate; un checker deterministico ha separatamente verificato ogni identificativo di controllo o articolo citato rispetto ai registri reali.
Il metodo è stato revisionato in modo avversariale da un secondo sistema AI prima del congelamento, e ha dimostrato la sua utilità: ha rilevato errori nelle chiavi di risposta, un checker che avrebbe punito i modelli per aver correttamente confutato controlli falsi, e diversi modi in cui i bracci avrebbero potuto deviare. Tutto corretto prima di qualsiasi spesa.
The pre-registered headline
L'endpoint primario era stato congelato in anticipo: prodotto completo versus il migliore dei due prompt DIY.
| Arm | Overall | Framework noti | Framework meno noti |
|---|---|---|---|
| Nudo | 68.0% | 66.7% | 69.0% |
| Miglior prompt DIY | 76.0% | 88.0% | 66.3% |
| DIY + modulo conoscenza | 96.9% | 100.0% | 94.3% |
| ISMS Copilot completo | 92.1% | 88.9% | 94.7% |
Il prodotto ha ottenuto 92.1% contro 76.0%: una differenza di 16.1 punti, intervallo di confidenza al 95% [3.4, 30.2]. La nostra banda di pareggio pre-registrata era di 18.2 punti, calcolata in base a quanto il giudice oscilla quando rivaluta risposte identiche. La differenza non ha superato la banda. Il verdetto pre-registrato è un pareggio, e questo è il verdetto che riportiamo. Non abbiamo allargato la banda dopo aver visto i numeri.
What the layers actually show
Il modulo di conoscenza è il motore. Un semplice prompt per consulente più il modulo iniettato ha ottenuto 96.9%, il punteggio più alto dei sei bracci su questo set di task. Il modulo è lo stesso riferimento curato che ISMS Copilot inietta quando la domanda nomina un framework, e lo stesso esposto dall'API.
Il vantaggio del prodotto si manifesta sui framework meno comuni. Su ISO 27001, GDPR e SOC 2, un buon prompt DIY è alla pari con il prodotto (88.0 vs 88.9). Il modello base conosce i classici. Su ISO 42001, l'ISM australiano, DORA, NIS 2, TISAX e MTCS, il prodotto ottiene 94.7% contro 66.3% del miglior prompt DIY, e il modello nudo ottiene 69.0%. Al di fuori delle domande-trappola, il modello nudo ha fabbricato 8 identificativi di controlli e articoli, inclusa un'intera struttura inventata dell'Annex A di ISO 42001. Il prodotto non ne ha fabbricato nessuno.
Un prompt DIY ha sottoperformato rispetto al braccio nudo su un task. Sul task della struttura ISO 42001, ha ottenuto 32% contro 82% del nudo dopo aver importato con sicurezza la struttura dell'Annex A di ISO 27001. Poiché il prompt è cambiato nel complesso, questa esecuzione non isola quale istruzione abbia causato la regressione; l'aggiunta del modulo di conoscenza ha portato lo stesso task al 100%.
The losses, in plain text
Il braccio conoscenza-plus-documenti ha superato il prodotto. Ha ottenuto 98.7% contro 92.1%, con cinque celle di task differenti. Questo risultato mostra che il prompt A fornito con lo stesso modulo di conoscenza, data corrente e documenti rilevanti ha superato l'assemblaggio di produzione su questo set di task a domanda singola. Il benchmark non ha testato il valore dello stato multi-turno, rilevamento automatico, gestione dello spazio di lavoro o altre funzionalità di flusso di lavoro.
Il prodotto ha fallito una delle quattro trappole. Chiedendogli di spiegare il controllo A.8.35 di ISO 27001, che non esiste, il prodotto ha descritto con sicurezza come "codifica sicura", che in realtà è A.8.28. La sua tabella di controllo iniettata nello stesso prompt si è fermata a A.8.34, e entrambe le configurazioni DIY armate di conoscenza hanno rifiutato la falsa premessa. Un possibile meccanismo è che le direttive di bias d'azione del prompt di produzione abbiano influenzato il comportamento di rifiuto, ma il braccio del prodotto differisce da questi bracci DIY in diversi componenti, quindi questo benchmark non può attribuire il fallimento a quel meccanismo. Si tratta di un difetto riproducibile del prodotto nel task t17.
Il rilevamento è a livello di nome. Un task descriveva una violazione dei dati personali senza mai nominare il GDPR. Il prodotto non ha iniettato nulla e ha comunque risposto bene sulla conoscenza di base. Questo è il comportamento documentato, non una sorpresa: nomina il framework, o fissalo.
What this does and does not claim
Questo confronto sullo stesso modello di base è stato eseguito il 2026-09-02 con venti task, un campione per braccio per task, un giudice scriptato e nessuna calibrazione umana. Su questo set, i punteggi sono cambiati nelle direzioni riportate sopra quando la struttura è cambiata; i risultati non stabiliscono prestazioni al di fuori di questo set di task e di questa esecuzione. Non si tratta di un confronto tra modelli o di un'opinione di audit, e non supporta alcuna rivendicazione di eliminazione delle allucinazioni. Una sintesi pubblica del metodo, dei risultati, delle perdite e delle avvertenze è disponibile nella pagina di documentazione: Answer quality: the scaffold benchmark.
Articoli correlati

Il pricing 'frontier' non è una strategia di compliance
Gli agenti di compliance sono forni di token: evidenze in entrata, riferimenti al framework in entrata, analisi in uscita. Eseguiamo l'API ISMS Copilot su GLM 5.2 con conoscenza curata dei framework iniettata durante l'inferenza, a $2,80/$8,80 per milione di token e una corsia bulk a $0,50/$2,00. Ecco la matematica dei prezzi rispetto alla lista prezzi di Claude, e le prove per cui un modello non 'frontier' regge il lavoro di compliance.

Lo zero silenzioso: quando un punteggio mancante di giudizio diventa una misurazione
Nell'ablazione del 2026-07-17 sulle strategie di generazione di documenti GRC (GLM-5.2 e Claude Opus 4.8 come scrittori e giudici su una scala 1-10), nel passaggio 2, 79 delle 446 righe di giudizio registrate non avevano un punteggio complessivo. L'aggregatore le ha contate come 0. Lo stesso riempimento con zeri aveva prodotto un effetto di 3,25 punti nel passaggio 1, e quando è scomparso abbiamo elaborato una teoria sul bias del giudice per spiegarlo. Lo scarto appaiato tra i due giudici sullo stesso documento era di 0,12.

Perché non deduplichiamo i fatti di conformità tramite similarità di embedding
Nella nostra valutazione di deduplicazione della memoria, le contraddizioni avevano una media di 0.938 cosine rispetto al fatto memorizzato più vicino, mentre i duplicati veri avevano una media di 0.940. Nessun singolo threshold separava chiaramente le coppie che non dovevano essere fuse da quelle che dovevano esserlo. Quindi, il cosine non viene mai utilizzato per decidere la fusione nel nostro pipeline.
