Sub-processors

1. What this list is

QoreSafe engages the third parties below to deliver the Service. Each one is a sub-processor under our Data Processing Addendum, and each is bound by data-protection terms no less protective than that addendum.

2. Current sub-processors

3. What error monitoring receives

Sentry is the one entry above where what is sent is a decision rather than a consequence, so it is stated precisely. We configure it not to collect: user identity, cookies, request or response bodies, the local variables held in a stack frame when an error is thrown, or anything written to the browser or server console. Request and response headers and query parameters are collected for diagnosis, with values that would reveal your network origin filtered out.

What remains is the error itself — its message and the sequence of code that produced it — together with a short trail of what happened immediately before: pages visited, network requests and their status codes, and which controls were clicked. That trail records addresses and outcomes, not the contents of the records you were working on.

We work to keep record content out of error messages, but that is a practice rather than a mechanism, so we do not claim it as a guarantee.

4. Artificial intelligence

The AI features are not enabled, and no workspace data has been sent to an AI provider. We previously undertook to name the provider on this list before any data reached it rather than after. OpenAI has been selected, so it is named above now, ahead of enabling anything. When that changes, this paragraph changes with it.

Three features would send data, and they send different things:

• AI incident triage. When someone asks for a suggested classification while reporting an incident, the draft is sent as written — its title and description, the location, the immediate actions taken, and the type and severity chosen so far. An incident description is free text about something that happened to a person, so this is the most sensitive of the three; it is sent only when triage is requested, not on every report.
• The Safety Copilot. The question submitted to the assistant and up to 6 recent turns of the same conversation, together with the workspace summary described below.
• The optional narration of Safety Insights. Counts and totals only — incidents this period against last, open and overdue items, training compliance — together with the wording of the observations our own software generates from those numbers. It receives no record titles and no individual records. The insights themselves are computed without any AI; only the written summary of them uses it.

The workspace summary the Copilot receives is capped and read-only. It begins with your workspace’s industry, not its name, so the assistant has the context it needs without identifying your organisation. After that: counts and totals; a breakdown of how your incidents, risks and objectives divide up, which names the severities, risk levels, objective statuses and objective categories it counted; and short lists of recent incidents, highest-rated risks and overdue actions. Those lists carry reference numbers, dates, severities, incident types, risk levels, risk scores, action types and the titles your people wrote — so whatever a title says, the Copilot sends.

Some of those classifications — incident types and objective categories — come from lists your workspace defines itself. When an administrator adds an entry to one, we store it under a name derived from the label they typed, and that stored name is what the assistant receives: a category entered as “Contractor fatigue programme” reaches OpenAI as “contractor_fatigue_programme”. So those labels leave your workspace in the same way a record title does, and are worth writing with that in mind. None of the three ever sends your files, and one workspace’s data never reaches another’s request.

Before any request is sent, we replace the identifiers we can recognise with placeholders: links, email addresses, phone numbers, bank account and payment card numbers, IP addresses, and the full names of the people recorded in your workspace. This removes what it recognises; it does not make a request anonymous. A first name on its own, a nickname, or a description that points to one person can still reach OpenAI, so the advice about titles above still applies.

Under OpenAI’s API terms, data sent through the API is not used to train or improve its models unless we explicitly opt in, and we do not. It may be retained for up to 30 days for abuse monitoring, unless a longer period is required by law, and then deleted. The contracting entity, the processing region, and whether we adopt their zero-retention or data-residency options will be confirmed before those features are enabled.

OpenAI is the only provider these features are permitted to contact. That is enforced in the software, not left to configuration: if the service were pointed at a different AI provider, the features above stop working rather than send your data to a company this page does not name.

5. Changes to this list

We will give notice of an intended addition or replacement before it takes effect, and customers may object in accordance with the Data Processing Addendum.

6. Contact

Questions about this list may be sent to Vantisco S.R.L.S., Milan, Italy (VAT IT10026760966). Further details are available at vantisco.it.