AI box-ticking must stop!

Updated: Jun 21

Without really understanding how or why, enterprise customers are convinced that they must specify an AI capability in just about any software system they’re choosing now – almost as though they worry they’ll be called to account if they fail to include it in their RFP.

It has echoes of the ‘No one ever got fired for buying IBM’ ad campaign from the 1990s, but here it’s more a case of the Emperor’s new clothes: companies are blindly specifying AI and bigging up its importance just because everyone else is.


Be careful what you wish for

We’re probably as guilty as anyone for promoting a platform that caters for AI. And, of course, if a requirement calls for it, we can absolutely provide fancy algorithms, machine learning, natural language processing (NLP), and the rest of it.


But it’s also incumbent on us as a software industry to select and use the appropriate technologies for a business solution, and not to promise more than can be delivered.


In time, smart automation and painstakingly-trained machine learning tools will open up all sorts of new opportunities for doing things more efficiently. But if our industry over-promises now, customers will continue to feel let down when AI’s accuracy isn’t immediately as precise, nor the results as exciting or as transformational, as they had been expecting.


Yet, still the requests come in – for cool chatbots or NLP plans. But rarely are these capabilities linked to a business need – something you just wouldn’t find in any other context.

Recent examples of non-outcome related requests include:

  1. The system will provide voice-to-data capabilities using AI.” (No mention of why, or of the scenarios in which this will help users.)

  2. “The system should leverage the latest in AI, e.g. to classify, structure and relate objects.” (Interpretation: ‘Please give us the latest AI stuff – here are some things we suppose it might do.’)

  3. “AI/ML should support the user in determining the complexity of a case and in selecting the appropriate workflow to manage the case.” (This assumes, for no apparent reason, that ‘AI/ML’ is the best way to achieve these automations.)

Changing the script

Put simply, companies are now making random requests for fancy python scripts rather than asking for the best solutions to their problems. And of course the temptation for vendors preparing their proposals is to make lofty claims about their AI roadmaps in response to this non-specific appetite for the technology.


And so the cycle becomes a downward spiral. The customer demands a specific technology or method that may not be the best solution; the vendor then implements this solution the way it has been demanded – and the customer is disappointed by the result. In the best-case scenario the customer loses faith in the vendor; in the worst case scenario the customer loses faith in ‘all of AI’, without ever really understanding it.


The point here is that, while we – and a lot of other vendors – can and should support using AI techniques to address specific business problems, we shouldn’t be proposing or agreeing to include AI or ML unless it’s quite clearly the best path to the delivering what the business needs.

Just as we wouldn’t use other tools or techniques that aren’t the best fit for any challenge at hand.


Horse for courses

Of course, when AI or machine learning does solve a real problem, the results can be fantastic. iPhone’s Face ID and Siri recommendations are transformational features because they save time, provide strong security, and help users to do what they want to do.


But people typically don’t go out looking for smartphones that ‘have AI’. All they care about is the improved experience it enables.


Indeed, demanding or promising AI for its own sake can be distracting. We’re really just talking about an algorithm or short fancy script which specifies a few parameters – a facility that’s cheap and easy enough to put anywhere now.


What it isn’t is a silver bullet that will guarantee an investment is ‘futureproof’. Seeing it as such sets false expectations.


Rather, RFPs should set out the business problem, leaving it to the software experts to determine the best way to solve it – taking an informed, ‘horses for courses’ approach.