| name | aipom-autonomy-boundary-designer |
| description | Define evidence-based boundaries for what an AI system may do independently, with human approval, or never. Use before launch, scaling, or increasing AI authority. |
| type | component |
| category | governance-and-accountability |
| phase | 1 |
| status | active |
| operating_level | ["organization","product-team","initiative"] |
| audience | ["Product Manager","Product Operations","Team Lead","Engineering","Design","Legal","Privacy","Security","Risk","AI Governance"] |
| best_for | ["Preparing an AI or agentic product for launch","Increasing the authority of an existing AI system","Resolving disagreement about human approval","Reviewing a workflow with vague human-in-the-loop claims"] |
| evidence_required | ["Inventory of proposed AI actions","Consequences for users and the organization","Existing approval and escalation policies","Evaluation or production evidence where available","Relevant legal, privacy, security, safety, and contractual constraints"] |
| produces | ["Autonomy boundary matrix","Escalation and stop policy","Named decision and accountability owners","Evidence plan for safely changing autonomy"] |
| assessment_questions | ["GOV-01","GOV-02","GOV-03","WFL-03","EVAL-02"] |
| maturity_move | {"from":"emerging","to":"repeatable"} |
| estimated_time | 45-60 min |
| group_size | 3-8 |
| depends_on | ["aipom-behavior-contract-builder"] |
| combine_with | ["human-aipom-work-contract","aipom-accountability-charter","aipom-risk-control-incident-playbook"] |
| sources | ["https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10","https://oecd.ai/en/dashboards/ai-principles/P9","https://eur-lex.europa.eu/eli/reg/2024/1689/oj"] |
AIPOM Autonomy Boundary Designer
What Is It
Use this skill to decide, action by action, what an AI system may do independently, what requires human approval, and what it must never do. Base each boundary on consequences, reversibility, detectability, evidence, and applicable constraints—not on what the technology can technically perform.
The skill changes autonomy governance from undocumented individual judgment into a reviewable operating practice with named owners, escalation triggers, and a path for changing authority when evidence improves or deteriorates.
Why Use It
“Human in the loop” is not a control unless the loop identifies the action being reviewed, the reviewer, the evidence available, the time allowed, the authority to intervene, and what happens when review fails.
Explicit boundaries help a product team:
- Prevent capability from silently becoming authority
- Match human review to consequence and uncertainty
- Avoid ceremonial approvals that add delay without reducing risk
- Design monitoring, rollback, and escalation around real actions
- Explain authority to users, operators, governance partners, and auditors
- Increase or reduce autonomy through evidence rather than optimism
Completing the matrix does not prove the controls are used. Test the workflow and retain evidence of actual operation.
When to Use It
Use this skill when an AI system will recommend, communicate, transact, modify records, trigger tools, allocate resources, affect access, or otherwise act on behalf of a person or organization.
Use it before launch, after a consequential incident, when expanding the system’s tools or permissions, when moving from recommendation to execution, or when evaluation evidence changes.
Do not use it as a substitute for legal, privacy, security, safety, accessibility, labor, or sector-specific review.
What It Produces
The completed artifact contains:
- Scope and action inventory
- Action-level autonomy decisions
- Rationale and supporting evidence
- Required controls and human review
- Escalation and stop triggers
- Named decision, review, and accountability owners
- Exceptions and unresolved questions
- Evidence needed to increase, retain, or reduce autonomy
Who Should Participate
Include the Team Lead, Product Manager, Product Operations where present, technical owner, workflow operator, and the person accountable for the affected outcome. Add design, research, data, legal, privacy, security, safety, risk, compliance, or domain specialists in proportion to the consequences.
Someone who performs the proposed human review should participate. Do not design oversight solely from management assumptions about how operators work.
