Your AI Rules Stop at Payroll. Your Risk Does Not.

Contractors, labour-hire workers and outsourced teams can touch the same customer work through different legal and technical boundaries. Give each boundary six equivalent operating controls before access starts, then test the handshake instead of trusting induction or contract language alone.

Your employee opens the approved AI workspace. The contractor beside them opens a personal account because their access request is still pending. The outsourced team follows its own review process, but nobody on your side can show what that process requires.

The work may be similar. The legal relationships, systems and accountabilities are not. This is a boundary question rather than a supplier-count question: where one foundation model sits under several vendors, the risk is concentration, and the fix is knowing what you actually depend on. Here the vendors may be entirely separate and the risk is that the same task runs under two different control regimes. Do not call everybody an employee or send the employee policy to every supplier. Require equivalent outcomes for tools, data, human review, records, escalation and incidents.

Use a six-control cross-boundary handshake. Internal and external work owners agree this one-page card before the use case starts. It does not replace worker-status analysis, privacy advice, procurement, contract management or prudential assessment. It closes the operational gap between them.

Where does the control boundary actually change?

Start with the relationship, not the badge colour. An employee, contractor, labour-hire worker and outsourced team member can sit in one meeting while different organisations employ or engage them. Classification and obligations depend on the facts and current law. An AI control card cannot decide them.

Privacy is a practical example of why the distinction matters. The current in-force version of the Privacy Act 1988 is C2026C00227, Compilation No. 104, effective 4 June 2026 and registered 17 June 2026. Section 7B(3) limits the private-sector employee-records exemption to an act or practice of an organisation that is or was the individual's employer, directly related to the current or former employment relationship and an employee record held by that organisation and relating to the individual.

That is not a general workplace-records exemption. A host should not assume it covers contractor records, labour-hire worker records held by the host or AI-generated observations about external workers. Privacy Act and APP coverage still depends on the entity, information, act or practice and any relevant exemption. Obtain advice for the arrangement.

The Office of the Australian Information Commissioner's employee-records guidance makes another boundary explicit. The exemption does not cover contractors and subcontractors handling another organisation's employee information. The OAIC says a contractor or subcontractor organisation collecting employee records from an employer must comply with the APPs when handling them, including APP 5 notice requirements.

Read that guidance with the Act and the entity's circumstances. It does not make every contractor covered in every activity. The receiving organisation cannot borrow the employer's exemption merely because a contract permits access.

The same discipline applies to AI inputs and outputs. For organisations covered by the Privacy Act, OAIC guidance applies the APPs when personal information is used to train, test or use AI. It recommends product and data-access due diligence, human oversight, training and monitoring. An input may be a use or disclosure depending on whether it remains under the organisation's effective control (OAIC).

An external worker's approved task does not answer those questions. Map which entity holds the information, which account sends it, who can access the input and output, and where the record returns.

What must be equivalent across the boundary?

Equivalent does not mean identical. A provider may use its own identity and incident systems. Both sides must demonstrate the agreed outcome for the use case, with named people and evidence.

Put six rows on the handshake card:

1. Approved tool and identity. Name the product or equivalent, environment, account owner, permitted features, access approver and offboarding trigger. "Enterprise tool" is insufficient when the provider uses another tenant.
2. Data boundary. State permitted inputs, classification, de-identification, storage, third-party access and the exception approver. Link the rule to the use case, not a slogan.
3. Human review. Name the human reviewer, acceptance test, decision boundary and evidence of review. An external quality check is not equivalent unless your accountable work owner understands what it checks and can reject the result.
4. Authorised record. Specify where sources, relevant instructions, output, review evidence, corrections and approvals are stored. Name the record owner and retention source. A worker's chat history is not the business record.
5. Escalation. Give people on both sides a stop route for inaccurate output, unsafe data, access problems and unclear instructions. Record who receives each issue, the response expectation and who decides whether work resumes.
6. Incident and exit. Define the triggers for containment, evidence preservation, internal notification, access revocation, provider coordination and controlled restart. Link contractual or regulatory reporting to the authorised functions that assess it. The AI system does not decide whether an incident is notifiable.

For each row, record the internal requirement, the external commitment, proof supplied, any gap, two named owners and an expiry or review date. A contract clause is an input. Evidence that the control operates is the handshake.

Use this prompt to draft a card from approved, de-identified material. The internal work owner, external delivery lead and relevant privacy, security, records and risk specialists must verify each row and decide whether work may start.

Draft a six-control cross-boundary handshake for [USE_CASE] between [INTERNAL_TEAM] and [EXTERNAL_PROVIDER_OR_WORKER_GROUP].

For each control return:
- internal requirement
- external commitment
- supplied evidence
- mismatch or missing evidence
- internal owner
- external owner
- review or expiry date

Controls:
1. approved tool and identity
2. data boundary
3. human review and decision boundary
4. authorised record
5. escalation
6. incident and exit

Use only the supplied documents. Do not decide worker status, legal coverage, privacy compliance, CPS 230 materiality or whether an incident is notifiable. Do not treat a policy statement as proof of operation. Mark missing evidence [GAP].

Approved, de-identified material:
[PASTE USE-CASE, POLICY, CONTRACT AND CONTROL EVIDENCE]

