Sicherheitscheckliste für KI-Support-Anbieter: 25 Fragen für 2026

Warum reicht ein SOC-2-Bericht bei einem KI-Support-Anbieter nicht aus?

Ich arbeite auf der Agent-Seite von eesel, also viel an dem Teil des Produkts, den Sicherheitsprüfer am härtesten abklopfen. eesel hat auch schon Deals genau an dieser Checkliste verloren. Eine US-Gesundheitsplattform auf Zendesk brach das Gespräch mitten in der Demo ab, weil wir damals keinen BAA unterschreiben konnten. Eine große Podcast-Plattform auf Freshdesk konnte ohne fertigen SOC 2 nicht weitermachen. Diese beiden Gespräche sind ein wesentlicher Grund, warum eesel heute ein öffentliches Trust Center mit datiertem Audit-Zeitplan hat, und ich bin ehrlich dazu, wo wir stehen.

Das haben mir diese Gespräche gezeigt: Ein SOC-2-Bericht sagt, dass ein Anbieter seine Systeme sorgfältig betreibt: Verschlüsselung, Zugriffsprüfungen, Change Management, Incident Response. Die Trust Services Criteria des AICPA decken Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz ab. Das ist die Untergrenze, und darauf sollten Sie bestehen.

Aber ein KI-Support-Agent ist eine andere Art von Anbieter. Er speichert Ihre Tickets nicht nur. Er liest sie, schickt sie an ein großes Sprachmodell einer anderen Firma, und in vielen Setups kann er eine Bestellung erstatten oder ein Konto ändern. Keine der SOC-2-Kategorien fragt: „Kann ein Kunde Ihren Bot zu einer Rückerstattung überreden?“

Das AICPA selbst warnt Käufer inzwischen vor der Abzeichen-Sammelmentalität. Seine SOC-2-Themenseite verlinkt einen Beitrag von 2026 mit dem Titel „Promises of 'fast and easy' threaten SOC credibility.“ Lesen Sie also den Bericht, prüfen Sie seine Daten und ob das KI-Produkt tatsächlich im Umfang liegt. Dann fragen Sie weiter.

Die gute Nachricht: Die zweite Ebene müssen Sie nicht neu erfinden. Die Frameworks gibt es schon:

Wenn Ihr Sicherheitsteam schon SIG oder CAIQ nutzt, bitten Sie den Anbieter vor dem ersten Gespräch um eine ausgefüllte Kopie. Das spart eine Woche. Die Checkliste unten ist das, was ich zusätzlich darauflegen würde, formuliert für eine Support-Leitung statt für einen Auditor.

Die Sicherheitscheckliste für KI-Support-Anbieter

Haken Sie Punkte ab, sobald der Anbieter sie beantwortet. Die als kritisch markierten würde ich als Blocker behandeln, bevor ein KI-Agent an echte Kundentickets darf. Der Zähler oben hält den Stand fest.

Der Rest dieses Beitrags geht die sechs Gruppen durch, mit dem, was 7 bekannte Helpdesk-Anbieter zu jeder tatsächlich veröffentlichen. Ich habe Zendesk, Freshworks, Salesforce, HubSpot, Gorgias, Help Scout und Front gewählt, weil ihre KI im Helpdesk lebt und ihre Trust-Seiten daher diejenigen sind, die die meisten Support-Teams am Ende lesen.

Trainieren sie mit Ihren Tickets?

Das ist die erste Frage, die alle stellen, und die Antworten sind weniger einheitlich, als man denkt. Dahinter stecken eigentlich drei getrennte Fragen: Trainiert der Anbieter eigene Modelle mit Ihren Daten, trainiert der Modellanbieter dahinter, und helfen Ihre Daten den Agenten anderer Kunden.

Die meisten Anbieter sind beim Modellanbieter klar. Zendesk sagt, seine LLM-Subunternehmer „cannot use your Service Data to train their models“, und Front untersagt seinen Subunternehmern, Kundendaten „to train foundation models“ zu nutzen. Spannend wird es bei den eigenen Modellen der Anbieter:

