Schutz von Verbrauchern vor Betrugsanrufen und -nachrichten (Betrugserkennung auf dem Gerät)

Betrüger erreichen Menschen per Telefon, SMS und Messenger mit falschen Geschichten über Bank, Polizei, Paket oder das "Enkelkind in Not", zunehmend mit KI-geklonten Stimmen. Kleine Sprach- und Audiomodelle, die auf dem Telefon (oder im Netz des Betreibers) laufen, können das Gesprächsmuster eines Betrugs erkennen, während er stattfindet, und ihn mit einer Warnung unterbrechen, ohne das Gespräch in die Cloud zu senden. Nutzen: Schutz im Moment der Manipulation, den die Transaktionsüberwachung der Bank (siehe ANOM-022) erst im Nachhinein leisten kann.

Problem & Nutzen

• Heute: Der Schutz ist überwiegend reaktiv: Nummern-Sperrlisten und gemeinschaftlich erstellte Spam-Kennzeichnungen, SMS-Filter, Aufklärungskampagnen von Polizei und Verbraucherstellen (die deutsche Polizei informiert über Enkeltrick, "falsche Polizisten", Schockanrufe und Messenger-Betrug [5]). Die Skripte ändern sich schneller als Sperrlisten, Nummern werden gefälscht oder gewechselt, und das Opfer wird in Echtzeit unter Druck gesetzt.
• KI-Nutzen: den Inhalt und die Absicht von Gespräch oder Nachricht (Dringlichkeit, Geheimhaltung, Vortäuschen einer Autorität, Aufforderung zu Codes/Fernzugriff/Überweisungen) klassifizieren statt nur die Nummer, lokal und in Echtzeit.
• Ausmaß des Problems: Die US-Handelsbehörde FTC berichtet, dass Betrug Menschen per Telefon, SMS und E-Mail erreicht und dass die in sozialen Medien entstandenen Verluste 2025 das Achtfache des Niveaus von 2020 betrugen [4]; Microsoft berichtet, innerhalb eines Jahres Betrugsversuche im Umfang von rund 4 Mrd. USD blockiert zu haben, und beschreibt Vishing, mit dem Fernzugriff erlangt wird (z. B. Quick Assist) [1]. EU-weite Zahlen sind den nationalen Statistiken von Polizei und Aufsichtsbehörden zu entnehmen (für diese Datei nicht geprüft).

Varianten

• Auf dem Gerät (Verbraucher): Betrugserkennung in den Nachrichten- und Telefon-Apps des Betriebssystemherstellers mit einem kleinen Modell auf dem Gerät, etwa Gemini Nano; der Gesprächsinhalt bleibt auf dem Telefon.
• Netzseitig (Betreiber): Telekommunikationsbetreiber analysieren Anrufsignalisierung und Verkehr (Rufnummernfälschung, Anrufwellen) und, wo rechtlich erlaubt, Inhalte; überschneidet sich mit ANOM-024.
• Begleitung durch die Bank: Warnungen in der App ("Sie telefonieren gerade, während Sie zahlen"), siehe ANOM-022.
• Senioren & Familie: Benachrichtigung von Vertrauenspersonen, Anruffilter, der unbekannte Anrufer mit einem Assistenten annimmt.
• KMU: Vishing-Schutz für Beschäftigte (CEO-Betrug, falscher IT-Support); siehe SEC-011, SEC-002.
• Private Nutzung: Hauptzielgruppe; kostenlose Funktionen des Betriebssystems oder kleine Abo-Apps.

So funktioniert es

1. eingehender Anruf / SMS / Chat
2. einfache Vorfilter: Nummern-Reputation, Echtheit der Rufnummer, URL-Reputation, bekannte Betrugsmuster
3. Verarbeitung auf dem Gerät: ASR-Ausschnitt (Anrufe) oder Text
4. kleines LLM / Klassifikator (Betrugsmasche + Absicht)
5. Risikowert mit Erklärung ("Der Anrufer gibt sich als Ihre Bank aus und bittet Sie, Geld zu verschieben")
6. Bedienung: stille Kennzeichnung | Warnbanner/Vibration/Hinweiston | Blockieren | Auflegen anbieten
7. optional: Vertrauensperson benachrichtigen, Nummer melden (mit Einwilligung des Nutzers, datensparsam)
8. Rückkopplung: Nutzermeldungen + Bedrohungsinformationen des Herstellers aktualisieren Modelle und Sperrlisten

