Which AI Actions Need Human Approval? A Practical Decision Framework

“Should this AI action require human approval?” sounds like a simple risk question. It is not.

A low-risk action may still require approval because policy says so. A high-risk action may be permitted inside a narrowly scoped, time-limited integration policy. A read can expose sensitive information without changing a record, while a routine update can become consequential at scale.

The more useful model is:

Approval decision = effect × risk × policy × execution-time authorization

This is an editorial decision aid, not a Figena architecture or policy-engine name, and it is not a numerical score. A team should understand what the action will do, evaluate possible harm, apply its specific rule, and confirm that the actor remains authorized at execution. If any gate is unclear, the system should pause, narrow the request, create a draft, or keep the work manual.

That approach is more durable than a blanket rule such as “all AI writes need approval” or “only high-risk actions need approval.” It also fits how Figena separates Cilila AI, product workflows, and OpenPort: different surfaces can share governance principles without pretending that every action has the same execution path.

Key takeaways

• Classify the effect first: read, recommend, draft, or execute. The presence of AI does not by itself determine whether approval is needed.
• Evaluate risk using impact, sensitivity, scope, reversibility, external consequences, and uncertainty—not a single generic “high” or “low” label.
• Apply the action’s actual policy. A role, domain, workflow, customer requirement, or integration setting may require a person, permit constrained automation, or prohibit execution entirely.
• Recheck authorization at execution time. Permission when a draft was created is not a promise that the same action remains allowed later.
• Cilila’s product-native mutation path prepares a reviewable action draft for explicit confirmation. Read, recommendation, and explanation work do not become mutations merely because they appear in the same assistant.
• OpenPort is draft-first by default, but an integration can conditionally auto-execute supported actions when its current identity, scopes, target access, policy, idempotency, and any configured expiry or action allowlist all pass.
• Compliance, legal, tax, and government work may have a manual boundary. Approval inside Figena does not create a filing connection, professional judgment, or authority the product does not have.

Start with the effect, not the label “AI”

The same business effect can begin in a form, import, scheduled workflow, integration, or assistant. Building rules around the “AI” label creates inconsistent controls. Start with the effect on business state.

Read: understand without changing business state

A read retrieves or analyzes information. Examples include summarizing cash movement, finding overdue projects, comparing budget periods, or opening a client’s history.

Reads usually do not need business approval because there is no mutation. They still need authorization: a project summary is not equivalent to an export containing financial details, employee records, or attachments. Field permissions, workspace boundaries, and export limits still matter.

This distinction prevents approval dialogs from becoming a substitute for access control. If a person or integration is not allowed to see the source records, asking someone to click Approve after the data has already been retrieved is too late.

Recommend: suggest without changing state

A recommendation surfaces a judgment or next step. Cilila might suggest a transaction category, flag an unusual amount, explain a variance, or propose which follow-up deserves attention.

The operator can accept the reasoning, disagree with it, or use it as a prompt for investigation. No business record changes just because the recommendation exists. The important controls are source visibility, uncertainty, and a clear distinction between observed facts and the system’s interpretation.

Draft: prepare an exact proposed change

A draft turns intent into structured, review-ready work. It should make the target, proposed fields, expected effect, and relevant context visible before commitment.

Examples include a proposed transaction update, a vendor change, an appointment record, or a prepared external-action packet. A draft can be useful even when the eventual action is not risky: it separates preparation from commitment and gives the operator a stable object to inspect.

Drafting is not execution. “Prepared” or “awaiting confirmation” must not imply that the underlying record or external system has changed.

Execute: create a real effect

Execution changes authoritative state or initiates an external consequence. It may create, update, delete, publish, export, send, grant access, or invoke a supported provider operation.

This is the point where approval policy matters most—but approval is only one possible control. Depending on the action, the correct result may be:

• execute immediately under current user authority;
• require confirmation of a prepared draft;
• require a different or additional reviewer;
• allow policy-bound auto-execution;
• reject the action because current authority or evidence is insufficient;
• hand the work to an authorized person or external system.

The goal is not to insert a person into every path. It is to match the control to the real effect.

Evaluate risk as a shape, not a color

“High risk” is useful shorthand, but it is not enough to design an approval rule. Two actions with the same label may need very different controls.

Consider six dimensions:

1. Impact: What changes if the action succeeds? A memo edit and a role change are both writes, but their consequences differ.
2. Scope: Does the action affect one record, a bounded batch, an entire workspace, or an external audience?
3. Sensitivity: Does it involve financial details, personal data, credentials, attachments, or regulated information?
4. Reversibility: Can the effect be safely undone? A correction with a known prior value differs from a sent message, disclosed export, or completed external submission.
5. External consequence: Does the effect remain inside Figena, reach a connected provider, communicate with a customer, or enter an official portal?
6. Uncertainty: Are the target, source revision, assumptions, and expected result clear? Ambiguity can make an otherwise routine action unsafe.

