Is it really AI? 17 thought-provoking techniques to find out

😕 The Pain Point

As we’ve been at pains to describe elsewhere, hype hurts AI. Our background is in the noisy legal AI vendor space — some 67 “AI” products in 11 verticals by one count in 2018. It’s no surprise most buyers of AI products and services are confused. They often don’t know:

What to ask in order to understand what to buy?

Dollop lashings of “Robot Lawyer” articles replete stock photo of gavel wielding android and it’s no wonder some vendors play fast and loose, whether deliberately or by omission, with their product claims.

This article provides 17 basic questions you can use to test an AI vendor (or expert’s) knowledge of AI and whether what they are selling / telling you is right for your need, or complete BS.

Save yourself some pain, and learn those lessons here.

🏥 But first, a health warning

This article is not meant to be exhaustive, nor demonstrate how to authoritatively benchmark one tool vs. another — hopefully, we can cover that in a later post! For now, these are indicative of the types of things should try to know about AI vendors to help you make the right decisions.

It’s meant to present the ideal when it comes to good vendors. By this, we mean good vendors in an ideal world. As a lot of vendors are new to the market — and the execution of such technologies in law relatively immature — very few vendors are good vendors across all measures.

Likewise, never start with the solution, AI or otherwise. Instead, begin by identifying the people, process and problem that needs solving. Once done, work forward from there to identify solutions to build / buy. If at that point AI seems relevant, get these questions ready!

📋 Five rules

To keep things organised we’ve grouped these questions into five core themes:

1. Fit: tied to the preceding point, do I need AI? Why? And is it even possible given my problem statement?
2. Delivery: who is building, training, curating and maintaining my shiny new AI (and at what / whose cost…)?
3. Compliance: auditability, integrity and explainability. We’ll explain these in due course (pun intended).
4. Tech Test: do you even AI? In other words, is this what it says it is?
5. ROI: show me the money saved, made or maintained by your AI.

We’ve also sort to explain why each question is important and the markers of good vs. bad vendors in terms of vendor responses.

🔥 Fit: a match made in heaven, or in hell?

01. Do we need AI to solve our problem? If so why?

Why ask? To validate the vendor has considered and understood your business challenge + whether and to what extent AI / their solution solves your actual problem vs. a presumed problem.

As we’ve covered separately, today’s AI is ANI — able to perform a single narrowly defined task — and therefore usually a point solution rather than an end-to-end solution in and of itself. Yes, it may come wrapped in other technologies — usually, workflow, automation and / or analytics (+ oftentimes search) to provide something close to an end-to-end solution, but the critical point is the AI bit won’t be the cure-all it’s sold to be.

Assuming you followed the above advice — identified the people, process and problem and worked with your stakeholders to generate solution ideas, of which AI is one of several — begin by asking the vendor this question. It reveals a lot!

✅ Good Vendor

• Invests time initially and throughout the engagement to ask questions to understand your business challenge.
• Answers with specifics.

❌ Bad Vendor

• Won’t spend time understanding the business challenge, instead jumps into a demo or generic slide deck.
• Answers generically, e.g. efficiency, accuracy, risk mitigation, digital transformation.

02. Do we have sufficient quantity and quality of data to use AI? If not, how do we get there?

✅ Good Vendor

• Pre-empts this question, coming forearmed to ask you to describe your dataset in terms of quantity and quality
• For example, if the tool extracts data points from contracts and your use case is how to extract provisions related to LIBOR in loan agreements, vendor will ask you:

To provide examples of the data points, and how you would like them extracted, i.e. do you want the full clause, a variable within the clause (e.g. a date or number) or a conclusion (e.g. LIBOR vs. EURIBOR).

To quantify the number of examples you have access to for each data point.

How variable each data point might be in language, structure or location within a document.

Whether the documents are in PDF and, if so, OCR’d (i.e. machine-readable) form.

To provide samples of the documents to understand and test whether they will be machine-readable and / or generally suitable to the solution’s techniques.

• If after the above the vendor believes you lack sufficient quantity / quality of data, vendor will explain and ideally work with you to design and implement a system (with or without technology, theirs or otherwise) to capture this data, e.g. recommending a friendly LPO expert in data tagging and clean-up to the extent you lack internal resources / time.

❌ Bad Vendor

