What we don't do

These are the limits of our offer, set out so you can check them before signing. Some work we do not take on at all; other work is not suitable for a first project. The links lead to related services and an explanation of how we work. The conditions in the second section come from the two pages linked beneath that list.

What we will not build

Automating bulk contact with people who have not asked for it. We do not build it for ourselves or for clients. AI-generated mass outreach is a legal risk — consent and electronic-communication rules — and a reputational one that campaign statistics do not show: a damaged reputation for the company’s e-mail domain, and for the company as a spam sender, outlasts the campaign. We do not build it even on explicit request. More at AI in a sales team.
Systems acting without approval from day one. Anything that goes out to customers or changes data in your systems or how they operate starts in a mode where a person approves the actions. Loosening the oversight is a decision made on pilot data, not an assumption in a proposal — described at AI agent implementation.
Autonomous accounting, lending and recruitment decisions. We do not offer autonomous accounting judgements, credit decisions or candidate ranking as ordinary automation. In accounting and lending, we can prepare data and working material for review; the decision stays with the person responsible for that domain. We do not build candidate assessments or rankings, including ones submitted for human approval. We apply this oversight boundary in AI agent implementation.
Voice agents as a first flagship deployment. We do not open with a large voice project or a promise to replace a call centre or conversations with customers. Where a voicebot (an automated system that holds phone conversations) makes sense, it starts as a voicebot pilot on one call type, integrated with an existing system and with handover to a person; widening the scope is a decision made on pilot data.
Unlimited support or 24/7 human availability. We agree the supported systems, work allowance and response hours. Continuous on-call cover needs a separately staffed operations team; an automation running around the clock does not mean we offer the same human availability. Our delivery methodology describes the handover.
Running everything on your own servers just to make the quote look cheaper. We compare the full cost: infrastructure, updates, backups and maintenance. Your own server makes sense when specific requirements justify it and someone is responsible for operating it, not just because there is no subscription fee. We agree the processing location alongside data and responsibility boundaries.
Predicting outcomes without data on past events. Route optimisation, failure prediction or scoring sales opportunities all need data covering enough past events — what counts is the number of recorded cases, not the number of months. If the company does not collect it, an honest offer starts by putting the data collection in order and says plainly that the predictive result comes later — rather than selling a data-collection project under the name of prediction. How to check that for yourself we set out under predictive maintenance; further examples at AI in a transport company.
Decisions with nobody accountable. The system prepares the material — a quote, a proposed accounting entry, a cost estimate — but the decision and the signature stay with a person who knows the technology and the rates. An offer promising an "automatic estimate" is promising decisions with nobody answerable for them; we develop this at AI in a construction company.
Voicebots that call people with offers they have not asked for. Automated calling systems (machines that place calls on their own) may not send commercial information without prior consent — business recipients included — and you may not call in order to obtain that consent. The fine is imposed by the President of UKE and the exposure stays with the caller, which is to say with the client. Same reasoning as the bulk e-mail item, with a penalty written directly into the Electronic Communications Law. More at voicebot implementation.
Machines pretending to be human. If a system is talking to a customer — by voice or in text — it is clearly marked as one, always. From 2 August 2026 Article 50 of the AI Act, the EU regulation on artificial intelligence, requires that disclosure too, although the article itself allows an exception where the machine is obvious from the circumstances and the context of use; we do not rely on it. Keeping a route to a person open throughout the conversation is likewise our own delivery rule rather than a requirement of that article. We do not build scripts whose purpose is that the other party fails to notice; described at voicebot implementation.
Systems that assess candidates in recruitment. Inferring emotions in the workplace is prohibited by Article 5(1)(f) of the AI Act and has been since 2 February 2025. The prohibition covers recruitment and probation, binds the deployer (the company using the system) as well as the provider, and a candidate’s consent does not lift it. We set out the boundary at voicebot implementation and at the AI Act technical compliance sprint.
Machines on emergency numbers. Evaluating and classifying emergency calls and prioritising dispatch is an Annex III high-risk use under the AI Act — the obligations for that category were deferred to 2 December 2027, which is deferred, not cancelled. We do not have the experience such a project would require. We return to it at voicebot implementation.
Debt-collection voicebots as a first project. We say this on reputational grounds, not legal ones: we found no provision prohibiting automated calling for debt collection, and we will not pretend one exists. We do not, however, want the first place a company tries an automated conversation with people under pressure to be debt collection. We develop this at voicebot implementation.
Legal advice. A register of AI systems, documentation, an activity log of what the system does (who, what, when) and a description of data flow — yes. Classifying the system, the legal basis and the impact assessment belong to the controller and their lawyer. We set out the boundary at AI Act technical compliance sprint and on the security and GDPR page.
AI training and workshops without an implementation. We practise working with the system only as a stage of an implementation — on the tools we have put live in that company, and on its own processes. We will not sell an open course or a one-day workshop with no implementation behind it, because without that context we cannot stand behind the result. More at AI implementation.

