BIAS Blog 2: Potential Harm in Machine Learning
Published on:
News Article Understanding Potential Sources of Harm throughout the Machine Learning Life Cycle
Case Study Summary
This case study explains that as machine learning becomes more involved in daily life, it also brings new risks that can lead to harmful or unfair outcomes. To prevent these issues, we need to understand where and how harm can be introduced at each stage of the machine learning life cycle. The authors present a framework that identifies seven potential sources of harm that can appear during data collection, model development, and deployment. They explain how each type of harm arises, why it matters in real-world applications, and how it calls for different solutions.
looking at these discussion questions: “Can you come up with an additional example of each source of harm?” My Response: — Historical bias can appear in hiring algorithms that learn from old company data where women or minorities were underrepresented in tech roles. Even if the data is collected fairly, the model still reflects those past inequalities.
Representation bias can happen when online job boards rely mainly on users from urban areas, leaving rural workers underrepresented. Models trained on that data may recommend fewer opportunities for rural applicants.
Measurement bias can occur when social platforms use the number of messages sent as a measure of friendship strength. This oversimplifies relationships because some people stay close even without daily texting.
Aggregation bias can arise in educational software that applies the same performance model to all students, even though learning patterns differ across age groups and cultural backgrounds. The “one-size-fits-all” model fails to adapt to those differences.
Learning bias can appear when a food-delivery algorithm is trained to maximize total deliveries per hour. That goal ignores driver fatigue or safety, rewarding risky behavior to meet time targets.
Evaluation bias can occur when a speech-to-text system is tested mainly on clear studio recordings rather than real-world audio with background noise. It looks accurate in testing but fails for most users in practice.
Deployment bias can show up when an image-generation tool meant for creative use gets used to make fake IDs or misleading media. The harm doesn’t come from the model itself but from how it’s used outside its intended context.
“How might these sources of harm manifest in a project you are currently working on, or have worked on in the past?” My response: — When thinking over my aim trainer game that I built, I started realizing how these sources of harm can appear even in small projects. Representation bias showed up because all my testing data came from me using the same laptop, screen size, and internet speed. That means the game could respond differently if people played it on slower computers or monitors with lower refresh rates. Measurement bias happened when I focused on accuracy and speed but did not include improvement over time, which could have given a fuller picture of player skill. It is crazy to think that these biases can appear in any design process if you do not test with different users or think carefully about what your metrics actually measure.
“Draft a checklist that people starting new projects could use to try to anticipate or prevent different types of bias.” My Response: Before starting a new project, it helps to think about where bias could appear and how to prevent it. Teams should start by asking what historical or social patterns might already exist in their data and make sure that all relevant groups are represented fairly. During data collection, it is important to check that the measurements or labels actually capture what matters rather than what is easiest to record. When designing and training the model, developers should decide if one system can work fairly for everyone or if separate versions are needed, and choose objectives that reflect real-world values instead of just accuracy or speed. Testing should include diverse and realistic data to make sure the model performs well under different conditions. Finally, before and after deployment, teams should be clear about how the system is meant to be used, include safeguards against misuse, and collect feedback from users to spot and fix issues early.
My New Discussion Question:
If bias exists in society, can any machine learning model ever be truly unbiased, or will we always have to deal with difficulties that come from the world we live in?
I chose this question because the article shows that bias is not only a technical problem but also a reflection of real social inequalities. Even if developers design fairer systems, those systems still learn from human choices, history, and behavior. This question invites people to think about whether complete fairness is possible or if our goal should be to reduce harm as much as we can while acknowledging those limits.
Reflection
Reading this case study made me realize that bias in machine learning is not something that can ever be fully removed, but something that must be understood and managed. The seven sources of harm helped me see that bias can enter at any stage, from the moment we choose what problem to solve to the way we test or use the final model. This also made me reflect on my own aim trainer project, where I saw how small choices in testing and design could unintentionally create bias. It reminded me that being careful and intentional at every step matters, even for personal projects, and that fairness is about awareness and responsibility, not just performance or accuracy.