Un assistente di conoscenza che non esce mai dal vostro edificio.

Tutti sono stati in quella riunione. Qualcuno mostra un'AI che risponde a domande sulle policy di un'azienda, in linguaggio naturale, con citazioni, e la sala si protende in avanti. Poi qualcuno fa la seconda domanda: quindi i nostri contratti li carichiamo dove, esattamente? E la sala si ritrae.

Entrambe le reazioni sono corrette. Il desiderio è reale: la conoscenza di un'azienda vive in contratti, ticket, wiki, fascicoli e codice, e quasi nulla di tutto questo è interrogabile senza che un essere umano vada a scavare. Anche lo stallo è reale: quella stessa conoscenza è la cosa più sensibile che l'azienda possiede, e «mandiamola a un'API» non è una frase che l'ufficio legale firmerà. La parte che quasi nessuno nella sala conosce è che le due cose non sono più in conflitto. L'intera pipeline che rende interrogabili i documenti può girare su una macchina, in un rack, sotto una giurisdizione, senza che nulla ne esca.

Cos'è davvero un assistente di conoscenza

Tolta l'adorazione degli acronimi, il meccanismo è semplice. I vostri documenti vengono divisi in passaggi e codificati in embedding, impronte numeriche del significato. Quelle impronte vivono in un vector database. Quando qualcuno fa una domanda, la domanda viene codificata allo stesso modo, il database trova i passaggi dal significato più vicino e il modello risponde a partire da quei passaggi, citando ciò che ha usato. Il settore lo chiama retrieval-augmented generation. La parte importante è ciò che implica: il modello non memorizza il vostro archivio. La pipeline lo consulta, dal vivo, a ogni domanda.

Il che significa che la pipeline è la superficie sensibile. Non solo il modello: i documenti che entrano, gli embedding ricavati da essi, ogni domanda che chiunque pone, ogni risposta che torna, e i log di tutto questo. Decidete dove vive la pipeline e avete deciso dove vive la conoscenza della vostra azienda.

La pipeline è il problema di privacy

Percorrete la ricetta cloud standard per questa funzione e contate le terze parti. I documenti vengono codificati attraverso un'API di embedding in hosting. I vettori vanno in un servizio di vector database gestito. Le domande passano per un'altra API verso un modello in hosting. I log si accumulano a ogni fermata, sotto la policy di conservazione di ciascun provider. Quattro parti esterne, ciascuna una risposta che ora dovete all'auditor.

Organizzazioni che non caricherebbero mai un contratto lo spingono volentieri attraverso un'API di embedding, perché «sono solo vettori». Gli embedding non sono numeri anonimi. Sono una codifica con perdita del significato del testo, costruita apposta perché quel significato si possa cercare. Un vector database popolato dal vostro archivio è il vostro archivio, trasformato. Trattate la sua giurisdizione, la sua tenancy e i suoi controlli di accesso esattamente come trattate i documenti stessi, perché funzionalmente lo sono.

Una volta vista la pipeline per intero, la risposta single-tenant smette di essere una preferenza e diventa il progetto. Una macchina contiene i documenti, gli embedding, il modello, le domande, le risposte e i log. L'elenco delle terze parti che vedono un token ha una sola voce: nessuno. Quando l'auditor chiede chi altro può vedere tutto questo, quella è l'intera risposta, ed è un pomeriggio migliore di un diagramma dei flussi di dati con cinque loghi sopra.

Cosa significa il livello gestito

Dimensioniamo la GPU in modo onesto rispetto al modello e al corpus (la logica di abbinamento nella pagina GPU Servers è la versione pubblica di quella conversazione), distribuiamo e mettiamo a punto lo stack di serving dietro un endpoint compatibile con OpenAI, affianchiamo il modello di embedding e il vector database e teniamo in funzione il tutto. Il lavoro di integrazione del vostro team è lungo due voci: puntare l'ingestione ai vostri documenti e chiamare l'endpoint. Le battaglie di compatibilità, il pinning dei driver, i compromessi di quantizzazione avvengono nel nostro tempo, che è l'intero senso dell'accordo. Il nostro servizio GPU gestito definisce il perimetro ingegneristico.

Per chi è davvero

I settori si ordinano da soli in base a ciò che temono. I team legali, perché il segreto professionale è esistenziale e un contratto non può toccare un'API di terzi. La sanità, perché un incidente da notificare è l'incubo e il contesto dei pazienti passa attraverso i prompt. Fintech e assicurazioni, perché la domanda del regolatore deve avere una risposta con un nome sopra. Il settore pubblico, perché la sovranità è sempre più un requisito di gara che una preferenza. E i team di prodotto che costruiscono su open weights, perché una base di conoscenza che addestra il modello di qualcun altro è un fossato con un buco. Paure diverse, una sola architettura.

E il confine onesto, perché è l'abitudine di casa: se il vostro corpus è piccolo, a basso volume e davvero non sensibile, un'API in hosting è spesso la risposta ragionevole e ve lo diremo quando lo chiederete. Questo post è per l'archivio che non può andare a terzi. Per quell'archivio, la domanda non è mai stata se l'assistente valga la pena. Era se i documenti fossero al sicuro, e la risposta è smettere di mandarli ovunque.

“Gli embedding non sono numeri anonimi. Sono i vostri documenti, codificati.”