• Won’t pre-empt this question.
• Dodges this question, answering in generic terms.
• Provides a very low number when asked how many examples of a data point might be necessary to train the system’s ability to identify that data point in documents sight unseen by that system. It is hard to give a concrete suggestion here as it depends on data and use case, but something like 1–5, or 5–10 is low and typically a stretch for most systems except the most basic of use cases to the extent it isn’t specifically designed and trained to your use case already.

03. Do you have domain expertise in our field?

Why ask? Although there are several common AI techniques used to solve thematically similar problems, their application and execution are not one size fits all and rarely “plug and play” for all but the most basic tasks. For this reason, it’s imperative the vendor understands, and ideally has experience in, your domain. Doing so will enable them to tailor techniques to the nuances of your business problem.

Without it, you end up buying clever but ultimately useless solutions. This is the difference between a tailored suit and a Small, Medium and Large offering where you are between sizes.

Often with AI projects (or indeed any technical undertaking) there is huge value in having someone who can bridge the gap between the domain problem and the technical problem. In other words, for a legal challenge this might be someone who is a lawyer, i.e. can talk lawyer with lawyers to understand their challenge, but also technical, i.e. can translate law to tech and vice versa. This skillset is rare, often undervalued or ignored entirely. Absence of it can disconnect the business problem from the technical challenge, solving neither.

✅ Good Vendor

• Able to identify, understand and talk about your domain.
• Able to identify and empathise with your domain-specific challenges.
• Ideally has someone who has experience working in or with your sector, or has completed projects for clients in the same or adjacent domains (e.g. law and finance).

❌ Bad Vendor

• Unable to talk intelligently about your domain, nor identify and empathise with your challenges and the “why” for your project.
• Glosses over differences in domain, falling back on AI generic wins instead.
• Lacks any credible / concrete experience in your domain with similar / adjacent clients, nor any staff in their network to bridge the gap between domain and technical expertise.

🚚 Delivery — how will we work together / with your solution?

04. What is your delivery model?

Why ask? Tied to the above, AI solutions vary greatly in their delivery.

Some are purely self-service, i.e. requiring no additional technical configuration / development. However, that may also mean you need to train the solution to your needs, e.g. by marking up example clauses if the system is designed to extract them from sight unseen documents.

Others are heavy on professional services, i.e. technical consulting and additional developer effort to calibrate, train and iterate a set of capabilities (rather than end-to-end user-configurable features) to solve your challenge.

Depending on your business challenge one or both approaches may be better.

Self-service is usually better if you have a limited time frame / budget and happy to trade-off usability and immediacy over and above a perfect fit to your use case, e.g. contract extraction tools that come pre-loaded with the ability to extract common M&A Isclauses without the solution requiring additional training. This might be useful for standard M&A due diligence review, but might not be suitable for all nuances of the particular transaction (i.e. DD of a biotech acquisition is different to DD of a timber company).

Professional services delivery is generally better if you have a longer timescale, a large budget and a need to deliver very specific results, e.g. an extraction tool to identify and classify granular data from a dataset, such as to augment the extraction and population of 100s of metadata fields in a contract management system. This might be the case for a law firm building a specific use case application to on-sell to clients, or a bank process improvement project.

✅ Good Vendor

• Is upfront about their delivery model, whether self-service, professional services or a blend and if a blend, what % of each.
• Is upfront about the prerequisites for professional services delivery, and has a well organised / communicated delivery plan and dedicated representative (i.e. a project manager) to coordinate the moving parts on both sides.
• Is able to answer the below Compliance questions about their self-service offering in sufficient detail for your users to feel comfortable trusting the solution to assist with their challenge.

❌ Bad Vendor

• Claims to be 100% self-service but struggles to explain specifically how the system would address the nuances of your business challenge (suggesting professional services would be necessary).
• Is reluctant or vague in demonstrating how to use the solution to solve your business challenge.
• Is unable to quantify (even as a range) the professional services required, usually because they can’t or don’t have the systems in place to properly scope and validate your challenge and in turn whether and to what extent their solution actually (vs hopefully) meets your needs.
• Unable to explain how their self-service training features work, i.e. how you can train the system to tailor it to your needs without developer support.

🦺 Compliance — do they / do we understand this solution should it fail

05. Who is training (or trained) the solution?

Why ask? Related to the last question is who trains the system? For instance, popular AI contract due diligence tools typically provide:

