An AI agent is ready for production only when the team can show what job it may do, which records and tools it may use, where a person must intervene, how accepted behaviour is tested, and how access can be reduced or removed. A convincing demo is not that evidence. This checklist turns the implementation decision into seven observable gates.
The checklist is written for Australian operators assessing an agent that reads or writes business systems. It is not legal, privacy, cyber security, or regulatory advice. Apply it with the controls and obligations that govern your organisation.
The seven-gate AI agent implementation checklist
Treat each gate as a decision point, not a maturity score. A gate passes when its evidence exists and the accountable owner accepts it. An unknown or disputed answer is a reason to hold scope, not to round the result up.
- Job boundary. Evidence: start event, finish event, allowed actions, excluded cases, and system of record. Hold or stop when: the job is described as a department, goal, or open-ended instruction.
- Accountable owner. Evidence: named business owner, system owner, reviewers, and incident decision-maker. Hold or stop when: nobody can approve access, exceptions, or a pause.
- Data boundary. Evidence: source register, data classification, retention rule, and test-data method. Hold or stop when: the team cannot say which records enter the agent or where they go.
- Tool and identity boundary. Evidence: separate identity, least-privilege permissions, approved tools, and an expiry or revocation path. Hold or stop when: the agent shares a human login or has broader access than the job requires.
- Acceptance evidence. Evidence: representative cases, expected outputs, prohibited actions, and regression results. Hold or stop when: testing relies on a few favourable demonstrations.
- Human stop and recovery. Evidence: review queue, escalation rules, pause control, and failed-write recovery. Hold or stop when: an uncertain or failed case can continue without an accountable person.
- Operate, support, and change. Evidence: logs, alerts, operator training, an affected-role plan, a feedback channel, review cadence, change approval, and rollback evidence. Hold or stop when: people are expected to absorb new work without support, or behaviour can change without detection, retesting, or a return path.
This is Svolta’s production-gate method: boundary, owner, data, access, evidence, stop, and operate. It adapts public guidance into a small-business and mid-market implementation artefact; it does not replace the source standards.
1. Bound one operational job
Write the job in floor language. Name the event that starts it, the record that proves it is finished, the systems it may touch, the actions it may take, and the cases that remain outside scope.
“Help the operations team” is not a job boundary. “Read a new service email, extract the required fields, draft a job record, and send incomplete packs to review” is bounded enough to inspect. The boundary should also state what the agent must not do, such as sending an external message, approving a payment, or changing a customer status.
If the workflow is still unclear, map the process before choosing the agent. A production decision made against a vague job cannot produce a meaningful acceptance test.
2. Assign people who can make the decisions
Name the business owner, the owner of each connected system, the people reviewing exceptions, and the person who can pause operation. Record their authority as well as their names or roles.
The National AI Centre’s Guidance for AI adoption calls for documented accountability across development, deployment, testing, human oversight, incidents, and system updates. Its accountability question applies directly to a business system: who may accept the behaviour, and who acts when it is outside the boundary?
The gate is not passed by a steering group with no operational owner. Someone must be able to grant access, accept the test evidence, resource the review queue, and order a pause.
3. Register data before connecting it
List every source the agent reads, every destination it writes, the fields it uses, the reason each field is required, and how long copied data is retained. Separate production records from test records. Mark personal, sensitive, confidential, licensed, or contract-restricted material for the appropriate internal review.
The National AI Centre guidance asks organisations to document data sources, collection processes, usage rights, privacy and confidentiality constraints, and the data used for testing and inference. It also recommends monitoring for leakage of personal and sensitive information. Use those questions as evidence prompts, then apply your own privacy, security, contractual, and industry obligations.
If the team cannot trace a field from source to action and log, restrict the scope until it can. Convenience is not a data boundary.
4. Give the agent its own constrained access
An agent that can act in a business system needs an identity and permission set designed for that job. Avoid shared human accounts. Allow only the records, actions, environments, and time windows the workflow requires. Document how credentials are issued, rotated, suspended, and revoked.
The Australian Signals Directorate’s guidance on careful adoption of agentic AI recommends distinct agent identities, fine-grained privileges, constrained objectives, isolation, phased access, and fail-safe escalation. The same source recommends increasing autonomy progressively and reducing it when evaluation or operating evidence does not support the wider scope.
Review permission at the action level. Read access to a job queue, creating a draft, changing a live status, and sending a message are different authorities. Approving one does not imply the others.
5. Test the accepted path and the prohibited path
Create a fixed evaluation set from representative, permission-safe cases. For each case, record the expected source use, output or action, human stop, and unacceptable behaviour. Include missing fields, conflicting records, ambiguous instructions, unavailable tools, and attempts to move outside the allowed job.
Run evaluations before expanding the agent. A pass needs the test set, results, reviewer, version, and decision. A model name or prompt screenshot is not acceptance evidence.
Retest when the model, prompt, connected tool, retrieval source, business rule, or permission changes. A change that seems small to the build team may alter behaviour at the workflow boundary.
6. Make human stops and recovery visible
Define the conditions that stop autonomous work and route the case to a person. Examples include a missing required field, conflicting source records, a prohibited action, unavailable destination, failed write, or case type outside scope. The reviewer needs the source context, attempted action, and reason for the stop.
Also design recovery. Can the team identify a partial write, prevent a duplicate retry, restore the previous record, and resume or close the case deliberately? A generic error message is not a recovery method.
The Australian Government proof-of-concept-to-scale checklist asks for defined success criteria, production pathways, representative testing, monitoring, feedback, and workforce support. Those prompts help distinguish a controlled pilot from an unsupported production hand-off.
7. Operate, support people, and roll back
Before launch, prove that an operator can answer: what did the agent attempt, which sources and tools did it use, what was written, where did it stop, and who reviewed the exception? Set alerts for conditions that matter to the workflow rather than collecting logs nobody reads.
Train the people who will operate, review, support, or be affected by the workflow. Record how their work changes, where instructions live, who answers questions, how they report unexpected behaviour, and how feedback reaches the owner. Check whether the review queue and support load are workable during the controlled rollout; access should not expand while operators are absorbing an unsupported process.
Record the review cadence, who can approve changes, which tests rerun, and what triggers a reduction in access. Keep a rollback path for configuration, permissions, prompts, integrations, and the workflow state affected by an action. Practise the pause and recovery path before relying on it.
ASD recommends continuous monitoring and auditing of agent operations, identity and privilege changes, tool use, retrieved information, anomalous behaviour, and drift from approved objectives. Monitoring is therefore part of the operating boundary, not a dashboard added after implementation.
How to use the checklist for a launch decision
Use three decision states:
- Proceed within the tested boundary. Every gate has reviewable evidence, the owners accept it, and the agent’s access matches the tested job.
- Hold and close a named gap. The workflow may be viable, but one or more gates lack evidence. Name the owner, artefact, and retest required before reconsidering the decision.
- Stop or choose a simpler approach. The job has no stable boundary, accountable owner, lawful and usable data path, controllable access, or meaningful acceptance method.
Do not total the gates into a readiness percentage. A missing revocation path cannot be cancelled out by good documentation elsewhere.
What belongs in the implementation pack
Keep the evidence together: workflow map, job boundary, responsibility map, data and tool register, permission specification, evaluation set and results, human-stop rules, operator training and affected-role plan, feedback path, operating runbook, incident contacts, change log, and rollback record. The pack should be readable by the business owner and operators as well as the build team.
The broader buyer guide is AI agents for business. The production disciplines behind the operating layer are covered in agentic workflows that survive production.
If the workflow is bounded but the implementation pack and production controls do not yet exist, Workflow Launch is the single commercial path for turning the accepted scope into an operated system. The service page remains the source for current scope and pricing.