AI governance is the system of owners, policies, technical permissions, validation, review and monitoring that determines how AI may be used and who is accountable for its outcomes. A tool that summarizes an internal document without changing anything needs different controls from a workflow that updates a customer record or sends a message.
In practice, inventory each use case, classify its data and actions by risk, assign an owner, limit access, validate outputs, gate consequential actions and monitor results. Governance covers the whole workflow before and after an AI call, not just a model approval form or a check for legal compliance.
This guide focuses on operating design: how to decide what an AI-assisted workflow may do, what must be checked before a write, and how to preserve enough evidence to explain the result later.
Govern the action, not just the model
Assess a workflow by its purpose, data sensitivity, affected people, destination system, reversibility and the impact of an incorrect result. Then give the AI-assisted process the least authority it needs:
- Read: retrieve or summarize information without changing a system.
- Recommend: suggest a category, priority or next step for a person to consider.
- Draft: prepare a message or record change that remains unsubmitted.
- Write: update a system of record or send a communication.
- Execute: take an action that is difficult to reverse, such as issuing funds or changing access.
Controls should increase as authority and potential impact rise. Name a business owner accountable for the outcome and a technical owner responsible for operating the workflow. Record both in a workflow inventory.
Use deterministic rules wherever the decision is fixed and testable: required-field checks, authorization, date parsing, allowed values, monetary thresholds and duplicate detection. AI is more useful for bounded tasks with meaningful ambiguity, such as summarizing unstructured text or proposing a classification. Validate that proposal separately before acting on it.
The governance burden should rise with data sensitivity and action authority, not with the model’s brand name.
Choose a framework for the job it does
Frameworks can organize an operating approach, but choosing one does not establish that an organization complies with law. Select a management approach for the work it helps you do, then separately identify legal duties that apply to your role, use case, data and jurisdiction.
- OECD AI Principles: an international, values-based reference updated in 2024. Current OECD material says 48 countries and the European Union have adhered. The Principles are not a directly enforceable business regulation. Read the OECD overview.
- NIST AI Risk Management Framework: a voluntary risk-management structure organized around Govern, Map, Measure and Manage. The functions are not a mandatory ordered checklist, and governance applies across the AI lifecycle. It can be a flexible starting point for internal processes. Review the NIST AI RMF core and its voluntary implementation Playbook.
- ISO/IEC 42001: an AI management-system standard for organizations that want a formal system for managing AI. Implementation is possible without certification. Certification is voluntary and, if sought, is performed by an independent certification body, not ISO. See ISO’s explanation.
- EU AI Act: a binding EU regulation with requirements that apply in phases and vary by system, role and context. The European Commission’s timeline says prohibitions and AI-literacy obligations began applying in 2025, while transparency rules generally apply from August 2, 2026. Check the current Commission overview and statutory text for the relevant use.
- GDPR: governs personal-data processing, including relevant AI uses. Article 22 addresses specified decisions based solely on automated processing that produce legal or similarly significant effects. It includes exceptions and safeguards; it is not a categorical ban on automated decisions. Read the GDPR text.
These obligations are jurisdiction- and use-case-specific. OECD and NIST materials are voluntary references, and an ISO management system is not a substitute for applicable law. Seek qualified legal advice for a determination about a particular deployment.
Turn policy into a controlled workflow
The following comparison uses hypothetical business workflows. It separates the source event, AI run and destination action so each can be reviewed and traced independently.
| Trigger and source | AI responsibility | Validation and destination | Human fallback |
|---|---|---|---|
| Employee submits an internal document for a summary. | Summarize the supplied text. Do not make a decision or write to another system. | Check that the source is authorized for the intended use. Save the summary with a reference to the document, or return it to the requester. | If the summary omits a critical point, the requester consults the source and corrects it. |
| New support ticket arrives in the ticketing system. | Propose a category and priority from controlled options. Do not close or reassign the ticket. | Check allowed values and required evidence before saving a proposal to the ticket or a review queue. | Unsupported category or conflicting evidence goes to the support lead. A missed urgent issue is escalated under the existing service process. |
| Customer interaction arrives for an existing CRM record. | Propose a category and specific field changes from the interaction. Do not authorize the CRM write. | Validate the record, field types, allowed values, permissions and freshness. After any required approval, write to the CRM. | A stale record or disputed change goes to the CRM process owner. No write occurs until resolved. |
For the CRM example, a plausible sentence is not a sufficient write condition. Confirm that the source record still exists, the proposed fields are permitted, values match their expected types and allowed options, and the record has not changed since the proposal was produced. A CRM process owner should approve material changes defined by policy. For help designing CRM ownership and field controls, see CRM systems consulting.
A proposed output contract can keep the AI response bounded and make validation errors explicit. This is an illustrative design, not a vendor template:
{
"status": "review_required",
"category": "account_update",
"evidence": [
{
"source_event_id": "evt-10482",
"locator": "message span 2"
}
],
"proposed_changes": {
"preferred_contact_channel": "email"
},
"policy_version": "crm-policy-v3",
"model_id": "recorded-model-id",
"prompt_version": "crm-extraction-v2",
"validation_errors": []
}Keep evidence references, model output, validation result, reviewer decision and destination write separately identifiable. This distinguishes what the customer said from what the AI proposed and what the CRM ultimately stored.
Build controls around data, permissions and failure
Route malformed output, missing evidence, unsupported values, stale records, policy-threshold breaches and failed authorization to review or rejection, not a best-effort write. Deterministic checks should validate required fields, enumerations, ranges, destination permissions and record existence. A model confidence score is useful only if the organization has defined how that score is calibrated and what threshold changes the action.
Define what one record represents before choosing a unique key. A source event, an AI run, an evidence citation, a reviewer decision, a destination write and an aggregate report are different records. A proposed per-run key might combine source_event_id, workflow_version, model_id, prompt_version and attempt_number. Do not use a date alone to identify individual runs, citations or writes.
Retries and concurrent workers can create duplicate actions. A lookup-then-create sequence can race if two workers check at the same time. Where supported, enforce uniqueness in the database or use a transactional upsert. Store references to sensitive payloads instead of copying full personal data into logs where possible, and set access and retention rules for the chosen record store.
A retry should find the same intended action, not create another one. Give each source event and workflow version a stable run identity, enforce uniqueness or update atomically where the destination supports it, and keep aggregate reporting keys separate from event-level keys.
Assign owners and monitor what changes
Each use case needs an accountable business owner and a technical owner. Add legal, security, privacy or domain reviewers where the risk warrants them. An inventory record can include:
workflow_id, purpose and business owner;- technical owner, data categories and connected systems;
- permitted actions, risk tier and human-review rule;
- policy, model and prompt versions, plus next review date.
Monitor exception and failure rates, rejected or corrected proposals, unauthorized-action attempts, stale-write rejections, incident reports and approval delays. Reassess when the model, prompt, data scope, destination, permission set or business purpose changes. The business owner decides whether the use remains acceptable; the technical owner investigates operational exceptions.
Where automation platforms fit, and where they do not
An automation platform can supply useful connection and access controls, but it cannot decide the organization’s risk tolerance, legal basis, approval policy or correct business outcome. Zapier says its app credentials are stored in managed connections so agents and MCP clients do not receive raw third-party tokens. It also documents controls for available apps and actions, audit-log capability, and managed MCP mode, where administrators select available actions. Field values can be locked for supported tools. Capabilities depend on the product, account, workspace and connected app configuration.
Managed mode does not itself establish human approval for every action. Configure the permitted tools, distinguish read access from write access, test the actions exposed to the AI client and verify the required review process separately. Switching MCP modes may also require refreshing the AI client’s cached tool list. Zapier’s public directory currently advertises 9,000+ app integrations, but triggers and actions vary by app. These are vendor statements, not independent evidence of outcomes or universal plan behavior. For configuration support, see Zapier automation services; for evaluating a connected agent workflow, see AI agent design and implementation.
Before enabling a vendor or agent, ask what data is retained, whether workflow data is used for model training, which subprocessors receive data, what permissions are exposed, what logs are available, and how revocation behaves in the actual configuration. Confirm details against the product and plan you will use.
A practical first implementation
Start with one live workflow rather than a policy document detached from actual use. Choose a bounded task with a clear owner, known system of record, reversible output and measurable result. Run in draft or shadow mode where feasible, compare proposals with human decisions, and only then decide whether write authority is justified.
- A named business owner and technical owner are recorded.
- Inputs, connected systems and permitted actions are documented.
- Output schema and deterministic validation rules are tested.
- Failures have a defined human fallback and exception owner.
- Source events, AI runs, approvals and destination writes can be traced separately.
- Retries cannot create duplicate writes, and success measures are defined.
Measure whether the workflow helps without shifting hidden work to reviewers: track useful accepted proposals alongside corrections, rejected outputs, processing delays and incidents. Use the results to refine controls before extending the pattern to workflows with similar risk.
Frequently asked questions
How do AI governance, AI ethics and AI compliance differ?
AI ethics describes principles about what is acceptable. AI governance turns those principles into owners, policies, permissions and controls. AI compliance means meeting external legal or regulatory obligations that apply to the organization.
When should a person approve an AI-assisted action?
Base approval on impact and authority. An internal summary with no system write may not need individual approval. A customer-facing message or material record change may need review. Financial actions, employment decisions, legal notices, access changes and regulated decisions may warrant specialist or dual approval. Missing evidence, stale data, unauthorized destinations and invalid output should be rejected or escalated rather than approved by default.
Does the EU AI Act require disclosure for every AI output?
No. Article 50 sets transparency duties for specified systems and contexts; it does not impose one disclosure rule on every AI-generated output or internal use. Check the European Commission’s Article 50 guidance and the Act for the particular situation.
Does Zapier managed mode automatically add human approval?
No. Zapier documents selected-tool controls and supported field locking in managed mode. The organization must configure access and establish any human approval its business policy requires.
The next practical step is to inventory one live workflow: identify its trigger, data, AI task, destination, action authority, owner and manual fallback before granting it permission to write.