Aufbewahrungsfristen im Support: Wie lange Tickets bleiben

Wichtige Erkenntnisse

• Die DSGVO fordert das Ende der Speicherung nach Zweckwegfall, HGB und AO erzwingen jedoch die Aufbewahrung.
• Support-Tickets, die Geschäfte anbahnen oder widerrufen, gelten als Handelsbriefe mit einer Frist von sechs Jahren.
• Anhänge durchkreuzen oft Löschkonzepte, da sensible Privatdaten und steuerlich relevante Infos vermischt werden.
• Aufbewahrungspflichtige Tickets müssen aus der aktiven Support-Historie gesperrt und sauber archiviert werden.

DSGVO und HGB: Der grundlegende Fristen-Konflikt

Kundensupport erzeugt täglich hunderte Datensätze: Anfragen zur Bedienung, Reklamationen, Adressänderungen oder Stornierungen. Genau hier treffen zwei Rechtsbereiche frontal aufeinander. Auf der einen Seite fordert die DSGVO nach Art. 5 Abs. 1 lit. e eine strikte Speicherbegrenzung: Personenbezogene Daten müssen gelöscht werden, sobald der ursprüngliche Zweck der Verarbeitung erfüllt ist. Auf der anderen Seite verlangen Handels- und Steuergesetze eine geordnete Archivierung über viele Jahre. Support-Tickets sitzen exakt zwischen diesen Stühlen.

Support-Teams sitzen tagtäglich zwischen zwei juristischen Fronten. Auf der einen Seite steht die europäische Datenschutz-Grundverordnung (DSGVO). Sie verlangt in Artikel 5 Absatz 1 lit. e eine strikte Speicherbegrenzung und in Artikel 17 ein konsequentes Recht auf Löschung, sobald der ursprüngliche Verarbeitungszweck entfallen ist. Auf der anderen Seite stehen das Handelsgesetzbuch (HGB) und die Abgabenordnung (AO), die Unternehmen zu mehrjährigen Aufbewahrungsfristen zwingen: § 257 Absatz 4 HGB nennt zehn Jahre für Handelsbücher und Jahresabschlüsse, acht Jahre für Buchungsbelege und sechs Jahre für die sonstigen Unterlagen wie Handelsbriefe¹; § 147 Absatz 3 AO staffelt die Fristen steuerrechtlich identisch².

Rechtsgrundlagen im direkten Vergleich

Wenn der Verarbeitungszweck auf das Steuerrecht trifft

Im Support-Alltag vermischen sich diese Anforderungen in kürzester Zeit. Ein Kunde eröffnet ein Ticket mit einer einfachen Frage, schickt kurz darauf eine verbindliche Reklamation oder Vertragsanpassung hinterher und fordert drei Monate später die vollständige Bereinigung seines Profils nach dem Leitfaden für Kundendaten löschen. Wer hier unüberlegt alle Daten löscht, riskiert Beanstandungen bei der nächsten Betriebsprüfung. Wer hingegen alle Tickets auf unbestimmte Zeit im System belässt, verstößt systematisch gegen das Datenschutzrecht.

Die Herausforderung für dein Team: Ein Ticketsystem ist kein statisches Archiv, sondern ein dynamischer Kanal. Wenn Kund:innen ihre Kundendaten löschen lassen möchten, darfst du nicht blind die gesamte Historie vernichten. Löschst du vertragsrelevante Absprachen vorzeitig, drohen steuer- und handelsrechtliche Sanktionen. Bewahrst du hingegen einfache Beratungsgespräche zehn Jahre lang auf, liegt ein klarer DSGVO-Verstoß vor. Die Praxis erfordert deshalb eine saubere Kategorisierung statt pauschaler Regeln.

Welche Support-Tickets als Handelsbriefe gelten

Ein Support-Ticket ist kein homogenes Dokument, sondern ein dynamischer Kommunikationsverlauf. Support-Leads und Datenschutzbeauftragte müssen daher genau differenzieren, wo die Grenze verläuft zwischen flüchtiger technischer Hilfestellung und rechtlich bindendem Handelsdokument.