Risk also changes over time: a one-record update may become a batch, a source may change, an integration may lose a scope, or an automation window may expire. Risk classification informs policy but does not replace it.

Use policy to decide the control

Policy translates the action’s effect and risk into a rule. It answers questions such as:

• Which role or capability may initiate the action?
• Is the action always draft-first in this domain?
• May an integration auto-execute it, and under what limits?
• Does the amount, record count, destination, or data class change the route?
• Is a second person required because the requester cannot approve their own work?
• Must the action include a justification, impact preview, source revision, or preflight result?
• Is execution unsupported, so only a manual handoff is allowed?

Policy should be attached to a stable action identity, not inferred from button text or an assistant’s prose. “Update vendor,” “export transactions,” and “change member access” are different actions even if all appear as a generic Confirm button.

A preference for fewer prompts cannot override tenant isolation, missing scope, a domain-enforced draft requirement, or an unsupported legal or government action.

Reauthorize when execution begins

An approved draft is evidence of a decision at a point in time. It is not a bearer token that can bypass future checks.

Before execution, the system should re-evaluate the current actor, workspace, target access, action scope, policy constraints, and relevant source state. If the requester lost access, the integration key was revoked, the target moved to another tenant, the action changed, or the source revision is stale, execution should stop or return to review.

This execution-time check closes an important gap. Without it, a draft prepared under yesterday’s permissions could execute after a role downgrade. A previously valid impact preview could be applied to a record that no longer matches it. A time-limited automation rule could silently behave like a permanent authorization.

For retried actions, an idempotency key or equivalent stable identity helps distinguish “continue the same effect” from “perform it again.” It reduces duplicate consequences but does not make an action safe by itself.

A practical decision table

The table below is a starting point, not a substitute for each domain’s live policy.

Cilila confirmation and OpenPort auto-execution are different paths

This distinction is especially important in Figena because “AI action” can refer to more than one product path.

Cilila: review before a product-native mutation

Cilila can read authorized context, explain changes, make recommendations, and prepare structured drafts. Read and recommendation modes do not write business records. When Cilila uses the product-native mutation path, the proposed create, update, or delete is represented as an action draft and requires explicit confirmation before the domain mutation proceeds.

The confirmation should be understood as approval of a specific proposed effect, not approval of Cilila in general. The operator should be able to inspect the target and important fields, correct the draft where supported, or cancel it. When confirmation occurs, current authorization and relevant target state still need to pass.

This does not mean every Figena write uses a Cilila approval card. An ordinary workflow may save a permitted change directly, while another domain may impose its own approval route.

OpenPort: draft-first with conditional auto-execution

OpenPort governs tool and integration actions. Its safe default is draft-first: an integration can prepare an action for review rather than silently applying a mutation.

An authorized workspace can also configure conditional auto-execution for supported actions. That is not a blanket “AI may write” switch. At execution time, the request still has to satisfy the integration’s current identity, scopes, tenant and data policy, target access, idempotency, and action-specific requirements, together with any configured expiry or action allowlist. High-risk auto-execution also requires active time-bounded authorization and a justification; configured impact limits still apply, and a matching server-derived preflight is required when the current policy says so.

If those conditions do not pass, the outcome is a draft or denial—not a best-effort write. Some domains remain force-draft even under a broader auto-execute setting, and unsupported actions remain unavailable.

Risk tier alone cannot decide approval: policy may permit a constrained high-risk route while a lower-risk domain stays draft-first. Teams can review connected workflows through Figena’s integrations experience while keeping the action contract explicit.

Four hypothetical examples

These examples illustrate the framework; they are not customer stories or performance claims.

1. Explain this month’s cash movement

The effect is a read and explanation. The system should restrict the analysis to records the requester can access and make the underlying entries available for verification. No mutation approval is needed because nothing is being changed.

The risk changes if the request becomes “export every transaction with notes and attachments.” That is still not a mutation, but its scope and sensitivity are much larger. The appropriate controls may include a narrower field set, row limit, explicit export scope, and audit event. See how Figena keeps entries reviewable in transaction management.

2. Recategorize twelve transactions through Cilila

The effect is a bounded set of mutations. Cilila can prepare the proposed categories and let the operator compare the targets and impact. The operator then confirms the specific draft. Before applying it, the system rechecks current authority and target conditions.

If two transactions changed after the draft was prepared, the right response is not to rely on the old click. The affected proposal should be refreshed or rejected as stale.

3. Let an integration update a known record type

Suppose a workspace intentionally enables a supported standard OpenPort write for an exact allowlist and a limited period. The request can auto-execute only while the policy remains active and the app, key, actor, scope, tenant, target, and idempotency checks pass.

Deletion, a broad export, or a permission change is not an implicit extension. Those actions need their own scopes and high-risk policy conditions, and a domain may still require a draft.

4. Prepare a registration or notice packet

