# What we prove ```json {"@context":"https://schema.org","@type":"WebPage","name":"Cosa dimostriamo \u2014 Mnemom","description":"Le Alignment Card sono la specifica di intento. La proof chain \u00e8 il legame di esecuzione. Firmate Ed25519, hash-chained, agnostiche al modello \u2014 la risposta zone-neutral a \u00abdimostra cosa, esattamente?\u00bb.","url":"https://www.mnemom.ai/it/what-we-prove","inLanguage":"it-IT","dateModified":"2026-06-08","publisher":{"@type":"Organization","@id":"https://www.mnemom.ai#organization","name":"Mnemom","url":"https://www.mnemom.ai"}} ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://www.mnemom.ai/it"},{"@type":"ListItem","position":2,"name":"Dimostra cosa, esattamente?","item":"https://www.mnemom.ai/it/what-we-prove"}]} ``` Per i team regolamentati # Dimostra cosa, esattamente? I log di audit provano che un agente ha fatto qualcosa. Non basta quando un solo passo falso costa 10 M$ e un regolatore chiede evidenze. Mnemom lega ciò che l'agente era autorizzato a fare a ciò che ha realmente fatto — crittograficamente, attraverso ogni modello, a ogni chiamata. [Leggi la spec della card](https://docs.mnemom.ai/concepts/alignment-cards)[Vedi cosa filtriamo](/it/security) Specifica di intento ### Alignment Card Un'Alignment Card è un contratto firmato: l'ambito in cui un agente è autorizzato a operare, espresso abbastanza strutturalmente perché una macchina lo applichi e abbastanza chiaramente perché un CISO lo firmi. - Intento dichiarato Ciò che questo agente è autorizzato a fare, in linguaggio chiaro e in forma strutturata firmata. - Tool e scope permessi Superficie callable esatta. Nulla fuori dalla card è raggiungibile a runtime. - Confini dei dati Cosa l'agente può leggere, cosa non deve mai scrivere e quali zone sono off-limits. - Contratto di escalation Quando l'agente deve passare a un umano — e quali evidenze deve portare. - Obblighi di compliance Legami con gli articoli dell'EU AI Act, ruoli HIPAA, clausole di retention settoriali. - Budget di drift Quanto l'agente può deviare dal comportamento di baseline prima che l'AIP scatti. Legame di esecuzione ### La proof chain Ogni esecuzione produce una catena di evidenze firmate. Ogni anello attesta una parte distinta dell'esecuzione dell'agente, legata all'hash della card e fornita di prove di inclusione Merkle per la verifica da terzi. 1. 1 Hash della card L'intento dichiarato, impresso e firmato. 2. 2 Attestazione degli input Ogni messaggio, risultato di tool e documento recuperato che ha raggiunto l'agente. 3. 3 Trace di decisione Checkpoint di ragionamento, valutazioni di policy e verdetti front-door — sequenziati e firmati. 4. 4 Ledger delle chiamate a tool Ogni invocazione di tool, argomenti e risposta — legati allo scope permesso dalla card. 5. 5 Certificato di output La risposta finale dell'agente, filtrata da back-door, firmata Ed25519, legata all'albero Merkle dell'esecuzione. ## Card in ingresso. Prova in uscita. La card è la domanda che fa il regolatore. La prova è la risposta che il tuo agente ha già prodotto — firmata, datata, verificabile in modo indipendente. Passo 1 Hash della card Passo 2 Attestazione degli input Passo 3 Trace di decisione Passo 4 Ledger delle chiamate a tool Passo 5 Certificato di output Ogni anello firmato Ed25519 · legato all'albero Merkle con prove di inclusione · esportabile come evidenza per regolatori, auditor e underwriter. ## Quattro prove che i regolatori chiedono davvero. «L'abbiamo loggato» non è una prova. Queste sì. ### Dimostra che l'agente ha fatto ciò che la card dichiarava. Ogni risposta è legata crittograficamente all'hash della card. Se l'esecuzione diverge dall'intento, la prova non si verifica. ### Dimostra che nessun tool non autorizzato è stato chiamato. Ogni tentativo di chiamata a tool dell'agente è registrato rispetto allo scope dichiarato dell'Alignment Card. Le chiamate fuori scope producono una violazione di confine nella trace firmata. ### Dimostra che nessun dato regolamentato è fuoriuscito. Il filtraggio back-door valuta ogni output contro pattern PII/PHI/segreti; il verdetto è firmato accanto all'output. Un leak non redatto non può produrre un certificato valido. ### Dimostra che l'agente non è stato prompt-injected alla compliance. I verdetti front-door su ogni messaggio in ingresso fanno parte della trace di decisione. Un'injection che l'agente ha seguito è visibile nella catena; un'injection che l'agente ha bloccato lo è altrettanto. Posizione zone-neutral ## Perché i provider di modelli non possono dimostrarlo per te. La fiducia d'agente è un problema cross-provider. Un piano di fiducia costruito dentro un frontier lab è strutturalmente in conflitto — e strutturalmente incompleto. ### La fiducia deve attraversare i provider. Una Fortune 500 non gira su un solo modello. Claude, GPT, Gemini, Llama open-weights — tutti in produzione, spesso nello stesso workflow. Un piano di fiducia costruito da un singolo vendor di modelli è strutturalmente incapace di attestare gli altri. ### Gli incumbent non possono fare da arbitri. I provider di modelli hanno interessi in ogni verdetto. La verifica zone-neutral — lo stesso standard di evidenza applicato a ogni modello, da una parte che non ha un modello proprio — è l'unica posizione che un regolatore accrediterà. ### Le card sono portabili; i modelli no. Un'Alignment Card viaggia con l'agente tra provider, versione e runtime. La proof chain è valida sia che il modello sottostante venga sostituito domani, tra sei mesi, o mai. Enforcement runtime ## Mnemom AEGIS è il runtime che trasforma queste prove crittografiche in decisioni di enforcement. La proof chain produce evidenza firmata. AEGIS è lo strato di protezione che agisce su di essa — a quattro checkpoint, su ogni gateway della rete, con Managed Rules firmate che portano un obiettivo SLO di propagazione cross-tenant P95 sotto i 30 secondi. 1 ### AAP — Alignment Card Dichiara l'identità dell'agente, i limiti di autonomia e gli impegni di audit. Pubblica su /.well-known/alignment-card.json. 2 ### AIP — IntegrityCheckpoint Verifica il reasoning dell'agente in volo. Verdict: clear, review-needed o boundary-violation, con evidenza thinking-block hashata SHA-256. 3 ### CLPI — Governance + ricevuta Governa il ciclo di vita della card su cinque fasi e ancora i Trust Ratings su Base L2 per verifica indipendente. 4 ### Mnemom AEGIS — Catena di valutazione Filtra ogni transazione a quattro checkpoint × quattro mode; firma le Managed Rules cross-tenant che agiscono sull'immagine integrata. Il runtime, la rete e la ricevuta. Costruzione onesta: AAP lo dichiara. AIP lo verifica in volo. CLPI governa il suo ciclo di vita e ancora le prove on-chain. AEGIS firma le difese cross-tenant che agiscono su di esso. [Vedere il learning network](/it/learning-network) ## La card è il contratto. La catena è la ricevuta. Cabla i tuoi agenti a Mnemom. Passa una card firmata. Ricevi una risposta verificabile ogni volta che agiscono. [Parti dal tier d'ingresso](/it/pricing)[Quickstart](https://docs.mnemom.ai/quickstart)[Vedi il flywheel](/it/learning-network) --- _Source: /it/what-we-prove/index.html · Generated by build-markdown-mirrors.mjs · For agent-readability commitment #4 see https://www.mnemom.ai/for-agents_