Nicht jede Support-Nachricht unterliegt gesetzlichen Aufbewahrungsfristen. Wenn Kund:innen nach Öffnungszeiten fragen oder ein vergessenes Passwort melden, endet der Verarbeitungszweck unmittelbar mit der Lösung des Falls. Anders liegt der Fall, sobald eine Unterhaltung den Vertrag selbst berührt. Nach § 257 Abs. 2 HGB sind Handelsbriefe alle Schriftstücke, die ein Handelsgeschäft betreffen. In der Praxis fällt darunter auch Korrespondenz, die ein Geschäft anbahnt, abwickelt oder rückabwickelt. Wer Support-Daten pauschal nach wenigen Wochen löscht, riskiert empfindliche Verstöße gegen handelsrechtliche Nachweispflichten.

Abgrenzung: Information, Handelsbrief und Buchungsbeleg

Nicht jede Kundenanfrage ist ein Handelsbrief. Entscheidend ist der inhaltliche Gegenstand der Korrespondenz. § 257 Absatz 2 HGB definiert wörtlich: Handelsbriefe sind nur Schriftstücke, die ein Handelsgeschäft betreffen. Für Support-Teams bedeutet das: Die rechtliche Einstufung hängt nicht vom Kommunikationskanal ab, sondern von der getroffenen geschäftlichen Vereinbarung.

Für die rechtliche Einstufung ist allein der Inhalt maßgeblich, nicht das verwendete Ticket-Tool oder der Eingangskanal. Support-Teams müssen zwischen drei Stufen differenzieren:

Drei Kategorien im Posteingang

Handels- und steuerrechtlich lassen sich Tickets in drei Kernkategorien unterteilen. Tickets zur Anbahnung, Abwicklung oder Rückgängigmachung eines Vertrags gelten als Handelsbriefe. Hier greift nach § 257 Absatz 4 HGB eine gesetzliche Aufbewahrungsfrist von sechs Jahren¹. Enthält das Ticket eine Rechnung, einen Zahlungsbeleg oder eine steuerlich relevante Gutschrift, handelt es sich um einen Buchungsbeleg. Für Buchungsbelege nennt § 147 Absatz 3 AO eine Frist von acht Jahren².

In der Praxis vermischen sich diese Kategorien häufig. Eine simple Frage zur Bedienung mündet in einer Reklamation oder einer Kulanzgutschrift. Sobald ein Vorgang geschäftliche Verbindlichkeit erlangt, greift die Pflicht zur Archivierung. Nach § 257 Absatz 5 HGB beginnt die Aufbewahrungsfrist erst mit dem Schluss des Kalenderjahres, in dem der Handelsbrief empfangen oder abgesandt wurde. Ein Ticket aus dem März 2024 muss somit bis zum 31. Dezember 2030 archiviert bleiben. Wer beim Thema Kundendaten löschen eine pauschale Frist ansetzt, verletzt entweder die DSGVO durch unnötige Vorhaltung oder das HGB durch voreilige Löschung.

• Handelsbriefe (6 Jahre): Angebote, Auftragsbestätigungen, Reklamationen, Kündigungen, Lieferverzögerungen und Vereinbarungen über Preisnachlässe.
• Buchungsbelege (8 Jahre): Rechnungsdokumente, Gutschriften, Stornobelege und Zahlungsnachweise, die als Grundlage für Buchungssätze dienen.
• Reiner technischer Support (keine HGB-Pflicht): Passwort-Resets, Bug-Meldungen, allgemeine Bedienungsfragen oder Feature-Anfragen ohne Bezug zu konkreten Vertragskonditionen.

Routine-Anfragen: Wann sofort gelöscht werden muss

Reine Support-Tickets, die keinen Vertrag vorbereiten oder modifizieren, unterliegen keiner kaufmännischen Aufbewahrungspflicht. Sie dürfen und müssen gelöscht werden, sobald das Anliegen geklärt ist und eventuelle Nachfragen oder Gewährleistungsfristen abgelaufen sind. Wer hierfür sauber Support-Tickets kategorisieren kann, schafft die Grundlage für jede verlässliche Datenhygiene.

Viele Support-Teams behandeln alle Tickets gleich: Kommt eine Nachricht rein, bleibt sie jahrelang im Helpdesk liegen. Für Routine-Anfragen ist das datenschutzrechtlich unzulässig. Nach dem Grundsatz der Speicherbegrenzung gemäß Art. 5 Abs. 1 lit. e DSGVO dürfen personenbezogene Daten nur so lange gespeichert werden, wie es für den ursprünglichen Verarbeitungszweck erforderlich ist. Sobald die Frage beantwortet und der Vorgang abgeschlossen ist, entfällt dieser Zweck vollständig.

Die Falle im Posteingang: Warum Anhänge Probleme machen

