Our role
For data inside a system we build and operate for a client, the client is the controller and Vectyr is the processor. We process that data only on the client’s documented instructions, for the purposes set out in the engagement, and we do not use it for our own purposes — including product development or model training.
For the personal data of people who contact Vectyr through our website, we are the controller. That is covered by our privacy policy and is separate from client system data.
What personal data our systems actually touch
The systems we build are about work, not people, but work is done by people, so personal data is unavoidably present. Typically:
Directly processed. Names, work email addresses, job titles, and team membership of the client’s staff and their vendors. Meeting participation and speech attributed to named participants, since a transcript records who said what. Task and action ownership. Workload and allocation estimates. Authored content in messages and documents.
Incidentally present. Anything a person happens to say in a meeting or write in a chat that is captured in the source material. This is the category that deserves the most care, because it is the one nobody plans for. A meeting about a research project can contain a passing remark about a colleague’s health, a personnel matter, or an individual’s circumstances.
We design for that reality rather than assuming it away: we minimize what is extracted and retained to what the task requires, we do not build features that profile individuals, and we support targeted deletion so that a specific item can be removed on request. Our handling rules for incidental sensitive content are in Data classification and handling.
Special categories, health data, and student records
Our default position is that our systems are not designed to process special-category personal data, protected health information, or student education records, and we architect engagements to avoid them.
Where an engagement runs in an environment that makes incidental exposure foreseeable — a clinical research department, for example, where a meeting could touch patient information — we treat that as a design constraint requiring specific controls rather than a disclaimer. That means self-hosted inference so no external AI service receives the content, a business associate agreement where HIPAA applies, exclusion of clinical systems from connection scope, minimized retention so source material is discarded once extraction completes, filtering and handling rules for incidental content, and a documented shared understanding of what the system is and is not permitted to ingest. The research institution annex sets this out in full, including FERPA considerations where students are involved in research programs.
Retention and deletion
Retention is set per engagement and per data category, not by a single global rule, because the right answer for a meeting transcript is different from the right answer for a verified decision record.
Broadly: source material such as transcripts and message content is retained for the shortest period that supports verification and audit, with a default that is deliberately short and configurable by the client. Extracted and human-verified records are retained for the life of the engagement because they are the operational record the client relies on. Audit and access logs are retained longer, since their purpose is to answer questions after the fact. Backups follow their own cycle and are covered in Backup and restore.
Clients can request deletion of specific items, of a person’s data, or of a whole category at any time. On termination, we return data in an agreed format and destroy remaining copies, including backups, within an agreed window, and confirm in writing when it is done. The schedule is in Data retention and disposal.
Individual rights
Because we act as a processor, requests from individuals normally reach the client as controller, and we support the client in responding. We can locate, export, correct, and delete an identified individual’s data within a system we operate, and we commit to assisting within timeframes that let the client meet its own statutory deadlines. We will not respond directly to an individual’s rights request about client data without the client’s instruction, since it is not our data to disclose.
International transfers
Data localization requirements vary by client and jurisdiction. We can pin storage to a region, and with self-hosted inference we can keep extraction in that region too, since we choose where that compute runs. With enterprise API inference the model provider processes content in its own region, which is the element most likely to conflict with a strict localization rule. Where a transfer requires a mechanism, we use standard contractual clauses and complete a transfer impact assessment on request. See International data transfers.
Contractual commitments
We sign data processing agreements, and we are happy to work from the client’s own template rather than insisting on ours. Institutions frequently have mandatory data protection terms; we would rather review yours than ask you to review ours. DPA and contractual commitments describes the terms we can commit to, including breach notification timelines, audit rights, subprocessor notice, and deletion obligations.
To start, email trust@vectyr.co with your standard terms attached.
