How to embed on‑device scam detection in 30 min without exposing any chat data

Singapore and Google DeepMind just proved the concept: a fine-tuned Gemma model running entirely on a phone can catch conversational scams before the user sends a single cent. No cloud. No data transfer. No compliance headache.

That's the research. This is what you do with it.

By the end of this guide you'll have three things: (1) a ready-to-use prompt template for scam detection, (2) a complete fine-tuning workflow using existing SDKs, and (3) integration code that keeps every chat 100% local. Every step runs on hardware you already own.

Why On-Device Gemma Beats Cloud Scanning for Scam Protection

The instinct is to pipe suspicious messages to a cloud API and let a big model decide. That instinct is wrong for three reasons.

Zero data exfiltration. On-device inference means no network call ever carries a user's message. That eliminates regulatory exposure under GDPR, PDPA, and similar frameworks before you've written a single compliance document.

And cost compounds over time. Every message you route through a cloud API is a billable inference. On-device runs for free after the model is loaded. For a customer-service platform handling thousands of conversations a day, that adds up fast. If you're already thinking about eliminating API costs on other workloads, running local models on your LAN follows the same logic.

The prompt matters as much as the model. Here's the gap most teams miss:

Before (generic classification):

"Classify this message as scam or not:"
{user_message}

After (Gemma-optimized):

"""You are a privacy-first fraud analyst. Examine the following chat snippet and answer with ONLY:
SCAM – if it contains manipulation, phishing, or money-request tactics.
NOT SCAM – otherwise.

Chat: {user_message}
"""

The role-based version forces a binary output, which makes post-processing trivial. No parsing ambiguous text. No follow-up calls. Just a flag your app can act on instantly.

Collecting and Preparing Your Own Scam Conversation Data

The Singapore deployment worked because the training data reflected local scam patterns: specific phishing language and regional impersonation tactics. Your model needs the same specificity for your users.

Two rules before you collect anything:

• Legal safe harbor first. Store raw chats locally, strip usernames and identifiers, and tag each message with SCAM or NOT SCAM. Personally identifiable information should never enter the training set.
• Balance the dataset. Avoid over-representing scams, which produces false positives on normal messages, and avoid under-representing them, which means the model misses real attacks. A balanced, diverse dataset across both classes is worth more than a large imbalanced one.

Manual labeling at scale is where most teams stall. Use a prompt to do the first pass:

You are an AI assistant tasked with labeling chat logs.
For each message, output:
- "SCAM" if it contains any of the following cues: urgent money request,
  impersonation of authority, link to payment portal.
- "NOT SCAM" otherwise.

Message: "{message_text}"

Run this against your raw export and generate a CSV with three columns: id, text, label. A human reviewer spot-checks 10% of the output for quality. That combination, AI doing the volume work and a person doing the judgment calls, gets a usable labeled dataset in a fraction of the time manual labeling would take.

Fine-Tuning Gemma with Existing SDKs (Step-by-Step)

Step 1. Install the dependencies.

pip install mediapipe-model-maker

Step 2. Load your labeled CSV and configure the fine-tuning job.

from mediapipe_model_maker import text_classifier

# Point to your labeled CSV with 'text' and 'label' columns
train_data = text_classifier.Dataset.from_csv(
    filename='scams.csv',
    text_column='text',
    label_column='label'
)

options = text_classifier.TextClassifierOptions(
    supported_model=text_classifier.SupportedModels.MOBILEBERT_CLASSIFIER,
    hparams=text_classifier.HParams(export_dir='./fine_tuned_model')
)

Step 3. Train and export.

model = text_classifier.TextClassifier.create(train_data, options)
model.export_model()

Start with conservative hyperparameter defaults and validate before changing anything. If your false-positive rate is too high after validation, add more NOT SCAM examples to the training set before adjusting other parameters. More representative data almost always beats hyperparameter tuning.

One thing to plan for before you ship: the exported TFLite model file for a Gemma-class model runs into the gigabyte range, typically 1.4 GB or more depending on the variant. That's not a drop-in addition to a standard app bundle. You'll need to handle model delivery separately, either via an on-demand download on first launch or bundled into a dedicated update. Plan your distribution architecture around this before you write the integration code.

Step 4. Validate before you ship anything.

import numpy as np
import tensorflow as tf

