Human Rights has never been more important in an AI-powered world.
For firms adopting AI, the easiest question to answer may be whether a system works. The harder question is what happens when it works as designed, but produces a discriminatory outcome, compromises privacy or leaves an affected person without a meaningful way to challenge it.
This is the central issue raised by the Joint Committee on Human Rights’ (JCHR) recent report, ‘Human Rights and the Regulation of AI’, and is one that is becoming increasingly important as firms and chambers move from deploying third-party systems to developing AI tools in-house.
The Factual Background
The JCHR identifies three principal human rights risks arising from AI:
Discrimination, where biased training data or design choices can reproduce or amplify unequal treatment (engaging Article 14 ECHR)
Privacy, where AI can enable intrusive collection, interference and processing of personal data (engaging Article 8 ECHR)
Effective remedy, where opacity about the use or operation of AI can prevent individuals from understanding, challenging or obtaining redress for harmful decisions (engaging Article 13 ECHR)
The ongoing US litigation in Mobley v Workday provides a useful illustration. The claimant alleges that AI-powered recruitment tools produced discriminatory disparate impact outcomes, demonstrating the difficulty of determining responsibility when harm emerges from a chain of development, design and deployment.
The issue therefore is not simply whether an AI system has caused harm, but where in the AI lifecycle the legally significant responsibility should attach.
Who is Liable?
There are, broadly, two groups to consider.
Developers – designing or building the underlying general-purpose or foundational models which may later be adapted for particular purposes.
Deployers – using those systems within a particular organisational or operational context.
Existing laws apply to AI primarily at the point of use, which more often than not places the burden of responsibility on deployers rather than the upstream developers. The difficulty, and instinctive injustice, arises where risks originate with the latter but materialise with the former.
For example, a developer may create a model containing particular limitations, biases or other risks. A downstream firm may then incorporate that model into a system without having access to the underlying training data or testing methodology. The downstream firm will likely be the actor dealing with the affected individual when the harm materialises, and thus be the party that fault is directed at.
Contractual terms and standard conditions on the part of developers often exclude their liability for the harm, potentially shielding them from this risk and displacing it on those who arguably could not reasonably control it.
That creates an obvious problem for smaller firms in particular. They may have considerably less technical expertise, financial resources and bargaining power than the companies supplying the technology, but nevertheless bear the ultimate responsibility.
Determining who is responsible simply by asking “who pressed the button?” undoubtedly, then, is a largely artificial inquiry.
The Proposed AI Bill
To reform this, the JCHR recommends a dedicated AI Bill which could impose obligations based on proportionate responsibility. Liability would be reflected in due diligence requirements differentiated according to the actor’s role within the AI lifecycle and the nature and seriousness of the risk created. The aim is to place responsibility for preventing and mitigating harm on those best placed to do so, rather than automatically on the final deployer.
The analogy used in the report is instructive:
“It is illegal to manufacture certain types of knives. It can also be illegal to sell certain types of knives. With respect to legal knives that are not banned, it is unlawful to sell them to certain groups of people. There are numerous laws that restrict what people can do with knives.”
AI thus presents a similar challenge. It is a general-purpose tool, for a vast array of purposes and thus potentially pervasive use, so the consequences incurred depend upon both how it is developed and how it is deployed.
Application to In-House AI
This distinction becomes especially important as professional firms and chambers move beyond simply buying AI products and begin developing their own.
The attraction is obvious.
An in-house system can offer greater control over data, confidentiality, workflows, integration and functionality. A firm may be able to develop a system around its own internal knowledge base or particular area of practice.
But under the JCHR’s proposal, greater in-house control is likely to demand greater in-house accountability.
The system may inevitably inherit certain limitations or biases from its underlying model, but the organisation can also introduce new risks through its choice of data, system design, prompts and workflow integration. The more it shapes the resulting system, contributing developer-type input, the stronger the argument that it should assume responsibility for those risks.
Thus, as firms move further upstream in the AI lifecycle, the distinction between developer and deployer becomes increasingly difficult to maintain.
This adds an additional liability dimension to the existing strategic trade-off:
Buy – potentially less responsibility, but greater dependence on the provider and its transparency, testing and contractual terms
Build – greater control and innovation, but potentially greater responsibility for testing, monitoring and governing the resulting system
Of course, this does not mean that outsourcing removes responsibility entirely. Nor does it mean that building in-house makes a firm responsible for everything the underlying model does.
The refined principle is that, the more an organisation moves from being a passive consumer of AI to being an active creator or adaptor of it, the more regulatory responsibility they will assume.
Where This Leaves Lawyers
The JCHR’s proposed reform points towards a simple principle – responsibility should follow the risk, not merely the point of deployment.
The practical question to consider is where in the AI lifecycle actors are exercising control, and what responsibility follows. Any new framework will need to balance innovation against legal certainty and meaningful accountability, ensuring that human rights protection and risk mitigation remain central considerations.
Ultimately, as firms and chambers move from buying to building AI, they gain control, but potentially assume greater accountability too.
Megan is a Contributing Writer at Best Practice. She is currently a second-year Law student at Queen’s College, University of Oxford. Alongside her studies, she is an Associate Editor at the OUULJ, and is pursuing a career at the Bar. Her areas of legal focus are in tort, copyright and public law, particularly through the lens of transformative AI developments.
