L’autonomie, avec des limites.
Nous définissons ce que le système sait, ce qu’il peut faire, ce qu’il doit confirmer et quand il doit passer à un humain.
Quatre points où le système s'arrête pour vérifier.
Permissions
Nous définissons les actions que le système peut exécuter. Lorsqu'une demande sort de ce périmètre, nous configurons ce qui doit se produire : la bloquer, demander une confirmation, notifier ou la transférer lorsque le canal le permet.
Informations
Nous limitons les sources, les données et les opérations auxquelles le système peut accéder. Dans ce périmètre autorisé, l'agent peut consulter les informations nécessaires à sa tâche. Ce qu'il peut enregistrer, et où, est également défini dans l'architecture.
Transfert à un humain
Lorsqu'une situation dépasse ses limites, nous pouvons configurer le système pour qu'il s'arrête, demande une confirmation, notifie ou transfère à une personne selon le canal et l'architecture.
Journalisation et contrôle
Les actions pertinentes peuvent être journalisées afin que vous puissiez vérifier ce que le système a fait et quand, selon la configuration de chaque projet.
Avant d'agir, le système vérifie s'il est autorisé.
Les limites d'ELENA, pas une promesse universelle.
Voici une démonstration de la façon dont les limites d'un agent précis sont configurées — et non le comportement garanti de tous les systèmes que nous construisons.
- Répondre aux questions fréquentes
- Consulter les disponibilités
- Mettre à jour un rendez-vous existant
- Accéder à des données non autorisées
- Exécuter une action hors de ce qui est permis
- Affirmer une information qu'il ne possède pas
- Le client le demande explicitement
- La demande n'est pas couverte par ses permissions
- Il existe une ambiguïté significative dans la demande
Vos données ne sont pas un détail.
Chaque conversation ou action peut passer par plusieurs parties, selon la façon dont votre projet est construit. Nous préférons que vous sachiez lesquelles, plutôt que de vous les faire supposer.
STEAMNODE
Conçoit, construit et maintient le système. Accède à ce qui est nécessaire pour l'exploiter.
Votre infrastructure
Serveur, base de données ou logiciel qui vous appartient, lorsque le projet y est hébergé.
Fournisseurs d'IA
Le modèle de langage qui traite les conversations (par exemple, OpenAI ou Anthropic).
Téléphonie
Lorsque des appels vocaux sont impliqués, un fournisseur d'infrastructure téléphonique.
Meta / WhatsApp
Lorsque le canal est WhatsApp Business, la plateforme de messagerie de Meta.
CRM et autres fournisseurs
Le logiciel connecté au système et tout autre service dont un projet précis a besoin pour fonctionner.
Nous concevons chaque projet en tenant compte des principes du RGPD — minimiser les données, limiter l'accès, définir la finalité de chaque traitement. Cela ne remplace pas un avis juridique. Si votre activité traite des données particulièrement sensibles (santé, mineurs, informations financières), nous recommandons une revue de confidentialité et de sécurité spécifique avant de construire.
La façon dont ces systèmes se connectent aux outils que vous utilisez déjà est expliquée dans intégrations.
Quand une personne doit intervenir, elle intervient.
La façon dont ce signal parvient à votre équipe dépend du canal et du projet : cela peut signifier transférer la conversation, notifier la personne concernée ou, lorsque l'infrastructure vocale le permet, transférer l'appel. Nous le définissons avant de construire, nous ne le promettons pas de façon générique.
Les limites ne restent pas figées le jour du lancement.
Les ajustements raisonnables portant sur des règles, des permissions et des limites déjà existantes peuvent faire partie de la maintenance continue. Si la modification nécessite une nouvelle fonctionnalité, une intégration ou une nouvelle architecture, elle est évaluée comme une nouvelle mise en œuvre.
Ce qu'on nous demande le plus souvent à ce sujet.
Le système peut-il halluciner ou inventer des informations ?
Cela peut arriver, comme pour tout système fondé sur des modèles de langage. C'est pourquoi nous limitons ce qu'il peut affirmer sans vérification et nous définissons les cas où il doit passer la main plutôt que de répondre avec incertitude.
Qui est responsable si le système commet une erreur ?
Cela dépend de l'erreur et de ce qui a été convenu pour le projet. Nous concevons des limites pour réduire le risque, mais nous n'éliminons pas la possibilité d'erreur — aucun système, humain ou automatisé, ne le fait.
Mes données sont-elles en sécurité ?
Nous appliquons les bonnes pratiques de sécurité et limitons l'accès au strict nécessaire pour l'exploitation. Nous ne revendiquons pas une certification que nous n'avons pas — si votre projet en exige une (ISO 27001, SOC 2, HIPAA, ENS ou autre), nous l'évaluons au cas par cas avant de commencer.
Êtes-vous conformes au RGPD ?
Nous concevons chaque projet en tenant compte des principes du RGPD : minimiser les données, limiter l'accès, définir la finalité de chaque traitement. Cela ne remplace pas un avis juridique. Si votre secteur traite des données sensibles (santé, mineurs, informations financières), nous recommandons une revue de confidentialité spécifique.
Où sont hébergées mes données ?
Cela dépend de l'infrastructure du projet : elle peut être la vôtre, la nôtre, ou celle d'un fournisseur d'IA ou de téléphonie nécessaire au fonctionnement du système. Nous le définissons et le documentons avant de construire, sans présupposer un emplacement par défaut.
Puis-je voir ce que le système a fait dans chaque conversation ?
Selon la configuration du projet, oui — vous pouvez avoir de la visibilité sur les actions pertinentes. Ce n'est pas un journal universel d'absolument tout ce qui se passe, c'est ce qui est défini comme nécessaire pour votre contrôle.