Il controllo dei dati va oltre il server IA

Un modello linguistico gestito localmente può consentire di stabilire un importante perimetro per i dati. L’estensione di questo controllo dipende anche dall’applicazione che chiama il modello. L’input può raggiungere correttamente il server del modello ed essere comunque salvato altrove, fuori dall’ambiente approvato.

Una chiamata interna al modello con un secondo percorso dei dati

In un’architettura fittizia, un portale progetti riassume note interne tramite un servizio di modelli autogestito. La chiamata normale rimane nell’ambiente aziendale. In caso di errore di elaborazione, però, l’applicazione invia tutto il contenuto della richiesta a un servizio esterno per gli errori. L’elaborazione del modello resta locale; la nota è comunque uscita attraverso il percorso di errore. È un controesempio costruito, non un incidente osservato presso un cliente.

Il server del modello non può impedire da solo questo trasferimento aggiuntivo nel codice dell’applicazione. Occorre valutarlo nel portale e nel servizio per gli errori. Una progettazione adeguata potrebbe registrare, per esempio, un codice di errore e un riferimento all’operazione al posto del testo della nota. Quali eventi siano necessari resta una decisione distinta; disattivare tutti i log non risolverebbe la questione operativa.

Lo stesso vale all’interno dell’ambiente: un modello locale non rende automaticamente una nota visibile soltanto al team di progetto autorizzato. L’applicazione deve limitare l’accesso a input e risultati. OWASP tratta esplicitamente i dati sensibili nel contesto dell’intera applicazione basata sul modello e raccomanda il principio del minimo privilegio. Chiedere al modello di non divulgare dati riservati non sostituisce questo controllo degli accessi.

Quando la gestione locale è un argomento forte

Se i dati aziendali non devono lasciare l’ambiente approvato dell’azienda, un servizio di modelli gestito al suo interno può sostenere proprio questo requisito. Anche interfaccia, servizi aggiuntivi, log e backup devono rispettare il perimetro. Questo controllo è un vantaggio concreto quando è effettivamente implementato e verificato.

L’azienda deve poter aggiornare modello e ambiente di esecuzione, gestire gli accessi e ripristinare il servizio dopo un guasto. Un servizio gestito trasferisce al fornitore i compiti operativi concordati. Può essere adatto a un percorso dei dati autorizzato; il nome non descrive le modalità concrete di trattamento e conservazione. Non ne deriva un vincitore universale in termini di costi o sicurezza.

Quale osservazione cambia la valutazione

Per il portale, una copia esterna confermata del testo della nota giustificherebbe il ritiro dell’affermazione di un percorso interamente interno. Se una verifica mostrasse invece che chiamate normali e percorsi di errore rimangono nel perimetro e che soltanto i ruoli autorizzati accedono ai contenuti, l’argomento del controllo locale acquisterebbe peso. Le FAQ di Ollama illustrano già la distinzione tra funzioni locali e cloud per quel prodotto; esaminare l’intero portale va oltre.

Resta da verificare se l’architettura delineata soddisfi queste condizioni.

Fonti

• Ollama — FAQ

• OWASP — LLM02:2025 Sensitive Information Disclosure

• OWASP — Logging Cheat Sheet