TL;DR: AI usage in mobile apps has risen from 18% to 25% in months and is projected to reach 80% by the end of 2026, while 75% of a typical app can sit inside third-party SDKs that silently expand data access, processing and retention risks according to NowSecure. The governance gap is now about visibility, authorization and continuous evidence, not just app hardening.
NHIMG editorial — based on content published by NowSecure: AI Security in Mobile Apps, The Hidden Threat Multiplying Faster Than You Think
By the numbers:
- AI usage in mobile apps has surged from 18% to 25% in just months, and experts predict this will surge to 80% by the end of 2026.
- Most organisations are only aware of the AI they intentionally build into their apps, while third-party SDKs account for roughly 75% of a typical mobile app.
- Only 34% of organisations have mapped their data flows to understand where AI systems send and store personal information.
Questions worth separating out
Q: How should security teams govern mobile apps that now include AI features?
A: Treat AI-enabled app functions as separate governed paths, not as ordinary code changes.
Q: Why do third-party SDKs create hidden risk in mobile AI governance?
A: SDKs can introduce data collection, inference and transmission paths that the app owner did not explicitly design or review.
Q: What breaks when organisations only review mobile AI at design time?
A: Design-time review misses runtime behaviour, SDK updates and endpoint changes that alter what data is collected or where it is sent.
Practitioner guidance
- Build an AI bill of materials for every mobile app Inventory first-party models, embedded SDKs, external APIs and any cloud AI services each app can reach.
- Map data flows at runtime, not just in code review Use dynamic testing to observe what data moves from the app to AI endpoints, where it is stored and whether behaviour changes after SDK updates.
- Enforce explicit authorization boundaries for AI components Document exactly which fields each AI system may access, then validate that actual behaviour matches those permissions in each build.
What's in the full article
NowSecure's full article covers the operational detail this post intentionally leaves for the source:
- Release-stage testing methods for detecting unauthorised AI data collection in mobile apps
- Examples of runtime data flow inspection across on-device and cloud AI components
- Operational guidance for building an AI bill of materials and maintaining release evidence
- Specific regulatory themes and audit questions that mobile app teams should expect
👉 Read NowSecure’s analysis of AI governance risks in mobile apps →
AI governance in mobile apps: are your controls keeping up?
Explore further
Mobile AI governance is becoming a hidden identity and access problem, not just a privacy problem. Once AI is embedded through SDKs, the question is no longer only what the app does, but what machine processing identities are allowed to touch, infer and transmit data. That creates a governance boundary much like NHI sprawl, where unknown components operate with implicit trust. Practitioners should treat embedded AI as an access and authorization issue, not a feature toggle.
A question worth separating out:
Q: Who is accountable when hidden AI processing in a mobile app causes compliance issues?
A: The organisation that published the app remains accountable, even if the risky behaviour came from a third-party component. Regulators and auditors will look for evidence of lawful processing, consent boundaries, data flow visibility and remediation. Responsibility cannot be outsourced to the SDK provider when the app owner chose the dependency.
👉 Read our full editorial: AI governance gaps in mobile apps are widening faster than controls