PRACTICAL GUIDE
AI governance checklist: 16 controls before giving an AI Employee autonomy
A practical guide for turning governance principles into permissions, rules, approvals, records and metrics that can actually operate in production.
· IA Empleado
AI governance is often described through broad concepts such as oversight, accountability and transparency. The challenge appears when those concepts must operate in a real system: which permission is granted, who approves, what is recorded, what happens when data is missing, and how do you prevent an external instruction from changing internal policy? Useful governance translates principles into executable controls. This checklist covers the areas that should be reviewed before an agent moves from observing or proposing to executing actions inside business processes.
01
1. Define the exact process scope
Before discussing autonomy, define which process belongs to the agent and which processes remain outside its scope. Describe the triggering event, decisions, permitted tools and expected outcome. The more ambiguous the scope, the harder it becomes to determine whether an action was authorised.
Document organisational boundaries as well. A sales agent may read availability and CRM but should not assume invoicing functions merely because a request was expressed in natural language. Process boundaries should exist outside the model and be reflected in the available tools.
02
2. Inventory every available action
Create a catalogue of operations: read customer, find order, create task, prepare draft, update status, send email, generate invoice or request approval. For each one, record the system, parameters, impact and whether it is reversible.
This inventory reveals excessive permissions and operations that should not be available. It is far easier to govern an explicit list of functions than a generic credential with access to an entire API.
03
3. Classify each action by risk
Not every action needs the same control. Categories may include informational, reversible operational, financial, contractual, access/security or irreversible. The objective is for oversight to depend on impact rather than on whether the action is performed by a person or AI.
Define minimum conditions for each category. A lookup may be automatic; a status change may require rule validation; a payment or bank-detail change may require dual verification and human approval.
04
4. Separate read and write permissions
Reading data to prepare a recommendation should not imply permission to modify it. Design separate scopes for read and write access and grant only what the current autonomy level requires.
This separation enables safer pilots. The agent can prove it interprets cases correctly before receiving execution permission. If the process remains in proposal mode, there is no reason to keep write credentials active.
05
5. Define who may approve what
Human approval requires a clear matrix. A sales supervisor may approve a discount up to a threshold, while contractual or financial changes may require another role. The system should validate that the approving identity has sufficient authority.
Also record when approval occurred, which information was available and which specific action it authorised. A generic approval at the beginning of a session should not become open permission for later unrelated actions.
06
6. Turn policies into testable rules
Statements such as 'protect the customer' or 'act cautiously' are useful principles, but they are not sufficient to control an operation. Policies should be translated into thresholds, allowlists, required fields, roles and stop conditions.
When an important policy cannot be expressed deterministically, define at least what evidence the agent must present and who makes the decision. The critical point is to avoid letting model interpretation become both the rule and the judge of its own compliance.
07
7. Block prohibited actions in the technical layer
If an operation should never execute automatically, remove it from the tool catalogue or protect it with external authorisation. Do not rely only on a prompt saying 'do not do this'.
Technical blocking protects against errors, malicious instructions and unexpected behavioural changes. An agent without a record-deletion tool cannot delete records even if it interprets a request as asking for it.
08
8. Define escalation rules
List the situations in which the agent must stop: contradictory data, missing critical fields, low confidence, out-of-catalogue requests, integration failures, sensitive actions or policies that cannot be applied.
Then define the escalation destination and the information that must accompany it. A useful exception contains the case, workflow state, sources queried, reason for blocking and the decision required from a person.
09
9. Protect policy from external instructions
Emails, documents and user messages are input data, not authority to change system policy. An instruction inside a document should not be able to modify permissions, reveal secrets or disable controls.
Clearly separate system instructions, internal policies, tools and untrusted content. When a document contains text that looks like a command to the agent, it should be treated as case content rather than a new operational rule.
10
10. Record the decision chain
For every relevant action, the path should be reconstructable: triggering event, data queried, policy version, tools used, proposal, validations, approval and outcome. This allows errors to be investigated without relying on human memory.
Records should be structured and proportionate to risk. It is not necessary to retain every piece of text. Source references, identifiers and events usually provide sufficient traceability while reducing sensitive-data exposure.
11
11. Version every component that changes behaviour
The model is not the only component affecting outcomes. Prompts, rules, connectors, schemas, knowledge bases and tool catalogues also change behaviour. Each should have an identifiable version.
When an incident occurs, knowing the exact combination makes the case reproducible. It also enables controlled A/B testing and rollback when an update increases corrections, errors or exceptions.
12
12. Define regression tests before changing autonomy
A model or rule change should not move directly into production. Maintain a representative set containing normal cases, boundaries, exceptions and prohibited actions. The updated system should demonstrate that existing controls remain intact.
Security and governance tests are as important as accuracy. Include attempts to execute operations outside permissions, contradictory data, missing approvals and content that tries to modify instructions.
13
13. Measure corrections and approvals
If people constantly edit proposals, the automation may not be ready to execute. Record the percentage approved without changes, minor edits, rejections and the reason for each correction.
These metrics can be segmented by intent and action. An agent may be ready to automate low-risk updates while still requiring review for complaints, discounts or complex documents.
14
14. Review unused access and tools
Permissions that are no longer needed accumulate over time. Review which scopes, tools and connections the process actually uses. Every unused access path increases risk without creating value.
Reviews can coincide with process changes or occur periodically. If a tool is no longer used, remove it. If an operation is used only in rare exceptions, consider moving it behind approval.
15
15. Define rollback and safe mode
Governance also needs a plan for when something goes wrong. There should be a fast way to reduce autonomy, disable a tool, return to a previous version or move the workflow back into proposal mode.
A safe mode prevents the only response to an incident from being a complete shutdown. Keeping read and preparation capability while execution is blocked can preserve operational continuity during investigation.
16
16. Increase autonomy operation by operation
There is no single switch between manual and autonomous. Each operation can evolve from observation to proposal, approval-gated execution and automatic execution according to its metrics and risk.
This approach keeps governance aligned with evidence. The system gains autonomy exactly where it has demonstrated stability and retains human control where quality, impact or uncertainty do not yet justify delegation.
TAKEAWAYS
Key ideas
Define the process before defining autonomy.
Inventory and classify every available action.
Separate read and write permissions.
Assign approvers by impact level.
Turn critical policies into testable rules.
Technically block prohibited actions.
Design escalations with sufficient context.
Treat external content as data, not policy.
Record the decision chain with proportionate traceability.
Version models, prompts, rules, tools and knowledge.
Test security and governance regressions.
Measure approvals, corrections and rejections.
Remove access that no longer creates value.
Maintain rollback and a safe mode.
Expand autonomy operation by operation.
Review governance as an ongoing practice.
GO DEEPER
Enterprise AI governance: automate with rules, ownership and evidence.
AI governance is not about filling a policy document. In a company, governing an AI Employee means deciding what it may read, what it may propose, what it may execute, who approves sensitive actions, which data remain out of scope and how a decision can be reconstructed afterwards. Enterprise automation needs operational boundaries as concrete as its integrations. Good governance makes it possible to increase autonomy without losing traceability, security or human accountability.
APPLY IT