How Small Teams Can Catch Scams Without Exposing Private Chats

How Small Teams Can Catch Scams Without Exposing Private Chats

A suspicious payment message creates a bad choice for a small team: ignore it and risk a loss, or paste a private conversation into an AI tool and expose information that did not need to leave the device.

A recent project points toward a different approach, but it is not a reason to install the first “AI scam detector” you find. The useful lesson is to separate scam review from unnecessary data sharing.

What changed—and what did not

Google DeepMind and GovTech Singapore describe a collaboration using lightweight on-device Gemma models to intercept conversational scams in private chats, with zero cloud data egress, according to the provided announcement summary.

That is a reported example of on-device AI being applied to scam detection. It does not establish that the same capability is available for your company’s messaging apps, that it will catch every scam, or that it fits your legal and security requirements. Treat it as a signal about a design option—not a ready-made procurement recommendation.

For a small business, the immediate decision is simpler: define how staff should handle suspicious requests now, then assess whether an on-device tool can support that process without moving sensitive conversations elsewhere.

Build the process before adding a detector

Scams often become operational problems when a message pressures someone to change payment details, share sensitive information, or act outside the usual approval path. A model may help flag a message, but your team still needs a reliable way to verify it.

  1. Name the risky requests. List the message types that could cause harm in your business: for example, a supplier bank-detail change, an urgent invoice, or a request for account access. Keep the list specific to your actual workflows.
  2. Set a separate verification route. Decide how staff confirm a request using contact details or an internal process they already trust—not by replying to the suspicious message or relying on its links.
  3. Make escalation easy. Give staff one person or channel to use when they are unsure. Tell them to pause the action while it is reviewed, rather than making a judgment under time pressure.
  4. Record only what you need. Keep a brief incident note, such as the request type, decision, and outcome. Avoid collecting or forwarding entire private chats by default.
  5. Test the routine. Walk through a realistic example with the people who approve payments or manage accounts. Check that they know how to verify, pause, and escalate.

When on-device AI is worth evaluating

Consider a controlled evaluation if staff regularly receive suspicious messages in private or sensitive communication channels, and manual review is becoming difficult to manage. Ask the vendor or internal team exactly what runs on the device, what data leaves it, what happens to flagged messages, and how a person can review or challenge an alert.

Do not assume that “on-device” alone settles privacy or security questions. Check the complete data path, including any reporting, synchronization, diagnostics, or follow-up review. Also test how the tool behaves on your real message types and languages before letting an alert influence a payment or account decision.

Wait if scam reports are rare, your verification process is unclear, or the tool cannot explain its data handling. In those cases, improve the process first. A detector that raises alerts without a clear owner can add noise rather than reduce risk.

Know the limitation

Detection is not verification. A warning can be wrong, and a message that receives no warning should not automatically be trusted. Keep consequential decisions—especially payment changes and access requests—behind a human verification step.

For now, most small teams do not need to build a custom model. They need a dependable pause-and-verify routine and a careful way to judge any tool that claims to assist with it. The memorable rule: protect the conversation, verify the request through a separate route, and let AI support—not replace—that judgment.

Next action: Write down the person and independent contact route staff should use to verify a payment-detail change.

// Share this post

Newsletter

New articles, in your inbox

One email when we publish. No digests and no product pitches. Unsubscribe any time. Privacy policy