Managing Data

Managing Data – Software Services And AI Legal

Managing data is an essential part of the operation of a growth business. It’s a cliché often bandied around that today data is more valuable than oil. But as with oil, it’s only how the resource is used that defines its value. Whereas oil can be relied upon to produce energy in all circumstances, data cannot be relied upon to produce useful insights at all times. Therefore, the means and purpose by which it is processed becomes all the more important. Given its potential, it comes as no surprise that initiatives, public and private, for managing data more effectively are commonplace. The legal sphere attempting to regulate this burst of energy gets more complex by the day. Here is our introduction to some general issues you may face when managing data for profit, or to simply improve the running of your business.

GDPR and Brexit

Before GDPR came into force in all EU member states on 25 May 2018, the ICO commissioner stated in the ICO’s March 2017 paper, Big data, artificial intelligence, machine learning and data protection, that ‘it’s clear that the use of big data has implications for privacy, data protection and the associated rights of individuals… In addition to being transparent, organisations… need to be more accountable for what they do with personal data’.

At the end of the Brexit transition period (January 1st 2021), the GDPR and parts of the Data Protection Act 2018 became part of a new body of retained EU law. Essentially replicating the old regime in the UK. Data protection legislation in the UK is now comprised of the UK GDPR and the DPA 2018. From a UK perspective the GDPR operating in the EU will be known as the EU GDPR.

As the EU GDPR will continue to have extra-territorial effect (Article 3, EU GDPR) it may continue to apply to UK organisations who act as controllers or processors and have an establishment in the EU, or who offer goods or services to data subjects in the EU; or monitor their behaviour, as far as their behaviour takes place within the EU. UK businesses could therefore find themselves subject to parallel data protection regulatory regimes under both the UK GDPR and the EU GDPR.

Are you managing data as a processor or controller?

If offering a service, for example a software platform that allows companies to process personal data, then it would often be prudent to ensure you are defined as a data processor, and not a data controller, for data protection purposes. This is because, as opposed to data controllers who bear primary responsibility for the personal data involved, data processors have less obligations under data protection laws. Processers are essentially processing data under the instructions of the data controller. Whilst a data controller determines ‘the purposes and means’ of processing the personal data (Article 4(7), UK GDPR). A helpful way of thinking about it is that a data controller has direct duties to data subjects whereas a data processor only has duties to the data controller.

The distinction between controller and processor in an AI context was first considered in the ICO’s July 2017 decision on an agreement between the Royal Free Hospital and Google DeepMind. Under the agreement DeepMind used the UK’s standard publicly available acute kidney injury algorithm to process personal data of 1.6 million patients. The ICO ruled that the hospital had failed to comply with data protection law and was ordered to perform an audit on the system. The hospital’s law firm, Linklaters, concluded in the hospital’s audit report, Audit of the acute kidney injury detection system known as Streams, that DeepMind had been properly characterised as a data processor. This was because Streams ‘does not use complex artificial intelligence or machine learning to determine when a patient is at risk of acute kidney injury. Instead, it uses a simple algorithm mandated by the NHS’. It was therefore the lack of complexity involved in the ‘means’ of processing the personal data which meant that DeepMind were considered to be a data processor. A complex algorithm would have constituted a level of agency on DeepMind’s part which would have rendered their processing that of a data controller. It was deemed, however, that their services were simple enough to be doing nothing more than following the hospital’s instructions. This grey area should be of concern to anyone planning to use AI to analyse data. Make an algorithm too complex and you may take on the liability of a data controller and hence liability towards data subjects.


Managing data to make it anonymous would fall under UK data protection laws. This is because the purpose with which the personal data was originally collected needs to be aligned with the purpose that it is later anonymised for. There are certain circumstances in which collecting personal data to begin with is not necessary and, if still useful, highly desirable for businesses wishing to process the data as they wish. If the data is originally collected in an anonymous format, then UK GDPR no longer applies. As GDPR states at recital 26, ‘the principles of data protection should… not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable’.

