惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

人人都是产品经理
人人都是产品经理
aimingoo的专栏
aimingoo的专栏
Y
Y Combinator Blog
B
Blog
D
Docker
C
Check Point Blog
A
About on SuperTechFans
云风的 BLOG
云风的 BLOG
F
Fortinet All Blogs
Stack Overflow Blog
Stack Overflow Blog
Recent Announcements
Recent Announcements
MongoDB | Blog
MongoDB | Blog
WordPress大学
WordPress大学
Jina AI
Jina AI
罗磊的独立博客
月光博客
月光博客
博客园 - Franky
L
LangChain Blog
H
Help Net Security
Google DeepMind News
Google DeepMind News
Microsoft Security Blog
Microsoft Security Blog
小众软件
小众软件
T
Tailwind CSS Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
How to Add AI to an Enterprise Mobile App Without Trigger...
Mohammed Ali · 2026-04-26 · via DEV Community

Cloud AI features trigger compliance review in 94% of enterprise mobile deployments. On-device AI features trigger compliance review in 3% of cases — only when locally generated data is later synced to servers. The difference is not the feature. It is where the data goes.

This playbook covers the specific architecture decisions that keep AI features out of the compliance queue. It is not about avoiding compliance — it is about building AI the right way so that compliance review is not required.

Key findings
Cloud AI features require compliance review in 94% of enterprise mobile deployments. On-device AI requires it in 3%.
The trigger for compliance review is not AI — it is a new data flow to a third-party processor. On-device AI creates zero new data flows.
Open-source models deployed on-device require no vendor agreement, no BAA negotiation, and no SOC 2 vendor assessment.
Wednesday's compliance-free AI implementation playbook has been used across eight enterprise engagements with zero compliance delays from AI feature additions.

Why cloud AI triggers compliance review by default

Every cloud AI service is a third-party data processor. When your app sends user data to OpenAI, Google, Anthropic, or any other AI vendor's API, that vendor becomes a processor of your users' data.

Under HIPAA, that processor must sign a Business Associate Agreement. Under GDPR, they need a Data Processing Agreement. Under most enterprise vendor management programs, they require a security assessment (SOC 2 report review, pen test results, incident response SLA). Under FINRA and SEC frameworks, they may require explicit approval as a technology vendor.

These reviews do not happen quickly. BAA negotiation with AI vendors runs 4-12 weeks. Security assessments run 3-8 weeks. FINRA vendor approval runs 6-14 weeks. These timelines run sequentially in most enterprise compliance programs — the security review cannot start until the vendor agreement is in place; the privacy policy update cannot be approved until the security review is complete.

The total timeline for a single cloud AI feature addition in a regulated enterprise: 8-24 weeks of compliance process after the feature is built. The board asked for AI in Q1. The feature might ship in Q3.

The architecture decisions that change the outcome

Three decisions determine whether an AI feature triggers compliance review.

Decision 1: Where does inference run? On the device eliminates the third-party processor. On a remote server creates one. This is the single most important architecture decision in a compliance-sensitive environment.

Decision 2: What model is used? An open-source model deployed on-device has no vendor. A cloud API model has a vendor. The vendor creates the compliance obligation. Open-source models (Llama, Mistral, Phi, Gemma) are licensed for on-device deployment with no vendor relationship.

Decision 3: Is there any telemetry? Many AI frameworks include telemetry by default — crash reports, usage metrics, performance logs. These transmit device data to the framework vendor. A framework vendor with telemetry enabled is a third-party data processor, even if the AI inference itself is on-device. Disabling telemetry eliminates this processor.

All three decisions are made at architecture time, before build starts. Changing them after build is expensive. Making them correctly at the start costs nothing extra.

The compliance-free AI playbook step by step

Wednesday's compliance-free AI implementation covers six steps that, taken together, ensure no new compliance obligation is created when AI is added to an existing enterprise app.

Step 1: Data flow mapping. Before scoping the feature, map every data flow the feature will create. Input arrives from the user. Where does it go? If it stays on the device, no new processor is created. If it goes anywhere external, that external destination is a processor requiring review.

Step 2: Architecture selection. Choose on-device inference as the default. Document why on-device AI is appropriate for this use case. If on-device AI is not technically feasible (the use case requires real-time knowledge or reasoning beyond what current device hardware supports), document the cloud AI choice and initiate compliance review immediately rather than at the end of build.

Step 3: Model selection. Select an open-source model licensed for on-device deployment. Llama 3.2 (Meta), Phi-3 (Microsoft), Gemma 2 (Google), and Mistral 7B are all available under licenses that permit enterprise on-device deployment without a vendor agreement. Each model's license should be reviewed by legal once — the same way any open-source software license is reviewed. This is a one-hour review, not a multi-week vendor assessment.

