What Enterprise CTOs Get Wrong When Scoping Mobile AI Features: 2026 Analysis for US Companies

Enterprise mobile AI projects average 4.2 unplanned weeks of delay. The delay does not come from hard engineering problems. It comes from five scoping mistakes that are predictable, avoidable, and still made by experienced CTOs at well-resourced companies.

Each mistake is invisible at the time the scope is locked. Each one surfaces three to eight weeks into build when it is expensive to fix. This guide names all five, explains why they happen, and gives you the pre-scope checklist that prevents them.

The four-week gap nobody budgets for

When a CTO presents a mobile AI roadmap to the board, the timeline usually shows: engineering weeks, QA, and release. It rarely shows: legal review, CISO security assessment, device compatibility matrix testing, or App Store first-submission review for new AI data handling declarations.

Those missing items add an average of 4.2 weeks to the project, based on Wednesday's data across enterprise mobile AI engagements. The 4.2 weeks does not appear in the original estimate because none of these items are engineering tasks. They fall between departments, between teams, and between the scope of work and the scope of what legal, security, and the app stores require.

The good news is that all five sources of delay are predictable. Every one of them can be identified before build starts and either eliminated through architecture choices or moved to run in parallel with build so they do not extend the critical path.

Mistake one: assuming cloud AI is the only option

Most CTOs who scope a mobile AI feature default to cloud AI because that is the model they know from web products. API call out, response back, display result. The architecture is familiar. The vendors are known.

Cloud AI is not wrong. It is the right choice for many features. But it is not the only option, and choosing it by default rather than by design means inheriting its compliance implications without evaluating alternatives.

Cloud AI creates a new third-party data processor. That processor needs to be reviewed by legal (is the vendor agreement acceptable?), by the CISO (does the data flow meet security requirements?), and in regulated industries, by compliance (HIPAA BAA, FINRA vendor review, SOC 2 assessment). Each review runs on a different timeline with different owners.

On-device AI eliminates all three reviews by keeping data on the device. The tradeoff is implementation complexity and device minimum requirements. But for many enterprise use cases — voice transcription, document summarisation, image analysis — on-device AI produces equivalent results without the compliance overhead.

The scoping mistake is not choosing cloud AI. The scoping mistake is choosing cloud AI without evaluating the compliance timeline that follows, then presenting a release date that does not account for it.

Mistake two: not factoring in CISO review time

CISO review of a new AI feature averages 6 weeks when initiated after build starts. When initiated in parallel with build, it completes in 2-3 weeks.

The difference is not the review itself. It is when the CISO team receives the request. Security teams at mid-market enterprises typically have a review queue. A request submitted at the start of a project sits at the top of the queue. A request submitted when the feature is nearly complete joins a queue that has grown by six weeks.

The CISO review covers: what data the feature processes, where the data goes, which vendor receives it, what the vendor's security posture looks like (SOC 2 report, pen test results, incident response SLA), what happens in a breach scenario, and whether the feature complies with any data residency requirements.

This review is not fast by nature. But it is parallelisable. The architecture decision and the vendor selection are made at scope time. Those two pieces of information — what data flows where, to which vendor — are all the CISO team needs to begin. Starting the review the day the scope is approved saves 3-4 weeks on the critical path.

The scoping mistake is treating CISO review as a final-mile step. The fix is treating it as a parallel workstream with a defined start date in the project plan.

Mistake three: scoping the model before the data flow

The third mistake is choosing the AI model before understanding what data it will process and where that data lives.

Many scoping conversations start with: "We want to use GPT-4o" or "We are looking at Gemini." The model is named in the first meeting. The data flow is discussed in week three, when the engineers start asking questions.

Model-first scoping creates two problems. First, the model choice may be incompatible with data residency or compliance requirements that emerge later. If your HIPAA-covered data cannot go to a specific vendor's API, but the model choice assumed that vendor, the scope needs to change.

Second, model-first scoping skips the question of whether on-device AI is feasible for the use case. A 3B parameter model on-device handles most text summarisation and classification tasks. If the scoping conversation starts with cloud model names, on-device alternatives are never evaluated. The compliance and data flow implications of cloud AI are inherited without the evaluation step.

