AI Accountability

What this skill is for

AI assistance can speed up analysis, but it also creates a responsibility gap: when the AI is wrong, who is accountable? This skill provides a governance framework for AI-assisted professional work. It defines ownership of AI-generated artifacts, review and sign-off requirements, audit trails for AI contributions, and error handling protocols. The goal is to make AI assistance transparent, reviewable, and accountable — not to replace human judgment with plausible-sounding output.

When to use this skill

• When a team or project starts using AI tools for requirements, design, or analysis.
• After an AI-generated error reaches a client, stakeholder, or production system.
• When drafting a team policy or engagement terms for AI-assisted delivery.
• When a manager asks "how do we know the AI output is correct?"
• When a consultant wants to disclose AI use to a client but is unsure how to frame it.

Real work situations

AI-generated requirement contained a fake transaction code

A consultant used AI to draft requirements for a custom SAP SD report. The AI included a requirement to "use transaction ZSD_CUST_REPORT to extract data." The transaction does not exist. The consultant copied the requirement into a client document without review. The client discovered the error during a steering committee meeting and questioned the consultant's credibility. There was no process for who should have reviewed the AI output or what to do when the AI was wrong.

AI-drafted architecture decision was not disclosed

A solution architect used AI to draft an architecture decision record (ADR) for a middleware change. The ADR contained a plausible but incorrect assumption about event ordering. The architect presented the ADR as their own work without disclosing the AI contribution. When the assumption was challenged during a technical review, the architect could not defend it because they had not done the underlying analysis. The team lost trust in the ADR and had to redo the decision.

Team uses AI for incident analysis with no review process

An SAP AMS team uses AI to analyze recurring incident tickets and suggest root causes. The AI correctly identifies a pattern 80% of the time but blames the wrong component in 20% of cases. Because there is no review gate, the incorrect diagnoses are passed to the client as findings. The client acts on one incorrect diagnosis and changes a configuration that was not broken, causing a new incident. The team has no protocol for reviewing AI output, no ownership of the error, and no way to prevent recurrence.

Inputs required

• Team structure — who does analysis, who reviews, who signs off, who owns the client relationship.
• AI tools in use — which tools, for what purposes, with what data access.
• Review processes — existing quality gates, approval workflows, sign-off requirements.
• Risk appetite — what level of error is acceptable for internal work versus client-facing work.
• Compliance requirements — any contractual, regulatory, or organizational rules about AI use or disclosure.

Questions to ask

• Who is accountable for the final output — the AI, the operator, or the reviewer?
• What is the review process for AI-generated artifacts before they leave the team?
• How is AI contribution disclosed to clients, stakeholders, or audit?
• What happens when AI output is wrong — who corrects it, who communicates the correction, and who prevents recurrence?
• Which decisions can the AI assist with, and which decisions must be made by humans alone?
• How is the AI's role documented in project records, contracts, or change logs?

Working method

1. Inventory AI tools and use cases. List every AI tool the team uses, what it is used for, and what data it accesses. Classify each use case by risk: internal research, draft generation, client-facing output, or production decision support.
2. Define the ownership matrix. For each use case, assign three roles: Operator (runs the AI), Reviewer (checks the output), Accountable (signs off and owns the consequences). These roles can be the same person for low-risk cases but must be separate for high-risk cases.
3. Set review gates. Define what must be reviewed before AI output is used: factual claims, system references, stakeholder attribution, assumptions, and conclusions. Define who performs the review and how it is recorded.
4. Define disclosure rules. Decide when and how to disclose AI use. At minimum, disclose AI use for client-facing deliverables. For internal work, document AI use in the artifact metadata.
5. Create an error handling protocol. Define: how an AI error is detected, who is responsible for correcting it, how the correction is communicated, and what is learned to prevent recurrence.
6. Distinguish assistance from delegation. Assistance means the AI drafts, the human decides. Delegation means the human accepts the AI output without review. Draw a clear line: which tasks are assist-only and which can be delegated with defined review.
7. Draft the AI usage policy. Write a one-page policy covering: tool inventory, ownership matrix, review gates, disclosure rules, error protocol, and assistance boundaries.
8. Review and ratify. Present the policy to the team and to stakeholders. Get explicit agreement on ownership and review gates. Update the policy when tools or use cases change.

Decision rules

• If AI generates a recommendation, a human must review it before it is acted upon.
• If AI output is sent to a client or external stakeholder, disclosure is mandatory; the exact wording depends on the engagement terms.
• If AI output is wrong, the human operator is accountable, not the tool vendor.
• If the AI is used for a decision that affects safety, compliance, or contractual obligations, the accountable role must be a human with authority to make that decision.
• If a task requires original analysis or judgment, it is assistance-only; the AI can draft, but the human must decide.
• If the same AI error recurs, the review process is broken, not the AI.
• If there is no time to review, do not use AI for the task.

Deliverables

• AI Accountability Framework — ownership matrix, review gates, and error protocol.
• Ownership Matrix — table of use cases with operator, reviewer, and accountable roles.
• AI Usage Policy — one-page team policy for AI-assisted work.
• Disclosure Template — standard wording for client communications about AI use.

Templates

AI Accountability Framework

---
title: AI Accountability Framework
team: [team name]
date: [YYYY-MM-DD]
review_cycle: [quarterly / on tool change]
---

## AI Tool Inventory
| Tool | Use Case | Data Access | Risk Level |
|------|----------|-------------|------------|
| [tool] | [drafting requirements] | [client data / public data] | [Low / Medium / High] |

