The Enterprise Mobile RFP Template: How to Evaluate Vendors on On-Device AI, MDM, and Edge Capabilities

Most enterprise mobile RFPs fail before they reach a vendor's inbox. The template was written for a different era: cloud-first, consumer-grade assumptions baked into every section, with no criteria for on-device AI readiness, MDM integration depth, or edge inference performance. For procurement and IT leaders evaluating enterprise mobile app development with on-device AI, that gap is not a minor oversight. It is the reason organizations sign contracts with vendors whose "AI features" collapse the moment a device goes offline.

Why Do Standard RFP Templates Fail Enterprise Mobile AI Procurement?

Generic RFP templates, even technology-focused ones, are built around a cloud-delivery assumption. Every scoring dimension, every vendor question, every compliance checkbox traces back to a model where compute lives in a data center and the mobile device is a thin client. That assumption is wrong for enterprise mobile app development with on-device AI. It produces three specific structural gaps.

Gap 1: No criteria for on-device model formats. Standard templates ask whether a vendor "supports AI/ML capabilities." They do not ask whether the vendor supports Core ML for iOS, TensorFlow Lite or ONNX Runtime for Android, or whether models are quantized for INT8 inference on mid-range hardware. A vendor can answer "yes" to the generic question while delivering a product that makes an API call to a cloud inference endpoint every time the AI feature runs.

Gap 2: No MDM/EMM integration depth questions. Basic enrollment is not MDM integration. Enterprise mobile deployments require managed app configuration via the AppConfig Community standard, per-app VPN support, certificate-based authentication, and the ability to remotely wipe AI model weights independently of app data. A vendor who lists "Intune compatible" in their marketing materials may mean only that the app installs via Intune. That is not the same as supporting managed configuration schemas or silent model updates via MDM push.

Gap 3: No edge inference benchmarking requirements. Vendors routinely provide benchmark data only on current flagship devices. A logistics company deploying to a fleet of three-year-old Android mid-range devices, or a field workforce running ruggedized hardware, will see inference latency two to five times higher than the vendor's published numbers. The RFP template never asked for tiered device benchmarks, so the vendor never provided them.

The scenario plays out predictably. A healthcare organization selects a vendor based on a generic RFP. The vendor's demo runs on a Wi-Fi-connected iPad Pro in a conference room. Post-contract, the IT team discovers that every AI inference call requires a live connection to the vendor's cloud endpoint, that the MDM "integration" is enrollment-only with no managed configuration support, and that the vendor's security documentation does not address PHI handling on-device at all. The contract is signed. The remediation cost is real.

MDM requirements for enterprise mobile differ from consumer mobile in ways that matter specifically for AI deployments. Policy enforcement, containerization, remote wipe of model weights, and per-app VPN are not features most consumer-grade MDM documentation even addresses. The RFP template in the following sections is structured to expose exactly these gaps before a contract is signed.

How to Score RFP Dimensions and Weightings

The scoring framework below gives procurement teams a defensible, auditable basis for vendor comparison. Apply it before sending the RFP so evaluators understand the logic behind each question.

Recommended Weighting Table

Evaluation Dimension	Default Weight	Regulated Industry Weight
On-Device AI Capability	30%	25%
MDM/EMM Integration Depth	25%	25%
Edge Inference and Runtime Performance	20%	15%
Security and Compliance Architecture	15%	25%
Implementation and Support Maturity	10%	10%

Organizations in regulated industries should shift weight toward Security and Compliance. A defense contractor or clinical environment where data cannot leave the device should treat Security at 25% and reduce Edge Inference to 15%, since offline-first is already a pass/fail gate rather than a scored dimension.

Scoring Scale

• 0: Not supported
• 1: On roadmap only, no committed delivery date
• 2: Partial support or third-party dependency required
• 3: Native, fully supported, with documentation and reference implementation available

Pass/Fail Gates

These criteria disqualify a vendor regardless of total weighted score:

