AI and Automation in Outsourcing

It is a rare outsourcing project these days which does not have automation or AI/machine learning as an important – if not key – component of it. In the BPO world in particular, the possibilities for the application of greater degrees of automation and associated step changes in both service improvement and cost reduction seem near endless, with cost reductions of 30% plus being far from uncommon. However, the implications for this headlong rush to automate may not yet be fully appreciated from a contractual perspective….

How Much Is Committed?

As noted above, many RFP responses will make aggressive/optimistic statements as to the degree to which automation and machine learning can be applied so as to streamline the Customer’s processes and so achieve cost reductions. However, how much of this is pure aspiration as opposed to commitment?

In many cases, some at least of the anticipated benefit of the application of AI will have been reflected in the pricing model; for example, if there is an FTE based or unitary pricing model, the numbers of FTE’s to be engaged in the services (assuming a steady volume) may show a ramped decline over the contract term, or the relevant unitary price may reduce to reflect the fact that the Service Provider anticipates being able to perform the services with progressively fewer numbers of service personnel.

However, if the Service Provider has dependencies upon the Customer in this regard (eg in terms of the Customer being willing to move to new processes which facilitate automation, or implementing new software tools), then these will need to be clearly stated in the contract, and a mechanism agreed to adjust or defer any price related changes in the event that the Customer does not then create the wider environment to allow an automation initiative to succeed.

Equally, for longer term contracts (which will typically be the case for outsource style engagements), it will likely not be possible to fully assess the potential advances of AI that will occur over the contract term; as impressive as technological change has been in the years leading us to where we are now, it is nonetheless a sobering thought that change will never again be as slow as it currently is…! Accordingly, the contract will need to create a framework for the application of initiatives that the parties have not yet thought about. Simple “agreements to agree” about things in future may not suffice, as the Service Provider will inevitably be focussed primarily on the business as usual delivery of the outsourced services. The parties may therefore want to consider alternative arrangements, such as the creation of dedicated “innovation funds” contributed to by both Customer and Service Provider, and with an associated governance regime to ensure appropriate attention is given to ensuring that the fund is then applied to AI initiatives in practice.

Who owns the Bots?

Traditionally, the discussions around IP ownership regarding software related tools would have led to ownership in the core code remaining with the licensor (be that the Service Provider or a third party), and such party then also owning any modifications made to such tools.

So far so good. However, when one looks at the bots (or – more accurately – the “taught versions” of the machine learning algorithms), one rapidly appreciates the value of the data schema which represent what the software has learned. If for example a pharma company has spent several months having its personnel work with a Service Provider to teach the particular software how that pharma company operates in a particular part of its operations, it is likely that such processes and data could be readily applied for the benefit of other organisations in the same sector (and so be of considerable value to the Service Provider). In some cases, however, such functions or processes may be so core as to what the Customer does that the Customer would not then want to see its competitive advantage being eroded by way of the Service Provider simply applying the data immediately for the benefit of its rivals.

The outsourcing agreement will therefore now need to deal specifically with the question of what rights each party will have in relation to the data which encapsulates what the software has “learned”, both during the contract term and thereafter.

Liability Regimes and Challenges

Historically, the assessment of what is “reasonable” in terms of liability caps in outsourcing agreements – following the principle of balancing out risk and reward – has been predicated on models of human failure. For example, in a BPO contract for the provision of finance and accounting services, there is an inherent risk that a human being will get something wrong in terms of missing a decimal place in a calculation, sending a document out to the wrong person, or simply missing something that he or she should have spotted.

However, whilst an automated service delivery model has many advantages (as the bots don’t need sleep or holidays, don’t get sick, don’t come in to work with hangovers or with distractions because of an argument that morning with their partner, etc), it can also have draw backs. Specifically, the software will not immediately know when it has made a mistake (as it will not yet have been taught what that mistake was!) and so may continue to make it, again and again, and potentially very quickly/multiple times. This in turn begs the question as to whether the approach we have historically adopted to the setting of liability caps in outsourcing deals should change, e.g so as to distinguish between the circumstances giving rise to loss, and setting different caps accordingly?

Costs of Personnel Impacts

In the past, outsourcing transactions have frequently raised the possibility of personnel impacts in terms of redundancies. Many such projects are predicated upon the Service Provider being able to make savings either by introducing efficiencies or moving services to lower cost geographies, and both such moves will usually involve personnel previously employed by the Customer or its incumbent suppliers no longer being required.

This hasn’t changed in the AI/automation driven world; it has however taken on new impetus. For first generation deals, the extent and speed with which workforce reductions can be made has been increased by virtue of the application of RPA solutions, which may in turn reduce the possibilities for the Service Provider to retrain and redeploy the inscope personnel. For second or third generation deals where efficiencies and labour arbitrage driven offshoring has already taken place, there may now be a further step change in terms of workforce reductions by reason of the introduction of improved RPA and AI solutions.

The cost impacts of this will need to be carefully considered. The Customer may be asked to bear the costs of redundancies for those who transfer across at the outset of the relevant deal, and so may now be asked to find a larger pot of transition related cash at the outset of the deal. Service Providers may also need to be wary about signing up to “mirror image” versions of indemnities regarding redundancy costs (ie to kick in upon the termination or expiry of the contract), as it may be more difficult for them to predict what kind of AI driven world may exist at that point in the future, and so what size of exposure it may be signing up to.

Termination and Transition

Being able to smoothly transition across to a replacement service provider is obviously a key concern for any Customer (and indeed will often be an explicit requirement of their regulators, as is the case with financial institutions in the EU, for example).

Traditionally, a significant element of this transition process would be the knowledge transfer workshops and engagements with the Service Provider’s personnel who had been engaged with the relevant services. However, in the AI world, there will be fewer such individuals to engage with, as their roles will have been replaced by the relevant bots/software. They will in turn not be able to “train” either the people or software solutions of the replacement supplier, leading to a potential gap in the ability of the Customer to transfer its outsourced operations.

This will clearly need some further advance planning and thinking in the context of each deal. For example, Customers may be wary about making over use of a proprietary AI solution of a particular Service Provider (which it may not then be able to continue to use beyond the end of the relevant outsourcing agreement), and may instead mandate the use of third party products, where the underlying licences will either be capable of assignment to the Customer or alternatively taken out in the Customer’s name from the outset.

Conclusion

AI is disrupting outsourcing just as it is disrupting many other areas of commerce and society. At the same time, lawyers and those involved in the contracting process need to understand the need that this presents to revisit the way that contracts address various issues, and to revise them accordingly