In an ICO report, Anonymisation: managing data protection risk code of practice, the ICO lists anonymisation as one of its six key recommendations for AI. It states ‘organisations should carefully consider whether the big data analytics to be undertaken actually requires the processing of personal data. Often, this will not be the case; in such circumstances organisations should use appropriate techniques to anonymise the personal data in the data sets before analysis’.

Profiling and automated decision making

AI’s ability to uncover hidden links in data about individuals and to predict individuals’ preferences can bring it within the GDPR’s regime for profiling and automated decision making. Article 22(1) states that ‘a data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly affects him or her’.

However, this is qualified by article 22(2) which states that this right does not apply to a decision that ‘(a) is necessary for entering into or performance of a contract between data subject and data controller; (b) is authorised by… law to which the controller is subject and which also lays down suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests; or (c) is based on the data subject’s explicit consent’.

This is further qualified: ‘in the cases referred to in points (a) and (c)…, the data controller shall implement suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests, (including) at least the right to obtain human intervention on the part of the controller, to express his or her point of view or contest the decision’. Having automated decision making within software performing data analysis can therefore introduce new obligations. Such obligations often being onerous for a data controller. This can include it being necessary to perform a Data Protection Impact Assessment or getting explicit consent from data subjects.

Other suggested compliance mechanisms

The ICO makes five recommendations for using AI to analyse data:

  • Privacy notices.
  • Data protection impact assessments – embed a privacy impact assessment framework into data processing activities to help identify privacy risks and assess the necessity and proportionality of a given project.
  • Privacy by design – implementing technical and organisational measures to address matters including data security, data minimisation and data segregation.
  • Ethical principles.
  • Auditable machine learning algorithms.

Treasure trove

Finding new and innovative ways for managing data is a treasure trove many wish to unlock. It is important to be wary of the growing regulatory landscape underpinning the sector. The world was shocked by the accusations made against Cambridge Analytica and making sure you display compliance is a must for maintaining a good reputation and attracting clients. With Brexit comes the potential for the complexity inherent in potentially diverging legal regimes. Being up to date on the development of the Privacy and Electronics Communications Regulations (PECR) will also be useful. Read our blog on PECR here.

EM law specialises in technology and data protection law. Get in touch if you need advice on data protection law or if you have any questions on the above.

Lease Advice

Lease Advice – Keeping The Legal Aspects Simple

Lease advice is one of the most common requirements for businesses who have got beyond the start-up phase. But if you are wary of lawyers making things complicated, you are not alone. Even in-house lawyers get upset when they hire external lawyers who make things complicated. As someone who has been both a partner in a law firm and in-house at one of the top property companies in Europe, I can assure you that lease advice can be kept simple. However, it is only kept simple when the lawyer deeply understands what is going on. A lease agreement (should) manage many risks relating to the building and the relationship between the landlord and the tenant. It is one of the most unregulated areas of law, so if something goes wrong it is unlikely that the law will impose any “fairness.” What we are actually doing is to make a complex thing simple. This also protects your relationship with the landlord and the managing agents. We do this in a number of ways:

We get involved early with our lease advice

This way we can most easily influence how the legal risks are divided up. If you have agreed detailed terms of the deal without taking legal advice you may find that you need to re-negotiate it and by then people dig in their heels and everything is much more time consuming.

We spend time with you

There are many property risks that we will manage on your behalf. We find simple solutions because we make sure we understand what you are doing, how you want things to be done and what you need to achieve.

I know there are many people who say they understand entrepreneurs but if you haven’t lived it, it is just not true. Some of our consultants also operate their own businesses and have been entrepreneurs.

Avoid Meaningless Arguments