## Ownership Matrix
| Use Case | Operator | Reviewer | Accountable | Review Gate | Disclosure |
|----------|----------|----------|-------------|-------------|------------|
| [use case] | [role] | [role] | [role] | [factual / full / none] | [client / internal / none] |

## Error Handling Protocol
1. **Detection**: [how errors are caught — review, client feedback, audit]
2. **Correction**: [who fixes the error and by when]
3. **Communication**: [who tells the client and in what format]
4. **Prevention**: [what changes to prevent recurrence — prompt, process, or tool]

## Assistance vs Delegation Boundaries
| Task Type | AI Role | Human Role |
|-----------|---------|------------|
| [requirements drafting] | [draft] | [review, verify, decide] |
| [incident analysis] | [pattern suggest] | [validate, diagnose, decide] |
| [client communication] | [outline] | [write, review, send] |

Quality checklist

• [ ] Every AI use case has an assigned operator, reviewer, and accountable role.
• [ ] Every high-risk use case has a separate reviewer who is not the operator.
• [ ] Review gates are defined with specific criteria, not just "check it."
• [ ] Disclosure rules are documented and cover client-facing work.
• [ ] The error handling protocol names who is responsible for correction, communication, and prevention.
• [ ] Assistance and delegation are distinguished for each task type.
• [ ] The policy has been ratified by the team and relevant stakeholders.
• [ ] The framework is reviewed when tools or use cases change.

Common mistakes

• Mistake: Treating AI as a black box that absolves the operator of responsibility. Consequence: When the AI is wrong, the operator blames the tool, the client loses trust, and the error is not corrected because no one owns it.
• Mistake: Skipping disclosure because "everyone uses AI now." Consequence: A client discovers undisclosed AI use during an audit or a challenge, and the engagement is damaged.
• Mistake: Not documenting error handling. Consequence: The same AI error recurs across multiple projects because the team has no process for learning from mistakes.
• Mistake: Blurring assistance and delegation. Consequence: A human accepts an AI-generated recommendation without review, acts on it, and causes a configuration error that requires emergency remediation.

Weak output vs Strong output

Weak output — bad AI usage

A team leader asks AI to "write an AI usage policy for our team." The AI produces a generic document that says "team members should use AI responsibly and verify output before sharing it." There is no ownership matrix, no review criteria, no disclosure rules, and no error protocol. The policy is signed and filed. Six months later, a consultant sends an AI-generated requirements document to a client. The document contains a hallucinated SAP transaction code. The client discovers the error in a steering committee. The team has no documented process for who should have reviewed the output, how to disclose the mistake, or how to prevent it from happening again. The policy is useless because it contains no operational specifics.

Strong output — good AI usage

The team leader uses AI to draft the framework, then applies the accountability skill. The ownership matrix assigns the operator role to the consultant, the reviewer role to the senior analyst, and the accountable role to the engagement manager. The review gate for client-facing requirements requires cross-checking every SAP transaction code in a sandbox and verifying every business rule with a stakeholder. The disclosure rule says: "AI-assisted deliverables contain a footer note: 'This document was drafted with AI assistance and reviewed by [name].'" The error protocol says: if a client finds an AI error, the accountable role must correct it within 24 hours, log it in the error register, and update the review checklist. The policy is ratified, and the first AI-assisted deliverable passes review because the reviewer knows exactly what to check.

Agent instructions

AI Prompt Pattern

Role: You are an AI governance assistant.
Context: I need to create an AI accountability framework for a team of [consultants / analysts / architects] working on [SAP / enterprise / data] projects.
Tasks:
1. Draft an AI tool inventory based on the tools and use cases I provide.
2. Propose an ownership matrix with operator, reviewer, and accountable roles for each use case.
3. Define review gates with specific criteria for each risk level.
4. Draft disclosure rules for internal and client-facing work.
5. Create an error handling protocol with detection, correction, communication, and prevention steps.
6. Distinguish assistance from delegation for each task type.
7. Output the framework in the provided template format.
Constraints: Do not write generic advice like "use AI responsibly." Every rule must name a role, a criteria, or a step. Do not omit error handling. Do not omit disclosure.

Agent dos

• Ask for the team structure, tools, and risk appetite before drafting the framework.
• Produce the ownership matrix as a concrete table, not a prose description.
• Define review gates with specific criteria: what must be checked, by whom, and how it is recorded.
• Include error handling as a full protocol, not a single sentence.

Agent don'ts

• Do not write generic policy language that contains no operational specifics.
• Do not omit disclosure rules.
• Do not omit the error handling protocol.
• Do not allow the same person to be operator, reviewer, and accountable for high-risk use cases.

Related skills

• Agent Usage Guide — general rules for how agents use Skill Hub.
• Requirements Elicitation — capturing needs before AI generates requirements.
• Validate AI-Generated Requirements — checking AI output before it enters a document.
• Quality Rules — criteria for what makes a Skill Hub page good or bad.

Related Atlas pages

• SAP Process Audit — example of a governance framework applied to SAP operations.

Verification status and limitations

This skill is a public working interpretation of AI governance for professional services. It is not an official legal, compliance, or SAP guideline. The framework must be adapted to local laws, contractual terms, and organizational policies. AI tools and regulations change rapidly; the ownership matrix and disclosure rules should be reviewed at least quarterly. Use this skill as a structured starting point for accountability design, not as a substitute for legal or compliance review.