AI privacy is not determined by whether a tool is called AI. It is determined by where data goes, who can access it, how long it is kept, and what secondary uses are allowed. Local processing can keep inference on your device, but it does not automatically make an app private. Cloud services can be secure and contractually constrained, but they require sending data to another party. This guide explains the data flows behind local and cloud AI, gives a decision framework, and shows a practical workflow for evaluating exposure.
This article is for technically curious beginners moving toward implementation: developers, WordPress site owners, automation builders, and local-model users. It is not legal advice. Compliance depends on jurisdiction, data type, contracts, and organizational policy.
What AI privacy actually covers
AI privacy is the set of controls and expectations around data that enters, passes through, or is produced by an AI system. The relevant data is broader than the prompt. It includes the input you provide, the output the model generates, metadata such as timestamps and account identifiers, logs and telemetry from the application or runtime, and any stored copies used for debugging, evaluation, or fine-tuning. In retrieval-augmented generation (RAG), it also includes documents, embeddings, and index metadata. In an agent or automation workflow, it includes tool calls, credentials, and the results of external actions.
A useful way to organize the topic is by three layers: input data, system data, and output data. Input data is what the user or workflow sends. System data is what the software, runtime, and provider collect around the request. Output data is what the model returns and what downstream systems do with it. Privacy failures can happen at any layer. A local model can leak through telemetry. A cloud model can leak through retention or human access. A hybrid system can leak through a silent fallback.
Local processing is not the same as offline
Local processing means inference runs on hardware you control: a laptop, workstation, server, or on-premises cluster. The model weights and computation stay on that device. Microsoft Learn notes that local, on-premises processing can offer security and privacy benefits because data remains on the device, but the responsibility for data security rests on the user, and the developer holds responsibility for managing updates, ensuring compatibility, and monitoring security vulnerabilities [1].
Local processing is not the same as offline operation. A local model can still be online. The application may send telemetry, check for updates, download models, upload crash reports, or fall back to a cloud endpoint when the local model is unavailable. Offline mode is a stronger claim: the task can complete without a network connection. To verify, disconnect the network and run the task. If it fails, something in the workflow depends on a remote service. If it succeeds, inspect network activity and logs to confirm that no data left the device during the test.
Cloud AI is a data transfer relationship
Cloud AI sends inputs to provider infrastructure. Depending on the provider, account tier, and contract, the provider may process the data, store it temporarily or persistently, log it, allow human review for safety or support, or use it to improve models. Microsoft Learn explains that cloud providers offer robust security measures, but data needs to be transferred to the cloud, which might raise data privacy concerns for the business or app service maintainer. Sending data to the cloud must also comply with data protection regulations such as GDPR or HIPAA, depending on the nature of the data and the region in which the app operates [1].
Cloud privacy is therefore a contract and configuration problem as much as a technical one. The same provider can offer different data controls across consumer, business, and enterprise plans. A promise not to train on customer data is not the same as no human access, no retention, or no legal compulsion. The next section gives a framework for separating those claims.
Data exposure is a spectrum, not a switch
DeepLearning.AI offers a practical framework for evaluating cloud AI privacy, from less to more private: No Guarantees, No Outside Exposure, Limited Access, and No Access [2]. The levels are useful because they force specificity.
- No Guarantees: The company provides no guarantees that your data will be kept private. It might train on your data and use the resulting models in ways that leak it [2].
- No Outside Exposure: The company does not expose your data to outsiders. It can meet this standard by not training on your data and by not posting your data online [2].
- Limited Access: In addition to safeguards against data leakage, no humans, including employees, contractors, and vendors, will look at your data unless they are compelled through a reasonable process such as a subpoena or court order, or if the data is flagged by a safety filter [2].
- No Access: The company cannot access your data no matter what. For example, data may be stored on the customer premises, so the company does not have access to it. Running an LLM on a private laptop is an example where no company can access prompts or output [2].
These levels are not a legal certification. They are a design target. A workflow can aim for No Access for regulated data, Limited Access for internal data, and No Outside Exposure for public data. The target should drive architecture, vendor selection, and testing.
A mental model: follow the data lifecycle
Privacy decisions become clearer when you follow data through a lifecycle: collection, transport, processing, storage, retention, secondary use, and deletion. At each stage, ask what data is present, where it is, who controls it, and what could go wrong.
Consider a WordPress AI drafting workflow. An editor types a prompt that includes an unpublished post title, an outline, and a customer name. If the plugin calls a cloud API, the data leaves the WordPress server. If the plugin calls a local model on the same server or a local network GPU, the inference data may stay inside your infrastructure. But the plugin might still log the full prompt, send analytics, or fall back to a cloud endpoint when the local model is busy. The privacy outcome depends on configuration, not on the label local or cloud.
A threat model helps prioritize. Who are you protecting against? Accidental leakage through logs, provider training, employee access, legal compulsion, a breach, or inference attacks? Different threats need different controls. Data minimization helps with almost all of them. If the data never enters the system, it cannot be exposed by that system.
Main approaches: local, cloud, and hybrid
There is no universal winner. Microsoft Learn notes that many production apps use a hybrid strategy: try a local Windows AI API or local model first, then fall back to a cloud endpoint when the model is not installed, the device is not supported, the user does not consent to a model download, or the task requires a larger model [1]. That pattern is useful, but it must be policy-gated. A silent fallback can turn a private local workflow into a cloud data transfer.
Local-only and on-premises
Local-only processing keeps inference inside hardware you control. The main privacy benefit is that data can remain on the device or inside your network. Other benefits can include lower latency, offline availability, predictable per-request cost after hardware is purchased, and more control over model choice. Microsoft Learn lists data privacy, compliance, and security as key decision factors, and notes that local, on-premises processing can offer benefits because data remains on the device [1].
The costs are real. Local processing depends on resource availability. Model size and complexity matter. The developer or operator holds responsibility for updates, compatibility, and monitoring security vulnerabilities [1]. A local deployment can be less capable than a large cloud model for complex reasoning, long context, or multimodal tasks. Maintenance is ongoing: runtime updates, model licenses, security patches, and hardware monitoring.
Memory planning is a common source of failure. Model weight size alone is not total memory use. You must account for the KV cache, which grows with context length, and runtime overhead. Quantization can reduce weight memory, but it can affect output quality. If a model crashes or swaps, the fix is usually a smaller model, a shorter context, a more aggressive quantization, or more RAM or VRAM. Check the runtime documentation for the specific model and version.
Cloud-only
Cloud-only processing sends requests to a provider. Benefits can include access to larger models, scalability, managed security updates, easier collaboration, and less dependence on local hardware. Microsoft Learn lists scalability, accessibility and collaboration, maintenance and updates, and model size and complexity as factors that can favor cloud [1].
The privacy cost is the data transfer relationship. Data leaves your control and enters a provider environment. The provider may have strong security, but the data is still transferred, and the business or app maintainer must consider privacy concerns and regulations such as GDPR or HIPAA [1]. Cloud-only is often a good fit for public data, non-sensitive tasks, burst capacity, and workflows where local hardware is unavailable. It is a poor default for regulated data unless the contract and configuration support the required privacy level.
Hybrid and routing
Hybrid processing combines local and cloud. The typical pattern is local first, cloud fallback. Microsoft Learn describes that pattern and the conditions that can trigger a fallback: the model is not installed, the device is not supported, the user does not consent to a model download, or the task requires a larger model [1].
For privacy, the routing rule is more important than the fallback itself. Sensitive data should not fall back to cloud without an explicit policy decision. A better design classifies data before inference. Sensitive requests go local. If local is unavailable, the request is blocked or queued for human review. Non-sensitive requests can use local or cloud. Unknown classification is treated as sensitive until reviewed. This prevents a temporary local failure from becoming a data leak.
| Dimension | Local or on-premises | Cloud | Hybrid |
|---|---|---|---|
| Data location | On device or inside your network | On provider infrastructure | Depends on routing decision |
| Provider access | None, unless the app sends data out | Governed by provider terms and controls | Only for cloud-routed requests |
| Hardware | You provide RAM, VRAM, storage, power | Provider manages hardware | Local hardware plus cloud capacity |
| Model capability | Limited by local resources | Can use larger, more complex models | Task-dependent routing |
| Updates and security | You manage updates and vulnerabilities | Provider handles many updates | Both sides need management |
| Cost pattern | Upfront hardware and operations | Usage-based or subscription | Mixed |
| Connectivity | Can be offline if configured | Requires network access | Local offline plus cloud when allowed |
| Compliance complexity | You control data location and retention | Requires contract, region, and data controls | Requires policy enforcement and audit |
| Best fit | Sensitive data, offline, latency, control | Public data, scale, larger models | Mixed workloads with clear rules |
The table is a decision aid, not a ranking. The right choice depends on the data, the task, the contract, and the operating capacity.
How to choose: a decision framework
Use a short sequence to avoid deciding by label alone.
- Classify the data. Public, internal, personal, or regulated. Include metadata and logs, not just the prompt.
- Set the target privacy level. Use the DeepLearning.AI levels: No Guarantees, No Outside Exposure, Limited Access, or No Access [2]. Write down what the level means for your workflow.
- Map the data flow. List every component: client, plugin, server, runtime, model, API, log store, analytics, backup, and third-party service.
- Evaluate local, cloud, and hybrid options. Check resource availability, model capability, maintenance, cost, connectivity, and compliance [1].
- Define fallback rules. Decide what happens when the preferred option is unavailable. For sensitive data, block or queue rather than silently falling back.
- Test and document. Run offline tests, inspect logs, and record the environment and result. Revisit when models, runtimes, or provider terms change.
Useful questions include: Does the task require a larger model? Is offline operation required? Is the data regulated? Can the data be redacted or minimized? What is the provider retention period? Is there a data processing agreement? Can training on your data be disabled? Who reviews the output? What happens if the local model fails?
Practical path: from inventory to verified workflow
This is a suggested path, not a tested environment. Adapt it to your stack and document what you actually run.
Step 1: Inventory one AI workflow
Pick one workflow, not your entire organization. List inputs, outputs, logs, telemetry, and third-party calls. For a WordPress drafting workflow, inputs might include the prompt, title, outline, and any customer names. Outputs include the draft. Logs may exist in the plugin, web server, database, and cloud provider. Telemetry may come from the plugin, the model runtime, or the hosting platform. Third-party calls may include a cloud model API, an embedding service, or a moderation service. Write the flow down before changing anything.
Step 2: Define the privacy target
Use the DeepLearning.AI levels to set a target [2]. For regulated data, No Access or Limited Access may be required. For public marketing copy, No Outside Exposure may be enough. Document the target in plain language: for example, unpublished customer stories must not leave our server, and no full prompt may be stored in logs.
Step 3: Choose architecture and fallback rules
Choose local for sensitive data. Choose cloud for public or non-sensitive data when larger models are needed. Choose hybrid when both are useful. Write the fallback rule before implementation. A simple rule: if data is sensitive and local is unavailable, block or queue. If data is non-sensitive and local is unavailable, use cloud with redaction. If classification is unknown, treat it as sensitive.
Step 4: Configure local processing
Prerequisites include hardware with enough RAM or VRAM, a compatible runtime, and a model that fits the task. Choose a quantized model if memory is tight, but test output quality. Plan for model weights, KV cache, and runtime overhead. Reduce context length if memory is exhausted. Disable telemetry where the runtime allows it. If the application supports offline mode, enable it.
Verification: disconnect the network, run a representative prompt, and confirm the result. Then inspect network activity with a firewall, packet capture, or operating system network monitor. Check application and runtime logs for prompt content. If the workflow requires a network connection, it is not offline. If it sends data during local inference, find the source: update check, analytics, crash reporting, model download, or cloud fallback.
Step 5: Configure cloud usage
Use an account tier and endpoint that match your privacy target. Look for data processing terms, training controls, retention controls, and region selection. If zero-retention or no-training options exist, verify them in the contract and configuration, not only in marketing text. Redact or minimize data before sending. Use scoped API keys and restrict who can view provider logs. Turn off verbose application logging that captures full prompts.
Verification: send a canary value in a test request and search your logs and provider-accessible logs for it. Check retention settings and deletion behavior. Training verification is harder; rely on contractual terms and provider documentation, and avoid sending data you cannot legally or ethically risk.
Step 6: Implement hybrid routing
The following pseudocode is illustrative. It shows a policy gate rather than a production implementation.
function route(request):
data_class = classify(request.data)
if data_class == 'sensitive':
if local_model_available():
return local_model.generate(request)
else:
return block_or_queue(request, reason='local_required')
if data_class == 'public':
if local_model_available():
return local_model.generate(request)
else:
return cloud_model.generate(redact(request))
return block_or_queue(request, reason='unknown_class')Add human review before publishing or acting on output. Log the routing decision, model identifier, timestamp, and token count, but not sensitive content. If the local model fails, the queue should alert an operator rather than silently switching to cloud for sensitive data.
Step 7: Evaluate and verify
Run a small test set that covers each route: sensitive local, sensitive local unavailable, public local, public cloud, and unknown classification. For each test, record the environment, model, runtime version, and result. Check for unexpected outbound connections, sensitive data in logs, retention behavior, fallback correctness, and user consent records. A successful evaluation shows that the workflow behaves according to policy, not just that it produces good text.
Worked example: privacy-preserving AI drafting in WordPress
This is an illustrative workflow, not a tested deployment. The goal is to use AI to draft posts without leaking unpublished content or customer data.
Architecture. A WordPress site runs on a virtual private server. A local model runtime runs on the same server or on a local network GPU. A custom plugin or automation script sends prompts to the local endpoint. If the local endpoint is unavailable, the job is queued for an editor. No cloud fallback is allowed for sensitive drafts. For public marketing copy, a cloud API is allowed with redaction.
Inputs. Title, outline, tone, and public facts. Excluded inputs include customer names, email addresses, unpublished financials, and private support tickets.
Process. Classify fields. Redact sensitive values. Route to local or cloud based on policy. Generate the draft. Send the draft to human review. Publish only after approval.
Outputs. A draft saved as pending in WordPress. The output is not published automatically.
Logs. Store routing decision, model identifier, timestamp, and token count. Do not store full prompts for sensitive requests. If debugging requires more detail, use a short-lived, access-controlled debug mode with redaction.
Evaluation. Disconnect the network and run a sensitive draft. Confirm it is queued, not sent to cloud. Send a canary marker in a public draft and check that it appears only where policy allows. Review logs for sensitive strings. Confirm that human review is required before publishing.
Recovery. If the local model fails, the queue grows. Alert an operator. Do not automatically downgrade sensitive data to cloud. If the queue is too large, add hardware, reduce model size, or schedule non-urgent work.
This example connects the main concepts: local processing keeps sensitive inference inside your infrastructure, cloud services are reserved for allowed data, and data exposure is controlled through classification, routing, logging, and human review.
Troubleshooting common privacy failures
Use a symptom, cause, diagnostic, action, and verification pattern. The causes below are plausible, not confirmed for every stack.
Local model still sends data
Symptom: Network activity during local inference.
Plausible causes: Telemetry, update checks, cloud fallback, analytics, crash reporting, or model download.
Diagnostic: Run an offline test, monitor network connections, and inspect runtime and application settings.
Action: Disable telemetry, block unnecessary endpoints, enable offline mode, and remove silent cloud fallback for sensitive data.
Verification: Repeat the offline test and confirm no outbound connections carry prompt data.
Cloud provider trains on data
Symptom: Terms or settings allow training on your inputs, or you are unsure.
Plausible causes: Consumer tier, default settings, or no data processing agreement.
Diagnostic: Review the provider terms, account tier, data controls, and contract.
Action: Use no-training or zero-retention options if available, sign appropriate terms, redact data, or move the workflow local.
Verification: Confirm the setting and contract, not just a help page. If you cannot verify, do not send data that requires the higher privacy level.
Local model runs out of memory
Symptom: Crash, swap, or severe slowdown.
Plausible causes: Model too large, context too long, KV cache growth, or runtime overhead.
Diagnostic: Monitor RAM and VRAM, check model size, context length, and runtime requirements.
Action: Use a smaller or more quantized model, reduce context, or add memory.
Verification: Repeat the task with monitoring and confirm stable memory use.
Sensitive data appears in logs
Symptom: Prompt text or personal data in debug logs, error traces, or analytics.
Plausible causes: Verbose logging, default application logging, or third-party monitoring.
Diagnostic: Search logs for a canary value and review logging configuration.
Action: Disable verbose logging, redact before logging, restrict log access, and rotate exposed logs.
Verification: Repeat the canary test and confirm the value does not appear in logs.
Compliance uncertainty
Symptom: Unclear whether GDPR, HIPAA, or another regime applies.
Plausible causes: Data type, region, contract, or organizational policy.
Diagnostic: Map data flows and consult legal or compliance expertise.
Action: Use a data protection impact assessment, data processing agreement, and data residency controls where appropriate.
Verification: Obtain documented legal sign-off. This article is not legal advice.
Evaluation, limitations, and responsible operation
Privacy is not binary. Local processing does not guarantee privacy, because applications can still transmit telemetry, logs, or fallback requests. Cloud processing can be private under the right contract and controls, but it always involves a data transfer relationship. Hybrid processing adds flexibility and complexity, and its privacy depends on policy enforcement.
Material limitations include local hardware capacity, model quality, maintenance burden, and security vulnerabilities that the operator must monitor [1]. Cloud limitations include data transfer, provider access, jurisdiction, retention, and cost [1]. No architecture eliminates all risk. Human error, misconfiguration, and third-party dependencies remain.
Responsible operation means data minimization, purpose limitation, consent where required, transparency, access control, encryption, retention limits, deletion, audit, and incident response. It also means not equating open weights, open source, and permission for commercial use. A model can have open weights and still carry license restrictions or security concerns. Verify the applicable license and the model card before deployment.
Learning path and next action
Immediate next step: pick one AI workflow and draw its data flow. Run an offline test. Decide the target privacy level using the DeepLearning.AI levels [2]. Then make one concrete change: disable telemetry, add redaction, or block cloud fallback for sensitive data. Document the environment and the result.
A practical progression:
- Beginner: Run a local model offline for a non-sensitive task. Learn where prompts, logs, and telemetry go.
- Intermediate: Add hybrid routing with policy gates. Log decisions without storing sensitive content. Test fallback behavior.
- Advanced: Deploy on-premises or private infrastructure, add local RAG, build audit trails, and run a data protection impact assessment.
Supporting topics that deepen this pillar include running a local LLM offline and verifying no network calls, reviewing cloud AI data retention settings, building a privacy-preserving WordPress AI drafting workflow, designing hybrid AI routing without leaking sensitive data, and applying redaction and data minimization to AI prompts. If you are working through a similar setup, share your goal, environment, attempted steps, and results in the community so others can compare configurations and failure modes.
FAQ
Is local AI always private?
No. Local inference can keep model computation on your hardware, but the application can still send telemetry, logs, crash reports, update checks, or fallback requests to a cloud service. Offline operation and network monitoring are needed to verify that data stays local.
Can cloud AI be private?
Cloud AI can meet higher privacy levels when the provider contract, account tier, and configuration limit training, retention, and human access. DeepLearning.AI's framework distinguishes No Guarantees, No Outside Exposure, Limited Access, and No Access, and the same provider may offer different levels across plans.
What data does an AI service collect?
It can include prompts, outputs, metadata such as timestamps and account identifiers, logs, telemetry, and stored copies used for debugging, evaluation, or training. In RAG or agent workflows, it can also include documents, embeddings, tool calls, and credentials.
How do I verify that a local model is not sending data?
Disconnect the network and run a representative task. If it succeeds, inspect network activity with a firewall or packet capture and search logs for prompt content. If it fails, identify the remote dependency, such as telemetry, update checks, model downloads, or cloud fallback.
Is an open-weight model automatically safe to use?
No. Open weights, open source, and permission for commercial use are different concepts. Check the model license, model card, security considerations, and maintenance status before deployment.
What is zero-retention in cloud AI?
Zero-retention is a provider setting or contract term intended to avoid storing prompts or outputs beyond processing. The exact meaning varies, so verify the provider documentation and contract rather than relying on a marketing page.
Does GDPR or HIPAA apply to my AI workflow?
It depends on the data, the region, the role of each party, and the contract. Microsoft Learn notes that sending data to the cloud must comply with regulations such as GDPR or HIPAA depending on the data and region. Consult legal or compliance expertise for your situation.