I meccanismi dietro la riservatezza e la sicurezza.

Questa pagina descrive i meccanismi dietro ogni affermazione che compare altrove nel sito. Ogni sezione nomina un meccanismo e indica dove si trova nel pipeline. Nulla di tutto questo e una politica priva di implementazione sottostante.

In sintesi: la voce del partecipante e sostituita con una voce sintetica prima che qualsiasi cosa venga memorizzata. Ogni citazione che esce dal sistema e qualcosa che la persona ha effettivamente detto. L'intervistatore e sottoposto ad audit per ogni conversazione. Il percorso dei dati applica l'isolamento del tenant a livello di riga e di nodo. Il cliente possiede il tenant. Anthropic ed ElevenLabs operano sotto contratti di non-addestramento e non-conservazione. In conformita con la politica d'uso e i requisiti di conformita di Anthropic, non lavoriamo su applicazioni militari e non aiuteremo nessuno a re-identificare un partecipante.

L'audio del partecipante passa attraverso ElevenLabs in Zero Retention Mode, che elimina la copia lato fornitore al termine della chiamata. La rimozione delle entita avviene prima che la trascrizione lasci il perimetro del cliente. Un proxy all'interno del tenant del cliente rimuove nomi oscurati, evocazioni e identificatori di persone rispetto a un elenco che il cliente controlla. Nexa non detiene quell'elenco e non vede la trascrizione originale. Il confine e applicato dal fatto che il cliente possiede il proxy, cosicché il nostro stesso personale resta al di fuori di esso.

La conservazione dell'audio e impostata per ogni distribuzione. Un cliente che conduce un audit pubblico o un concorso mantiene la registrazione, perche quel caso d'uso ne ha bisogno. Un cliente la cui politica vieta la voce conservata viene configurato in modo che l'audio non raggiunga mai alcun sistema che operiamo. In quella configurazione, la re-identificazione tramite voce non ha nulla su cui lavorare, perche nessuna registrazione e stata mantenuta.

Quando si desidera un record audio anonimizzato, la trascrizione pulita viene rigenerata come nuova voce sintetica. Lo stesso design di minimizzazione dei dati opera in configurazioni di livello HIPAA senza lavoro di conformita specifico sul livello di acquisizione.

Ogni citazione che esce dal sistema e una sottostringa letterale di un vero turno USER di un vero colloquio. Un filtro deterministico lo verifica prima della persistenza. Quando il filtro rileva una citazione inventata, la elimina anziche riscriverla. Un controllo separato di contaminazione incrociata verifica che gli output di mappatura delle percezioni non contengano entita che il partecipante non ha mai menzionato. Quando il controllo scatta, i campi interessati vengono azzerati e contrassegnati.

I livelli di visualizzazione puliti, abbreviati e tradotti sono tutti derivati dall'originale verbatim. Nessun passaggio introduce nuove parole. Il verbatim nella lingua sorgente non viene mai tradotto. Rimane nella sua lingua originale come registro di provenienza.

Ogni affermazione in ogni report e collegata alla trascrizione che l'ha prodotta tramite un identificatore di chunk nella forma transcript_id / turn_id / sentence_id. Il collegamento e sempre presente, per ogni conversazione, senza campionamento. La stessa proprieta vale per cinquanta colloqui come per cinquantamila.

Il nostro agente di conversazione IA e costruito con un albero di comportamento, regole di applicazione del protocollo, domini di conoscenza e guardrail per agente, tutti definiti in una specifica con versioning. L'audit viene eseguito separatamente, da un agente di audit indipendente che valuta l'agente di colloquio su sei KPI di protocollo per ogni singolo colloquio: consegna del contesto, copertura del profilo, copertura della percezione del marchio, assenza di domande ripetute, neutralita e chiusura appropriata.

La specifica di protocollo che configura l'agente e lo stesso documento che l'auditor usa come riferimento. Entrambe le parti si basano sulla stessa fonte, in modo che l'audit non possa silenziosamente discostarsi dal protocollo che sta misurando. Una conversazione con esecuzione scadente vede la sua intelligence ridotta nel punteggio composito.

Non abbiamo trovato un'altra piattaforma nella categoria che sottoponga il proprio strumento ad audit per conversazione.

Prima che un agente raggiunga un partecipante reale, Claude assume il ruolo di un partecipante simulato ed esegue la nostra libreria di attacchi avversariali contro l'agente di colloquio su larga scala. La libreria copre la confusione deliberata, l'iniezione di dati falsi, il seppellimento dei segnali e gli attacchi di confusione del marchio. L'agente deve rilevare la manipolazione e far emergere il segnale reale. La libreria viene distribuita con la piattaforma. Il cliente la estende con i pattern specifici del suo dominio.

I fallimenti gravi bloccano la distribuzione. I fallimenti lievi diventano monitor di produzione. Per ogni pattern di fallimento lieve, il sistema verifica se la stessa classe di fallimento emerge nelle conversazioni reali. Quando accade, qualsiasi intelligence ricondotta a quel momento viene esclusa dall'output compilato.

Quando un esperto del dominio del cliente indica al sistema che un'interpretazione e errata nel suo contesto, il sistema trova ogni conversazione nel corpus che corrisponde a quel contesto e le rielabora. Rianalizza, ricontrassegna e ripesa ogni corrispondenza. La correzione dell'esperto si propaga all'intero corpus storico. La pista di audit conserva ogni interpretazione precedente accanto alla nuova, in modo che nessuna delle due vada persa.