(a) Out of the Box / OOTB Extractors: machine learning models pre-trained by the vendor to identify and extract in a particular format-specific data points; and

(b) Customisable Extractors: blank machine learning models to be trained by you using your own data to your own needs in terms of what to extract and sometimes, in what format.

This distinction — essentially what can I do OOTB vs. not OOTB — is common to most AI solutions. It’s crucial to understand this as it will have a direct impact on fit and compliance.

Concerning fit do we have time, resource and understanding of the technology to train and maintain the system ourselves or are we happy to rely on the vendor to do so?

For compliance: how much control do we have over how the system is taught to meet our need and, if it isn’t us doing the training, do we understand with what dataset, how, by whom and why the vendor trained the system for us?

Failing to understand this can lead to misapplied efforts at best, or at worst an inability to correct course (and explain why it went wrong) should the solution fail.

✅ Good Vendor

• Clearly defines what dataset was used to train their OOTB features, who trained them (i.e. was it law students, junior lawyers, senior lawyers or developers), how they did that (including their quality control procedures), why they chose those methods.
• Can concretely articulate what you should train on (i.e. the right quantity and quality of dataset), who should train them, how you should train (i.e. do you select an entire sentence, individual words or phrases to train an AI extraction tool for DD… train / test / cross-validation splits etc) and why the foregoing matter.
• Has features that allow you to version control any self-trained models to enable sharing and / or maintain their integrity.
• Is upfront about the solution needing training in multiple languages even if the techniques are themselves “agnostic”, e.g. a solution trained to find English language governing law clauses won’t find Spanish language governing law clauses for the simple fact the patterns in syntax are entirely different.

❌ Bad Vendor

• Can’t articulate in meaningful detail the what, who, how and why of training concerning their OOTB features.
• Can’t articulate the what, who, how and why of doing your own training
• Can’t offer sensible ways to version control or share your own models.
• Unable to provide anything resembling thorough documentation or best practices concerning these items.
• Is vague or misleads by omission when asked about language compatibility.

06. Do you have any human(s) in the loop?

Why ask? Unfortunately, a lot of AI tools adopt “Wizard of Oz” techniques.

This is nothing new in technology and refers to the iconic scene in the Wizard of Oz when Dorothy, the Scarecrow, the Lion and the Tin Man finally get to meet Oz the Great and Powerful Wizard only to discover he is an elderly magician operating machinery behind the curtain to give the impression of wizardly powers when he, in fact, possess none.

It’s very common in consumer “AI” apps, including a lot of apps that claim AI to verify identities or expense receipts. Often those tasks are completed by a human in a low-cost centre, sometimes with or without technology. Sometimes this is disclosed, sometimes not.

Some legal AI vendors do this. Sadly not all of them admit to this. Naturally, this raises significant issues concerning client confidentiality and data privacy!

✅ Good Vendor

• Is a Good Vendor concerning the preceding questions concerning the system’s training mechanism.
• Is upfront about any human in the loop on the vendor side, e.g. a legal reviewer employed by the vendor who reviews the solution’s machine-generated output and, if necessary, amends it, before returning it to the end-user.
• To the extent a vendor side human in the loop features, has LPO like safeguards and controls to protect confidentiality and data security and / or offers a version of the product without a human in the loop on the vendor side.

❌ Bad Vendor

• Can’t disclose any vendor side human in the loop at all, or unless asked or discovered.
• Vendor side human in the loop solutions are usually detectable if identical tasks seem to take wildly varying times to complete, in particular to the extent the completion times differ depending on the time of day (e.g. before 9:30am and after 5:30pm) / day of the week (e.g. weekends) in the vendor’s place of business.

07. Is the system interpretable and auditable?

Why ask? The best AI solutions should be interpretable. By this we mean:

(a) transparent, can we answer: “how does it work?

(b) explainable, can we answer: “why did it do that?”

Continuing the previous theme, if you can understand the what, who, how and why with regards a system’s training (and decision making) then the system is more transparent.

Knowing that, plus auditing features to track those metrics, puts you in a better position to explain results. Hopefully, this is obvious, but the ability to explain results will help you train (depending on its delivery model) the system more effectively.

Most importantly explainability is critical to the extent the system is responsible in whole or in part for decision making or the data for decisions. Without this, should such decisions come under court or regulatory scrutiny, failure to justify the approach taken in building the system or inability to defend it could be disastrous!