• Zendesk trainiert „generic, cross-account machine learning models“ für die Klassifizierung mit Servicedaten, nach einem Bereinigungsschritt, der Kennungen entfernt, laut seinem Trust Center. Die generativen Funktionen sind ein Sonderfall.
• Gorgias ist ungewöhnlich direkt: „Our AI Agent does learn from interactions from other brands“, mit Schutzmaßnahmen gegen Datenabfluss, sagt die AI-Agent-Sicherheits-FAQ. Diese Offenheit ist nützlich. Sie bedeutet aber auch, dass der Agent eines Wettbewerbers von Ihrem Ticketverlauf profitieren kann, was manche Marken akzeptieren und andere nicht.
• Freshworks bietet ein Opt-out vom Training, das aber per E-Mail an support@freshworks.com läuft, laut seinem Freddy AI Data Processing Framework. Lassen Sie sich die Bestätigung schriftlich geben.

Dann gibt es die Aufbewahrung beim Modellanbieter. „Zero Data Retention“ heißt, dass der Anbieter nach der Antwort nichts behält. Zendesk, Salesforce und Front beanspruchen das alle für ihre generativen Funktionen. Die AI-Assist-Doku von Help Scout sagt, OpenAI speichere Daten „for up to 30 days.“ Dreißig Tage sind für die meisten Teams kein Ausschlusskriterium, aber es ist eine Zahl, mit der Ihr DPA übereinstimmen sollte.

Auf der Seite von eesel: Wir trainieren oder fine-tunen keine Modelle mit Ihren Daten, und die vier Open-Model-Hoster auf unserer Subunternehmerliste arbeiten mit Zero Data Retention. Bei Anthropic, OpenAI und Google verlassen wir uns auf deren kommerzielle API-Bedingungen, die Training mit API-Daten nicht erlauben. Wenn Sie für diese drei eine Aufbewahrungszahl schriftlich brauchen, fragen Sie uns im Rahmen des Security-Pakets, statt dem Wort eines Blogbeitrags zu vertrauen.

Wohin geht ein Ticket tatsächlich?

Stellen Sie sich eine Kunden-E-Mail vor. Sie landet in Ihrem Helpdesk, wird zum KI-Anbieter synchronisiert, an einen Modellanbieter geschickt und in einem Suchindex (oft eine Vektordatenbank) und einigen Logs gespeichert. Jede Station ist ein Ort, an dem sie aufbewahrt, kopiert oder über eine Grenze bewegt werden kann.

Nach Artikel 28 der DSGVO ist der Modellanbieter ein Unterauftragsverarbeiter, und der Anbieter darf keinen hinzufügen, ohne Sie zu informieren und Ihnen die Möglichkeit zum Widerspruch zu geben. Die Subunternehmerliste ist also ein Rechtsdokument, keine Formalie. Hier zeigt sich auch die Abweichung. Die FAQ von Gorgias sagt, der AI Agent nutze „OpenAI, Anthropic, and internally fine-tuned LLMs“, während die Subunternehmerliste, zuletzt am 30. März 2026 überarbeitet, OpenAI als einzigen KI-Anbieter aufführt. Die Liste von Help Scout ist auf Januar 2025 datiert. Keines von beiden ist zwingend falsch (ein bei einem Cloud-Anbieter gehostetes Modell kann rechtlich unter der Zeile dieses Cloud-Anbieters stehen, genau so erklärt Salesforce seine Nutzung von Anthropic), aber es ist eine Frage wert.

Datenresidenz ist die andere Hälfte, und hier steckt das Kleingedruckte. Jeder dieser Punkte ist vom Anbieter selbst dokumentiert:

• HubSpot: Für die Rechenzentren in Australien und Kanada zeigt jede KI-Anbieter-Zeile auf seiner Subprozessor-Seite „United States.“ Das EU-Rechenzentrum hält die KI-Verarbeitung im Europäischen Wirtschaftsraum.
• Salesforce: Wenn die Endpunkte in der Region nicht antworten, „the request falls back to Azure OpenAI in the United States.“ Das abzuschalten erfordert zuerst Data 360, laut seiner Doku zum geo-aware Routing.
• Freshworks: Bei Konten in Indien, Australien und Naher Osten/Afrika werden manche Funktionen in den USA verarbeitet, aber „AI features that require data processing outside your primary hosting region are disabled“ standardmäßig. Dieser Standard ist gut. Mehr zu Freddy im Leitfaden zur Datenresidenz bei Freshdesk.
• Zendesk: KI-Nutzung „does not impact any Customer data locality commitments“, außer dass zugekaufte Produkte wie AI Agents - Advanced „may remain on“ Google Cloud in den USA oder Europa „for a period of time“, laut Trust Center.
• Front: Sie wählen US- oder EWR-Hosting, aber Daten „may be otherwise processed“ außerhalb davon „as reasonably necessary“, laut seiner Hosting-Richtlinie.

