AI in workplace decision-making: privacy, governance and human oversight

An employer that uses an AI system to allocate shifts, flag underperformance, score a monitoring feed or triage a leave case still makes the employment decision, and still answers for it. The employer remains responsible for its employment decisions, and managers are required to apply the organisation's decision-making process and controls when they act on a system output. Accountability and evidence are governance issues as well as technical issues. A governance failure occurs when a tool is adopted by a function, for a sensible operational reason, without anyone deciding who owns the decisions it influences, what evidence supports them, and what happens when an output is wrong.

Australia has no single workplace AI statute, and no general statutory right to human review of an employment decision. What applies instead is the existing body of law: privacy, workplace surveillance, the Fair Work Act and applicable industrial instruments, anti-discrimination law, work health and safety duties, and the employment contract itself. An AI system does not change any of those obligations. It changes how easily an employer can explain what it did, and how quickly a defect can spread across a workforce.

This guide sets out a governance and control system for AI that affects existing workers — rostering, workload allocation, monitoring, performance assessment, leave and case-management triage, and inputs into conduct decisions. Recruitment, candidate assessment and résumé screening raise a distinct set of questions and are outside its scope. AWS is a workplace consultancy, not a law firm, and nothing here is legal advice.

Vendor labels are unreliable. A product marketed as artificial intelligence may apply a fixed rule set; a product described as a scheduling optimiser or a wellbeing dashboard may be doing statistical inference on employee data and driving material decisions. Legal effect depends on what the system does with personal information and how its output is used, not on what it is called in the procurement paperwork.

It is more useful to classify by the degree of automation. AI-assisted decisions are those where a system surfaces information, patterns or summaries and a person decides. AI-recommended decisions are those where the system proposes an outcome, ranking or score and a person is expected to accept or reject it. Materially automated decisions are those where the output takes effect without a person meaningfully intervening, whether by design or because no one has the time, information or authority to intervene.

The third category is easily under-declared. A roster that is generated automatically and published unless a manager objects is materially automated in practice, whatever the policy says about oversight. So is a flag that automatically opens a case, restricts an access right or feeds a scorecard. The classification question to ask of every system is whether a specific person, before the output takes effect, has the time, the information and the authority to reach a different conclusion.

Avoid describing a system as objective or neutral. Any model reflects the data it was built and tuned on, the choices made about what to measure, and the way its output is used in a particular workplace. Those are all points at which error and unfairness can enter.

• Record, for each system, whether it is assisting, recommending or materially automating, and who made that assessment.
• Test the recorded classification against how the system is actually used in the business, not against the policy description.
• Re-classify whenever a workflow changes, an approval step is removed or the output is connected to a further system.

Before designing controls, establish what is already running. Build the inventory across the use cases listed below, including those introduced through a module of a system the organisation already licenses rather than through a distinct AI procurement.

The common uses are rostering and shift allocation; workload and task distribution; productivity, activity or attention monitoring; quality assurance scoring of calls, messages or transactions; video, location or telematics monitoring with automated analysis; performance and capability assessment, including summarisation of feedback; leave, injury and case-management triage; complaint and conduct triage or drafting; and workforce analytics that feed restructure, redeployment or retention decisions.

Include two further categories in the inventory. The first is general-purpose assistants used by managers to draft performance documentation, investigation notes or disciplinary correspondence, which puts employee personal information into a third-party system without any procurement decision having been made. The second is a feature switched on inside an existing platform by an administrator, which never passes through the approval path a new system would follow.

There is no AI-specific compliance regime to satisfy. There is a set of existing obligations, each of which needs to be assessed against the particular system, the particular data and the particular jurisdiction.

Privacy. If the organisation is an APP entity, the Australian Privacy Principles apply to acts and practices involving personal information unless a specific exemption applies to the act or practice in question. Coverage is not universal, and it is not determined by size alone. The OAIC's overview of the Privacy Act sets out who is covered, including the small business categories that are covered despite turnover of $3 million or less.

Surveillance and monitoring. These laws are made by states and territories, and they differ by jurisdiction and by the technology used. There is no single national workplace surveillance standard. The OAIC's guidance on workplace monitoring and surveillance is a useful orientation point, and the enacted Workplace Surveillance Act 2005 (NSW) is a clear example of what a specific regime can require. It is an example only. Employers must check the law in every state and territory where monitored work is performed.

