Executive summary

An organisation may rely on several suppliers to deliver an AI-supported service, but the person affected should not have to untangle that chain to get help. Leaders need to know where important responsibilities sit, what evidence they can obtain and who can act when something goes wrong. This paper explains how to keep those connections workable, so that buying a service does not mean losing the ability to question it.

Who should answer when someone questions an AI-supported decision? Consider a hypothetical recruitment process: an employer uses a vendor’s platform, that platform relies on another company’s AI model and a consultant helped configure the workflow. An applicant’s request for an explanation now involves several organisations.

From the applicant’s point of view, the central concern is straightforward: someone made a decision about me, and I would like to understand it. They should not need to identify the model provider or read a software contract before the employer listens.

For the employer, answering may require evidence it does not hold. That is where governance across organisational boundaries becomes real. The issue is whether the relationships behind the service allow an important question to reach someone who can answer it and return to someone who can do something useful.

Know which handovers matter

A supplier relationship often contains sensible divisions of work. One company develops a model, another runs the software and the customer decides how staff use it. Different parties can take responsibility for different tasks without everyone being responsible for everything.

Trouble begins when the handovers are assumed rather than understood. The employer may believe the supplier checks the suitability of recommendations for its recruitment process. The supplier may assume the employer performs that check. Each can point to a functioning part of the service while the gap between them remains unattended.

Current Australian implementation guidance recommends clarifying shared responsibilities for monitoring, human oversight, incidents and updates across the AI supply chain. [1] This is voluntary guidance, not a complete statement of legal liability. Suppliers may have duties of their own; the applicable law, professional obligations, contracts and facts need separate consideration.

For a significant use, start with the decisions that matter locally. Who checks whether the output is suitable for this task? Who receives notice of a change? Who can restrict the local use while a concern is investigated? Those answers are more useful than a diagram that lists companies without explaining how they work together.

Ask for evidence you can use

Paper 5 considered procurement and vendor relationships. A contract can give the customer rights to information, but those rights need to work in practice. Receiving a technical report is of limited help if nobody can tell whether it addresses the concern.

In our recruitment example, the employer might need to understand how a recommendation was produced, what information was considered and what limitations are known. General claims about the model’s accuracy may not answer a question about the employer’s particular workflow or applicants.

Some technical details may reasonably be withheld for privacy, security or commercial reasons. The customer does not necessarily need every detail of the underlying model. It does need enough understanding to judge its intended use. Any important gap should remain visible rather than being treated as resolved because the supplier has offered an explanation for withholding information.

Sometimes an independent test, a narrower use or an additional safeguard can reduce the uncertainty. Sometimes the organisation will be unable to obtain enough evidence to justify the use. Deciding not to proceed can be a sound outcome of the assessment.

Information also needs to travel back upstream. A supplier cannot investigate an unexpected local outcome it never hears about. The customer’s experience may reveal a limitation that general testing missed. Useful oversight therefore involves an exchange, not simply a folder of supplier certificates.

Look beyond the company on the invoice

One contract may sit above several important dependencies. A platform could use another provider’s model, external infrastructure and local integrations. An upstream change can affect the service even though the customer has not bought anything new.

This does not call for cataloguing every software component. Focus on dependencies whose failure or alteration could materially affect people, information or the ability to continue safely. A routine drafting tool may warrant modest attention. A system influencing employment, care or essential services deserves closer scrutiny.

NIST’s voluntary AI Risk Management Framework addresses third-party risks and contingency arrangements for failures in high-risk dependencies. [2] The practical question is whether the organisation knows where a material problem could arise and what it would do if that happened.

Suppose the recruitment platform changes its underlying model. Who tells the employer, and can the employer understand whether earlier testing still applies? Paper 10 examines that question of continuing approval. A supplier’s change process needs to connect with the customer’s decision about continued use.

Follow a concern all the way back

A prompt incident notice can still fail if it lands in an inbox nobody associates with the affected service. The route needs a named recipient who understands the local use and knows who can make the next decision. Deputies and realistic response times matter where the consequences cannot wait.

The same is true in the other direction. The applicant’s concern should reach someone able to gather the relevant evidence from suppliers. The employer then needs to interpret it, reconsider its own process where warranted and respond to the applicant. Referring them to a vendor help desk may leave the original question unanswered.

Paper 8 explored assurance: the evidence that safeguards actually work. Where a supplier performs an important check, the customer needs proportionate evidence about that check, rather than assuming that the commercial relationship provides assurance by itself. A useful test is to trace one concern through the arrangements before anyone has to depend on them in earnest.

Ask what happens if the relationship ends, too. Necessary records may still be needed to explain earlier decisions after access to a supplier’s portal closes. A workable exit should preserve what the organisation is required to retain and provide a safe alternative to an unacceptable service.

Keep local judgement connected

External platforms can provide useful capabilities that a regional organisation could not reasonably build alone. The aim is to make that reliance governable, with enough understanding and authority to protect the people using the service.

There may be opportunities for institutions to share protected lessons about suppliers, useful questions and recurring weaknesses. BRAIN could help that understanding accumulate while each organisation remains responsible for its decisions. Shared dependencies are a possibility to investigate, not an established measurement of Ballarat’s exposure.

Any sharing must respect permissions, confidentiality and the risk that local context identifies someone even after names are removed. Useful learning does not require circulating private case files.

Start with one consequential service and follow a plausible question from the person affected to the external party holding the evidence, then back to the local decision-maker. Where does it slow down or stop? That is the connection worth strengthening.

The applicant should not have to solve the supplier relationship. They should encounter an organisation willing and able to pursue their question through it.

About BRAIN

The Ballarat Region Artificial Intelligence Network (BRAIN) is a regional institution focused on understanding the impact of artificial intelligence across Ballarat and surrounding communities and strengthening the capability required to respond. Through research, publications and regional collaboration, BRAIN examines how AI can contribute to regional prosperity and wellbeing while helping institutions navigate its risks and wider consequences.

About the Author

Matt Bowd is Co-Founder and Chief Executive Officer of the Ballarat Region Artificial Intelligence Network (BRAIN). His work focuses on AI governance, institutional capability and the implications of artificial intelligence for regional organisations and communities.

Sources

[1] National AI Centre, Guidance for AI adoption: implementation guidance. Sections 1.2, 4.3 and 5.1; shared responsibilities and information across the supply chain; voluntary guidance.

[2] NIST, AI Risk Management Framework 1.0, Core. 2023, GOVERN 6.1–6.2; third-party risk and contingencies; voluntary framework.

Sources checked 21 October 2026.