Understand how your models and data will be used
A model’s weights, the inputs sent to it, and the outputs it generates are different things. The HIPS platform is being designed to make those distinctions visible before you choose a plan or execution pool.
We are inviting early-access interest while we develop the platform.
Set out in the legal texts in force from
Your model weights
Customer-owned model weights will never be used to train other models on any plan.
That commitment applies to the weights themselves. It does not change the separate policy for request inputs and generated outputs.
Your model will come to HIPS from a model hub as weight files only. HIPS will run those files on its own inference engines: no executable code from your model’s repository (scripts, libraries or custom operators) will run anywhere in the network, a language model’s chat template will be read as data and rendered only inside the inference engine’s sandbox, and files that would need code to load will be refused when the model is imported.
Request inputs and generated outputs
On Free/PAYG and the lower paid plan, request inputs and generated outputs may be used for training. This includes requests processed by customer-owned models.
On the higher paid plan, request-data training is off by default. 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.
When you submit a batch job, HIPS will keep its input file, and the output and error files it produces, for 30 days, or for less if you set a shorter expiry or delete them sooner. Their content will follow the same request-data policy as requests sent one at a time. Prompt caches will be kept apart for each workspace, and personal GPUs will not keep one at launch.
Where computation happens
HIPS will centrally coordinate inference across independently supplied GPUs. For customer-owned models, customers will select between personal GPUs and an approved-provider pool.
The choices must disclose the relevant model-access conditions as well as price and availability. Cross-pool fallback will be off by default and require explicit enablement. It must not override region or data-use rules.
Customer models will run in the approved-provider pool first. Personal GPUs will follow later, only for supported ONNX models and only for deployments you opt in. If you opt in, the device owner’s machine will hold your model’s weights while it serves your requests.
Encryption and runtime access
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.
Organization controls
The higher paid plan is intended to include region selection and single sign-on. The scope of region controls, including how they apply to processing and related data, will be specified before that feature is offered.
Early-access information
The contact details you submit to join early access are enrollment information, not inference request data. They require a separate privacy notice explaining how we use them for access updates and how you can withdraw.