• Zentrale KI-Bausteine: Spracherkennung für Audio-Streams, ein kleines LLM oder ein Encoder-Klassifikator für Betrugsmaschen, optional Erkennung synthetischer Stimmen (vgl. SEC-011), URL-/Domain-Klassifikatoren.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Nutzer entscheidet immer; das System warnt, es übernimmt den Anruf nicht und erhebt keine Anschuldigung. Eskalationen von Bank oder Betreiber gehen an die Betrugsteams.
• Gestaltungsregel: Verhaltensmuster erkennen (Dringlichkeit, Geheimhaltung, Autorität, Zahlungs-/Codeaufforderung), statt Personen zu identifizieren.

Datenaufbereitung

Die Betrugserkennung braucht drei Arten von Daten: gekennzeichnete Betrugsbeispiele (Skripte, Nachrichten, URLs, Nummern), Bedrohungsinformations-Feeds und, bei Eigenentwicklungen, die von Nutzern eingereichten Transkripte oder Texte. In einem KMU gibt es diese selten im eigenen Haus; die praktische Quelle sind Bedrohungsinformationen von Anbietern sowie die eigenen Anrufprotokolle, Berichte des Mail-Gateways und Meldungen der Beschäftigten ("das sieht verdächtig aus").

Typische Lücken sind wenige gekennzeichnete Beispiele auf Deutsch, verstreute Meldungen (Mail, Chat, Telefonnotizen), kein einheitliches Kategorienschema und Transkripte, die personenbezogene Daten enthalten. Schritte zur Aufbereitung:

1. Ein einfaches Kategorienschema festlegen (Phishing, Vishing, CEO-Betrug, falscher Tech-Support), bevor Beispiele gesammelt werden (PREP-019).
2. Kennzeichnungen aus vorhandenen Unterlagen gewinnen, etwa aus Helpdesk-Tickets und Protokollen blockierter Mails (PREP-020).
3. Transkripte und Nummern pseudonymisieren, bevor sie für Bewertung oder Training genutzt werden (PREP-022).
4. Einen kleinen, von Fachleuten geprüften Testdatensatz aufbauen (PREP-018) und Nutzerkorrekturen anschließend erfassen (PREP-021).
5. Zweck und Rechtsgrundlage prüfen, einschließlich des Fernmeldegeheimnisses für Gesprächsinhalte (PREP-025).

Die Werkzeuge sind bescheiden: eine Tabelle oder ein Ticket-Export, Whisper für Transkripte, ein Pseudonymisierungsskript. Grober Aufwandsanteil: etwa 30 Prozent bei Pilotprojekten auf dem Kaufweg, 40 bis 50 Prozent, wenn Sie einen eigenen Detektor bauen.

Umsetzungswege

Welcher Weg für wen

• private: A. Der eingebaute Betrugsschutz des Betriebssystems und Anrufer-ID-Apps funktionieren ohne Einrichtung; rein lokale Apps sind eine Option für datenschutzbewusste Nutzer.
• enterprise: B. Banken und Betreiber müssen Warnungen in ihre eigenen Apps und Betrugssysteme integrieren, und kein Produkt passt zu ihrem Fall und ihren Datenflüssen.
• developer: C. Kleine Modelle auf dem Gerät (Gemma 3n, Whisper-Varianten über llama.cpp) halten Audio und Nachrichten auf dem Telefon, was dem datenschutzfreundlichen Entwurf entspricht.
• smb: A. Unternehmen schützen ihre Beschäftigten mit Spamfilter- und Anrufer-ID-Produkten oder Diensten der Betreiber; einen Detektor für ein Standardproblem zu bauen lohnt sich nicht.

Weg A: Kaufen (empfohlen)

• Funktionen des Betriebssystems: Googles Betrugserkennung auf dem Gerät in Nachrichten/Telefon unter Android, Anrufscreening und Mailbox-ähnliche Live-Funktionen unter iOS, die Entsprechungen von Samsung. Sie sind kostenlos, geräteabhängig, und die Verfügbarkeit nach Region/Sprache schwankt. Prüfen Sie die aktuelle Verfügbarkeit für Ihren Markt (hier nicht geprüft).
• Apps und Netze von Drittanbietern: Anbieter von Anrufer-ID und Spamschutz wie Hiya, Truecaller und Pindrop (Sprachbetrug im Unternehmensumfeld); Dienste von Betreibern (z. B. Deutsche Telekom, Orange, Vodafone bieten netz- oder app-basierten Spam-/Betrugsschutz an; aktuelle Produktnamen bitte bestätigen).
• Betreiber und Banken kaufen Netzanalysen und SDKs für Warnungen in der App; prüfen Sie die Rollenverteilung nach DSGVO, EU-Hosting und die Einhaltung des Fernmeldegeheimnisses (TKG/ePrivacy).
• Wählen Sie A, wenn: Sie Verbraucher, Bank oder Betreiber sind und schnell einen Nutzen ohne Modellbetrieb erreichen wollen.