Esistono due superfici per effettuare una correzione. La prima e un'annotazione nel pannello di controllo: l'esperto vede l'interpretazione dell'IA, il verbatim sorgente e la metodologia, e annulla dove necessario. La seconda e l'agente di colloquio direttamente, in voce. L'esperto parla all'agente come a una superficie di coaching, e il raffinamento entra nello stesso ciclo di correzione.

Lo stesso ciclo calibra le emivite. I fatti di percezione del marchio decadono in settimane. I fatti sulle lacune formative decadono solo quando il catalogo di formazione cambia. Distribuiamo una base calibrata su due anni di lavoro. L'Expert-in-the-Loop la regola per il settore verticale.

La sicurezza e applicata dal percorso di accesso ai dati stesso. Non esiste un livello di policy separato tra la richiesta e i dati. Ogni ticket di sessione porta uno scope di sicurezza. Tale scope si propaga negli strumenti MCP che il LLM chiamante puo vedere, nei nodi del grafo che puo attraversare, nelle righe del repository di fatti che puo leggere e nei chunk verbatim che si risolvono quando cita.

Una richiesta non autorizzata non viene rifiutata con un errore. Al contrario, i dati non autorizzati sono invisibili al chiamante. Un attore malintenzionato all'interno di uno strumento privilegiato vede i dati che il suo scope consente. Non puo vedere oltre, e non ha alcun segnale che qualcosa sia stato nascosto.

In concreto: un utente Excel chiama il nostro MCP con il suo ticket di sessione OAuth. Il ticket e coniato con il suo scope. Da tale scope, il sistema filtra l'elenco degli strumenti visibili al LLM, filtra l'attraversamento del grafo a livello di nodo, filtra le letture Postgres a livello di riga e risolve le citazioni solo per i chunk in scope.

Ogni distribuzione opera all'interno del tenant del cliente. Il substrato predefinito e Cloudflare, ovvero l'account Cloudflare del cliente. Noi lo configuriamo. Gli appartiene. AWS, Azure e on-premise seguono lo stesso modello su un fornitore diverso. Il pipeline di acquisizione, le trascrizioni pulite, il livello di conoscenza bi-temporale (costruito sul modello temporale Zep e mem0, con Apache AGE su Postgres come implementazione del grafo), il repository di fatti, i pannelli di controllo e gli agenti IA risiedono tutti su un'infrastruttura che il cliente controlla.

Lo schema e aperto. Il corpus e portabile. Il modello bi-temporale consente al cliente di riprodurre lo stato del proprio corpus a qualsiasi data passata, confrontare con oggi e verificare l'evoluzione della metodologia nel tempo. Se Nexa Intelligence dovesse chiudere domani mattina, il cliente continua a operare senza interruzione.

Il corpus arricchito del cliente e il prodotto. Non alimenta l'addestramento di modelli. Ogni piano utilizza il contratto di non-addestramento di Anthropic per impostazione predefinita. Enterprise utilizza inoltre il contratto di non-conservazione: nessun dato cliente LLM persiste presso il fornitore del modello oltre la richiesta. La voce opera in non-conservazione per ogni piano e ogni livello, con ElevenLabs.

La distinzione e importante. La voce e in non-conservazione per ogni account. Il livello LLM e in non-addestramento per ogni account e in non-conservazione per Enterprise. Tutte queste proprieta sono in contratti firmati prima che i dati fluiscano.

Non rifiutiamo le decisioni strategiche che i nostri clienti prendono sulla base di intelligence aggregata. Chiudere punti vendita, ristrutturare unita operative, riprogettare ruoli: queste sono decisioni che l'operatore era gia in posizione di prendere. Il corpus esiste per informarle. Non editorizziamo l'utilizzo dell'intelligence che il cliente ha pagato per acquisire.

La re-identificazione individuale e una questione separata. Il sistema non e stato costruito per recuperare chi ha detto cosa. Recuperarla sarebbe un fallimento architetturale e non figura in nessun elenco di casi d'uso consentiti.

Le cose che rifiutiamo:

• ×Applicazioni militari.
• ×Sorveglianza di individui nominati. Qualsiasi scope OAuth che lo consentirebbe e rifiutato prima che i dati fluiscano.
• ×Re-identificazione dei partecipanti. La cascata di sicurezza e la catena di sostituzione vocale non lasciano alcun handle utilizzabile per tentarla.
• ×Vendita di trascrizioni grezze a terze parti.
• ×Addestramento di LLM di terze parti su dati dei clienti.
• ×Aumento con partecipanti sintetici presentato come acquisizione reale.

Nexa Intelligence e stato costruito all'interno di ACET, l'incubatore tecnologico dell'Universite de Sherbrooke. Il protocollo di interazione comportamentale dietro il nostro agente di conversazione IA e stato sviluppato in collaborazione con il programma di ricerca CEL, basato su uno studio comportamentale di 4.000 colloqui sulla dinamica conversazionale umano-IA.

Ogni proprieta di questa pagina deriva da una specifica scelta di design. Il pipeline vocale non ha un posto dove conservare un'impronta. Il filtro delle allucinazioni opera inline sulla trascrizione pulita. Il registro di audit dell'arricchimento e append-only. L'audit dell'intervistatore opera come passo di primo livello nel protocollo. La cascata di sicurezza vive nel percorso di accesso ai dati. Il sistema e stato costruito in questo modo fin dalla prima distribuzione.