Trust center. Le risposte prima della chiamata.

1. Il questionario di sicurezza, già compilato

Queste sono le domande che ci arrivano da chi valuta Userbot per la sicurezza o per la privacy, con la risposta corta. Ogni voce è ripresa per esteso nelle sezioni che seguono. Dove la risposta è "no", la trovate scritta "no": serve a farvi sapere cosa mettere sul tavolo prima del contratto, non dopo il rollout.

2. Dove sono i dati

L'infrastruttura è nell'Unione Europea, su OVH e AWS. I dati vivono in tre depositi: la base dati (conversazioni, agenti, progetti, impostazioni, registro), l'archivio dei file e l'indice di ricerca.

Sull'indice di ricerca conviene essere espliciti: oltre alla forma numerica conserva anche il testo dei passaggi così com'è, perché serve a mostrare la citazione sotto la risposta. È la domanda che ci fa sempre chi valuta la conformità, quindi la mettiamo per iscritto: eliminando il documento spariscono entrambe le copie.

Cifratura. Dischi cifrati, traffico su HTTPS, password conservate solo in forma cifrata e non reversibile. La chiave privata di una passkey non lascia mai il dispositivo. Una chiave API si legge in chiaro una sola volta: dopo resta solo il suo hash.

Conservazione. Le chat restano per sempre, oppure 30, 90, 180 o 365 giorni se l'area di lavoro imposta una politica. La sessione di accesso dura 30 giorni. Per il Registro di audit la durata la sceglie l'area di lavoro, con 90 giorni di default.

Cancellazione. Le eliminazioni dentro il prodotto sono immediate e definitive: non esiste un cestino da cui recuperare, e non esiste una copia che resta indietro nell'indice. A fine contratto la cancellazione completa avviene entro 30 giorni: sezione 13.

Isolamento. Ogni azienda lavora nella propria area di lavoro, isolata dalle altre. Le Mini App generate girano in una sandbox isolata dall'origine, e le chiavi dei modelli e delle integrazioni restano lato server: nel browser non c'è nessuna chiave da intercettare.

3. Cosa esce verso i fornitori dei modelli AI

Le richieste ai modelli passano da un unico punto di uscita, e da lì raggiungono i fornitori dei modelli AI attraverso Azure, Bedrock ed Eden AI.

Cosa arriva al fornitore del modello AI: il messaggio, la parte pertinente della conversazione, i passaggi recuperati dalla ricerca e le istruzioni in vigore. Non l'archivio dei documenti dell'azienda.

Cosa succede una volta arrivato. È attiva la configurazione zero data retention: i contenuti non vengono conservati, nemmeno per il monitoraggio degli abusi. Vale inoltre una clausola che vieta l'addestramento sui vostri contenuti. Il testo della clausola cambia da un fornitore del modello AI all'altro: se vi serve verbatim per il fascicolo, è nel Security Pack e nell'elenco dei sub-responsabili (sezione 15).

Il catalogo comprende, oltre ad Auto, la scelta automatica del modello, modelli tutti etichettati "Ospitato in UE". Accesi di partenza in un'area di lavoro nuova: GPT-OSS 120B, GPT-6 Astra, GPT-5.6 Terra, GPT-5.6 Luna, Claude Opus 5, Claude Sonnet 5, Claude Haiku 4.5, Gemini 2.5 Pro, Gemini 3.8 Flash e Gemini 3.5 Flash-Lite. Li accende un amministratore: GPT-5.6 Sol, GPT-5.4, GPT-5.4 mini, Claude Fable 5.1, Gemini 3.5 Flash, Mistral Large 3, Mistral Medium 3.5, Mistral Medium Latest, Mistral Small 4, Codestral, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3 Max e Qwen3.5 Flash. I fornitori dei modelli AI dietro al catalogo sono OpenAI, Anthropic, Google, Mistral, DeepSeek e Qwen. Un modello nuovo entra nel catalogo spento: lo accende un amministratore.

Cosa può uscire dall'Unione Europea. Due cose, e solo se le scegliete voi. Le Integrazioni con app esterne del catalogo (per esempio un CRM o un gestionale in cloud) possono trattare dati anche fuori dall'UE quando le collegate. I modelli Global, distinti nel catalogo da quelli ospitati in UE, si usano solo se un amministratore li accende. Tutto il resto, infrastruttura e modelli di partenza, è in UE. Il dettaglio di come si sceglie e si cambia modello è su Model agnostic.