Employment and industrial. The Fair Work Act, any applicable modern award or enterprise agreement, and the employment contract continue to govern how decisions about existing workers are made. A system output may form part of the information an employer considers; it does not replace the evidence or process required by the applicable law, industrial instrument, contract or policy. It does not answer a question about an entitlement, a classification or a required consultation step.

Discrimination. Commonwealth, state and territory anti-discrimination law applies to the decision, regardless of how it was generated. A system that produces different outcomes for a group sharing a protected attribute creates real exposure, though whether any particular outcome is unlawful depends on the applicable statute, the attribute, the causal question and the facts. Not every inaccurate or skewed output is unlawful discrimination, and not every lawful output is defensible as a management decision.

Work health and safety. Where an AI-enabled work system changes work pace, control, monitoring intensity, job demands or the predictability of hours, it engages the same psychosocial hazard analysis as any other change to how work is designed. Our guide to managing psychosocial risk during organisational change covers that analysis in detail.

Use a mandatory gate that runs before a system is bought, and again before a feature is switched on inside a system already in use. The gate does not need to be elaborate. It needs to be mandatory, to have an owner, and to produce a written record.

Four factors determine how much control a use case needs: the severity of the effect on the worker if the output is wrong; the sensitivity of the information used; the degree of automation; and the number of people affected before an error would be noticed. A system that ranks employees for redeployment using health-related information, with no routine human check, sits at the top of every factor. A system that summarises publicly available policy text for a manager sits at the bottom of all four.

Set the consequence of the classification in advance, so the assessment changes what happens. Higher-risk uses attract a named senior approver, a documented privacy assessment, pre-deployment testing, a defined human check on every output that affects a person, monitoring with reporting obligations, and a scheduled review date. Lower-risk uses attract registration, an owner and a review date, and nothing more. A classification that produces the same process at every level is decoration.

• Apply the gate to feature activations and administrator toggles, not only to new procurements.
• Require the business owner, not the vendor and not the technology function, to state what decision the output will influence.
• Record the classification, the reasoning and the date, and make a higher classification the default where the position is unclear.

Test two assumptions directly: that information entered into a tool is not really a disclosure, and that the employee records exemption removes the whole question. Test both vendor data transfers and the scope of the employee records exemption against the arrangement in front of you.

On the first: information an employee or manager types into a commercially available AI product, and an output that contains or reveals personal information, may both be regulated. The OAIC's guidance on privacy and the use of commercially available AI products works through the practical implications: whether the collection is reasonably necessary, privacy by design, purpose limitation on use and disclosure, notice and transparency, accuracy and data quality, security, retention and destruction, and due diligence on the product before it is adopted. A privacy impact assessment is recommended risk practice in that guidance rather than a universal statutory requirement, though a separate obligation may require one in a particular setting. It is worth doing on higher-risk uses for its own sake, because it forces the data-flow question into the open.

On the second: the employee records exemption is conditional and narrow. It applies to an organisation in certain circumstances, for an act or practice directly related to a current or former employment relationship between the organisation and the individual, and to an employee record held by the organisation relating to that individual. The OAIC's explanation of the employee records exemption is worth reading before it is relied on. It does not follow that every act involving workforce information is exempt: information about contractors, labour-hire workers, volunteers and third parties named in a record, information that is not an employee record, and acts whose connection to the employment relationship is not direct all need separate analysis.

Sensitive information deserves a specific decision. Health information, information revealing union membership, and biometric information used for identification or verification carry additional requirements under the APPs. A monitoring or wellbeing tool that infers a health state, or a system that uses facial or voice characteristics, should not be treated as an ordinary workforce analytics deployment.

The practical control is a data-flow map for each system: what is collected, from whom, by what means, for what purpose, who inside the organisation can see it, who outside receives it, where it is stored and processed, how long it is kept, and how it is destroyed.

Contract terms determine much of the residual privacy and security risk, and they are settled long before anyone is monitored or scored. The questions worth answering before signature are narrow and answerable.

