From an agent pilot to a system you can run

A pilot is a controlled demonstration. Someone points a model at a task, often with a person nearby, and the organisation learns whether the idea is worth a longer look. Production is a different object. The agent takes steps while people are busy. It calls tools. It sees data. It can be wrong at a speed and a scale a slide does not show.

This briefing is a gate for that change, written for CIOs, CTOs, risk owners and the infrastructure leaders who will be asked to host the system. It follows public Australian guidance. It is not legal advice, and it is not a certification.

What changes between the demo and the working day

In a pilot, the operator is the control. They notice a bad answer. They do not let the tool send the email, move the money, or write the record. In production, that person is not in the loop unless you put them there.

The design questions follow from that.

• Identity. Which account does the agent use, and can security revoke it this afternoon?
• Tools. Which systems may it call, and which actions are forbidden even if the model asks?
• Data. What is allowed into the prompt, the retrieval index and the logs? Where does that data sit?
• Evaluation. On what set of cases did you decide it was good enough, and what was the threshold?
• Cost and failure. What does a run cost, what happens when a dependency times out, and how do you turn the agent off?
• People. Who is affected when it is wrong, and how do they challenge the outcome?

An agent that cannot reach a system of record will not change the business. An agent that can reach one, without an allow-list, an identity and a log, will change it in ways you hear about from someone else. The path into those systems is described as integration work on the AI integration page. The compute underneath, when you need your own, sits with the AI Factory practice.

The Australian guidance to design against

Australia has a public set of documents for this, and they have moved recently. Use the current ones, and say which version you designed against.

The Department of Industry, Science and Resources still publishes Australia’s AI Ethics Principles (opens in a new tab). The page lists eight: human, societal and environmental wellbeing; human-centred values; fairness; privacy protection and security; reliability and safety; transparency and explainability; contestability; and accountability. The same page points readers to the newer Guidance for AI Adoption as the practical update. The principles were first published in 2019 and the page records later updates.

The Guidance for AI Adoption (opens in a new tab) was published in October 2025. It sets six essential practices and evolves the Voluntary AI Safety Standard (opens in a new tab). The department is explicit that this line of guidance is voluntary and does not, by itself, create new legal obligations. Existing law still applies. The department’s note on the legal landscape (opens in a new tab) is the right pointer for counsel. Do not treat a blog post as that advice.

The six practices, in the government’s words, are:

1. Decide who is accountable.
2. Understand impacts and plan accordingly.
3. Measure and manage risks.
4. Share essential information.
5. Test and monitor.
6. Maintain human control.

There is a shorter “Foundations” version and a fuller “Implementation practices” version. Use Foundations to start the conversation with a leadership team. Use the implementation guidance when the use case is material, when you are building the system rather than only buying it, or when you already have a governance function that can absorb detail. The foundations page (opens in a new tab) is a fair place to begin.

ISO/IEC 42001:2023 is the international management-system standard for AI. It is a way to organise roles, risk and improvement over time. An organisation can align its operating model to it. Alignment is a choice you record. Dynacore does not claim certification, and a project that “references ISO 42001” has not, by that sentence, been assessed.

A production gate

The list below is our shorthand for an agent that is about to touch a real process. It is not a quotation of the government text. Map it back to the six practices when you write the internal paper, so an auditor can see the join.

A named owner. One senior owner for the program, and a named owner for this agent. The owner can describe the decision the agent influences and the harm if it is wrong. If the owner cannot do that, the use case is not ready.

An impact note. Who can be affected: customers, staff, applicants, the public. Extra attention where the impact falls on people with less ability to complain. A channel to challenge the outcome, scaled to the impact. Contestability is one of the eight principles, and it is easy to leave as a sentence. Name the inbox, the queue, or the person.

An allow-list. The tools, APIs and data sets the agent may use. Everything else is out. High-impact actions, such as payments, access changes, or writes to a system of record, either stay with a person or carry an approval step you have tested.

An identity. The agent runs as a principal your directory can show, with least privilege, a rotation method and a revoke method. Shared passwords pasted into a prompt are not an identity design.

An evaluation set. Cases you curated before go-live, including the awkward ones: missing data, hostile input, a tool that fails, a question the agent should refuse. A threshold that is written down. A decision record of who accepted the result.

Logs and a rollback. Enough of a record to see what was asked, which tool was called, and what changed. Retain it under the same privacy rules as the data it contains. A way to undo, or to compensate, when an action should not have happened. A switch that stops the agent without stopping the business process entirely.

A privacy check. Personal information may sit in prompts, retrieval stores, tool arguments and logs. The Australian Privacy Principles (opens in a new tab) are the public reference. If the use case collects, uses or discloses personal information, the privacy team should see the data flow before go-live, including whether a vendor’s service stores that information outside Australia.

A cost ceiling. Agents that loop, or that call an expensive model on every trivial event, will discover your budget for you. Set a limit, alert on it, and decide the behaviour when the limit is hit.

None of these items requires a particular product. They require a decision and a place to write it down.

Where infrastructure shows up

Governance documents sometimes float free of the platform. They should not.

The evaluation set and the logs need a home, a retention rule and access control. The model, if you host it, needs the capacity and the network path described in an AI factory plan, including the power and cooling reality of the hardware. A retrieval index is a data store with a backup and a restore. Secrets for tools belong in a secret store, not in a notebook. The kill switch has to be real in the environment the agent runs in, not only in a policy PDF.

If the agent calls a hosted model, the contract has to cover the same facts: what is retained, where it is processed, who can see it, and how you get an export or a deletion when you need one. “The vendor is certified” is not a data-flow diagram. Ask for the diagram.

A sensible order of work

Teams that succeed at this tend to move in a boring order.

1. Pick one process with a patient owner and a visible cost of being wrong.
2. Write the impact note and the allow-list before the prototype hardens.
3. Build the evaluation set from real cases, with the operators who do the job today.
4. Run the pilot against that set, with production identity still turned off.
5. Turn on the smallest useful tool, under the allow-list, and read the logs for a defined period.
6. Only then remove the human from a step, and only for the cases the evaluation covered.

Skipping to step 6 because a demonstration went well is how pilots become incidents. The Guidance for AI Adoption (opens in a new tab) is patient about this for a reason: accountability, impact, risk, transparency, testing and human control are sequential habits, not a slide at the end.

What to ask for in the next meeting

If you are the executive being asked to approve a pilot’s promotion, ask for five artefacts. A one-page description of the decision the agent influences. The allow-list. The evaluation result against a threshold. The identity and the log sample. The name of the person who can stop it, and the name of the person a customer or employee can reach.

If any of the five is missing, the honest status is still “pilot”. That is a useful status. It is not a failure of ambition. It is a description of the controls you have actually built.

Dynacore helps Australian organisations design this gate and the integration underneath it. The practice page is Agentic AI. A briefing starts on the contact page.