On-Device AI for Government and Defense Mobile Apps: FedRAMP, Data Sovereignty, and Delivery 2026

Only 47 cloud services held FedRAMP High authorization as of late 2025. General-purpose AI APIs were not among them. For government and defense organizations that need to process Controlled Unclassified Information or higher on mobile devices, this is not a gap that can be filled with a workaround. It is a hard constraint. Cloud AI is off the table.

On-device AI is not a compromise for these use cases. It is the architecturally correct answer. The data never leaves the device. There is no cloud service to authorize. The FedRAMP question does not arise because there is no cloud processing.

This guide covers why cloud AI fails the FedRAMP test for sensitive government workflows, which AI capabilities work on-device for government and defense applications, and what scoping a government AI project looks like.

Why cloud AI fails FedRAMP requirements

FedRAMP is the US federal government's authorization program for cloud services. Any cloud service that handles federal data must be FedRAMP authorized at the appropriate impact level. The three levels are Low, Moderate, and High, corresponding to the sensitivity of the data processed.

Controlled Unclassified Information requires FedRAMP Moderate at minimum. Classified data requires controls beyond FedRAMP High and is generally handled through government-specific classified cloud environments.

The problem for AI is that the major commercial AI APIs have not pursued FedRAMP High authorization. The authorization process is expensive, the requirements are extensive, and the commercial market does not justify the investment for most vendors. FedRAMP Moderate authorizations exist for a handful of AI-adjacent services, but general-purpose language model APIs are not on the authorized products list at the level required for CUI processing.

Government program managers who want to add AI capabilities to field apps face a choice: use a non-FedRAMP cloud AI API (non-compliant), wait for FedRAMP authorization to appear (indefinite), or use on-device AI that never touches a cloud service (compliant today).

Data sovereignty and classification levels

Data sovereignty in government contexts means the government retains complete control over where its data resides and who can access it. For mobile applications, this plays out at two levels.

The first level is data in transit. Any data sent from a government device to a cloud server crosses a network boundary. The government loses direct control of the data for the duration of the transit and while it is on the server. Even if the server is operated by a trusted vendor, the data is no longer physically under government control.

The second level is data at rest. Data stored on a cloud server is subject to the operational security practices, legal jurisdiction, and subpoena exposure of wherever that server is located.

On-device AI addresses both. Data processed by an on-device model stays on the device. The device is in government possession. The data is in government possession. There is no transit and no remote storage.

Data classification	Cloud AI (typical)	On-device AI
Unclassified, public	FedRAMP Low or none required	No authorization required
Controlled Unclassified Information	FedRAMP Moderate required	Device security controls apply
CUI with Specified controls	FedRAMP High required	Enhanced device security controls
Classified	Classified cloud environment required	Classified device and app controls

The on-device column shows that the authorization question shifts from "is this cloud service authorized?" to "does this device meet the security requirements?" Government agencies already have policies for device security. They have answers to the device question. The cloud authorization question is the one that has no good answer for AI today.

On-device AI: the only viable path for CUI

For applications that handle Controlled Unclassified Information on mobile devices, on-device AI is the only path that works without a waiver or exception.

This is not a niche observation. A substantial portion of government field operations involves CUI: personnel records, medical information about service members, law enforcement information, financial information, and information systems vulnerability data. Any mobile app that touches these data categories while also providing AI features needs an architecture where the AI processing does not transmit that data to a cloud service.

The architecture is straightforward. The AI model lives on the device in app storage. The data the model processes (an audio recording, a document image, a text field) is provided to the model on-device. The output (a transcription, a classification, a summary) is returned to the app on-device. Nothing leaves the device for AI processing.

Device-level security controls, which the government already manages through MDM and security configuration standards, protect the data at rest on the device.

Government AI features feasible on-device

The following capabilities are built and tested for production use, including in environments with strict data handling requirements.

Voice transcription for field reports. Field agents, inspectors, and military personnel can dictate reports without typing. Whisper on-device models produce accurate transcriptions that stay on the device until the user submits the report through the approved backend channel.

Document processing and data extraction. Government field work involves extensive paperwork: forms, permits, inspection records, identification documents. On-device OCR extracts structured data from photos of documents without the document image being transmitted for processing.

Image classification. On-device image models can classify photos against trained categories: equipment types, infrastructure conditions, plant and wildlife species for regulatory inspection. The photo is processed locally and classified without leaving the device.

Language translation. On-device translation models cover 20-40 languages at acceptable quality for field use. Sensitive conversations do not need to be transmitted to a commercial translation API.

Text generation for reports. Structured report templates can be partially populated using on-device language models based on field inputs. A technician describes a finding in plain language; the model formats it into the required report structure.

FedRAMP authorization and on-device models

On-device AI models are software components that run within the app. They are not cloud services and do not require FedRAMP authorization.

The model file is a data file containing numerical weights. Downloading it from a vendor is similar to downloading a software library: it is a third-party component incorporated into the app. This does not create a cloud processing relationship.

What does require government approval is the app itself, through the standard Authority to Operate process. The ATO review covers all components of the app including the AI model. The review documents what the model does, what data it processes, and how the output is handled. This is the same documentation that any novel app component goes through in an ATO review. It is not a new category of approval.

Cost and timeline for government AI features

Government AI feature development has different cost drivers than commercial enterprise. The ATO documentation, security review support, and testing in representative environments add cost and time. These ranges reflect government delivery.

Feature	Cost range	ATO documentation	Total timeline
Voice transcription	$55,000 - $85,000	2-3 weeks	8-12 weeks
Document OCR and extraction	$50,000 - $80,000	2-3 weeks	8-12 weeks
Image classification	$65,000 - $100,000	2-4 weeks	9-14 weeks
Language translation	$60,000 - $95,000	2-3 weeks	8-13 weeks
Full field AI suite	$200,000 - $350,000	4-6 weeks	16-24 weeks

The ATO documentation timeline assumes the feature is new and the app already has an existing ATO. Adding AI features to an app with no existing ATO requires the full ATO process, which varies significantly by agency and program.

What to know before scoping a government AI feature

Government AI mobile projects have four questions that need answers before a vendor conversation makes sense.

What is the data classification level of the information the AI feature will touch? This determines whether cloud AI is possible at all and what device security controls are required.

Does the app have an existing ATO? If yes, the AI feature will go through a change request process. If no, the full ATO process applies to the entire app.

What devices will the users carry? Government device fleets have specific approved device lists. Not every approved device has the hardware required for on-device AI inference. Check the approved device list against the minimum device requirements for the capability you want.

Is connectivity available in the field environment? If the operational environment involves RF-shielded facilities, underground spaces, or denied-area operations, on-device AI is required not just preferred. Design for offline from the start.