What information will the vendor receive, and what may it do with that information? Is any of it used to train, tune or evaluate models available to other customers, and can that be turned off in the contract rather than in a settings page? Where is data stored, and where is it processed, including by subprocessors? Where an overseas vendor or subprocessor is involved, determine whether the arrangement involves a cross-border disclosure of personal information, which may engage APP 8 subject to its scope and applicable exceptions. Classification depends on the terms of the arrangement and on the OAIC's distinction between a use and a disclosure, so overseas processing does not by itself determine the answer. What security controls, certifications and breach-notification commitments apply, and what are the notification timeframes? What retention period applies to inputs, outputs and logs, and what happens to all three at the end of the contract? What can the vendor actually evidence about how the system performs, including across different groups of workers, as distinct from what its marketing material asserts?

Keep the answers with the risk classification rather than in a procurement folder nobody reopens. When a question arises about an individual decision months later, the contract terms and the data-flow map are what make an honest answer possible.

Human oversight is a control the employer chooses to build. As at 6 August 2026 there is no general statutory right to human review of an employment decision in Australia, although an award, enterprise agreement, contract or policy may create its own review obligation, and the fairness of a process is regularly examined in unfair dismissal, general protections and discrimination matters. Oversight is worth building on its merits, because it is the mechanism that keeps a defective output from becoming a decision.

Oversight that exists on an organisation chart but not in practice is worse than none, because it creates a record suggesting a decision was checked when it was not. Six conditions separate the two.

The reviewer needs actual authority to change or reject the output, and that authority must be exercisable without an exceptional escalation. They need the competence to understand what the system measures and what it does not, which usually means training specific to the tool rather than general awareness. They need access to the underlying evidence, not only the score or the recommendation. They need practical capacity, because a person reviewing several hundred outputs a day is not reviewing anything. They need a safe route to disagree, with departures recorded as normal practice rather than treated as an exception requiring justification. And they need to record reasons that stand on their own — reasons that would make sense to a reader who never saw the system's output.

Two supporting measures make the difference visible. Track the rate at which reviewers depart from recommendations, by reviewer and by use case: a rate at or near zero is a signal that the review step is not functioning. And require the reviewer's reasons to identify the evidence relied on, so the record does not reduce to agreement with a score.

Test the system before deployment and at defined intervals afterwards. The work is procedural as well as technical.

Start by defining what a correct output looks like for this workplace, in writing, before testing begins. Then test against the actual workforce rather than a vendor demonstration set, using historical scenarios where the right answer is known. Examine whether outputs differ systematically for groups sharing a protected attribute, and whether any difference has a defensible operational explanation. Look for proxies: a variable such as availability at particular hours, tenure, part-time status, location or leave history can stand in for an attribute the employer would never knowingly use.

Distinguish accuracy from validity. A model can be accurate at predicting the thing it was built to predict and still be the wrong basis for a decision, because the measured proxy is not the quality the employer actually cares about. Time logged at a keyboard is not productivity. Message volume is not contribution. A model that predicts who previously received a low rating may be reproducing the pattern of past ratings rather than measuring performance.

Testing is not a one-off. Workforce composition changes, vendors update models, and a system that behaved acceptably at deployment can drift. Set a monitoring cadence proportionate to the risk classification, define the thresholds that trigger investigation, and name who reviews the results.

• Write the expected-correct-output definition before testing, and keep it with the test results.
• Test on the actual workforce population and on historical cases with known outcomes.
• Examine outcome patterns across groups, and interrogate proxies as carefully as direct attributes.
• Set a review cadence, thresholds for investigation and a named owner for the monitoring results.

Consultation obligations do not attach to AI as a category. They attach to particular circumstances, and there are two separate sources to check.

The first is industrial. Modern awards and enterprise agreements contain consultation terms, and the common formulation is triggered where the employer has made a definite decision to introduce a major change to production, program, organisation, structure or technology that is likely to have significant effects on employees. Whether an AI deployment meets that threshold depends on the instrument's wording and on the facts, including the effects on job content, hours, work arrangements and the need for retraining. The Fair Work Ombudsman's best practice guide on consultation and cooperation in the workplace is a practical reference. Read the applicable clause before deciding either that consultation is required or that it is not.

