Ciò che il percorso della richiesta può dimostrare
Il primo anno del Regolamento europeo sull'IA è stato conformità sulla carta. Dal 2 agosto 2026 si applicano i poteri di esecuzione della Commissione sull'IA per finalità generali, gli obblighi di trasparenza dell'articolo 50 e il regime sanzionatorio. Nessun componente infrastrutturale vi rende conformi — ma una parte sostanziale di ciò che ogni obbligo finisce per richiedere sono prove, e le prove vengono prodotte nel percorso della richiesta oppure ricostruite in seguito a caro prezzo.
È una mappa tecnica, scritta per il team di piattaforma che deve produrre gli artefatti: obbligo → l'artefatto che lo comprova → da dove proviene. La classificazione del rischio, la valutazione di conformità e la vostra posizione legale restano vostre e dei vostri legali.
Cosa cambia, con precisione
Entra in vigore
- I poteri sanzionatori della Commissione sui fornitori di GPAI.
- Gli obblighi di trasparenza dell'articolo 50.
- Il regime sanzionatorio.
Cosa invece no
Gli obblighi per i sistemi ad alto rischio dell'allegato III sono stati rinviati al 2 dicembre 2027 in base all'accordo provvisorio Digital Omnibus del 7 maggio 2026. Seguono un percorso separato, e chi vi dice che gli obblighi per l'alto rischio iniziano ad agosto sta lavorando su informazioni superate.
Le pratiche vietate si applicano dal 2 febbraio 2025 e le regole sui modelli GPAI dal 2 agosto 2025. Ciò che arriva ora è l'esigibilità e l'esposizione alle sanzioni.
Obbligo, artefatto, origine
Una tabella su cui il vostro team di piattaforma può lavorare direttamente. Gran parte è ciò che un percorso della richiesta governato registra comunque; il pacchetto di prove Enterprise lo collega poi alle disposizioni come provato, parziale o lacuna. Gli articoli 12, 14 e 26 vincolano i sistemi ad alto rischio, dalla data indicata sopra.
| Requisito di evidenza | Artefatto necessario | Prodotto da Wäg come |
|---|---|---|
| Registrazione automatica degli eventi (art. 12) | Ogni chiamata al provider e ogni rifiuto, in un record che rende visibile ogni manomissione | Registro delle prove (open source): concatenato con hash, con checkpoint firmati Ed25519; in modalità obbligatoria, nessuna prova, nessuna uscita |
| Conservazione dei log (art. 19, art. 26, par. 6) | Record conservati almeno sei mesi, e oltre il database se necessario | Log delle richieste 180 giorni e traffico del registro 365 giorni per impostazione predefinita; archivio write-once su S3, Azure o GCS (Enterprise) |
| Tracciabilità delle decisioni automatizzate | Quale modello ha servito una richiesta, e perché | x-waeg-routed-model su ogni risposta, x-waeg-route-reason quando ha scelto il routing intelligente; entrambi nel log delle richieste |
| La sorveglianza umana è dimostrabile | Evidenza che i controlli esistono e sono applicati, non consultivi | Verdetti di policy per richiesta, rifiuti di budget a blocco netto, allow-list dei modelli |
| Ignorare e arrestare (art. 14, par. 4, lett. d–e); sorveglianza affidata a persone (art. 26, par. 2) | Un responsabile e approvatori nominati per agente; una persona ha approvato l'azione rischiosa, o fermato l'agente | Approvazioni della policy sugli strumenti e arresti di emergenza, con chi e perché, nel registro delle prove |
| Prove sugli agenti verificabili da un auditor | Esecuzioni, approvazioni, arresti e registro su un periodo, in un unico file firmato | Pacchetti di prove degli agenti (Enterprise): firmati, verificati con waeg evidence verify, con un mapping.json per disposizione |
| Marcatura leggibile da macchina dei contenuti generati (art. 50, par. 2) | Marcature leggibili da un rilevatore, e quanta parte dell'output le portava | Enterprise: credenziali C2PA, watermark, impronte del testo, un endpoint di verifica. Ogni build registra la copertura delle marcature |
| Etichette del deployer (art. 50, par. 4) | Quali risposte sono generate o modificate dall'IA | x-waeg-ai-label su ogni risposta di contenuto, generata o modificata: un'indicazione; ciò che mostrate ai vostri utenti è una vostra decisione |
| Governance e minimizzazione dei dati | Evidenza che i dati sensibili sono stati controllati prima dell'uscita | Verdetti di scansione prima della chiamata, mid-stream e dopo la chiamata, con l'azione intrapresa |
| Controllo su provider e localizzazione | Dove è stata inviata ogni richiesta, e che è rimasta nelle giurisdizioni consentite | Residenza (applicazione o osservazione), giurisdizione per richiesta e nel registro, registro delle informazioni in CSV o JSON |
| Ricostruzione degli incidenti | Una ricostruzione di quanto accaduto, inclusi i cicli degli agenti | Esecuzioni e span degli agenti, voci del registro per chiamate a strumenti e approvazioni; righe MCP con server, strumento, latenza ed errore |
| Responsabilità e titolarità | Attribuzione dell'utilizzo a un'unità organizzativa e a una persona | Gerarchia organizzazione → team → utente → chiave con tag di riaddebito |
| Controllo delle modifiche alla configurazione dell'IA | Chi ha modificato quale policy o budget, e quando | Traccia di audit amministrativa (Enterprise); ogni revisione della configurazione viene anche registrata come hash nel registro delle prove |
| Revisione indipendente | Un auditor verifica le prove senza vedere i prompt | Ruolo org_auditor (Enterprise): sola lettura, verifica ed esporta il registro, nessun corpo di richiesta |
| Cancellazione senza perdere il record (GDPR) | I dati di una persona resi non collegabili, le prove ancora intatte | Chiavi di digest per persona distrutte; la catena resta verificabile e la cancellazione stessa viene registrata |
Gli export del registro e i pacchetti di prove si verificano offline con una chiave Ed25519 che fissate voi (waeg ledger verify, waeg evidence verify), e l'algoritmo richiede solo SHA-256 ed Ed25519, quindi un auditor non deve fidarsi del sistema che li ha scritti. La mappatura del pacchetto è una guida per chi valuta la conformità, non una valutazione della conformità né una consulenza legale.
La strumentazione applicativa non basta ad arrivarci
Il logging a livello applicativo produce evidenze per le applicazioni che lo hanno implementato. Ed è tutto qui il problema: i vostri obblighi si applicano all'uso dell'IA della vostra organizzazione, non al sottoinsieme che qualcuno si è ricordato di strumentare. Una control plane nel percorso della richiesta produce gli stessi record per ogni carico di lavoro dietro l'endpoint.
È anche l'unico livello che produce evidenze di applicazione anziché evidenze di osservazione. Un record che mostra come una richiesta sia stata rifiutata perché violava una policy è un artefatto sostanzialmente diverso da un record che mostra che è stata inviata.
Cosa Wäg non fa
Wäg è infrastruttura, non un programma di conformità. Non classifica la categoria di rischio dei vostri sistemi, non produce valutazioni di conformità, non tiene la documentazione tecnica, non registra i sistemi, non esegue valutazioni d'impatto sui diritti fondamentali e non stabilisce se siete fornitori o deployer. Produce evidenze e applica i controlli che definite voi. Tutto il resto è vostro, ed è in gran parte un esercizio legale e organizzativo più che tecnico.
Sette cose che vale la pena fare
- Inventariate quali applicazioni chiamano oggi quali provider — e annotate come lo sapete, perché è quella la parte che si deteriora.
- Stabilite un unico punto di ingresso per il traffico verso i modelli, così l'inventario resta veritiero senza manutenzione.
- Attribuite ogni richiesta a un'unità organizzativa e a una persona o identità di servizio.
- Registrate le decisioni di routing, non solo le richieste. "Quale modello ha servito questa richiesta" è un fatto distinto da "questa richiesta è avvenuta".
- Rendete i controlli sul trattamento dei dati applicati anziché consultivi, e registratene comunque i verdetti.
- Portate nel perimetro le chiamate agli strumenti da parte degli agenti — sono la maggiore lacuna di evidenze nella maggior parte delle installazioni.
- Impostate la conservazione di quei record in base ai vostri obblighi, non al budget dei log — per i log del deployer, almeno sei mesi.
Come la governance viene applicata nel percorso della richiesta
Un endpoint. Tutti i modelli. Controllo completo.
Gestitelo nella vostra infrastruttura
Tutto ciò che serve per gestire una control plane in produzione è sotto Apache-2.0 e lo resterà — routing, alta disponibilità, cache, failover, budget, policy, MCP, job e osservabilità. Self-hosted, senza account, senza chiamate verso l'esterno.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Non è un pull funzionante: le immagini non sono ancora pubbliche. I partner di progettazione ricevono i dettagli del registry in forma privata.
Avvia in 5 minutiContribuite come design partner
Wäg non è ancora disponibile pubblicamente. Lavoriamo con un piccolo gruppo di team che gestiscono IA multi-provider in produzione e prendono sul serio governance e sovranità, per irrobustire la control plane su carichi reali.
- Tutte le funzioni Enterprise incluse, senza costi di licenza
- Migrazione assistita — la facciamo insieme a voi, anche da LiteLLM
- Una linea diretta con gli ingegneri e un'influenza reale su ciò che arriva dopo