Some people think they are effective but in fact they are just argumentative. In fact, that happens because (i) the lawyers are thinking of their own ego and overlook that their sole aim should actually be to help the client (ii) they don’t understand the actual financial cost of what they are talking about (iii) they don’t really understand the document so they are afraid to make any changes (iv) they never bothered to ask your opinion! We are interested in what you are doing and why. It helps us to understand what you need and what you don’t need. That means we can avoid meaningless arguments and we can solve the issues that do matter and tailor our lease advice without damaging your business relationships.

We understand the entire lifecycle of the lease

When the lease is signed, there are many more steps left: (i) the contracts to fit-out the shop or office (possibly with structural changes to the building), (ii) possibly you need to install cabling in a technical fit-out, (iii) supply and distribution agreements for your stock, (iv) marketing (v) hiring staff (vi) security (vii) managing the exit or expansion of the lease to ensure that you get a clean break and do not overpay. The lease of your property is not just an academic exercise but it affects the entire lifecycle of everything in your business. We understand all this and that’s why we can ensure the lease is not only simple but also thorough and avoids any uncertainty as you go through all these steps.

And most of all…

We are interested to learn about you. We keep learning and stay flexible. We do not operate a rigid system that you have to fit into. We will adapt to whatever you need.

And to give you peace of mind with our lease advice…

Because we want to give you a great service without causing anxiety, we will always offer you a reasonable fixed fee for lease advice so that you can control the costs.

Contact me, James Williamson, for lease advice or any other commercial property law advice here.

Systems Integration Contracts

Systems Integration Contracts: Co-op v IBM

Systems integration contracts govern the relationship between the parties involved in an IT implementation project. Such a contract can make for a complicated relationship and a messy dispute, as seen in CIS General Insurance v IBM [2021] EWHC 347. Few of these kinds of projects ever see their day in court, arguably due to inherent complexities and the expense of their unpicking. This case concerned the implementation by IBM of a new IT solution for Co-op’s insurance business. The agreement was supposed to deliver the system by December 2017 and used an Agile methodology (read our blog).

Success with system integration contracts often relies upon customer co-operation and participation as much as the supplier’s delivery. The simple question of defining what a customer wants from the outset can be a challenge when creating bespoke software. A number of alternative contractual and management solutions (Agile for example) have developed in an attempt to match this complexity. In short, systems integration contracts need to be meticulously thought through and understood. IBM’s failure to use relief mechanisms under its agreement with Co-op left them with few legs to stand on when their subcontractor failed to deliver, leading to an award of £15.8 million in damages to Co-op.

Customer’s requirements

In systems integration contracts, the purpose of a customer’s requirements section is to set out clearly and comprehensively all the functionality that the customer requires from the system. This is about letting the supplier know exactly what the project needs to achieve - which can be difficult and so customers often seek help from third parties. Consultants can be used to investigate the various interest groups within the customer’s company to discern exactly what is needed and then to write up the requirement’s document for the customer. Consultants can then also be instructed to undertake market research with a view to suggesting potential suppliers.


Once a customer’s requirements are known, it is then the supplier’s job to specify exactly how those requirement’s will be achieved. This means a more technical outlining often called a ‘specification’. The customer’s requirements therefore represent the customer’s interests and the specification represents the supplier’s abilities. This opens up a spectrum of ways for the two parties to contract. Firstly, a customer could agree that it doesn’t care how their requirements are achieved so long as they are achieved. Secondly, a customer could agree to accept a product that fulfils all the obligations a supplier sets for itself in a specification. And thirdly some kind of balance between the two which gives the supplier an assurance that certain specifications will be accepted by a customer, but also the customer confidence that their requirements will be met. The third option is likely to be the most desired, but also the more difficult to communicate in a contract. This is why various alternative approaches have emerged, such as Agile, with a view to making software development more co-operative. However, as seen in CIS v IBM, the Agile Alliance’s manifesto principle ‘customer cooperation over contract negotiation’ proved ineffective when IBM was held to be responsible for critical delays to this very large ‘Agile at scale’ project.