Un'eccezione da dichiarare sempre: se usate un modello vostro, con endpoint e chiave vostri, le richieste vanno lì e valgono le condizioni del fornitore di quel modello, non le nostre.

4. Accesso e identità

Come si entra: passkey (WebAuthn), password, link via email valido 24 ore, oppure SSO Google e Microsoft via OIDC, su tutti i piani. Sui contratti Enterprise si configura l'SSO su misura verso il vostro provider di identità aziendale (Keycloak e simili). La password richiede almeno 8 caratteri, senza regole di complessità né scadenza forzata.

Sessioni: durano 30 giorni fissi. Non si allungano con l'uso e non c'è disconnessione per inattività. Si terminano una per una, non esiste un "esci da tutti i dispositivi", e cambiare la password chiude tutte le altre sessioni attive.

Cosa non c'è oggi: la verifica in due passaggi. Il fattore forte disponibile è la passkey. Se la vostra policy impone un secondo fattore obbligatorio per tutti, è un punto da mettere sul tavolo prima del contratto, non a metà del rollout.

5. Chi vede cosa dentro l'azienda

Niente è condiviso finché non lo condividete. Chat, memoria e file di una chat restano di chi li ha creati.

Su ogni oggetto condivisibile agiscono due leve: l'accesso generale (riservato, oppure esteso a tutta l'area di lavoro) e i permessi espliciti, con ruolo Proprietario, Editor o Visualizzatore. Se una persona rientra in più permessi sullo stesso oggetto, vale il più alto. Sopra a tutto, tre ruoli di area di lavoro: Member, Editor, Admin. Sono questi tre: non esistono ruoli personalizzati, e non esiste un ruolo Auditor che legga il registro senza poter amministrare. Se il vostro modello di controllo lo prevede, va sostituito da una scelta su chi è Admin.

Chi amministra è Proprietario di ogni oggetto condivisibile, comprese le cartelle private: serve a non perdere il lavoro di chi lascia l'azienda, ed è giusto dirlo alle persone. Non accede però alle chat private né alla memoria dei membri. L'eccezione è il Customer Service: lì le conversazioni sono con i clienti finali, quindi chi amministra e chi supervisiona le vedono tutte.

La ricerca dell'AI non esce dall'area di lavoro. Per restringerla ancora c'è una leva sola: collegare una cartella alla conversazione.

Connessione personale: un Agente agisce con l'account di chi lo sta usando e non raggiunge niente a cui quella persona non abbia già accesso in azienda. La connessione condivisa esiste, la autorizza solo chi ha il permesso apposito, e in ogni caso un Agente può solo restringere ciò che l'area di lavoro consente, mai allargarlo.

6. Il nostro accesso ai vostri dati

Un nostro tecnico entra nella vostra area di lavoro solo se lo autorizzate voi. Non è una prassi implicita nel contratto né una porta di servizio: senza la vostra autorizzazione l'accesso non avviene.

E quando avviene, lo vedete voi. L'accesso finisce nel vostro Registro di audit, insieme a tutto il resto: non dovete chiederci un report per sapere che è successo, ce l'avete già dalla vostra parte.

Dentro Userbot vale il principio del minimo accesso: si arriva a quello che serve per il compito in corso, e a niente altro.

7. Regole e Approvazioni

Le Regole si scrivono in italiano, non in codice, e hanno due parti da non confondere. Le linee guida orientano il comportamento: l'AI le segue, ma può interpretarle. Cosa richiede approvazione è invece un vincolo garantito: il compito non parte senza un sì.

Quando una Regola scatta, l'AI si ferma prima di eseguire, lo dice a chi sta chattando e chiede conferma prima di inoltrare la richiesta all'approvatore. Il compito resta sospeso fino alla decisione.

L'ambito di una Regola può essere un gruppo (la scelta normale), una singola persona o tutta l'area di lavoro. Chi rientra in più Regole se le somma: un ambito ristretto non può togliere un obbligo generale. L'approvatore è di norma un Admin, oppure una persona indicata.

Le Regole valgono anche per gli Agenti e per le automazioni, perché sono dell'organizzazione e non della singola chat. Solo un Admin può scriverle, e questo non è delegabile dalla matrice dei permessi. Il racconto esteso, con gli esempi, è su AI Governance.

