Symptoms and causes
How can data leaders effectively drive compliance with regulation – and stay compliant – with a growing number of regulations on data, including the EU AI Act? I’m looking back at the recent history of data regulation and offering a friendly provocation to the data leaders’ community. Think like a public health professional: would you go around checking how every restaurant is preparing every meal every day? Or would you focus on giving professionals sufficient knowledge (contagions, pathogen transmission), access to training (hygiene habits, apprenticeship, certification), clear and simple rules of the road (standards), and checks and balances (surprise inspections)? We cannot make data conform with all expectations from all stakeholders by redesigning the system every time; i.e. this is not sustainable. But we can improve the complex adaptive system by shifting our focus to people and their interactions in our businesses.
Image by StockSnap from Pixabay
Human progress – despite some serious mishaps along the way! – happens largely because we “stand on the shoulders of giants”. Conveniences we enjoy today are products of an incredible amount of building blocks placed by many generations before us. These invisible foundations encapsulate lessons learned, what to do, and what not to do. Just like in our physical buildings, they remain invisible.
While I think this makes logical sense, working with data can occasionally appear to be going backwards. We keep trying to build upwards at a frantic pace – you can translate this to the latest strategy to get value from data or adopt GenAI for … well… something! At the same time, we seem to be arguing with the chartered surveyor whether or not the foundations are dangerously rotten (a.k.a. within “risk appetite”); or arguing with the architect – if you have one – about the how much more weight this old load-bearing concrete beam (a.k.a. legacy system) can support. But it's all happening too late because we must comply with an ongoing stream of regulation now. After all, regulation is encapsulating lessons learned.
Why is compliance with regulation around data governance, including security, privacy, quality and ethical use, seen as an outcome to be achieved rather than robust foundations? Perhaps it’s because being in financial services means, unsurprisingly, being “finance led”. When a business becomes a highly complex mix of digital and manual systems, it’s time to inject some lessons from other industries. The Crossrail project in London, UK, now the Elizabeth Line, became infamous for being over budget and late. But one thing is certain: When I use their service, I don’t think about the structural integrity of the tunnels or if the train brakes are working. I trust that standards and regulations protect the passengers and staff. We, data leaders, have much to learn about making a stand for professional rigour. If the business cannot afford to invest in managing digital data, I wonder if risks are truly understood among its leaders.
So, what have we learned from “data catastrophes” of the recent past? We have been adding more policies to the organisation’s library, adding more “controls” into processes (sometimes latent, manual and opinion-based), and creating more internal and external reports. Is that all we have learned? What are the fundamental data lessons of Enron (how data manipulation happens), Lehman’s bankruptcy (how data lacks systemic meaning), and Target’s pregnancy predictor (how data usage must follow a moral compass)?
From Dodd-Frank, Sarbannes-Oxley, and MiFID (+ MiFID II), to the likes GDPR, BCBS-239, Basel IV, the US CLOUD Act and now the EU AI Act, the financial sector has demonstrated the same repeating pattern: process mapping, risk assessment, controls improvement, and reporting - with a sprinkle of agile and digital transformation - then rinse and repeat. In a complex adaptive system going through accelerated change, this model struggles to keep up.
Perhaps civil engineering is not a suitable analogy for the dynamics of data in an organisation, which is a complex adaptive system. Epidemiology or public health may give us a more suitable frame of reference due to its reliance on the interactions between people (agents.) Maybe the business case to fix the source of bad data should be made with more human storytelling – like the cholera outbreak traced to the water pump in Soho in 1854. Even with knowledge of the contamination, people kept taking water from the well until the pump handle was removed, forcing them to fetch water further afield. As data professionals, we must be more curious about human behaviour!
Image from https://johnsnowsociety.org/2018/07/20/the-return-of-the-pump/
That reminds me of the difficulties of delivering one of the regulatory reporting strategies many years ago. A certain “source” system had granular, transaction-level financial data of poor quality (for a few business lines only, i.e. incomplete), and another "source” had better quality data (complete, albeit slightly untimely), but aggregated at a different level from what the report needed. Many organisations have similar muscle memory: The starting point for change is an imaginary boundary of “source” systems visible to the sponsoring or “process-owning” department. This is the equivalent of the Soho water pump behaviour. Sharing data from quality-controlled true sources should be encouraged rather than building more compensating processes on top of already unsuitable ones.
I imagine that when the Food Safety Act was introduced in the UK in 1990, restaurants did not plan to comply once and be done with it. If anything, I expect standards to be improving. As a data leader, I’m curious about how I can make data a safer product to be consumed. I want the data chefs, sous chefs, prep cooks, servers, and baristas to have knowledge about why data hygiene matters to the health of the organisation and its customers.