Timetables give suppliers the opportunity to outbid other potential suppliers at the tender stage – pushing down their delivery time to the greatest possible extent. It is no wonder, therefore, that IT projects are notorious for exceeding their original contractual timetables. This can be the result of a number of factors. And not just the result of overly aggressive bidding. It could be due to customer changes or faults made by the supplier. This is all tied together by the fact that timetables are usually unrealistic at the outset.

It should therefore be in both parties’ interests to try and be as realistic as possible when it comes to timetabling in systems integration contracts. It can also be useful to introduce phase-level assessments which mean that customers have to accept early stages of development before moving on to later ones. This is where a third party consultant or project manager can come in handy – someone who can introduce a stronger notion of objectivity.

Intellectual property rights

Ownership in or licensing of intellectual property rights in the software being supplied are a fundamental consideration in software projects and must be addressed in systems integration contracts. It may seem logical that the creation of software for a customer should lead to the intellectual property rights of that software being transferred to the customer, when such projects are finalised. However, the current trend is towards the granting of licences to customers. This is because the bespoke software developed on the project will often include modules which the supplier has already created and may even be licencing to other customers. If the licence rights are wide enough and the customer’s use of the software is for its own internal operations then in practice it shouldn’t matter whether the software is owned or licensed by the customer as far as the customer’s use of the software is concerned. However, what if the customer is undertaking the project in order to give it some competitive advantage? This advantage  would be undermined if a supplier was able to licence the new software to competitors.

Another consideration is that, given the extensive involvement of customers in such projects, it can often be the case that key ideas underpinning the development of the software have the potential to come from the customer – what rights should the customer receive (if any) as a result of its input into the development of the software?


It is common practice to include acceptance testing clauses in systems integration contracts. Without such provisions there is greater scope for debate between the parties around whether the supplier has created software that does what it is supposed to. A failure of acceptance tests usually gives rise to an obligation for the supplier to fix the software and re-submit it for testing. If the product continues to fail, this usually gives customers the option to:

  • Ask for the product to be fixed and tested again.
  • Accept the system with its faults, but with a reduction in price.
  • Introduce a third party to carry out the work.
  • Terminate the contract.

CIS General Insurance v IBM

This recent case is a compelling warning of how systems integration contracts can go awry. From the start of the second phase of user acceptance testing in October 2016 until termination, 1,784 defects were recorded, of which 116 were severity level one, 432 severity level two, 1,052 severity level three and 184 severity level four. With a defect in severity level one or two constituting a failed acceptance test. This put IBM in a sticky situation. Not helped by their failure to obtain relief for certain problems when they were attributable, in part, to the customer (Co-op). This was because IBM needed to promptly serve notice of such customer caused problems, which it failed to do.

The case ended up taking nearly three years to get to court with the parties then spending two months in court and a judgement taking a year to be finally produced. IBM were deemed to have successfully excluded liability for “indirect or consequential losses, or for loss of profit, revenue, savings (including anticipated savings), data, goodwill, reputation (in all cases whether direct or indirect” and so Co-op’s primary claim for £128 million of wasted costs on the abandoned project was dismissed. Co-op was successful in its secondary claim for additional costs incurred in supporting the project as a result of IBM’s breaches and was awarded £15.9 million in damages set off by a £2.9 million counterclaim against Co-op resulting from an unpaid invoice.

Final observations

It can easily be argued that the failings of IBM to ensure its subcontractor delivered was the main cause of their downfall. But that doesn’t make this case a simple question of a supplier failing to supply. The nature of the agreement, being a systems integration contract, meant that Co-op (the customer), had obligations to ensure the system delivered all it needed. When Co-op failed to correctly co-operate, IBM (the supplier) failed to serve notice to claim against such customer failings, leaving them with nothing more than a defect ridden piece of software and a set of customer caused problems which they had failed to properly address. Systems integration contracts needs to be thoroughly understood before such projects go ahead. Otherwise you could find yourself in a similarly sticky situation.

EM law specialises in technology law. Get in touch if you need advice on systems integration contracts or other technology law matters.