Depuis le 2 août 2026, le règlement européen sur l'IA appliqué au service client se résume à une règle que la plupart des équipes peuvent respecter en un après-midi : si un client parle directement à votre IA, dites-lui au début de la conversation qu'il s'agit d'une IA. Une mention dans vos conditions générales ne compte pas, pas plus qu'un nom vague comme « assistant ». Les manquements peuvent coûter jusqu'à 15 millions d'€ ou 3 % du chiffre d'affaires mondial.
Ce que la plupart des guides oublient, c'est ce qui est hors champ. Les brouillons IA qu'un agent relit et envoie, l'étiquetage des tickets, le routage et les résumés n'ont pas besoin de mention IA, parce que le client ne parle jamais directement à l'IA. Deux sujets méritent plus d'attention que le chatbot : la lecture des émotions dans la voix (interdite pour surveiller vos propres agents depuis février 2025) et l'IA qui note la performance des agents ou décide de l'octroi de crédit et d'assurance, qui devient à haut risque le 2 décembre 2027.
Je travaille dans la file de support d'eesel elle-même, et la plupart des équipes européennes que je vois sur eesel utilisent l'IA selon un partage qui correspond bien à la loi : smava fait rédiger par eesel environ 15 300 réponses par mois en allemand, que les conseillers valident, tandis que la compagnie de ferries Norden-Frisia exploite un bot orienté client appelé CaptAIn. Seul le second a besoin de la mention. Ce guide n'est pas un conseil juridique, mais il devrait vous indiquer précisément quels outils IA examiner en premier.
Que demande vraiment le règlement européen sur l'IA à une équipe support ?
Le règlement sur l'IA répartit la responsabilité entre deux rôles. Un fournisseur construit un système d'IA et le met sur le marché sous son propre nom, comme un éditeur de helpdesk qui livre un agent IA. Un déployeur utilise un système d'IA sous sa propre autorité, ce que vous êtes quand vous activez cet agent pour vos clients. La plupart des équipes support sont déployeurs, et quelques-unes deviennent fournisseurs lorsqu'elles construisent leur propre bot en interne ou rebaptisent et réentraînent celui d'un autre.
Pour une équipe support, quatre parties de la loi comptent. Tout le reste (règles sur les modèles à usage général, sécurité des produits, application de la loi) concerne d'autres personnes.
| Règle | Ce que cela signifie pour le support | S'applique depuis | Amende maximale |
|---|---|---|---|
| Article 50 transparence | Dire aux gens qu'ils parlent à une IA ; les informer si une reconnaissance des émotions est utilisée sur eux | 2 août 2026 | 15 M€ ou 3 % du chiffre d'affaires |
| Article 5 interdictions | Aucune IA qui déduit les émotions des travailleurs, donc pas de notation vocale des émotions de vos agents | 2 février 2025 | 35 M€ ou 7 % du chiffre d'affaires |
| Article 4 maîtrise de l'IA | Prendre des mesures pour que le personnel qui utilise l'IA la comprenne | 2 février 2025 | Fixée par chaque pays |
| Annexe III usages à haut risque | Obligations supplémentaires si votre IA note les agents ou évalue le risque de crédit ou d'assurance | 2 décembre 2027 | 15 M€ ou 3 % du chiffre d'affaires |
Les plafonds d'amende viennent de l'article 99, qui demande aussi à chaque pays de tenir compte des intérêts des petites entreprises et d'appliquer le plafond le plus bas aux PME. Ce sont les autorités nationales de surveillance du marché qui font appliquer la loi, et la Commission indique dans son explication du 2 août qu'elles peuvent désormais prononcer ces amendes.
Le Digital Omnibus n'a-t-il pas tout repoussé ?
En partie, et c'est là que beaucoup d'équipes se sont trompées. Le Digital Omnibus on AI (règlement 2026/1744, adopté le 8 juillet 2026) a repoussé les règles à haut risque, mais n'a pas touché à la date de l'information sur les chatbots. D'après l'article 113 modifié, le calendrier ressemble maintenant à ceci :
Le seul délai de transparence qui a bougé est technique : les systèmes d'IA déjà sur le marché avant le 2 août 2026 ont jusqu'au 2 décembre 2026 pour ajouter des marqueurs lisibles par machine au contenu qu'ils génèrent, selon la FAQ de la Commission sur l'article 50. C'est un travail pour les ingénieurs de votre éditeur. L'information « vous parlez à une IA » est en vigueur depuis août.
Quelle IA de support a besoin d'une mention « je suis une IA » ?
C'est la partie qui économise le plus de travail. Les lignes directrices de la Commission sur l'article 50, publiées le 20 juillet 2026, énumèrent quatre conditions qui doivent toutes être réunies avant que la règle d'information s'applique : c'est un système d'IA, il est destiné à interagir, l'interaction est directe, et elle a lieu avec une personne. Le mot qui compte vraiment est directe.
Les lignes directrices précisent que le service client est le cas d'école des deux côtés de la ligne. Un chatbot de helpdesk qui répond aux clients est dans le champ. Un agent qui utilise l'IA pour l'aider à rédiger une réponse n'y est pas :
"Direct interaction excludes indirect or mediated human interaction where a natural person is exposed to AI outputs without directly interacting with the system (for example, if customer service representatives use AI assistance tools to help them communicate with natural persons...)"
Triez vos outils en deux piles et l'essentiel de l'inquiétude disparaît :
Trois précisions des lignes directrices valent la peine d'être connues avant de ranger quoi que ce soit dans la pile de droite :
- « Un humain pourrait intervenir » n'est pas une échappatoire. Les lignes directrices disent que la simple possibilité qu'une personne relise les réponses ne peut pas servir à contourner la règle. Les brouillons ne sont hors champ que si une personne les relit réellement et les envoie comme voix principale de la conversation.
- Les conversations mixtes exigent des mentions sur les parties IA. Si un chat est transmis d'un bot à une personne, ou qu'une personne repasse la main à un bot, les tours générés par l'IA doivent comporter l'information.
- Les e-mails envoyés automatiquement comptent. L'interaction peut avoir lieu « via technical communication means including online interfaces, phone or e-mail », et l'exemple de bonne mention donné par les lignes directrices est un e-mail rédigé par IA avec une mention IA en haut. Les réponses automatiques à règles et les messages d'absence classiques ne sont pas des systèmes d'IA, ils sont donc exclus.
Les bots internes destinés à du personnel formé sont aussi exemptés. Les lignes directrices citent un « internal employee-facing assistant for properly trained staff » (RH, juridique, support informatique) comme un cas où la nature IA est assez évidente pour ne pas exiger de mention.
Où se situent les clients d'eesel
C'est le partage que je vois chaque semaine. Dokument 24, un service danois de documents juridiques, fait préparer par eesel environ 670 brouillons de réponse en danois par mois sous forme de notes internes dans Zendesk, et quelqu'un de l'équipe modifie et envoie chacun d'eux. C'est une interaction médiatisée. Nordbutiker, qui vend des vélos électriques et des scooters de mobilité dans quatre pays nordiques, exploite un bot orienté client distinct pour chaque marque et chaque langue sur ses sites de boutique. Ces bots parlent directement aux clients, donc chacun a besoin de sa propre mention, dans sa propre langue.
Qu'est-ce qu'une bonne mention ?
L'article 50(5) dit seulement que l'information doit être « clear and distinguishable », fournie « at the latest at the time of the first interaction », et accessible. Les lignes directrices comblent les détails, et elles sont étonnamment pratiques. Une seule mention bien visible avant la première interaction suffit dans la plupart des cas.
| Fonctionne | Insuffisant seul |
|---|---|
| Un message d'accueil au premier tour qui dit que c'est une IA (« Je suis l'assistant IA de... ») | Une ligne dans vos conditions générales ou votre politique de confidentialité |
| Une mention en langage clair près de la zone de saisie (« Vous discutez avec un système d'IA ») | Un nom générique comme « Assistant » ou « Support » |
| Un badge ou une icône IA permanents à côté des réponses du bot | Une photo humaine ou un nom à consonance humaine sur l'avatar du bot |
| Une mention IA en haut d'un e-mail rédigé par IA | « Les services de ce site utilisent l'IA » sur tout le site |
| Une phrase parlée au début d'un appel (« Ceci est un assistant propulsé par l'IA ») | « Propulsé par des LLM » ou autre jargon technique |
| Répondre honnêtement chaque fois qu'un client demande « est-ce un bot ? » | Des métadonnées cachées ou un filigrane que le client ne peut pas voir |
Les lignes directrices veulent plus d'une mention dans les « contextes plus risqués », et deux de leurs exemples relèvent directement du support : le traitement des réclamations, et les conversations sur le conseil financier, l'assurance, le juridique ou la santé. Elles y attendent des rappels périodiques, surtout quand une conversation change de mains ou que le rôle de l'IA change. Tout ce qui s'adresse au grand public doit aussi fonctionner pour les personnes en situation de handicap, les clients âgés et les enfants : une mention grise en 9 px ne suffit donc pas.
On lit souvent dans les fils de discussion de développeurs que le contexte suffit à lui seul :
"The main point is that it is trying to prevent deception, e.g. in a "live support chat" where a website claims you're talking to a human when in fact you're not... if it's clear from the context, that you're interacting with AI, it doesn't need to be explicitly said. No cookie banners."
La première moitié est juste. C'est dans la seconde que les équipes support se font piéger : l'exception d'évidence ne sauvera pas un bot orienté client. Les lignes directrices disent qu'elle doit être lue « restrictively », et citent les chatbots de helpdesk dont les réponses peuvent être « perceived as human-generated » par les clients comme exemple où la règle s'applique.
Voici à quoi peut ressembler une configuration de base d'apparence conforme. Dans la bulle de chat d'eesel, le nom de l'agent est affiché à côté de chaque réponse, et une ligne de mention distincte se trouve sous la zone de saisie :
Remarquez le piège dans cette capture. Le nom « Shop Assistant » est exactement le genre d'étiquette générique que les lignes directrices jugent ambiguë ; c'est la ligne de mention sous la zone de saisie qui fait le travail juridique. Si vous voulez que les deux portent le message, mentionnez aussi l'IA dans le message de bienvenue. eesel signe les réponses « AI Agent » quand vous laissez vide le nom de l'agent.
Il y a une raison commerciale de le faire au-delà de l'amende. Les clients qui repèrent un bot se faisant passer pour une personne perdent confiance dans l'entreprise, pas seulement dans le bot :
"I think a voice agent trying to appear as a human is actually hurting the business that’s deploying it. I can tell within 5 seconds that it’s not a real human and then my sentiment is they’re 1. being cheap and 2. trying to play me."
Les personas nommés sont d'ailleurs permis. Le bot de Norden-Frisia s'appelle CaptAIn, « Captain plus AI », avec son propre avatar et un message d'accueil en dialecte local. Un persona avec « AI » dans le nom est un bon début ; y associer une phrase claire dans l'accueil (« Je suis un assistant IA ») lève tout doute pour un passager qui ne remarque pas le jeu de mots. Le cas d'échec, c'est un prénom humain sans aucune mention, ce qui a valu au bot de support d'un outil de programmation de se faire éreinter sur Hacker News en 2025 :
"LLMs pretending to be people (you named it Sam!) and not labeled as such is clearly intended to be deceptive."
Cette IA de support a-t-elle besoin d'une mention ?
Choisissez une configuration pour voir quelle règle du règlement européen sur l'IA s'applique, depuis quand et quoi changer.
Mettez une mention IA dans le premier message et une étiquette IA visible près de la zone de saisie, dans chaque langue que le bot parle. Veillez à ce qu'il réponde honnêtement quand on lui demande s'il est un bot.
Ajoutez une étiquette IA en haut de chaque e-mail que l'IA envoie sans relecture par une personne. Les réponses automatiques à règles et les messages d'absence ne sont pas des systèmes d'IA, ils n'en ont donc pas besoin.
C'est hors du champ de la règle d'information tant qu'une personne relit réellement le brouillon et l'envoie comme voix principale. Une étape de relecture qui n'existe que sur le papier ne compte pas.
Dites-le à voix haute au début de l'appel, par exemple « Ceci est un assistant propulsé par l'IA ». Répétez-le après les transferts ou les longues attentes, et ne comptez pas uniquement sur un bip ou une tonalité.
Le texte n'est pas une donnée biométrique : repérer les tickets de clients en colère d'après leurs mots n'est donc pas de la reconnaissance des émotions au sens du règlement sur l'IA. Cela reste un traitement de données personnelles, et doit figurer dans vos registres RGPD.
Déduire les émotions des travailleurs est interdit hors raisons médicales ou de sécurité. Désactivez tout outil qui note les agents selon leur degré de stress ou d'amabilité à l'écoute de l'audio.
L'IA qui surveille et évalue la performance des travailleurs figure sur la liste à haut risque. Si les scores alimentent des décisions de promotion ou de licenciement, demandez dès maintenant à votre éditeur sa classification par écrit.
Évaluer la solvabilité ou fixer le prix d'assurances vie et santé est à haut risque. Un bot qui explique le formulaire de demande ne fait pas ce travail ; un bot qui dit aux clients s'ils sont éligibles, si.
L'analyse de sentiment compte-t-elle comme de la reconnaissance des émotions ?
En général non, et c'est la partie de la loi la plus mal comprise dans les équipes support. Le règlement définit un système de reconnaissance des émotions comme une IA qui déduit des émotions ou des intentions « on the basis of their biometric data ». Un texte n'est pas une donnée biométrique. Donc l'analyse de sentiment que votre helpdesk exécute sur le texte des tickets pour repérer un client en colère n'est pas de la reconnaissance des émotions au sens du règlement sur l'IA, même si elle reste un traitement de données personnelles au titre du RGPD.
La voix, c'est différent, car la voix est biométrique. C'est là que les règles se durcissent :
- Noter les émotions de vos agents à partir de leur voix est interdit. L'article 5(1)(f) interdit l'IA qui déduit les émotions des personnes « in the areas of workplace and education institutions », sauf pour des raisons médicales ou de sécurité. Un outil de centre d'appels qui note les agents selon leur degré de stress ou d'amabilité entre dans cette interdiction, qui s'applique depuis le
2 février 2025, avec le palier d'amende le plus élevé du règlement. - Détecter l'émotion d'un appelant à partir de sa voix est permis, mais encadré. Vous devez informer les appelants que cela fonctionne en vertu de l'article 50(3) depuis août 2026, et les lignes directrices confirment que tout système de reconnaissance des émotions est aussi à haut risque : les obligations complètes à haut risque s'appliquent donc à partir du
2 décembre 2027.
Si vous achetez un logiciel de centre d'appels avec de l'« IA des émotions » ou du « coaching de ton », posez une question à l'éditeur : analyse-t-il l'audio de la voix, ou les mots de la transcription ? La réponse détermine dans quelle catégorie vous êtes.
Quand l'IA de support devient-elle à haut risque ?
Rarement, mais les cas limites sont plus proches du support que la plupart des guides ne l'admettent. La liste à haut risque de l'annexe III porte sur ce que l'IA décide, pas sur votre secteur. Trois entrées frôlent le travail de support :
- L'IA qui surveille ou évalue les travailleurs. Le point 4(b) couvre l'IA utilisée « to monitor and evaluate the performance and behaviour of persons » dans les relations de travail, ou pour répartir des tâches selon des traits personnels. Un outil de QA par IA qui note les conversations de chaque agent et alimente des décisions de promotion ou de licenciement se situe près de cette ligne.
- Les décisions de crédit et d'assurance. Les points 5(b) et 5(c) couvrent la solvabilité et la tarification des assurances vie ou santé. Un bot de support qui dit à un client s'il remplit les conditions d'un prêt, plutôt que d'expliquer le formulaire, fait un travail à haut risque.
- Les prestations publiques et le triage des urgences. Les points 5(a) et 5(d) couvrent la décision d'éligibilité aux aides publiques et le triage des appels d'urgence.
L'article 6(3) offre une porte de sortie pour l'IA qui n'exécute qu'une « narrow procedural task » ou une « preparatory task » et n'influence pas sensiblement le résultat. Il la ferme pour tout ce qui établit le profil de personnes : un système de l'annexe III qui établit le profil de personnes physiques est toujours à haut risque.
smava est l'exemple utile ici. C'est une plateforme berlinoise de comparaison de crédits, à peu près aussi réglementée que le support peut l'être, et ses trois agents eesel catégorisent les tickets, rédigent des réponses mot pour mot à partir de macros approuvées et n'envoient jamais seuls. Ils n'évaluent la solvabilité de personne : le secteur seul ne rend donc pas l'IA de support à haut risque.
Si vous êtes déployeur d'un système à haut risque à partir de décembre 2027, l'article 26 demande une supervision humaine nommée, la conservation des journaux du système pendant au moins six mois, l'information des représentants des travailleurs avant de l'utiliser sur le personnel, et l'information des clients quand il contribue à des décisions les concernant. C'est un effort plus lourd qu'une mention de chatbot : si votre outil de QA ou de routage est près du point 4(b), ouvrez dès maintenant cette discussion avec votre éditeur.
Qui est responsable : vous ou votre éditeur de helpdesk ?
Les deux, de manières différentes. L'article 50(1) met l'obligation d'information sur le fournisseur, qui doit concevoir le système de façon que les gens soient informés. Si vous activez l'agent IA d'un éditeur, celui-ci vous doit un système qui peut se déclarer. Mais c'est vous qui écrivez le message d'accueil, choisissez le nom et l'avatar du bot et décidez sur quels canaux il fonctionne : en pratique, une mauvaise configuration est à corriger de votre côté.
Vous pouvez aussi devenir le fournisseur. Les lignes directrices disent qu'une entreprise qui construit un chatbot en interne et l'exploite sous son propre nom est fournisseur, tout comme celle qui prend le système d'un autre fournisseur, le modifie (par exemple avec de nouvelles données d'entraînement) et le met en service sous son propre nom. Si vous avez construit votre propre bot de support sur une API de modèle, l'information relève entièrement de vous.
Le contrat de votre éditeur dit généralement la même chose. L'AI Services Addendum de Zendesk indique que le client « will ensure any requirements of notice, transparency, and choice are met », et l'AI Acceptable Use Policy de Salesforce indique que les clients « must disclose to end users when they are interacting directly with automated systems ». Mieux vaut donc savoir ce que chaque helpdesk offre d'office. Voici ce que j'ai trouvé dans la documentation de chaque éditeur :
| Agent IA du helpdesk | Renommer le bot | Mention IA dans le chat | Mention IA dans l'e-mail | Déclaration propre sur le règlement européen sur l'IA |
|---|---|---|---|---|
| Zendesk AI agents | Oui | Oui, activée par défaut (« Zara · AI ») | Non intégrée | Oui |
| Freshdesk Freddy AI Agent | Oui, avec avatar | Non documentée ; utilisez le message d'introduction | Non intégrée | Non documentée |
| Gorgias AI Agent | Oui | Oui, « Automated » sous les messages IA | Signature IA en option | Non documentée |
| HubSpot Customer Agent | Oui, avec avatar | Oui, « Powered by AI » dans l'en-tête | Signature d'équipe uniquement | Non documentée |
| Salesforce Agentforce | Oui | Non documentée ; utilisez le message de bienvenue | Non documentée | Oui |
| Help Scout Scout | Non documenté | Oui, « clearly labeled as AI » | Non documentée | Non documentée |
| Front AI agents | Oui, avec avatar | Avertissement de conformité optionnel sur le widget Resolve | Non documentée | Non documentée |
| Kustomer Concierge | Non documenté | Non documentée ; utilisez le message d'accueil | Non documentée | Non documentée |
Zendesk propose la configuration par défaut la plus complète. Depuis mars 2026, son Web Widget place une étiquette « AI » sur le nom du bot une fois par groupe de messages, et sur les canaux sociaux et applications mobiles, l'étiquette fait partie du nom affiché. On ne peut la désactiver que canal par canal via l'API, et Zendesk prévient que si vous le faites, vous êtes responsable du respect des règles sur l'IA là où vous opérez.
Freshdesk adopte l'approche inverse pour le nom : sa documentation suggère d'éviter les noms génériques comme « Bot » ou « AI » parce que les agents nommés suscitent plus d'engagement. C'est un choix produit défendable, et cela signifie que la mention doit se trouver dans le message d'introduction, que vous pouvez modifier et traduire automatiquement. Le texte par défaut dans la documentation est « Hello. How can I help you? », vérifiez donc le vôtre.
Le constat sur l'ensemble du tableau : l'e-mail est l'endroit où la plupart des helpdesks vous laissent gérer la mention. Gorgias est le seul à documenter une signature IA pour les e-mails, et elle est en option. Si votre agent IA envoie seul des réponses par e-mail, ajoutez vous-même une ligne IA dans sa signature ou en haut du message.
La règle sur la maîtrise de l'IA signifie-t-elle que je dois former mes agents ?
Légèrement. L'article 4 s'applique depuis février 2025, et l'Omnibus l'a assoupli : les déployeurs doivent « take measures to support the development of AI literacy » pour le personnel qui utilise l'IA, en tenant compte de ses connaissances et du contexte, et le texte précise désormais que cela « does not require providers or deployers to guarantee any specific level of AI literacy of any individual ». La Commission doit aussi publier des exemples pratiques pour les PME.
Pour une équipe support, un socle raisonnable est court : quels outils utilisent l'IA, ce qu'ils peuvent et ne peuvent pas faire, comment vérifier un brouillon avant l'envoi, quand faire remonter un dossier, et quoi répondre quand un client demande s'il parle à un bot. Écrivez-le une fois et ajoutez-le à l'intégration des nouveaux agents.
Une checklist de 30 jours sur le règlement européen sur l'IA pour les équipes support
Voici l'ordre dans lequel je procéderais, du plus exposé au moins exposé :
- Listez chaque outil IA qui touche un client. Chat du site, agents vocaux IA, réponses e-mail envoyées automatiquement, bots sociaux et WhatsApp, et tout ce que vos agents utilisent pour rédiger.
- Marquez chacun comme direct ou médiatisé. Direct signifie que la production de l'IA atteint le client sans qu'une personne la relise et l'envoie.
- Corrigez d'abord les directs. Ajoutez une mention IA au premier tour dans chaque langue prise en charge, une étiquette visible et une réponse honnête à « êtes-vous un bot ? ». Vérifiez les messages d'accueil vocaux et le haut des e-mails envoyés automatiquement.
- Cherchez les fonctions d'émotion vocale. Désactivez toute notation vocale des émotions orientée agents. Si la détection de l'émotion de l'appelant reste, ajoutez l'information et préparez les obligations à haut risque de 2027.
- Signalez tout ce qui note les agents ou décide de l'éligibilité. Une notation QA qui alimente des décisions RH, des réponses sur le crédit, l'assurance ou les prestations : obtenez par écrit la classification à haut risque de votre éditeur.
- Demandez à votre éditeur sa position sur l'article 50. Vous voulez savoir comment l'information fonctionne canal par canal et quand arrive le marquage lisible par machine.
- Rédigez la note d'une page sur la maîtrise de l'IA et partagez-la avec l'équipe.
Si vous avez déjà fait une revue de sécurité ou un passage RGPD sur votre éditeur d'IA, greffez ceci dessus plutôt que de lancer un nouveau processus. Les questions se recoupent plus qu'elles ne diffèrent, et le règlement sur l'IA s'appuie expressément sur le RGPD au lieu de le remplacer.
Comment eesel s'inscrit dans le règlement européen sur l'IA
eesel est un coéquipier IA pour votre helpdesk. Il rejoint votre file existante dans Zendesk, Freshdesk, Gorgias ou Help Scout, apprend de vos anciens tickets, macros et centre d'aide, et traite les tickets que vous lui indiquez. Ce qui compte pour le règlement sur l'IA :
- Vous choisissez direct ou médiatisé par action. Chaque action s'exécute seule, attend une personne ou reste désactivée, réglé par agent dans Actions and Approvals. Garder les réponses publiques sous validation maintient l'IA du côté médiatisé de la ligne pendant que vous bâtissez la confiance.
- La bulle de chat a un champ de mention IA. La mention figure sous la zone de saisie dans chaque conversation, et le nom de l'agent est par défaut « AI Agent ».
- Les règles vivent dans des instructions en langage courant. « Dis toujours que tu es un assistant IA si on te le demande, dans la langue du client » tient en une ligne dans les instructions de l'agent, pas dans un ticket pour l'ingénierie.
Ce n'est pas un produit de conformité, et je ne prétendrai pas le contraire : eesel ne classera pas vos systèmes d'IA et ne rédigera pas votre politique de maîtrise de l'IA. Il est aussi honnête de dire que l'audit SOC 2 Type II d'eesel est toujours en cours (la période d'observation court jusqu'au 31 décembre 2026) et que la résidence complète des données dans l'UE est une fonctionnalité du plan Enterprise, d'après la page sécurité d'eesel. eesel n'entraîne pas de modèles sur vos données.
Essayez eesel sur votre file de support européenne
Si votre équipe répond aux clients en allemand, en danois ou en suédois et veut une IA qui annonce clairement qu'elle est une IA, eesel est conçu pour cette configuration. smava l'utilise sur 27 000 tickets Zendesk par mois, chaque réponse attendant un conseiller, et Norden-Frisia exploite CaptAIn sur son site web, via un lien de chat public et dans Zendesk. Commencez par des brouillons sous validation, ajoutez un bot nommé avec un message d'accueil IA clair quand vous êtes prêt, et essayez eesel gratuitement pendant 7 jours.
