Is YOUR data training THEIR AI? In our personal and working lives we’re under a barrage of notifications inviting us to use new AI functionality. Sometimes it’s not even a feature we actively turn on, it’s automatically on by default and we need to take steps disable it or opt-out. The problem is we often don’t know how this AI actually works, what it might do, what data it uses, or what data is used to train it. Recently LinkedIn announced it has started sharing user generated content for LLM training. While you may be happy with this, for those that aren’t, you need to actively go into your data privacy settings and switch it off. More broadly, many organisations are being encouraged to take advantage of shiny new AI capabilities offered by their existing software providers. HR, Finance, IT and CRM software can seemingly do so much more if the latest AI tool is enabled. It’s very tempting to give it a try. And I suspect many data protection teams are struggling to keep up with parts of the business which have drifted into using AI tools without much deliberation. We need to be aware using AI for seemingly innocuous purposes can have unexpected consequences. We’ve written about the risks to consider when using AI to transcribe or record meetings. Did you know there’s a feature on MS Teams which can automatically detect when an employee is connected to the company wi-fi and update their location to ‘in the office’? This may seem like a simple and useful feature to switch on. But in essence this is a form of workplace tracking, and may raise some considerations, not least is it proportionate and lawful? Even with our existing suppliers, we’d be wise to conduct some due diligence. AI functionality isn’t always a straight-forward extension of an existing service. We should assess the benefits and risks, be clear about our objectives and whether we are a controller or joint controller. Make sure our activities are lawful, fair and transparent. Be sure our data is still being processed by the same party and in the same country. Understand if our data will be used to use to train the software providers’ models, and where data is anonymised or aggregated, be confident this is effective enough in preventing risk. It may feel daunting, but we should try and have some level of understanding about how a third-party supplied AI system works. Ultimately, we’re responsible for complying with data protection law for any personal data we allow to be used in or by an AI system. Recently I was reviewing the AI usage of a client’s existing software provider. They were ambiguous about the use of the client’s personal data to train their own models. It became clear processing was no longer taking place in Ireland, but in the United States and India. I’ve seen other AI software where it’s transpired it’s not been developed by the software provider themselves, but they are using AI provided by a third party (who the data is shared with). Which made me wonder; is the AI provider using that data for their own purposes, such as AI training? Ideally we should be asking AI providers, whether they be new or existing suppliers, to work with us to conduct a Data Protection Impact Assessment. If they’re reluctant to help, or not able to answer key questions, this might raise concerns. I’m not saying all AI tools are inherently a bad thing. There are many benefits to be gained! Just do some digging, and keep your eyes open. How to govern your organisation’s use of AI

GDPR RoPA simplification Will EU proposals to change Records of Processing Activities requirements have an impact in practice? As GDPR passes its 7th birthday, there’s been a flutter of excited commentary about European plans to make changes to the ground-breaking data protection law. In particular, potential amendments aimed at easing the compliance burden on small to medium-sized businesses. So far, it’s fair to say the proposed changes from the European Commission are far from earth-shattering (albeit there could be more in the pipeline). A key proposal relates to Article 30, Records of Processing Activities. The obligation to keep a RoPA would no longer apply to organisations with fewer than 750 employees provided their processing activities are unlikely to pose a ‘high risk‘ to the rights and freedoms of individuals. The proposal also clarifies the processing of special category data for purposes related to employment, social security and social protection would not, on their own, trigger the requirement to maintain Article 30 records. For comparison, the existing exception only applies to organisations with less than 250 employees, unless the processing carried out is: ⏹ Likely to result in a risk to the rights and freedoms of data subjects, ⏹ The processing is not occasional, or ⏹ The processing includes special category data or personal data relating to criminal convictions and offences. What impact might this RoPA change have? As many organisations process special category data (even if just for their employees), and processing activities are often routine, not occasional, the current exception for smaller companies is limited in scope. The proposed wider exemption would clearly apply to far more organisations. I can absolutely see why the Commission has homed in on RoPA requirements, as in my experience many organisations struggle to maintain an up-to-date RoPA, or don’t have one at all. But how helpful could this change actually be? In practice, organisations subject to GDPR will still need to assess whether their processing activities involve ‘high risk’ to individuals. To do this they will need to weigh up their purpose(s) for processing, their lawful basis, how long they keep personal data, who it is shared with, whether any international data transfers are involved, what security measures are in place and so on. It seems a bit of a catch 22 – a RoPA is a great way of capturing this vital information and clearly ascertaining where risk might occur. Alongside this, organisations will still need to meet transparency requirements and the right to be informed. And, yes you guessed it, an accurate RoPA is very helpful ‘checklist’ in making sure a privacy notice is complete. We’ve written more about the benefits of a RoPA here. Importantly, if this proposed change goes ahead, it won’t apply to organisations which fall under the scope of UK GDPR (unless the UK Govt decides to adopt a similar change). Notably, fairly significant changes to UK GDPR’s accountability requirements were on the cards under the previous Conservative Government’s data reform bill. However, seen as too controversial, these were swiftly dropped after the election in the new Labour Government’s Data (Use and Access) Bill (DUA). It’s possible the UK could regret not being more ambitious in the DUA Bill; there’s an obvious irony given oft-heard criticisms of EU overregulation – here’s a case where the EU’s easing of certain requirements could leave UK organisations with more onerous rules.

