AI Development in the UK

For most business-to-business services supplied from outside the UK, the reverse charge applies: you account for the VAT in your own return rather than paying it to us, and it is typically neutral if you are fully recoverable. Our invoices state the position clearly so your accountant is not guessing. If your situation is unusual, for example partial exemption, we would rather your accountant confirms the treatment before we invoice than after.

We build to it rather than claiming a certificate. In practice that means data minimisation designed in rather than bolted on, a documented lawful basis for each processing activity, retention periods that actually delete, subject access and erasure handled as features rather than manual database work, and hosting in a region you approve. Where we process personal data on your behalf we sign a processor agreement setting out exactly that.

Yes, and it is scoped from the start because retrofitting accessibility is considerably more expensive than building it in. We work to WCAG 2.2 AA, test with a screen reader rather than relying on an automated scan, and produce the accessibility statement the regulations require. Automated tools catch perhaps a third of real issues, which is why the manual pass is not optional.

We are happy to contract under English law with the courts of England and Wales, and most UK clients prefer that. IR35 does not apply to us: it governs individuals working through an intermediary, and you are engaging a company for a defined deliverable rather than a person for their time. Your accountant will want to see that the contract reflects that, and ours does.

Often not, and we will tell you before you spend anything. Roughly half the briefs that reach us are better solved by a database query, a rule, or a clearer form. AI earns its place when the input is genuinely unstructured and the output is genuinely open-ended. If your problem is deterministic, a model just makes it slower, costlier and less predictable.

Grounding and checking. The model answers only from context we retrieved from your data, we validate the structure of what comes back, and we make it cite the source so a human can verify it. For anything where a wrong answer is expensive, we design a human approval step rather than pretending the problem is solved. No prompt makes a model incapable of being wrong.

That depends on model choice, context size and volume, and it is one of the first things we size rather than one of the last. We build per-request cost tracking and hard budget ceilings in from the start, and we route cheap requests to cheap models. A typical grounded support assistant runs a few thousand rupees a month at moderate volume; a heavy document pipeline can run considerably more, which is exactly why it gets measured before launch.

We use enterprise API tiers where prompts are not used for training, and we scope precisely what leaves your systems. Where data cannot leave at all, we build on open models you host yourself. This gets settled in scoping, not discovered during a security review.

Model Context Protocol is a standard way to give an assistant controlled access to real tools and data, so it can query your systems instead of guessing. It is useful when you want an assistant to actually do things rather than only talk about them. If you just need a grounded chatbot over a set of documents, you do not need it.