Weg B: Auf Cloud-KI-Diensten aufbauen

• Für Apps, die sich nicht auf Funktionen des Betriebssystems stützen können (Banking-Apps, Messenger, Werkzeuge für Contact-Center): vom Nutzer eingereichte oder freigegebene Texte/Transkripte mit einer in der EU gehosteten LLM-API klassifizieren (Mistral, Azure OpenAI in EU-Regionen, Claude oder Gemini über EU-Regionen), dazu verwaltete Spracherkennung.
• Live-Anrufaudio in die Cloud zu senden ist rechtlich heikel (Fernmeldegeheimnis, Einwilligung aller Beteiligten); bevorzugen Sie Textausschnitte, vom Nutzer ausgelöste Abläufe ("diese Nachricht prüfen") und Vorfilterung auf dem Gerät.
• Nützlich für Dienste zum "Weiterleiten verdächtiger Nachrichten zur Analyse", die von Verbraucherorganisationen, Banken oder öffentlichen Stellen betrieben werden.

Weg C: Selbst betreiben (Open Source)

• Modelle auf dem Gerät/am Rand: Gemma 3n E4B (offene Gewichte, Eingabe aus Text+Audio+Bild, effektive Größe etwa 4 Mrd. Parameter) [3], kleine Qwen-/Llama-/Phi-Modelle, Whisper-Varianten über faster-whisper [7] oder whisper.cpp; Betrieb mit llama.cpp (Android/iOS/Desktop, 4–8-Bit-Quantisierung) [6], ONNX Runtime oder ExecuTorch.
• Serverseitig (Betreiber/Banken): dieselben Modelle auf einer Workstation-GPU für die Textvorsortierung; Kaldi-/Whisper-Streaming-ASR für Anwendungsfälle im Callcenter.
• Hardware: HW1: moderne Telefon-NPU oder CPU für quantisierte Modelle mit 1–4 Mrd. Parametern; HW2 für netzseitige Batch-/Streaming-Analyse.
• Aufwand: hoch auf der Seite der Mobile-Entwicklung (Akku, Latenz, Beschränkungen der Hintergrundausführung unter iOS/Android).

Weg D: Eigenes Training

• Lohnend für Betreiber, Banken und Sicherheitsanbieter: einen kleinen Klassifikator mit gekennzeichneten Betrugsskripten, Transkripten und Nachrichten in der Landessprache feintunen (deutsche Dialekte, Türkisch, Russisch usw.), dazu einen Detektor für gefälschte/Deepfake-Stimmen. Dafür braucht es Tausende gekennzeichneter, mit Einwilligung gewonnener oder synthetischer Beispiele sowie laufend aktualisierte Angriffsdaten, da Betrüger sich anpassen. Der übliche Weg ist die Destillation eines großen Modells in ein Modell mit 1–3 Mrd. Parametern für das Gerät.

Stand der Technik (2026)

• LLMs auf dem Gerät sind inzwischen Routine: Google stellt Gemini Nano über AICore und die ML-Kit-GenAI-APIs bereit, einschließlich Prompt- und Spracherkennungs-APIs auf unterstützten Telefonen (Pixel 9–11, Galaxy S25/S26 und weitere) [2]; Betriebssystemhersteller nutzen solche Modelle zur Betrugserkennung bei Nachrichten und Anrufen, wobei der Gesprächsinhalt lokal bleibt, wie von Google angekündigt (Details hier nicht erneut geprüft).
• Offene multimodale Modelle für den Rand wie Gemma 3n nehmen Audio direkt entgegen und laufen mit einem Speicherbedarf der 4-Mrd.-Klasse [3]; damit werden offene Umsetzungen realistisch.
• Verschiebung der Bedrohung: KI-generierte Online-Shops, falsche Stellenangebote, Stimmklonen und Tech-Support-Betrug mit Fernzugriff sind von Microsoft dokumentiert [1]; die Abwehr verbindet Reibung im Produkt (Warnungen, bevor Fernzugriff gewährt wird) mit Erkennung [1].
• Grenzen und Fehlerbilder: Fehlalarme (legitime Anrufe von Bank, Arzt, Schule) untergraben das Vertrauen; übersehene neue Skripte; ASR-Fehler bei Dialekten/Akzenten; Angreifer, die den Detektor austesten; Grenzen bei Hintergrundausführung und Akku; Abdeckung nur auf neueren Geräten; Anrufe über Ende-zu-Ende-verschlüsselte Messenger sind für Betreiber in der Regel nicht zugänglich. Die Erkennung geklonter Stimmen ist ein Wettlauf und sollte nicht der alleinige Beleg sein.
• Öffentliche Benchmarks für die Erkennung von Betrugsanrufen sind selten; Herstellerzahlen nur mit unabhängiger Überprüfung zitieren.

