Private AI on Cloudflare · Part 1
Frontier models should be an escalation path, not your AI architecture
The model is one component. The real system is the policy boundary around the workflow: what data may enter, what truth remains deterministic, which model is allowed to see the task, who approves the result, and where the process must stop.
Many AI projects begin with the wrong architectural question: Which frontier model should we use?
That question quietly makes the largest, most general model the center of the system. The workflow, the data boundary, the decision risk, and the operating cost become details added later. By then, the application may already be sending more context than the task requires, depending on one provider, and treating model output as if it were business truth.
workrr takes the opposite approach. Start with the work. Classify the data. Preserve authoritative records in application code. Use the smallest model that can perform the bounded task. Escalate to a frontier model only when the task needs capability that the default path cannot provide—and only through a governed route.
Rebase from model-first to workload-first
A service request, billing exception, document intake, status update, and operating review do not need the same model. They do not carry the same data. They do not justify the same cost or authority.
Before selecting a model, separate the workflow into jobs:
- Deterministic work: permissions, balances, thresholds, schedules, eligibility, required fields, and state transitions belong in code and authoritative systems.
- Narrow inference: classification, extraction, reranking, summarization, and structured drafting can often use workload-fit models.
- High-capability reasoning: ambiguous synthesis or unfamiliar cases may justify a frontier model, but the request should contain only the minimum approved context.
- Consequential decisions: commitments, financial changes, access changes, regulated judgments, and exceptions outside policy retain named human ownership.
This is not a model leaderboard. It is an operating design.
Cloudflare becomes the control plane
A Cloudflare-native implementation can put policy in front of inference rather than burying it inside a prompt.
Request → identity and authorization → data classification → DLP and minimization → workflow policy → workload-fit model → evaluation → approval or stop → recorded outcome
Workers can enforce identity, authorization, request shape, allowed tools, data minimization, and stop conditions before a model call is made. Workers AI provides Cloudflare-hosted inference for supported workloads. AI Gateway provides a consistent route for Workers AI and third-party providers, with controls such as analytics, logging, caching, rate limiting, retries, and fallback. D1, R2, KV, Vectorize, Durable Objects, and Queues are selected deliberately for the state the workflow actually needs rather than used as an accidental transcript archive.
Cloudflare documents that Workers AI customer content is not made available to other Cloudflare customers and is not used to train AI models or improve Cloudflare or third-party services without explicit consent. Storage is a separate architectural choice: customer content may be stored when an application uses services such as R2, KV, Durable Objects, or Vectorize. That distinction matters. Privacy depends on the full data path, not a reassuring sentence about the model.
Use frontier capability as a governed exception
Some tasks will still benefit from OpenAI, Anthropic, Google, or another high-capability provider. AI Gateway supports multiple providers, so the application can route an approved task without rewriting its operating boundary around one vendor.
A sensible escalation policy asks:
- Did the default model fail a defined evaluation?
- Does the task actually require more reasoning capacity?
- Has sensitive or irrelevant context been removed?
- Is the selected provider approved for this data class and purpose?
- Is logging appropriate for this request, and is retention configured intentionally?
- Will a person review the output before any consequential action?
If those answers are not explicit, the request should stop. A fallback chain should not become a quiet data-export chain.
Security and privacy controls are not compliance claims
No model, gateway, or cloud platform makes an organization compliant by itself. Compliance depends on the applicable obligation, the organization's configuration, contracts, policies, access controls, retention, operating practices, and evidence.
A compliance-ready AI implementation should make those controls inspectable:
- Which data classes are allowed in each workflow?
- Which model routes are approved for each class?
- What is redacted, blocked, or minimized before inference?
- When are prompts and responses logged, and for how long?
- Who can approve an action or change a policy?
- Which evaluations must pass before a release?
- How can the workflow be stopped, recovered, and audited?
Cloudflare's AI Gateway DLP can scan prompts and responses for sensitive information and apply shared DLP profiles across supported providers. That is a useful enforcement point, but it is one control in a larger program. Streaming responses also require care: Cloudflare notes that DLP buffers a streamed response before scanning, changing how the user experiences delivery.
What this changes for a real operator
Consider a finance or service exception. Application code retrieves the authoritative status and balance. A narrow model classifies the correspondence and drafts a factual summary. Policy blocks prohibited data and tools. A frontier model is used only if the exception is genuinely ambiguous and the approved route permits it. A named person reviews the proposed response. The system records the source facts, model route, evaluation, approval, and final action.
The organization gets useful AI without making a general-purpose model the owner of the workflow.
How workrr One applies the pattern
workrr One is built around Discover → Shadow → Assist → Bounded Automation. The workflow is mapped before authority is granted. Model output is compared with actual work in shadow mode. Assistance enters a reviewed queue. Automation is narrow, tested, recoverable, and measurable.
The model route is part of that boundary. Cloudflare-hosted inference can be the default where capability fits. A third-party frontier model can remain available for an explicitly approved escalation. Deterministic code preserves financial and operational truth throughout.
The practical starting point
Do not begin by replacing every frontier call. Begin with one repeated workflow and build a route table:
- the task and accountable owner,
- the allowed data classes,
- the authoritative records,
- the default model and evaluation threshold,
- the approved escalation route,
- the human approval and stop conditions, and
- the evidence needed to expand authority.
That is the rebase: away from frontier-first demos and toward customer-controlled, Cloudflare-native operating systems that use each model for the work it has actually earned.
Official Cloudflare references
- Workers AI data usage
- AI Gateway overview
- AI Gateway Data Loss Prevention
- AI Gateway supported providers
Rebase one workflow, not the whole company.
workrr.ai will map the data classes, model routes, source-of-truth rules, approvals, stop conditions, and smallest shadow-mode pilot for one operating workflow.