RunationBusiness systems
Book a free systems review
Menu
Plain-English website policy. Client work is also governed by a signed statement of work and, where needed, a data processing agreement.

AI Usage Policy

Last updated: 14 July 2026

We use AI in some of the systems we build. This page explains how, where, and — most importantly — where we deliberately don't.

For subprocessors, data retention and data protection terms, see the Privacy Policy.

Our principles

Five rules govern every AI component in every workflow we build:

1. No solely-automated decisions on anything significant.

Per UK GDPR Article 22 and ICO guidance, decisions with legal or similarly significant effects must not be made solely by automated processing where they affect a person. We don't build systems that do this. Examples we won't automate:

If your project requires automation in any of these areas, the AI assists a human; the human decides. We document the human's role explicitly in the SOW.

2. Your data does not train public models.

We use AI through API endpoints with explicit no-training settings:

If we build a workflow that fine-tunes a model on your data, we use a private model that only you can access. Your data does not leave your control to train public infrastructure.

3. AI is documented in every workflow it's part of.

If a workflow uses AI, that fact is in the documentation. No "hidden AI" — no workflows we describe as "automation" that quietly include an LLM doing something unsupervised.

The documentation specifies:

4. Confidence ≠ accuracy. AI errors get caught.

LLMs hallucinate confidently. We design every AI component on the assumption it will sometimes be wrong, regardless of how confident the output sounds.

For each AI component we build:

5. AI-generated content is labelled or human-reviewed.

If an AI generates content that goes to a customer or the public, one of two things is true:

We don't write fake LinkedIn posts pretending to be hand-written reflections. We don't generate "personalised" cold emails that pretend to be specific. If we wouldn't be comfortable seeing the workflow described publicly, we don't build it.

Where AI fits in our work

Concretely, where AI typically appears in workflows we build:

As a classifier or router

Reading inbound enquiries and tagging them by topic, urgency, or sender intent. The classification feeds routing logic. If the model is unsure, the message goes to a human.

Risk level: low. Errors are caught quickly.

As a draft generator

Producing first drafts: meeting summaries, follow-up emails, kickoff briefs, proposal sections. A human always reviews before anything goes out.

Risk level: low-medium. Quality varies; we tune the prompts and model choice per use case.

As a question-answering assistant

Internal "ask the SOPs" assistants over your knowledge base. Customer support chatbots with explicit escalation paths.

Risk level: medium. We invest more here in confidence thresholds, source-citing (the assistant links to the page it learned from), and clear "I don't know — let me get a human" fallback behaviour.

As an extraction tool

Pulling structured data from unstructured input — e.g. parsing an email reply for a date, extracting line items from a PDF invoice. Results are validated before they enter your CRM or finance system.

Risk level: low. Errors typically caught at validation step, not after.

As a voice agent (Phase 2 — month 4–6)

Phone agents that answer calls, qualify, and book audits. Deferred until we can build them robustly enough to publish a Workshop post about. Currently not in any client workflow.

Risk level: high. We're not building these in production until we trust them.

What we will not build with AI

To be specific:

How we handle AI errors

When an AI component produces wrong output:

  1. Detection: the workflow's validation logic catches it (low confidence, format mismatch, business rule violation), or you flag it.
  2. Containment: the workflow pauses for that input. Other instances continue running.
  3. Investigation: we look at the prompt, the output, the surrounding data. If the error is reproducible, we fix it (better prompt, different model, additional validation).
  4. Communication: if the error affected a customer-facing output, we tell you within 24 hours with what happened and the fix.
  5. Documentation: errors that change a workflow are logged. If a pattern of errors emerges, we revisit the design — sometimes the right answer is "this shouldn't be AI at all."

Where AI is a bad fit (and we'll say so)

Not every problem is an AI problem. We frequently recommend not using AI where:

Most "AI agency" pitches start with "we'll use AI." Ours start with "let's check if AI is the right tool." Sometimes it's not; we'll tell you.

Your rights

You always have the right to:

For data subjects whose data is processed by AI in our workflows, the rights in our Privacy Policy apply, including the right not to be subject to solely-automated decisions with significant effects.

Models we use

Currently, depending on the workflow:

Model choice is documented per workflow. We don't pick based on which vendor has the most aggressive partner programme; we pick what works for the task.

Changes to this policy

We update this page when:

Material changes are reflected here with an updated date. Active clients will be notified by email.

Contact

For any question about how we use AI: info@runation.co.uk.

For complaints about AI handling of your data, you can also contact the Information Commissioner's Office.