Sicurezza, governance e compliance
Per organizzazioni con requisiti elevati di sicurezza — enti pubblici, banche, assicurazioni, industria regolamentata — la sicurezza non è un capitolo a parte: è un vincolo di progettazione fin dalla prima riga di architettura.
In sintesi, tre promesse
I dati restano sotto controllo
Classificazione, minimizzazione, segregazione tra clienti e nessun addestramento sui vostri dati senza autorizzazione esplicita — su infrastruttura cloud, on-premise o ibrida secondo i vostri vincoli.
L'AI non agisce oltre i limiti definiti
Le azioni ad alto impatto restano soggette a conferma umana esplicita; ogni contenuto recuperato da fonti esterne è trattato come input non fidato, non come istruzione.
Ogni decisione rilevante è verificabile
Fonti, azioni e decisioni assistite restano tracciate con riferimento al dato di origine, con ruoli e responsabilità definiti fin dal design del sistema.
Il dettaglio, per chi lo deve verificare
Gestione dei dati
Classificazione dei dati trattati, minimizzazione, nessun addestramento sui dati del cliente senza autorizzazione esplicita, segregazione tra ambienti e clienti.
On-premise, cloud e hybrid
Il deployment segue i vincoli dell’organizzazione, non il contrario: quando la residenza dei dati non è negoziabile, l’architettura resta on-premise o ibrida.
Audit trail
Ogni fonte consultata, azione eseguita e decisione assistita viene registrata in modo verificabile, con riferimento al dato di origine.
Human-in-the-loop
Le azioni ad alto impatto restano soggette a conferma umana esplicita; il sistema segnala i casi dubbi invece di decidere al posto delle persone.
Difesa da prompt injection
Ogni contenuto recuperato da documenti, email o pagine esterne è trattato come input non fidato: isolamento del system prompt, sanitizzazione, controllo delle azioni eseguibili dagli agenti.
AI Act
Classificazione del rischio del sistema, documentazione tecnica e requisiti di trasparenza allineati al framework normativo europeo, gestiti fin dalla fase di design.
Ruoli e responsabilità
Definizione esplicita di chi può configurare, supervisionare, approvare o disattivare il sistema, e di chi risponde di ogni fase del suo funzionamento.
Logging e tracciabilità
Log tecnici e applicativi conservati secondo policy concordate, utilizzabili per audit interni, verifiche esterne e analisi di incidenti.
Percorso di certificazione e conformità
L’AI Act, in breve
Il Regolamento europeo sull'intelligenza artificiale entra in vigore per fasi. Dal 2 agosto 2026 sono applicabili gli obblighi di trasparenza e la piena operatività di vigilanza e sanzioni; il Digital Omnibus di luglio 2026 ha invece rinviato l'applicazione degli obblighi per i sistemi ad alto rischio. Per banche, assicurazioni ed enti pubblici non è un tema da rimandare: il rinvio riguarda le scadenze, non la preparazione necessaria per arrivarci pronti.
1 ago 2024
Entrata in vigore del Regolamento
2 feb 2025
Divieto delle pratiche a rischio inaccettabile
2 ago 2025
Obblighi per i modelli GPAI e regole di governance
27 lug 2026
Digital Omnibus in vigore: rinvio degli obblighi per i sistemi ad alto rischio
2 ago 2026
Obblighi di trasparenza (art. 50) e piena operatività di vigilanza e sanzioni
2 dic 2027
Applicazione degli obblighi per i sistemi ad alto rischio (Allegato III)
2 ago 2028
Obblighi per l'IA nei prodotti regolamentati (Allegato I)
2 ago 2030
Termine esteso per una parte dei sistemi ad alto rischio già in uso presso autorità pubbliche
Classificazione del rischio
Il Regolamento distingue quattro livelli: rischio inaccettabile (vietato), alto rischio (obblighi stringenti), rischio limitato (obblighi di trasparenza) e rischio minimo. Il livello dipende dall'uso del sistema, non dalla tecnologia in sé.
Chi è coinvolto più direttamente
Scoring creditizio, valutazione dell'affidabilità assicurativa, gestione del personale e accesso a servizi pubblici essenziali rientrano tra i casi d'uso ad alto rischio dell'Allegato III: banche, assicurazioni e PA sono tra i soggetti più esposti.
Obblighi per i sistemi ad alto rischio
Sistema di gestione del rischio, governance dei dati, documentazione tecnica, log automatici, supervisione umana e valutazione di conformità prima della messa in produzione.
Deployer, non solo provider
Anche chi utilizza un sistema ad alto rischio — non solo chi lo sviluppa — ha obblighi propri: per gli enti pubblici e per specifici casi nel settore finanziario, è richiesta una valutazione d'impatto sui diritti fondamentali.
Le quattro classi di rischio dell’AI Act
Il livello di obbligo dipende dall’uso del sistema, non dalla tecnologia sottostante: lo stesso modello può ricadere in classi diverse a seconda del contesto in cui viene impiegato.
Progettiamo i sistemi trattando questi obblighi come un vincolo architetturale fin dall'inizio, non come un adempimento da aggiungere a fine progetto: la classificazione del rischio è il primo passo di ogni Assessment AI.
Leggi il Regolamento (UE) 2024/1689 su EUR-LexCome verifichiamo un sistema prima del rilascio
Il collaudo di sicurezza fa parte del progetto, non è un controllo finale.
- 01
Threat modeling
Identifichiamo gli scenari di abuso più rilevanti per quel processo specifico: dati esposti, azioni non autorizzate, prompt injection.
- 02
Red teaming
Tentativi mirati di aggirare i guardrail, manipolare il system prompt o ottenere dati e azioni non previste.
- 03
Test su casi reali
Verifica di accuratezza e comportamento su dati e scenari reali, non solo su esempi predisposti.
- 04
Revisione dei permessi
Controllo incrociato di ruoli, accessi e segregazione dei dati prima del rilascio in produzione.
Questa pagina non sostituisce una valutazione formale di compliance specifica per il vostro settore: è la base su cui costruiamo, insieme ai vostri responsabili di sicurezza, governance e protezione dati, un sistema pronto per la produzione.
Richiedi un Assessment AIDomande frequenti
Come garantisce Futura AI la sicurezza dei sistemi di AI?
Guardrail applicativi, difesa da prompt injection, audit trail completo e conferma umana sulle azioni ad alto impatto.
Con guardrail applicativi, difesa da prompt injection, audit trail su ogni fonte e decisione assistita, e human-in-the-loop sulle azioni ad alto impatto. Il collaudo include threat modeling e red teaming prima del rilascio in produzione, non dopo: un sistema va in produzione solo quando accuratezza, robustezza e tracciabilità sono state verificate su casi realistici, e le azioni ad alto impatto restano comunque soggette a conferma umana.
I sistemi di Futura AI sono conformi all’AI Act?
Sì: la classificazione del rischio è il primo passo di ogni Assessment, non un adempimento aggiunto a fine progetto.
Trattiamo gli obblighi del Regolamento (UE) 2024/1689 come vincolo architetturale fin dall'inizio: la classificazione del rischio del sistema è il primo passo di ogni Assessment AI, non un adempimento aggiunto a fine progetto. Il divieto delle pratiche a rischio inaccettabile è in vigore dal 2 febbraio 2025. Dal 2 agosto 2026 sono applicabili gli obblighi di trasparenza dell'articolo 50 e la piena operatività del sistema di vigilanza e sanzioni; il Digital Omnibus di luglio 2026 ha invece spostato l'applicazione degli obblighi per i sistemi ad alto rischio dell'Allegato III al 2 dicembre 2027, e al 2 agosto 2028 per l'Allegato I. In pratica, questo significa documentazione tecnica, tracciabilità delle decisioni e valutazione d'impatto già integrate nell'architettura, non ricostruite a posteriori quando un sistema è già in produzione: è più semplice progettarle da subito che aggiungerle dopo — e il rinvio delle scadenze non è un motivo per rimandare questo lavoro, solo più tempo per farlo bene. È il criterio con cui impostiamo ogni Assessment fin dalla prima analisi del processo.
Futura AI addestra i modelli sui dati dei clienti?
No: nessun addestramento sui dati del cliente senza autorizzazione esplicita, in ambienti separati per cliente.
No. La gestione dei dati prevede classificazione, minimizzazione e segregazione tra ambienti e clienti: nessun addestramento sui dati del cliente senza autorizzazione esplicita. Ogni cliente lavora in un ambiente separato, con permessi coerenti con i ruoli e le policy già in uso nell'organizzazione, e i dati usati per interrogare il sistema — documenti, archivi, gestionali — restano distinti da quelli eventualmente usati per valutare o migliorare il sistema stesso. Quando un progetto richiede fine tuning o personalizzazione del modello, la scelta viene concordata esplicitamente con il cliente come parte dell'architettura, non come pratica di default: la regola è che il comportamento del sistema in produzione dipende da configurazione, prompt engineering e dati recuperati in tempo reale, non da un addestramento silenzioso sulle informazioni riservate dell'organizzazione. Questo vale sia per i clienti pubblici sia per quelli privati, senza eccezioni legate al settore o alla dimensione del progetto.
Futura AI ha certificazioni di sicurezza?
Progettiamo secondo misure tecniche e organizzative coerenti con il GDPR; ISO 9001, ISO 27001 e NIS2 sono in corso di certificazione.
Il percorso di certificazione è in corso: ISO 9001 (gestione qualità) e ISO 27001 (sicurezza delle informazioni) sono in fase di certificazione, l'adeguamento alla direttiva NIS2 sulla cybersicurezza è in corso. Sul GDPR non dichiariamo una "conformità" generale — non esiste, è specifica per ogni trattamento — ma progettiamo e configuriamo i sistemi secondo misure tecniche e organizzative coerenti con gli obblighi applicabili: minimizzazione, segregazione, gestione degli accessi, tracciabilità, e definizione contrattuale dei ruoli fra titolare e responsabile. La valutazione di conformità resta specifica per ciascun trattamento e si svolge con il cliente e, quando necessario, con i suoi referenti privacy. Preferiamo dichiarare lo stato reale del percorso piuttosto che presentare come acquisito un traguardo non ancora raggiunto: per organizzazioni regolate come pubblica amministrazione, banche e assicurazioni, la verifica indipendente conta più dell'annuncio. Nel frattempo, i controlli di sicurezza che le certificazioni ISO/NIS2 formalizzano — governance dei dati, gestione degli accessi, tracciabilità delle decisioni, gestione degli incidenti — sono già parte integrante di come progettiamo e collaudiamo ogni sistema, indipendentemente dallo stato del certificato, perché sono requisiti architetturali e non solo requisiti documentali. Lo stato di avanzamento di ciascuna certificazione è consultabile nella pagina dedicata a sicurezza e governance.