Before accepting the card, confirm that named systems exist, owners accept their roles, evidence is current, the reviewer can access sources, records reach the authorised repository, workers can stop through a named channel and offboarding has an owner. One failure keeps the use case closed or constrained until an authorised person accepts a lawful alternative.

How do you test the handshake before an incident?

Test one realistic boundary break. Ask what happens when someone pastes a prohibited input, a reviewer rejects an output, an approved feature changes, access fails mid-case or a suspected disclosure appears in a provider log.

Consider this fictional worked example in financial services. [INSURER_NAME] engages [SERVICE_PROVIDER] to prepare first-pass summaries of de-identified claims correspondence. The provider uses an approved enterprise AI product in [PROVIDER_TENANT]. A human [PROVIDER_REVIEW_ROLE] checks each summary against the source, and [INSURER_ACCEPTANCE_ROLE] accepts or rejects it before use in the claim process.

During a tabletop, [EXTERNAL_WORKER_NAME] finds unredacted health information in an attachment. The data row says stop. Escalation routes it to [PROVIDER_PRIVACY_ROLE] and [INSURER_PRIVACY_ROLE]. The original remains in [AUTHORISED_SOURCE_SYSTEM], and named people preserve evidence and assess notifications. The test fails because no current after-hours provider contact can suspend access.

The owners add a verified revocation contact and suspension method, then repeat the scenario. The exercise does not declare a legal data breach. Authorised privacy, security and legal functions assess the facts.

For APRA-regulated entities, CPS 230 adds a specific prudential context. The replacement determination came into force on 29 April 2026, while the standard commenced on 1 July 2026 (Federal Register, APRA). It applies to entities defined in the standard, not every workplace or supplier.

CPS 230 requires an in-scope entity to identify, assess and manage operational risks that may result from inadequate or failed internal processes or systems, the actions or inactions of people or external drivers and events, and to manage service-provider risks. Its material-service-provider test turns on reliance for a critical operation or exposure to material operational risk, subject to the standard's specified categories and APRA's powers. It does not make every contractor, labour-hire firm, outsourced team or AI supplier a material service provider.

Where a relevant arrangement is material, the handshake can provide operational evidence for the entity's broader service-provider controls. It does not determine materiality, satisfy the prudential standard by itself or transfer accountability to the provider.

Use this prompt to build a tabletop scenario. Human operational, privacy, security, records, legal and risk owners must approve the scenario, interpret the result and decide any containment, notification or restart action.

Create a 25-minute tabletop test for the verified cross-boundary handshake below.

Select one supplied failure trigger. Return:
- opening facts and information deliberately withheld
- expected action for each of the six controls
- evidence each side must produce
- decision points reserved for named people
- stop condition
- gaps to record
- retest owner and date

Do not determine legal liability, worker status, regulatory materiality or notification obligations. Do not invent contact details, contract rights or system capabilities. Mark any missing authority [CONFIRM BEFORE TEST].

Verified handshake:
[PASTE HUMAN-APPROVED CARD]

Do this Monday

1. Choose one boundary and use case. Select one contractor, labour-hire or outsourced workflow using or preparing to use AI.
2. Name both owners. Assign internal and external leads who can obtain evidence and escalate gaps. Neither decides legal status or compliance alone.
3. Complete the six rows. Record the internal requirement, external commitment, evidence, mismatch, owners and review date for tool, data, review, record, escalation and incident controls.
4. Close the unsupported path. Restrict the task, data or access where a material row lacks evidence. Route legal, privacy, security, records or prudential questions to the authorised function.
5. Run one tabletop test. Use a realistic boundary failure, record what each side actually produces and repair the first control that fails.
6. Set expiry and offboarding. Review the card when the use case, tool, provider, data, contract or people change. Test access removal when [EXTERNAL_WORKER_NAME] or [SERVICE_PROVIDER] leaves the work.

Bottom line

Equivalent work needs equivalent operating control, not identical employment labels or systems. Agree six cross-boundary outcomes and test whether both sides can prove them before AI-assisted work begins. Keep privacy scope, worker status and CPS 230 materiality as separate, fact-specific assessments. AI can organise the card and draft a scenario, while people authorise access, review work, assess incidents and retain every legal, employment and prudential decision.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. Federal Register of Legislation, "Privacy Act 1988", current in-force version C2026C00227, Compilation No. 104, effective 4 June 2026 and registered 17 June 2026. https://www.legislation.gov.au/C2004A03712/latest/details
2. Office of the Australian Information Commissioner, "Employee records exemption", accessed 31 July 2026. https://www.oaic.gov.au/privacy/privacy-guidance-for-organisations-and-government-agencies/organisations/employee-records-exemption
3. Office of the Australian Information Commissioner, "Guidance on privacy and the use of commercially available AI products", published 21 October 2024, updated 17 January 2025 and accessed 31 July 2026. https://www.oaic.gov.au/privacy/privacy-guidance-for-organisations-and-government-agencies/guidance-on-privacy-and-the-use-of-commercially-available-ai-products
4. Federal Register of Legislation, "Banking, Insurance, Life Insurance, Health Insurance and Superannuation (prudential standard) determination No. 1 of 2026", made 23 April 2026 and in force from 29 April 2026. https://www.legislation.gov.au/F2026L00475/asmade
5. Australian Prudential Regulation Authority, "CPS 230 Operational Risk Management", in force 1 July 2026. https://www.apra.gov.au/standards/cps-230