AI Integration.

AI that fails safely.

The risk with AI in a business workflow is not that it is wrong sometimes. Everything is wrong sometimes. The risk is that nothing watches it being wrong, and the wrong output reaches a customer, a regulator, or a decision the business cannot easily walk back. Every AI integration we build includes a Judge. That is the difference.

What a Judge actually does

A Judge is a check that validates AI output before it reaches a person or a customer. It can be code, a rule, or another AI step asked to grade the first one. The right Judge for the job depends on what is being asked of the AI and what would happen if the output were wrong.

For a draft email reply: the Judge checks tone against policy, looks for off-brand language, flags any factual claim the AI introduced that is not in the source thread, and checks confidence. Anything that scores below threshold is held for a person to review.

For a document classifier: the Judge checks the classification against rule-based signals (sender, attachment type, file size, prior history) and only routes automatically when both agree. Disagreement queues the item for human review with the AI’s reasoning shown.

For a lead-scoring step: the Judge applies a rule-based floor (real company, real role, real industry) so the AI cannot promote an obviously unqualified record purely on enthusiastic copy.

The Judge runs every time. It does not get switched off because the AI has “been working fine lately”. The methodology aligns to internal audit and process optimisation discipline: the control exists because the absence of the control is what makes the system unsafe, not because anything has gone wrong yet. Read more on how Judges work in judges and AI guardrails for small business.

Where AI fits in a workflow, and where it does not

AI is one node in a larger automation, not a separate tool your team has to log into. A typical integration takes four weeks end to end: discovery and use case selection, design and prompt work, build and test, integration and deployment. The length depends more on the cleanliness of the data and access to systems than on the AI itself.

Use cases that work well: drafting replies that a human approves, summarising long documents into structured fields, classifying inbound work, qualifying leads, extracting data from unstructured documents, flagging anomalies for review. The common thread is that AI is augmenting a decision, not making the final one.

Use cases that do not work yet: anything that needs to be right every time without a check, anything where the cost of a wrong output is high and the cost of a human review is low, anything where the source data is too noisy or too sparse for the AI to have a chance. We will say no to these in scoping rather than build them and watch them fail.

Why model choice and data routing are independent decisions

Two questions get decided service-by-service, not once and applied to everything.

The model. Claude is the default for most reasoning, drafting, and summarisation work because it follows instructions reliably and handles long context. Other models are used where they perform better: smaller local models for sensitive data, faster models for high-volume classification, alternative providers for redundancy. The choice is made on the work, not on the bill.

The data route. Where the AI step touches personal data (customer information, employee records, financial data, anything that identifies a real person), we agree the processor relationship and the data flow before the build starts. Cross-border flow, data retention, and processor obligations under GDPR Article 28 all get named in writing. For client-sensitive work or work that cannot leave the UK or the EU, the AI step can run on a self-hosted model on infrastructure you control rather than a hosted API.

We are independent AI and automation specialists. No vendor pays us to recommend their model. No commission flows from where the data ends up. The choice is the one that fits the work, including the choice of “do not use AI for this step” when that is the honest answer. A build that uses AI in one step often needs an Automation Build around it, and the team using the result usually benefits from an AI Training session once it is in live use.