Kein Handelsbrief, keine Aufbewahrungspflicht

Ticketsysteme leiden chronisch unter unstrukturierten Daten. Kundinnen und Kunden schildern ihre Probleme selten im genormten Format. Sie hängen Screenshots, PDF-Dokumente oder Fotos an. Was als gut gemeinte Hilfestellung beginnt, verwandelt sich im Posteingang schnell in ein handfestes Datenschutzrisiko.

Typische Routine-Anfragen besitzen weder steuerliche noch vertragsbegründende Relevanz. Dazu gehören Passwort-Resets, Fragen zu allgemeinen Funktionen, Auskünfte vor einem Kauf ohne Vertragsabschluss oder kurze Hinweise auf Tippfehler. Weder das Handelsgesetzbuch noch die Abgabenordnung fordern dafür eine mehrjährige Archivierung. Wer solche Tickets jahrelang vorhält, betreibt de facto eine rechtswidrige Vorratsdatenspeicherung. Wenn Betroffene später Kundendaten löschen lassen oder Auskunft verlangen, vergrößern ungelöschte Altfälle zudem den manuellen Suchaufwand.

Sensible Daten in unbeachteten Dateien

• Passwort-Resets und Login-Hilfe: Löschung unmittelbar nach Abschluss oder nach einer Sicherheitsfrist von maximal 30 bis 90 Tagen.
• Allgemeine Vorab-Fragen: Reine Informationsanfragen ohne Kundenkonto oder Bestellbezug direkt nach Klärung entfernen.
• Feedback und Fehlerberichte: Inhaltliche Produktinformationen anonymisiert in das Issue-Tracking übertragen, das ursprüngliche Ticket mit den Kundendaten danach bereinigen.

Häufig landen in Ticket-Anhängen sensible Informationen, die für die eigentliche Problemlösung gar nicht benötigt werden: Ausweiskopien bei förmlichen Auskunftsersuchen, Screenshots mit fremden Kundendaten, Bankverbindungen oder besondere Datenkategorien nach Artikel 9 DSGVO wie Gesundheitsangaben. Wenn ein Ticket aufgrund steuerlicher Relevanz sechs oder acht Jahre archiviert werden muss, lagern diese sensiblen Beifänge unbemerkt in den Schatten-Ablagen deines Systems.

Klare Löschregeln schützen dein Unternehmen vor DSGVO-Verstößen und halten den Datenbestand sauber. Entscheidend ist, Routine-Tickets von geschäftsrelevanten Vorgängen wie Reklamationen oder Rechnungsfragen frühzeitig zu trennen, statt den gesamten Posteingang pauschal zu archivieren.

• Ausweiskopien: Nach erfolgter Identitätsprüfung für ein Auskunfts- oder Löschersuchen besteht kein legitimer Zweck mehr für die Speicherung der Ausweisdatei.
• Screenshots mit Drittdaten: Aufnahmen von internen Systemen oder Browserfenstern enthalten regelmäßig Namen und Kennungen unbeteiligter Dritter.
• Kreditkarten- und Bankdaten: Vollständige Zahlungsdaten dürfen aus Sicherheits- und Datenschutzgründen keinesfalls dauerhaft im Ticketverlauf archiviert werden.
• Besondere Datenkategorien: Ärztliche Nachweise oder Atteste bei Kulanzanfragen unterliegen dem strengen Schutz des Art. 9 DSGVO und erfordern gesonderte Löschroutinen.

Ein Löschkonzept, das ausschließlich auf Ticket-Ebene operiert, greift hier zu kurz. Wenn die Aufbewahrung des Vorgangs handelsrechtlich geboten ist, müssen die sensiblen Anhänge separat bereinigt oder unkenntlich gemacht werden. Andernfalls hebelt ein einzelner Anhang dein gesamtes Löschkonzept aus.

Kund:innen schicken im Support oft weit mehr als nötig: Ausweisfotos zur Identitätsprüfung, Verträge mit Drittdaten oder Gehaltsabrechnungen als Beleg. Das Problem: Während die eigentliche Konversation unter handelsrechtliche Aufbewahrungspflichten oder berechtigte Nachweisinteressen fallen kann, gilt das für unaufgefordert mitgesendete Dokumente fast nie. Wer Dateianhänge pauschal an den Ticketverlauf koppelt, verstößt direkt gegen das Prinzip der Datenminimierung nach Art. 5 Abs. 1 lit. c DSGVO.

