How we use AI responsibly

AI is only useful if you can trust it. This page explains how we build AI for clients and how we use it ourselves, in plain English. If it doesn’t answer your question, ask us: we’d rather explain than have you guess.

Last updated 18 October 2026 · Not legal advice

Our principles

  • You choose where your data goes, and we write it down.
  • Your data isn’t used to train AI models unless you agree to it in writing.
  • A person is in charge of anything that matters: payments, messages to customers, changes to records, and decisions about people.
  • Answers can be checked. Where our systems give an answer, they show its source.
  • We measure accuracy before launch and every time something changes.
  • You own what we build: the code, the prompts, the configuration and the data.
  • We tell you when AI isn’t the right tool.
Illustration: a sheet of paper with a column of boxes, four ticked and the rest empty, a navy pen resting on the sheet and a cup of tea at the edge.

Where your data goes

Before we build anything, we agree a one-page data route with you. It shows where your data is stored, where it’s processed, which providers see it, and for how long. There are three ways to run the AI.

Tier 1

A hosted model, through a UK or EU endpoint

The best quality for the least effort. Before any of your data goes to a provider, we check that its business terms rule out training on it, and we tell you which region does the processing.

Tier 2

Inside your own cloud account

The model runs in your AWS or Azure account, under your access controls and your logs.

Tier 3

A private model on hardware in the UK

Open-weight models on your hardware or ours. Nothing goes to an outside AI provider. Our own research and document reading run this way.

A provider may store your data in the UK but process a request in another region. Some of the newest models are only offered through an EU-wide region rather than in London.

Storage location and processing location aren’t the same thing. We’ll tell you both, in writing.

Which models and providers we use

We pick a model for each job and record it in a model register you can see: the provider, the model and version, where it runs, and what data it sees.

Before any of your data goes to a provider, we tell you which provider it is and which region does the processing. For each project, the exact list of providers is in your data processing agreement.

Training and retention

  • We don’t use your data to train models. Before we use a provider for your data, we check that its business terms don’t let it train its models on your inputs and outputs, and we show you where that’s written. Where a provider offers reduced or zero data retention, we turn it on for sensitive work.
  • What we keep: logs needed to troubleshoot and to show what the system did, with as little personal data in them as we can manage. You choose how long they’re kept, and we write it into your contract. For the most sensitive data we can switch off detailed logging, and we tell you where we have.

People stay in charge

  • Anything uncertain goes to a person. Each system has a confidence threshold, and you set it.
  • Payments, messages to customers and changes to records wait for a person’s approval unless you decide otherwise, in writing, for a specific routine task.
  • Decisions about people. UK data protection law restricts decisions that are made solely by automated means and have a legal or similarly significant effect on someone. Where such decisions are allowed, they need safeguards: people must be told, be able to ask for a human to step in, and be able to challenge the decision. Where a system we build could make that kind of decision, we design those safeguards in from the start. We don’t build solely automated decisions based on special category data, such as health information.

Accuracy and testing

  • Before it goes live

    We agree a test set of real examples and a pass mark with you. A system doesn’t go live until it meets the pass mark.

  • When anything changes

    When the model, the prompt or the data changes, we re-run the test set before switching.

  • Counts, not percentages

    Small tests are reported as counts. “3 out of 3” is honest. “100%” from three examples isn’t.

  • After launch

    We monitor accuracy, cost and speed, and report them monthly.

Security

  • Every system gets the narrowest access that does the job.
  • Secrets are kept out of the code and stored encrypted.
  • Data is encrypted in transit and at rest.
  • Anything that comes from outside (web pages, emails, documents) is screened for hidden instructions before a model sees it.
  • Actions that matter are logged in a way that shows if anything has been altered.
  • Every application has its own spending limit and an off switch.

Data protection and DPIAs

  • When we build for you, we’re usually your data processor. We sign a written data processing agreement (UK GDPR Article 28), list our sub-processors, and keep to your instructions.
  • DPIAs. The ICO says most uses of AI that involve personal data are likely to need a data protection impact assessment. We help you write it: we know how the system works, so we can describe it accurately.
  • Our own example. We completed a DPIA for one of our own products in August 2026, following the ICO’s structure.

The EU AI Act

If you have customers or staff in the EU, the EU AI Act can apply to systems used there, even if they’re built in the UK.

  • Chatbots tell people they’re AI. Any assistant we build that talks directly to the public says it’s AI.
  • High-risk areas get extra care. AI used for hiring or managing staff, for credit decisions, or for pricing life and health insurance for individuals is treated as high-risk. If a project goes near those areas, we say so at the start and recommend legal advice before building.
  • We don’t build anything the Act prohibits.

What we won’t do

We won’t:

  • present AI-generated people as our staff, our clients or real customers;
  • write or publish fake reviews or testimonials;
  • make deepfakes of real people;
  • send messages or make payments on a client’s behalf without the approval rules agreed in writing;
  • use one client’s data for another client’s work.

How we use AI ourselves

  • Code. We write and review code with AI assistants. A person reviews everything that ships, and larger reviews use independent checking passes.
  • Email. Messages to our own inboxes, including website enquiries, may be sorted, and replies drafted, by AI. A person reads and sends every reply.
  • Content. When we draft content with AI, a person checks every claim before it’s published.
  • Images. The illustrations on this website are AI-generated and labelled as illustrations. Photos of Steven and Marta are real. We don’t use AI to create images of real people or to show client work that doesn’t exist.
  • Research. Our research crawler identifies itself as DatafaceResearch, reads robots.txt and backs off when asked. Read our crawler policy.

Questions or concerns

Email info@dataface.uk, or write to us at our registered office: Dataface Ltd, 6th Floor Gordon Chambers, 90 Mitchell Street, Glasgow G1 3NQ. If you think one of our systems has made a mistake about you, tell us and a person will look at it.

Get in touch

Ask us how your data would be handled.

One paragraph is enough. We’d rather explain than have you guess.

All fields are required unless marked optional.

0 of 4,800 characters

We use your details only to reply. See our privacy policy.