The second is safety. Where a proposed AI-enabled work system or monitoring practice may affect the health or safety of workers, consultation duties under the applicable WHS or OHS law can apply in their own right, independently of any industrial instrument. Those duties are enacted jurisdiction by jurisdiction and the detail differs, so the model WHS provisions cannot be assumed to apply everywhere. WorkSafe Victoria's material on consultation under Victorian OHS law is one enacted example of what the duty can require. Identify the jurisdictions in which the affected work is performed and apply the law of each.

Where neither obligation is engaged, consultation is often still the better commercial decision. The people who perform the work know where the data is unreliable, which edge cases the system will handle badly, and which measures can be gamed. Raising those points before deployment costs a fraction of discovering them through a dispute. Where a deployment also requires policy changes, the notice and consent questions are dealt with in our guide to updating workplace policies with proper notice and consultation.

It is important to keep the categories straight. Australian law as at 6 August 2026 does not give employees a general right to be told that AI contributed to a decision about them, a right to an explanation of that decision, or a right to appeal it. Building those pathways is a governance decision, and a sound one, because the absence of an explanation is what turns a correctable error into a grievance.

The transparency requirement that is coming operates at the level of the privacy policy rather than the individual decision. From 10 December 2026, an affected APP entity whose computer programs use personal information to make, or to do a thing substantially and directly related to making, a decision that could reasonably be expected significantly to affect the rights or interests of an individual must include prescribed information in its privacy policy: the kinds of decisions involved, the kinds of personal information used, and the kinds of decisions for which a program does something substantially and directly related to making the decision. The OAIC's consultation on guidance for transparency in automated decision-making is the place to follow how the regulator expects that to be met, and the general expectations for privacy policies are set out in the OAIC's APP 1 guidelines.

Preparing for it is a data exercise before it is a drafting exercise. An organisation cannot describe the kinds of decisions and the kinds of personal information involved unless it knows which programs use personal information in a way that engages the requirement. That is the AI-use register, applied to a specific legal purpose.

The controls worth building now are modest and durable: tell affected employees, in plain terms, where a system contributes to decisions about them and what it uses; give a reason for an adverse outcome that a person can respond to; provide a route to correct inaccurate underlying information; provide a route to have a decision looked at again by someone who was not involved; and connect all of it to the existing grievance process rather than creating a parallel one.

The inventory underpins every other control. An organisation that cannot list the systems influencing decisions about its workers cannot answer a privacy question, prepare for the December 2026 requirement, respond to a dispute, or decide what to suspend when something goes wrong.

The register should hold, for each system: the name and vendor; the business owner and the technical owner; the decisions it influences and the workers affected; the risk classification and its date; the categories of personal information used, including any sensitive information; the data flows, including any overseas processing; the degree of automation and the human check that applies; the testing performed and when; the monitoring arrangements and thresholds; the consultation undertaken and its basis; and the next review date.

One accountable executive should own the register, with the authority to require registration before activation and to suspend an unregistered use. Where obligations, controls and evidence are already managed in a governance platform, the register belongs there so it survives a change of personnel — a general point covered in our guide to building a compliance framework that is monitored and evidenced.

The Australian Government's Voluntary AI Safety Standard is a helpful structure for the accountability, testing, transparency and record-keeping elements. It is guidance, and it is voluntary. It creates no new legal obligation, and the department's own summary of the legal landscape for AI in Australia makes the point that existing law continues to apply. Label voluntary controls as voluntary in your own documentation so the distinction survives inside the business.

Decide in advance what happens when an output is found to be wrong, so the response follows a defined process rather than being settled at the time.

The plan needs four elements. A trigger definition covering what counts as an incident: a materially incorrect output affecting a person, a pattern of outputs correlating with a protected attribute, a privacy or security breach involving the system, a vendor-notified defect, or a change the vendor made without notice. A suspension authority, held by a named person who can switch a use off or revert to a manual process without assembling a committee. A scoping step that asks how many decisions since deployment may be affected, not only the one that was reported, since a systematic defect is systematic by definition. And a remediation path covering correction of individual decisions, correction of records, notification to affected employees, mandatory data-breach assessment where personal information is involved, and the fix or replacement of the system before it is reinstated.