• No support for managed app configuration via MDM (AppConfig Community standard or equivalent)
• No on-device inference capability without a persistent internet connection
• No documented data residency guarantee for on-device processed data
• No SOC 2 Type II certification or equivalent (for commercial deployments)

For a deeper look at how to structure the full vendor comparison process, the Enterprise Mobile App Development Vendor Scorecard 2026 provides a parallel scoring framework that complements this RFP template.

Adapting Weights by Deployment Context

Field workforce apps should elevate Edge Inference to 30% and treat extended offline operation as a pass/fail gate. Executive mobile deployments can reduce Edge Inference weight and increase Implementation Maturity, since device diversity is lower and connectivity is more reliable. Regulated clinical environments should treat Security and MDM as co-equal at 25% each.

What Does the RFP Template Cover?

This is the copy-paste section. Each table below maps directly to the scoring scale defined above. Include a vendor attestation signature block at the end of your RFP requiring a named technical contact to sign off on all responses.

Section 1: On-Device AI Capability (30%)

Vendor Question	Score 0	Score 1	Score 2	Score 3
Which on-device model formats do you support natively? (Core ML, TFLite, ONNX Runtime)	None supported	One format, roadmap for others	Two formats, third-party wrapper required	All three, native SDK integration
What is the maximum model size supported without measurable inference latency degradation on mid-range Android hardware?	No data provided	Flagship-only data	Mid-range data for one OS	Tiered data across iOS and Android mid-range
Do you support model quantization (INT8/INT4) and pruning for on-device deployment?	No	Roadmap	Third-party tooling required	Native tooling with documentation
Do you support on-device fine-tuning or federated learning?	No	Roadmap	Partial, requires cloud coordination	Full on-device or federated with privacy guarantees
What is the fallback behavior when device NPU/GPU is insufficient for inference?	App fails	Undefined	CPU fallback, undocumented	Documented CPU fallback with latency SLA

(Most commonly missed): The fallback behavior question. Vendors routinely omit this because their testing environment uses current-generation hardware with dedicated NPUs. In production, a significant portion of enterprise device fleets run hardware without NPU support, and undocumented CPU fallback produces unpredictable user experience.

Section 2: MDM/EMM Integration Depth (25%)

Vendor Question	Score 0	Score 1	Score 2	Score 3
Do you support managed app configuration via AppConfig Community standard?	No	Roadmap	Partial key/value support	Full schema with documentation
Which MDM platforms are you certified compatible with? (Intune, Jamf, Workspace ONE, MaaS360)	None	One, enrollment only	Two or more, enrollment only	Two or more, full managed config support
Do you support per-app VPN configuration via MDM?	No	Roadmap	Manual configuration required	MDM-managed, documented
Can AI model weights be remotely wiped independently of app data via MDM command?	No	Roadmap	Requires full app wipe	Independent model wipe supported
Do you support certificate-based authentication integrated with enterprise PKI via MDM?	No	Roadmap	Third-party dependency	Native, documented

(Most commonly missed): Remote wipe of AI model weights independently of app data. Procurement teams assume that remote wipe covers all sensitive data. In practice, model weights trained on or fine-tuned with proprietary data are intellectual property and may contain embedded signals from training data. Standard MDM wipe commands operate at the app or device level, not the model artifact level. Vendors who cannot answer this question specifically have not designed for enterprise data governance.

Section 3: Edge Inference and Runtime Performance (20%)

Vendor Question	Score 0	Score 1	Score 2	Score 3
Provide inference latency benchmarks for: iPhone 13, Samsung Galaxy S22, and one Android mid-range device (Snapdragon 695 or equivalent)	None provided	Flagship only	Two device tiers	All three tiers, reproducible methodology
What is the maximum documented offline inference duration without connectivity?	Not supported	Under 4 hours	4-24 hours	72+ hours with documented degradation curve
How are model updates delivered without requiring an app store resubmission?	Not supported	Manual sideload	OTA via vendor CDN	MDM silent push, no app store dependency
Do you support on-device model versioning and rollback?	No	Roadmap	Manual rollback	Automated versioning with rollback API