PWC has produced an excellent report (available here) examining these concerns in more detail — well worth a read as a follow-up to this guide.

✅ Good Vendor

• Is a Good Vendor concerning the preceding questions concerning the system’s training mechanism.
• Includes audit trail functionality to track the what, who, how and why with regards a system’s training.
• Provides version control over models and ability to roll back and forth between them.

❌ Bad Vendor

• Is a Bad Vendor concerning the preceding questions concerning the system’s training mechanism.
• Does not include, nor has thought about any audit trail functionality.
• Does not provide version control over models.

08. Who is liable if your solution fails?

Why ask? This is a grey area and a lawyer favourite!

Market / legal practice has not settled this issue, whether by law, regulation or contracting terms. As such, it is a question to be aware of and consider against your business case.

Is the solution replacing or significantly assisting a critical function? What is the cost of that solution failing? Is the failure rate better or worse vs. the current solution? Are there are vendor side humans in the loop?

Ask these questions of yourself, and weigh them up against responses to similar questions asked of the vendor.

✅ Good Vendor

• Understands why this is a concern in general and in the context of your business need.
• Able to talk constructively and provides comfort through built-in failsafes to minimise the risk and / or mitigate its consequences, e.g. visible and adjustable thresholds for precision, recall and confidence (where appropriate).
• Provides detailed best practice guides and training to the users to ensure any shortcomings or blind spots are known and ideally avoided.

❌ Bad Vendor

• Defensive and / or unwilling to admit any risk.
• Unable to talk constructively about safeguards, nor offers any.
• Training and guidance are non-existent or patchy, leaving users unclear what the system can and cannot do and more importantly the what they can do to avoid any pitfalls.

09. Where is our data stored? Do you share / own our training?

Why ask? This issue is twofold.

First, where is the application and its data stored? On-premise installations are expensive to set-up, support and update. Cloud distributions scale, don’t require you to buy servers or staff to maintain them and are easily updated but may be impossible if a client prohibits the use of cloud services, which is typically the default request for most legal clients.

Second, does the vendor leverage your training to offer and / or improve it’s own “pre-trained” features? In the consumer space, this is commonplace via click-through Ts&Cs. This is how your Netflix learns to predict what films you like but also anyone else similar to you, i.e. by combining data about similar behaviours.

For legal work, this goes against client confidentiality, ethics and data privacy concerns. However, some legal AI vendors also admit — upfront, or after probing — using user data (presumably anonymised in some way) to improve their own OOTB pre-trained models, and in some cases, making those available to other clients.

For most legal users sharing anything resembling client data with third parties is a massive no. Watch out for this one, it could put you in breach of your organisation obligations!

✅ Good Vendor

• Talks clearly about where their solution lives, either your servers, theirs or a third-party cloud service provider.
• If cloud, uses trusted third party providers and / or has private cloud option (i.e. no connection to the public internet, access limited to the law firm and explicitly excepted third parties).
• Upfront about use, sharing and ownership of any training you provide into the system and its outcomes.
• Most vendors own the tooling you use to train the system (unless they build it custom for you) and have the users own the training and its outputs.

❌ Bad Vendor

• Struggles to explain differences between hosting options.
• Unclear or evasive regarding the ownership of data and outputs from the system and / or whether they collect that data to improve or develop products to sell to your competitors!

🤖 Tech test — do you even AI? (40% don’t)

10. Why did you choose AI for this product?

Why ask? This is a lot like the very first question about the vendor understanding whether or not their product fits your need. Naturally, they ought to have gone through a similar exercise when designing their solution, i.e. identified the people, process and problem they sought to solve, tested assumptions and assessed all solutions… rather than simply saying let’s solve X with Y.

In this regard, AI is a lot like blockchain — often at worst a solution looking for a non-existent problem, or at best over-complicating something best solved by simpler solutions.

✅ Good Vendor

• Has considered this question at the outset and able to articulate their reasons why theirs is an AI solution and probably also which parts aren’t AI and why (as AI is rarely an end to end solution in and of itself).
• Able to describe alternative approaches considered and, ideally with some form of evidence, explain why their approach is significantly better for your use case.

❌ Bad Vendor

• Has not thought this through, and very likely will have been narrowly focused on cleverness over utility.
• Can’t / won’t identify and explain alternative solutions nor justify their approach over others.