The system can organize recorded facts, deadlines, documents, review notes, and evidence into a useful packet. It can help the compliance owner see what is missing.

The effect stops at preparation. Figena does not thereby submit a government filing, complete a tax registration, or provide legal advice. An authorized person completes the official external step, verifies the result in the authoritative portal, and records the confirmation or manual outcome afterward. Internal approval cannot erase that boundary.

Design an approval that helps the reviewer

An approval step adds value only when the reviewer can make an informed decision. A generic prompt—“Allow AI to continue?”—mostly transfers anxiety to the user.

A useful review should answer:

• What exact action will run?
• Which workspace and target records will it affect?
• What values will change, and from what to what?
• How many records or external recipients are in scope?
• Which source revision or preflight result supports the preview?
• Why is the action being proposed?
• Which policy requires this review, or permits execution?
• Is the result reversible, retryable, or manually reconcilable?
• What will be recorded after success, failure, or rejection?

Figena’s applied AI research treats permission, uncertainty, provenance, and failure handling as part of product behavior. That is a helpful design standard: the control should explain the system’s boundary, not merely interrupt the workflow.

Approval-policy checklist

Use this checklist before enabling a new AI-assisted action or changing an existing automation policy.

• [ ] Name the canonical action and owning business domain.
• [ ] Classify it as read, recommend, draft, or execute based on its actual effect.
• [ ] Identify the target workspace, records, recipients, provider, or external system.
• [ ] Assess impact, scope, sensitivity, reversibility, external consequence, and uncertainty.
• [ ] Decide whether the default route is direct execution, draft confirmation, independent approval, conditional auto-execution, rejection, or manual handoff.
• [ ] Define the role, capability, app scope, and tenant boundary required to initiate and execute it.
• [ ] Define thresholds such as record count, amount, destination, field class, or time window that change the route.
• [ ] For auto-execution, require idempotency and bounded impact; for high-risk routes also require active time-bounded authorization and justification, plus any configured allowlist or limits and any policy-required preflight.
• [ ] Reauthorize the current actor, target, scopes, and policy at execution time.
• [ ] Detect stale drafts or changed source revisions before committing the effect.
• [ ] Make success, failure, denial, and reconciliation states distinct; do not label a queued or prepared action as complete.
• [ ] Record the action identity, actor, decision, relevant policy context, result, and minimal necessary evidence without turning logs into a second sensitive-data store.
• [ ] Keep unsupported compliance, legal, tax, government, money-movement, or provider effects behind their documented manual or external boundary.
• [ ] Test revocation, expiry, replay, partial failure, and policy-change scenarios—not only the happy path.

Frequently asked questions

Does every AI-generated write need a human approval?

No universal rule covers every surface. A Cilila product-native mutation is prepared as a draft for explicit confirmation. An ordinary product form follows its domain’s normal policy. An OpenPort integration is draft-first but may conditionally auto-execute a supported, allowed action when every current policy and authorization check passes.

Does every high-risk action always require a person?

Not solely because of the label. Some high-risk actions can be eligible for constrained OpenPort auto-execution with active time-bounded authorization, justification, idempotency, and current permission. Configured allowlists and limits must pass, and a matching preflight is required when the current policy says so. Other actions are force-draft, require independent approval, or remain unsupported and manual. The action contract and domain policy decide.

Are reads safe enough to skip governance?

Reads avoid mutation risk, but they can still expose sensitive or excessive data. Use permission checks, tenant isolation, field minimization, purpose-appropriate access, and export controls. Do not use an approval prompt after retrieval to compensate for weak access control.

What if an action was approved but permissions changed?

The execution should reauthorize against current identity, scopes, tenant, target access, and policy. If the actor or integration no longer has authority, the action should stop even if the draft was approved earlier.

Can approval make an unsupported external action valid?

No. Approval expresses a decision inside a governed workflow; it does not create a provider capability, government connection, professional license, or legal authority. When execution is outside Figena’s supported boundary, the product should prepare the handoff and let an authorized person complete and record the external result.

Who should approve?

The approver should have current authority for the business effect and enough context to evaluate it. For actions subject to separation of duties, the requester may not be an eligible approver. The policy should identify the required role or capability rather than choosing whoever happens to be available.

How often should approval rules be reviewed?

Review them when an action’s effect changes, a new provider becomes executable, data sensitivity changes, a domain adds a hard boundary, roles or scopes are redesigned, or incidents reveal that the preview and actual consequence can diverge. Time-limited automation policies should expire by design rather than depend on someone remembering to disable them.

Put people at the point of judgment

Human approval is valuable when a person can resolve ambiguity, accept accountability, or stop a consequential effect—not when it merely repeats a permission check. Start with the effect, shape the control around risk, apply the real policy, and reauthorize at execution time. This keeps routine work fast while preserving review and manual boundaries where they matter.

Prepare for a lost device with approved backup authentication, a known recovery route, clear business coverage, and checks after access is restored. Use a practical recovery plan.