Salta ai contenuti

Sicurezza e conformità

Sicurezza e conformità

Questa pagina descrive i controlli implementati in Aymar Agents — mai una certificazione. Nulla qui sostituisce la tua valutazione del rischio o la tua verifica di conformità; è una descrizione onesta, in linguaggio semplice, di quali meccanismi esistono oggi e dove vivono.

Quattro livelli di accesso, su tutto ciò che è nuovo

Sezione intitolata “Quattro livelli di accesso, su tutto ciò che è nuovo”

Prima che qualsiasi azione raggiunga l’agente IA del tuo account — o qualsiasi chiamante identificato, come una chiave API o una sessione della Piattaforma — passa attraverso quattro controlli indipendenti, in quest’ordine:

  1. Esistenza per il tuo account. Un’integrazione collegata, o un template, espone solo le azioni specifiche che hai attivato tu, una alla volta — niente arriva “aperto di default”.
  2. Visibilità per l’agente. Ogni agente IA ha il proprio ambito di risorse (etichette); un agente potrebbe non vedere una risorsa anche se il tuo account l’ha collegata — negato di default, totale.
  3. Audience del componente. Ogni azione, template o documento dichiara se è Interno o Entrambi — un visitatore anonimo di un canale (per esempio il widget pubblico del tuo sito) può raggiungere solo ciò che è marcato Entrambi; tutto il resto è Interno di default, senza eccezioni.
  4. Permessi di chi chiama. Per un chiamante identificato (una persona con sessione, un dipendente con il proprio canale, una chiave API), il catalogo fine dei permessi del tuo account decide cosa può fare, incrociato con ciò che quella chiave o quel canale hanno ricevuto.

Tutti e quattro i livelli vengono applicati sul server, non dal giudizio del modello linguistico — un’istruzione nel prompt non sostituisce mai un controllo a livello di codice.

Ogni account (tenant) è un compartimento isolato: ogni dato viene filtrato per l’id del tuo account in ogni query, e un id di un altro account su qualsiasi rotta risponde “non esiste” — mai “non autorizzato”, il che confermerebbe che il dato esiste. Le azioni sensibili vengono registrate in un log di audit per account, consultabile dalla Piattaforma.

La API pubblica (/public/v1, vedi Iniziare con la API) espone esattamente 5 risorse — lead, contatti, conversazioni, appuntamenti, ticket — e nient’altro: non ci sono rotte per fatturazione, team, impostazioni o amministrazione, qualunque sia il permesso della tua chiave. Ogni chiave dichiara i propri scope di lettura/scrittura per risorsa alla creazione, e quella selezione resta sigillata. Il server MCP proprio di Aymar Agents (vedi MCP) è un adattatore senza database né stato proprio: inoltra la tua stessa chiave a questa stessa API, chiamata dopo chiamata — tutto il controllo reale vive nella API, mai nell’adattatore.

Il copilota: revisionato e approvato, in linguaggio semplice

Sezione intitolata “Il copilota: revisionato e approvato, in linguaggio semplice”

Il copilota a schermo (dove disponibile) permette a un assistente di navigare, evidenziare o compilare campi, e — con la tua conferma esplicita — premere un pulsante reale. L’assistente legge un “manifesto” che descrive le schermate del tuo stesso sito; quel manifesto è un dato che invii tu, mai un’istruzione di cui il sistema si fida ciecamente. Otto difese concrete lo proteggono:

  1. È un dato, mai un’istruzione. Il manifesto passa dallo stesso filtro anti-injection di qualsiasi altro strumento del sistema prima di arrivare al modello linguistico.
  2. Vocabolario chiuso. Esistono solo i tipi di campo, azione e ancora già documentati — qualsiasi altra cosa viene rifiutata con un motivo concreto.
  3. Limiti rigidi di dimensione, quantità e lunghezza, controllati prima di qualsiasi altra cosa.
  4. Revisione umana di ogni versione, e attivazione azione per azione, disattivata di default.
  5. Impronta per sessione. Se il manifesto cambia, il copilota si disattiva finché qualcuno non lo approva di nuovo.
  6. Il piano viene validato sul server contro il manifesto approvato: l’assistente può riferirsi solo a id che esistono davvero lì, e qualsiasi azione che salva viene sempre forzata a richiedere conferma, qualunque cosa dica il piano.
  7. Il client stesso impone la conferma, nel caso il server fallisse — un secondo meccanismo indipendente, mai un unico punto di fallimento.
  8. Origine e sessione vincolate. Il manifesto viene accettato solo dalle origini consentite del tuo canale, e un risultato viene accettato solo per il piano e la sessione che lo hanno richiesto.

Nessuna azione che salva, invia o cancella viene mai eseguita senza conferma esplicita — è il livello minimo del prodotto.

Trasparenza e formazione (AI Act, Regolamento (UE) 2024/1689)

Sezione intitolata “Trasparenza e formazione (AI Act, Regolamento (UE) 2024/1689)”
  • Art. 50 — chiunque parli con un agente Aymar Agents sa che è un’IA, su ogni canale e in ogni lingua con cui servi i tuoi clienti.
  • Art. 4 — la documentazione di prodotto (questo stesso sito, e le guide al prodotto) è pensata perché il tuo team capisca come funziona il sistema che gestisce il suo account.

Aymar Agents ha un doppio ruolo, a seconda dei dati:

  • Responsabile del trattamento (encargado) dei dati dei tuoi clienti finali (i lead, i contatti e le conversazioni che gestisci nel tuo account) — li trattiamo e li conserviamo per tuo conto, con le garanzie del tuo contratto e il nostro accordo sul trattamento dei dati (DPA).
  • Titolare del trattamento dei dati del tuo stesso account (il tuo team, la tua fatturazione, la tua configurazione).

Questo include il diritto alla cancellazione di un cliente finale, e il dovere di informazione in ogni punto in cui i suoi dati vengono raccolti. Maggiori dettagli, applicati specificamente alla API pubblica, in Responsabilità dei dati.

  • MCP — come si collega il tuo assistente IA al tuo account.
  • Autenticazione — il catalogo completo degli scope di una chiave API.
  • Responsabilità dei dati — la ripartizione RGPD applicata alla tua integrazione.

Dubbi su sicurezza o conformità? Scrivi a legal@aymaragents.com.