Security & Responsible AI
Requirements get agreed before anything is built.
Some things are how we work on every engagement. The rest (data scope, hosting, retention, model providers, logging, incident handling) is decided with you and written into the project before the build starts.
Standard on every engagement
Five things that don't change from project to project.
Your data stays yours
You keep ownership of your data and of the systems it sits in. We use it for the scope of work you've agreed, and for nothing else.
We deploy into your environment
The system runs on your infrastructure, cloud or on-premise, so access follows the controls your organisation already operates.
The logic is visible
You can see what the system reads, what business rules it applies and what it returns. No part of the reasoning is hidden from the people accountable for it.
A person approves before anything acts
The system prepares work. Actions that commit the business are released by someone on your team, not by the system on its own.
You keep it at the end
Documentation, the working logic and the deployed system stay with you, so your team can run and extend it without us.
Automatic work and approved actions
Nothing decides unsupervised.
Reading, extracting, matching, ranking and drafting run automatically: that's the work the system is there to take off people. Sending, ordering, pricing and anything else that commits the business waits for a named person to approve it.
Where the line sits is a project decision. We agree it per workflow, with the people accountable for the outcome, before the system goes live.
Agreed per project
Eight decisions we write down before production.
These depend on your systems, your data and your risk. We work through them during scoping, record what was agreed, and design against it rather than against a generic checklist.
Which records, fields and documents the system may read, and which are explicitly out of scope.
Which systems it connects to, with what credentials, and whether access is read-only or able to write back.
Where the system and its data sit. Set against your infrastructure and any residency requirement you bring.
How long working data and intermediate outputs are kept, and how they're removed at the end of the engagement.
Which models are used and on what terms, including whether any data may leave your environment to reach them.
What the system records about its own runs and decisions, who can read those records, and for how long they're held.
Who's contacted, in what time frame, and what happens to the system when something goes wrong.
What your team takes over at the end, and whether Casper continues in a support role and on what terms.
What we don't claim.
Casper doesn't publish a certification, a residency guarantee or a service level on this page. Where your organisation has one of those requirements, bring it into the first conversation: we'll tell you plainly whether the project can be scoped against it, and what it would take.
How we handle personal information from this website, our contact form and bookings is set out in the privacy policy. Client projects are governed by the confidentiality and data-processing terms agreed for that engagement, which can be more specific than anything written here.