When AI meets BI: 5 red flags to watch for

If there is a Holy Grail to business success in 2021, it most certainly has something to do with the power of data. And if business intelligence wasn’t already the answer to C-suite prayers for insight and vision derived from massive amounts of data, then artificial intelligence would be.

Today, AI is widely seen as the enabler that BI has always needed to take it to next-level business value. But incorporating AI into your existing BI environment is not so simple.

And it can be precarious, too: AI can dramatically amplify any almost unnoticeable issue into a significantly larger — and negative — impact onto downstream processes. For example, if you can’t sing in tune but only play with a small karaoke machine at home, there is no risk. It’s not a big problem. But imagine yourself in a huge stadium with a multi-megawatt PA system.

With that amplification potential firmly in mind, organizations hoping to integrate AI into their BI solutions must be keenly aware of the red flags that can scuttle even the best-intentioned projects.

Major pitfalls to watch out for when integrating AI into BI include the following:

1. Misalignment with (or absence of) business use case

This should be the easiest pitfall to recognize — and the most common found among current AI implementations. As tempting as it may be to layer AI into your BI solution simply because your peers or competitors are doing so, the consequences can be dire. It may prove difficult to justify the ROI if you spend millions of dollars to automate a piece of work done by a single employee earning $60,000 per year. Here, the positive ROI does not look obvious.

When seeking input from business leaders about the potential viability of an AI-enabled BI, start the conversation with specific scenarios where AI’s scale and scope could potentially address well-defined gaps and yield a business value exceeding the estimated expense. If those gaps aren’t well-understood or the sufficient new value is not guaranteed, then it’s difficult to justify proceeding further.

2. Insufficient training data

Let’s assume that you have a feasible business case — what should you look out for next? Now, you need to make sure that you have enough data to train AI via a machine learning (ML) process. You may have tons of data, but is it enough to be used for AI training? That will depend on a specific use case. For example, when Thomson Reuters built a Text Research Collection in 2009 for news classification, clustering, and summarization, it required a huge amount of data — close to two million news articles.

If at this point you’re still wondering who can determine what the right training data is, and how much of it will be enough for the intended use case, then you’re facing your next red flag.

3. Missing AI teacher

If you have an outstanding data scientist on-staff, it does not guarantee that you already have an AI teacher. It’s one thing to be able to code in R or Python and build sophisticated analytical solutions, and quite another to identify the right data for AI training, to package it properly for the AI training, to continuously validate the output, and guide AI in its learning pathway.

An AI teacher is not just a data scientist – it’s a data scientist with a lot of patience to go through the incremental machine learning process, with a thorough understanding of the business context and the problem you’re trying to solve, and an acute awareness of the risk of introducing bias via the teaching process.

AI teachers are a special breed, and AI teaching is increasingly considered to be at the intersection of artificial intelligence, neuroscience, and psychology — and they may be hard to find at the moment. But AI does need a teacher: Like a big service dog, such as a Rottweiler, with the proper training it can be your best friend and helper, but without one it could become dangerous, even for the owner.

If you are lucky to get an AI teacher, you still have a couple of other concerns to consider.

4. Immature master data

Master data (MD), the core data that underpins the successful operation of the business, is critically important not only for AI, but for traditional BI as well. The more mature or well-defined that MD is, the better. And while BI can compensate for MD’s immaturity inside a BI solution via additional data engineering, the same cannot be done inside AI.

Of course, you can use AI to master your data, but that is a different use case, known as data preparation for BI and AI.

How can we tell so-called mature MD from immature MD? Consider the following:

1. The level of certainty in deduplication of MD Entities — it should be close to 100%
2. The level of relationship management:
   • Inside each MD entity class — for example, “Company_A-is-a-parent-of-Company_B”
   • Across MD entity classes — for example, “Company_A-supplies-Part_XYZ”
3. The level of consistency of categorizations, classifications, and taxonomies. If the marketing department uses a product classification that is different from the one used in finance, then these two must be properly — and explicitly — mapped to one another.

If you have mastered the above A-B-C of your MD and have successfully moved through the preceding three “red flag” check points, then you can attempt relatively simple use cases of enhancing BI with AI — the ones that use structured data.

If unstructured data, such as free-form text or any information without a pre-defined data model, must be involved in your AI implementation, then watch out for red flag #5.

5. Absence of a well-developed knowledge graph

What is a knowledge graph? Imagine all your MD implemented in a machine-readable format with all the definitions, classes, instances, relationships, and classifications, all interconnected and queryable. That would be a basic knowledge graph. Formally speaking, a knowledge graph includes an information model (at the class level) along with corresponding instances, qualified relationships (defined at the class level and implemented at the instance level), logical constraints, and behavioral rules.

If a knowledge graph is implemented using Semantic Web standards, then you can load it straight into AI, thereby significantly minimizing the AI teaching process described earlier. Another great feature of a knowledge graph is that it is limitlessly extensible in terms of the informational model, relationships, constraints, and so on. It is also easily mergeable with other knowledge graphs. If mature MD may be sufficient for AI implementations using only structured data, then a knowledge graph is a must for:

• AI solutions processing unstructured data — where the AI uses the knowledge graph to analyze the unstructured data in a similar way as structured data;
• AI storytelling solutions — where the analytical results are presented as a story or a narrative, not just tables or charts, thereby shifting BI from an on-screen visualization supporting the discussion at the table, to a party of this discussion; a cognitive support service, if you will.

While these potential pitfalls seem daunting at first, they are certainly less worrisome than the alternative. And they serve as a reminder of the best practice common to all successful AI implementations: up-front preparation.

AI can change BI from an insights-invoking tool to a respected participant in the actual decision-making process. It is a qualitative change — and it may be a highly worthwhile investment, as long as you know what to watch out for.

Igor Ikonnikov is a Research & Advisory Director in the Data & Analytics practice at Info-Tech Research Group. Igor has extensive experience in strategy formation and execution in the information management domain, including master data management, data governance, knowledge management, enterprise content management, big data, and analytics.