Data, privacy, and guardrails

This guide explains our general approach to data and safety when we build AI automation, assistants, or agents. It's written in plain language to set expectations before a project starts; it is not legal advice, and it doesn't replace your own data protection obligations or a conversation with a solicitor about your specific situation, especially if you handle sensitive personal data (health records, financial details, data about children).

Under UK GDPR, any processing of personal data needs a lawful basis, and that doesn't change because an AI model is involved: if an automation reads, stores, or acts on customer or staff personal data, the same obligations apply as they would for any other system: knowing what you're processing, why, for how long, and under what basis. We work through this with you as part of scoping a project, rather than treating it as a technical afterthought once something is already built.

When we use a hosted model provider (Claude, OpenAI, or Google, depending on the task), a request is sent to that provider's service to be processed. Provider terms around data retention, use for model training, and deletion do change over time and vary by plan and region, so rather than quoting a fixed policy here that could become outdated, we check the provider's current terms with you before anything goes live, and revisit this if a provider's terms change materially during an engagement.

On data residency: some providers offer regional processing options, and for businesses with specific residency requirements, this is something we scope explicitly rather than assuming a default location is acceptable. Where residency matters to your business, tell us early; it affects which provider and model are a sensible fit, not just a configuration toggle after the fact.

We practise data minimisation by default: an automation is given access to the specific information a task actually needs, not broad access to every system it could theoretically touch. A workflow that triages enquiries doesn't need access to your full customer financial history, for example, even if that data technically lives in the same CRM, access is scoped per task, not granted wholesale for convenience.

Human approval steps are the default, not an optional extra: anything that takes an action with real consequences (sending something externally, making a change a customer or staff member will notice, spending money) has a human checkpoint until there's a track record that makes an exception sensible, and that exception is always something we agree with you explicitly rather than assume.

Everything an automation does is logged: what it was asked to do, what it decided, and what action it took, kept for a retention period we agree with you based on your own data retention policy. This matters for two reasons; it lets you audit what happened if something goes wrong, and it gives us the evidence needed to improve the automation over time rather than guessing at what needs fixing.

Where an automation reads text from an external source (a customer email, an uploaded document, a web page), we build in limits against prompt injection: attempts to manipulate the model's behaviour by hiding instructions inside that content. No defence here is absolute, which is exactly why a human approval step on consequential actions, logging, and scoped permissions all matter as additional layers rather than relying on the model's judgement alone.

Finally, every automation we build has a kill switch: a straightforward way for you to pause or fully disable it immediately if something isn't behaving as expected, without needing to involve us first or wait for a scheduled change window. You should never be dependent on us being available to turn something off.