Il registro di consegna che consigliamo per un servizio AI privato

Il Framework per la Gestione del Rischio AI del NIST affronta l'affidabilità attraverso la progettazione, lo sviluppo, l'uso e la valutazione dei sistemi AI.[1] Il periodo operativo merita una propria evidenza. Per un pilota AI privato che passa all'uso routinario, consigliamo un registro di consegna che consenta al team ricevente di identificare l'installazione, comprenderne i limiti e rispondere quando qualcosa smette di funzionare.

Questo è il nostro formato di consegna proposto, non un rapporto di un'implementazione cliente verificata. Integra le informazioni tecniche e sui confini dei dati nel centro di fiducia Software Tailor. Ogni organizzazione dovrebbe assegnare le responsabilità al proprio modello operativo.

Nominare il proprietario ricevente e il lavoro consentito

Iniziare con un ruolo nominato che accetta la responsabilità del servizio. Registrare il suo canale di contatto e l'accordo alternativo quando il proprietario abituale non è disponibile. Un indirizzo di supporto del fornitore è utile, ma l'organizzazione ha anche bisogno di qualcuno che possa decidere se il servizio deve continuare a funzionare durante un incidente.

Descrivere le attività approvate per l'uso routinario e quelle ancora confinate al pilota. Includere i gruppi autorizzati a utilizzare il servizio e gli orari di funzionamento previsti. Un problema irrisolto del pilota dovrebbe rimanere visibile con un proprietario e una data decisionale pianificata; non dovrebbe scomparire perché lo stato dell'installazione è cambiato.

Trasportare le ipotesi di capacità e scadenza usate nella decisione di acquisto. Questo dà al team ricevente un motivo per indagare quando il carico di lavoro cambia.

Preservare la configurazione effettivamente verificata

Registrare le build dell'applicazione e del server, il runtime e il riferimento esatto del modello. Conservare la fonte dell'installazione e la configurazione rilevante attraverso il normale processo di documentazione controllata dell'organizzazione. Archiviare le credenziali tramite il processo di gestione delle credenziali, con riferimenti nel registro di consegna anziché valori segreti copiati.

Le schede modello di Hugging Face forniscono documentazione per usi, limitazioni e valutazioni del modello.[2] Collegare la scheda e la revisione rilevanti, quindi aggiungere i risultati locali del pilota. La descrizione dell'editore e i risultati dei test dell'organizzazione rispondono a domande diverse; il team ricevente dovrebbe poter localizzare entrambi.

Quando il sistema ha fornitori esterni opzionali, registrare quali percorsi sono abilitati. Descrivere il confine dati previsto per ogni percorso e chi può approvare una modifica. Evitare un'etichetta generica come “locale” quando la configurazione operativa richiede una spiegazione più precisa.

Assegna la responsabilità per azioni e permessi

Per un'integrazione agente, allega l'elenco degli strumenti concordati e l'identità utilizzata da ogni connessione. OWASP raccomanda di limitare le capacità e i permessi dell'agente e di applicare l'autorizzazione nei sistemi a valle.[3] La nostra proposta di consegna trasforma questa indicazione in una questione di proprietà: chi può rivedere o revocare ogni concessione?

Includi l'esito dei controlli di integrazione tool-call, con eventuali restrizioni residue. Distingui il permesso di proporre un'operazione dal permesso di eseguirla. Se una persona deve approvare un'azione, identifica dove avviene tale approvazione e come viene gestita un'approvazione fallita o abbandonata.

Il proprietario ricevente dovrebbe anche sapere quali registri diagnostici esistono, chi può accedervi e per quanto tempo vengono conservati. Usa la policy configurata e un esempio verificato. Non dedurre che i prompt siano assenti da ogni componente connesso solo perché un componente ha un design di audit senza contenuti.

Esegui una simulazione di interruzione prima della consegna

Scegli un'interruzione concordata e non distruttiva in un ambiente di test. Fai seguire al team ricevente le istruzioni di recupero mentre l'implementatore originale osserva. Registra le informazioni mancanti che incontrano e aggiorna le istruzioni prima della firma.

L'esercizio dovrebbe stabilire come riconoscere il problema, chi può fermare il lavoro interessato e come verificare il servizio recuperato. Se il rollback fa parte del piano, identifica la versione conservata e il punto in cui il rollback è appropriato. Mantieni le ipotesi di recupero non testate etichettate come tali.

Per una discussione su un servizio Software Tailor, un record di configurazione oscurato e una descrizione chiara del passaggio fallito sono più utili di un'affermazione non supportata che l'intero sistema sia guasto. La consegna dovrebbe spiegare come raccogliere tali informazioni tramite il percorso di supporto approvato dall'organizzazione.

Rendi la firma un documento utilizzabile

Concludi con l'accettazione del proprietario ricevente, la data e gli elementi irrisolti. Nomina i cambiamenti che dovrebbero innescare una revisione, come un modello diverso, un nuovo connettore o un compito consentito più ampio. Questa è una disciplina operativa proposta, non uno schema di certificazione.

Il documento è pronto quando il team ricevente può usarlo per prendere una decisione senza dover ricostruire il progetto pilota dalla memoria.

Riferimenti

[1] NIST. AI Risk Management Framework. Framework 1.0 rilasciato nel 2023; guida di riferimento. Accesso 2026-09-26.

[2] Hugging Face. Schede Modello. Guida permanente alla documentazione del modello. Consultato il 26-09-2026.

[3] Progetto di Sicurezza OWASP Gen AI. LLM06:2025 Agenzia Eccessiva. Edizione 2025. Consultato il 26-09-2026.