Australian Law Already Names A Human In The Loop

Australian workplace law contains an express instruction that a human being must look at the reply. It is one line in a legislative instrument written for a different industry, and it is the single most useful sentence available to anyone deciding how far to let AI into a people decision.

Section 13(7) of the Fair Work (Digital Labour Platform Deactivation Code) Instrument 2024, as in force in Compilation No. 1 with a compilation date of 12 June 2026, reads: "A human representative of the digital labour platform operator must consider the employee-like worker's response (if any), including the discussion (if any) between the worker and the digital labour platform operator's representative."

That is the only occurrence of the word "human" in the whole instrument. The drafters put it exactly where the decision gets made.

Why does a delivery code matter to an HR function?

Because of what it regulates. A digital labour platform allocates work, sets service standards, measures completion and quality, and can end a working relationship by switching off an account. Much of that can run on systems rather than supervisors. Australian law looked at that arrangement and, rather than banning it or ignoring it, wrote out the process an adverse decision has to survive.

The Code does not apply to employees, and it does not apply to your organisation unless you operate a platform. It is also not the only place Australian law has started reaching inside a system that manages people: NSW has legislated a power for WHS entry permit holders to inspect a digital work system, which commences on a day to be proclaimed and is not yet exercisable, and the ordinary requirements of procedural fairness already shape what an AI-assisted performance document has to contain. Read the Code anyway. It is the most detailed statement Australian law has yet made about what has to happen around a systematised assessment of a worker, and the shape it settles on is not a technology rule. It is a fairness rule with a human placed at a named point.

The regime also moved. On 17 August 2026 the Interim On-Demand Delivery Employee-like Worker Minimum Standards Order took effect, which the Fair Work Ombudsman describes as "the first minimum standards order that the Commission has issued". It covers workers engaged through an app "to mainly pick up food, drinks, alcohol or groceries from a business and deliver them to the customer as soon as possible", and its terms include record-keeping, "consultation about significant changes", a platform feedback forum, workplace delegates rights and dispute resolution. Deactivation process, consultation and record-keeping now sit in the same regime.

What does the Code actually require?

Four things, in order, and each one maps onto a decision an HR team makes about AI.

A written reason, at a stated standard of comprehensibility. Before deactivating, the operator must give a written deactivation warning "stating that the worker risks being deactivated from the platform for a reason related to the worker's conduct or capacity". The warning must specify that reason, state what will happen if the matter is not remedied within a reasonable time or the reason continues or repeats, and tell the worker they may seek assistance or support from a person who may be a delegate or an employee of an organisation.

Then the test that does the work. Subject to a narrow carve-out for allegations of sexual harassment, the warning "must include sufficient information to enable a reasonable person in the position of the employee-like worker to understand the matters" it raises.

That is a comprehensibility standard, not a disclosure standard. It is not satisfied by attaching a score.

A real opportunity to respond. If the operator then considers that deactivation is justified, it must give a preliminary deactivation notice, which has to specify the reason, state that termination of access is being considered, and state that the worker has a right to respond and a right to request a discussion within a reasonable period. The worker may respond in writing or orally. The worker may request that the operator "make a representative of the operator available to discuss" the preliminary deactivation notice, and if they do, the operator "must make a representative available for the discussion within a reasonable time". A support person the worker appoints may participate.

A human who considers the reply. Section 13(7). Not a system that records the reply, not a workflow that advances a ticket. A human representative who must consider it.

A decision that has to be justified. The operator may terminate access "only if: (a) the reason for the termination is a valid reason; and (b) the operator considers on reasonable grounds that the reason has been established", and it must notify the worker of the decision in writing as soon as reasonably practicable. If the decision is to take no further action, any suspension of access has to be lifted.

There is a fifth requirement that catches the quiet version of the same problem. Where an operator modifies or suspends a worker's access while the process runs, it must notify the worker in writing of "the time and day from which the modification or suspension takes effect" and "the consequences of the modification or suspension for the worker's access to the platform". Throttling somebody's work without telling them is treated as an act with consequences, not as a neutral system state. Every HR function has an equivalent: the person quietly taken off the roster, dropped from the allocation queue or moved to lower-value work while a concern is looked into. The Code's answer is that it has to be visible and dated.

Where does the algorithm sit in all this?

Inside the valid-reason list, and this is the part worth reading closely.

A valid reason can be that the worker "fails or refuses to meet" a set of named requirements, including "the operator's standards or requirements in relation to quality, service level or performance". That is precisely where an acceptance rate, a completion rate, a customer rating or a time-to-deliver metric lives.

