La risposta più facile arriva in pochi secondi. Il provider è sicuro, i dati non vengono usati per addestrare il modello e sul sito esiste una privacy policy. Sembra rassicurante, almeno fino a quando il DPO fa una domanda molto semplice.
Se domani un cliente chiede di cancellare i propri dati, sappiamo davvero dove sono finiti?
A quel punto la conversazione cambia. Qualcuno deve sapere che cosa è rimasto nella memoria dell’Agent, nei checkpoint, nei registri, nelle richieste ancora in attesa e nei sistemi collegati. Qualcuno deve poter dimostrare quale versione dell’Agent ha preso una decisione, perché ha chiamato uno strumento e chi ha autorizzato un’azione delicata. Se qualcosa va storto, non basta dire che il modello ha interpretato male il prompt.
È qui che una bella demo smette di essere un prodotto. Ed è proprio pensando a questo momento che ho costruito Spectre.
La demo non è il prodotto
Molti framework per Agent sono ottimi per arrivare rapidamente a una dimostrazione. Si collega un modello a qualche strumento, si aggiunge memoria e in poco tempo il sistema risponde, cerca informazioni e compie azioni. È un risultato utile, ma per un’azienda rappresenta solo l’inizio.
Un CEO deve chiedersi che cosa succede alla fiducia dei clienti se l’Agent espone informazioni che non dovrebbe conoscere. Un CTO deve capire chi possiede lo stato del sistema, come vengono approvati i cambiamenti e se una cancellazione resta valida anche dopo un riavvio. Il responsabile della sicurezza vuole sapere se un processo vecchio può scrivere dati ormai superati. Il DPO vuole una risposta precisa quando una persona esercita un proprio diritto.
Queste domande non riguardano la qualità della conversazione. Riguardano la responsabilità dell’azienda.
Spectre 0.3.3 nasce come runtime governato per Agent che devono vivere dentro prodotti e processi reali. Il modello può capire, proporre e aiutare. Non possiede però l’autorità finale sullo stato, sulle credenziali o sulle azioni che producono conseguenze nel mondo. Quell’autorità resta all’applicazione e quindi all’organizzazione che la gestisce.
Per chi deve acquistare o portare in produzione una soluzione AI, questa differenza è molto più importante di una nuova funzione nella demo.
La privacy comincia da ciò che scegli di non conservare
Nel GDPR ricorrono principi come minimizzazione, limitazione della conservazione, sicurezza e protezione dei dati fin dalla progettazione. In termini aziendali, il messaggio è diretto. Se un’informazione non serve, è meglio non raccoglierla. Se serve, bisogna sapere perché esiste, dove si trova e per quanto tempo rimarrà disponibile.
Spectre applica questa idea alla struttura stessa dell’Agent. Il suo Journal registra il percorso delle decisioni senza dover copiare per impostazione iniziale l’intera conversazione, gli argomenti sensibili di un’azione, il risultato completo di uno strumento o gli errori grezzi di un provider. Conserva ciò che serve a capire il comportamento del sistema, lasciando all’azienda la scelta consapevole di ampliare la raccolta quando esiste una ragione valida.
È una distinzione pratica. Un registro utile per le verifiche non deve diventare automaticamente un secondo archivio di dati personali. Meno copie inutili significano meno superficie da proteggere, meno luoghi da controllare e meno sorprese quando arriva una richiesta di accesso o cancellazione.
Cancellare deve voler dire cancellare
La cancellazione è uno dei punti nei quali molti prototipi mostrano i propri limiti. Eliminare una riga dal database può sembrare sufficiente, ma un Agent vive spesso in più luoghi contemporaneamente. Può avere uno stato attivo, un checkpoint, eventi registrati, ricevute ancora da consegnare e processi che stanno lavorando su una versione precedente dei dati.
Con la versione 0.3.3, Spectre introduce una procedura di cancellazione governata per le Instance non attive. Prima identifica con precisione il soggetto interessato e mostra che cosa rientra nell’operazione. Poi rimuove i dati core configurati in un ordine controllato, produce una prova che non rivela il contenuto cancellato e lascia un segnale durevole che impedisce a un processo ormai superato di ricreare quello stato.
Questo ultimo dettaglio conta molto. Una cancellazione non è reale se, pochi secondi dopo, un vecchio processo può far riapparire i dati che l’azienda aveva appena dichiarato di aver eliminato.
Spectre verifica anche che l’operazione resti limitata all’identità corretta, che possa essere ripetuta senza effetti imprevisti e che una scrittura concorrente non vinca sulla cancellazione. Sono problemi poco visibili durante una presentazione, ma diventano essenziali quando l’Agent gestisce clienti, dipendenti, pazienti o cittadini.
Naturalmente nessun runtime può sapere da solo dove un’azienda abbia copiato tutti i dati. Spectre governa ciò che vede e ciò che gli adapter dichiarano. L’applicazione resta responsabile per memoria esterna, telemetria, copie esportate, registri del provider, repliche e backup. La differenza è che ora esiste un confine esplicito e verificabile, non una promessa vaga nascosta nel codice.
Il modello propone, l’azienda decide
Quando un Agent può inviare una comunicazione, modificare un ordine, accedere a un documento riservato o avviare un pagamento, scrivere nel prompt di chiedere conferma non è un sistema di controllo.
Il modello potrebbe fraintendere la richiesta. Un aggiornamento potrebbe cambiarne il comportamento. Un attacco potrebbe provare a convincerlo che l’approvazione è già avvenuta. Per questo in Spectre l’autorità non vive nel prompt.
Il modello propone un’azione. Le policy e il ciclo di vita deterministico stabiliscono se quell’azione può procedere. Quando serve una decisione umana o aziendale, il sistema può aspettarla senza bloccare l’intera conversazione. L’approvazione arriva da una fonte controllata dall’applicazione, non da una frase generata dal modello stesso.
Per un CEO questo significa poter dichiarare con maggiore credibilità che le decisioni sensibili restano sotto controllo umano. Per un CTO significa disporre di un confine che può essere testato, osservato e collegato ai sistemi di autorizzazione già presenti in azienda.
Il principio è semplice: l’intelligenza può stare nel modello, ma la responsabilità deve restare nell’organizzazione.
La conformità ha bisogno di prove
Durante una verifica, dire che il team segue un buon processo non è la stessa cosa che poterlo dimostrare.
Spectre tratta la configurazione operativa di un Agent come una Definition versionata e immutabile. Quando cambia un modello, una policy, un prompt, una capacità o una regola di approvazione, l’azienda può sapere quale versione è stata valutata e quale è stata effettivamente attivata. Il Journal e le ricevute collegano poi le decisioni allo stato e alla Definition corretti senza dover esporre segreti o contenuti personali non necessari.
Questo permette di ricostruire una domanda che prima o poi arriva in ogni progetto serio: che cosa sapevamo, quale versione era attiva e perché il sistema ha potuto agire?
Con gli strumenti di osservazione e riproduzione di Spectre, compreso Spectre Lab, un comportamento può essere studiato e confrontato senza affidarsi alla memoria di chi era presente. Una versione problematica può essere fermata e una Definition precedente può essere ripristinata attraverso un processo esplicito. Per il business significa indagini più rapide, cambiamenti meno rischiosi e conversazioni più concrete con sicurezza, legale, clienti e auditor.
La libertà dal provider è anche una scelta di governance
In Europa la posizione dei dati, i termini del fornitore e i trasferimenti internazionali possono influenzare una decisione commerciale. Una soluzione legata in profondità a un solo modello o a un solo servizio può sembrare comoda oggi e diventare costosa domani.
Spectre lascia all’host il controllo di storage, credenziali, autorizzazioni e azioni esterne. Modelli e infrastrutture possono essere sostituiti dietro contratti verificabili senza cedere loro la proprietà dello stato canonico dell’Agent. Questo non elimina il lavoro necessario per valutare un nuovo fornitore, ma rende quella scelta possibile senza ricostruire l’intero prodotto.
Per un CTO significa maggiore libertà architetturale. Per un CEO significa ridurre una dipendenza che può incidere su margini, continuità operativa e accesso a clienti regolamentati. Per un’agenzia significa poter adattare la stessa base a clienti con requisiti diversi di conservazione, residenza dei dati e approvazione.
GDPR, AI Act e ISO chiedono una cosa simile
Il GDPR, l’AI Act e gli standard ISO non sono la stessa cosa. Il GDPR tutela le persone nel trattamento dei dati personali. L’AI Act introduce obblighi legati al rischio e, quando applicabili, richiede particolare attenzione a gestione del rischio, registrazione, supervisione umana, robustezza e sicurezza. Standard come ISO/IEC 42001, ISO/IEC 23894, ISO/IEC 27001 e ISO/IEC 27701 aiutano invece a organizzare sistemi di gestione per AI, rischio, sicurezza e privacy.
Eppure, quando queste prospettive entrano in un progetto reale, fanno emergere la stessa esigenza. L’azienda deve conoscere il proprio sistema, assegnare responsabilità, controllare i cambiamenti, limitare i dati, mantenere supervisione e produrre prove credibili.
Spectre 0.3.3 non trasforma automaticamente un’organizzazione in conforme e non consegna una certificazione ISO. Offre però una base tecnica che parla la stessa lingua dei processi di governance. Lo stesso Journal che aiuta a capire un incidente può sostenere una verifica interna. La stessa Definition che rende controllabile un aggiornamento può diventare evidenza per la gestione del cambiamento. La stessa separazione tra modello e autorità può supportare il disegno della supervisione umana.
Non significa usare una prova per dichiarare soddisfatto qualunque requisito. Significa evitare di costruire ogni volta un sistema diverso per dimostrare aspetti dello stesso controllo.
Il vantaggio per un CEO e un CTO
Il valore di questa architettura non si misura soltanto nel codice. Si vede quando una revisione di sicurezza richiede settimane invece di mesi. Si vede quando un cliente enterprise riceve risposte precise, quando il DPO non deve inseguire dati nascosti in cinque servizi e quando un aggiornamento può essere fermato senza spegnere l’intero prodotto.
Si vede soprattutto nel costo che l’azienda evita. Aggiungere governance dopo che un Agent è già collegato a clienti, sistemi e processi è molto più difficile che progettarla dall’inizio. Quello che in una demo sembra un dettaglio tecnico può diventare un blocco commerciale, una perdita di fiducia o un rischio per il consiglio di amministrazione.
Per questo non considero Spectre migliore per ogni esperimento AI. Se serve soltanto provare un’idea in un pomeriggio, esistono strumenti più semplici. Ma quando un Agent deve restare attivo, trattare dati personali o produrre effetti reali, la capacità di governarlo non è un’aggiunta. È parte del prodotto.
La tecnologia non sostituisce la responsabilità
Spectre non sceglie la base giuridica del trattamento, non scrive l’informativa privacy, non esegue la valutazione di impatto al posto del DPO e non decide se un sistema rientra in una categoria dell’AI Act. Non configura la conservazione del provider, non approva trasferimenti internazionali, non forma il personale e non assegna una certificazione ISO.
Queste responsabilità restano all’organizzazione e ai professionisti che la accompagnano. Spectre serve a fare in modo che le loro decisioni possano diventare controlli tecnici reali, osservabili e riproducibili.
La domanda da fare prima di portare un Agent sul mercato non è soltanto quanto bene sappia parlare. È chi possa fermarlo, chi possa autorizzarlo, come si possano cancellare davvero i dati e quali prove rimangano dopo una decisione.
In Europa un Agent credibile non deve soltanto funzionare. Deve meritare la fiducia necessaria per entrare in azienda. Spectre 0.3.3 è stato costruito esattamente per questo passaggio.