What makes an AI workflow governed and operable?

Approving the model is not enough

An AI workflow may retrieve organisational knowledge, call a model, wait for a person, send a message and update another system. Each step can change the outcome. Governance has to cover the whole sequence, not only the model.

Use the checklist below to identify decisions and evidence that still need an owner before release. It is a starting point for review, not a certification or a guarantee that the workflow is safe or compliant.

A practical AI workflow governance checklist

1. Purpose and owner: Is the task approved, its boundary clear and a person accountable for the service?
2. Information and permissions: Are source authority, access rights and permitted uses understood?
3. Models, tools and actions: Are calls bounded and action inputs checked before another system changes?
4. Human decisions: Does the reviewer have the evidence, time and authority to reject or change the proposed action?
5. Failure and recovery: Have rejection, timeout, retry and partial failure been tested without duplicate business action?
6. Operation and evidence: Are versions, tests, monitoring, incidents and change responsibilities recorded together?

For a workflow involving security-sensitive information, start with our security assurance approach. For unclear hand-offs, decisions or exceptions, review our business-process and automation readiness work.

An illustrative workflow

Imagine a staff member asking for guidance about an internal policy. The workflow searches approved policy documents, sends relevant passages to a supported model and produces a draft answer with sources. If the question could lead to an operational action, the workflow pauses for an authorised person to review the evidence and approve or reject the next step. Only then may an integration update another system.

To operate that workflow responsibly, the organisation must know which policies are authoritative, who can ask the question, what the model receives, what the reviewer must check, what happens after rejection and how the service recovers if the integration fails.

Separate the process, decision and AI behaviour

The workflow defines the sequence. Business rules or authorised people make decisions. The model performs a bounded task such as retrieval-assisted drafting or classification. Keeping those responsibilities visible makes the service easier to test and change.

A human approval step is meaningful only if the reviewer has the information, time and authority to disagree. A button labelled “approve” does not create accountability.

Control inputs, tools and actions

• Use approved information sources with understood owners and permissions
• Limit which models, prompts, tools and integrations the workflow may call
• Validate data before an action reaches another system
• Record which version of the workflow, prompt and model handled the request
• Prevent retries from creating duplicate messages or business records

Guidance from the National Cyber Security Centre, the Office of the Privacy Commissioner and the Public Service AI Framework can help inform the relevant controls.

Design the failure path before release

Make waiting, rejection, timeout, retry, cancellation and failure explicit. Decide which steps can run again safely, when a person must intervene and how partial actions are reconciled.

Test the complete service with missing information, conflicting sources, permission changes, model failure, unavailable integrations, delayed approval and repeated requests. A successful happy path is only one test.

Operate and change it as one service

Assign owners for the process, information, model behaviour, integrations, controls and support. Monitor completion, waiting work, failures, overrides, incidents and user impact. Keep the workflow, prompts, configuration and tests under version control and repeat the relevant assurance when they change.

A useful evidence pack

For each workflow, keep the purpose, owner, diagram, information sources, permissions, models, tools, decisions, controls, tests, approved version, monitoring, known limitations, incidents and change history together. The record should allow another authorised person to understand what happened and why.

Where Pūnaha fits

Pūnaha provides visual, versioned workflows with retrieval, model, approval and merge steps, plus developer-configured conditions and integrations. The product does not decide the organisation's purpose, source authority, approval rules or acceptable risk.

Discuss AI workflow governance, review Pūnaha's technical detail or read our New Zealand AI governance checklist.

A note about this article

This is general information from Hot Desk Consultancy Services Limited. It does not certify a workflow as governed, operable, accurate, safe, secure, private or compliant and is not legal, privacy, security, architecture or operational advice.