11. Can you explain how your advertised machine / deep / supervised / unsupervised learning works in general and for my use case?

Why ask? The plethora of technical terms littered throughout any discussion of AI make it easy for vendors to obfuscate the how of their product.

As is hopefully clear from the preceding, this is a blocker to your understanding of its workings, your use of it, its fit to your need, its interpretability and so on.

It is also a basic test of whether the solution includes any AI. Shockingly a 2019 survey of European AI start-ups identified that only 40% actually use AI. As we’ve noted elsewhere this is partly because AI is a suitcase phrase open to manipulation!

✅ Good Vendor

• Can explain machine learning and deep learning, in particular that the latter is a subset of the former and is concerned with multi-layered neural networks and in what circumstances which technique is more suitable.
• Can distinguish between supervised and unsupervised learning, in particular that unsupervised learning does not mean “it just learns stuff without training OOTB”.
• Can articulate why supervised and unsupervised learning should not be considered in direct competition with other, rather each has a distinct function albeit often are used together in an end-to-end solution. For instance, unsupervised techniques may be used to group data before a supervised process is used to classify items within groups.
• Can map the above concepts to specific feature present in their solution, and more importantly use cases for those features aligned to your needs.

❌ Bad Vendor

• Does not appreciate or articulate what AI actually means in any real sense.
• Struggles / is unable to define any of these terms.
• Provides blanket statements about deep learning being superior to anything else (this is often not the case, both in general and often simply because the use case is wrong).
• Claims unsupervised learning is superior to supervised learning; confuses unsupervised learning with pre-trained supervised learning led features… sadly this is super common, and often used to discredit Good Vendors.
• Fails to identify which parts of their solution use which techniques and how any of it would solve your need.

12. Do you use rules and / or search based techniques? If so, when, where, how and why?

Why ask? As we’ve covered elsewhere (see our 101 on Search vs. Rules vs. ML), most “AI” products, legal AI or otherwise, are a cocktail of techniques. Vendors using multiple techniques, or using more of one kind than another, should not be discounted.

But then isn’t the question “what’s the best combination?” Well sort of, but the better question is “what’s the best combination for my use case?” Better still, which techniques should we use, when, where, how and why?

You need to be specific in your questions, and vendors precise in their answers. This is because it’s horses for courses.

Certain techniques are better suited to particular tasks, or where several techniques can all achieve a similar outcome one may be preferred over others to the extent it superior in means, e.g. a rules based solution to detect a boilerplate clause is computationally cheaper to run vs. a machine learning solution but sub-optimal for non-boilerplate language.

Vendors who go deep on detail in answer to the very first question in this article (Do we need AI to solve our problem?) should perform well here. Such vendors will be open at explaining which techniques they use, but most importantly which best fit your need. Understanding this will help you assess fit and differentiate products within a noisy market.

✅ Good Vendor

• Able to explain each technique.
• Open and happy to talk about which techniques their product employs.
• Precisely and incisively identifies which features best fit what aspects of your business challenge, the extent to which gaps remain and ideally alternative solutions — whether theirs or someone else’s.

❌ Bad Vendor

• Unaware / unable to explain each technique.
• Evasive and unable to demonstrate which techniques are used where in their product.
• Brushes off the question with general statements about the superiority or machine or deep learning techniques.
• Claims “everything is AI”

13. What are the precision, recall and F1 scores for your product?

Why ask? Buyers typically ask in general “how accurate is your product?” or slightly more specifically “how accurate is your product at doing X?”. Neither is the right question from a machine learning perspective.

Asking about the system’s precision, recall and F1 scores and how long and with how much and what type of data was required to achieve those figures are better questions to ask.

However, accuracy vs. precision vs. recall vs. F1 scores are a detailed subject — see here for our 101.

Once you’ve read up on these terms, you’ll appreciate how little vendors talk in these terms despite them being fundamental measures for machine learning.

Partly this is to manage expectations, but often because vendors haven’t rigorously tested their systems against such measures. Sometimes that’s because they use no machine learning at all. Again, not a write-off if they don’t (depending on your use case), but it does raise a trust issue!

We often ask this question, even if we don’t really care about the answer. A lot of the time the reaction from the vendor says it all!

✅ Good Vendor

