One employee.
A defined responsibility.
“Book a consultation next Tuesday.”
Customer instructions describe the task. They do not expand the employee’s authority.
GOVERNANCE & SECURITY
Give AI the authority to work.
And boundaries that hold.
Governance in UnleashX is the set of rules that decides what an AI employee may access, what it may change, and which decisions must go to a named person. Let routine work move without repeated approvals. Define what your AI employees can access and change, when people must decide, and how each outcome is reviewed.
Autonomous within scopePeople own exceptionsEvidence behind outcomes
AUTHORITY IN ACTION
One request. Three possible paths.
A permitted action proceeds. An exception asks the right person. A prohibited action stops. Explore how the same employee handles each case without losing the work’s context.
UnleashX at workIllustrative policy flow · not a live product interfaceOne employee.
Is this action permitted?
Calendar creation is allowed for an agreed slot. Pricing changes and bulk exports are not.
Example policy · version 1.0Execute autonomously
Allowed action. Verify the result.
SELECTED OUTCOMERequest a human decision
Exception. Preserve context and wait.
Block the action
Not permitted. Do not execute.
Appointment confirmed · event reference recorded
The appointment is within the employee’s configured calendar permissions.
Create the appointment, verify the event ID and send confirmation.
Next owner: AI employeeHuman involvement is conditional, not a checkpoint on every routine action.
A PRACTICAL CONTROL FRAMEWORK
Define the responsibility. Then the controls.
Use these six areas to scope your operating model. The exact enforcement, evidence and security configuration must be confirmed for your systems and deployment.
Role-level authority
Define the records an employee may read and the actions it may perform. Separate viewing a balance from changing a payment instruction.
Agree: system scopes, credential owner and revocation process.
Data boundaries
Choose the minimum fields and approved knowledge needed for the job. Map where data is processed, stored and retained before connecting a workflow.
Agree: data categories, destinations and retention requirements.
Action boundaries
Make permitted, approval-required and prohibited operations explicit. Customer messages and retrieved documents must not grant additional permissions.
Agree: enforcement points and negative test cases.
Human decision ownership
Give exceptions a named destination and a decision request. Preserve completed work while the affected action waits for a recorded response.
Agree: decision owner, response window and escalation path.
Operational evidence
Connect the requested action, applied rule and destination-system result. Keep sensitive content out of records that do not need it.
Agree: event fields, access to records and review responsibility.
Controlled change
Treat changes to instructions, tools and authority as changes to the operating model. Evaluate the affected workflows before expanding responsibility.
Agree: release owner, acceptance criteria and rollback procedure.
SHARED RESPONSIBILITY
A control needs an owner, not just a label.
Agree responsibilities before release. This is a starting point for implementation, not a substitute for the responsibilities in your service agreement.
| Area | Customer ownership | Implementation agreement |
|---|---|---|
| Business authority | Approve permitted decisions, exceptions and prohibited actions. | Translate the approved scope into workflow rules and test cases. |
| Connected systems | Authorize credentials and destination-system access. | Confirm supported operations, permission enforcement and failure handling. |
| Data handling | Identify sensitive fields and required data boundaries. | Document processing destinations, retention and access arrangements. |
| Human decisions | Name reviewers and escalation owners. | Define the handoff packet, response capture and resumption criteria. |
| Operational changes | Approve changes to scope and production responsibility. | Agree testing, release evidence, monitoring and recovery procedures. |
ENTERPRISE SECURITY REVIEW
Bring concrete questions. Review concrete evidence.
Security review should follow the proposed data flow and system access, not a generic badge wall. Confirm the following with your business, security and implementation teams.
Where does the data go?
Map input channels, model or service providers, connected tools, storage locations and outbound destinations. Identify any residency or processing restrictions before selecting the configuration.
Who can access or change it?
Review user and service identities, credential storage, permission scope and revocation. Confirm supported identity controls rather than assuming SSO or a particular access model.
What is retained, and why?
Agree what conversation, action and diagnostic data is retained, who can inspect it and how long it is needed. Review redaction, deletion and backup handling for the actual deployment.
How is an incident handled?
Define detection and notification responsibilities, how affected actions are paused, who investigates and what evidence is available. Review applicable assurance documents and their scope with the team.
BEFORE RESPONSIBILITY EXPANDS
Test the boundary, not only the happy path.
Use representative requests and inspect the final system state. A fluent answer does not prove that an action was authorized, completed or safely refused.
Define
Document the role, allowed tools, prohibited operations and exception owners.
Output: approved authority mapChallenge
Test routine requests, missing identity, conflicting instructions and out-of-scope actions.
Output: boundary test resultsVerify
Inspect writes, blocked actions, uncertain results and the information carried into handoffs.
Output: reviewed evidence setRelease & review
Agree acceptance criteria, review ownership and how to pause or revert affected work.
Output: scoped release decisionGOVERNANCE QUESTIONS
Clarity before you connect production systems.
What does governance mean for an AI workforce?
It defines what each employee may access, decide and change; which requests require another authority; and what evidence is needed to review the outcome. Begin with the business responsibility, then map its rules to system permissions, exception handling and evaluation.
Does every action need human approval?
No. Routine actions within configured authority should proceed autonomously. Human decisions are reserved for specified exceptions or higher-authority actions. Prohibited actions remain blocked rather than being treated as routine approval requests.
How is a human handoff different from a notification?
A handoff identifies the decision required, the owner, relevant records and what has already happened. Sending a message is not the same as receiving approval. Define how the decision is captured and what permits the affected action to resume.
Are prompts enough to enforce permissions?
A written instruction is not a substitute for access control. Review the permissions of connected credentials and enforcement at the tool or destination system. Test disallowed actions directly rather than relying only on whether an employee describes the rule correctly.
What security evidence should we request?
Request the documentation relevant to your deployment: data flows, system access, credential handling, retention, incident responsibilities and available independent assurance. Confirm the scope and currency of any evidence with the team; this page does not assert a certification or a specific hosting configuration.
What should happen when a system response is uncertain?
Do not report success or blindly repeat a potentially completed action. Preserve the request reference and reconcile the destination-system state. Route unresolved cases to the defined recovery owner, with enough context to avoid duplicating work.
How should policy changes be released?
Assign an owner, identify affected actions and retest normal, exception and prohibited paths. Review outcomes against acceptance criteria, retain the policy version associated with the release and agree a way to pause or revert the affected workflow.
How do we scope governance for our first workforce?
Bring one representative workflow, its system list and the decisions your team reserves for people. Together, map role permissions, evidence, exception owners and release criteria. Confirm which controls are supported in the proposed deployment before production.
START WITH ONE RESPONSIBILITY
What should your AI workforce own?
Bring the workflow, connected systems and decisions your people reserve. We’ll map the authority, exceptions and evidence needed to move forward.