Skip to main content
La Knowledge Base è l’insieme di documenti che l’AI legge per rispondere agli ospiti: codice WiFi, indirizzo, regole della casa, istruzioni lockbox, listino prezzi. Deve essere organizzata strettamente per appartamento, ogni listing ha la propria KB isolata. Un errore di scoping fa sì che l’AI risponda a un ospite con le informazioni di un altro appartamento, causando un leak di dati che può avere conseguenze operative gravi (ospite che si presenta alla porta sbagliata, codice di accesso condiviso con il soggetto sbagliato, tariffe errate).

​
Regola non negoziabile: per-listing, mai globale

Un nodo KB senza entity_ids viene recuperato in ogni conversazione, per ogni appartamento dello studente. Questo significa che se crei un articolo globale (senza scope), l’AI lo usa come contesto per qualsiasi ospite, indipendentemente dall’appartamento che sta cercando. Il risultato è un leak garantito: l’ospite del Loft Navigli A riceve le istruzioni di accesso del Loft Navigli B, o il WiFi di un appartamento compare nella risposta per un altro.
KB senza scope = leak garantito. Non creare MAI un articolo KB a livello globale senza entity_ids sulla directory. Anche un singolo articolo globale compromette l’isolamento dell’intero workspace.

​
Come si fa lo scoping corretto

1

Crea una cartella per ogni appartamento in Conduit

Nella sezione Knowledge Base del workspace Conduit dello studente, crea una nuova cartella (directory) per ciascun appartamento. Assegna alla cartella gli entity_ids: [listingId] corrispondenti al listing_id Kross dell’appartamento. Questo è il punto più critico: senza questo campo, la directory è globale.
2

Crea gli articoli DENTRO la cartella scopata

Tutti gli articoli (WiFi, indirizzo, regole, lockbox, listino) devono essere creati all’interno della cartella, non al livello radice del workspace. Gli articoli dentro una cartella scopata ereditano automaticamente lo scope della cartella, non devi impostare entity_ids a livello di singolo articolo.
3

Si può collegare anche il singolo articolo

Dal 10/09/2026 Conduit collega all’appartamento anche il singolo articolo, non solo la cartella (verificato: una ricerca fatta come un appartamento restituisce solo il suo articolo, una fatta senza appartamento non lo restituisce). Resta più ordinato lavorare per cartella, ma un articolo collegato al suo listingId è davvero isolato. Quello che conta è che nessun dato di un singolo appartamento resti senza collegamento.
4

Verifica: testa una domanda ospite cross-appartamento

Dopo ogni modifica alla KB, simula una conversazione ospite per l’appartamento appena configurato e verifica che la risposta contenga solo le informazioni di quell’appartamento. Poi testa la stessa domanda simulando un ospite di un altro appartamento: la risposta non deve contenere dati del primo. Se c’è cross-contaminazione, il problema è quasi sempre una directory senza entity_ids.

​
Codici di accesso: uno per casa, mai una tabella unica

I codici (cassetta chiavi, portone, cancello) sono il dato più delicato della KB: se i codici sono simili fra loro, una fuga apre tutte le case.
  • Mai un documento unico con i codici di tutte le case, nemmeno in una cartella riservata al team: basta spostarlo o cambiare un permesso perché diventi leggibile da qualunque ospite.
  • Un documento per casa («Codice accesso – nome casa»), collegato solo all’annuncio di quella casa. Se deve restare interno al team, va in una cartella riservata all’agente del team.
  • Quando si trova una tabella unica: si creano i documenti per casa, si verifica con una ricerca fatta come due appartamenti diversi, poi si svuota la tabella (non si cancella: resta il segnaposto che spiega dove sono finiti i codici).
  • Le case senza codice nella tabella non si riempiono a intuito: si chiede allo studente.

​
Tipi di nodo KB

Conduit supporta tre tipi di nodo KB. Scegli il tipo corretto in base al contenuto che stai inserendo.
Usa il tipo rule con parsimonia: ogni nodo rule viene caricato in ogni risposta dell’agente, aumentando il consumo di token. Riservalo alle policy che devono essere sempre rispettate, non al contenuto informativo generico.

​
Bridge dal Notion

Il registro appartamenti su Notion ospita il contenuto degli appartamenti dello studente (WiFi, indirizzo, regole, accessi). Il bridge Notion → Conduit sincronizza automaticamente quel contenuto nella KB, creando e aggiornando le cartelle per-listing con lo scope corretto — per gli appartamenti già presenti in anagrafica, che nasce dalle listing di Conduit e non da Notion (vedi Notion · Anagrafica canonica). Usare il bridge evita la doppia digitazione: quando lo studente aggiorna il WiFi o l’indirizzo su Notion, la modifica si propaga in KB senza intervento manuale del team. Ogni cartella creata dal bridge ha già gli entity_ids correttamente impostati sul listing_id Kross corrispondente. → Per configurare il bridge: Bridge Notion → Conduit
Dopo ogni modifica alla KB, sia manuale che via bridge, esegui sempre una domanda di test per verificare che la risposta arrivi dall’appartamento corretto. Non dare mai per scontato che lo scoping funzioni senza verifica diretta.