Trust Center
How Velzyx handles operator data, security, and compliance.
The Trust Center is the consolidated reference for the institutional posture behind every Velzyx deployment: what data is touched, how it is stored, how it is protected, how compliance obligations are met, what is in place today, and what is on the roadmap. It is written in plain language and is meant to be read end-to-end by an operator, a counsel, or an evaluator running formal diligence.
01 — Trust posture
Production-first. Operator-owned. Honest about the trajectory.
Velzyx runs AI systems that handle real conversations and real workloads for real operators. A system that takes a patient phone call, that schedules a dental hygiene visit, or that underwrites a commercial real estate deal is a piece of operational infrastructure. The trust posture has to match that reality. The page below is meant to be the kind of document an operator's counsel or an enterprise security reviewer can read and recognize: specific, written down, and free of marketing language that would not survive a careful read.
Three principles shape the rest of this document. The first is that the operator owns the data. Velzyx is the engineering layer underneath; the data the system handles belongs to the operator and is treated accordingly. The second is that the posture is described in plain language — there are no statements on this page that the engineering team is not prepared to defend in a written response to a diligence questionnaire. The third is that the trajectory is explicit. Where Velzyx has a control in place today, the section below says so. Where Velzyx is actively working toward a control, that distinction is made explicit, and the page is updated as the trajectory advances.
The Trust Center sits alongside the dedicated Security and Privacy pages. The Security page covers the operational mechanics; the Privacy page covers the legal disclosures, including the consumer-facing rights an operator's end users hold under the California Consumer Privacy Act. This page consolidates the institutional view: how Velzyx behaves as a company across the operator data, the security boundary, the compliance posture, and the conduct expected during an incident.
02 — Data handling
What is collected, how it is stored, who can access it.
A Velzyx deployment touches the data the operator's workflow requires it to touch, and nothing more. For a dental voice deployment, that typically includes patient names, contact information, insurance details, scheduling preferences, and the transcript of the conversation the system handled on the operator's behalf. For a real estate web platform, it is listing data and inquiry information. For an underwriting engine, it is the deal parameters and financial inputs the operator submits. The data the system touches is the data the engagement explicitly scopes.
Conversation transcripts and workflow records are retained for a window the operator configures during the engagement and then deleted or archived per that configuration. Retention is a setting the operator chooses, recorded in writing during onboarding. Where an operator wants stricter retention — for example, deleting transcripts immediately after the structured data has been written back to the practice management system — that configuration is supported. Where an operator wants longer retention to satisfy a regulator or an internal policy, the engineering team configures the storage tier and the access controls around the longer-lived data accordingly.
Access to operator data inside Velzyx is restricted to the engineers who require it for the system they operate. The default access posture is no access. Any engineer who needs to look at production data for a specific debugging or operational reason does so under a logged, time-bounded grant, with a written record of the reason. There is no shared engineering account that retains standing access to operator data, and access reviews are conducted on a defined schedule with the results recorded.
Velzyx does not train shared models on operator data. The operational AI systems Velzyx ships are configured per operator, and the data that flows through them stays within the scope of that operator's deployment. Inference is run within the Velzyx engineering practice under contractual terms that prohibit any operator data from being used for model training, ever. Operators can request documentation of the relevant terms during diligence.
03 — Security architecture
Encryption, access controls, audit logging.
Data in transit between operator interfaces, Velzyx components, integrated systems, and supporting services is encrypted using current transport-layer standards. The engineering team treats unencrypted in-transit traffic as a defect, not a configuration option. Integrations are wrapped in defensive code that fails closed when a transport-level expectation is not met.
Data at rest in Velzyx-managed storage is encrypted using current industry-standard symmetric encryption. Key management is handled through a hardened key management service, with separation between the engineers who can deploy code and the controls that can read keys. Backups are also encrypted at rest, with retention configured to match the operator's retention policy on the primary store. The architecture treats per-operator isolation as a design principle: the operator's data within a deployment is logically separated from other operators' data, and Velzyx does not run a shared multi-tenant database in which an engineering mistake could expose one operator's data to another.
Production system access is gated by hardware-backed second-factor authentication. Engineering credentials are rotated on a defined cadence and immediately upon any role change. The set of engineers with production access is small by design. Production actions of consequence — deployments, configuration changes, access grants, manual data operations — are recorded in an append-only audit log. The audit log is retained, monitored, and available to operators on request during diligence or post-incident review.
04 — PHI and HIPAA posture
HIPAA-aware deployments, BAA on request, AES-256 on PHI fields.
The Aria voice runtime is deployed inside dental practices, which means a meaningful share of Velzyx's production traffic involves protected health information. The engineering team treats those deployments as HIPAA-aware: data flows are scoped to the minimum information the workflow requires, access controls are applied to the data the system retains, and the engineering and operational practices around those deployments are designed to support HIPAA-relevant obligations.
A business associate agreement is available on request for HIPAA-relevant deployments. Operators in dental, and operators in adjacent healthcare-aware industries where the same posture is required, can sign a BAA as part of the engagement. The agreement covers the data the deployment handles, the access controls in place around that data, the breach notification obligations Velzyx accepts, and the operational practices the engineering team commits to. Operators are encouraged to involve their own counsel during BAA review.
For PHI fields in HIPAA-aware deployments, the encryption grade is AES-256 at rest. The same encryption posture is applied to backups and to any long-lived transcript storage where PHI fields are present. PHI-aware data handling extends to the integration layer: where a deployment writes structured data back into the operator's practice management system, the write path is engineered to avoid leaking PHI to surfaces the workflow does not require it to touch.
05 — Compliance trajectory
On the SOC2 trajectory. Currently in alignment with SOC2 principles.
Velzyx is actively working toward SOC2 Type II. The engineering team is currently in alignment with SOC2 principles — documented controls, formalized access management, hardened production environment, evidence collection practices — and formal certification is on the roadmap. The page is precise about this on purpose: the engineering team will not claim a certification it has not earned, and this section is updated when that status changes.
In the meantime, Velzyx is willing to share, under appropriate confidentiality, the working documentation of the controls in place today. That package includes the data handling policies described on this page, the access control model, the incident response procedures, the subprocessor management posture, and the current state of the SOC2 readiness work. Operators with formal diligence requirements can request the package as part of the engagement.
HIPAA is treated as a compliance posture rather than a certification. There is no HIPAA certificate to display, because HIPAA does not work that way. Instead, Velzyx makes the HIPAA-aware controls explicit in writing, signs a BAA where the engagement requires it, and supports the operator's HIPAA obligations through the engineering practices described above. Where an operator has additional jurisdictional obligations — PIPEDA in Canada, sector-specific obligations in education, financial services, or hospitality — the engineering team works with the operator to align the deployment's posture with those obligations.
06 — Subprocessor stance
No public subprocessor list. NDA-protected disclosure on request.
A production AI system depends on a handful of underlying services. Velzyx maintains a current internal subprocessor list, with the data each one touches and the contractual posture under which it is engaged. The engineering team treats subprocessor selection as a security decision rather than a convenience decision: each vendor is evaluated against its own published security posture, its contractual willingness to support the obligations Velzyx has to operators, and the production reliability the engineering team has observed.
Velzyx does not publish a public subprocessor list. The full current list is shared with operators on request, under an NDA-protected disclosure during diligence, by writing to info@velzyx.ai. There are two reasons for this stance. The first is that publishing a complete current vendor list creates a target surface that adversaries can use to study the deployment from the outside; the engineering team would rather keep that information inside a controlled disclosure process with operators who have a contractual relationship. The second is that the public vendor list, once published, becomes a marketing surface for those vendors; Velzyx is not in the business of providing free marketing for its underlying services, and operators are generally indifferent to which specific services sit behind the deployment as long as the contractual posture and the engineering controls are documented.
When the subprocessor set materially changes, operators are notified in advance. The notification includes what is changing, why, and what (if anything) the operator needs to acknowledge. Operators can object to a subprocessor change inside a defined window; where the objection cannot be resolved, the engagement's contractual exit terms apply.
07 — Operator data ownership
Operators own their data. Export and deletion on request.
The operator owns the data that flows through a Velzyx deployment. Velzyx is a custodian: the engineering team operates the system, applies the security controls described above, and supports the operator's use of the deployment, but the data itself is the operator's. The legal posture in the master services agreement reflects this, and the operational posture described on this page is consistent with it.
Operators can request a structured export of their data at any time. The export is delivered in a documented format, with the schema and the field-level descriptions an operator's engineering team can use to ingest it into another system. Where an operator is winding down a deployment, the export is the basis for the orderly hand-off back to the operator's environment.
Operators can also request deletion of their data. The request is processed against the deployment's primary store, the backups, and any long-lived archival storage, with a written confirmation of completion. Deletion timelines are documented in the engagement's master services agreement and the BAA where applicable. Where regulatory or contractual obligations require Velzyx to retain a subset of the data beyond the deletion request, those exceptions are identified in writing.
08 — Incident response
Documented playbook. Engineering on call. Written post-incident reviews.
Velzyx maintains a documented incident response playbook covering detection, triage, containment, eradication, recovery, and post-incident review. The same engineers who build and operate the production systems are the ones on call when something goes wrong, which compresses the path from detection to resolution and avoids the hand-off failure mode that affects larger operations.
When an incident affects an operator's deployment, Velzyx commits to notifying that operator inside the engagement's contractual window. Where a signed BAA is in place, the BAA-defined breach notification timeline applies. The notification includes what is known about the incident, what is being done about it, and what the operator needs to do, if anything. The engineering team does not wait for a complete picture before notifying — the operator gets the first communication early, and then a follow-up as the picture sharpens.
Post-incident reviews are written and shared with the affected operator in their full technical form, including the timeline, the root cause analysis, the contributing factors, and the corrective actions. Where a review reveals a control gap, the gap is closed before the review is closed. The corrective actions are tracked to completion and the operator is informed when each one is done.
09 — Related references
Trust posture sits alongside the operational and legal references.
The Trust Center is the institutional summary. The supporting references go into more detail on the specific surface they cover. The Privacy Policy covers the consumer-facing rights an operator's end users hold, including the California Consumer Privacy Act's Do Not Sell My Personal Information right. The Terms of Service cover the contractual framework that sits between Velzyx and an operator. The Security page goes into the operational mechanics of encryption, access controls, vendor management, and vulnerability disclosure.
Diligence questions that this page does not answer go to engineering. Responses come from the people who run the systems, not from a separate compliance desk.
Contact
Questions about trust posture? info@velzyx.ai.
If your organization has a security questionnaire, a BAA template, or a specific control to evaluate, send it to engineering. Responses come from the people who run the systems.