Einschränken statt Löschen: Das Prinzip der Sperrung

Trennung von Text und Datei

Wenn eine betroffene Person die Löschung ihrer Daten verlangt, aber gesetzliche Aufbewahrungsfristen entgegenstehen, geraten Teams oft in Unsicherheit. Die DSGVO sieht für genau diesen Konflikt eine praxistaugliche Regelung vor: die Einschränkung der Verarbeitung nach Artikel 18 DSGVO sowie die Ausnahmebestimmung in Artikel 17 Absatz 3 lit. b DSGVO.

Ein funktionierendes Löschkonzept behandelt Nachrichtentexte und Datei-Uploads als getrennte Datenobjekte. Sobald ein Ausweisdokument oder ein Vertrag gesichtet und der Vorgang bearbeitet ist, entfällt der Verarbeitungszweck für die Rohdatei. Der Anhang muss gelöscht werden, während das Ticket als Prüfpfad bestehen bleibt. Ein Systemvermerk wie „Identität am TT.MM.JJJJ verifiziert“ genügt der Dokumentationspflicht vollständig. Wenn Teams Prozesse für Kundendaten löschen aufsetzen, gehört diese technische Entkopplung an die erste Stelle.

Vom operativen Postfach in das gesicherte Revisionsarchiv

• Automatische Ablaufzeiten: Dateianhänge erhalten eine strikte Speicherfrist (z. B. 7 bis 14 Tage nach Ticketschließung) und werden danach automatisch vom Server entfernt.
• Gezieltes Strippen per Klick: Support-Mitarbeitende müssen sensible Anhänge direkt nach der Bearbeitung einzeln löschen können, ohne den gesamten Ticketverlauf zu vernichten.
• Prävention am Eingabekanal: Datei-Uploads im Chat-Widget auf notwendige Formate beschränken und Nutzer aktiv auffordern, unbeteiligte Daten und Ausweisnummern vor dem Upload zu schwärzen.

Das Prinzip der Sperrung trennt den operativen Zugriff vom reinen Prüfungszugriff. Nach dem Schließen eines geschäftsrelevanten Vorgangs erlischt der primäre Support-Zweck. Die Daten verbleiben zwar im System, werden aber für das operative Team unzugänglich geschaltet. Sie tauchen nicht mehr in der täglichen Kundensuche auf, fließen in keine Marketingauswertungen ein und können nicht beliebig eingesehen werden.

Bleiben Anhänge dauerhaft im Ticketsystem liegen, sammeln sich über Jahre Tausende ungesicherte Identitätsnachweise an. Das bläht den Datenbestand unnötig auf und verwandelt jeden Sicherheitsvorfall in ein schwerwiegendes Compliance-Risiko.

1. 01Phase 1 - Operativ aktiv: Das Ticket ist offen oder in Bearbeitung. Das Support-Team hat vollen Lese- und Schreibzugriff für die Kundenbetreuung.
2. 02Phase 2 - Zweckbindung beendet (Soft Close): Das Anliegen ist gelöst. Daten bleiben für eine definierte Übergangsfrist für Rückfragen im Team einsehbar.
3. 03Phase 3 - Gesperrt und isoliert (Archivierung): Der operative Zugriff wird entzogen. Die Daten bleiben ausschließlich für Wirtschaftsprüfer, Steuerberater und Datenschutzbeauftragte abrufbar.
4. 04Phase 4 - Endgültige Löschung: Nach Ablauf der sechs Jahre für Handelsbriefe nach § 257 Absatz 4 HGB¹ bzw. der acht Jahre für Buchungsbelege nach § 147 Absatz 3 AO² werden Daten und Metadaten automatisiert und unwiderruflich vernichtet.

Das Löschkonzept: Von der Richtlinie zur Realität

Die Sperrung ist keine bloße Formalie. Die DIN 66398 gibt als Leitlinie für Löschkonzepte vor, für jede Datenart genau eine Löschregel aus Regellöschfrist und Startzeitpunkt festzulegen³. Im Ticketsystem ist die Sperrung die technische Umsetzung dieser Logik: Sie stellt sicher, dass Unternehmen gesetzliche Aufbewahrungspflichten erfüllen, ohne das Recht auf informationelle Selbstbestimmung zu verletzen.

