AI Use Policy 

Almost nobody in this industry publishes one of these. That's the reason we do.

If you're going to let an AI system talk to your customers or read your paperwork, you're entitled to know how it behaves, what happens to the data, and where the limits are — before you sign, not after something goes wrong. This page is that answer, in plain language.

On this website. We run AI agents you can talk to by text and by voice. They identify themselves as AI in their opening line, and they confirm it plainly if you ask again.

In our content. We use AI tools in producing written content for this site. A person reviews everything before it publishes. We do not publish unreviewed AI output.

In the systems we build for clients. Voice agents, support agents, document processing, workflow automation and content production.

Any AI agent we operate or build identifies itself as AI at the start of an interaction. We do not build systems designed to pass as human, and we will not accept an engagement that asks us to.

Every agent we build has a route to a person. If someone asks to speak to a human, the agent hands over — it does not attempt to resolve the request first.

On this site. Our agents receive what you tell them in conversation. Voice conversations are recorded and transcribed. We keep the conversation content, and any contact details you choose to give us, to respond to your enquiry and to improve how the agents perform.

Don't give our website agents sensitive personal information, financial details, or confidential information about your business. They're a front door, not a secure channel. Our agents will never ask you for payment details, banking information or government identification numbers — if anything claiming to be us does, it isn't us.

In client systems. What a system accesses is defined in that client's scope document and is limited to what the job requires. We document it before the build starts.

Our systems are built on third-party AI platforms. For each platform we use, we can tell you: who it is, where processing takes place, what their retention period is, and whether data passed to them is used to train their models.

Our current position: [state it plainly — for example, "we use vendors under business or enterprise terms that exclude customer data from model training, and we confirm this in writing for each engagement"].

Where a client requires processing in a specific jurisdiction, tell us before the build. It affects which platforms we can use and sometimes what the system can do.

Full autonomy is where AI projects go wrong. We design for the opposite.

Document processing runs on confidence thresholds. Clean extractions flow through; anything ambiguous routes to a person with the source document and the suggested answer side by side.

Customer-facing agents escalate on rules the client sets, and always on request.

Content is reviewed by a person before publication, without exception.

Decisions that materially affect a person — credit, eligibility, employment, service refusal — are not automated end-to-end. An AI system may prepare, extract or recommend. A person decides.

We document these review points, and we'll tell you before launch where they sit. If a client removes one against our recommendation, we record that in writing.

We decline this work, and we say so on the first call rather than after the invoice:

• Systems designed to deceive, including AI presented as a person

• Impersonation of a real individual without their documented consent

• Unsolicited bulk messaging, or outreach that breaches CAN-SPAM, CASL or GDPR

• Scraping in breach of a site's terms or applicable law

• Surveillance of employees or individuals without their knowledge

• Fully automated decisions on credit, employment, housing, insurance or anything else where being wrong causes serious harm to a person

• Content designed to mislead about health, finance, elections or public safety

• Anything unlawful in the jurisdiction it operates in

AI systems produce probabilistic output. They can be wrong, and they can be wrong confidently. That's a property of the technology, not a fault we've failed to fix.

What we do about it: ground systems in your actual documentation rather than general knowledge; build confidence thresholds and escalation paths; test with your team before anything reaches a customer; monitor and report on what the system couldn't answer.

What we don't do: claim any system is always right, or ask you to take that on trust.

Website conversations: retained for [period], then deleted.

Client system data: retained per that client's agreement, in systems the client owns wherever technically possible.

You can ask us what we hold about you and ask us to delete it. Write to [privacy email] and we'll respond within [period]. Where data sits in a client's own accounts, we'll tell you who to contact.

Wherever it is technically possible, we build in your accounts, on your keys, with your data. That means your information stays under your control, and it means you can leave.

We don't sell client data. We don't use one client's data to build another client's system.

We hold our staff to the same standard we'd write for yours: approved tools only, no customer personal information or credentials in unapproved tools, and every person responsible for the output they send regardless of what produced the draft.

If one of our systems produces something wrong that reaches a customer, or if data goes somewhere it shouldn't, tell us and we'll tell you. Same day, in writing, with what happened and what we're doing about it.

We'd rather have an awkward conversation early than a worse one later.

We review this policy every [six months]. This technology moves faster than most policies, so this page will change. The current version is the one published here, with its date.

[privacy email] · We answer these properly, and a person writes the reply.