Data handling

That commitment applies to the weights themselves. It does not change the separate policy for request inputs and generated outputs.

A customer model is imported from a model hub, never uploaded, and it is weight files only: no customer code runs anywhere. The import pins the revision, fetches only the files an engine reads, re-saves what passes its checks, copies it once into encrypted HIPS storage in the workspace's storage region, where its deployments run, and signs it with a HIPS key. Workers and devices load only that signed copy, never the hub. Import and run your model has the whole path.

A hub token for a private or gated repository is read-only, kept encrypted under a cloud key, shown by its last four characters, used only in the import job and never sent to a data-center worker, its RunPod pod or a device; it is deleted when you delete it. Access tokens has the rules.

The Console will show the applicable policy so that teams can understand it before sending work. Retention, deletion, and any other permitted uses will be set out in the service terms before production access. Turning training off is not, by itself, a promise of zero retention.

The policy applies to requests against catalog models and against customer models alike. It is not a header; a request cannot override it. The policy in force at the moment the gateway accepts the request is the one recorded on the job and the usage event, and it travels with the job through every retry.

In the personal pool a job runs on a device that its owner controls physically. The provider app handles weights and inputs in memory and removes them after the job, and the software is signed; but a person with physical control of a machine can in principle read its memory, and HIPS cannot verify from outside that they did not. HIPS discloses this before a customer selects the pool. In the approved pool a job runs on data-center supply operated by an approved provider, with published execution protections and access conditions per provider Not decided yet.

Encryption in transit and at rest is part of the platform requirements. It protects data during transfer and storage, but does not by itself prevent a GPU operator from accessing weights or request data during execution. We will publish the execution protections and access conditions for each pool before customers deploy workloads to it.

Cross-pool fallback is off by default and requires explicit enablement. It never relaxes a region or data-use rule. Customer-owned models run in the approved pool only at launch.

A region is a requirement of a request, available on the higher paid plan only. What a region requirement covers (processing, logs, storage, backups, retries, verification samples, operations access, sub-processors) is open Not decided yet, and it is not offered until specified. The rule that holds regardless: no request silently crosses a required boundary. If no eligible supply exists in the required region, the gateway answers 503 overloaded_error with Retry-After, never a result from elsewhere.