Dal prototipo alla modifica distribuita: integrare l’IA con permessi limitati

1. Definisci il confine di fiducia

Immagina una funzione interna che prepara un aggiornamento per un record. Il modello può leggere solo le informazioni strettamente necessarie e proporre nuovi campi, ma non riceve credenziali del database né esegue la modifica. Il controllo resta nell’applicazione convenzionale: autentica la persona, verifica i suoi permessi, controlla lo stato attuale e decide se applicare la modifica. Questa separazione limita l’impatto di una risposta errata o manipolata.

Disegna il percorso dei dati prima di scrivere codice. Individua che cosa invia la persona, quale contesto viene aggiunto, quale risposta ti aspetti e quali sistemi potrebbero essere coinvolti. Considera non attendibili i testi recuperati da documenti, ticket e record: potrebbero contenere istruzioni ingannevoli e non devono ampliare l’autorità del modello. Evita di includere segreti o dati personali non indispensabili per formulare la proposta.

Definisci un output con ambito ristretto. Invece di chiedere al modello di aggiornare un record, per esempio, chiedigli un oggetto con l’identificativo del record, i campi che propone di modificare e una breve spiegazione. La spiegazione può aiutare chi deve esaminare la proposta, ma non sostituisce i controlli del server. Il modello non deve stabilire chi è autorizzato né quali regole di business si applicano.

Una chiamata a strumenti o funzioni consente al modello di richiedere operazioni disponibili nell’applicazione; non trasforma la richiesta in un’autorizzazione. L’applicazione deve interpretarla come una proposta e applicare la propria policy. Se la funzione scelta comporta una scrittura, è preferibile che l’interfaccia esposta al modello permetta soltanto di preparare l’operazione, non di confermarla.

2. Inserisci un adattatore tra il modello e i servizi interni

L’adattatore è codice dell’applicazione che traduce tra la richiesta dell’utente, l’interfaccia del provider del modello e i servizi interni. Custodisce le credenziali, limita il contesto inviato, valida la risposta e richiama le operazioni deterministiche di business soltanto dopo aver superato i controlli. In questo modo il modello non si collega direttamente al database e non decide come autenticare una persona.

Separa le responsabilità in moduli comprensibili: autenticazione e autorizzazione; costruzione del contesto; chiamata al modello; validazione dell’output; presentazione per la revisione; esecuzione dell’operazione confermata. Questa separazione permette di cambiare provider senza riscrivere le regole di business e di disattivare la generazione senza rendere inutilizzabile la funzione convenzionale.

Definisci un contratto di input e output versionato. Una risposta strutturata può richiedere campi obbligatori, tipi specifici ed enumerazioni chiuse. L’output strutturato aiuta a ridurre le ambiguità di formato, ma non dimostra che i valori siano corretti o sicuri. Valida l’oggetto sul server, rifiuta i campi sconosciuti se previsto dal contratto e verifica anche le regole specifiche del dominio.

Lascia fuori dal modello le decisioni che devono essere deterministiche: identità dell’utente, permessi, limiti delle risorse, transizioni di stato, calcoli esatti e scrittura persistente. La documentazione delle piattaforme di integrazione illustra schemi per collegare modelli e flussi di lavoro, ma configurazione, connettori disponibili e relativi permessi dipendono dal prodotto e vanno verificati nella documentazione aggiornata.

3. Trasforma la proposta in un’operazione autorizzabile

La risposta del modello non è un comando attendibile. Prima di applicare una modifica, verifica che rispetti lo schema previsto, che la risorsa rientri nell’ambito autorizzato e che l’utente corrente possa eseguire proprio quell’operazione. Non dedurre l’autorizzazione dalla spiegazione del modello, da una categoria suggerita o da contenuti trovati nei documenti.

