5: How to Hold Developers Accountable for Bias?
If the IRIS application fails to achieve unbiased performance or causes harm/unfair outcomes, what are the legal and ethical grounds for holding the application/owners accountable?
39 Answers
Yes
Yes. If IRIS causes harm or shows biased performance, developers and deployers can be held accountable under product liability law, GDPR, and the EU AI Act, especially if they failed to meet safety, fairness, or risk-mitigation obligations.
Yes—there would be clear grounds for accountability if IRIS causes harm or unfair outcomes, under EU AI Act (provider obligations and liability), GDPR (discriminatory or unlawful processing), product liability laws, and negligence standards, especially if bias, inadequate validation, or lack of safeguards can be demonstrated.
Yes
If IRIS causes harm or shows bias, developers or operators can be held accountable. Safety technology must be properly tested and monitored. Accountability encourages responsible design and protects users from avoidable risks.
Yes, if IRIS causes harm or unfair outcomes due to bias or poor performance, there are clear grounds for accountability under product liability, data protection, and AI governance laws.
No at the moment
Under the EU AI Act and the revised Product Liability Directive, if an application like IRIS fails to perform as promised—particularly if it exhibits demographic bias or causes harm—it is treated as a defective product. Owners and developers are held to a "duty of care".
Depends if people are negatively affected by it
Yes, there are clear grounds for holding the application or its owners accountable if IRIS causes harm or produces unfair outcomes. Potential bases for accountability include: EU AI Act non-compliance, particularly failures in risk management, bias mitigation, or post-market monitoring. Product liability law, if IRIS is deemed defective or unsafe. Negligence, if known limitations or biases were not adequately addressed or disclosed. GDPR violations, if personal data is processed unlawfully or without sufficient transparency. High-risk classification increases the expectation that providers exercise heightened due diligence, making liability more likely where safeguards are insufficient.
Yes. Bias or risk was foreseeable
No
It depends
Yes
Yes.
Yes, as the IRIS models lack sufficient training
Yes, I do believe those in charge of implementing the software should be held accountable.
I would say the the legal side, because it may not provide all of the details necessary to make a fair decision.
Those organisation which agree to make use of technology without sufficiently finding out or recognising these flaws and how they can, or cannot, be managed. The producers/researchers (these may be different bodies) behind the technology are also responsible for making full information about the technology available, without having to be asked direct questions to elicit it.
Provided users respond appropriately to warnings, do not deliberately attempt to manipulate inputs, and use the system as intended, they should not be held accountable for any unfair outcomes arising from the system itself. Responsibility for such outcomes lies with the designers, developers, and deploying organisations, who control the model design, training data, and validation processes.
Accountability should sit with the organisation that deploys the system, supported by responsibility from the developers and data controllers. Users should not bear blame for failures caused by poor design or biased training data.
Final accountability should rest with the deploying organisation, because it chooses the use case, training data, and deployment thresholds. Vendors remain responsible for defects in the underlying model and documentation.
The company and the system integrator should be accountable first, because they make the operational decisions. Regulators should also be able to examine the training data and evaluation results.
The organisation should be the primary accountable party because it controls the risk to end users. Vendors should remain accountable for defects, misleading claims, and insufficient documentation.
Accountability should be shared, but the deploying organisation bears the main responsibility for safe implementation. Developers, data suppliers, and maintainers should each have defined duties.
The organisation deploying the product should be accountable first, because it is the one choosing to rely on the system in practice. Developers and suppliers should support that with transparent testing and documentation.
The deploying organisation should be accountable for system harm, with developers responsible for design and validation defects. Responsibility should not disappear into a vague supply chain.
Ultimately, the organisation operating the system should be responsible for its outcomes. They choose whether the model is good enough to use on real roads.
The company and the system integrator should be accountable first - they make the operational decisions. Regulators should also be able to examine the training data and evaluation results.
The organisation deploying the product should be accountable first, because it is the one choosing to rely on the system in practice. Developers and suppliers should support that with transparent testing and documentation.
Yes - and all the researchers/funders
Usually companies
Must be a human (not driver) somewhere in the pipeline. Need to investigate the problem cause to determine who would be responsible.
The vehicle manufacturer would be the main culprit although it depends on the agreements with other parties involved in the component, e.g., data owner, model developer, camera manufacturer, etc.
Your Answer
Login to add your answer!
We’d love to hear your thoughts — share a meaningful answer by logging in.