Architettura di riferimento
Otto competenze e un metodo in otto fasi spiegano cosa facciamo. Questa pagina spiega come è costruito il sistema, layer per layer — per chi deve valutarlo tecnicamente prima di autorizzarlo, non solo leggerne il risultato.
Non è un'architettura unica applicata a ogni cliente: è l'insieme di pattern che ricombiniamo in base al processo, al livello di rischio e ai vincoli infrastrutturali di ogni organizzazione — la stessa logica già dichiarata per la scelta delle tecnologie, qui un livello più in profondità.
RAG & evaluation
Recupero delle fonti e verifica dell'accuratezza
Le risposte si basano solo su fonti autorizzate e recuperate al momento della richiesta, mai su conoscenza non verificabile del modello. Prima del rilascio l'accuratezza si misura su casi reali del cliente, non su esempi predisposti, con soglie esplicite sotto le quali il sistema segnala invece di rispondere.
Identità e permessi
Chi può fare cosa, su quali dati
Il sistema eredita ruoli e permessi già esistenti nell'organizzazione invece di crearne di nuovi: un utente vede e interroga solo ciò che i suoi permessi consentono già altrove, con segregazione netta tra ambienti e tra clienti.
Guardrail applicativi
Limiti espliciti su cosa il sistema può fare
Ogni contenuto recuperato da documenti, email o pagine esterne è trattato come input non fidato: isolamento del system prompt, sanitizzazione e un perimetro esplicito di azioni eseguibili dagli agenti, verificato con red teaming mirato prima del rilascio.
Logging e audit trail
Ogni fonte, azione e decisione tracciata
Log tecnici e applicativi collegano ogni risposta alla fonte che l'ha generata e ogni azione eseguita a chi l'ha avviata, conservati secondo policy concordate e utilizzabili per audit interni, verifiche esterne e analisi di incidenti.
Versioning
Modelli, prompt e basi documentali sotto controllo di versione
Modelli, prompt e basi documentali cambiano nel tempo, per aggiornamenti del fornitore, nuovi documenti o tuning delle soglie. Ogni modifica è versionata e testata prima del rilascio: se peggiora l'accuratezza misurata, si torna alla versione precedente invece di accettare la regressione in produzione.
Human review
Le azioni ad alto impatto restano umane, per scelta
Le soglie di confidenza determinano quando il sistema agisce da solo e quando segnala per revisione; le azioni ad alto impatto restano soggette a conferma umana esplicita in ogni caso, per scelta di design — non perché il modello non sia abbastanza accurato.
Questi sei layer non sono un prodotto software venduto così com'è: sono il criterio con cui progettiamo ogni sistema, ricombinato in base al processo, al livello di rischio e ai vincoli infrastrutturali dell'organizzazione — cloud, on-premise o ibrido. Il dettaglio di policy, certificazioni e AI Act che sta dietro a ciascun layer vive nella pagina Sicurezza e governance.
Vuoi vedere come si applica al vostro caso?
Un Assessment AI parte da un processo reale, non da un'architettura teorica: verifica quali di questi layer contano davvero per il vostro contesto, prima di qualunque impegno di sviluppo.
Richiedi un Assessment AI