8. Perimetro dell'area di lavoro

Domini email verificati. Un dominio si rivendica con un record TXT nel DNS: il token vale 7 giorni, il controllo gira circa ogni 15 minuti, e dopo 5 controlli senza record la verifica viene revocata. Chi ha un indirizzo su un dominio verificato entra senza invito, sempre come Member, e occupa un posto.

Restrizioni IP. Sono applicate davvero, non informative: fuori dall'elenco l'area di lavoro risponde "Rete non autorizzata". Si dichiarano IPv4 singoli o in notazione CIDR, e la restrizione vale anche per le chiamate con chiave API. Tre limiti da sapere prima di attivarla: funziona solo su IPv4 (chi si collega in IPv6 viene rifiutato anche dalla sede), non copre il momento dell'autenticazione né le attività programmate, e una lista scritta male chiude fuori tutti tranne chi la sta configurando.

Chiavi API. Sono chiavi dell'area di lavoro: si leggono in chiaro una sola volta, hanno una scadenza predefinita in mesi per le chiavi nuove, e creazione e revoca finiscono nel registro di audit con il nome della chiave. L'API pubblica è OpenAI-compatibile: dettagli su API.

9. Registro di audit

La durata la scegliete voi, il default è 90 giorni. Non si può invece spegnere una categoria: si traccia tutto quello che segue.

Cosa traccia: accessi riusciti e falliti, impostazioni dell'area di lavoro con l'elenco dei campi toccati, impostazioni di prodotto, membri (invito, cambio ruolo con valore prima e dopo, rimozione), ogni casella della matrice dei permessi, integrazioni, chiavi API create e revocate con il loro nome, agenti creati ed eliminati, il download di file caricati da altri, le Mini App. E, quando lo autorizzate, l'accesso di un nostro tecnico (sezione 6).

Cosa non traccia: il contenuto delle conversazioni e la lettura dei documenti. È una scelta, e conviene saperlo prima: il registro dice chi ha cambiato cosa, non cosa si sono detti le persone con l'AI.

Com'è fatta una riga: attore, azione, oggetto, metadati con il valore prima e dopo, IP, browser, data e ora. IP e browser sono valorizzati solo sugli eventi di accesso, vuoti sul resto.

Il registro si consulta dall'area di amministrazione, ed è visibile al ruolo Admin. Oggi non esiste un'esportazione, né come pulsante né come chiamata API: se il vostro SIEM deve ricevere gli eventi, mettetelo tra i requisiti in fase di valutazione.

10. Certificazioni e verifiche indipendenti

Infrastruttura certificata ISO/IEC 27001. La piattaforma gira su infrastruttura europea certificata ISO/IEC 27001, con i controlli sui data center, sull'accesso fisico e sulla gestione operativa che la norma richiede.

Penetration test ogni anno. Il test lo esegue un'azienda terza esterna, non il nostro team, e si ripete annualmente. Il report è condivisibile sotto NDA: lo trovate nell'elenco dei documenti, sezione 15. Se il vostro processo prevede di leggere l'esito prima della firma, si fa prima della firma.

11. Disponibilità e continuità

Stato del servizio: pubblico e senza login su status.userbot.ai, con lo storico dei periodi di disponibilità e degli incidenti passati. È il posto da guardare per primo quando qualcosa non risponde, e da linkare al vostro service desk.

Continuità dentro il prodotto. Se il modello scelto va in errore, la richiesta passa in automatico a un modello di riserva invece di fallire. Quando si superano le finestre di utilizzo (sessione da 5 ore e finestra settimanale) le risposte fanno downgrade automatico su GPT-OSS 120B invece di bloccarsi.

I livelli di servizio concordati, con i tempi di ripristino, sono nell'SLA: è un documento contrattuale, lo trovate nell'elenco alla sezione 15. Su questa pagina non pubblichiamo una percentuale di uptime: il dato reale, misurato, è quello dello storico su status.userbot.ai.

12. Incidenti e violazioni dei dati

Il conto che deve tornare è il vostro: davanti a una violazione di dati personali il GDPR vi dà 72 ore per notificarla al Garante (art. 33). Perché quelle 72 ore siano rispettabili, dovete sapere quanto tempo passa prima che arrivi la nostra segnalazione.

