An AI proposal is not permission: designing reviewable HR actions

Hamza Awan — Wed, 04 Nov 2026 22:43:58 +0000

A conversational interface can make a workflow easier to start. It should not make a consequential change easier to apply accidentally.

Consider this request: "What is left for Maya's onboarding?" A helpful answer might identify an incomplete task. That is different from permission to change Maya's access, assign work, or mark onboarding complete. Maya is a fictional example here.

Here is a practical design pattern for keeping those boundaries clear. These are implementation recommendations, not a claim that a particular product implements every control below.

Separate explanation, proposal and execution

Treat these as three different operations:

Explain: retrieve authorized context and answer the question.
Propose: describe a specific possible change without applying it.
Execute: validate an explicitly confirmed proposal and run the permitted action.

Do not turn an ambiguous question into an execution request because the model inferred a likely next step. "What is missing?" and "Apply this change" are different user intentions.

Make the review screen concrete

A useful proposal should tell the reviewer who will be affected, what will change, and what will remain unresolved. Show the relevant before-and-after values and the source of the context when available.

For example: "Assign the security orientation task to Maya, due Friday" is reviewable. "Optimize onboarding" is not. If the person, task or date is ambiguous, ask a focused follow-up instead of presenting a confident guess.

Keep the confirmation attached to that exact proposal. An approval for one employee must not authorize a later change for another employee. Editing the target or payload should require another review.

Keep authorization outside the model

The server should derive workspace and actor identity from the authenticated session. It should independently check whether that actor can read the requested records and perform the proposed action. A model-supplied workspace identifier or employee identifier is an input to validate, not proof of access.

Use the same validation and business rules as the ordinary application workflow. The conversational interface should not become a second route around required fields, role checks or tenant boundaries.

Recheck at execution time

A proposal can become stale while someone reviews it. The employee may have moved teams, the task may already be complete, or the reviewer's permissions may have changed.

Before applying a confirmed proposal, re-read the relevant state and validate it again. If the underlying facts have changed materially, explain the difference and ask for a fresh review. Use an idempotency strategy so a retry cannot apply the same operation twice.

Report the result, not the intention

After execution, distinguish success, failure and partial completion. "I prepared the update" should not look like "The update was applied." Keep a minimal audit record of the actor, approved action and outcome, without copying sensitive employee conversations into general-purpose logs.

A useful review checklist is: correct person, correct workspace, explicit change, current authority, current data, safe retry, verified outcome.

Why this matters for HR tools

People operations involve records and access that deserve a clear decision boundary. A friendly chat interface does not remove that responsibility. The better experience is a shorter path to an informed decision, with the person still able to inspect and approve what happens next.

Disclosure: I’m Hamza, founder of Hively HR. Hively's product approach is to ask Buzz for HR context and review proposed changes before approving them. Hively is free for up to 5 employees; paid plans start at $9 per company per month for 6–9 employees. This article describes a general engineering pattern, rather than a complete security audit of Hively.