Security & Delivery Pack

Modello operativo e responsabilità

Ogni progetto ha un referente Futura AI identificabile per nome, che segue il sistema dall'Assessment alla messa in produzione e resta disponibile dopo il go-live. Ruoli e responsabilità — chi configura, chi supervisiona, chi approva, chi può disattivare il sistema — vengono definiti esplicitamente con il cliente durante l'Assessment, non lasciati impliciti. Specialisti verticali vengono coinvolti sul singolo progetto quando servono competenze specifiche, non come struttura fissa aggiunta per default.

Residenza dei dati e segregazione

Il deployment — cloud, on-premise o ibrido — segue i vincoli del cliente, non una preferenza tecnologica di partenza. In ogni configurazione, i dati e le richieste di ciascun cliente restano in un ambiente separato da quello degli altri clienti, e non vengono usati per addestrare i modelli di base senza autorizzazione esplicita.

Titolarità dei dati e dei modelli

I dati caricati dal cliente restano di sua proprietà: non transitano ad altri clienti, non alimentano modelli di base senza autorizzazione esplicita, e la portabilità in uscita — esportazione o cancellazione dei dati a fine incarico — viene definita in fase di Assessment, non lasciata implicita. Sulla titolarità delle componenti sviluppate su misura per il progetto (pipeline, prompt, configurazioni) non pubblichiamo qui una clausola generica: dipende da cosa è specifico del cliente e cosa è parte riutilizzabile del nostro metodo, e viene definita nel contratto di ciascun progetto.

Integrazione con i sistemi esistenti

Il sistema si collega ai gestionali, ERP, CRM, protocollo, PEC e database già in uso dal cliente tramite le API disponibili, senza duplicare strumenti già adottati: l'obiettivo non è sostituire l'infrastruttura esistente, ma inserirsi al suo interno. I permessi di accesso ereditano ruoli e policy già configurati nell'organizzazione. Il perimetro esatto dei sistemi da integrare viene mappato durante l'Assessment, prima di qualunque sviluppo.

Gestione degli accessi e permessi

I permessi di accesso al sistema seguono i ruoli e le policy già in uso nell'organizzazione cliente, non un modello a sé stante. Prima del rilascio in produzione, ogni progetto include una revisione incrociata di ruoli, accessi e segregazione dei dati.

Audit trail e logging

Ogni fonte consultata, azione eseguita e decisione assistita dal sistema viene registrata in modo verificabile, con riferimento al dato di origine. I log tecnici e applicativi sono conservati secondo policy concordate con il cliente, coerenti con i requisiti di audit del suo settore: non esiste un periodo di conservazione standard valido per ogni progetto, e non ne pubblichiamo uno qui per non farne intendere uno che non si applica al vostro caso.

Gestione degli incidenti

Le azioni ad alto impatto restano soggette a conferma umana esplicita: è la prima linea di controllo su un comportamento anomalo del sistema. Le procedure di escalation e i tempi di intervento in caso di incidente vengono definiti per ciascun progetto insieme al cliente, in coerenza con i suoi processi di gestione incidenti già esistenti — non pubblichiamo qui uno SLA generico, perché dipende dal contesto operativo e dal livello di criticità del sistema.

Test di sicurezza prima del rilascio

Ogni sistema attraversa quattro fasi prima del rilascio in produzione: threat modeling, per identificare gli scenari di abuso rilevanti per quel processo specifico; red teaming, con tentativi mirati di aggirare i guardrail o manipolare il system prompt; test di accuratezza e comportamento su casi reali, non solo su esempi predisposti; revisione incrociata di ruoli, accessi e segregazione dei dati.

Certificazioni e standard

ISO 9001 (gestione qualità) e ISO 27001 (sicurezza delle informazioni) sono in fase di certificazione; l'allineamento alla direttiva NIS2 procede in modo progressivo. Sul GDPR non dichiariamo una conformità generale — non esiste, è specifica per ogni trattamento — ma progettiamo i sistemi secondo misure tecniche e organizzative coerenti con gli obblighi applicabili: minimizzazione, segregazione, gestione degli accessi, tracciabilità. Lo stato di avanzamento di ciascuna certificazione è consultabile nella pagina Sicurezza e Governance.

Infrastruttura e fornitori cloud

Lavoriamo sia con modelli open-source sia con servizi PaaS erogati dai principali cloud provider — AWS, Azure, GCP — scegliendo caso per caso in base a costo, prestazioni, residenza dei dati e vincoli di sicurezza del cliente: non siamo legati a un singolo fornitore di modelli. L'elenco dei fornitori terzi effettivamente coinvolti in un progetto viene condiviso con il cliente come parte della documentazione tecnica, perché varia da progetto a progetto.

Continuità operativa

La scelta fra cloud, on-premise e ibrido incide direttamente sulla continuità: in cloud dipende dagli SLA del provider, on-premise è sotto controllo diretto del cliente, in configurazione ibrida la ridondanza si distribuisce su entrambi i livelli. Non pubblichiamo un uptime garantito generico: è un parametro che si concorda per progetto, in base alla criticità del sistema.

Ciclo di vita del modello e miglioramento continuo

Dopo il rilascio, i risultati vengono rivisti periodicamente: aggiornamento di dati e prompt, calibrazione delle soglie, adeguamento del sistema ai cambiamenti del processo. È una fase del progetto concordata fin dall'Assessment, non un servizio separato da rinegoziare in un secondo momento.