(Most commonly missed): Model update delivery without app store resubmission. Enterprise IT teams cannot accept a model update cycle tied to app store review timelines, which can run two to seven days. Vendors who deliver model updates only through app binary updates create a security and operational risk: a compromised or underperforming model cannot be patched quickly. Ask vendors to demonstrate this capability in a proof-of-concept, not just describe it.

Section 4: Security and Compliance Architecture (15%)

Vendor Question	Score 0	Score 1	Score 2	Score 3
What data residency guarantees apply to data processed by on-device AI?	None	Policy statement only	Contractual, no audit	Contractual with audit rights
Do you support differential privacy for on-device model training or federated learning?	No	Roadmap	Third-party library	Native implementation, documented
What mechanisms protect model IP from extraction or reverse engineering on-device?	None	Obfuscation only	Encrypted model weights	Encrypted weights plus secure enclave storage
Which compliance certifications do you hold? (SOC 2 Type II, FedRAMP, HIPAA BAA)	None	In progress	SOC 2 Type II only	SOC 2 Type II plus one or more additional

Section 5: Implementation and Support Maturity (10%)

Vendor Question	Score 0	Score 1	Score 2	Score 3
Provide two reference customers with on-device AI deployments in MDM-managed environments	None	One reference	Two references, no MDM detail	Two references with MDM architecture detail
What is your documented implementation timeline for an MDM-integrated on-device AI rollout?	No documentation	Estimate only	General timeline	Phase-by-phase plan with milestones
What are your SLA terms for on-device model performance degradation?	No SLA	Best effort	Response SLA only	Response plus remediation SLA

For guidance on structuring the questions before you send this template, the article How To Write Mobile Development RFP 2026 covers the process of scoping and sequencing vendor questions to get technically useful responses rather than marketing answers.

How to Evaluate Vendor Responses: Red Flags and Scoring Walkthroughs

Red Flags

A vendor claims "on-device AI" but cannot specify the model format, cannot provide an offline inference demo, or describes their AI feature as "processing data locally" without clarifying whether inference runs on-device or on a local network server. These are different things.

MDM support listed as "compatible" with no AppConfig schema documentation means enrollment-only compatibility. Ask for the managed configuration schema file. If the vendor cannot produce it, score MDM integration at 0 or 1.

Edge inference benchmarks provided only on current flagship devices, with no mid-range or older device data, confirm the vendor has not tested their product on the hardware your fleet actually runs. This is not a minor gap. It means performance claims are not production-validated.

Security sections answered with marketing language ("we take security seriously," "enterprise-grade encryption") rather than specific certifications, architecture diagrams, or audit report references should be scored at 0 for each unanswered criterion.

Green Flags

The vendor provides a reproducible benchmark methodology: named device models, OS versions, model size, quantization level, and raw latency numbers in milliseconds. They offer to run the benchmark in your environment during a proof-of-concept.

MDM integration documentation includes a downloadable AppConfig schema with key/value pairs for all configurable parameters. The vendor can demonstrate managed configuration working in a test Intune or Jamf environment within the proof-of-concept period.

The vendor demonstrates model update delivery via MDM silent push without an app store update, and can show version history and rollback in a staging environment.

References include at least one regulated-industry deployment where the vendor can describe the MDM architecture, not just confirm the customer exists.

Scoring Walkthrough: Vendor A vs. Vendor B

Vendor A has strong marketing materials. Their website lists Core ML, TFLite, and ONNX support. Their security page references SOC 2. Their MDM section says "compatible with all major MDM platforms."

Vendor B has a less polished proposal. They support Core ML and TFLite natively, with ONNX on roadmap for Q3. Their MDM documentation includes an AppConfig schema. They cannot demonstrate independent model weight wipe. Their benchmark data covers three device tiers.