Controlla lo stato del record immediatamente prima della scrittura. Se è cambiato da quando è stata generata la proposta, non applicare in silenzio valori calcolati sulla base di una versione precedente. Puoi sottoporre nuovamente il caso a revisione, generare una proposta aggiornata sul nuovo stato o mostrare un conflitto perché la persona possa decidere. La scrittura deve includere un controllo di concorrenza adeguato al sistema di archiviazione utilizzato.

Definisci regole di business indipendenti dal modello. Una proposta può essere sintatticamente valida ma non consentita perché, per esempio, lo stato del ticket è già chiuso. Limita il numero di campi modificabili, rifiuta i valori fuori intervallo ed evita che il modello introduca identificativi di risorse non autorizzati in precedenza.

La revisione umana è particolarmente utile quando una modifica è delicata, difficile da annullare o riguarda altre persone. Deve permettere una decisione informata: mostra i valori attuali e quelli proposti, indica quali campi cambieranno e consenti di annullare. Nei contesti regolamentati, gli obblighi specifici dipendono dalla funzione e dalla classificazione applicabili; le guide pratiche di AESIA sono destinate all’attuazione del Regolamento sull’IA e sono presentate come raccomandazioni non vincolanti, non come sostituti della normativa.

4. Limita credenziali, strumenti e contesto

Applica il principio del minimo privilegio a ogni componente: una credenziale deve consentire solo le operazioni necessarie sulle risorse necessarie. Se il flusso deve consultare dati e proporre un aggiornamento, separa l’identità di lettura da quella che esegue le scritture. Tieni la seconda fuori dal processo del modello e usala soltanto nel percorso applicativo controllato dal server.

Non esporre al modello strumenti generici, come eseguire query arbitrarie, accedere a tutti i record o invocare qualsiasi API interna. Offri operazioni circoscritte, per esempio ottenere un riepilogo di un record autorizzato o preparare una modifica di categoria. Se la piattaforma consente di selezionare strumenti o funzioni, quell’elenco definisce un confine di capacità, ma non sostituisce l’autorizzazione implementata dall’applicazione.

Conserva chiavi e token nel sistema di gestione dei segreti approvato per l’ambiente; non inserirli nelle istruzioni, nei log di debug o nelle risposte agli utenti. Definisci rotazione e revoca, separa le credenziali per ambiente ed evita di riutilizzare chiavi di sviluppo in produzione. I meccanismi di sicurezza di un’API, come token, chiavi o certificati, hanno portata e requisiti diversi: verifica quale sia effettivamente configurato sulla tua piattaforma e non dare per scontato che il nome di un meccanismo implichi permessi minimi.

Riduci anche le informazioni fornite al modello. Elimina i campi irrilevanti, nascondi gli identificativi quando non servono e imposta limiti di dimensione. Verifica quali dati vengono inviati al provider, le condizioni aggiornate di trattamento e conservazione e le opzioni disponibili per la regione e il tipo di servizio acquistato. Questi dettagli variano in base a provider, prodotto, configurazione e data; non si possono dedurre da un modello architetturale generale.

5. Gestisci timeout, tentativi ripetuti e duplicati

Una chiamata al modello può richiedere tempo, restituire una risposta incompleta o fallire a causa di un’interruzione temporanea. Definisci un tempo massimo e considera non disponibile una risposta che lo supera; non eseguire azioni sulla base di un risultato parziale. Comunica uno stato chiaro e consenti un nuovo tentativo senza perdere la possibilità di controllare che cosa è stato richiesto.

Distingui tra ripetere la generazione e ripetere una scrittura. Una nuova richiesta di proposta può produrre un output diverso; conserva quindi l’identificativo della richiesta e mostra quale proposta è in revisione. Invece, ripetere una scrittura dopo un timeout può duplicare l’effetto se la prima richiesta è arrivata al sistema. Usa una chiave di idempotenza o un meccanismo equivalente quando il servizio lo supporta e controlla il risultato prima di inviare nuovamente la richiesta.

