AI Deployment and the Reasonable Steps Problem

The gap

Boards are deploying AI into high-volume operational decisions while retaining accountability structures designed for deterministic systems. This creates a gap between how decisions are made and how responsibility is exercised—a gap that existing governance frameworks do not address.

How AI reintroduces prohibited behaviours

Large language models learn from historical data. That data encodes past organisational behaviour—including behaviours that were once legal but are now prohibited under Australian law. The optimisation functions that make AI effective at operational decisions will rediscover these patterns precisely because they worked. This is not a design flaw. It is how the technology functions.

Output shaping—alignment techniques, bias filters, fairness constraints—operates at the wrong layer. It can modify what the system produces. It cannot reach back into what the system has learned. The patterns remain in the model. The risk does not go away because the output has been shaped.

The legal exposure

Australian discrimination law does not require discriminatory intent. Disparate impact—outcomes that disadvantage a protected class—is sufficient to establish liability. This is the operative standard.

The exposure crystallises at the intersection of three facts:

First The presence of prohibited patterns in training data is documented and publicly evidenced.

Second Deployment of an AI system that produces discriminatory outcomes is sufficient for liability—regardless of whether the system was designed to discriminate.

Third The Workday ruling (US, 2024) confirmed this direction of travel. Australian regulatory trajectory follows.

Once the evidence of prohibited patterns in training data is established as a known risk, the question for regulators and courts becomes: what did the organisation do to prevent those patterns from being installed in current operations? That question applies to every AI system already deployed.

Where the risk concentrates

Not all AI deployments carry equal exposure. The risk concentrates in a specific profile:

High volume Statistical patterns express at scale. A handful of edge cases becomes a systematic outcome.

Optimised The optimisation function searches for what predicts the target variable—and historical patterns do.

Operational Decisions with real consequences for real people: hiring, lending, insurance, benefits, service allocation.

This profile is the governance triage test. It identifies where the reasonable steps obligation is most exposed and where board liability attaches first.

What reasonable steps looks like

Technical compliance does not reach this problem. Documenting the model, following vendor best practice, and running pre-deployment bias testing are necessary but not sufficient. They address the design layer. The problem is in the data.

A defensible governance position requires three things:

1 Map what is in the data. Enumerate known prohibited patterns and proxies. This is not a one-time audit—the data changes.

2 Instrument the outputs. Monitor for the expression of known patterns in operational decisions. Treat detected patterns as signal, not noise.

3 Document the decision trail. Before deployment, and on an ongoing basis, boards need evidence that the right questions were asked—not just that the model was built correctly.

The 'don't deploy' option is underused. For high-volume operational decisions, the risk/benefit calculation often does not close once liability exposure is properly priced. Deployment decisions made under competitive pressure, without a documented governance trail, are the most exposed.

The board question

Current AI governance frameworks are built around design intent. They ask: was the system built correctly?

The regulatory direction of travel—in Australia and internationally—is toward a different question:

You knew the prohibited patterns were in the data. You could not fully isolate them. What did you do to prevent them from being installed in current operations?

This is not a technical question. It is a governance question. The answer does not live in the model documentation. It lives in the board papers, the pre-deployment decisions, and the ongoing monitoring records.

Most organisations cannot yet demonstrate a defensible answer.