Data Protection Impact Assessments for Agile projects How to assess risks when a project has multiple phases Agile methodology is a project management framework comprising of several dynamic phases, known as ‘sprints’. Many organisations use Agile for software & technology development projects, which often involve the processing of personal data. From a data protection perspective, Agile (and indeed other multi-stage projects) present some challenges. The full scope of data processing is often unclear at the start of a project. The team are focussed on sprint one, then sprint two, and so on. So how do you get Privacy by Design embedded into an Agile project? Conducting a Data Protection Impact Assessment (DPIA) is a legal requirement under data protection law for certain projects. Even when a DPIA is not mandatory it’s a good idea to consider the privacy impacts of any new processing. Looking at a project through a privacy lens at an early stage can act as a ‘warning light’, highlighting potential risks before they materialise and when measures can still be easily put in place to reduce the risks. If your organisation uses Agile, it’s likely you’ll need to adapt your DPIA process to work for Agile projects. Understand the overall objectives and direction of travel to get a handle on how data use will evolve and what risks might be involved. Working together to overcome challenges It’s important all areas of the business collaborate to make sure projects can proceed at pace, without unnecessary delays. Compliance requirements must be built into Agile plans alongside other business requirements – just as ‘Privacy by Design’ intended. Those with data protection responsibilities need project management teams to engage with them at an early stage, to explore the likely scope of processing and start to identify any potential privacy risks, while there’s still time to influence solution design. This isn’t always easy. Given the fluid nature of Agile, which is its great strength, there is often very limited documentation available for review to aid Compliance assessments. Privacy questions often can’t be answered at the start – there may be many unknowns. So its key to agree what types of data will be used , for what purposes and when more information will be available for the DPIA – crucially before designs are finalised. Timings for assessment need to be aligned to the appropriate sprints. As many companies have found, embedding privacy awareness into the company culture is a big challenge and ensuring Data Protection  by Design is a key consideration for tech teams at the outset is an on-going task. Example: data warehouse Organisations with legacy data systems might want to build a data warehouse / data lake to bring disparate data silos together under one roof, gain new insights and drive new activity. It’s important to assess any privacy impacts this new processing create. Using Agile, new capabilities may be created over several development phases. So it’s important to conduct an initial assessment at the start, but stay close to as the project evolves and be ready to collaborate again, in line with sprint timings – before data is transferred or before new solutions are created. Top tips for ‘Agile’ DPIAs Here are my top tips for a fluid DPIA process; 1. DPIA training & guidance – make sure relevant teams, especially IT, Development and Procurement, all know what a DPIA is (in simple layman’s terms) and why it’s important. They need to recognise the benefits of including privacy in scope from the start (i.e. ‘by Design’). 2. Initial screening – develop a quick-fire set of questions for the business owner or project lead, which will give the key information you need, such as the likely personal data being use any special category data, children’s data or vulnerable people’s data the purposes of processing security measures… and so on Once it has been identified there is personal data involved you can start assessing the potential risks, if any. As odd as this may sound, it is not uncommon for tech teams to be unsure at the beginning of a project if personal data (as defined under GDPR to include personal identifiers) will in fact be involved. 3. DPIA ‘Lite’ – if there are potential risks, develop a series of questions to evaluate compliance against the core data protection principles of the GDPR. The Agile environment can prove challenging but also rewarding. Adopting a flexible DPIA process which works in harmony with Agile is a positive step forward for innovative companies, allowing your business to develop new solutions while protecting individuals from data protection risks, as well as protecting your business from any possible reputational damage.