Il retrieval semantico può individuare il contenuto più vicino alla domanda senza stabilire se sia anche la fonte corretta su cui costruire la risposta. Una policy approvata, una guida operativa locale e una procedura superata possono risultare tutte pertinenti, pur avendo autorevolezza e ambiti di applicazione molto diversi. Per questo rendiamo espliciti versione, periodo di validità, ownership, stato di approvazione, contesto organizzativo e condizioni di accesso. Distinguiamo le fonti che possono sostenere una risposta da quelle utilizzabili soltanto come supporto e dai contenuti che devono rimanere esclusi. Non tutto ciò che è disponibile in un repository deve entrare nella knowledge base. E non tutte le fonti incluse devono avere lo stesso peso.

Un documento può essere aggiornato, accessibile e pertinente, ma non per questo sicuro. Contenuti provenienti da fonti non controllate possono includere istruzioni manipolate capaci di interferire con il comportamento del sistema. Informazioni alterate o introdotte deliberatamente nella knowledge base possono condizionare il retrieval e influenzare la risposta senza compromettere direttamente il modello. La sicurezza non può quindi fermarsi all’autenticazione degli utenti e ai permessi applicati al repository. Deve comprendere la provenienza e l’integrità delle fonti, i controlli sui contenuti acquisiti, la separazione tra documenti recuperati e istruzioni di sistema e la verifica dell’output prima che venga utilizzato da applicazioni o processi a valle. In produzione deve essere possibile ricostruire sia i contenuti utilizzati sia quelli esclusi, segnalati come sospetti o bloccati dai controlli di sicurezza.

Non tutte le richieste devono produrre lo stesso tipo di risultato. Quando le evidenze sono solide e il rischio è contenuto, il sistema può formulare direttamente la risposta e indicare le fonti utilizzate. Nei contesti più delicati può limitarsi a presentare le evidenze, chiedere un chiarimento o coinvolgere il responsabile del processo. Se le fonti sono insufficienti, contrastanti o non adeguate alla richiesta, il comportamento corretto può essere non rispondere. Queste condizioni devono essere definite prima del go-live, non possono dipendere dal livello di sicurezza con cui il modello formula il testo.

Una risposta può essere chiara e ben costruita anche quando parte dalla fonte sbagliata. Allo stesso modo, il sistema può recuperare il documento corretto e interpretarlo in modo impreciso. Per individuare la causa di un errore, valutiamo separatamente la qualità delle fonti recuperate e quella della risposta generata. La soluzione viene verificata su un insieme versionato di domande, fonti attese, eccezioni, tentativi di manipolazione e situazioni in cui dovrebbe astenersi dal rispondere. Questo riferimento permette di misurare l’effetto di modifiche ai contenuti, ai modelli e alla pipeline, identificando eventuali regressioni prima che incidano sul servizio. Le metriche tecniche vengono quindi collegate ai risultati del processo: riduzione dei tempi, diminuzione delle escalation, minori rilavorazioni, adozione e costo delle attività completate correttamente.

La scelta tra una piattaforma, l’estensione dello stack esistente o la realizzazione di componenti dedicati viene effettuata sulla base del comportamento che la soluzione deve garantire. Sicurezza, integrazione, volumi documentali, frequenza degli aggiornamenti, prestazioni, residenza dei dati, sostituibilità dei componenti e costo operativo vengono valutati prima di definire la target architecture. La tecnologia è una conseguenza dei requisiti del servizio, non il punto di partenza del progetto.