interpreter = tf.lite.Interpreter(model_path='./fine_tuned_model/model.tflite')
interpreter.allocate_tensors()

# Run a quick sanity check on a known scam message
# (Wire up your tokenizer and input formatting here)
print("Model loaded. Run inference against held-out test examples before deploying.")

Adding the Model to Chat Workflows While Keeping Data Local

Integration is where the privacy architecture either holds or breaks down. The key rule: only the verdict leaves the inference layer. The raw message never gets serialized, never touches a server, never hits a log.

Here's the pattern in React Native using the react-native-fast-tflite package:

import {loadTFLiteModel} from 'react-native-fast-tflite';

const detector = await loadTFLiteModel(require('./model.tflite'));

async function handleSend(message) {
  const inputTensor = tokenize(message); // your tokenizer here
  const [verdict] = await detector.run([inputTensor]);
  if (isScam(verdict)) {
    alert('⚠️ Potential scam detected. Review before sending.');
    return; // block send
  }
  sendMessageToServer(message); // safe path
}

Hook this into the onSubmit event of any chat UI and the detection runs before the send completes. The user sees a warning. The message never leaves the device until they've had a chance to review it.

For teams working on sensitive client communications more broadly, the same data-local principle applies, which is why keeping client data safe while drafting on your Mac follows the same architecture pattern.

Prompt Templates That Catch Manipulation in Real Conversations

The fine-tuned model handles classification. Prompts handle nuance. These three cover the most common attack vectors:

"""You are a privacy-first fraud analyst. Identify any message that pressures the recipient to transfer funds within 24 h. Return ONLY SCAM or NOT SCAM."""

"""Detect if the speaker pretends to be a bank, government agency, or known brand. Output SCAM/NOT SCAM."""

"""If the message contains a URL that is shortened, unverified, or points to a payment gateway, label as SCAM."""

Each template is deliberately narrow. Narrow prompts outperform broad ones on binary tasks because the model has less room to hedge. Stack multiple checks in sequence if you need coverage across all three attack types. The performance cost on-device is minimal for three sequential inferences.

For teams using AI to review contracts or other documents for risk language, the same "narrow prompt, binary output" principle applies, as covered in the guide to scoring contract risks in 12 hours.

Deploying and Keeping Your Scam Detector Current

Scam tactics evolve. A model trained on last quarter's phishing scripts will miss this quarter's attacks. Build the update cycle in from the start.

Step 4 is the part most teams skip, and it's the reason scam detectors degrade over six months. Quarterly re-training with fresh examples keeps the model calibrated to current attack patterns without requiring a full rebuild.

Ultra Prompt's Personal AI Workflows and Business Vertical: Fraud and Compliance categories supply ready-made prompts and pipeline templates for all four steps. Nothing leaves the device at any stage.

FAQ

How do I run a scam-detection model on my own device without sending data to the cloud?

Load the exported TFLite model into your app and run inference locally using TensorFlow Lite's mobile runtime. No network request is made at inference time. Only the binary verdict (SCAM / NOT SCAM) is used by your application logic.

Can I fine-tune Gemma for my company's specific scam patterns?

What SDKs are needed to add on-device scam detection to a chat app?

How accurate are on-device AI scam detectors compared with cloud models?

According to the Google DeepMind and Singapore GovTech collaboration, the on-device Gemma approach delivers strong real-world performance, with the pilot reporting 89% accuracy. Independent accuracy comparisons against cloud baselines will vary by dataset and fine-tuning quality. Your fine-tuned model's performance will depend on how representative your training data is of the scams your users actually face.

How do I keep scam-detection data private while still getting good results?

Store raw chats locally, anonymize before labeling, and only share aggregated metrics like false-positive rates across your team. Never include raw message content in shared reports. The quarterly re-training pipeline described above follows this pattern throughout.

The Bottom Line

Google DeepMind and Singapore's GovTech showed it's possible. The fine-tuning workflow, the prompt templates, and the integration pattern above show you how to do it yourself, for your users, with your scam patterns, and without touching a cloud API.

Your users stay private. Your model stays current. And the detector runs before anyone loses money.

If you want the prompt templates and fine-tuning scaffolding without building from scratch, Ultra Prompt's On-Device Fraud Detection category has everything from labeled data prompts to deployment pipelines, ready to drop into your workflow today.