A product manager can approve an AI-assisted mobile workflow while believing the main unknown is model quality. The expensive surprise is usually where customer data travels: from a Vue form to an API, onto a phone, into a model request, and perhaps into a diagnostic log. I would scope those data paths before estimating screens or prompts, even if that delays the first demo.
The first scope decision is which data must leave the existing workflow
Start with one task, such as turning a field worker’s notes into a draft visit summary. Write down the exact fields the worker selects, where those fields currently live, and who may read the result. “Summarize the visit” is not a sufficient requirement because the underlying record might also contain an address, a private comment, or a customer identifier that the model does not need.
Draw a boundary for each transfer: Vue 3 in the browser to your API; your API to a model provider; and, if a mobile app is planned, the API to a device that may be lost or shared. For every boundary, ask whether the receiving system needs the full record, a selected excerpt, or no record at all. This exercise changes the estimate because field-level filtering, deletion, and support access require backend work even when the UI looks finished.
Vue Security and Privacy Traps Junior Devs Find Too Late is a useful warning about frontend mistakes, but I would not make Vue hardening the primary workstream here because a perfectly escaped interface can still send unnecessary personal data to an AI provider. Keep the frontend controls in scope: avoid rendering model output with Vue’s v-html unless it has been sanitized with a maintained library such as DOMPurify, and test a Content Security Policy with an explicit script-src. Neither control answers whether the prompt should contain the customer’s phone number.
Give the team a data inventory rather than a broad instruction to “be privacy compliant.” For each field, record its source, reason for inclusion, recipient, retention rule, and deletion owner. If nobody can explain why a field belongs in the prompt, exclude it from the first release; that rule makes review possible before model behavior becomes part of the argument. Include attachments separately because a photo can contain more information than the form fields around it.
I would not copy complete workflow records into prompts to improve context, because the resulting output gain is uncertain while the extra data transfers, logs, and deletion obligations are definite. If the model needs more context, require the team to demonstrate the failure on a minimized input and add only the missing field.
On-device AI and provider-hosted AI have different bills
On-device inference wins when the chosen model can handle the narrow task on supported phones and sensitive input should remain on the device; it costs device testing, model packaging, battery and memory checks, and a plan for older hardware. Provider-hosted inference wins when output quality or frequent model updates justify a server call; it costs network reliability work, request filtering, provider review, and a clear answer to where prompts and outputs are retained. Neither option eliminates risk: on-device output may be backed up or shared, while a hosted request may pass through more systems than the product diagram shows.
Custom Mobile Apps with AI for Smarter Business Workflows makes the case for an app, but I would require a device-specific reason before funding one because an existing web workflow may already support the task without adding another place to store data. Camera access, reliable offline work, or a tested need for background capture can justify the app. “The AI feature should feel native” is not a scope criterion because it does not identify a user action the web flow cannot perform.
For hosted inference, put your API between the client and the provider so the mobile or Vue client never holds the provider credential. The API should construct the provider request from approved fields rather than forwarding arbitrary client JSON. Ask the provider whether prompts are used for model training, what retention controls apply to your account and endpoint, where processing occurs, and how deletion requests are handled. Record the answers against the exact service configuration being purchased; a provider’s general privacy page may describe a different endpoint or contract.
Choose a provisional 30-day maximum for operational request metadata, then shorten or extend that working value only after support and legal owners explain what they need. Metadata should identify a request and its outcome without preserving the prompt by default, because storing every prompt creates a second dataset to govern. If a team proposes prompt logging for debugging, ask for a restricted, time-limited sampling process with an owner and a deletion job instead of accepting an indefinite switch in production.
Run a small pilot on the real task before committing to an architecture. Record the measured rate of drafts users substantially edit, the measured rate of retries, and the measured time to complete the task with and without AI. A faster model response does not establish a faster workflow if users must inspect or repair more text. Review failed and rejected outputs as carefully as successful ones, since they reveal what information staff may be tempted to paste into an unrestricted prompt box.
A mobile release adds a second copy of the data unless you prevent it
A phone changes the threat model because data can persist in local databases, notification previews, screenshots, backups, and crash reports after the user has closed the task. Decide which of those surfaces may contain customer text before asking engineers for a mobile estimate. “Encrypted in transit” covers the network connection, not the cached draft or the analytics event created when a screen fails.
If offline editing is required, specify the smallest local record and its expiration behavior. Use iOS Keychain or Android Keystore for suitable secrets, but do not treat either as a general-purpose database for customer documents because the app still needs a storage and deletion design for those documents. Test sign-out, account switching, lost-device response, and reinstall behavior with actual builds; each can expose a stale draft that a happy-path demo misses.
For sign-in, prefer an established OpenID Connect flow using OAuth 2.0 Authorization Code with PKCE rather than inventing a mobile password exchange, because the established flow avoids putting the user’s password into custom app code. Scope token refresh and revocation tests, including what an offline device does after access is removed. App Attest and the Play Integrity API can add evidence about the app or device, but neither replaces authorization checks on the API because a legitimate app can still submit a request for a record its user must not access.
Diagnostics need their own acceptance criteria. Sentry and OpenTelemetry can help identify crashes and slow requests, but review their SDK configuration and every custom event before launch because request bodies and user-entered text can be attached through application code. Assign a reviewer to inspect a captured test error and trace, not merely the dashboard settings. Set a planning target of 2 hours from a reported leak to disabling the affected AI route; treat that as a response drill to tune, not a guarantee that an incident will be resolved in that time.
Release criteria should test data handling, not merely the model demo
Turn the boundary decisions into work items that can fail a release. A useful acceptance test submits a record containing a permitted note and a forbidden customer identifier, then checks the outbound provider request, API logs, client storage, and error telemetry for that identifier. Add a deletion test that follows a saved draft through both server and device. OWASP ASVS can guide API and web verification, while OWASP MASVS gives the mobile team a separate checklist; use the applicable requirements rather than declaring either standard “done” after a scan.
The following Node.js example runs locally as a small test boundary. It accepts only task and selectedText, rejects oversized input, and avoids logging the body. Save it as server.mjs and run it with node server.mjs. Its 8 KiB input ceiling is a starting limit to adjust against actual task data; this is not a production endpoint because it has no authentication or provider integration.
import { createServer } from 'node:http';
const allowed = new Set(['task', 'selectedText']);
createServer(async (req, res) => {
if (req.method !== 'POST' || req.url !== '/ai-input') { res.writeHead(404).end(); return; }
let body = '';
for await (const chunk of req) {
body += chunk;
if (Buffer.byteLength(body) > 8192) { res.writeHead(413).end(); return; }
}
try {
const input = JSON.parse(body);
const payload = Object.fromEntries(Object.entries(input).filter(([key]) => allowed.has(key)));
res.writeHead(200, { 'Content-Type': 'application/json', 'Cache-Control': 'no-store' }).end(JSON.stringify(payload));
} catch { res.writeHead(400).end(); }
}).listen(3000, '127.0.0.1');
The example makes one policy visible, but an allowlist alone is insufficient because selectedText can still contain a secret. In the production design, authenticate the caller, authorize access to the source record, validate field types and lengths, and give users a chance to review selected text before sending it. Put the provider call after those checks. Test rejection paths as well as successful requests so a malformed or unauthorized submission cannot quietly reach the model.
Budget an owner for provider settings, an owner for mobile storage, and an owner for incident response; otherwise each team may assume another has checked the same transfer. Define a release gate around evidence: a captured outbound request containing only approved fields, a device test showing what survives sign-out, and a diagnostic sample with no customer text. Those artifacts let a product manager decide what to defer without relying on a general assurance that the feature is secure.
First, take one proposed AI task and put its real input fields on a single page with their source, destination, and deletion owner. Ask engineering to trace one test record through the browser, API, provider, phone, and diagnostics. If the team cannot account for a field at every stop, remove that field from the launch scope before estimating the build.