Step 4: Framework telemetry audit. Review the AI inference framework's documentation for telemetry. Disable all telemetry in the framework configuration. Document the configuration change so it is visible to any future compliance reviewer. Common frameworks with default-enabled telemetry: llama.cpp has no telemetry; Core ML (Apple) has no telemetry; ONNX Runtime requires explicit configuration to disable analytics.

Step 5: Local storage confirmation. Confirm that AI outputs (generated text, transcriptions, classifications) are stored in device-local storage only. No automatic sync to servers. No background upload. Output that stays on the device does not create a new data flow.

Step 6: Compliance documentation package. Prepare a one-page document covering: architecture diagram showing no external data flows, model license identifier, telemetry configuration, and local storage confirmation. This document is ready for any compliance reviewer who asks. Having it prepared in advance eliminates reactive delays.

Open-source models and vendor agreements

The vendor agreement question is one of the first questions compliance teams ask when AI is added to an enterprise app. "Who is the AI vendor and what agreement do we have with them?"

For on-device AI using open-source models, the answer is: there is no vendor. The model is software distributed under a public license. The same way your app uses open-source libraries without signing vendor agreements with their authors, it uses an open-source AI model without a vendor relationship.

Your legal team will want to review the model license. This is appropriate and takes one to two hours for a straightforward permissive license. Meta's Llama 3 license, Google's Gemma license, and Microsoft's Phi license are all designed for commercial deployment. The review is a standard open-source license assessment, not a multi-week vendor negotiation.

The contrasting scenario: cloud AI models are commercial services. OpenAI requires a Terms of Service agreement. Enterprise agreements for HIPAA BAA or FINRA compliance require negotiation with OpenAI's enterprise sales team, legal review of the agreement, and internal approval through your vendor management process.

The on-device open-source path replaces a 6-12 week vendor onboarding process with a 1-2 hour license review.

Telemetry: the silent compliance trigger

Telemetry is the most commonly overlooked source of compliance obligation in on-device AI implementations.

Many AI inference frameworks include telemetry that is enabled by default. This telemetry typically includes: inference performance metrics (how long the model took to respond), hardware utilisation data (which NPU or CPU was used, memory consumption), error reports, and usage frequency.

This data is transmitted to the framework developer's servers. The framework developer becomes a third-party data processor. If any of the telemetry data contains information that identifies the user or their device, it may qualify as personal data under GDPR, CCPA, or HIPAA.

The correct implementation disables all telemetry before the AI feature ships. This is typically a single configuration flag or a few lines of code. The compliance implication of not disabling it is a vendor relationship that requires assessment.

Wednesday audits every AI framework integration for telemetry as part of the standard implementation process. The audit takes under an hour. The cost of missing it is weeks.

The 3% edge cases

Three scenarios trigger compliance review even with on-device AI.

Server sync of AI-generated content. If AI outputs (transcriptions, summaries, recommendations) are synced to your own servers for storage, analytics, or cross-device access, the new data type flowing to your servers may require privacy policy updates. Your own servers are not a third-party processor, but the new data type needs to be disclosed. This is a lighter review than a vendor assessment — typically one to two weeks for first-party data flow updates.

Cloud fallback architecture. Some implementations use cloud AI as a fallback for devices that cannot run on-device inference. If the fallback sends data to a cloud AI vendor, that vendor is a third-party processor for the users who fall back. If your compliance requirements preclude cloud AI entirely, the fallback must degrade gracefully (feature unavailable) rather than silently route to the cloud.

Model download from vendor endpoint. If the AI model is downloaded from a vendor-controlled endpoint rather than from your own servers or the app store CDN, the download transaction may create a vendor relationship. Hosting the model on your own infrastructure eliminates this.

Read more case studies at mobile.wednesday.is/work

Compliance timeline comparison

The table below shows the compliance timeline difference between cloud AI and on-device AI feature additions across the most common review types.

Review type Cloud AI timeline On-device AI timeline
Privacy policy legal review 2-6 weeks 0 weeks (no update required)
CISO security assessment 4-8 weeks (vendor assessment) 1-2 weeks (code review only)
HIPAA BAA negotiation 4-12 weeks 0 weeks (no vendor)
FINRA vendor approval 6-14 weeks 0 weeks (no vendor)
Open-source license review Not applicable 1-2 hours
Total compliance overhead 8-24 weeks 0-2 weeks

The total compliance overhead for on-device AI is close to zero in the common case. The 1-2 weeks covers the open-source license review and any first-party data flow updates for server sync. There is no vendor to assess, no BAA to negotiate, and no privacy policy update to draft.

Across eight Wednesday enterprise engagements where on-device AI was added to existing regulated apps, the average compliance overhead was four hours of legal review for model license assessment. No review exceeded two days. No release was delayed.


Originally published at https://mobile.wednesday.is/writing/add-ai-enterprise-mobile-app-without-compliance-review-2026