Vi avvisiamo entro 24 ore dal momento in cui veniamo a conoscenza dell'incidente. Il riferimento a cui vi raggiungiamo si indica nel DPA, insieme al resto della procedura: classificazione, escalation e post mortem sono nella policy di gestione degli incidenti, nell'elenco dei documenti alla sezione 15.

Cosa potete fare da subito, dalla vostra parte: il Registro di audit traccia gli accessi riusciti e falliti con IP e browser, ed è il primo posto in cui guardare se sospettate un accesso non autorizzato a un'area di lavoro.

Per gli incidenti gravi ai sensi dell'art. 73 dell'AI Act, il quadro degli obblighi è descritto in AI Act & Userbot.

13. Contratto: DPA, sub-responsabili, DORA

Chi siamo, nel contratto. Il fornitore è Neuraltech S.r.l., parte del Gruppo Smeup, con sede in Milano e P.IVA IT13005930964. Nel trattamento dei dati che passano dalla piattaforma voi siete titolari, noi responsabili ai sensi dell'art. 28 GDPR.

DPA. L'accordo sul trattamento dei dati è l'Allegato 2 delle Condizioni di servizio: si accetta con il contratto e si legge prima di qualsiasi impegno. L'informativa privacy è una sola per il sito e per la piattaforma: Privacy.

I sub-responsabili, con il loro nome.

Dietro il catalogo ci sono OpenAI, Anthropic, Google, Mistral, DeepSeek e Qwen, raggiunti attraverso quei tre canali con la configurazione zero data retention e la clausola sull'addestramento descritte alla sezione 3. Se usate un modello vostro, il fornitore di quel modello è fuori dal nostro perimetro e dentro il vostro. L'elenco completo, con ragione sociale, servizio e luogo del trattamento, è nell'Appendice C delle Condizioni di servizio.

Entità finanziarie: DORA, art. 30. Sul Regolamento (UE) 2022/2554 accettiamo i tre punti che di solito bloccano una fornitura: il diritto di audit vostro e dei vostri incaricati, la cooperazione con l'autorità di vigilanza e una strategia di uscita scritta. Le clausole entrano nel contratto, non restano una dichiarazione su una pagina web.

Quando finisce il contratto. I dati vengono cancellati entro 30 giorni. Su richiesta rilasciamo un attestato di cancellazione da mettere agli atti.

14. AI Act: ruoli e classe di rischio

Il Regolamento (UE) 2024/1689 assegna obblighi diversi a seconda del ruolo. Questa è la ripartizione tra noi e voi.

Classe di rischio. Nell'uso interno come assistente aziendale (chat, ricerca nella conoscenza, documenti) la piattaforma opera in rischio minimo. Quando attivate il Customer Service sui vostri canali verso utenti finali, si entra nel rischio limitato, con gli obblighi di trasparenza dell'art. 50. Negli usi in settori regolamentati la classificazione va valutata caso per caso: dipende da cosa fate fare all'Agente, non dalla piattaforma.

Art. 50 in pratica. L'assistente si presenta sempre come assistente di Userbot e non finge di essere una persona. Sui canali di Customer Service resta disponibile il passaggio a un operatore umano con l'escalation "Scala su operatore", secondo gli orari che configurate.

La classificazione per singolo caso d'uso e la ripartizione puntuale degli obblighi sono nella scheda AI Act, il documento da mettere nel vostro fascicolo di conformità: sezione 15. L'impianto generale è descritto in AI Act & Userbot.

15. Documenti e contatti

Questo è l'elenco completo di cosa esiste. Sopra la riga: quello che è pubblico e si legge subito, senza lasciare un indirizzo. Sotto: i documenti contrattuali e di sicurezza, che si richiedono.

Pubblici, senza form e senza NDA

• Trust center: questa pagina, leggibile e stampabile così com'è.
• Informativa privacy del sito: Privacy.
• Cookie policy: Cookie.
• Termini di servizio: Termini.
• Nota AI Act: AI Act & Userbot.
• Stato del servizio e storico: status.userbot.ai.

Documenti per la due diligence

A chi scrivere. Per privacy, DPA e trattamento dei dati: privacy@userbot.ai, ed è lo stesso indirizzo che apre i link qui sopra. Per tutto il resto, compresa la documentazione da allegare a una gara, la pagina Contatti. Se una valutazione è già in corso, potete chiedere l'intero pacchetto in fase di demo.