Just over a year ago, I wrote a blogpost titled “A Lawyer and A Data Scientist Walk Into A Bar” about what it’s like to work at the intersection of data science and the law. This was in response to many questions I received from friends and colleagues at the FBI and elsewhere about my transition from the public sector to working for a startup focused on data science.
“What does law have to do with software?” some asked. “Why leave public service for the private sector?”
More recently, I’ve started to receive a new question: “What exactly does it mean to be a ‘legal engineer’?”
Legal engineer is a reference to part of my title, and to the team I lead at Immuta, focused on viewing legal regulations as software requirements within our platform. And the answer to all these questions rests on the same point.
Here’s what I wrote in 2016:
Hiding behind Immuta’s software is an incredible, although not completely obvious, ambition. In the task of creating software to help solve [growing data regulation] issues . . . Immuta is also confronting one of the great legal issues of the modern era: how do we embed our laws into the software we increasingly use to regulate society? More precisely, what does the intersection between the algorithms we use and the values we hold look like?
In the months since, we’ve only seen these questions become more prominent. Regulations like the EU’s GDPR, the increasing use of machine learning across verticals, the explosive generation of personal data – all of these trends are exacerbating tensions between technology and the law. And a legal engineer, or a legal engineering team, is focused on solving these issues from an engineering perspective.
What logical requirements on data can be represented within software? How can we create a policy builder that easily allows lawyers to translate these requirements into code? These are all questions we ask at Immuta on a daily basis. Indeed, these are questions we’re seeing global regulators ask themselves as they confront the very same tensions between law and technology, as we recently saw firsthand working with the FCA and the Bank of England.
The idea of legal engineering is not new – see, for example, this 1989 article by a group of lawyers at Stanford – but it is an idea whose importance is growing, perhaps even exponentially. As software eats more and more of the world, to quote Marc Andreessen, the ways that laws are created and enforced are beginning to change as well. These challenges call for a new way of thinking about the intersection of technology and the law, and that’s exactly what legal engineers aim to do.
Here are a few examples of what the legal engineering team will be focused on at Immuta over the next few quarters:
- Examining current model risk management frameworks, like the Federal Reserve’s SR 11-7, and embedding aspects of these frameworks within the Immuta platform.
- Studying practical, implementable best practices on reducing bias and risk in machine learning. We’ll then frame these practices into digestible, easy-to-scale methods to help our customers control risk across their data science programs.
- Continuing to break down the EU’s General Data Protection Regulation requirements from a logical, machine-executable perspective.
- Analyzing how much of the GDPR’s requirements on data overlap with other data regulations, like China’s cybersecurity law or Turkey’s new, anonymization-focused data protection regime, to pick two examples, and embedding that logic within the Immuta platform.
To learn more about what Immuta’s legal engineering team is working on, or what we’ve built, please email [email protected].
