AI² Consumer · Deep dive · scam-shield
AI scam shield: від раннього warning до контрольованого containment і recovery
Практичний AI2C-патерн — не один «детектор шахрайства», а defense-in-depth до і після ризикової дії: локально помітити розвиток підозрілої розмови, за можливості перевірити identity окремим сигналом, перевірити provenance медіа, яким шахрай намагається довести свою легенду, додати friction перед небезпечною дією, а якщо компрометація вже сталася — перейти в окремий recovery mode із trusted-channel routing, containment, evidence capture і захистом від другої хвилі recovery scams. Ключова архітектурна теза: AI score, watermark або Content Credential не повинні самі отримувати право на незворотну фінансову чи account-security дію — вони лише змінюють рівень підозри й оркеструють наступний безпечний крок, а authority лишається у користувача та офіційного provider surface.
Референсний workflow
- 1.Trigger → нова або продовжена розмова / дзвінок, де канал, контакт і поточна дія створюють fraud-risk context; система не оцінює лише одне слово.
- 2.Local context → останні релевантні повідомлення або аудіо-сигнали формують bounded контекст для on-device detection там, де це підтримує продукт.
- 3.Risk classification → модель та/або локальні classifiers шукають sequence-aware патерни соціальної інженерії: терміновість, impersonation, gift cards, переказ коштів, screen sharing або прохання змінити security settings.
- 4.Synthetic-media fork → якщо співрозмовник використовує фото, відео чи аудіо як «доказ» своєї особи, події або терміновості, система може окремо перевірити доступні provenance signals: SynthID, Content Credentials, edit history і signer. Це не verdict «справжнє/фейкове», а ще один evidence channel.
- 5.Identity verification → якщо доступний сильніший не-модельний сигнал, він оцінюється окремо: bank-app confirmation для verified financial calls або device-to-device RCS confirmation для fake call detection. Media provenance не підміняє identity verification.
- 6.Out-of-band challenge → коли медіа нібито показує знайому людину, банк, роботодавця чи держорган і від користувача вимагають consequential action, безпечний шлях — перевірка через canonical контакт/app/domain або заздалегідь узгоджений канал, а не відповідь у тому самому підозрілому треді.
- 7.Intervention policy → low/medium confidence дає warning і пояснення; contextual high-risk state може додати friction чи тимчасово заблокувати небезпечну security action; deterministic spoof confirmation може дозволити жорсткішу реакцію.
- 8.Action checkpoint → перед фінансовою або security-sensitive дією система перевіряє контекст: невідомий caller, screen sharing, financial app, sideloading, accessibility permission, synthetic-media claim або інший high-risk step.
- 9.User control → для AI-based scam suspicion користувач зберігає можливість dismiss / end call / report / block. AI тут радник-запобіжник, а не автономний «суддя».
- 10.High-assurance enforcement → verified financial calls можуть автоматично завершити дзвінок, якщо participating financial app підтверджує, що genuine outbound call не виконується; це інший authority class, ніж probabilistic AI warning або provenance result.
- 11.Compromise fork → якщо користувач уже переказав кошти, віддав credentials, надав remote access або втратив контроль над номером/акаунтом, система припиняє повторювати prevention copy і переводить сесію в окремий recovery track за типом шкоди.
- 12.Trusted recovery routing → AI не генерує «службу підтримки» з памʼяті й не використовує контакти з підозрілого повідомлення. Він веде користувача тільки до canonical app/domain/payment-provider/account-provider surface, де той сам ініціює reversal, password reset, device/session review або іншу офіційну процедуру.
- 13.Containment & evidence → до будь-якої незворотної дії AI збирає мінімальний timeline: канал, приблизний час, тип платежу/доступу, transaction reference та наявні user-provided screenshots або original media без паролів, OTP чи recovery secrets. Original file зберігається окремо від screenshot/transcode, якщо потрібна перевірка provenance.
- 14.Recovery-scam guard → будь-який несподіваний контакт, що обіцяє «повернути гроші» за оплату, переведення коштів або надання фінансових даних, знову класифікується як untrusted. Recovery mode не вимикає scam detection — він підвищує вимоги до identity і trusted destination.
- 15.Outcome & eval loop → окремо вимірюються prevention outcome і recovery outcome: чи було попередження до дії, чи synthetic-media signal був інтерпретований коректно, time-to-containment після компрометації, чи дійшов користувач до офіційного provider flow, чи виникла повторна шахрайська взаємодія та чи були unsafe autonomous actions.
Контроли та межі
- • Signal separation: reputation, AI classification, media provenance, cryptographic/device verification і partner-app confirmation мають окремі confidence semantics; їх не можна зливати в один непрозорий «risk score».
- • Least-authority intervention: warning за probabilistic signal; friction або temporary block для contextual high-risk action; hard termination лише там, де є достатньо сильний deterministic/partner signal і продуктова політика це дозволяє.
- • Provenance ≠ truth: валідний Content Credential може підтвердити походження, signer та history конкретного asset, але C2PA прямо не трактує provenance як доказ того, що показане твердження фактично правдиве.
- • No-watermark ≠ authentic: відсутність SynthID означає лише, що Gemini не виявила Google-AI watermark; Google прямо зазначає, що такий файл міг бути створений іншими AI-системами або watermark міг стати недоступним після змін.
- • Original-file preference: screenshot, re-encode, crop або platform transcoding можуть змінити чи прибрати metadata/provenance. Для forensic-style verification зберігай original asset, а результат для похідної копії позначай окремо.
- • Provenance authority ceiling: ні позитивний Content Credential, ні відсутність watermark не авторизують payment, password reset, remote-access grant чи іншу consequential action. Для цього потрібні canonical identity/provider controls.
- • On-device first: Google описує Messages і Phone Scam Detection як локальну обробку для real-time warnings; call audio для Phone Scam Detection не зберігається і не надсилається на сервери Google.
- • Bounded scope: Messages Scam Detection орієнтується на non-contact conversations, а Phone Scam Detection не використовується для calls with contacts; це зменшує privacy blast radius.
- • Human-in-the-loop: probabilistic detection не повинна сама переказувати гроші, видаляти контакт або виконувати фінансову дію. Користувач бачить warning і зберігає фінальне рішення.
- • Action friction: Android in-call protections можуть блокувати окремі risky settings/actions під час підозрілого дзвінка, а financial-app screen-sharing pilot вводить warning і паузу перед продовженням.
- • Privacy separation: on-device scam inference, caller-ID/spam services, media verification upload, device verification і добровільний report — різні data flows. Маркетингове «все on-device» без цього розділення буде неправдою.
- • Fallback contract: якщо identity-verification або media-provenance signal unavailable, invalid чи unsupported, система не повинна вигадувати «verified». Вона деградує до warning/manual verification path.
- • Trusted-destination allowlist: recovery links/deep links походять із versioned provider registry або OS-owned surfaces. URL, номер телефону чи QR-код із підозрілого контенту ніколи не успадковує trust лише тому, що модель красиво пояснила його призначення.
- • Credential non-collection: recovery copilot не просить пароль, OTP, recovery code, seed phrase, full card credentials або security answers. Re-authentication виконується всередині офіційного provider surface.
- • Authority split after compromise: AI може класифікувати incident, пріоритезувати кроки й підготувати evidence summary; reversal/dispute, password reset, session revocation, carrier recovery та інші consequential actions запускаються користувачем або детермінованим provider control із власною автентифікацією.
- • Second-wave defense: recovery state сам є high-risk context. Несподівані «агенти з повернення коштів», прохання сплатити fee, перевести гроші у «safe account» або передати financial info автоматично повертають систему в scam-warning path.
- • Evidence minimization: incident timeline зберігає лише те, що потрібне для support/reporting; secrets редагуються або не приймаються. Retention і delete policy мають бути окремими від model conversation history.
- • Recovery KPI: time-to-trusted-provider, time-to-containment, completed official recovery flow, duplicate/unsafe action rate, second-wave scam exposure і false reassurance. «Користувач відкрив warning» — надто дешевий KPI.
- • Provenance KPI: supported-verification coverage, correct interpretation of positive/negative/invalid/absent credentials, false reassurance after “no watermark”, original-file availability і percentage of high-risk media claims that were followed by out-of-band verification.
- • Freshness gate: країни, мови, моделі, device coverage, participating banks, verification formats та provider recovery flows змінюються; availability і canonical destinations треба перевіряти окремо від архітектурного патерну.
Зріз доказів
- • FTC повідомила у березні 2026 року: за 2025 рік споживачі подали близько 3 млн fraud reports і повідомили про $15.9 млрд втрат. Це reported consumer loss data, а не оцінка повного реального масштабу шахрайства.
- • FTC окремо повідомила у червні 2026 року: imposter scams дали понад 1 млн reports і близько $3.5 млрд reported losses у 2025 році.
- • Google у лютому 2026 року повідомила, що Scam Detection у Google Messages розширено більш ніж на 20 країн і кілька мов; на частині нових Android flagship devices використовується Gemini on-device model.
- • Google описує ціль як detection conversational scams, що можуть починатися нешкідливо і ставати небезпечними пізніше — це аргумент на користь sequence-aware detection замість keyword blacklist.
- • 12 травня 2026 року Google анонсувала verified financial calls для Android 11+: якщо participating bank app підтверджує, що genuine call не виконується, Android може автоматично завершити spoofed call. Початково названі Revolut, Itaú і Nubank; це product rollout claim Google, не незалежний fraud-reduction benchmark.
- • 2 червня 2026 року Google представила fake call detection: Phone by Google використовує end-to-end encrypted RCS confirmation між пристроями; при відсутності первинного confirmation система може перевірити фактичний device контакту і попередити про impersonation. Для launch потрібні Android 12+, Phone by Google, Contacts, Google Messages/RCS і підтримка обома сторонами.
- • Google у грудні 2025 року описала expanded in-call protection pilot: коли користувач відкриває participating financial app під час screen sharing і дзвінка з non-contact, Android показує warning і вводить 30-секундну паузу перед можливістю продовжити. Це reported product behavior; публічного незалежного causal-effect benchmark у джерелі немає.
- • Phone by Google Help прямо попереджає, що Scam Detection не виявляє всі scam calls і не є 100% accurate. Це важливий production boundary для UX, support copy і acceptance criteria.
- • 19 травня 2026 року Google повідомила про розширення content-verification tools у Search, Gemini, Chrome, Pixel і Cloud та про C2PA Content Credentials у власних generative-media/camera flows. У тому ж матеріалі Google повідомляє про понад 100 млрд watermarked images/videos і 60 000 років audio та 50 млн використань Gemini verification — це provider-reported scale metrics, не accuracy benchmark.
- • Актуальний Gemini Apps Help описує два окремі verification mechanisms: SynthID для Google-AI watermark та Content Credentials для origin/history. Якщо SynthID не знайдений, Google прямо застерігає: контент усе ще міг бути створений іншою AI-системою; отже negative result не є доказом authenticity.
- • Gemini Apps Help також документує Content Credentials verification для image/video/audio і зазначає, що валідні credentials можуть показати signer, media composition, edit history та AI use. Підтримка залежить від compatible C2PA versions/products, а invalid/unsupported/unrecognized credentials мають окремі failure states.
- • C2PA Explainer прямо встановлює semantic boundary: Content Credentials підтверджують provenance/integrity claims, але provenance сама по собі не визначає, чи контент правдивий, accurate або factual. Відсутність Content Credentials також не робить asset автоматично недовіреним.
- • FTC у своїй recovery guidance радить після платежу шахраю звертатися саме до компанії/банку/provider, через який були відправлені кошти, і просити зупинити або повернути транзакцію, якщо це можливо; конкретні кроки залежать від payment rail. Це аргумент за provider-aware recovery routing, а не за універсальну кнопку «AI поверни гроші».
- • FTC окремо радить після передачі username/password змінити пароль і всі повторно використані паролі; якщо шахрай отримав remote access до компʼютера — оновити security software, провести scan і видалити знайдене; при захопленні phone number/account — повернути контроль через carrier і перевірити фінансові акаунти на unauthorized changes.
- • Google Account Help описує recovery як офіційний account flow: якщо sign-in втрачено — account recovery; якщо доступ є — review recent security events та devices і видалення/позначення незнайомої активності. Це provider-owned control surface, а не дія, яку consumer LLM повинен емулювати власними credentials.
- • Apple Support для compromised Apple Account радить змінити або reset password, перевірити security/account data на account.apple.com, видалити невідомі devices, переконатися у контролі над повʼязаними email/phone та після відновлення ввімкнути two-factor authentication; це ще один приклад recovery через canonical provider authority.
- • FTC у червні 2026 року окремо попередила про second-wave refund/recovery scam: шахраї представляються «агентами FTC», обіцяють повернути втрати з попередньої афери та просять оплату, переказ у вказаний рахунок або financial information. Отже post-incident UX не може автоматично довіряти самому факту «recovery offer».
- • У липні 2026 року FTC знову підкреслила time sensitivity: якщо людина вже заплатила шахраю, треба без зволікання звернутися до payment company/provider і запитати, чи можна зупинити або reverse transaction. Це guidance, не гарантія повернення коштів і не benchmark конкретного AI-продукту.
Що не можна перебільшувати
- • У наведених Google-джерелах немає публічного precision / recall benchmark для Messages або Phone Scam Detection, тому AI-Magister не приписує їм конкретну точність або незалежно доведену prevented-loss ефективність.
- • Verified financial calls і fake call detection — не те саме, що AI classification: вони використовують app/device verification signals. Їх не можна подавати як «Gemini сам визначив, що дзвінок фейковий».
- • SynthID verification теж не є універсальним deepfake detector. Поточний Gemini Help прямо каже, що Gemini наразі розпізнає SynthID для контенту, створеного Google AI tools; negative result не виключає інший генератор.
- • Content Credentials не є “сертифікатом правди”. C2PA дозволяє перевірити provenance та integrity заяв, але достовірність реального твердження все одно потребує source/identity/context verification.
- • Відсутність Content Credentials не є негативним verdict: adoption opt-in, metadata може бути відсутня, unsupported або видалена під час редагування/перекодування. Тому “credentials absent → fake” є такою ж грубою помилкою, як “credentials valid → усе правдиве”.
- • Фраза «on-device» стосується конкретних Scam Detection inference paths. Caller ID/spam, reporting, media uploads for verification та інші platform services мають окремі правила обробки даних.
- • FTC-цифри — дані США про reported losses. Їх не можна переносити на весь світ або трактувати як суму, яку конкретна Android-функція здатна запобігти.
- • Google scale figures для SynthID/verification — provider-reported usage/coverage metrics, а не independent precision, recall, false-positive чи prevented-loss evidence.
- • 30-секундна pause у financial-app pilot — опис Google про product behavior, а не незалежно доведений optimal intervention interval. Власний продукт має тестувати friction vs abandonment vs prevented unsafe actions.
- • Automatic call termination виправдана лише для сильного verification contract. Якщо partner/app confirmation unavailable, безпечний fallback — warning/manual verification, а не самовпевнене блокування.
- • Scammers адаптуються до detection logic. Production KPI має включати false-negative rate, adversarial drift, time-to-warning, override quality і unsafe-action completion rate, а не лише кількість показаних alerts.
- • Recovery не гарантує повернення грошей. FTC прямо зазначає різну reversibility для різних payment methods; crypto payments зазвичай не є reversible. AI має пояснювати uncertainty, а не створювати фальшиве відчуття «case resolved».
- • Google й Apple recovery guidance використані як design references для trusted provider routing. Це не твердження, що Google Account або Apple Account уже інтегровані в описаний AI2C scam shield чи делегують LLM право виконувати account recovery.
- • FTC guidance орієнтована на США. Для production-продукту legal/reporting/payment routing має бути country-aware, а не механічно копіювати американські контакти глобальній аудиторії.
- • Canonical recovery destinations і media-verification capabilities змінюються. Їх треба версіонувати та верифікувати поза model output; hard-coded URL у prompt — майже такий самий «надійний» control, як sticky note на моніторі.
- • Recovery mode не повинен збирати більше sensitive data, ніж attack уже забрав. Паролі, OTP, seed phrases, security answers і recovery secrets не входять у model context навіть «для зручності користувача».
Джерела
Google Security Blog — Staying One Step Ahead: Strengthening Android’s Lead in Scam Protection (Feb 2026)Поточна на 2026 рік картина розширення Messages/Phone Scam Detection, мов, device coverage та on-device Gemini.Google Security Blog — What’s New in Android Security and Privacy in 2026Первинний опис verified financial calls: app-backed verification, automatic termination для spoofed calls і початкові партнери.Google Security Blog — How Android helps keep you safe from impersonation scams with fake call detectionПервинний опис RCS-based device confirmation, privacy/requirements і rollout fake call detection у 2026 році.Google Security Blog — Android expands pilot for in-call scam protection for financial appsПервинний опис screen-sharing + financial-app risk context, warning і 30-second pause у expanded pilot.Google Security Blog — New AI-Powered Scam Detection Features to Help Protect You on AndroidПервинний опис real-time conversational detection, non-contact scope, user controls та on-device processing.Phone by Google Help — Use Scam DetectionАктуальний support boundary: feature coverage, on-device behavior та пряме попередження, що Scam Detection не є 100% accurate.Android Help — Protect yourself from likely scam callsОпераційний contract verified financial calls: real-time bank-app confirmation, inbound-only number protection і call termination.Google Messages Help — How Google protects your privacy with spam detectionPrivacy caveat: spam protection має окремі правила обробки даних від Scam Detection.Google — Making it easier to understand how content was created and edited (May 2026)Primary product update для SynthID/C2PA verification, Pixel capture provenance і provider-reported scale metrics; не accuracy benchmark.Gemini Apps Help — Verify AI-generated images, videos, and audioCurrent product semantics: SynthID vs Content Credentials, supported media, negative-result boundary, C2PA validation states і current availability.C2PA — C2PA and Content Credentials ExplainerPrimary standards reference для provenance semantics: valid provenance не дорівнює factual truth; відсутність credentials не є автоматичним distrust verdict.C2PA — Specifications 2.4Current C2PA specification index verified 2026-08-20; Google Gemini Help currently documents compatible Content Credentials 2.2+.Federal Trade Commission — FTC Testifies on Agency’s Efforts to Combat Fraud (Mar 2026)Первинне джерело для 3 млн fraud reports і $15.9 млрд reported losses за 2025 рік.Federal Trade Commission — FTC Data Show People Reported Losing $3.5 Billion to Imposter Scams in 2025Первинне джерело для imposter-scam reports/losses; reported losses, не AI performance metric.Federal Trade Commission — What To Do if You Were ScammedПервинний recovery reference: payment-specific reversal requests, credential reset, remote-access cleanup, phone-account recovery та reporting.Google Account Help — Secure a hacked or compromised Google AccountProvider-owned recovery pattern: account recovery, review security events, review devices та further security steps.Apple Support — If you think your Apple Account has been compromisedCanonical account recovery pattern: password reset, account-data review, unknown-device removal, phone/email control та 2FA hardening.Federal Trade Commission — A real FTC employee won’t text you their photo ID to “verify” their identity (Jun 2026)Первинний recent reference для second-wave refund/recovery scams після попередньої втрати.Federal Trade Commission — A way to spot scams: how someone asks you to pay (Jul 2026)Recent primary guidance: після оплати шахраю не зволікати й одразу звернутися до payment provider щодо stop/reverse transaction; це guidance, не recovery guarantee.