• Understand the question, the metrics involved and why and how these matter to machine learning systems.
• Understand how precision and recall applies to your use case. If you’ve read our post on these metrics you’ll understand that sometimes you want the system to be over inclusive (higher recall and less precise). For example, a system to detect cancer will have higher recall and lower precision because the cost of too many false diagnoses (aka false positives) is outweighed by the cost of missing a true diagnosis (aka a true positive).

❌ Bad Vendor

• Is confused by the question or simply replies a single % number, usually in the 90s, e.g. “98% accurate”.
• Cannot explain these metrics.
• Cannot apply these metrics to your use case and identify which matter more to you.
• Sometimes this may be simply because the vendor representative is not technical enough. If you suspect that, ask them to arrange a follow-up with their technical team. If that team also fails, then there might not be a robust machine learning system (and / or team — of that, see below) behind the solution. Again, not a deal breaker if it solves your need but does raise a red flag re trust and transparency!

14. What qualifications does your technical team possess?

Why ask? As is neatly summarised in this excellent Law Society article by Rafie Faruq, “machine learning is becoming more commoditised and easier to understand. Nonetheless, it is a mathematical discipline rooted in fields such as linear algebra, statistics and optimisation. Not understanding the equations that underpin these models means providers won’t be able to build quality machine learning products. It is therefore best to check whether the AI provider has real expertise in the firm — typically this means founders or employees that have degrees in machine learning, and advisors who are professor level in machine learning.”

✅ Good Vendor

• Has strong technical team with backgrounds in machine learning, data science and mathematics.
• Team is able and open to talking about technical topics, and ideally is good at explaining them, their impact / fit and prerequisites to non-technical business people.

❌ Bad Vendor

• Has no / very little technical expertise / individuals in these areas.
• Closed to talking about technical detail and struggles to explain in plain English how these relate to the business case.

💸 ROI — how much bang do I get for my buck?

15. Are clients in production or POC with this solution? If only the latter, why?

Why ask? During the heady hype-filled years of 2016–2018, it seemed every week a legal AI vendor announced a new “deal” with a law firm or large organisation. Naturally, this created serious FOMO (fear of missing out), an arms race ensued and this trend increased. But… how many had a system in production, that is solving a front line business problem vs. an internal experiment or “proof of concept” (aka “POC”)?

The answer is often hard to find. Vendors hate disclosing this data, often because fewer than suggested customers use their system in production. Often if they do it’s on a limited scale or ad hoc. This isn’t always a fault of the software, but a change management / adoption issue for the buyer.

Buyers likewise want to be seen to “have some AI” but don’t wish to share, usually because they aren’t doing as much with it as they’d hope (and as soon) but also because it’s often seen as their competitive edge.

Answering this question matters because it should tell you whether the solution is mature, adoptable and actually does what it says on the tin. It should also ideally shed some light on how you might pre-empt and stay ahead of adoption and change management issues, for instance if the vendor can advise you on lessons learnt by other clients or their own deployments.

If the vendor can evidence referenceable clients using their solution in production then great. If not, tread with caution unless you are happy to trial a potentially immature solution (and / or the vendor’s outsourced quality assurance and testing hub — this is unfortunately not uncommon).

✅ Good Vendor

• Has reference clients using the solution in production that they are willing to advertise.
• Is willing to introduce you to those reference clients without unreasonable delay.
• Has a willingness to talk about lessons learnt and design / provide an adoption / change management plan tailored to your business need.

❌ Bad Vendor

• Has no reference clients using the solution in production or, to the extent they claim them, is unable or unwilling to introduce them to you.
• Reluctant to discuss adoption and change management issues, potentially evidencing lack of confidence in their offering.

16. What ROI are clients seeing? How do they / did you measure this?

Why ask? Related to the above, POCs don’t generate ROI other than to validate or eliminate a potential solution (or perhaps to iterate it towards success).

Solutions in (or very likely to be in) production generating value, reducing cost and / or enabling new opportunities should be a given, or why else promote the solution (other than to make a fast buck or to test the market)? Granted if the company is new, production clients will take time — so bear that in mind and weigh it up in the context of your discussion and need.

To the extent a vendor can demonstrate an ROI, they should be able to explain how it was measured and against what, e.g. against the business as usual practice, a competitor product (hard / impossible for a vendor to do the latter). Without this you are back to the realms of incomplete data and inviting a misunderstanding that might jeopardise your project and by extension your own reputation within your organisation!

