This page contains no new caveats — it collects the ones already made on the individual service pages, because spread across six of them they were hard to find at exactly the moment they matter most: before signing. Each thing we will not build links the page that covers it in more depth; the conditions in the second section come from the two pages named beneath that list.
What we will not build
- Cold-email automation. AI-generated mass outreach is a legal risk — consent and electronic-communication rules — and a reputational one that no dashboard shows: a burned domain and a spammer's reputation outlast 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 reaches customers or changes the state of a system starts in an approval mode. Loosening the oversight is a decision made on pilot data, not an assumption in a proposal — described at AI agent implementation.
- Predictions without a data history. Route optimisation, failure prediction and opportunity scoring all need months of consistently described history. 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. Examples at AI in a transport company.
- Decisions with nobody accountable. The system prepares the material — a quote, a posting, an 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.
- Legal advice. A register of AI systems, documentation, logging 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 readiness audit and on the security and GDPR page.
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. A history of decisions in somebody's head, in email attachments, or in a system with no API is not data an implementation can be built on within a sensible budget.
- The saving does not cover the running cost. Every AI system has a fixed cost: the model, monitoring, corrections. 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 outright, and others require preparation whose cost changes the point of the project.
- The bottleneck is not the work the system would take over. 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.
- The decision rules are unspoken. 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 add up: the process takes little enough time that the saving will not cover running the system, or the bottleneck is 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 will you not build cold-email automation?
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 burned domain and a spammer reputation outlast the campaign by a long way, and the cost of rebuilding them shows up on no dashboard. 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 GDPR?
No. We handle the technical and organisational side: the register of AI systems, documentation, logging, 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 useful role is making sure the system can be built in line with that decision, not the other way round.