Quali modelli AI toccano i tuoi dati finanziari, e a quali condizioni

«Quale modello vede i nostri bilanci, e cosa gli impedisce di addestrarsi su di essi?» è una domanda che ogni acquirente serio prima o poi pone, e la risposta onesta è più interessante di «usiamo un unico fornitore fidato». Rexfin usa diversi modelli per diversi compiti, deliberatamente, e il motivo per cui questo è sicuro anziché sconsiderato si riduce a due scelte progettuali: nessun singolo modello viene mai considerato affidabile riguardo a un numero, e nessun modello vede alcunché finché i suoi termini sui dati non sono stati verificati.

Il numero non dipende da quale modello lo ha scritto

La catena di fiducia di Rexfin si basa sull’accordo tra passaggi di estrazione indipendenti, sulla riconciliazione con il totale stampato e su un controllo di identità deterministico, mai sulla fiducia di un singolo modello. È di questo che tratta davvero perché il calcolo è deterministico, non generativo, ed è il motivo per cui Rexfin può permettersi di essere pragmatica su quale modello svolge quale compito.

Le attività ad alto volume e a basso rischio (estrarre cifre da una pagina, classificare una voce, riscrivere una query di retrieval) girano su modelli più economici, perché il controllo di accordo sull’estrazione intercetta una stima sbagliata indipendentemente da quale modello l’abbia prodotta. I due ruoli che contano davvero per ciò che legge un cliente, ossia il verificatore che ragiona su un fallimento di identità e lo scrittore che produce la risposta finale citata, sono riservati a modelli più forti. Se il livello forte non è disponibile, Rexfin fallisce in modo chiuso e restituisce un errore chiaro invece di declassare silenziosamente una risposta critica per la fiducia a un modello più economico. Una risposta sbagliata da un modello economico travestita da risposta ponderata è peggio di nessuna risposta.

Nessun provider entra senza termini verificati

Ogni provider passa attraverso un gate di ammissione prima di poter essere instradabile in assoluto. I termini sui dati di un provider vengono registrati come un fatto strutturato: se trattiene i prompt, se li usa per l’addestramento, in quale regione elabora, qual è il riferimento del DPA. Solo un provider registrato come zero retention e no training viene ammesso; qualsiasi altro viene segnalato o respinto e semplicemente non può essere selezionato, indipendentemente da quanto sia buono il modello. Se i termini di un provider decadono o scadono, viene automaticamente retrocesso e smette di ricevere traffico, senza bisogno di modifiche al codice né di un umano che ricordi di azionare un interruttore.

Questa non è deliberatamente una politica del tipo «non usiamo provider del paese X». Un provider viene ammesso o respinto puramente in base ai termini che può dimostrare, il che è ciò che mantiene onesto il racconto di governance invece che performativo, e significa che nessun singolo fornitore diventa mai qualcosa da cui Rexfin non possa instradare altrove se i suoi termini cambiano.

Nulla resta fuori dalla regione a cui appartiene

I dati a riposo (le cifre estratte, i registri di audit, le risposte in cache) restano vincolati a un’unica regione dichiarata. Un provider di modelli esterno può vedere un prompt in transito, ma solo secondo un termine di zero retention, e la comunicazione su quali provider vedono cosa è generata dalla configurazione di routing attiva piuttosto che mantenuta a mano come un documento che silenziosamente finisce per non essere più aggiornato. Per i clienti con requisiti più rigidi, i ruoli critici per la fiducia possono essere indirizzati invece verso un modello self-hosted e in regione, uno dei percorsi trattati nelle opzioni di residenza dei dati per il GCC.

Il flusso di dati a volume più alto nel sistema, il calcolo degli embedding per il retrieval, gira localmente anziché passare attraverso un’API esterna: il che significa che il singolo flusso di dati più grande non lascia mai la regione e, offline, non tocca mai un fornitore.

Cosa attraversa davvero il perimetro

Prima che un prompt vada a un provider fuori regione, passa attraverso un secondo gate: un passaggio che identifica gli span sensibili (nomi, numeri di conto, identificatori) e li maschera con segnaposto stabili prima che la richiesta lasci il sistema. Il modello ragiona sulla versione mascherata; i segnaposto vengono sostituiti con i valori reali localmente, dopo che la risposta ritorna, e quella mappatura non lascia mai il processo e non viene mai registrata nei log. Se il passaggio di mascheramento non può girare per qualche motivo, la chiamata viene bloccata invece che inviata non oscurata: la modalità di fallimento è sempre «rifiuta di inviare», mai «invia comunque e spera».

Cosa non promette

Nulla di tutto questo è una dichiarazione di certificazione: Rexfin non afferma qui uno status SOC o ISO. Ciò che afferma è più circoscritto e verificabile: le decisioni di routing sono configurazione, l’ammissione dei provider è applicata nel codice piuttosto che promessa in un DPA, e la comunicazione su chi vede cosa è generata da ciò che è effettivamente collegato, non redatta separatamente. Questa combinazione è ciò che trasforma «verifichiamo i nostri fornitori IA» da una frase in un questionario di sicurezza in qualcosa che un acquirente può effettivamente verificare. Per come questo si collega all’architettura di sicurezza più ampia della piattaforma e a come Rexfin resiste agli input avversari nei prompt, vedi difese contro il prompt injection. Per la mappa completa di come è costruita la piattaforma, visita l’hub Dentro la piattaforma Rexfin.