Ein Löschkonzept existiert in vielen Unternehmen nur als PDF im Datenschutzordner. Auf dem Papier klingt der Plan einfach: Nach Wegfall des Verarbeitungszwecks und Ablauf gesetzlicher Aufbewahrungsfristen werden personenbezogene Angaben entfernt. Im Support-Alltag greift das selten. Agenten bearbeiten Tickets, schließen Vorgänge ab und widmen sich der nächsten Anfrage. Niemand öffnet nach Monaten alte Konversationen, um Daten manuell zeilenweise zu bereinigen. Wenn du Kundendaten löschen musst, scheitert die reine Papierform an den operativen Abläufen des Helpdesks.

Anonymisierung als Alternative zur Volllöschung

Manuelle Tabellen und verpasste Fristen

Vollständiges Löschen vernichtet nicht nur personenbezogene Daten, sondern oft auch wichtiges Prozesswissen. Support-Teams benötigen historische Falldaten, um Fehlerschwerpunkte im Produkt zu analysieren, Reaktionszeiten zu messen und Wissensartikel gezielt auszubauen. Eine datenschutzkonforme Alternative zur restlosen Vernichtung ist die echte Anonymisierung.

Versuchen Teams, Löschtermine über Tabellen oder Kalender-Erinnerungen zu verwalten, entstehen typische strukturelle Schwachstellen. Etablierte Standards wie die DIN 66398 fordern deshalb feste Löschregeln mit definierten Startzeitpunkten und automatischer Ausführung³:

Wann Daten datenschutzrechtlich wirklich anonym sind

• Lücke zwischen Papier und Praxis: Die Richtlinie definiert abstrakte Löschklassen, aber kein technischer Prozess setzt sie im Posteingang durch. Aufgeschrieben ist nicht umgesetzt.
• Menschliche Fehler: Bei manueller Bearbeitung werden Tickets übersehen, falsch kategorisiert oder Anhänge vergessen. Fristen verstreichen unbemerkt.
• Fehlende Skalierbarkeit: Mit wachsendem Ticketvolumen vervielfacht sich der Kontrollaufwand. Manuelle Bereinigungen bleiben im Tagesgeschäft als Erstes liegen.

Nach Erwägungsgrund 26 der DSGVO gelten die Grundsätze des Datenschutzes nicht für anonyme Informationen. Entscheidend ist der technische Unterschied zur bloßen Pseudonymisierung: Bei pseudonymisierten Daten lässt sich der Personenbezug durch zusätzliche Zuordnungstabellen wiederherstellen. Bei einer echten Anonymisierung muss die Re-Identifizierung mit verhältnismäßigen Mitteln technisch unmöglich sein.

Ein Löschkonzept entfaltet rechtliche Sicherheit erst durch technische Durchsetzung. Wer Fristen nicht automatisiert im System hinterlegt, verlagert Datenschutzrisiken auf manuelle Kontrollen, die im Alltag verlässlich scheitern.

• Kopfdaten bereinigen: Name, E-Mail-Adresse, Telefonnummer, IP-Adresse und Anschrift werden unwiderruflich überschrieben.
• Freitexte filtern: Automatische Erkennung und Schwärzung von Klarnamen, individuellen Kennungen und Adressangaben im Nachrichtentext.
• System-IDs entkoppeln: Interne Kundennummern und Ticket-Verknüpfungen werden von den operativen CRM- und Datenbankeinträgen getrennt.
• Statistiken aggregieren: Tickets werden nur noch als anonyme Zähleinheit in Sachkategorien geführt, ohne Rückschluss auf einzelne Personen.

Fristen im Ticketsystem technisch durchsetzen

Anonymisierte Support-Tickets unterliegen weder der Löschpflicht noch den Speicherbeschränkungen der DSGVO. Sie können dauerhaft aufbewahrt werden, um Wissensdatenbanken zu trainieren oder Qualitätstrends über mehrere Jahre hinweg zu vergleichen.

Ein dokumentiertes Löschkonzept schützt vor keinem Bußgeld, wenn im Alltag niemand alte Konversationen bereinigt. Manuelle Prozesse scheitern im Supportbetrieb fast immer an Zeitmangel und wechselnden Zuständigkeiten. Verlässlich wird Datenschutz deshalb erst, wenn die Software die Fristen selbst durchsetzt, statt sie an Kalendererinnerungen zu delegieren. Wer verlässlich Kundendaten löschen will, muss Lösch- und Archivierungsregeln fest in der Systemarchitektur verankern.

Drei Säulen für die technische Umsetzung

