Kurzantwort: Ein KI-Telefonassistent macht ein Unternehmen nicht NIS2-pflichtig. Ist das Unternehmen nach § 28 BSIG jedoch eine wichtige oder besonders wichtige Einrichtung, gehört ein externer Voice Agent in das Risikomanagement, sobald er für den regulierten Dienst relevant ist. § 30 BSIG nennt ausdrücklich Lieferkettensicherheit, Vorfallbewältigung, Business Continuity, Zugriffskontrolle, Wirksamkeitsprüfung und gesicherte Kommunikation. Der Anbieter muss deshalb nicht nur „sicher sein“, sondern dem Kunden überprüfbare Kontrollen, belastbare Alarmwege und verwertbare Vorfalldaten liefern.
Wann ein KI-Telefonassistent für NIS2 relevant wird
Der erste Fehler passiert oft noch vor der Sicherheitsprüfung: „Wir nutzen KI, also gilt NIS2.“ So funktioniert das Gesetz nicht. Die Betroffenheit hängt vor allem von Einrichtungsart, Tätigkeit, Größe und besonderen gesetzlichen Tatbeständen ab. § 28 BSIG unterscheidet wichtige und besonders wichtige Einrichtungen; die Anlagen 1 und 2 ordnen die Sektoren zu.
Der zweite Fehler ist das Gegenteil: „Der Assistent ist nur ein SaaS-Tool, also ist er nicht Teil unserer regulierten IT.“ Wenn über ihn Kundenstörungen aufgenommen, Einsatztermine koordiniert, Identitäten geprüft oder wesentliche Anrufe geroutet werden, kann sein Ausfall oder seine Manipulation sehr wohl die Erbringung des Dienstes beeinträchtigen.
| Frage | Entscheidung | Nachweis |
|---|---|---|
| Ist das Unternehmen wichtige oder besonders wichtige Einrichtung? | § 28 BSIG, Anlagen, Größen- und Sondertatbestände prüfen | schriftliche Betroffenheitsbewertung mit Annahmen und Stichtag |
| Unterstützt Telefon-KI einen regulierten Dienst? | Geschäftsprozess statt Produktname betrachten | Prozesskarte vom Anruf bis zum Zielsystem |
| Welche Wirkung hat ein Ausfall? | Informations-, Komfort- oder betriebsrelevanter Kanal | Schutzbedarfs- und Business-Impact-Bewertung |
| Kann die KI Daten oder Zustände verändern? | Lesender FAQ-Agent anders behandeln als CRM-Schreibzugriff | Rechte- und Funktionsmatrix |
| Ist der Anbieter selbst NIS2-reguliert? | Separat nach Einrichtungsart und Größe prüfen | nachvollziehbare Selbstauskunft, nicht nur Werbeaussage |
Für Finanzunternehmen können vorrangige Regeln wie DORA gelten; § 28 Absatz 6 BSIG enthält hierzu Ausnahmen. Auch sektorspezifische Vorgaben bleiben zu prüfen. Dieser Beitrag konzentriert sich auf die Lieferanten- und Betriebsfragen rund um Telefon-KI.
Drei Kritikalitätsklassen, die im Projekt mehr helfen als „KI-Risiko: hoch“
| Klasse | Beispiel | Ausfallreaktion |
|---|---|---|
| A – ergänzend | Öffnungszeiten und öffentliche FAQ, keine personenbezogenen Daten | Hinweis oder Weiterleitung auf vorhandenen Kontaktweg |
| B – geschäftsrelevant | Termin, Ticket, Rückruf, Statusabfrage mit begrenzten Daten | sichere Ersatzannahme, Schreibzugriffe deaktivieren, Rückstau abarbeiten |
| C – dienstkritisch | Störungsannahme, Bereitschaft, regulierter Kundenprozess oder zentrale Rufverteilung | getestete Umleitung, definierte Wiederanlaufzeit, 24/7-Alarmierung und Krisenrolle |
Nicht jedes Unternehmen braucht Klasse C. Aber jedes Unternehmen sollte vor Vertragsschluss wissen, welche Klasse es einkauft. Sonst werden Verfügbarkeit und Vorfallservice erst verhandelt, wenn das Telefon bereits schweigt.
Die tatsächliche Lieferkette eines Voice Agents
„Anbieter: Teloro“ wäre für eine Risikoanalyse zu kurz. Ein produktiver Telefonassistent besteht typischerweise aus mehreren Diensten und Übergängen. Welche Komponenten tatsächlich eingesetzt werden, muss der konkrete Anbieter offenlegen.
Typische Kette: Rufnummer/Carrier → SIP oder Telefonieplattform → Sitzungssteuerung → Spracherkennung → Sprachmodell und Wissensabruf → Sprachsynthese → CRM/Kalender/Ticketing → Protokollierung und Alarmierung.
Für jede Station sind fünf Dinge wichtig: Betreiber, Verarbeitungsort, Datenart, Berechtigung und Ausfallwirkung. Erst damit lässt sich beurteilen, ob ein Unterauftragnehmer nur austauschbare Infrastruktur liefert oder einen Single Point of Failure für den gesamten Kundenservice darstellt.
| Schutzziel | Telefon-KI-Risiko | Prüfbare Kontrolle |
|---|---|---|
| Verfügbarkeit | Rufnummer unerreichbar, Gespräch bricht ab, Rückstau bleibt unsichtbar | Fallback-Routing, Monitoring von außen, Wiederanlaufziel, Last- und Ausfalltest |
| Vertraulichkeit | Transkript oder CRM-Daten gelangen an falschen Mandanten | Mandantentrennung, minimale Datenfelder, Schlüssel- und Zugriffsprotokolle |
| Integrität | Termin, Ticket oder Kontaktdaten werden falsch geändert | serverseitige Regeln, Bestätigung, unveränderbares Änderungsereignis, Rückrollweg |
| Authentizität | Rufnummer oder Stimme wird als Identität missverstanden | risikobasierte, vom Audiokanal unabhängige Authentisierung |
| Nachvollziehbarkeit | Vorfall lässt sich wegen fehlender Ereignisse nicht rekonstruieren | zeitlich synchronisierte Logs, definierte Aufbewahrung und gesicherter Export |
§ 30 BSIG in konkrete Telefon-KI-Kontrollen übersetzen
§ 30 BSIG verlangt geeignete, verhältnismäßige und wirksame Maßnahmen. Die dort genannten zehn Themen sind kein Einkaufsformular, lassen sich aber in prüfbare Anforderungen an einen Voice-Agent-Dienst übersetzen.
| BSIG-Thema | Konkrete Frage bei Telefon-KI | Sinnvoller Nachweis |
|---|---|---|
| Risikoanalyse | Welche Daten, Rechte, Ausfälle und Missbrauchsfälle wurden je Use Case bewertet? | aktuelle Risiko- und Datenflussdarstellung |
| Vorfallbewältigung | Wer erkennt, klassifiziert und meldet einen mandantenbezogenen Vorfall? | Incident-Playbook mit Kontakten und Probebericht |
| Business Continuity | Wie werden Anrufe bei Ausfall sicher angenommen oder umgeleitet? | Wiederanlaufplan und dokumentierter Failover-Test |
| Lieferkettensicherheit | Welche unmittelbaren und wesentlichen Unterauftragnehmer tragen den Dienst? | Subdienstleisterliste mit Funktion, Region und Wechselprozess |
| Sichere Beschaffung und Entwicklung | Wie werden Änderungen, Schwachstellen und Abhängigkeiten behandelt? | Secure-Development- und Vulnerability-Prozess |
| Wirksamkeitsbewertung | Wie wird belegt, dass eine Kontrolle im realen Telefonpfad greift? | Testprotokolle, Kennzahlen und geschlossene Befunde |
| Schulung | Wer darf Dialoge, Wissen, Integrationen und Rechte verändern? | Rollenmodell, Schulungs- und Freigabenachweis |
| Kryptografie | Wie sind Transport, gespeicherte Daten und Schlüssel geschützt? | Architekturübersicht, Schlüsselverantwortung und Rotationsprozess |
| Personal und Zugriff | Welche Mitarbeiter des Anbieters können auf Mandantendaten zugreifen? | JIT-/Least-Privilege-Verfahren und administratives Zugriffslog |
| MFA und gesicherte Kommunikation | Wie sind Adminzugang und Notfallkommunikation abgesichert? | MFA-Nachweis, Break-glass-Prozess und getesteter Zweitkanal |
Die Maßnahme muss zur Kritikalität passen. Ein öffentlicher FAQ-Assistent braucht keine dieselbe Wiederanlaufarchitektur wie eine Störungsannahme. „Verhältnismäßig“ bedeutet aber nicht „unbestimmt“: Ziel, Verantwortlicher, Prüfintervall und Nachweis sollten benannt sein.
Die 24 Stunden beginnen nicht beim Anbieter-Ticket
Nach § 32 BSIG muss eine betroffene Einrichtung einen erheblichen Sicherheitsvorfall grundsätzlich gestuft melden: frühe Erstmeldung innerhalb von 24 Stunden nach Kenntnis, Vorfallmeldung innerhalb von 72 Stunden und Abschlussbericht grundsätzlich spätestens einen Monat nach der Vorfallmeldung. Der Anbieter des Voice Agents meldet diese Fristen nicht automatisch für den Kunden.
Das schafft eine einfache Vertragslogik: Die Informationsfrist des Anbieters muss deutlich vor der gesetzlichen Frist des Kunden liegen. Ein Versprechen wie „Wir informieren im Rahmen der gesetzlichen Anforderungen“ ist dafür zu unklar. Welches Gesetz, wessen Kenntnis und mit welchen Mindestdaten?
| Zeitpunkt | Was der Kunde benötigt | Was vertraglich feststehen sollte |
|---|---|---|
| Erstes belastbares Signal | Betroffener Dienst, Zeitraum, mögliche Schutzzielfolge | sofortiger benannter Alarmweg, auch bei noch unsicherer Lage |
| Interne Erstbewertung | betroffene Mandanten, Datenarten, Regionen und Integrationen | Mindestinhalt eines Initial Reports und erreichbare Einsatzleitung |
| Vor Ablauf von 24 Stunden | Grundlage für Erheblichkeits- und Meldeentscheidung | regelmäßige Updates, keine Wartepflicht bis zur Root Cause |
| Bis zur 72-Stunden-Bewertung | Schwere, Auswirkung, Indikatoren und erste Abhilfe | technische Artefakte und fachkundige Mitwirkung |
| Abschluss und Nachbereitung | Ursache, Verlauf, Maßnahmen und dauerhafte Abstellung | Root-Cause-Bericht, Beweissicherung und Maßnahmenverfolgung |
Die Formulierung „unverzüglich“ kann sinnvoller sein als eine großzügige Stundenfrist, braucht aber einen operativen Alarmkanal. Eine Nachricht an ein allgemeines Supportpostfach am Freitagabend ist für einen dienstkritischen Prozess kein Alarmweg.
24 Fragen an den Anbieter – mit erwartbarer Antwort
Architektur und Lieferkette
- Welche Dienste verarbeiten Audio, Transkript, Prompt, Wissensdaten und Ergebnisfelder? Erwartet wird ein aktueller Datenfluss, kein Logo-Schaubild.
- Welche Unterauftragnehmer sind für den Betrieb wesentlich? Funktion, Region und Austauschbarkeit gehören dazu.
- Wo liegen Single Points of Failure? Der Anbieter sollte sie benennen und nicht behaupten, es gebe keine.
- Wie werden Lieferantenwechsel angekündigt und risikobewertet? Eine bloß jederzeit veränderbare Webliste reicht für kritische Dienste selten aus.
Daten und Zugriffe
- Welche Daten werden dauerhaft gespeichert, welche nur flüchtig verarbeitet? Audio, Transkript, Metadaten und Tool-Ergebnisse getrennt beantworten.
- Wie wird Mandantentrennung technisch erzwungen und getestet? Architektur und negativer Test sind stärker als eine Vertragszeile.
- Wer kann administrativ auf Kundendaten zugreifen? Anlass, Freigabe, Dauer und Protokollierung müssen erkennbar sein.
- Wie schnell wirkt ein Rechteentzug? Offboarding darf nicht vom nächsten manuellen Monatslauf abhängen.
Sichere Funktionen und Änderungen
- Welche Aktionen darf das Modell vorschlagen, welche darf es ausführen? Berechtigung und Geschäftsregel müssen außerhalb des Modells greifen.
- Wie werden neue Integrationen und Schreibrechte freigegeben? Es braucht Owner, Test und Rückrollplan.
- Wie schützt das System gegen Prompt Injection und übermäßige Autonomie? Die Antwort sollte technische Grenzen statt nur Filter nennen.
- Wie werden sicherheitsrelevante Änderungen angekündigt? Release, Auswirkung, Ansprechpartner und Notfall-Rollback gehören zusammen.
Verfügbarkeit und Wiederanlauf
- Welches SLO gilt für den vollständigen Anrufpfad? Eine Plattform kann „grün“ sein, obwohl Anrufe nicht ankommen.
- Wie wird von außerhalb der Anbieterumgebung überwacht? Ein echter Testanruf erkennt mehr als ein interner Prozess-Ping.
- Was passiert bei Ausfall von Modell, CRM oder Telefonie? Jeder Teilausfall braucht ein sicheres, fachlich passendes Verhalten.
- Welche RTO und RPO gelten, und wann wurden sie zuletzt erreicht? Zielwerte ohne Testdatum sind Absichtserklärungen.
Vorfall und Schwachstellen
- Welche Ereignisse lösen eine Kundenwarnung aus? Nicht nur bestätigte Datenabflüsse, sondern auch relevante Verfügbarkeits- und Integritätsereignisse betrachten.
- Wie erreicht die Warnung unsere 24/7-Rolle? Person, Zweitkanal und Eskalationsstufe müssen getestet sein.
- Welche Mindestdaten enthält der Initial Report? Dienst, Zeitraum, Mandant, Schutzzielfolge, Abhilfe und nächste Aktualisierung.
- Wie unterstützt der Anbieter BSI- und Betroffenenbewertung? Zuständigkeit, Artefakte und Reaktionszeit vorab klären.
Nachweis, Übung und Exit
- Welche unabhängigen Prüfungen decken genau unseren Dienst ab? Zertifikat und Scope gemeinsam vorlegen lassen.
- Welche Befunde sind offen und wann werden sie geschlossen? Ein geschwärzter Managementbericht kann mehr sagen als ein Siegel.
- Können wir Alarmweg, Fallback und Wiederanlauf gemeinsam üben? Ein Anbieter, der keinen Test zulässt, verlagert Unsicherheit zum Kunden.
- Wie funktionieren Export, Rufnummern-/Routing-Wechsel, Löschung und Nachweis beim Exit? Der letzte Betriebstag gehört zum Sicherheitsmodell.
Vertiefung zu Frage 11 bietet unser Beitrag über Prompt Injection und sichere Aktionsgrenzen bei Telefon-KI.
Welche Nachweise wirklich helfen
Ein Zertifikat ist nützlich, wenn sein Geltungsbereich den konkreten Dienst umfasst. Es ist kein Ersatz für Betriebsdaten. Einkauf und IT sollten Nachweise danach bewerten, welche Frage sie tatsächlich beantworten.
| Nachweis | Belegt | Belegt nicht automatisch |
|---|---|---|
| ISO/IEC 27001-Zertifikat | geprüftes Informationssicherheits-Management im angegebenen Scope | Mandantentrennung, konkrete RTO, Vorfall-SLA oder vollständige Lieferkette |
| Penetrationstest-Zusammenfassung | Prüfumfang, Zeitpunkt, Befunde und Nachtest | Business Continuity oder tägliche Zugriffskontrolle |
| Architektur- und Datenfluss | Komponenten, Übergänge, Regionen und Verantwortungen | dass die gezeichneten Kontrollen wirksam betrieben werden |
| Failover-Protokoll | erreichte Umschalt- und Wiederanlaufzeiten im Test | Verhalten bei einem anderen Fehlermodus |
| Beispiel-Incident-Report | Informationsqualität und Prozessreife | dass der Alarmweg nachts funktioniert |
| Gemeinsame Übung | Zusammenspiel von Mensch, Technik, Vertrag und Kontaktweg | jede zukünftige Angriffsklasse |
Die 60-Minuten-Ausfall- und Vorfallübung
Ein einfacher Tabletop-Test liefert in einer Stunde mehr Klarheit als zehn Sicherheitsfolien. Das Szenario: Um 09:02 Uhr meldet das Monitoring ungewöhnlich viele fehlgeschlagene CRM-Abfragen. Gleichzeitig nennen zwei Anrufer falsche Statusinformationen. Die Ursache ist noch unbekannt.
- Minute 0–10: Wer erkennt den Vorgang? Welche Person beim Anbieter und beim Kunden übernimmt? Erreicht der Alarm die hinterlegte Rolle?
- Minute 10–20: Lassen sich CRM-Schreib- und Lesezugriffe getrennt stoppen? Bleiben öffentliche Informationen und sichere Rückrufannahme verfügbar?
- Minute 20–30: Welche Logs werden gesichert? Sind Mandant, Zeitraum, betroffene Felder und Gesprächs-IDs abgrenzbar?
- Minute 30–40: Welche Fachbereiche, Datenschutz-, Sicherheits- und Geschäftsleitungsrollen benötigen die Information? Wer bewertet Erheblichkeit?
- Minute 40–50: Reichen die Anbieterinformationen für eine frühe BSI-Bewertung? Was fehlt, wer liefert es bis wann?
- Minute 50–60: Wie wird der Dienst kontrolliert wieder freigegeben? Welche Stichprobe beweist, dass Zugriffsgrenzen und Antworten wieder stimmen?
Das Ergebnis der Übung ist keine Note. Es ist eine Liste aus fehlender Telefonnummer, unklarem Abschaltrecht, unvollständigem Logfeld oder unrealistischem RTO. Genau diese kleinen Lücken werden im echten Vorfall teuer.
Häufige Fragen zu NIS2 und KI-Telefonassistenten
Fällt ein Unternehmen wegen eines KI-Telefonassistenten unter NIS2?
Nein. Der Einsatz von Telefon-KI löst die NIS2-Betroffenheit nicht aus. Entscheidend sind Einrichtungsart, Tätigkeit, Größe und besondere Tatbestände nach § 28 BSIG. Ist das Unternehmen bereits eine wichtige oder besonders wichtige Einrichtung, kann der Telefonassistent jedoch Teil der für den Dienst genutzten IT und damit Teil des Risikomanagements sein.
Muss der Anbieter der Telefon-KI selbst NIS2-reguliert sein?
Nicht zwingend. Ob der Anbieter selbst eine wichtige oder besonders wichtige Einrichtung ist, hängt von seiner Einrichtungsart und Größe ab. Für den regulierten Kunden bleibt er dennoch ein unmittelbarer Diensteanbieter in der Lieferkette. Sicherheitsanforderungen, Informationswege und Nachweise sollten deshalb vertraglich festgelegt werden.
Welche NIS2-Anforderungen gehören in den Vertrag mit einem Voice-Agent-Anbieter?
Mindestens eine klare Leistungs- und Unterauftragnehmerkette, Sicherheitsmaßnahmen, Zugriffsregeln, Schwachstellenprozess, unverzügliche Vorfallinformation, Mitwirkung bei Meldungen, Wiederanlaufziele, Protokollzugang, Prüf- und Nachweisrechte, Änderungsinformation sowie ein getesteter Exit- und Löschprozess.
Welche Meldefristen gelten bei einem erheblichen Sicherheitsvorfall?
§ 32 BSIG sieht grundsätzlich eine frühe Erstmeldung innerhalb von 24 Stunden nach Kenntnis, eine Vorfallmeldung innerhalb von 72 Stunden und spätestens einen Monat nach der Vorfallmeldung einen Abschlussbericht vor. Damit der Kunde diese Uhr starten kann, muss der Anbieter ihn deutlich früher und mit verwertbaren Mindestinformationen informieren.
Reicht eine ISO-27001-Zertifizierung des Anbieters aus?
Nein. Ein Zertifikat kann ein wichtiger Nachweis sein, beantwortet aber nicht automatisch, ob der konkrete Telefon-KI-Dienst im Geltungsbereich liegt, welche Unterauftragnehmer beteiligt sind, welche Ausfallziele gelten oder wie schnell der Kunde verwertbare Vorfallinformationen erhält. Zertifikat, Scope und konkrete technische Nachweise müssen zusammen geprüft werden.
Wie testet man die NIS2-Tauglichkeit eines Voice Agents?
Mit einer gemeinsamen Ausfall- und Vorfallübung. Getestet werden Erkennung, Alarmweg, erreichbare Kontakte, Informationsqualität, Abschaltung von Integrationen, sichere Ersatzannahme, Wiederanlauf, Protokollsicherung und die Fähigkeit des Kunden, innerhalb seiner gesetzlichen Fristen zu bewerten und zu melden.
Fazit: NIS2-tauglich ist ein nachweisbarer Betriebsprozess
Die richtige Frage lautet nicht: „Ist diese KI NIS2-konform?“ Ein einzelnes Produkt erhält kein pauschales NIS2-Siegel. Entscheidend ist, ob das regulierte Unternehmen den Dienst in sein eigenes Risikomanagement integrieren, seine Lieferkette verstehen, Kontrollen prüfen und einen Vorfall fristgerecht beherrschen kann.
Ein guter Voice-Agent-Anbieter macht diese Arbeit konkret: Er zeigt Daten- und Dienstekette, begrenzt Zugriffe, nennt realistische Ausfallziele, liefert frühe verwertbare Warnungen und übt den Fallback gemeinsam mit dem Kunden. Damit wird Sicherheit vom Verkaufsversprechen zum überprüfbaren Betrieb.
Sie möchten einen Telefon-KI-Prozess nicht nur demonstrieren, sondern mit Lieferkette, Rechten, Ausfallweg und Alarmkontakten abnehmen? Bringen Sie Ihre kritischste Rufnummer mit.
Teloro-Betriebsmodell prüfen