01
Data submitted for proof of concept
Client data provided for a proof of concept is held in an environment scoped to that engagement, separated from other clients’ data and from our general infrastructure.
Access is limited to the engineers assigned to the engagement. Access is granted for the duration of the work and revoked on completion.
At the end of the engagement, data provided for the proof of concept is deleted or returned, at the client's election. Retention beyond that point happens only where the client has asked us to retain it in writing, or where a legal obligation requires it. Specific retention, residency, and deletion terms are set in the engagement agreement.
02
Model training
We do not use client data to train models that serve other clients. Data provided by a client is used to build, tune, and evaluate systems for that client only.
Any exception requires a separate written agreement identifying the data involved and the purpose. Absent such an agreement, no client data enters a shared or general-purpose model.
03
Inference logging
A deployed system records what it decided and why. Depending on the configuration agreed with the client, that record can include the input the decision was made on, the model or agent that made it, the action taken, and the rationale.
Logs exist so that decisions are auditable and failures are diagnosable. Retention periods, storage location, and who may read them are set per engagement. Where logs are held in client infrastructure, the client controls them.
04
Third-party model providers
Where a system uses a hosted model API rather than a model we run ourselves, data sent to that model transits the provider's infrastructure. We disclose which providers are involved before the system is built, and the choice is subject to client approval.
Where a client requires that no data leave their environment, we scope the system for self-hosted or on-device models instead.
The named list of current providers is to be confirmed before publication.
05
Automated decision-making
Some systems we build make decisions without a person in the loop. Where such a decision concerns an individual and has a legal or similarly significant effect on them, that individual has the right to obtain human review of it.
Systems are configured with human-in-the-loop checkpoints on the decision classes that require them, an audit trail of every automated action, and the ability to override or roll back a decision. Where a decision class cannot safely be autonomous, we scope it as recommendation-only.
Requests for human review of an automated decision made by a system deployed in a client's operation are handled by that client as data controller, with our support.
06
Contacting us
Questions about this policy, or a request concerning your data, can be sent to [email protected].