But the limb is qualified twice over. It applies only "to the extent that the requirement is reasonable and is known to the worker as a result of communication from the digital labour platform operator or otherwise".

So a metric can ground an adverse decision, and only if it is a reasonable requirement, and only if the worker was told about it. Stack that on top of the comprehensibility test in the warning and the position is clear. The number can be the trigger. The number cannot be the explanation.

How do you use this as a template?

Take any process where a system produces an assessment that feeds an adverse people decision, and run it against the Code's own sequence. This works for performance management, for absence patterns, for productivity dashboards, for a shortlisting tool, for anything where the output lands on a person.

1. Name the requirement before you measure it. Write down what standard the person is being held to, in plain terms, and confirm they were told. If the requirement only exists as a threshold in a system configuration, it fails the "known to the worker" test before you start.
2. Ask whether the requirement is reasonable. Reasonable for this role, this shift pattern, this equipment, this caseload. A threshold inherited from a vendor's default is not a considered standard.
3. Write the reason so a reasonable person in their position understands it. Not the score. What they did or did not do, when, and what would have been different. If you cannot write that sentence from what the system gives you, the system is not ready to feed an adverse decision.
4. Give a real response window, and a real person to talk to. With placeholders: "[EMPLOYEE_NAME], the concern is [SPECIFIC CONDUCT OR CAPACITY MATTER] on [DATE]. You have until [DATE] to respond, in writing or in a meeting. You may bring a support person."
5. Have a named human consider the reply, and record that they did. The record should show what was said, what the decision-maker made of it, and whether it changed anything. A decision that never changes on any response is not a consideration step, and it will read that way later.

TheAICommand works to the Verified Draft Method: de-identify the inputs, ground the model in your own source material, keep a person at the decision point, verify against the primary source, and log what happened. Step 5 is the decision point. Steps 3 and 4 are what make a decision point real rather than ceremonial.

What should never be automated here?

Three bright lines, and the Code draws all three.

The consideration of a response must be human. If an AI tool summarises the reply for the decision-maker, the decision-maker still has to read what the person wrote. A summary that drops the one qualifying sentence is the failure mode, and it is a familiar one.

The content of the reason cannot be generated from the score alone. A model can draft the paragraph. It cannot invent the facts that make the score meaningful, and if the underlying record does not contain those facts, no amount of drafting fixes it.

Nor is the tool ever the reason. A process that ends with "the system flagged it" has not produced a reason at all, which is the same failure the site has described where AI is offered as an explanation for conduct.

The decision itself must have a named person behind it who considers on reasonable grounds that the reason has been established. Under the Code that is expressed as a condition on the power to terminate. In an ordinary workplace it is the difference between a defensible process and one where nobody can say who decided.

There is one further point of design worth borrowing. The Code carves serious misconduct out of the process entirely, so the slow, careful pathway is not forced onto genuine emergencies. Any process you build should have the same escape hatch, deliberately defined, so that the fast path is a decision rather than an improvisation.

The bottom line

• Section 13(7) of the Deactivation Code requires a human representative to consider a worker's response before an adverse decision. It is the only use of the word human in the instrument, and it sits at the decision point.
• The written warning must contain enough information for a reasonable person in the worker's position to understand it. A score does not meet that standard.
• Performance and service-level standards can be a valid reason, but only where the requirement is reasonable and was known to the worker.
• The Interim On-Demand Delivery Employee-like Worker Minimum Standards Order took effect on 17 August 2026 and adds consultation, record-keeping and information sharing to the same regime.
• None of this binds an ordinary employer today. All of it is a reasonable guide to the process an AI-assisted people decision will be measured against.

Do this Monday

• List the places in your organisation where a system output already influences an adverse decision about a person, including tools nobody calls AI.
• For the top one, write the requirement in plain words and check whether the affected people have ever been told it in those words.
• Take a recent decision and try to write the reason without using the score. If you cannot, the record is not carrying the facts.
• Confirm who the named human is at the consideration step, and whether their consideration produces a record that shows what they made of the response.
• Define your serious misconduct equivalent, the narrow case where the slow path does not apply, before you need it.
• Read the Code itself. It is short, and it is the clearest worked example Australia has of a fair process wrapped around a systematised judgement.

References

1. Fair Work (Digital Labour Platform Deactivation Code) Instrument 2024, F2024L01573, Compilation No. 1, compilation date 12 June 2026 (F2026C00472)
2. Fair Work Ombudsman, New minimum standards for on-demand delivery workers
3. Fair Work Ombudsman, Employee-like workers
4. Fair Work Commission, Regulated workers and businesses hub