Sponsored by
Google DeepMind and Singapore's Government Technology Agency, GovTech, have developed an artificial-intelligence model intended to identify scam patterns in conversations. Google announced the collaboration on October 14 at Singapore International Cyber Week. It is not yet a generally available consumer feature. Google says the system is intended for Android and will enter applications through a phased rollout with Singapore's government.
State of Product reveals what AI still hasn’t solved
80% of product professionals say AI helps them ship faster, but customers aren’t seeing value any sooner. Atlassian’s State of Product 2027 explores the gains AI is delivering and the challenges that remain, from decision-making that hasn’t kept pace to gut instinct overriding customer evidence.
The technical design uses two stages. A lightweight classifier first screens incoming messages while using what Google describes as minimal power. Messages it considers safe receive a benign verdict. Suspicious messages move to a fine-tuned Gemma model, which examines a larger conversation snapshot. That second stage can issue a scam warning or dismiss the initial signal. The sequence reserves deeper analysis for messages that pass the first screen. Google identifies battery efficiency as a central engineering constraint for running the classifier on phones.
Google says the model was fine-tuned on local scam conversations involving impersonations of public institutions, banks, public figures, and regional schemes. Social engineering can unfold across several exchanges, as a fraudster builds trust before asking for money or credentials. Considering preceding messages may detect patterns missed by filters that score each text independently. This is the developers' intended capability, not a measured comparison with existing tools.
Processing location is the project's main privacy distinction. Google says the deployed model will run on-device and access conversations only with user consent under the relevant application's terms. Google and Singapore's government say they will not receive conversations through deployment. The company also says training excluded private or personally identifiable citizen data. Development instead used anonymised datasets derived from scam reports and intelligence feeds, with tests using synthetic dialogues and local corpora.
Turn your expertise into working software
Describe what you want to build
Get real software, not a prototype
Lovable handles payments, logins, databases
Change any detail yourself, any time
Put it in front of customers this week
Discount of $5 applies to first month of any paid plan. You need to sign up via this webpage in order to claim the discount. The discount applies to new and returning users without an active paid plan. Terms apply.
Those statements describe the developers' design and governance claims. The announcement does not disclose false-positive or false-negative rates, test-set size, language coverage, or performance across Android devices. It also omits participating applications, a release schedule, battery measurements, and how users can challenge alerts. Without these details, readers cannot assess warning usefulness or how the system handles ordinary conversations resembling fraud. The description does not report an independent public audit, so these remain developer and government statements pending implementation evidence.
An on-device design could complement existing protections, but it does not see a scam's full sequence across services. Singapore's minister described cases moving between social networks, messaging services, telephone calls, and financial institutions. A local classifier would observe only conversations available to its host application. It would not verify callers, stop transfers, or connect signals across services. The minister separately argued that organisations need coordinated defenses, making device analysis one intervention point rather than a complete response.
Local analysis avoids sending message contents to a remote server, but privacy also depends on application access, consent, storage, and alert governance. Those conditions must be evaluated in the product that deploys the model. Local execution alone does not settle questions about permissions or user control. The public description does not yet show how these safeguards will appear in participating applications.
For now, the concrete development is a government and research-company collaboration, a two-stage architecture, and a plan for phased Android integration. Independent deployment evidence is absent. The distinction between a described design and a verified protection remains central. Future evaluations can examine detection quality, battery effects, consent flows, and real-world performance once implementation details are available.
Your agents work while you sleep
Give a Skydive agent an ongoing responsibility and they’ll handle it on schedule, every time.
Have them prep your morning report, research new leads, monitor customer feedback, or keep projects moving overnight. You wake up, the work is already done.