Gemeinsame Bausteine & Kombinationen

• Gleiche Bausteine (asr, llm-small, edge-runtime, text-classifier): PERS-019 Online-Sicherheit für Kinder (Schutz auf dem Gerät), SEC-002 Phishing- und E-Mail-Sicherheit (Text-/URL-Klassifikatoren), SEC-011 Erkennung von Deepfakes und Stimmklonen, CONV-002 Sprachagenten (derselbe ASR-/Streaming-Stack), ANOM-015 Herkunftsnachweis synthetischer Inhalte.
• Vor- und nachgelagert: ANOM-022 (Warnungen der Bank vor APP-Betrug, Informationen zu Zahlungsempfängern/Finanzagenten), ANOM-024 (Betrugssignale im Telekommunikationsbereich wie SIM-Swap, Wangiri), ANOM-004 (gefälschte Konten auf Plattformen), ANOM-014 (Identitätsfälschung).
• Hardware: Telefon-NPUs für die Verbraucherebene; ein HW2-GPU-Server kann Streaming-ASR plus ein kleines LLM für die Analysekette eines Betreibers oder einer Bank betreiben; die Datenbank für Bedrohungsinformationen wird von allen gemeinsam genutzt.

Aufwand, Kosten & Kennzahlen

• Weg A: Stunden (Funktionen aktivieren) für Verbraucher; Wochen für Banken/Betreiber, um das SDK des Anbieters oder den Netzdienst einzubinden.
• Weg B: 2–4 Monate für einen Dienst "Nachricht prüfen" oder Warnungen in der App.
• Weg C/D: 6–12+ Monate für einen produktiven mobilen Detektor auf dem Gerät mit mehrsprachigen Modellen, plus laufender Betrieb der Bedrohungsinformationen.
• Kostentreiber: gekennzeichnete mehrsprachige Daten, Mobile-Entwicklung und Gerätematrix, Pflege der Bedrohungsinformationen, Unterstützung für Opfer.
• Kennzahlen: Erkennungsrate von Betrug und Falschalarmrate je 1.000 Anrufe/Nachrichten, Abbruchrate nach Warnung (Nutzer, die nach einer Warnung aufhören), geschätzte verhinderte Schäden (sorgfältig definiert), Zeit bis zur Abdeckung eines neuen Skripts, Vertrauen der Nutzer/Zustimmungsquote, Mehrbelastung von Akku/Latenz.

Menschen & Veränderung

Wer und wann. Die Geschäftsleitung entscheidet zuerst über Umfang und Budget. IT und IT-Sicherheit binden die Lösung ein und sichern sie ab, Recht/Compliance klärt das Fernmeldegeheimnis (TKG) und die Einwilligung für Gesprächsinhalte, und die oder der Datenschutzbeauftragte wird von Anfang an einbezogen. Betroffene Beschäftigte und, bei Banken und Betreibern, die kundennahen Teams nehmen vor dem Rollout am Pilotprojekt teil.

Betriebsrat. Kommt darauf an. Bei Verbraucherprodukten ist keiner beteiligt. Setzt das Unternehmen ein Screening von Anrufen oder Nachrichten für die eigenen Beschäftigten ein, ist eine Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG wahrscheinlich, weil das System Anrufe und Nachrichten protokolliert und objektiv geeignet ist, Verhalten zu überwachen (BAG). Zusätzlich verlangt § 90 Abs. 1 Nr. 3 eine rechtzeitige Unterrichtung über KI-gestützte Arbeitsabläufe. Öffentliche Stellen beteiligen den Personalrat.

Datenschutz. Nachrichten und Anrufaudio sind personenbezogene Daten. Schließen Sie mit jedem Anbieter einen AVV (Art. 28 DSGVO); für die großflächige Analyse von Kommunikationsinhalten ist eine DSFA (Art. 35 DSGVO) wahrscheinlich.

KI-Kompetenz. Unterstützen Sie die Beschäftigten mit einer kurzen Einweisung, was das Werkzeug markiert, warum Fehlalarme vorkommen und wie übersehene Fälle gemeldet werden (GUIDE-006).

