Feature × Audience

How does government route model requests with Plugsky?

Government teams route with Plugsky inside a defined security boundary: model="plugsky-fusion" applies strategies per workspace or key, sensitive or repeatable flows pin a fixed model to bypass routing, and every decision is logged. The same routing layer runs in region-pinned cloud, on-prem and air-gapped deployments, so optimisation never requires data to leave the environment.

Key facts

Router modelmodel="plugsky-fusion" routes inside your deployment (live)
DeterminismExplicit model names bypass routing for sensitive, repeatable flows
Strategiescost_saver, balanced, max_quality and custom, scoped per workspace or key
DeploymentRegion-pinned cloud, VPC, on-prem Helm and fully air-gapped bundles
Decision logModel, strategy and rule logged per request; exportable to SIEM
PII handlingNo-PII, detect-only and passthrough modes for prompt content
ResidencyData never leaves the pinned region; sa-central-1 available on Enterprise
RoadmapClassifier routing /v1/plugsky/route (model=auto) is coming soon

TL;DR

  • Route within the boundary: cloud-pinned, VPC, on-prem or air-gapped.
  • Keep deterministic overrides for anything a citizen could challenge.
  • Use cheap-first strategies for public information services.
  • Log every routing decision and export the trail to your SIEM.
  • Document evaluation results before expanding a pilot.

How it works, step by step

  1. Define the security boundary and pick a deployment topology per service.
  2. Classify workloads by sensitivity and assign an allowed strategy to each.
  3. Pin fixed models where policy, reproducibility or oversight demands determinism.
  4. Configure PII handling before any citizen data reaches a prompt.
  5. Export routing, key and admin events to your SIEM with named reviewers.
  6. Pilot on an internal service, document results, then extend to public-facing workflows.
1Define the securityboundary and pick adeployment topology2Classify workloadsby sensitivity andassign an allowed3Pin fixed modelswhere policy,reproducibility or4Configure PIIhandling before anycitizen data5Export routing, keyand admin events toyour SIEM with6Pilot on aninternal service,document results,

Try it yourself

Open the AI workload router simulator →

Routing inside the security boundary

Routing must not become a covert egress path. In Plugsky, the router runs inside the API gateway of your deployment, so an air-gapped installation routes among locally served models with no outbound calls, and a region-pinned cloud deployment never sends data outside the pinned region.

That lets agencies treat model selection as an internal optimisation. Public-facing FAQ services can run on cost_saver; internal case analysis can run balanced; high-assurance outputs can take max_quality — all without reopening the security review that approved the environment.

Determinism and oversight

Administrative decisions must be reproducible. Where an output may be appealed or audited, pin the model explicitly: an explicit model name bypasses routing, so the same input follows the same path every time. Where routing is allowed, the decision log retains the model, strategy and rule for every request, giving oversight a readable chain.

  • Export: routing and inference events stream to Splunk, Sentinel, QRadar or Chronicle.
  • Key control: BYOK and HSM integrations keep encryption keys in your control.
  • PII: no-PII mode auto-redacts; detect-only tags; passthrough leaves controls with you.

Evidence for procurement and pilots

Sovereign procurement rewards documented behaviour. Plugsky publishes its regions, retention posture, audit logging and deployment topologies, and enterprise agreements include a DPA with options for in-region routing. A pilot should produce the same paperwork: a defined case set, agreed success measures and a review of the decision log.

The commercial argument is straightforward too. Flat self-serve plans carry no per-token charges, so routing more traffic does not create unpredictable spend, and enterprise pricing is scoped to deployment, security and volume. See the live pricing page for current options.

Honest comparison

ConcernPlugsky routingPublic cloud AI APIsAgency-built router
BoundaryRuns inside your deploymentVendor-managedOwn data centre
DeterminismExplicit model names bypass routingLimitedCustom logic
Decision evidenceModel, strategy and rule loggedVendor logsOwn implementation
PII controlsNo-PII, detect-only, passthroughVariesYou build it
Time to pilotWeeksWeeks to monthsQuarters

Frequently asked questions

Does routing work in an air-gapped deployment?

Yes. The router operates inside the environment and selects among locally served models with no outbound network calls.

Can we prevent automatic model selection for certain work?

Yes. Pin an explicit model name to bypass routing on any request or endpoint.

How is routing audited?

Every request logs the chosen model, strategy and matching rule, and events can be exported to your SIEM with your own retention.

Could routing route data outside our jurisdiction?

No. Data never leaves the pinned region, and air-gapped deployments have no external connectivity.

Who decides which strategies agencies may use?

Policy does. Strategies are scoped per workspace or key, so governance sets the allowed profiles and teams consume them.

Is citizen data used for training?

No. Prompts and completions are not used to train models, and request bodies are not retained.

How should a pilot be structured?

One internal service, a fixed evaluation set, agreed measures and a routing-log review before any expansion.