Nichts davon ist versteckt. Alles steht auf den eigenen Seiten der Anbieter, was ihnen zugutekommt. Es steht nur nicht auf der Seite, die Ihr Vertriebsmitarbeiter Ihnen schickt. Bei eesel läuft die Produktion standardmäßig auf AWS in den USA (N. Virginia), und unser Trust Center knüpft volle EU-Datenresidenz, einschließlich KI-Verarbeitung, an den Enterprise-Tarif. Bestätigen Sie den Tarif, bevor Sie etwas annehmen.

Was darf der Agent in Ihrem Helpdesk tun?

Diesen Abschnitt würde ich am längsten besprechen, denn hier entsteht der echte Schaden. OWASP nennt es Excessive Agency: schädliche Aktionen als Reaktion auf „unexpected, ambiguous or manipulated outputs.“ Die drei Grundursachen sind zu viel Funktionalität, zu viele Berechtigungen und zu viel Autonomie. Auf den Support übertragen ist das ein Agent, der Rückerstattungen auslösen kann, obwohl er nur Bestellungen nachschlagen sollte.

Auch die Rechtslage hat aufgeholt. In Moffatt v. Air Canada wies ein Tribunal in British Columbia das Argument der Fluggesellschaft zurück, ihr Chatbot sei für seine eigenen Worte verantwortlich: „It makes no difference whether the information comes from a static page or a chatbot.“ Der Schadensersatz war klein ($812.02 CAD insgesamt), und es ist ein Tribunal-Urteil, kein bindendes Fallrecht. Doch das Prinzip gilt überall: Was Ihr Agent sagt und tut, geht auf Ihre Rechnung.

Die Frage an den Anbieter ist also konkret: Zeigen Sie mir die Berechtigungsliste, und zeigen Sie mir, was passiert, bevor etwas Unumkehrbares läuft.

Das dokumentieren die Anbieter:

• Gorgias hat einen guten Standard. Bei unumkehrbaren Aktionen „like canceling an order or skipping a subscription, Customer confirmation is turned on automatically“, und sie auszuschalten heißt, zu bestätigen, dass man es versteht, laut seiner Aktions-Doku. Mehr in unserer Übersicht zu den Aktionen des Gorgias AI Agent.
• HubSpot gibt jeder Aktion des Customer Agent eine Schutzstufe None, Match email oder Verify email und rät, dass Änderungen am Kontozugang sichere Links senden sollten, statt direkt zu handeln, laut seiner Einrichtungsanleitung. Unser Leitfaden zu Breeze-Leitplanken behandelt die Eskalationsseite.
• Salesforce lässt Agenten „respect standard Salesforce access controls“, und eigene Aktionen erben die Berechtigungen des Flows oder der Apex-Klasse dahinter, laut Trust and Agentforce. Mächtig, aber es heißt, dass Ihre Salesforce-Berechtigungshygiene jetzt Ihre KI-Berechtigungshygiene ist.
• Freshworks sagt, sein Agent „stays within predefined flows“, laut dem Freddy AI Trust Framework. Fragen Sie, wie das im Admin-Bereich aussieht.

Beachten Sie die zwei unterschiedlichen Formen: Gorgias und HubSpot lassen den Kunden bestätigen, während eine Freigabe-Warteschlange Ihr Team fragt. Die Kundenbestätigung stoppt einen Angreifer, der nicht der Kontoinhaber ist. Sie stoppt nicht, dass der Agent eine schlechte Entscheidung trifft, die der echte Kunde gern annimmt, etwa eine Rückerstattung außerhalb der Richtlinie. Bei Aktionen, die Geld bewegen, will ich eine Person aus Ihrem Team in der Schleife haben, zumindest in den ersten Monaten. Unser Leitfaden zu Freigabe-Workflows im Support geht tiefer darauf ein, wo man die Grenze zieht.

Hier bin ich bei eesel am meisten festgelegt. Jede Aktion ist eine Berechtigung, pro Agent auf Auto, Freigabe nötig oder Deaktiviert gestellt, und die Doku zu Aktionen und Freigaben empfiehlt, „refunds, cancellations and anything that costs money behind an approval“ zu halten. Freigaben laufen nach einem Timeout nie von selbst, Viewer können nicht freigeben, und jede Freigabe hält fest, wer wann entschieden hat.

