Gli agenti AI scrivono già codice di produzione nella vostra organizzazione. Quello che non sanno fare è dimostrare il proprio lavoro — a voi, a un auditor, a un regolatore. Questo plugin rende la delivery assistita dall'AI verificabile, l'evidenza di conformità UE automatica e la vostra policy di ingegneria applicata — con ogni affermazione sostenuta da prove, a partire da questa pagina.
Gli obblighi di segnalazione CRA (art. 14) si applicano dall'11 settembre 2026.
Ognuna è silenziosa finché non diventa costosa. Un incidente di produzione ricondotto a output AI mai verificato, una richiesta di informazioni del regolatore, un rilievo di audit — quando una di queste emerge, l'evidenza che serve o esiste già, o non esiste.
Un agente dichiarerà il lavoro finito e i test superati — in buona fede, e a volte a torto. Moltiplicatelo per ogni sviluppatore, ogni giorno. Senza un passaggio di verifica imposto, «fatto» significa «l'agente ci crede», ed è quella convinzione che finisce in produzione.
Come si assicura la delivery →Gli obblighi CRA di segnalazione delle vulnerabilità partono l'11 settembre 2026 per chiunque immetta software nel mercato UE, con sanzioni fino a 15 milioni di euro o al 2,5% del fatturato mondiale. Il GDPR è già in vigore. L'AI Act sta entrando in applicazione. L'evidenza che questi regimi esigono è tediosa da produrre a mano — e quindi non viene prodotta, finché non è improvvisamente urgente.
L'orologio regolatorio →Ogni modifica esce con un test. Le migrazioni sono reversibili. Gli endpoint autorizzano. I vostri team le hanno concordate — e vengono controllate, quando va bene, da chi revisiona la pull request e per caso se ne ricorda. Non falliscono rumorosamente; si erodono.
Come si applicano le policy →Cinque regimi UE toccano ormai direttamente il software. Le date qui sotto sono fissate dalla legge; l'unica variabile è se l'evidenza esiste il giorno in cui qualcuno la chiede.
Il GDPR non ha più nessuna data da aspettare. gdpr-evidence registra quali dati personali un repository detiene davvero e la base giuridica di ciascuno — e poi fa fallire una build quando arriva una nuova colonna di dati personali che ne è priva.
Rispondete come stanno le cose oggi, non come dovrebbero stare. Nulla lascia questa pagina: niente form, niente tracciamento — il conteggio avviene nel vostro browser. E siamo onesti in anticipo: otto risposte non sono un audit, sono il motivo per farne uno.
Questa è la forma reale dell'output di /compliance-status, su un repository d'esempio. Tre soli esiti possibili — presente, lacuna, non applicabile — ognuno con un puntatore o una ragione. «Sembra a posto» non è un esito che questo strumento produce, e ogni lacuna arriva già instradata verso la skill che la chiude.
Il rapporto porta sempre le due date che rendono tutto questo urgente anziché teorico: gli obblighi di segnalazione dell'art. 14 CRA si applicano dall'11 settembre 2026, la piena applicazione del CRA arriva l'11 dicembre 2027.
Installato una volta dal vostro platform team, attivo in ogni repository. Ogni track risponde a una delle tre passività qui sopra — e ogni output è evidenza che un terzo può controllare, mai un'autovalutazione.
Nessuna dashboard, nessun nuovo strumento in cui autenticarsi. L'agente che i vostri sviluppatori già usano, semplicemente, si rifiuta di cantare vittoria senza prove. Qui — trascrizione autentica, nella lingua del prodotto — ha appena modificato un file sorgente e dichiarato il lavoro finito: il gate trattiene la dichiarazione finché la suite di test non è girata sul codice così com'è ora.
Un gate che blocca a partire da congetture viene disattivato entro una settimana — e si porta via i controlli che invece funzionavano. Perciò un controllo può bloccare solo dove il suo rilevamento è esatto; tutto il resto avvisa. È questa moderazione a farlo sopravvivere al contatto con una vera organizzazione di ingegneria.
Il contratto che rende sicuro mettere tutto questo davanti a un regolatore: l'AI produce evidenza e bozze, la responsabilità resta a persone con nome e cognome. Non è un limite che abbiamo accettato — è il progetto.
Nessun artefatto — ADR, SBOM, gap report, audit, adempimento regolatorio — viene mai marcato Accettato, Conforme o Validato da Claude di propria iniziativa. Tutto esce come Proposed o Draft finché una persona precisa non dice altrimenti.
Ogni report dichiara per ciascuna voce uno di esattamente tre esiti — presente, lacuna, o non applicabile — ognuno con un riferimento o una motivazione. «Sembra a posto» non è un output che questo plugin produce; dove compare, è un bug.
Niente qui invia ad autorità, spedisce email o pubblica su una piattaforma di segnalazione. Scrive il testo e calcola l'orologio. La trasmissione è un atto organizzativo compiuto da una persona precisa, e ogni bozza lo dice nella sua prima riga.
Dove una domanda genuinamente non si applica — uno strumento di migrazione senza rollback, un framework che i gate non sanno leggere — il report lo dice, e dice perché. Un report che non dice mai «non applicabile» è un report che ha cominciato a inventarsi rilievi per sembrare utile.
Un repository può abbassare la severità di un gate, mai alzarla — e un abbassamento viene stampato come abbassamento. Un team che ha spento un gate non deve poter produrre un output uguale a quello di un team che lo ha superato. Questa proprietà sopravvive alle modifiche di configurazione, per costruzione.
Un prodotto di governance che asserisse la propria qualità sarebbe il controesempio di sé stesso. Perciò questa pagina è tenuta allo stesso contratto di tutto il resto: 1523 controlli automatici su 23 suite girano a ogni pull request, su due sistemi operativi — e uno script rideriva dalla fonte ogni numero pubblicato qui, facendo fallire la build quando una copia non concorda. Esiste perché in una sola settimana abbiamo pubblicato tre numeri stantii.
Che ogni skill si attivi quando deve è testato alla cieca: 987 giudizi ciechi finora — tre giudici indipendenti per prompt, senza strumenti, su un modello fissato. Uno split 2 su 3 viene registrato come FLAKY e mai arrotondato in su: il disaccordo è il rilievo.
Un giro ha scoperto che la skill di segnalazione incidenti non si sarebbe attivata su «degli attaccanti sono entrati nel nostro build server» — un incidente grave da manuale sotto il CRA. Tutti e tre i giudici l'hanno mancata, per la stessa ragione documentata. La correzione erano poche parole; il punto è che l'abbiamo trovata misurando, prima che la trovasse un cliente.
Sostenevamo che il nostro catalogo fosse vicino al suo tetto — poi ci siamo accorti che l'affermazione non derivava da nulla, e abbiamo costruito lo strumento: 600 giudizi di selezione su 200 righe, quattro bracci. Aggiungere tre skill è costato zero regressioni di instradamento, due volte. L'affermazione è morta; il numero l'ha sostituita.
Ogni giro di validazione è registrato, compresi quelli scartati e quelli che hanno trovato una lacuna vera. Lo stato finale pulito è la parte meno informativa di quel registro, quindi non è l'unica che conserviamo.
Onesti anche sulla scala. Dieci prompt per skill giudicati in tre modi sono uno smoke test per i fallimenti grossolani, non un benchmark — e il registro stesso lo dichiara. Ha trovato difetti reali in materiale che i suoi autori avevano letto con cura più volte: è questo l'intero argomento per continuare a eseguirlo.
È un plugin per Claude Code — viaggia sugli strumenti che i vostri sviluppatori già usano. Nessun server da gestire, nessun dato che lascia i vostri repository, nessuna dashboard a consumo. Lo installa il vostro platform team; le skill, i gate e il hook di verifica sono attivi dalla sessione successiva.
Ci raccontate come i vostri team usano l'AI oggi e quali regimi vi toccano. Nessuna slide da parte nostra: l'esito della call è la scelta del repository per l'audit pilota.
L'audit del harness e il primo /compliance-status girano su un vostro repository. Ne esce una baseline reale: presente, lacuna o non applicabile — la stessa forma del rapporto qui sopra.
Decidete sul gap report del vostro codice, non su una demo. Se si prosegue, l'installazione sono i due comandi qui sotto — attiva dalla sessione successiva.
claude plugin marketplace add <url-del-vostro-repository-privato>
claude plugin install oltrematica-skills@oltrematica
La consegna avviene da un repository privato dedicato al vostro contratto: l'URL vi viene fornito all'attivazione dell'ingaggio. È lo stesso canale con cui le release 3.x sono già state consegnate in produzione ai primi clienti.
Dite "audit our harness" in un repository qualsiasi. Dieci superfici, ognuna riportata come presente, lacuna o non applicabile — una baseline da mettere in una slide per il comitato di direzione il giorno stesso.
Eseguite /compliance-status. La posizione regolatoria — CRA, GDPR, AI Act, PLD, EAA — inventariata per repository, con ogni lacuna instradata verso la skill che la chiude.
I gate girano su ogni modifica, in CI se volete. Il hook di verifica sottopone ogni «fatto» a un'esecuzione fresca dei test. Da qui in poi l'evidenza si accumula come effetto collaterale del lavoro normale.
Nove ecosistemi per il rilevamento dei comandi di test, e tredici strumenti di migrazione per il gate di reversibilità — compresi i due che un rollback non ce l'hanno affatto, riportati come non applicabile anziché come lacuna. Licenza proprietaria; la consegna avviene da un repository privato per cliente. Parlate con Oltrematica per un ingaggio.