Data processing and subprocessors

1. Roles

Ruhu is a conversational AI runtime. Customers author agents that hold conversations with their own end users across web chat, WhatsApp, SMS, voice and telephony channels.

For that conversation content, the customer is the data controller and Ruhu is the data processor. Ruhu processes it only to provide the Service and on the customer's documented instructions.

The signed Data Processing Agreement that governs a customer contract is available on request from privacy@ruhu.ai. This page summarises how the managed Service processes personal data today.

2. What Ruhu processes

When providing the managed Service, Ruhu processes:

• conversation content between a customer's agent and that customer's end users;
• configuration authored by customer staff, such as agent documents, tools and knowledge;
• customer staff identity data, for authentication and authorisation; and
• credentials the customer supplies to connect their own systems.

3. Our commitments as a processor

As a processor, Ruhu will:

• process personal data only on the customer's documented instructions;
• keep it confidential and limit access to staff who need it to provide the Service;
• maintain the technical and organisational measures described in section 6;
• engage subprocessors only under written terms at least as protective as our agreement with the customer, and give at least 30 days' notice before engaging a new one;
• help the customer respond to data subject requests and data protection assessments;
• notify the customer without undue delay after becoming aware of a personal data breach affecting their data; and
• delete or return personal data at the end of the Service, as the customer chooses.

4. Where data is processed

Default region. The managed Service is hosted on Google Cloud in London (europe-west2). Model inference regions are recorded per model and constrained by configuration; certain AI inference may use a global endpoint.

Licensed deployments. Ruhu can also be deployed inside the customer's own infrastructure. There the customer controls hosting, data residency, key management and the network boundary, and the isolation, authorisation and audit controls in section 6 still apply.

International transfers. Where personal data moves across borders, for example to a subprocessor in the United States, we rely on recognised transfer mechanisms such as standard contractual clauses, with supplementary safeguards where needed.

5. Subprocessor register

A subprocessor is a third party that processes customer personal data on Ruhu's behalf when Ruhu provides the managed Service as a data processor. Optional providers apply only when the customer enables the corresponding channel.

Core subprocessors

Optional channel subprocessors

Some listed providers may act as independent controllers for limited account, security, fraud-prevention or telecommunications-compliance data. They are listed because they also process customer personal data on Ruhu's behalf for the purpose shown.

Stripe provides payment and subscription billing for Ruhu and, under its own Data Processing Agreement, may act as both a processor and an independent controller. Stripe does not process customer conversation content and is therefore not a subprocessor for the managed Service.

Integrations and identity providers that the customer selects and contracts directly are not Ruhu subprocessors.

Register last updated September 29, 2026.

6. Technical and organisational measures

The controls below are implemented in the product today. What we have not yet delivered is stated in section 8, not here.

• Tenant isolation. Every organisation-scoped database table carries a row-level security policy, enforced for the table owner as well as ordinary roles. A session without a resolved tenant sees no tenant-scoped rows, and a deployment fails at startup if a tenant table lacks a policy.
• Identity and access. OpenID Connect single sign-on to the customer's identity provider, with enforced SSO, just-in-time provisioning and group-based roles. Multi-factor authentication is governed by the customer's identity provider. Every API route declares a required permission, verified at startup.
• Encryption. All external traffic uses TLS. Customer-supplied integration credentials are encrypted with authenticated encryption before storage, with key rotation. Plaintext credentials are never written to logs, traces, metrics or audit payloads.
• Agent action safety. The model proposes actions; a policy outside the model decides whether they execute. High-impact actions require explicit confirmation and policy approval, and model output, retrieved documents and tool results are never authorisation inputs.
• Audit log. An append-only, hash-chained log of authentication, configuration changes, privileged operations and agent actions, exportable as CSV or NDJSON to the customer's SIEM.
• Telemetry. Conversation content is not written into general-purpose telemetry. Sensitive content is held in a restricted evidence store with separate access and retention controls.
• Change control. All changes go through version control and continuous integration, including the full test suite and dependency vulnerability scanning.

7. Deletion and data subject requests

Data-subject deletion is orchestrated across every store that can hold the subject's data: conversations, traces, real-time events, attachments, evaluation records, knowledge chunks and embeddings, summaries, analytics derivatives and caches. A request is reported complete only when every registered store confirms no remaining records.

Stores under legal hold are reported explicitly rather than silently skipped, and backup expiry is disclosed rather than backups being edited in place. Continuous integration fails if a new store holding subject data is added without a registered deletion adapter.

Customers can raise deletion and export requests for their end users through the Service or by contacting privacy@ruhu.ai.

8. Audits and certification status

We do not represent uncertified controls as certified. As of this page's last update, SOC 2 (Type I and Type II), ISO 27001 and ISO 42001 have not yet been obtained, and an independent penetration test has not yet been commissioned. Customers who need a current attestation should discuss timing with us before contracting.

We make information about our security controls available on request, share any audit reports we hold, and will cooperate with reasonable audits required by law or by our agreement with the customer.

9. Changes and contact

Ruhu will give customers at least 30 days' notice before engaging a new subprocessor, subject to the applicable Data Processing Agreement. Material changes to this page are dated above.

Privacy and data processing

privacy@ruhu.ai

Security and vulnerability reports

security@ruhu.ai