Dati e permessi prima di un assistente AI interno

Un assistente interno deve cercare procedure e ticket. I documenti sono distribuiti fra cartelle condivise e repository con permessi nati per esigenze diverse. La verifica risponde a «Che cosa deve essere governato prima di collegare un assistente alle fonti interne?» per il compito «separare accesso tecnico, autorizzazione e utilità del contenuto», con un owner e un esito osservabile.

Un assistente interno non deve ereditare un accesso tecnico universale: ogni risposta deve rispettare i permessi dell’utente e la governance della fonte. Tratta test di accesso negativo, rimozione e log come requisiti di prodotto, non come configurazione successiva.

Per «Che cosa deve essere governato prima di collegare un assistente alle fonti interne?» le precondizioni partono da «proprietario di ogni fonte». Una risposta vaga diventa «inventariare fonti e owner», con owner, evidenza richiesta e data di riesame.

Caso isolato: «utenti autorizzati a vedere il contenuto». Operazione osservata: «inventariare fonti e owner». Deviazione forzata: «mantenere documenti obsoleti nell’indice».

Criterio di firma: «utenti autorizzati a vedere il contenuto». Un esito orale o non ripetibile lascia aperta la voce. Perimetro della prova: «separare accesso tecnico, autorizzazione e utilità del contenuto».

Controprova: «ciclo di aggiornamento e rimozione». Arresto: «dare al modello un accesso più ampio dell’utente». Passo ammesso dopo il recupero: «escludere contenuti non governati». Verbale finale: «Che cosa deve essere governato prima di collegare un assistente alle fonti interne?»

Differenza decisiva: «Tratta test di accesso negativo, rimozione e log come requisiti di prodotto, non come configurazione successiva». Regola di chiusura: «La checklist è completa soltanto quando dimostra anche ciò che l’assistente non può vedere, ricordare o restituire».

La prova deve lasciare artefatti revisionabili, non soltanto impressioni. Il riferimento «ACL propagate al retrieval, document owner e cancellazione dall’indice» va controllato su casi normali e su almeno un caso costruito per fallire.

Verificare che un’azione riesca non dimostra che venga negata nel contesto sbagliato; l’evidenza da conservare è «dare al modello un accesso più ampio dell’utente». I casi seguenti devono produrre un blocco comprensibile o una revisione, mai un successo silenzioso; il caso operativo si verifica con «inventariare fonti e owner».

Alla chiusura servono: elenco dei casi, versione di dati e configurazione, esito per criterio, errori classificati e decisione dell’owner; il controllo associato riguarda «testare accessi negativi oltre a quelli positivi». Questo pacchetto permette di ripetere la valutazione dopo una modifica.

Le evidenze devono distinguere qualità del percorso e impatto dell’errore; nel perimetro descritto conta «dare al modello un accesso più ampio dell’utente». Una media positiva non può compensare un singolo comportamento non autorizzato o irreversibile; il controesempio viene cercato in «inventariare fonti e owner».

La checklist è completa soltanto quando dimostra anche ciò che l’assistente non può vedere, ricordare o restituire. La scelta può essere pass, fail oppure una riduzione del perimetro: tutti e tre gli esiti sono utili se derivano dagli stessi criteri dichiarati prima della prova; la decisione resta collegata a «ACL propagate al retrieval, document owner e cancellazione dall’indice».

La checklist è completa soltanto quando dimostra anche ciò che l’assistente non può vedere, ricordare o restituire. Prima del pass, allegare l’esito di «testare accessi negativi oltre a quelli positivi», il controllo «presenza di dati personali o riservati» e il test negativo «registrare dati sensibili senza necessità»; ciò che manca resta fuori dal perimetro approvato.