メニュー
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.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/deanpeters/ai-product-operating-model-skills --skill aipom-autonomy-boundary-designerコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Diagnose missing, stale, conflicting, inaccessible, excessive, sensitive, or untrusted context and recommend the next source, package, data, or lifecycle intervention.
Assess whether data is fit for a specific AI product decision across provenance, quality, access, representativeness, consent, privacy, freshness, and operations.
Recommend the product, model, workflow, human, and production evaluations needed for an AI decision, based on behavior, consequences, evidence gaps, and lifecycle stage.
SOC 職業分類に基づく
SKILL.md を表示中
| 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"] |
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.
“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:
Completing the matrix does not prove the controls are used. Test the workflow and retain evidence of actual operation.
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.
The completed artifact contains:
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.
Bring whatever is available; missing evidence is a finding, not a reason to cancel the activity.
Useful evidence includes:
Label unsupported claims as assumptions. No evidence of reliable control operation means no maturity claim above 2 — Emerging.
Name the system, version, environment, users, affected people, jurisdiction or sector assumptions, and decision being made. Separate design-time, test, and production authority.
Write actions as verbs with objects: “draft a reply,” “send a reply,” “change an account limit,” or “delete a record.” Split bundled actions because different steps often require different authority.
For each action, discuss:
Do not collapse these dimensions into a decorative risk score. Use them to explain the boundary.
Choose one state for each action:
When evidence is weak or consequences are difficult to reverse, choose the more restrictive boundary.
For Human approval required, state who executes after approval: the AI system under a logged approval token, or the authorized human. Use Human execution only when the AI must not hold the execution permission at all.
For every non-prohibited action, name preventive controls, monitoring, logs, thresholds, reviewer competence, response time, fallback behavior, rollback, and the accountable owner.
Confirm the reviewer can understand the evidence, challenge the system, refuse the action, and stop operation. If not, the review is ceremonial.
Specify events that suspend independent action or the whole system, such as threshold breaches, missing logs, novel cases, control failure, material complaints, data drift, security events, or unavailable reviewers.
Name who receives the escalation, who decides whether to resume, and what evidence is required.
State the evidence required to increase autonomy and the signals that reduce it. Use shadow operation, bounded pilots, representative evaluation, monitored production sampling, and incident learning as appropriate.
Set acceptance thresholds before reviewing results. Define them in terms of the action's consequence, incorrect-action rate, severity, recovery, subgroup or edge-case behavior, control reliability, and operating load. Do not infer threshold sufficiency from aggregate agreement alone, and do not reuse evidence from one action—such as refunds—as a proxy for another—such as payout freezes.
Record disagreements, unresolved legal or policy questions, the final human decision owner, the accountable executive or operational owner, and the next test. Do not let the AI facilitator make the authority decision.
If those people are not named, identify the required roles and mark them unassigned. Do not silently appoint the Product Manager or another participant as the authority.
Technical ability does not grant organizational permission. Authority is delegated by accountable humans within constraints.
The scope of independent action should grow only when evidence demonstrates acceptable behavior and effective controls in representative conditions.
Oversight requires competence, information, time, authority, and a practical ability to intervene. A click-through approval does not satisfy those conditions.
Grant only the tools, data, permissions, duration, and action scope necessary for the intended outcome.
Prefer bounded, observable, and reversible actions while learning. Separate drafting from sending and recommendation from execution.
aipom-behavior-contract-builder to define acceptable and prohibited behavior before assigning authorityhuman-aipom-work-contract to integrate boundaries into the daily workflowaipom-accountability-charter to formalize decision rights and escalationaipom-risk-control-incident-playbook to operationalize detection, rollback, response, and learning