Does Artificial Intelligence (AI) matter?
“AI is probably the most important thing humanity has ever worked on. I think of it as something more profound than electricity or fire.”
—Sundar Pichai, Google CEO
Davos World Economic Forum, 24 Jan 2018
You have to have been living under a rock the last few years to have not caught on that artificial intelligence is making waves in many parts of our economy. In the last decade, computers have been trained to perform ever more complex tasks—becoming capable in a range of activities we once thought the exclusive domain of humans, from identifying people in a crowd, to driving cars in heavy traffic, to beating the best human players at chess, go and poker. Often, computers do these things better than humans. They nearly always do them more consistently, faster and for longer.
AI evangelists claim this technological revolution will create a new life of abundance and leisure. Doom-mongers believe it will take over all our jobs, and perhaps destroy the fabric of our society. Naysayers dismiss either position as idle speculation—something we won’t need to worry about for fifty years or more. The reality is probably somewhere in the middle. Seismic societal change is not yet here, and if or when it will happen is beyond the scope of this post. But let’s be clear—AI is happening, now, and with the outcomes that are possible, you probably want to be involved with it. Why? Benefits include significant cost savings, a reduced administrative burden, improved processes through reengineering, the rationalisation of technology solutions, reduced errors, improved productivity, enhanced data and reporting, improved (and more auditable) compliance and better customer engagement, as well as the ability to develop new products and revenue lines.
So It’s All Good News?
There are, of course, complicating factors. AI technology is built on a fusion of mathematics, data and computers so complex it can appear opaque to anyone outside of the developer world. Digital transformation often requires a very significant change programme, throwing up many challenges, including configuring the multitude of point solutions, platforms, tools, systems and other rapidly emerging technologies across a range of automation technologies, such as robotic process automation (RPA), machine learning, predictive analytics, optical character recognition (OCR), chatbots and natural language processing. Many of these solutions will need to be acquired from third parties rather than developed in-house, to be followed by significant coding and configuration to get the systems “production ready.” The impact of implementing AI with regard to your existing IT infrastructure also needs to be understood, including on software licences already in placegiven recent “indirect use” litigation in the enterprise resource planning (ERP) software space.
Any time you work with new technology, you need to learn to harness the benefits while minimizing the risks and downsides, as well as cutting through the sales hype. A key way to do that is to adopt best practices with structuring and negotiating your AI contracts.
So, how do you buy AI right?
Whether you are sourcing an AI technology solution to be deployed in your business, or contracting for outsourced services involving AI delivery, there are a number of key issues to consider:
- Preparation & Planning
Set clear objectives and requirements for the procurement, including strategic and/or tactical outcomes, which should align with the business’ automation strategy and business case. Equally important is bringing the right team together: change management experts, as well as business owners, IT, risk and compliance, procurement, legal and finance, and of course, HR. Doing so will assist with obtaining the buy-in needed from senior leadership and stakeholders across the enterprise. - Vendor & Product Selection
Allow sufficient time for the procurement (e.g., RFI, RFP, ITT) process and for contracting itself. This will enable the team to develop and validate business requirements, and to carefully assess the market, rather than rushing to buy the first solution seen. Assessment criteria should include a proof of capability (i.e., a comprehensive demonstration) before potentially moving on to proof of concept or pilot stages, as well as ensuring that the shortlisted products or solutions align with the internal business and use cases and that the technology requirements fit with internal constraints such as the availability (and type) of data. Client references should be taken up at this stage. - Other Service Providers
Apart from the technology vendor, there are a number of other key roles which, depending on in-house capability and availability of internal resource, may require the appointment of a third party, such as configuration and implementation, training, support and maintenance and change management. These work packages should also be bid competitively at the same time as the technology procurement. Much like other large software implementations such as ERP, a far greater proportion of the budget will be spent (at least initially) on configuration and implementation services rather than on licences. The technology vendor may have an ecosystem of certified implementation partners, or you may look to one of the Big 4 consultants or a niche firm with an automation focus. This is a hot area right now, so make sure you will have access to top-tier, experienced professionals. It may be also worth considering your incumbent business process and IT outsourcing providers to see if they have experience or if there is capability in-house. We are seeing a growing number of clients looking at adding automation scope to existing BPO contracts and renegotiating pricing and other terms, for example where an automation solution can be implemented in place of offshored BPO roles. - Pricing Model
The discussion around the pricing depends on the scope of the service, and where it sits in the value chain. As a starting point, expert professional services will typically command a service fee (whether it is calculated on a time and materials, day rate, lump sum or other basis), whereas digitised/commoditised work lends itself to a different approach – to date, the norm for RPA, for example, has been licensed-based pricing (e.g., a fee per installed robot, management server, development tool etc.) with an annual subscription or a one-time perpetual license fee, together with fees for maintenance and support. However, the market is starting to see a shift towards transaction-based pricing and even value-based pricing such as gainshare related to FTE savings and other risk/reward models. Whatever model, the pricing metrics need to be carefully understood and assessed, including the ability to scale across the enterprise, or to reduce the number of robots, for example, as business requirements change. - Contract Form
The selected vendor’s standard terms may not be fit for your purpose; however, be wary of providing your own standard software purchase terms, as they likely aren’t right for the transaction either. Depending on maturity, these technologies might be delivered on premise or via the cloud – cloud computing brings its own issues from a contracting (and in the financial services sector, regulatory) standpoint. When contracting for implementation services a different approach to that of a typical professional services or software development agreement will be needed – the implementation provider will no doubt be using an Agile methodology and the contract form used should fit that particular purpose. - Software
Remember that you are essentially buying some combination of software and services. The software maybe delivered on-premises or via the cloud, or through subscription to an automation platform. Contractual clauses covering important aspects of the ownership and licensing of the intellectual property rights, including who owns the IP in any modifications made (e.g., during customisation and configuration), will often need to be addressed, as well as indemnity protection in the case of claims for IP infringement by third parties. This is new technology; there will inevitably be teething problems, and potentially claims between competitors for patent infringement, hence the need for the buyer to be insulated from that risk. Third party escrow of the underlying code may also need to be arranged, especially where the technology is business critical and/or embedded within the buyer’s delivery infrastructure. And, as mentioned above, the manner in which the AI technology interfaces with the existing technology stack needs to be considered, not just operationally but also from a licensing perspective. - Data
Automation technologies and solutions depend on data. The contract should establish who owns the underlying data including the outputs. Where personal data is involved, then data protection and privacy laws and regulations will be relevant. This is likely to be the case in any Business to Consumer (B2C) context. And – post GDPR (i.e., from 25 May 2018) – there is a potential need for data privacy impact assessments (PIAs) early on and in any event prior to the start of the relevant processing operations. PIAs will be required in “high risk” scenarios, for example, where the processing of personal data is “systematic” and “large scale”, also potentially where profiling and automated decision-making is being carried out. Data security is another critical area to be addressed, especially where cloud automation services are deployed. - Scope of Services
Regardless of whether you are licensing a point solution with support and maintenance services, subscribing to a platform, undertaking a pilot, or committing to a large-scale automation project, it is important to ensure that the solution is carefully documented, including any required outcomes or other requirements. Translating promises made in the sales cycle into commitments that can be relied on contractually can be a challenge but is important to do. The contract might be for a licence or a service, or a blend of the two – whatever the scope should be clearly set out together with the applicable service levels and a description of the remedy available if these service levels are not met. Other service-related items to be locked down in the contract include the provision of knowledge transfer services (particularly important if you plan to run the service in-house post implementation) and exit support in case of an unforeseen termination. Where your business builds an AI solution on a third-party platform, there is a risk of lock-in because the ‘machine learning’ built up over a period of service may not be transferrable to an alternative third-party AI system. Options and remedies should be discussed at an early stage. - Regulatory Considerations
Space doesn’t permit a detailed review of the regulatory considerations likely to apply, especially to banks and financial services firms, such as the FCA’s outsourcing rules and cloud computing guidance; however an important consideration is that in many heavily regulated sectors additional controls may be required (both during the development stage and ongoing) and that, where the decision making process is effectively a “black box” (e.g., machine leaning rather than cognitive reasoning solutions), this can present a real problem since the regulator needs to be assured that there is an understanding as to how a decision about, for example, a loan application, was actually made. - Liability and Indemnity
Last, but by no means least, is the issue of liability and indemnity (and related contractual provisions such as warranties and representations, step-in rights, force majeure, insurance and the like, which all deal with apportionment). These are all relatively tried and tested; however, particularly in the area of AI, causation and loss are areas of contractual (and negligent) liability which will need to be given particular scrutiny and dealt with in the contract. For example, where an AI system makes autonomous decisions which have potential liability impacts, especially in the case of “mission critical” systems, the allocation of risk in the event of “bad” outcomes should be clearly stated.
Conclusion
AI is a new and fast-moving industry, with rapidly-changing capabilities and terminology, and evolving standards and regulation. In terms getting the right contract in place, customers need to be particularly rigorous and alert even where the project is kicking off in a relatively low key way with a proof of concept or pilot. Adopting a robust approach to contract negotiation, and to ongoing management, will ensure that the promises made by vendors in the sales cycle don’t vanish into thin air and the technology delivers the required outcomes.
Tim Wright, partner, and Antony Bott, special counsel, in Pillsbury’s Global Sourcing & Technology Transactions Practice look at some of the issues to be considered when procuring and sourcing AI software and solutions.