The right scoping sequence is: define the user outcome, map the data the feature will process, determine where that data can go based on compliance requirements, then evaluate which models (on-device or cloud) produce the required output within those constraints. The model is the last decision, not the first.

Mistake four: underestimating device compatibility testing

Standard mobile QA tests across a representative set of devices. For most features, this is sufficient. For on-device AI, it is not.

On-device AI features have hard dependencies on device hardware: RAM for model loading, NPU availability for hardware-accelerated inference, and specific chipset variants for Android. These dependencies create a compatibility matrix that is fundamentally different from standard QA.

An on-device voice transcription feature that works on an iPhone 15 Pro with 8GB RAM may produce different performance characteristics on an iPhone 14 with 6GB RAM, and may not run at all on an iPhone 12 with 4GB RAM. The Android picture is more complex: Qualcomm, Exynos, and MediaTek chipsets each have different NPU capabilities, and Qualcomm's QNN SDK requires chipset-specific model variants.

Underestimating device compatibility testing adds two to four weeks to the project. The testing itself takes time, but the larger delay is architectural: when device compatibility testing reveals unexpected failure cases, the architecture may need to change (different model size, different fallback behaviour, different minimum device requirement) and that change needs re-testing.

The fix is to define the device compatibility matrix at scope time, before build starts. This means: what is the minimum device specification the feature will support, what is the fallback behaviour on unsupported devices, and how will the app detect and handle device capability gaps gracefully. These decisions take a few hours at scope time. They take weeks to fix if discovered during QA.

Mistake five: forgetting App Store review requirements for AI features

Apple and Google have specific requirements for apps that add AI capabilities involving user data. These requirements affect the App Store submission process for first-time AI feature launches.

On iOS, apps that process user data through AI must include a privacy manifest declaring exactly what data types are collected, processed, or used. Apps that use AI for user-generated content processing must declare the data handling in the App Store description. Submissions that do not include these declarations are rejected on first review.

First-time App Store review for apps adding AI data handling declarations averages 1-3 weeks. This is not standard review time (which runs 1-4 days for routine updates). The extended timeline occurs because App Store reviewers examine AI-related submissions more carefully to validate that declared data handling matches actual implementation.

Most mobile AI project roadmaps budget 2-4 days for App Store review, based on prior release history. The first AI feature submission typically takes 7-21 days. That gap is the mistake.

The fix is to treat the first AI feature submission as a new category of App Store review with its own timeline budget, and to front-load the privacy manifest preparation and App Store description update in the final two weeks of build rather than on the day of submission.

The pre-scope checklist

Before locking any mobile AI feature scope, answer these eight questions:

Question	Why it matters
Does this feature process data that cannot leave the device?	Determines cloud vs on-device architecture
Who is the CISO review owner and when will they receive the request?	Start the review the day scoping is approved
What data types does this feature process, and under what compliance regime?	Determines BAA, DPA, or vendor agreement requirements
What is the minimum device specification for this feature?	Drives the device compatibility matrix
What is the fallback behaviour on unsupported devices?	Required for App Store submission
What does the App Store privacy manifest entry look like for this feature?	Required before submission; draft it during build
Have the vendor agreements for any cloud AI components been approved?	Legal review timeline
Has the App Store description been updated to reflect AI data handling?	Required before submission; takes time to approve internally

Answering all eight questions before build starts eliminates the 4.2 unplanned weeks. The questions take two hours to answer in a scoping session with an engineer and a compliance representative.

How Wednesday uses this checklist

Wednesday's pre-scope process for every mobile AI engagement starts with this checklist. The first call is not about model selection or feature design. It is about data flow, compliance context, and CISO review timing.

The output of that first call is a one-page scope document covering: architecture recommendation (on-device or cloud with rationale), compliance review timeline with start dates, device compatibility matrix with minimum specifications, App Store submission plan with timeline budget, and build start date.

This scope document is the input to every subsequent meeting. It is also the document the CISO team receives on the day the engagement starts so their review begins immediately.

The result is a project where CISO review, legal review, and device compatibility testing all complete before the feature is ready to ship — not after.