Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

To assess whether an AI system is biased, identify the decision it influences, who is affected, what comparison is being made, and which outcomes or errors differ. Then examine the data, design assumptions, deployment context, and human practices around the system. A disparity is a reason to investigate—not, on its own, proof of the cause or a legal finding. Who must prove discrimination depends on the claim, jurisdiction, and forum.

AI bias is not just a data problem

AI systems operate within social and organizational settings. Bias can enter through the data and statistical choices used to build a system, through the institutions that select and deploy it, and through the people who interpret or act on its output. A technically accurate model can still contribute to unfair outcomes if its purpose, inputs, or use do not fit the situation.

The National Institute of Standards and Technology (NIST) describes three broad sources: systemic, computational or statistical, and human-cognitive bias. They can overlap. A dataset may reflect past practices; an organization may carry those practices into its workflow; and a person may treat a model’s output as more complete or authoritative than it is. Fixing one dataset or model component may not address the surrounding process.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

As NIST principal investigator Reva Schwartz put it, “Context is everything.” NIST also notes that AI systems help people make decisions that affect other people’s lives. Its overview of harmful bias in AI, 2022 report summary, and AI Risk Management Framework resource on trustworthiness provide a useful starting point for considering these connected sources.

What “bad data” means depends on the system’s purpose

Data is not simply good or bad in isolation. The relevant questions are whether it fits the system’s stated purpose and whether it reflects the population, conditions, and decisions for which the system is used. A dataset can be large yet omit people or situations important to the deployment. Labels and historical outcomes may also encode earlier judgments or institutional practices.

For covered high-risk AI systems, Article 10 of the EU AI Act addresses data governance for training, validation, and testing datasets. It calls for datasets to be relevant, sufficiently representative, and as complete and free of errors as possible in light of the system’s intended purpose. It also addresses design choices, data collection and preparation, bias examination and mitigation, data gaps, and the system’s geographical, contextual, behavioural, or functional setting. These are provisions of the EU framework for covered systems, not a universal rule for every AI system. The European Commission’s Article 10 text reflects the consolidated Act as of July 27, 2026; its AI Act guidance provides broader regulatory context.

How to investigate a suspected disparity

Begin with the real-world decision, not a general claim that an AI model is “biased.” A useful investigation defines the outcome, comparison, and use context so that another reviewer can understand how the result was reached and what it does—and does not—show.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  1. Specify the decision and purpose. Identify what decision the system supports or makes, what its stated purpose is, and where human judgment enters the process.
  2. Identify affected people and comparison groups. State who is included in the analysis, how groups are defined, and whether the comparison reflects the people and setting at issue.
  3. Define the outcome and measure. Explain what counts as a different result or error. Report the measure’s limitations; a single aggregate score may hide differences relevant to the decision.
  4. Examine data and assumptions. Record data provenance, sample construction, missing or uncertain information, labels, and assumptions used in model design and evaluation.
  5. Check the deployment process. Look at the system version and setting, organizational rules, human overrides, downstream uses, feedback loops, and whether affected people can obtain meaningful review.
  6. Preserve a reproducible record. Keep dates, versions, methods, and relevant documentation so an independent reviewer can reproduce, question, or challenge the analysis.

These steps are an investigation framework, not a single mandated test for every system. NIST’s bias overview and risk-management resource emphasize context and trustworthiness; the EU’s Article 10 ties data governance to intended purpose and setting.

A disparity, a cause, and a legal finding are different things

An observed difference between groups can be important evidence, but it does not by itself explain why the difference occurred. Establishing a plausible cause requires examining the decision, data, assumptions, deployment conditions, and alternative explanations. Whether that evidence establishes a legal violation is a separate question governed by the relevant law and procedure. Technical frameworks can help structure an inquiry; they do not decide an individual legal claim.

Who has the burden of proof?

There is no universal answer to “Who must prove AI bias?” The answer depends on the legal claim, jurisdiction, forum, and procedural stage. In its evidence guidance, the U.S. Equal Employment Opportunity Commission (EEOC) distinguishes the responsibility to produce material, relevant, and reliable evidence from the responsibility to persuade the factfinder. How those responsibilities apply, including whether an initial burden shifts after it is met, depends on the case facts. See the EEOC’s evidence guidance.

U.S. employment claims illustrate why precision matters. The EEOC discusses disparate treatment and adverse impact under particular legal frameworks in its overview of discrimination theories. Those frameworks should not be treated as a substitute for the rules governing a different claim—such as one involving credit, housing, health care, or education—or a claim outside the United States.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Legal standards can change. In 2022, the EEOC and U.S. Department of Justice issued technical assistance about disability discrimination risks in algorithmic hiring, including screening out people with disabilities and the need for accommodation safeguards. In 2026, the Justice Department’s Office of Legal Counsel issued an opinion on Title VII disparate-impact liability. The latter is an agency legal position, not a universal resolution of every AI-related discrimination dispute. For a particular matter, the current controlling statutes, regulations, court decisions, agency authority, and state or local law must be considered alongside the facts. See the agencies’ 2022 disability-discrimination warning and the Justice Department’s 2026 Office of Legal Counsel opinion.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

What the four-fifths rule does—and does not—tell you

The EEOC’s 1978 Uniform Guidelines Q&A describes the four-fifths, or 80%, rule as a practical rule of thumb for directing attention to serious discrepancies in employment selection rates. It says the rule is not intended as a legal definition. It is not a universal fairness test, and a result under or over that threshold does not by itself prove discrimination or fairness. Its scope is employment-selection analysis under that guidance, not every AI use or jurisdiction. The EEOC explains the point in its Uniform Guidelines Q&A.

Questions to ask about an AI system

  • What specific decision does the system influence, and what purpose was it designed to serve?
  • Which people and groups were represented in the data and evaluation, and how were those groups defined?
  • What outcomes and error measures were compared, and what do those measures leave out?
  • Do the data, assumptions, and operating conditions fit the system’s actual deployment context?
  • Can a reviewer inspect the system version, methods, sample construction, and relevant records?
  • What happens when the system produces an error or a person challenges its output?

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.