Ein Löschkonzept auf dem Laufwerk des Datenschutzbeauftragten schützt vor keinem Bußgeld, wenn es im Support-Alltag niemand umsetzt. Manuelle Löschaufträge, bei denen Mitarbeiter am Monatsende alte Tickets per Hand aussortieren, scheitern in der Praxis verlässlich. Sie erzeugen unnötigen Arbeitsaufwand und sind fehleranfällig.

• Automatischer Statuswechsel: Tickets dürfen nach Lösung eines Falls nicht unbegrenzt offen bleiben. Eine definierte Regel schließt Konversationen nach einer festen Frist ohne Rückmeldung (etwa nach 7 Tagen) automatisch ab. Erst mit diesem Statuswechsel startet der exakte Countdown für die definierte Speicherfrist.
• Getrennte Löschung von Dateianhängen: Hochgeladene Screenshots, Protokolldateien oder Dokumente enthalten oft sensible personenbezogene Daten. Eine saubere Konfiguration trennt Anhänge vom Nachrichtentext: Dateien werden bereits nach 30 bis 90 Tagen restlos gelöscht, während der reine Textverlauf bis zum Ablauf der regulären Frist bestehen bleibt.
• Rollenbasierter Archivzugriff: Sobald ein Vorgang gelöst ist, gehört er nicht mehr in die normale Ansicht des Support-Teams. Ein abgestuftes Berechtigungskonzept entzieht operativen Agenten den Zugriff und verschiebt Altfälle in ein geschütztes Archiv, das ausschließlich für Datenschutz- oder Rechtsprüfungen einsehbar ist.

Automatisierte Löschregeln statt manueller Listen

Mit dieser Automatisierung erfüllst du die Vorgaben zur Speicherbegrenzung nach Art. 5 Abs. 1 lit. e DSGVO direkt im System: Personenbezogene Daten dürfen nur so lange in einer identifizierbaren Form gespeichert werden, wie es für den Verarbeitungszweck erforderlich ist⁴. Das reduziert menschliche Fehlerquellen deutlich und hält den aktiven Posteingang frei von veralteten Daten.

Rechtssicherheit entsteht erst, wenn Lösch- und Sperrfristen technisch im Ticketsystem verankert sind. Das System muss Konversationen anhand eindeutiger Kriterien automatisiert durch ihren Lebenszyklus steuern. Als verlässlicher Startpunkt für jede Frist dient dabei der Zeitpunkt, an dem ein Ticket seinen Status auf 'Geschlossen' wechselt.

Durch fest definierte Auslöser und Kategorieregeln verhinderst du, dass dein Datenbestand unkontrolliert wächst. Datenschutz wird damit vom bürokratischen Sonderprojekt zum lautlosen Hintergrundprozess.

ComLayer-Praxis: Fristen objektiv abbilden

Moderne Support-Infrastrukturen müssen von Grund auf so konstruiert sein, dass rechtliche Leitplanken technisch eingehalten werden. Statt getrennte Werkzeuge für Chat, E-Mail, Wissensdatenbank und KI mühsam zu verknüpfen, bündelt ComLayer diese Bausteine in einem zentralen Posteingang.

Klare Statuswechsel und saubere Datenhaltung

Die Einhaltung von Fristen beginnt mit sauberen Statuswechseln: Konversationen werden nach festgelegten Inaktivitätsregeln automatisch geschlossen, wodurch der gesetzliche Fristen-Timer verlässlich startet. Weil alle Konversationen, Wissensquellen und Dateianhänge in europäischen Rechenzentren verarbeitet und gespeichert werden, bleibt die Datenhoheit jederzeit im Geltungsbereich der DSGVO.

• Zentraler Posteingang: E-Mails und Chats laufen in einem einheitlichen Thread zusammen, ohne Daten in unübersichtlichen Drittsystemen zu zerstreuen.
• Strenge Quellentrennung: Der integrierte KI-Agent antwortet ausschließlich auf Basis verifizierter Wissensquellen und vermeidet unautorisierte Zusagen.
• Europäisches Hosting: Konversationen, Wissensbasis und Dateianhänge verbleiben in der EU und unterliegen transparenten Datenschutzvereinbarungen.

Wenn Support-Systeme Datenflüsse von Anfang an transparent strukturieren, wird der Konflikt zwischen HGB-Aufbewahrung und DSGVO-Löschung beherrschbar. Fristen sind kein Widerspruch zur Effizienz, sondern eine Frage der richtigen Softwarearchitektur.

Häufig gestellte Fragen