Zwei weitere Dinge sollte ein Prüfer hier checken. Erstens Zugangsdaten: Bei eesel gehen ausgehende Anfragen nur an Domains, die Sie unter Network Access freigegeben haben, und der Auth-Header wird serverseitig angehängt, sodass „a manipulated agent can't read out a key or token because it never had one.“ Zweitens jeder andere Zugang. eesel hat eine CLI (npx @eesel/cli), mit der eine Person, ein Skript oder ein Coding-Agent wie Claude Code oder Cursor mit dem Teammate chatten, Wissen hochladen, Automatisierungen verdrahten und die Freigabe-Warteschlange mit eesel approvals leeren kann. Jeder Workspace ist außerdem ein Model Context Protocol-Server. Der Sicherheitspunkt: CLI- und MCP-Schreibzugriffe „follow the same action permissions as everything else“, sodass eine zurückgehaltene Aktion zurückgehalten bleibt, egal durch welche Tür sie kam. Stellen Sie jedem Anbieter dieselbe Frage zu seiner API.

Der Umfang zählt so viel wie die Berechtigungen. Adverscale, das Menschen bei US-Passanträgen hilft, lässt seinen Zendesk-Agenten nur laufen, wenn eine Person @eesel in eine interne Notiz schreibt, und „She never decides a refund.“ XAP, ein Bildungssoftware-Unternehmen, das mit US-Bundesstaaten und Colleges arbeitet, setzt einen Filter vor seinen Freshdesk-Agenten, sodass nur Vermittlungsfälle und Passwort-Zurücksetzungen im Portal durchkommen.

Kann eine Kunden-E-Mail den Bot zu etwas überreden?

Möglicherweise ja, und gute Anbieter sagen das, statt Immunität zu behaupten. OWASP führt Prompt Injection als Risiko Nummer eins und hält fest, dass eingeschleuste Anweisungen „do not need to be human-visible/readable, as long as the content is parsed by the model.“ Für einen Support-Agenten heißt das: weißer Text in einer E-Mail, eine Zeile in einem PDF-Anhang oder ein vergifteter Hilfeartikel. OWASP merkt auch an, dass Retrieval-Augmented Generation und Fine-Tuning es „do not fully mitigate.“ Unser Glossareintrag zu Prompt Injection hat die verständliche Version.

Was Anbieter dokumentieren:

• Freshworks prüft Eingaben mit „Azure AI Content Safety and Prompt Shields“ (Freddy AI Trust Framework).
• Salesforce hat „Prompt Defense“, beschrieben als Systemrichtlinien plus Erkennung von Prompt Injection (Trust and Agentforce).
• Front führt in seinem Trust Center einen Bericht „Front AI Pentest 2026“ auf, genau die Art Dokument, die ich bei jedem Anbieter anfordern würde.
• Zendesk, HubSpot, Gorgias und Help Scout beschreiben auf den von mir geprüften Seiten keine Abwehr gegen Prompt Injection. Das heißt nicht, dass keine existiert. Es heißt, dass Sie fragen müssen.

Die ehrliche Antwort: Filter senken das Risiko, Berechtigungen begrenzen den Schaden. Die Sicherheits-FAQ von eesel sagt es gut: „the protection isn't that the model can't act. It's that what it can act on is bounded, and you set the bounds.“ Eine Aktion, die Sie nicht eingeschaltet haben, steht dem Modell gar nicht zur Verfügung, egal was eine E-Mail ihm sagt. Wenn Sie das vor der Unterschrift selbst testen wollen, enthält unser Leitfaden zu Adversarial Testing Test-Prompts, die einen Versuch wert sind.

Sensible Daten sind das Schwesterrisiko. OWASPs Sensitive Information Disclosure umfasst personenbezogene Daten, Finanzdetails, Gesundheitsakten und Zugangsdaten. Die Falle, die ich am häufigsten sehe: anzunehmen, dass die PII-Maskierung eines Anbieters den KI-Agenten abdeckt. Salesforce ist hier erfrischend offen: Muster- und feldbasierte Maskierung „is disabled for agents“, und die Datenschutz-FAQ sagt, das geschehe „to improve performance and accuracy of agents“ (Data Masking Limitations in Agentforce). Die automatische Schwärzung und Maskierung von Zendesk steckt im ADPP-Add-on für Enterprise-Tarife.