Un’operazione idempotente produce lo stesso stato effettivo se viene ripetuta nelle medesime condizioni; non va confusa con la ripetizione indiscriminata di qualsiasi richiesta. Per una scrittura non idempotente, predisponi un modo per rilevare se è già stata applicata, per esempio registrando l’identificativo dell’operazione insieme al risultato. Se dopo un errore non riesci a determinare l’esito, interrompi i tentativi automatici e avvia una procedura di riconciliazione.

Proteggi le scritture dalle modifiche concorrenti. Includi una versione o una condizione relativa allo stato letto dall’applicazione e rifiuta la scrittura se nel frattempo è cambiato. Definisci che cosa è possibile annullare: a volte basta ripristinare alcuni campi; in altri casi ci sono effetti esterni o notifiche che non si possono eliminare. In questi casi specifica un’azione compensativa e chi può decidere di applicarla.

6. Distribuisci per fasi e mantieni una via d’emergenza

Prepara un ambiente di test con dati non di produzione o adeguatamente protetti e credenziali separate. Verifica l’intero percorso: generazione di una proposta, rifiuto di un output non valido, diniego per mancanza di permessi, conflitto di stato, timeout e fallimento della scrittura. L’obiettivo è verificare il comportamento dell’integrazione scelta, non presumere che il provider offra una determinata funzione di sicurezza.

Inizia in modalità di proposta senza esecuzione: l’applicazione può generare e mostrare risultati, ma non applicare modifiche. Poi abilita la conferma per un gruppo ristretto o per una classe limitata di operazioni, assegnando chiaramente le responsabilità. Definisci in anticipo quali condizioni impongono di fermare la funzione, chi può attivarla o disattivarla e come comunicare il cambiamento agli utenti.

Il rollback deve essere una capacità operativa concreta. Prevedi un interruttore che disattivi la generazione o l’esecuzione delle azioni senza modificare i dati esistenti, un percorso convenzionale per completare l’attività e una procedura per esaminare le proposte in sospeso. Se la distribuzione avviene tramite un’API o una pipeline, separa la distribuzione tecnica dalla pubblicazione agli utenti e verifica quale fase consente di ricevere traffico. I dettagli dipendono dalla piattaforma specifica.

Prima di estendere l’accesso, documenta i limiti noti, i permessi effettivi, il trattamento dei dati e le istruzioni del provider applicabili alla configurazione scelta. Le guide di AESIA indicano esplicitamente che i loro documenti sono raccomandazioni non vincolanti e soggette a revisione; usale come orientamento contestuale, non come parere legale automaticamente applicabile a ogni integrazione.

7. Modello per la revisione architetturale

Prima di implementare, rispondi per iscritto a domande verificabili nel codice, nella configurazione o nella documentazione aggiornata. Non considerare risolta una voce solo perché il provider annuncia una capacità generale: verifica che sia disponibile nel prodotto, nella versione, nella regione e nel livello di servizio che utilizzerai.

Includi nella revisione l’interfaccia esatta dell’adattatore, lo schema della risposta, le regole deterministiche, l’identità di ciascun componente, le risorse accessibili e il percorso dalla conferma alla scrittura. Registra anche gli scenari di errore, il comportamento dei tentativi ripetuti, il metodo per rilevare i duplicati, le condizioni di concorrenza e il meccanismo di disattivazione della funzione.

Tieni separati i fatti documentati, le decisioni di progettazione e le ipotesi ancora da verificare. Per esempio, il fatto che una piattaforma supporti chiamate a funzioni non dimostra che una funzione specifica possa essere autorizzata in modo indipendente. Una guida che descrive meccanismi di autenticazione non dimostra che siano attivi nella tua distribuzione. Verifica ogni dettaglio nella documentazione primaria pertinente e nella configurazione effettiva.

Per approfondire i concetti, consulta la guida di apprendimento sull’IA, la guida ai modelli locali e le schede del glossario dedicate a chiamata agli strumenti, principio del minimo privilegio, output strutturato e iniezione di prompt. Questi collegamenti interni devono portare alle pagine di Inferama e integrare questa guida; non sostituiscono la documentazione del provider scelto.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.