Record what was found and what was changed. Contemporaneous records of a defect and its remediation are the evidence an employer can rely on if the matter is examined later.

The matrix is a governance tool for calibrating controls to risk. It does not answer the legal questions, which turn on the entity, the jurisdiction, the applicable instrument and the facts.

A logistics employer deploys an optimiser that builds fortnightly rosters across four sites, tuned to reduce overtime and unfilled shifts. Both measures improve. Six months later a delegate raises that a group of employees is consistently receiving fewer weekend and penalty-rate shifts, and that several of them have flexible-work arrangements or ongoing carer responsibilities.

The examination has to look at inputs rather than intent. The optimiser was tuned to prefer employees with the widest availability windows and the lowest historical decline rate. Neither variable mentions a protected attribute. Both correlate with one: employees with carer responsibilities have narrower availability and decline more often. The result is a systematic reduction in the earnings of a group whose characteristics are protected under applicable anti-discrimination law and whose flexible arrangements may have their own protections. Whether any particular outcome is unlawful is a legal question on the facts, and the employer should take advice on it. The governance failure is not in doubt: nobody defined what a fair distribution looked like, nobody tested the pattern before deployment, and no one monitored allocation by group afterwards.

There is a safety dimension as well. Rosters optimised for coverage can concentrate short breaks between shifts, unpredictable start times and consecutive nights on the employees with the widest availability. That is a fatigue and psychosocial hazard analysis, engaging the applicable WHS or OHS duties, and it is not answered by the optimiser's efficiency metrics.

The remediation runs on four tracks. Suspend automatic publication and require managerial review against fatigue and equity rules before release. Reconstruct the allocation history to quantify who was affected and by how much, and decide on correction. Retune the objective so distribution of penalty-rate and unpopular shifts is a constraint rather than an accident, and re-test against the actual workforce. Then consult properly on the revised approach, checking the applicable industrial instrument's consultation clause and the WHS or OHS consultation duty in each relevant jurisdiction rather than assuming either the presence or the absence of an obligation.

A professional services employer uses a platform that ingests project data, timesheets, client feedback and written peer comments, and produces a mid-year assessment for each employee with a suggested rating and a summary of themes. Managers are told the output is a starting point. In practice most ratings are submitted unchanged, because the summary is fluent, the platform is confident, and changing it requires writing an explanation.

One employee receives a low rating with a theme of limited client engagement. The employee has spent eight months on an internal remediation program at the firm's direction, with almost no client-facing work. The system measured client interaction volume and had no way to know why it was low. The summary read as an assessment of the employee's contribution; it was an artefact of how the work had been allocated.

The manager's obligation was to test the recommendation against what they knew: to check the evidence behind each theme, to identify the work the employee actually performed, and to record reasons that would make sense to a reader who had never seen the platform's output. That is what separates a defensible rating from an endorsement of a score. Where a rating carries consequences for remuneration, progression or performance management, the process discipline in our guide to performance management and procedural fairness continues to apply in full.

The systemic controls the incident points to are specific. Exclude from the model any employee whose work allocation was materially non-standard during the period, or flag them for manual assessment. Require the manager's reasons to identify the evidence for each theme rather than to affirm the summary. Track the reviewer departure rate and treat a rate near zero as a defect in the oversight design rather than as evidence the model is accurate. Give the employee the substance of what the assessment relied on, and a route to correct the underlying facts before the rating is finalised.

AWS works with employers on the governance side of workplace AI: building the use register and risk classification, setting approval thresholds and decision rights, designing human oversight that stands up to examination, mapping obligations across privacy, surveillance, industrial instruments and WHS duties in the jurisdictions where the work is performed, structuring consultation and change management, and reviewing systems already in use to find the ones that were never approved. Where obligations, controls and evidence are managed in Strobe, the AI-use register and its review triggers can sit alongside the rest of the compliance framework.

AWS is a workplace consultancy, not a law firm. Advice on disputed legal rights, the drafting of contractual terms, and any matter with litigation exposure should be referred to a qualified lawyer. Where the two overlap, we work alongside your legal advisers so the governance design and the legal position stay consistent.