Ich messe eesel am selben Maßstab. Unsere PII-Schwärzung deckt 15 Kategorien ab (Karten, Sozialversicherungsnummern, Bankdaten, API-Schlüssel, Namen, Adressen und mehr) bei alten Tickets, bevor sie gespeichert oder indexiert werden, und sie schlägt geschlossen fehl: Tickets, die sie nicht schwärzen kann, werden übersprungen, nicht roh indexiert. Aber sie ist pro Integration opt-in, bei neueren Workspaces standardmäßig aus und gilt nicht für Live-Gespräche. Wenn der Agent ein Ticket live abruft, um eine Antwort zu entwerfen, erreicht das rohe Ticket das Modell. Wenn Ihnen das wichtig ist, gehört es ins DPA-Gespräch. Unser Leitfaden zum Schwärzen von PII in Support-Transkripten behandelt die weiteren Optionen.

Können Sie danach jede Antwort und Aktion nachvollziehen?

Ein Audit-Trail macht aus „wir glauben, der Agent hat sich richtig verhalten“ ein „das hat er bei Ticket 4,812 getan, und das war der Grund.“ Er fehlt für KI auch am häufigsten. Das allgemeine Admin-Audit-Log ist üblich. Ein Log dessen, was die KI getan hat, nicht:

• Fronts Audit-Log gibt es in jedem Tarif, aber seine gelisteten Quellen sind Admin Copilot, API, Applications, SCIM und Teammates. Autopilot gehört nicht dazu.
• HubSpots Aktivitätsverlauf „only records HubSpot-user based actions.“
• Zendesks Audit-Log gibt es für Enterprise-Tarife und höher. Für Custom Agents zeigt es laut Zendesk, „how an agent arrived at its responses or decisions.“
• Salesforce protokolliert Prompts, Antworten und Trust-Signale in Data 360, mit einem Audit-Trail ab Enterprise mit einem Einstein-Add-on. Auf dem Papier der vollständigste der sieben.
• Gorgias lässt Sie „view every single answer AI Agent sends, including the knowledge sources it pulls from“, laut seiner FAQ.

In eesel listet Activity jeden Lauf in jedem Kanal: was ihn ausgelöst hat, welches Wissen er gelesen hat, welche Aktionen er ausgeführt hat und seine Begründung. Sie können nach freigegeben, abgelehnt und ausstehend filtern.

Transparenz vor dem Start zählt so viel wie danach. Die sicherste Prüfung, die ich gesehen habe, endet damit, dass der Agent auf Ihren eigenen gelösten Tickets läuft, ohne dass etwas gesendet wird, sodass Ihr Sicherheitsteam und Ihre Support-Leitungen echte Antworten statt eines Demo-Skripts beurteilen. Der Simulationsbericht von eesel macht das mit 20 kürzlich gelösten Tickets, und unsere Leitfäden zum Testen eines KI-Agenten vor dem Start und zum Durchführen eines KI-Support-Piloten zeigen den Rest. Es ist auch die beste Verteidigung gegen KI-Halluzinationen: Der Agent von XAP „never invents a URL, a fee, a date or a policy“ und lässt einen Platzhalter für das Team, wenn er ein Detail nicht belegen kann.

Wie schneiden die 7 Helpdesk-Anbieter auf dem Papier ab?

Hier die Vertragsseite in einer Tabelle, aus dem Trust Center, dem DPA und den Hilfedokumenten jedes Anbieters, geprüft am 20. Oktober 2026. „Not stated“ heißt, ich habe es auf den öffentlichen Seiten nicht gefunden, nicht dass es nicht existiert.

Zwei Zeilen dieser Tabelle verdienen einen zweiten Blick. Erstens die Meldefristen. Artikel 33 der DSGVO gibt Ihnen als Verantwortlichem 72 Stunden, um die Aufsichtsbehörde zu informieren, verlangt vom Auftragsverarbeiter aber nur, Sie „without undue delay“ zu informieren. Wenn der Vertrag Ihres Anbieters dasselbe sagt, kann Ihre 72-Stunden-Uhr schon laufen, bevor Sie es überhaupt wissen. Fragen Sie nach einer Zahl in Stunden.

