Trust posture, data handling, and HIPAA-aware AI — explained plainly.

02 — Posture

Production-first. Operator-owned. Honest about the trajectory.

Velzyx runs AI systems that handle real conversations and real workloads for real operators. That is the starting point for everything on this page. A system that takes a patient call, or a system that underwrites a commercial real estate deal, is a piece of operational infrastructure, not a marketing surface. The security posture has to match that reality.

Two principles shape the rest of this document. The first is that the operator owns its 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 security claims on this page that the engineering team is not prepared to defend in a written response to an operator's diligence questionnaire.

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. The page is updated as the trajectory advances.

03 — Data handling

What data Velzyx touches, and what it does with it.

A Velzyx deployment touches the data the operator's workflow requires it to touch — no 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 includes listing data and inquiry information. For an underwriting engine, it includes 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 period the operator configures during the engagement, and then they are deleted or archived per that configuration. Retention is not a Velzyx default that operators have to argue against. It is a setting the operator chooses, with a written record of the choice. 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.

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.

04 — Encryption

In transit and at rest, with current industry standards.

Data in transit between an operator's interface and a Velzyx deployment is encrypted using current transport-layer standards. The same applies to traffic between Velzyx components, between Velzyx and the third-party services a deployment depends on, and between Velzyx and the operator's existing systems on the integration layer. The engineering team treats unencrypted in-transit traffic as a defect, not a configuration option.

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.

Where an operator's deployment integrates with systems the operator already runs, the in-transit posture extends to that perimeter. Velzyx does not exchange operator data with integrated systems in cleartext, and integrations are wrapped in defensive code that fails closed when a transport-level expectation is not met.

05 — HIPAA-aware deployments

Built for dental front offices, with BAA available on request.

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.

HIPAA-aware does not mean every Velzyx deployment is HIPAA-bound. For deployments outside healthcare — real estate web platforms, commercial real estate underwriting — the posture is appropriate to that context. The principle is the same: data handling matches the regulatory reality of the operator's industry, and the engineering team is explicit about what that means in writing.

06 — SOC2 trajectory

On the path to SOC2 Type II. Not certified today.

Velzyx is actively working toward SOC2 Type II. The engineering team has begun the work that supports that trajectory: documenting controls, formalizing access management, hardening the production environment, and building the evidence collection practices an audit will require. Operators evaluating Velzyx today should understand that the certification is in progress and not yet issued. The engineering team will not claim a certification it has not earned, and this page will be 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 includes the data handling policies described on this page, the access control model, the incident response procedures, the vendor 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.

The reason for being explicit about the trajectory rather than implying a certification is that the kind of operator Velzyx serves — dental practices with patient data, brokerages with client relationships, underwriters with deal data — deserves a straight answer. The engineering team would rather say "not yet, here is the timeline" than imply something that would not survive a careful read.

07 — Access controls

Least privilege, written down, reviewed.

Access to operator data is restricted to the engineers who require it for the system they are responsible for. Velzyx operates on a least-privilege model: the default access posture is no access, and any engineer who needs to look at production data for a specific debugging or operational reason does so under a logged, time-bounded grant. There is no shared engineering account that retains standing access to operator data.

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, both because the team is small and because keeping that set small is itself a security control. Access reviews are conducted on a defined schedule and the results are recorded.

The operator's data within a deployment is logically separated from other operators' data. Velzyx does not run a shared multi-tenant database in which an engineering mistake could expose one operator's data to another. The architecture treats per-operator isolation as a design principle, not as a configuration that can be relaxed for convenience.

08 — Vendor management

A small set of subprocessors, each chosen deliberately.

A production AI system depends on a handful of underlying services — infrastructure for compute and storage, transport for voice and messaging, and supporting tooling for engineering operations. The AI capability is operated within Velzyx-engineered infrastructure as part of the engineering practice. A current subprocessor list is available on request under NDA.

Subprocessor selection is driven by the security and operational posture of the underlying service, not by convenience. Vendors that handle operator data are evaluated against their own published security posture, their contractual willingness to support the obligations Velzyx has to operators, and the production reliability the engineering team has observed. When the subprocessor set changes, operators are notified in advance. Read more about how this fits into the engagement on the how it works page.

09 — Incident response

Documented playbook. Engineering on call.

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 within a window that matches the engagement's contractual obligations — including, where applicable, the breach notification obligations under a signed BAA. The notification includes what is known about the incident, what is being done about it, and what the operator needs to do, if anything. Post-incident reviews are written and shared in their full, technical form, and where a review reveals a control gap, the gap is closed before the review is closed.

10 — Vulnerability disclosure

If you find something, tell us.

Velzyx welcomes responsible disclosure of security issues affecting any of the systems we operate. Researchers who identify a vulnerability are encouraged to email security@velzyx.ai with a description of the issue, the steps to reproduce, and any information needed to assess impact. The engineering team commits to acknowledging the report within three business days and to working with the reporter on a coordinated disclosure timeline.

Velzyx will not take legal action against security researchers who act in good faith, follow standard responsible-disclosure practices, and avoid accessing data beyond what is necessary to demonstrate the issue. The engineering team values the work of the security research community and treats well-formed reports with the seriousness they deserve.

For diligence questions this page does not answer, the next step is to contact engineering. Privacy-related questions are addressed in the privacy page.