When we advise against a project

We check these conditions in the first phase, and if any of them holds we say so immediately — before invoicing for a build.

The process is not settled. If five people do it five ways and none of them is written down, there is nothing to automate yet. The process has to be agreed first, and that is organisational work, not engineering.
The data does not exist or cannot be reached. We check whether the data the process needs can be obtained — from an API (the interface other software uses to work with a system and its data), a file import, or documents such as email attachments. We also check whether the required actions can be carried out and whether the total cost is justified. If the decision history exists only in somebody's head, it has to be written down first — we then say how much work that is and whether it pays off. If the data cannot be obtained, or the actions cannot be carried out, at a justified cost, we do not take the project on.
The saving does not cover the running cost. Every AI system has a fixed cost: using the AI model (the engine behind tools such as ChatGPT), ongoing checks that the system works, making fixes. If a process takes two hours a month it is almost certainly not worth it — and better to hear that at the start.
The process has no owner. Without someone who decides, the project stops at the first disagreement about what counts as an error.
Regulation rules the scenario out. The AI Act prohibits some uses of AI outright, and others require preparation whose cost changes the point of the project.
The problem is waiting for a decision or missing information, not the time the task takes. Cases often sit still not because nobody is processing them, but because they are waiting on a decision, or on a form nobody fills in. Automation then speeds up the part that was never the problem.
Nobody can explain the decision rules. A process can be perfectly settled — everybody does it the same way — and still nobody can say why one case ends one way and the next ends another. Writing those rules down is work to do before the project, not during it.
A ready-made tool already does it. Do not build what you can buy on a subscription — we will say so even when it means there is no work in it for us.

The first five are checked in phase one of the delivery methodology; the last three are described at AI automation. If none of them holds, we usually start with a single document process — which one, and why, is on the AI implementation page.

Frequently asked questions

Do you turn work down?

Yes, and regularly. Usually not because the project is technically impossible, but because counted honestly it does not pay off: the process takes little enough time that the saving will not cover running the system, or the problem is waiting for a decision rather than the work the system would take over. We say so in the first phase, before invoicing for a build — we would rather lose the work than build something that will not pay for itself.

Why don’t you automate bulk sales e-mails to people who have not asked to be contacted?

For two reasons, neither of them ideological. The first is legal risk: mass outreach requires consent, falls under electronic-communication rules, and the liability stays with the sender. The second is more practical and less often mentioned in proposals: a damaged reputation for the company’s e-mail domain, and for the company as a spam sender, outlasts the campaign by a long way, and the cost of rebuilding it is not reflected in campaign statistics. We do not build this even when a client asks for it directly.

Can AI make decisions without a person involved?

Technically yes, but we do not start there and do not recommend it as a starting point. Every implementation begins in a mode where the system prepares and a person approves. Only the data from that pilot — how many proposals were correct, what errors occurred and what they cost — supports a deliberate decision about which categories of action can proceed without approval. That is a decision made on numbers after a pilot, not an assumption written into a proposal.

Do you give legal advice on the AI Act and the GDPR (General Data Protection Regulation)?

No. We handle the technical and organisational side: the register of AI systems, documentation, an activity log of what the system does (who, what, when), human oversight, and the description of data flow that a legal assessment can rest on. Classifying the system, choosing the legal basis for processing and running an impact assessment belong to the controller and their lawyer or data protection officer. Our job is to make sure the system can be built in line with that decision, not to bend the decision to fit a finished system.