It is tempting to imagine bias as a single villain hidden in the code. In practice it enters at four distinct points, and a rigorous audit checks each one in turn.

The first is the data. Models are trained or calibrated on records of the past, and the past was unequal. If a fiscal system holds rich data on formal salaried workers and almost nothing on informal or care workers, the model inherits that imbalance and reads the gap as risk rather than as a record that was never collected.

The second is the design, sometimes called specification bias. Every system encodes a goal and chooses variables to pursue it. A platform that optimises for client satisfaction and uses client ratings as the measure has chosen a variable that may capture prejudice as easily as performance. The choice of objective and the choice of proxy are value choices dressed as technical ones.

The third is deployment. A tool built and validated on one population is applied to another for whom it was never designed. Risk scores tuned on formal taxpayers, applied to platform workers, misfire predictably.

The fourth is the feedback. The outputs of the system shape the inputs it sees next. A worker ranked low gets fewer jobs, earns less, and so looks even less established to the system the following month. Bias that loops is the most dangerous kind, because it manufactures the very evidence that appears to justify it.