Zweitens HIPAA. Dass Help Scout einen separaten AI Feature Healthcare Addendum verlangt, ist tatsächlich ein gutes Muster, weil es die Frage erzwingt, die viele Gesundheitskunden vergessen: Deckt der BAA die KI ab oder nur das Postfach? Unser Leitfaden zu HIPAA-konformer KI und der Beitrag KI-Kundenservice für das Gesundheitswesen gehen weiter. Wenn Sie speziell auf einem dieser Helpdesks sind, haben wir auch Zendesk-Sicherheit und Compliance, Freshdesk SOC 2 und Gorgias SOC 2 ausführlicher beschrieben.

Noch ein Gesetz für die Liste. Artikel 50 des EU AI Act verlangt, dass KI-Systeme, die mit Menschen sprechen, diesen sagen, dass sie mit einer KI sprechen, sofern es nicht offensichtlich ist, und diese Pflicht gilt seit dem 2. August 2026. Wenn Sie EU-Kunden bedienen, prüfen Sie, ob der Anbieter Sie diesen Hinweis festlegen lässt.

Wie führen Sie die Prüfung durch, ohne das Projekt auszubremsen?

Sicherheitsprüfungen für KI-Tools sterben meist in einer Warteschlange, nicht an einem „Nein“. So würde ich sie ablaufen lassen, meist innerhalb von zwei Wochen:

1. Fordern Sie das Paket am ersten Tag an. SOC-2-Bericht oder Audit-Zeitplan, DPA, Subunternehmerliste und ein ausgefülltes CSA AI-CAIQ oder SIG Lite. Ein Anbieter, der eine Woche braucht, um diese zu schicken, sagt Ihnen damit etwas.
2. Gehen Sie die 10 kritischen Punkte oben in einem Gespräch durch. Training, kundenübergreifendes Lernen, Aufbewahrung, Modellanbieter, Berechtigungen pro Aktion, Freigaben für Geldbewegungen, Prompt Injection, das Aktionslog, SOC-2-Umfang. Lassen Sie sich die Antworten danach schriftlich geben.
3. Zeichnen Sie den Datenpfad für Ihre Region. Zeichnen Sie die fünf Stationen aus dem Diagramm oben mit den echten Antworten des Anbieters. Hier tauchen Residenz-Ausnahmen auf.
4. Starten Sie den Agenten im Entwurfsmodus. Nur interne Notizen, nichts geht an Kunden. Timengo, ein dänischer Anbieter sicherer E-Mail, zu dessen Kunden Gemeinden und Schulen gehören, betreibt eesel so auf Freshdesk: „The engineer sends; eesel does not.“
5. Erweitern Sie Berechtigungen Aktion für Aktion. Beobachten Sie das Log, stellen Sie dann Tagging auf automatisch, dann erste Antworten, und halten Sie Rückerstattungen am längsten hinter einer Freigabe.

Wenn Sie noch entscheiden, ob Sie überhaupt kaufen, behandelt Build vs. Buy für KI-Support den Eigenbau, und So wechseln Sie den KI-Support-Anbieter hilft, wenn Sie einen ersetzen, der eine Prüfung nicht bestanden hat. Unsere Pilot-Scorecard für KI-Support macht aus Schritt 4 Zahlen für bestanden oder durchgefallen.

eesel mit Ihrer Sicherheitscheckliste testen

Wenn Ihr Team diese Prüfung für einen KI-Agenten auf Zendesk oder Freshdesk durchführt, führen Sie sie auch bei eesel durch. eesel ist ein KI-Helpdesk-Teammate, das in Ihre bestehende Warteschlange auf Zendesk, Freshdesk und anderen Helpdesks einsteigt, mit jeder Aktion auf einer Berechtigungsliste, die Sie kontrollieren, und jedem Lauf, der mit seiner Begründung protokolliert wird. smava, ein Vergleichsportal für Verbraucherfinanzen, betreibt begrenzte eesel-Agenten für zwei Marken auf einem Zendesk, wo „Each agent has one job and a list of things it must never do.“

Das Trust Center zeigt unseren aktuellen Stand, und das Security-Paket (Richtlinien, DPA, CAIQ- oder SIG-Lite-Antworten) gibt es auf Anfrage unter NDA, meist innerhalb eines Werktags. Sie können auch kostenlos mit 100 Credits auf der Preisseite starten und eine Simulation an Ihren eigenen früheren Tickets laufen lassen, bevor jemand etwas unterschreibt. eesel testen.