Kommunikation und Kontrolle. Kündigen Sie an, was analysiert wird und was nicht, beginnen Sie mit einer freiwilligen Pilotgruppe, und lassen Sie Nutzer eine Warnung immer übergehen. Typische Sorgen sind Überwachung und fälschliche Sperrungen; begegnen Sie ihnen durch Verarbeitung auf dem Gerät, keine Speicherung von Inhalten und einen klaren Beschwerdeweg (GUIDE-004, GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko: Ein Warnwerkzeug für Verbraucher steht nicht in Anhang III und entscheidet nicht über den Zugang zu Leistungen. Achten Sie darauf, dass das System in Arbeits- und Bildungskontexten keine Emotionen aus der Stimme ableitet (Verbot nach Art. 5 Abs. 1 Buchst. f; in anderen Kontexten ist Emotionserkennung hochriskant bzw. unterliegt der Transparenzpflicht nach Art. 50 Abs. 3). Die Erkennung geklonter Stimmen und jede KI-generierte Warnstimme bzw. jeder KI-generierte Warntext kann Transparenzpflichten nach Art. 50 auslösen [8]. KI-Kompetenz (Art. 4) gilt für die einsetzenden Organisationen.
• DSGVO / ePrivacy / Fernmeldegeheimnis: Anrufaudio und Nachrichtentext sind personenbezogene Daten und Kommunikationsinhalte. Verarbeitung auf dem Gerät ohne Abfluss ist der datenschutzrechtlich bevorzugte Entwurf; serverseitige Analyse braucht eine klare Rechtsgrundlage, die Einwilligung des Nutzers (und bei Aufzeichnung oder Analyse von Anrufen nach nationalem Recht auch der Gegenseite, z. B. § 201 StGB in Deutschland), Datenminimierung und strenge Aufbewahrungsfristen. Betreiber sind an das Fernmeldegeheimnis gebunden (TDDDG/TKG in Deutschland).
• Schaden für Verbraucher: fälschliches Blockieren legitimer Anrufe (Notfall, Medizin); abmildern durch nachvollziehbare Warnungen und einfaches Übergehen, niemals durch stilles Löschen wichtiger Nachrichten.
• Gegenmaßnahmen: lokale Verarbeitung, Opt-in, transparente Erklärungen, Beschwerdeweg, Red-Team-Tests mit Betrugstranskripten, Barrierefreiheit für ältere Nutzer.

Erste Schritte

1. Bedrohungen in Ihrer Zielgruppe erfassen (z. B. anhand von Berichten der nationalen Polizei bzw. Verbraucherzentralen [5]) und 5–10 Betrugsskripte in Ihrer Sprache als Testfälle auswählen.
2. Verbraucher/Familien: Betrugserkennung und Spamschutz des Betriebssystems aktivieren und ein Familien-Codewort vereinbaren; Organisationen: 2–3 Anbieteroptionen (Weg A) an echten Anruf-/Nachrichtenproben bewerten.
3. Für einen eigenen Dienst zuerst mit Text prototypen: LLM-basierter Klassifikator auf 500 gekennzeichneten Betrugs-/legitimen Nachrichten, Falschalarme messen.
4. Den Audiopfad erst nach rechtlicher Prüfung ergänzen (Einwilligung, Fernmeldegeheimnis); Gemma 3n oder quantisiertes Whisper-small auf den Zielgeräten auf Latenz und Akkuverbrauch testen.
5. Warnungen mit nachgelagerten Kontrollen verbinden (Zusatzabfrage der Bank, Vertrauensperson) und die Kennzahlen monatlich verfolgen.

Quellen

1. Microsoft Security — Cyber Signals Issue 9: AI-powered deception — https://www.microsoft.com/en-us/security/blog/2025/04/16/cyber-signals-issue-9-ai-powered-deception-emerging-fraud-threats-and-countermeasures/
2. Google — ML Kit GenAI APIs (on-device Gemini Nano, AICore) — https://developers.google.com/ml-kit/genai
3. Google DeepMind — Gemma 3n E4B-it model card — https://huggingface.co/google/gemma-3n-E4B-it
4. US FTC — Data Spotlight (April 2026: USD 2.1 billion reported losses to scams starting on social media in 2025, an eightfold increase since 2020) — https://www.ftc.gov/news-events/news/press-releases/2026/04/new-ftc-data-show-people-have-lost-billions-social-media-scams
5. Polizeiliche Kriminalprävention — Betrug (Enkeltrick, falsche Polizisten, Schockanrufe, Messenger-Betrug) — https://www.polizei-beratung.de/themen-und-tipps/betrug/
6. llama.cpp — https://github.com/ggml-org/llama.cpp
7. faster-whisper — https://github.com/SYSTRAN/faster-whisper
8. EU AI Act Article 50 (transparency obligations) — https://artificialintelligenceact.eu/article/50/