The short version

This website collects very little. The part that matters is the other one: by default Runvo hosts the workspace it builds for a customer, which makes Runvo a processor of that customer’s data rather than a bystander to it. What that means in practice, and who else is involved, is set out below.

What this website collects

Messages you send us by email, and whatever you choose to put in them.
Standard server request logs, retained for a short period for security and diagnostics.
Aggregate, non-identifying usage statistics, where these are enabled.

We do not sell personal data, and we do not share it for advertising.

Why we hold it

To reply to you, to run a recruitment process where you have applied for a role, and to keep the site secure and working. Where the law requires a basis, that basis is our legitimate interest in operating the business, or the steps needed to enter into a contract at your request.

How long

Correspondence is kept for as long as it is useful to the relationship and then deleted. Recruitment material is kept for the duration of the process unless you ask us to keep it on file. Request logs are short-lived.

None of that covers data inside a customer deployment. Retention there is configured with the customer and stated in their agreement, because it is their retention policy and not ours.

Customer data in engagements

This is the part that usually matters. By default Runvo hosts the deployment. The workspace runs on single-tenant infrastructure in the region the customer names, the United Kingdom by default: the customer’s own instance, own database, own storage and own keys, shared with no other customer. Prompts, responses, uploaded material and the records behind them sit in that deployment.

Runvo operates it, so Runvo processes that data on the customer’s instructions. The customer is the controller and Runvo is the processor. What Runvo may do with the data, which people at Runvo may reach it, and how long each kind of record is kept are fixed by the engagement agreement and its data processing terms. Those are the binding statement; this page is a description of them.

Two kinds of sub-processor sit underneath a hosted deployment. The cloud provider holds the infrastructure it runs on. The provider of whichever model a request is sent to receives that request. Both are named, for that deployment, in the agreement, and the models in use are disclosed to the customer. Runvo does not train models and does not use customer content to do so; what a model provider may do with a request is governed by the terms Runvo holds with it, which the agreement identifies.

Where a customer’s own client contracts require it, the deployment can instead run inside that customer’s cloud tenancy. Then the customer holds the infrastructure and Runvo’s access to it is whatever the customer grants; the model provider is still a sub-processor. That option is priced separately and takes longer.

Where operating a deployment requires access to a customer’s own systems, that access is governed by the engagement agreement, scoped to what the work requires, and logged.

Processors

We use a small number of service providers for running Runvo itself: email, this website, document storage and recruitment. They are bound by contract to handle data only on our instructions.

The providers behind a customer deployment are a separate list. It is named in that customer’s agreement and kept current there rather than here, and the customer is told before anything on it changes.

Your rights

Depending on where you are, you may have the right to ask for a copy of the personal data we hold about you, to have it corrected or deleted, or to object to how we use it. Ask, and we will action it.

If you are in the UK or the EU and think we have got something wrong, you can also complain to your data protection authority. In the UK, the Information Commissioner’s Office.

Contact

Privacy questions and data requests: privacy@runvo.ai.

Privacy.