Dimension	Weight	Vendor A Score	Vendor A Weighted	Vendor B Score	Vendor B Weighted
On-Device AI	30%	2.0	0.60	2.5	0.75
MDM/EMM Integration	25%	1.0	0.25	2.0	0.50
Edge Inference	20%	1.5	0.30	2.5	0.50
Security	15%	2.0	0.30	2.0	0.30
Implementation	10%	2.0	0.20	2.0	0.20
Total			1.65		2.25

Vendor A's "compatible with all major MDM platforms" answer scores 1 on MDM integration because no schema documentation exists. Vendor B's honest roadmap answer on ONNX scores 1 for that criterion, but their documented AppConfig schema and tiered benchmarks lift their overall score significantly. The scoring rubric surfaces the difference that marketing language obscures.

How to Adapt the RFP Template for Non-Obvious Verticals

The base template covers the universal criteria. Three verticals require specific additions that change the scoring logic.

Energy and Utilities

Field technicians in energy and utilities operate in environments with no connectivity, extreme temperatures, and ruggedized devices that may be three to five years old. Add these questions:

1. What is the minimum Android OS version and hardware specification your on-device AI supports?
2. Provide inference latency data for devices operating at temperatures below 0°C and above 40°C.
3. What is the model sync protocol for low-bandwidth satellite or LTE-M connections?
4. Do you support integration with SOTI MobiControl or Zebra's MDM platform?
5. What is the maximum offline operation duration before model accuracy degrades, and how is degradation communicated to the user?

For energy and utilities deployments, extended offline operation (72+ hours) becomes a pass/fail criterion, not a scored dimension.

Legal and Professional Services

Law firms and professional services organizations deploying on-device AI for document analysis or contract review face specific data governance requirements. Add these questions:

1. Can on-device AI inference be configured to process documents without any data leaving the device, including telemetry?
2. What audit logging is available for on-device AI inference decisions, and where are logs stored?
3. Do you support client matter isolation at the model or inference level?
4. What is your model IP protection mechanism if a device is lost or stolen before remote wipe completes?
5. Can your solution operate within a containerized workspace (e.g., Intune MAM without device enrollment)?

The last question is critical for BYOD deployments common in professional services. Vendors who require full device enrollment cannot serve this segment.

Manufacturing and Industrial

Manufacturing deployments combine the connectivity challenges of field workforce with the compliance requirements of regulated industries. Add these questions:

1. Do you support integration with industrial IoT data streams for on-device AI inference (OPC-UA, MQTT)?
2. What is your approach to model updates on air-gapped or semi-connected production floor networks?
3. Do your on-device AI features support ruggedized Android devices with IP67 or higher ratings?
4. Can inference results be written to local edge databases (SQLite, Realm) for later sync without cloud dependency?
5. What is your documented approach to model governance in environments subject to ISO 13485 or IEC 62443?

For manufacturing, the model update delivery mechanism (Section 3 of the base template) should be elevated to a pass/fail criterion. A production floor cannot accept a model update process that requires internet connectivity or app store access.

What the Scoring Framework Cannot Resolve

For a detailed breakdown of how individual vendors currently perform against on-device AI criteria specifically, the Evaluate Mobile Vendor On Device Ai Capability 2026 article maps named vendors against the model format and inference performance dimensions covered here.

The unresolved tension in any enterprise mobile AI procurement is this: vendors with the most mature on-device AI capability are often the ones with the least flexible MDM integration, because they built their AI stack before enterprise MDM requirements were part of their design assumptions. Vendors with the deepest MDM integration are often the ones who added on-device AI as a feature layer on top of an existing EMM-first architecture, which means their model performance and format support lags behind AI-native vendors.

Choosing between a vendor with strong AI capability and weak MDM integration versus a vendor with strong MDM integration and weaker AI capability depends on whether your organization's primary risk is AI performance failure or MDM compliance failure. Those are different risks with different consequences. The weighting table is where that organizational judgment gets made explicit. Getting that weighting decision right, before the RFP goes out, is the work that no template can do for you.