Robotic process automation - understanding the legal issues

Quite simply, Robotic Process Automation (RPA) is software which mimics and replaces computer facing work which is or can be done by humans. Think of it is a “digital workforce”.

RPA is becoming popular and is seeing huge growth; particularly in organisations where there is significant manual processing of data. The trend towards RPA will undoubtedly continue. A 2016 study by Deloitte found that 11m jobs in the UK are at risk of automation.

The growth in the use of RPA, so why is it so popular?

When you understand some of the benefits of RPA it is easy to see why such growth is being predicted, these include:

• Cost savings – between a 40-80% saving compared to human workforce costs;

• Quick and easy to deploy - often taking between 8-12 weeks, with the advantage that the technology can be tweaked at short notice dependant on the task;
• 24 hour delivery - this “digital workforce” will deliver any time of the day or night with no constraints by shift or work patterns;

• Speed of processing - a digital worker can execute processes more quickly than a human;

• Improved accuracy - risk of human error is eliminated;

• Scalable technology;

• Improved access to management information.

Implementing RPA technology – the how to basics

Organisations implement RPA technology in two ways:

1. through a new contract with a supplier where it has been agreed upfront that the supplier will use RPA technology in delivering services to the customer. We refer this option as “managed service”; and
2. by acquiring some RPA licences from a vendor of RPA software to use internally. Often this is done initially as a proof of concept, and use is then increased/adjusted depending on the outcome of the proof of concept phase. We refer this option as “in-house option”.

Getting Started

Legal due diligence

Whether deploying RPA as part of a “managed service” or via an “in-house option” due diligence will be important. Some issues to be considered:

• what data will the robots have access to and has data security/data protection been considered;

• for critical processes, is there business continuity in place if the digital workforce is not able to operate (e.g. revert to manual processing)?;
• what is the worst case scenario and what mitigants are in place to avoid these;

• what commercial benefits will RPA generate and are they/can they be locked in contractually (i.e. will the business case be delivered?);

• are the tasks to be performed by the “robots” repeatable and can they be mapped;

• what is the people impact of the use of RPA technology: is there a risk of redundancy/TUPE for those currently doing the work, do roles need to be re-profiled (e.g. to focus on quality assurance/exceptions rather than manual processing);

• is the RPA use in a regulated sector, e.g financial services; if so, are the regulatory requirements applicable to that sector being complied with (e.g. SYSC 8 in the financial services sector); and

• will the ‘adopter’ be able to exit the RPA technology, without disrupting ongoing operations.

For those familiar with outsourcing and long term services arrangements, many considerations are not new or unique to RPA. In deploying any new technology within an organisation there will naturally, be a greater anxiety than over a technology that an organisation has used before. This will be particularly true where the use is as part of a “managed service” rather than via an “in-house option”, where you might just be dipping your toe in the water.

Contract Considerations

What do you need to think about in your contract for RPA technology?

When putting in place a contract related to RPA, the first thing to think about is are you buying a service (i.e. outputs) or are you buying the technology (primarily software) to use as required. If buying a service then the contract should look like a services arrangement (with defined outputs). However, if buying the technology then the contract will look similar to other software licences or SaaS arrangements.

When discussing the contractual arrangement for RPA, focus on:

• the rights to use the technology: how wide are those rights? This is a typical discussion in a software licensing regime. User caps and other use restrictions are the norm. It is less common in a “managed service” for a customer to be able to use some of the supplier’s tools. Will that be permitted;

• locking in the commercial benefits so productivity is guaranteed (particular to a “managed service”);

• ownership and ability to adjust the processes on an ongoing basis;

• availability of the robotic workforce (uptime), speed of processing, accuracy of processing and break/fix support (and related service levels and service credits);

• who owns the licence in the underlying RPA software: the customer or the service provider. This will be relevant in the case of an exit; (particular to a “managed service”)  the roll-out schedule for the robots and any success criteria attached to that (and any subsequent increased roll-out); and

• liability for errors. If looking at an “in-house option”, liability will likely be the same as a software licence i.e. a time limited warranty (compliance with spec) followed by a break/fix service. If, however, RPA is being supplied as part of a “managed service” a service provider is likely to take on a greater degree of risk and liability, discussions will focus on issues such as excluded losses, caps on liability and liability for systemic issues/repeat failures.

How does RPA technology impact existing contractual arrangements?

If you are only looking at using RPA software you will need to consider how it interacts with your existing operations, for example:

• do all employees have the necessary rights to use the software?

• can a third party supplier use your software or does it breach the third party licence terms?

• are user number restrictions or locations impacted at all by the digital workforce?