✅ Good Vendor

• Has quantitative and qualitative metrics regarding the ROI and how that was measured, e.g. a simple example might be a side by side comparison of their solution vs. a client’s business as usual prior solution, demonstrating time saved, costs reduced or profits increased etc.
• Able to explain the methodology and why it was chosen.

❌ Bad Vendor

• Is evasive when asked about ROI, cannot provide any metrics or case studies to evidence any measurement of their solution’s value vs. alternative options let alone articulate any method.
• Unfortunately few vendors avoid these shortcomings, but in part this is because the market remains relatively immature and customers are reluctant to publish even anonymised data with regard to their own ROI exercises.

17. How much training / time was required for that ROI?.

Why ask? As described above, depending on the delivery style (self service vs. professional services) and features (OOTB vs. non-OOTB pre-trained features) you may need to invest more or less time and money to solve your need.

Whomever is training, it’s imperative you understand its quantum. If it’s you, do you have the resources and expertise internally to train the system? If not, where, when and can you even obtain that resource? If you’re not training the system, how long did it take the vendor to do so? Bear in mind the aforementioned issues to be addressed regarding the domain expertise quality and assurance processes.

Understanding these items will identify whether your problem is one solvable by AI within the confines of your resource, time and budget constraints. It’s also another good measure of how seriously the vendor understands the importance of this aspect to your own success. Likewise whether they can demonstrate with evidence any claims in this regard.

The more your goals are made known and aligned with the vendor, the better chance you will both succeed together.

Unfortunately vendors often forget you have to prove ROI and by extension struggle to answer this question, usually because they don’t (and sometimes can’t) collect the necessary data.

✅ Good Vendor

• Can provide concrete metrics with example, ideally from clients and / or their own internal benchmarking — preferably being able to explain the methodology as noted above.

❌ Bad Vendor

• Cannot provide any metrics or is able only to provide cursory data in this regard and / or unable to detail the method for such measurement.

⚡Conclusion — start, but don’t end here

Forewarned is forearmed! Don’t believe the hype. A little learning goes a long way. This guide will prove helpful should you be in the market for legal AI.

The more you can read around and understand these concerns, and in general, how AI tools work under the hood (you don’t need to code, theory = sufficient) will massively improve your AI hype detector. In doing so you will save yourself a lot of wasted efforts and build or buy what you need, not what somebody else prescribes!

Likewise, a nice way to think about what we today call AI is to think about its purpose. In most / all use cases, it’s about supplementing not supplanting humans. In the legal context, this is making lawyers better not bots.

Framed this way against the limits of today’s AI (which are hopefully clearer from the above), you will realise today’s AI (and its use cases) are really all about IA: intelligence augmentation.

This will help you manage your own, and your stakeholders’, expectations, but will also help find the best vendor. The best vendors understand AI today is really about IA, i.e. making people better at their job. One day that might change, but that day is not now.

Lastly, when dealing with AI vendors observe the Goldilocks Rule — make sure the porridge is neither too hot nor too cold when it comes to their claims and responses!

If you have any questions or disagree with the above let us know!

🚨 Post Credits Scene: other red flags

Because we like superhero movies

Any / all of the below. Unfortunately, these have been — and continue to be — somewhat unavoidable, especially with regard to hyperbolic language.

Genuine AI marketing copy

Robot lawyers

That’s because explaining how AI systems work is not especially sexy… at least from a marketing perspective.

Special mention also goes to claims re X% accuracy or Y% time / cost saving. Rarely, if ever, are these claims backed up with properly benchmarked data (hence the detail above re these questions).

But at the cost of repeating ourselves, this is in part because vendors don’t often complete this type of exercise. If they haven’t done so, neither will it be easy for them to obtain equivalent ROI data from clients to the extent their clients have done such testing. This is usually due to clients perceiving their use of AI as their competitive advantage, which in legal is a bit of a none point as everyone is using the same handful of tools.

That said, these aren’t insurmountable obstacles, neither do they excuse lazy language and a failure to try harder and respect buyer intelligence.

Educate don’t obfuscate!

*This one is a joke. It’s the corporate slogan of the fictional Tyrell Corporation (from the movie Blade Runner). The Tyrell Corporation manufactures bio-engineered artificial humans, known as “replicants”.

Originally published at lawtomated.