Data Residency & AI Infrastructure

Yes, Voltade stores personal data on behalf of its customers: typically business contact records (names, phone numbers, email addresses), conversation and message history, and the operational data customers connect to the platform. Voltade acts as a data intermediary (processor); the customer remains the data controller.

Voltade's agents use frontier large language models accessed via API through a central model gateway, which enforces provider allow-lists, logging, and per-tenant controls. We do not train, fine-tune, or host our own foundation models, and customer data is never used to train any AI model: inputs are processed ephemerally (retrieval-augmented generation) and are not retained by model providers for training.

The specific model versions in use evolve with the frontier; the providers, controls, and no-training guarantees above are contractual and stable. Per-engagement model details are available on request.

• Encryption: AES-256 at rest and TLS 1.3 in transit for all customer data, including backups
• Tenant isolation: per-tenant data isolation enforced with database row-level security across the multi-tenant platform
• Data minimisation towards AI providers: only the minimum context required for a given task is sent to a model; credentials and secrets are never included in model context
• Access control: least-privilege, role-based access with MFA on privileged accounts; customer data access by Voltade staff is need-based and logged
• Monitoring: audit logging, alerting, and observability across production (see Security Principles)
• Assessments: CASA Tier 2 penetration tested (9.7/10), CSA Cyber Essentials certified, DPIAs for new personal-data processing

Beyond encryption and isolation, dedicated privacy-enhancing technologies (e.g. homomorphic encryption, differential privacy) are not currently deployed; data minimisation, contractual no-training terms, and ephemeral processing are the operative safeguards for AI workloads.

Every third party involved in delivering Voltade's services is published in our sub-processor register: Hetzner Cloud (Voltade compute, Singapore sin-dc1), AWS (Volty database, backups and transactional email, Singapore ap-southeast-1), Cloudflare (edge network), Microsoft Azure (internal container registry and Entra ID sign-in only, holding no customer data), Anthropic, OpenAI and Google (AI models via API), SigNoz/Sentry (observability), and Windmill (self-hosted automation). Each is bound by a written agreement with data protection obligations equivalent to those we owe our customers, per our Personal Data Protection Policy. No customer engagement is subcontracted to any other party without the customer's knowledge and agreement.

Inside the product, the AI agent operates on customer records under a set of standing constraints. These are properties of the system rather than settings that have to be switched on.

• Tenant isolation: Every customer record lives in an organisation-scoped table protected by row-level security, and the isolation is pinned by tests. A contact scoped to a single inbox cannot be attached to organisation-wide records.
• Gated actions: Every action the agent can take carries a risk and impact tier. Reads are low-risk, ordinary writes apply inline, and destructive or closing actions require human approval before they take effect. Custom fields are not exempt: there is no path that skips the checks because a field is customer-defined.
• Audited justifications: High-impact actions require a stated justification, recorded as an audit event, so every sensitive action carries both a reason and an actor.
• Compliance-floor fields: A contact or company field can be marked compliance-floor, covering identity documents, national ID numbers, and anything else that must never be handled casually. A compliance-floor field can never be written automatically without review, and an automated process can raise the flag on a field but never lower it.
• Stated contact details are claims, not identity: When someone states an email address or phone number in conversation, it is recorded as unverified and non-primary, with a record of where it came from. An unverified detail never becomes the primary contact method, never receives outbound messages, never resolves incoming messages, and never authenticates anything, so a mistyped or maliciously supplied address cannot capture another person's future conversations. It is promoted only by proof of ownership: a message arriving from that address, or a staff member confirming it.
• Two-tier deletion: Deleted material is soft-deleted first, with an undo window, then permanently purged by a nightly job 30 days later. Entirely removed is true at 30 days.
• Per-organisation provider keys: Model provider credentials are scoped per organisation, so one customer's model traffic is never keyed as another's.