Our consultancy includes advice on applied artificial intelligence, and the first thing we tell a client is what we do not do. We do not sell software, we do not resell anyone else's, and we take no commission from any vendor. We help operators judge what the technology can do for their particular business, pilot it on terms that produce evidence, and buy it where buying is warranted. Where a tool needs an evaluation or a workflow built around it, we will build that, and it belongs to the client. The boundary sounds like a limitation. It is most of the value.
The incentive problem
Most advice about this technology arrives with a conflict attached. The integrator's assessment concludes that integration is needed. The vendor's workshop discovers that the vendor's product fits. The consultancy with a delivery arm finds, reliably, a solution shaped like delivery. None of those people are lying. They are answering the question their business model asks. The operator meanwhile needs an answer to a different question, which is whether this is worth the money and the organisation's attention, and almost nobody in the room is paid to answer that one.
We arranged the practice so that we are. Because we have nothing to sell, we can conclude that a tool is not worth adopting, and we often do. Some of our most useful engagements have ended in a short memo explaining why the proposed system should not be bought, because the data was not ready, because the process it automated was itself the problem, or because the saving disappeared once the true cost of the exceptions was counted.
What operators actually need
The questions that matter here are operating questions wearing technical clothes. Which of our processes have enough volume and regularity to reward automation, and which are exceptions wearing a uniform. What does this tool want from our data, and what does it do with it afterwards, which we weigh heavily because confidentiality is a working condition for most of our clients and a surprising number of tools want private correspondence and commercial records sent elsewhere as the price of convenience. Who inside the business will own the system once the enthusiasm fades. What happens when it is wrong, and how would anyone notice.
None of those require a data science qualification to ask. They require the habits of someone who has run an operation, meaning scepticism about demonstrations, respect for the boring path and an instinct for where the exceptions hide. That is the experience we bring from our own trade and our own brand, and it transfers between industries better than enthusiasm does.
Piloting on honest terms
Where a tool passes the first test, we design the pilot so that it can fail informatively. A defined process, a measured baseline before anything is switched on, an agreed number that would justify adoption, and a date on which the answer is yes, no, or a named reason to extend. A pilot without those elements does not test the tool. It tests the organisation's willingness to admit a sunk cost, and the tool wins by default.
We also insist that a person stays in the loop wherever a mistake would be expensive, and that the cases the system is unsure about are routed to someone who can decide. A workflow with no answer for the wrong case is a workflow that gets switched off in its second month, usually after it has already caused the problem it was bought to prevent.
Where it does earn its place
None of this is scepticism about the technology itself. In the businesses we know best, it earns its place in a few specific jobs. Reading documents that arrive as scans and photographs, and pulling out the fields somebody would otherwise type. Suggesting a customs classification for a person to approve. Drafting a first version of something repetitive that a knowledgeable person then corrects. Searching a company's own accumulated material, which is usually more valuable than anyone expects, because most businesses have already written down the answer to the question being asked.
What those jobs share is high volume, a clear definition of a correct answer, and a person available to catch the cases where the answer is wrong. Where any of those three is missing, enthusiasm tends to outrun the result, and the pilot quietly stops being mentioned.
The question to ask any adviser
The technology will keep changing faster than anyone's advice about it. The incentives will not. An operator choosing an adviser should ask one question before any other, which is what this firm gains if I adopt. If the honest answer is a fee for the judgement and nothing else, the advice is at least pointed in your direction. That is the practice we chose to build, smaller than it could be and more useful because of it.
