Vectyr hosts and operates the system
We build and run the system on infrastructure we operate. That is a deliberate engineering position rather than a commercial preference, and it is worth explaining, because a reviewer sometimes expects a vendor to offer installation into the customer’s own cloud account and reads its absence as inflexibility.
The systems we build are not static applications that sit still once installed. They are continuously evolving pipelines: extraction logic changes as we learn how a client’s meetings actually sound, models and prompts are versioned and re-evaluated, classifiers are retrained, new data sources are connected, and new calculated outputs are added as the client thinks of them. That pace of change is the product. Delivering it depends on our team being able to deploy, observe, instrument, and roll back many times over the life of an engagement, against infrastructure whose behaviour we know precisely.
Running that inside a customer’s cloud account means every change is mediated by someone else’s change-control process, every diagnostic depends on access we do not control, and every provider difference becomes a source of defects we cannot reproduce. Clients who have been through a vendor-installed deployment of something genuinely dynamic will recognize the failure mode: the system freezes at the version that got approved.
So we take responsibility for the platform, and we earn the trust that requires by being auditable rather than by handing over the keys. What follows is what that means concretely.
Dedicated resources per client
There is no shared multi-tenant application. Each client gets:
Its own deployed application instance. Its own database. Its own object storage. Its own credentials and secrets. Its own audit trail. Its own retrieval and search indexes.
No datastore holds more than one client’s records, so there is no query that could return another client’s data and no tenant identifier doing the work of isolation. This is a stronger separation than the logical filtering most multi-tenant products rely on, and it is the main reason we can host without asking a client to. See Tenancy and isolation.
Where it runs
| Provider | Role | Notes |
|---|---|---|
| Cloudflare | Primary platform: application runtime, relational storage, object storage, secret storage, controlled outbound gateway | Fully managed and serverless, so there is no operating system fleet to patch. Holds SOC 2 Type II and ISO/IEC 27001 certification |
| Amazon Web Services | Dedicated compute where an engagement requires it, including GPU capacity for self-hosted models | Used per engagement rather than by default. Holds SOC 2 and ISO/IEC 27001 certification |
| DigitalOcean | Dedicated compute and GPU capacity, as an alternative where it suits the workload | Used per engagement rather than by default. Holds SOC 2 certification |
The providers and regions actually in use for a given engagement are recorded in that engagement’s own documentation and confirmed in its data processing agreement. We can pin storage and processing to a specific region where a client has a residency requirement; see International data transfers.
Two options for AI processing
This is the choice that matters most in a security review, and it is genuinely a choice.
Option 1 — Enterprise API inference (default)
Extraction and question answering use a commercial model provider’s enterprise API, under contractual terms that prohibit training on submitted content and provide zero or minimal retention. Prompt content leaves our infrastructure to reach that provider, under contract, and reaches no other third party.
This is the default because frontier models are currently the most capable at reading human conversation, which is the hardest part of what we do. For most programme and project data it is proportionate.
Option 2 — Self-hosted models on dedicated infrastructure
Extraction runs on open-weight models deployed on GPU capacity we operate for that client alone. No third-party inference provider receives any client content. There is no external model API in the path at all.
This is the option for clients whose policy restricts what may be submitted to external AI services, which is a common and reasonable restriction — particularly in research institutions and critical infrastructure. It is what we mean when we describe processing as private or self-hosted, and we are precise about it because that language gets used loosely in our industry.
The trade-off is real and we state it rather than glossing it: open-weight models are capable but not identical in quality to the strongest frontier models, so extraction accuracy is tuned and measured against the client’s own evaluation set during the pilot, and we set expectations from measurement rather than optimism. See AI evaluation and accuracy.
Either option can be combined with deterministic processing — parsers, rules, and classifiers — which handles a substantial share of the work with no model involved at all. Reducing what reaches any model is the strongest privacy control available, and it is a design goal in both options. See AI governance and the AI model register.
What we do not offer
Stated plainly so nobody spends review time on it.
Installation into the client’s own cloud account or on-premises servers. For the reasons above. If your process requires that a vendor deploy into your tenancy with no exceptions, we are not a fit, and it is better to establish that in week one than in week six.
Customer-managed encryption keys. Encryption at rest uses the platform’s managed keys. We do not offer client-held keys, because we do not operate in an environment where the client controls the key management service. See Encryption and key management.
A configuration in which Vectyr is technically incapable of reading client data. The system’s core function is to extract meaning from content, which requires the ability to read it. What we offer instead is that access is narrow, authenticated, logged, and contractually constrained, and that no third party sees the content in Option 2.
How to get assurance without hosting it yourself
The reasonable question behind a client-hosting request is usually “how do I verify what you say is true.” Our answers:
Completed HECVAT and CAIQ responses, warranted contractually, with material deviation treated as material breach.
A technical session with the engineer who builds the system, not a sales engineer. Bring your integration and identity people.
Client-commissioned penetration testing of your deployed system, at no charge, with findings remediated on our standard severity timelines and evidence provided. See Penetration testing program.
Contractual audit rights, annually and after any incident.
An independent examination of the delivered system once it is live and operating, scoped by you, available as a contractual milestone. See Compliance and certifications.
Read-only, narrowly scoped integration credentials that you create, consent to, and can revoke at any time without contacting us — which means the exposure you are being asked to accept is bounded by a grant you control and can inspect in your own tooling. In practice this is the single most important control in the architecture. See Microsoft 365 integration security.
