When an application assigns shifts, measures breaks, ranks candidates or recommends discipline, it is useful to think of the system as one part of the boss. The software has neither intention nor legal authority, but it translates organisational goals into instructions that shape income, time and opportunity. This idea helps a young worker look beyond the screen: every score reflects human choices about what to measure, what to ignore and how much error other people are expected to bear.
Imagine Leo, twenty-two, in his first warehouse job. A wrist device records routes and an application sends each task. After several days working in an area with fragile goods, his indicator falls and he loses access to preferred shifts. Nobody directly accuses him of poor work; he simply appears below a threshold. His supervisor says nothing can be changed because allocation is automatic. Thinking of the system as part of the boss makes the issue visible: a workplace decision has occurred even though it is presented as an inevitable technical output.
The system does not command alone: it executes a policy#
An algorithm does not discover naturally what a good worker is. An organisation chooses an objective—more deliveries, shorter waits or fewer absences—and selects data to represent it. Parcels per hour may look like productivity, yet they miss the colleague who trains a newcomer, prevents an accident or handles a difficult case properly. Instant availability may be mistaken for commitment, disadvantaging someone who studies or provides care. A metric is a partial interpretation of work. Asking who chose it and which contributions it hides is more useful than debating whether technology is good or bad in the abstract.
An algorithm does not discover naturally what a good worker is. An organisation chooses an objective—more deliveries, shorter waits or fewer absences—and selects data to represent it.
Process design contains decisions too. Someone sets the threshold, determines how long a score lasts, decides whether a recommendation needs confirmation and specifies who can correct data. A vendor builds a tool; the employer chooses where to use it and which consequences follow. A supervisor may click “accept,” but if they see only a number, have seconds to respond and will be challenged for disagreeing, their involvement is not meaningful review. Authority becomes distributed among code, policies, managers and contracts, but responsibility cannot be allowed to evaporate between them.
This perspective avoids giving the program a will of its own. Saying “the algorithm hates me” expresses genuine frustration but makes a remedy harder to locate. Translate the experience into facts: which data entered, which rule was applied, which result appeared, who acted and what harm followed. Perhaps authorised absence is recorded as misconduct; perhaps unlike tasks are compared; perhaps a seemingly neutral rule burdens people who require an accommodation. Separating input, inference and consequence makes it possible to request a precise correction while preserving anything that works.
Five questions that return the decision to the human world#
The first question is, “What exactly is it used for?” Improving efficiency is not a sufficient answer. Name the decision: screening applications, allocating routes, forecasting demand, calculating a bonus or flagging unusual performance. The second is, “Which information does it use, and where did that information come from?” This includes data supplied by the worker, device records, previous assessments and inferred characteristics. The third is, “What consequence can it have?” A recommendation that helps organise work is not equivalent to a score that reduces hours, blocks promotion or contributes to dismissal.
The fourth question is, “Who can review and change it?” There must be an identifiable person who has relevant context, enough time and effective authority. The fifth is, “How can someone challenge it without retaliation?” An unanswered email or a form that sends the case back through the same calculation is not an appeal. People need to know the deadline, responsible role and possible outcome. These questions work in an interview, a team meeting or a conversation with worker representatives. They require neither source code nor advanced statistics.
In Spain, legal worker representatives have a right to information about parameters, rules and instructions underpinning algorithms or artificial-intelligence systems that affect working conditions and access to or continuation in employment, including profiling. The amendment is available in the official Spanish state gazette. This right does not resolve every individual case automatically, but it demonstrates that “the system decided” cannot end the discussion. An employer must understand its own process and be able to discuss collective effects.
How to document a case without becoming a specialist#
When a decision appears unfair, build a short timeline. Record the communication date, a screenshot of the result, the shift or task affected, the explanation received and any data that may be wrong. Keep the contract, accessible policies and relevant messages while avoiding confidential information belonging to others. Then formulate a concrete request: correct a record, explain the relevant criterion, provide human review, restore lost hours or pause discipline until facts are established. A precise account helps a union representative, inspector or adviser distinguish an isolated malfunction from a pattern.
The General Data Protection Regulation provides safeguards regarding certain decisions based solely on automated processing that produce legal or similarly significant effects. Depending on the circumstances, these may include human intervention, expressing one's point of view and contesting the decision. The official GDPR text is published by EUR-Lex. Not every algorithmic recommendation automatically falls under Article 22: the level of automation and the effect both matter. Serious cases deserve fact-specific professional advice rather than a confident universal legal answer.
Meaningful human review must be capable of changing something. The reviewer needs relevant data and reasons, time to hear the affected worker and a record of what was examined. Merely checking that software operated technically does not establish that the outcome was accurate or proportionate. Nor should a person be punished for challenging it. An organisation can learn by grouping incidents: five similar corrections may reveal a broken sensor, a poorly defined category or a rule that systematically disadvantages one shift.
What an employer should test before deployment#
A responsible team can create a one-page map. For every use, it records the purpose, affected people, data, expected benefit, worst plausible harm, detection method, owner and stop condition. It then tests ordinary and edge cases: unstable connectivity, disability, pregnancy, a name change, an authorised break, cooperative work or another language. The goal is not to predict every life. It is to look deliberately for places where a uniform rule loses context and imposes an unequal cost.
A red line is also necessary. A system may propose a schedule but should not publish it without checking rest periods, agreed availability and protected needs. It may identify a performance variation but should not turn the signal directly into discipline. It may rank applicants but should not silently erase people with unusual career histories. The greater the effect on pay, health or job continuity, the stronger testing, oversight and power to stop must be. Approval should expire when the model, purpose or affected population changes.
The European Artificial Intelligence Act classifies certain employment uses as high risk, including recruitment and selection, decisions affecting work-related conditions, promotion or termination, task allocation based on traits or behaviour, and monitoring or evaluation of performance. Its scope and exceptions appear in Regulation (EU) 2024/1689. “High risk” does not mean every use is prohibited. It means proportionate controls, documentation, monitoring and human oversight are needed. Applicable dates and detailed duties should always be checked in the current official text.
Work experience remains a form of knowledge#
The people doing a job know things that are absent from a database: informal cooperation, different rhythms across shifts, physical hazards, complex customers and small adaptations that keep the service running. Involving them before deployment improves both fairness and performance. A pilot should measure more than speed or cost. It should track mistakes, challenges, injuries, schedule predictability, mental load and the time required to feed or correct the tool. If apparent efficiency merely transfers invisible work to employees, the assessment is incomplete.
Joint research by the International Labour Organization and the European Commission's Joint Research Centre has examined algorithmic-management practices in ordinary workplaces. It shows that operational gains can coexist with intrusive surveillance and deteriorating job quality. The report is available through the ILO's official research repository. The lesson is not to reject every tool. It is to examine who receives the benefit, who carries the risk and whether workers have a genuine ability to negotiate the design.
For a family, supporting a young son or daughter does not mean taking control of their workplace conflict. A parent can help order dates, read communications, separate suspicion from fact and decide which remedy to request. Health also matters: feeling that every movement is scored may create anxiety, accelerate pace and make rest difficult. Persistent symptoms, serious discipline or risk of dismissal justify appropriate union, legal or healthcare support. Prudence means neither minimising harm nor announcing certainty before the facts have been tested.
A minimum agreement that makes the tool governable#
Before accepting a system, an organisation should agree on a limited purpose, data inventory, accuracy and equality tests, prior consultation, training, meaningful human review, a correction channel, periodic audits, a deletion schedule, change logging and a suspension mechanism. Every task needs a named owner. The vendor must provide sufficient information; trade secrecy cannot prevent an employer from understanding the variables, limitations and failure conditions of a tool it uses to make decisions about people.
Thinking of the system as part of the boss is useful because it makes an otherwise natural-looking authority visible. It enables people to ask who set the goal, who may disagree and who provides repair. Software can calculate a route or detect a pattern, but it cannot decide by itself what treatment is dignified or what risk is acceptable. Those remain human, collective and revisable decisions. When an organisation can explain, test and correct them, technology remains a tool; when nobody answers for them, it becomes faceless power.
