The accountable party for an AI agent is the person who has authority to approve its business purpose, set its operating limits, accept its outcomes, and stop its use. In most enterprises, that is the accountable business Process owner. Technical, model, data, security, tool, policy, approval, operations, compliance, audit, and vendor roles hold defined responsibilities around that owner. Responsibility follows the authority and control boundary through every action, Release, incident, change, and external dependency.
Who is responsible for an AI agent in production
Assign one accountable business Process owner for the production use and its outcomes. The executive sponsor owns enterprise risk appetite, funding, and escalation authority. The agent product or technical owner owns technical integrity and controlled Releases. Every other role owns a specific decision, control, artifact, or independent conclusion. A vendor contract changes the distribution of work while the enterprise owner retains accountability for the Process operated under enterprise authority.
Trace accountability through four boundaries: who authorizes the purpose, who can change the system, who can permit or stop an action, and who accepts the resulting business impact. Record each boundary with a named person, delegated authority, decision criteria, evidence source, escalation path, and effective dates. Shared committees can advise and approve within a charter; each decision still needs one named accountable role.
Use the enterprise AI agent audit framework to test this matrix as part of the wider production system. The Agent Audit Readiness Assessment checks whether the ownership, authority, controls, and evidence are ready for independent review.
- Purpose and outcomes: the business Process owner approves intended use, affected people, outcome measures, risk acceptance, and retirement.
- Build and change: technical, model, data, identity, tool, and policy owners approve the components and boundaries within their mandates.
- Action authority: policy owners define routing rules, named human approvers decide consequential cases, and operations can contain execution.
- Assurance: second-line functions challenge within their mandates, while internal audit chooses its scope and provides an independent conclusion.
Default AI agent responsibility matrix across the lifecycle
Use this default matrix when an enterprise operates an agent inside a business Process. Accountable means final decision authority for the listed activity. Responsible means control operation and delivery. Consulted roles provide expertise or formal challenge. Informed roles receive the decision and its conditions. Each row has one accountable role for its defined decision scope.
The matrix is a starting control. The operating-model variations below replace specific assignments where architecture, sourcing, tool ownership, or mandatory human approval changes the authority boundary.
| Lifecycle stage | Accountable | Responsible | Consulted / challenged by | Informed | Evidence of responsibility |
|---|---|---|---|---|---|
| Design | Accountable business Process owner | Agent product/technical owner; model or AI assurance owner; data, IAM/security, Tool Catalog, and policy/control owners | Compliance/legal/privacy; third-party/vendor owner; operations | Executive sponsor; internal audit through the audit universe | Purpose and boundary approval, architecture, impact and risk assessments, role charter, control specification |
| Approval | Accountable business Process owner | Agent product/technical owner and policy/control owner assemble the decision package | Model or AI assurance; data; IAM/security; compliance/legal/privacy; operations | Executive sponsor; affected control owners; internal audit through risk reporting | Production-use decision, accepted conditions, exceptions, approver identity, dated rationale |
| Release | Agent product/technical owner | Engineering, model, data, IAM/security, tool, and policy/control owners | Business Process owner; model or AI assurance; operations; compliance/legal/privacy | Executive sponsor; named human approvers; third-party/vendor owner | Release manifest, test results, policy Simulation, permission review, Rollback result, approval |
| Runtime | Accountable business Process owner | Operations; policy/control owner; named human approver; technical, data, identity, and tool owners | Model or AI assurance; compliance/legal/privacy; third-party/vendor owner | Executive sponsor; internal audit through agreed reporting | Decision Requests, policy verdicts, tool receipts, Lineage Records, outcome reconciliations, control reviews |
| Incident | Operations and incident commander | Technical, IAM/security, data, tool, policy/control, vendor, and communications responders | Business Process owner; compliance/legal/privacy; model or AI assurance | Executive sponsor; named human approvers; internal audit according to protocol | Incident command record, affected-case population, containment, notifications, recovery, root cause, retest |
| Change | Accountable business Process owner | Agent product/technical owner and every owner whose boundary changes | Model or AI assurance; operations; compliance/legal/privacy; third-party/vendor owner | Executive sponsor; named human approvers; internal audit through risk reporting | Change classification, dependency diff, reassessment, regression results, conditions, Release approval |
| Retirement | Accountable business Process owner | Agent product/technical owner; operations; data, identity, tool, policy, and vendor owners | Compliance/legal/privacy; records owner; model or AI assurance | Executive sponsor; users; internal audit through the audit universe | Retirement decision, access revocation, dependency closure, data disposition, retained evidence, outcome reconciliation |
Role charters for all 13 AI agent governance roles
A role name becomes useful when it carries five complete duties: decisions owned, controls operated, evidence produced, escalation events, and a boundary the role retains. Put a named person, delegate, effective date, and backup against every row. Vacancies and overlapping assignments are control exceptions until the accountable business Process owner resolves them.
A person may hold several roles in a smaller organization. The evidence must still show which role the person exercised for each decision and where independence safeguards apply.
| Role | Decisions they own | Controls they operate | Evidence they must produce | Events requiring escalation | Boundary they cannot delegate away |
|---|---|---|---|---|---|
| Executive sponsor | Enterprise risk appetite, funding, strategic priority, executive exception ceiling, and program stop | Executive governance forum, risk acceptance limits, resource allocation, and board reporting | Approved mandate, risk appetite, funding decisions, exception decisions, and governing-body updates | Risk-appetite breach, material harm, systemic control failure, unresolved ownership, or inadequate resources | Executive accountability for mandate, resources, and escalation within the sponsor charter |
| Accountable business Process owner | Intended use, production approval, outcome criteria, operating conditions, risk acceptance, remediation priority, and retirement | Process controls, outcome review, use restrictions, exception governance, and owner recertification | Purpose statement, Process map, approval, responsibility matrix, outcome review, risk acceptance, and closure evidence | Unexpected affected-person impact, threshold breach, control bypass, purpose drift, incident, or owner vacancy | Accountability for the Process, its decisions, customer or employee impact, and use of suppliers |
| Agent product/technical owner | Architecture, approved components, technical acceptance, Release content, Rollout conditions, Rollback recommendation, and technical remediation | Versioning, build and release gates, integration controls, configuration management, observability, and technical containment | Architecture and data flows, Release manifest, test results, dependency inventory, runbook, and Rollback record | Unapproved component, failed threshold, unstable behavior, hidden dependency, evidence gap, or unsafe Rollout | Technical integrity, inventory accuracy, reproducibility, and truthful disclosure of limitations |
| Model or AI assurance owner | Evaluation method, datasets, thresholds, validation conclusion, limitations, retest scope, and assurance exception | Independent evaluation, red teaming, subgroup and regression testing, drift review, and finding follow-up | Evaluation plan, dataset and version record, results, limitations, validation conclusion, and retest evidence | Threshold failure, material drift, invalid test design, new failure mode, weak coverage, or unresolved limitation | Integrity, scope, methods, limitations, and independence of the assurance conclusion |
| Data owner | Approved sources, permitted purpose, quality thresholds, field access, lineage, retention, correction, and disposition | Data quality, provenance, Data Boundaries, minimization, retention, correction, and source reconciliation | Source inventory, data approval, quality results, lineage, access record, retention schedule, and correction history | Unauthorized source, quality breach, provenance gap, sensitive-data exposure, stale data, or deletion conflict | Fitness, permitted use, provenance, and lifecycle of data within the owner domain |
| IAM/security owner | Identity design, delegation pattern, effective access, security exceptions, credential lifecycle, revocation, and emergency access | Unique identities, least privilege, authentication, authorization, session limits, secret handling, detection, and revocation | Identity records, authority snapshots, access reviews, threat model, security tests, exceptions, and revocation events | Shared or orphan identity, privilege escalation, compromised credential, toxic grant, bypass, or active exploit | Integrity of identity, delegated authority, security posture, and timely revocation |
| Tool Catalog owner | Tool admission, owner assignment, approved actions, interface and version status, evidence contract, suspension, and removal | Catalog completeness, tool attestation, action schemas, permission mapping, version review, health status, and disablement | Tool Catalog entry, owner approval, action and scope definition, version history, test result, receipts, and suspension record | Unregistered tool, owner vacancy, schema drift, unsupported version, receipt gap, excess action, or unsafe dependency | Completeness and current status of the governed tool inventory and its evidence contract |
| Policy/control owner | Control objective, policy rules, thresholds, Decision Routing, exception criteria, control test, and remediation acceptance | Policy authoring, Simulation, approval workflow, runtime evaluation, exception expiry, control monitoring, and recertification | Control specification, policy version, Simulation results, verdicts, exceptions, reviews, and remediation tests | Policy bypass, stale rule, conflicting rule, unexplained verdict, exception expiry, or control failure | Control intent, rule accuracy, decision criteria, and complete accounting for exceptions |
| Named human approver | Approve, deny, return, or escalate each assigned consequential decision within documented authority | Evidence review, conflict check, authority check, rationale capture, deadline handling, and escalation | Decision Request, evidence presented, authority snapshot, decision, rationale, timestamp, and escalation record | Insufficient evidence, authority conflict, suspected manipulation, policy conflict, deadline risk, or impact beyond mandate | Personal exercise of judgment and the contemporaneous rationale for the assigned decision |
| Operations and incident commander | Runtime intervention, incident classification, containment sequence, service restriction, recovery, and return to operation | Monitoring, alert triage, on-call response, kill and revoke procedures, affected-case reconciliation, recovery, and exercises | Operating review, alert history, incident timeline, command decisions, affected population, recovery proof, and lessons learned | Uncontained execution, material service or outcome impact, repeated alert, evidence loss, failed recovery, or notification trigger | Incident command, containment accounting, recovery criteria, and accurate status communication |
| Compliance/legal/privacy | Applicable criteria, legal and privacy position, assessment need, contractual safeguards, notice obligations, and formal filing advice | Regulatory inventory, control mapping, privacy and impact review, legal-change monitoring, notice workflow, and issue challenge | Criteria memo, assessments, control mapping, contract terms, advice, notifications, filings, and legal-change record | Law or guidance change, new jurisdiction or purpose, rights impact, privacy incident, regulator contact, or disputed interpretation | Professional advice, formal notices, privilege decisions, and escalation within the assigned mandate |
| Internal audit | Audit universe, engagement scope, criteria, sampling, reliance, finding rating, conclusion, reporting, and follow-up verification | Independent planning, evidence requests, population testing, sampling, reperformance, workpaper review, reporting, and follow-up | Risk assessment, audit plan, population and sample record, workpapers, exceptions, report, and verified closure | Scope limitation, management override, evidence integrity failure, material finding, independence threat, or overdue remediation | Independent and objective audit scope, procedures, conclusion, and direct reporting route |
| Third-party/vendor owner | Supplier selection, due diligence, contractual controls, service acceptance, performance response, evidence access, exit, and replacement | Supplier inventory, due diligence, contract and SLA review, service review, issue tracking, evidence collection, and exit testing | Due diligence, contract and responsibility schedule, service reports, incidents, control evidence, change notices, and exit record | Supplier control failure, opaque subprocessor, service change, evidence refusal, incident, SLA breach, concentration risk, or termination | Commercial relationship, contract enforcement, supplier accountability, and an executable exit path |
Vary the matrix for four AI agent operating models
A universal RACI masks material differences in control and authority. Record a scenario-specific override beside the default matrix, identify every changed cell, and approve the variation before production use. The accountable business Process owner signs the complete version.
The four patterns below cover common production boundaries. Each pattern preserves named accountability while moving technical, tool, supplier, or case-decision responsibility to the role with actual control.
| Operating model | Accountability pattern | Responsibility changes | Required evidence | Boundary to preserve |
|---|---|---|---|---|
| Internally built agent | The business Process owner owns purpose and outcomes; the agent product/technical owner owns architecture and Releases | Internal model, data, IAM/security, tool, policy, and operations owners operate the full control stack; the vendor owner covers external models or services only | Source and build provenance, architecture, component inventory, tests, Release approval, authority model, runtime records, and Rollback proof | The enterprise retains direct control of design, access, release, operation, evidence, and retirement |
| Vendor agent embedded in a business Process | The enterprise business Process owner owns use and outcomes; the third-party/vendor owner owns the supplier relationship; the vendor owns its contracted system scope | The enterprise configures purpose, data, access, tools, policy, human review, monitoring, incidents, and exit; the vendor supplies contracted technical controls, change notices, and evidence | Fact-specific role assessment, responsibility schedule, system and subprocessor inventory, configuration record, service evidence, incidents, change notices, and exit test | The enterprise retains authority over deployment, affected-person decisions, operating conditions, containment, and supplier acceptance |
| Multi-agent Process with several tool owners | One business Process owner owns the final outcome; one agent product/technical owner owns orchestration; each tool owner owns its action boundary | Sending and receiving agent owners secure every handoff; Tool Catalog and IAM/security owners reconcile identities, permissions, versions, receipts, and delegated limits across the graph | Dependency graph, agent and tool owners, authenticated handoffs, purpose propagation, authority snapshots, tool receipts, failure containment, and end-to-end Journey | Sub-agents and tools receive bounded authority; the final outcome reconciles to every contributing action and owner |
| Consequential decision with mandatory human approval | The business Process owner owns the Process and outcome framework; the named human approver owns the individual approve, deny, return, or escalate decision | The policy/control owner routes every in-scope case; the technical owner prevents execution before a valid decision; operations monitors queues, authority, expiry, and bypass attempts | Decision Request, evidence presented, policy and authority versions, reviewer identity, rationale, timestamp, final action receipt, and override history | The named approver retains case judgment; the business Process owner retains policy, staffing, outcome quality, and remediation accountability |
Worked example: responsibility for one regulated loan-decision Journey
Assume an EU retail bank uses an agent to assemble application data, call a credit-risk model, apply lending policy, route every recommendation to an underwriter for mandatory approval, and write the final outcome. An AI system intended to evaluate a natural person's creditworthiness or establish a credit score is listed in Annex III point 5(b) of the EU AI Act and is presumed high-risk under Article 6(2), subject to the Article 6(3) rules; profiling in an Annex III use remains high-risk.
This example treats the model-and-agent vendor as provider and the bank as deployer based on the stated facts. The table follows the same Journey used in the enterprise audit framework and changes the lens from audit procedure to named responsibility. Every step ends in an artifact and an escalation condition.
| Journey step | Accountable decision | Responsible execution | Consulted / challenged by | Evidence | Escalation condition |
|---|---|---|---|---|---|
| 1. Approve purpose and boundary | Business Process owner approves credit use, customers, outcomes, limits, and mandatory approval | Agent product/technical owner documents the system and Process boundary | Executive sponsor; model assurance; compliance/legal/privacy; data; IAM/security | Purpose approval, classification basis, Process map, responsibility matrix, and conditions | Unclear purpose, unsupported classification, rights impact, missing owner, or unacceptable residual risk |
| 2. Accept the vendor system | Third-party/vendor owner accepts the supplier within approved commercial authority | Vendor owner coordinates due diligence; technical and assurance owners test the service | Business Process owner; compliance/legal/privacy; IAM/security; data; model assurance | Role assessment, due diligence, contract schedule, provider evidence, subprocessor list, and exit plan | Evidence refusal, unresolved control gap, opaque dependency, material contract gap, or failed exit test |
| 3. Bind identity, data, and tools | Data, IAM/security, and Tool Catalog owners approve their respective boundaries | Technical owner configures the approved identities, Data Boundaries, and tool actions | Policy/control owner; compliance/legal/privacy; operations | Identity and authority snapshots, data approval, Tool Catalog entries, versions, scopes, and tests | Excess privilege, unapproved source, unregistered tool, missing owner, or incomplete receipt |
| 4. Approve the Release | Agent product/technical owner approves the technical Release | Engineering and component owners build, test, and stage the Release | Business Process owner; model assurance; data; IAM/security; tool; policy; operations | Release manifest, evaluation, policy Simulation, access review, evidence test, and Rollback result | Failed threshold, changed purpose, unresolved exception, evidence gap, or failed Rollback |
| 5. Assemble the application | Business Process owner owns the case-entry control | Technical and data owners operate retrieval within approved boundaries | IAM/security; compliance/legal/privacy; operations | Journey ID, source references, query and source hashes, boundary version, and redaction record | Missing or duplicate case, prohibited data, boundary mismatch, stale source, or provenance gap |
| 6. Invoke model and apply policy | Policy/control owner owns the routing verdict; technical owner owns execution integrity | Technical, model, data, and tool owners execute approved versions and capture receipts | Model assurance; IAM/security; business Process owner | Model and Release IDs, input and output hashes, policy version, matched rules, verdict, and timestamps | Unapproved version, policy bypass, rule conflict, excess tool action, or threshold breach |
| 7. Decide the consequential case | Named human approver owns the case decision; business Process owner owns the outcome framework | Underwriter reviews evidence and approves, denies, returns, or escalates within authority | Policy/control owner; compliance/legal/privacy; model assurance | Decision Request, evidence shown, authority snapshot, decision, rationale, and decision time | Insufficient evidence, reviewer conflict, expired authority, manipulation signal, or impact beyond mandate |
| 8. Commit and communicate the outcome | Business Process owner owns the final Process outcome | Operations and technical tool owners write the approved decision and issue required communication | Named human approver; compliance/legal/privacy; policy/control owner | Approval reference, tool request and response, before and after state, notice, and review route | Outcome mismatch, extra side effect, failed notice, broken review route, or missing receipt |
| 9. Monitor and respond | Operations and incident commander owns incident decisions | Operations, technical, IAM/security, data, tool, policy, and vendor owners investigate and contain | Business Process owner; model assurance; compliance/legal/privacy | Outcome monitoring, alerts, affected-case list, incident timeline, containment, recovery, and retest | Material drift, repeated exception, rights impact, data exposure, uncontrolled action, or evidence loss |
| 10. Change or retire | Business Process owner approves changed use or retirement; technical owner approves the Release | Technical and all affected control owners reassess, release, revoke, archive, or decommission | Executive sponsor; model assurance; compliance/legal/privacy; vendor owner; operations | Change assessment, new matrix, tests, approval, revocations, data disposition, and retained evidence | Purpose change, substantial modification, dependency loss, failed reassessment, or incomplete closure |
Provider and deployer responsibility in the loan example
The EU AI Act defines provider and deployer through the facts. Under Article 3(3), a provider develops or has an AI system developed and places it on the market or puts it into service under its own name or trademark. Under Article 3(4), a deployer uses an AI system under its authority outside personal non-professional activity. In this example, the vendor is provider and the bank is deployer for the supplied system and stated use.
Article 25 can shift the provider role for a high-risk system when a deployer or another third party applies its own name or trademark, makes a substantial modification, or changes the intended purpose so the system becomes high-risk. Article 26 duties apply to deployers of high-risk systems and cover use according to instructions, assignment of competent and authorized human oversight, operational monitoring, action and reporting when risk or a serious incident arises, and retention of automatically generated logs under deployer control for at least six months unless other applicable law provides otherwise.
| Boundary or event | Vendor as provider in this example | Bank as deployer in this example | Evidence to retain | Legal basis |
|---|---|---|---|---|
| Role classification | Develops or has the system developed and supplies it under the vendor name or trademark | Uses the system under bank authority for the credit Process | Role assessment, system identity, intended purpose, names and trademarks, contract, and approval | Article 3(3)–(4) |
| Instructions and operating conditions | Defines the supplied system scope, instructions, declared limitations, and supported configuration | Uses the high-risk system according to instructions and documents any operating condition or exception | Instructions and version, bank configuration, operating procedure, exceptions, and owner approval | Article 26(1) |
| Human oversight | Provides the high-risk system capability for effective oversight within the supplied design | Assigns oversight to people with the necessary competence, training, authority, and support | Oversight design, role assignment, training, authority, Decision Requests, rationales, and overrides | Articles 14(1)–(4) and 26(2) |
| Monitoring, risk, and serious incident | Receives and acts on bank reports within the provider and contractual scope | Monitors operation and takes the required action and reporting steps when risk or a serious incident arises | Monitoring review, risk and incident records, supplier notification, response, containment, and follow-up | Article 26(1)–(6) |
| Logs under each party's control | Retains automatically generated high-risk-system logs under provider control for at least six months, subject to other applicable law | Retains automatically generated logs under deployer control for at least six months, subject to other applicable law | Log inventory, control mapping, retention schedule, legal override, access record, and deletion evidence | Articles 19(1) and 26(6) |
| Rebranding, substantial modification, or purpose change | The original provider position changes for the specific system according to Article 25 conditions and cooperation rules | The bank can become provider of the high-risk system when the Article 25(1) conditions are met | Change assessment, trademark and purpose record, modification analysis, written agreement, technical access, and new role approval | Article 25(1)–(5) |
Keep current legal status attached to the responsibility record
Regulation (EU) 2024/1689 is law in force with phased application. The June 2026 Digital Omnibus on AI had been finally adopted by Parliament and Council as of the 14 July 2026 source review. Official Journal publication and entry into force remained pending. The final adopted text sets 2 December 2027 for Article 6(2)/Annex III stand-alone high-risk systems and 2 August 2028 for Article 6(1)/Annex I product-embedded systems.
The Council final-adoption notice stated that publication would occur shortly and entry into force would follow on the third day after publication. Keep the in-force Regulation and the adopted amendment as separate status records until EUR-Lex confirms publication and entry into force. Recheck the consolidated legal text before using the dates in a legal conclusion.
Keep internal audit independent from management responsibility
The IIA Three Lines Model assigns risk ownership and management to first-line roles, expertise, support, monitoring, and challenge to second-line roles, and independent and objective assurance and advice to internal audit. The lines describe roles and can span several departments.
Management retains agent design, approval, operation, control ownership, risk acceptance, and remediation. Internal audit sets its own scope, criteria, sampling, procedures, finding ratings, conclusion, reporting route, and follow-up. Advisory work needs documented safeguards whenever it could affect later independence.
| Role group | Owns | Produces | Boundary for internal-audit reliance |
|---|---|---|---|
| First-line management | Business outcomes, agent operation, control design and operation, incidents, risk acceptance, and remediation | Approvals, runtime records, control reviews, incidents, outcomes, exceptions, and remediation evidence | Management evidence is subject to completeness, integrity, and operating-effectiveness testing |
| Second-line roles | Expertise, standards, support, monitoring, and challenge within risk, compliance, security, privacy, and model-assurance mandates | Assessments, challenge records, monitoring, exceptions, opinions, and escalations | The degree of objectivity, competence, scope, period, and source reliability determines reliance |
| Internal audit | Independent audit plan, scope, criteria, procedures, conclusion, reporting, and verified follow-up | Population and sample records, workpapers, findings, report, and closure verification | Internal audit preserves independence and avoids management approval or control ownership for the system under audit |
Map responsibility to operating evidence in KLA
A responsibility matrix becomes operational when each named owner can point to a current control and source-of-truth artifact. The product mapping below connects the ownership decision, runtime action, reconstruction record, ongoing review, and retained evidence without changing the underlying responsibility.
| Responsibility need | KLA surface | Operating record |
|---|---|---|
| Name agent ownership, approved Releases, state, and accountable Process | Agent Registry | Agent owner, Release history, approval state, operating boundary, and retirement status |
| Name each tool owner and govern actions, scopes, versions, and status | Tool Catalog | Tool owner, action contract, permission boundary, version, receipt requirement, and suspension state |
| Define control objectives, rules, thresholds, routing, and exceptions | Policy Builder | Policy owner, approved version, Simulation results, rules, thresholds, and exception lifecycle |
| Route consequential cases to a named person with current authority | Decision Desk | Decision Request, evidence presented, reviewer authority, decision, rationale, and timestamp |
| Reconstruct the Journey and inspect the chronological control record | Lineage Explorer + Audit Trail | Identity, inputs, model and tool calls, policy verdicts, human decisions, effects, and correlated events |
| Review control health, drift, outcomes, alerts, and remediation | Assurance Center | Assurance Alert, owner review, affected population, Remediation Plan, retest, and closure |
| Retain review-ready artifacts and independently verifiable packages | Evidence Room | Responsibility matrix, approvals, assessments, manifests, integrity metadata, reports, and retained case evidence |
Test whether AI agent responsibility is real
A board, regulator, or internal auditor can ask these questions and require a named owner plus a contemporaneous artifact for every answer. An org chart, committee name, or supplier assertion alone leaves the responsibility unproven.
- 1. Is one named business Process owner accountable for the agent purpose, production use, outcomes, incidents, changes, and retirement?
- 2. Can that owner stop the agent, restrict its operating boundary, fund remediation, and explain every accepted exception?
- 3. Does every Release, policy, data source, identity, tool, and vendor dependency have a current owner with approval authority?
- 4. Can the organization trace each consequential action to the agent, sponsoring principal, policy verdict, named human decision, tool effect, and business outcome?
- 5. Do the four relevant operating-model variations appear in the approved matrix, with every changed assignment and retained boundary documented?
- 6. Can each named human approver prove current authority, evidence reviewed, conflict status, decision, rationale, and timing for the case?
- 7. Can the incident commander identify the full affected population, revoke authority, contain execution, recover safely, notify required parties, and prove retesting?
- 8. Does every material model, prompt, policy, permission, tool, data, Process, or supplier change trigger reassessment and a new approval decision?
- 9. Are provider and deployer roles documented from the actual name, authority, purpose, modification, and operating facts, with Article 25 changes reassessed?
- 10. Does internal audit have independent access to complete populations, source records, specialists, governing-body reporting, and follow-up evidence?
Foire aux questions
Who is accountable when an AI agent makes a mistake?
The accountable business Process owner owns the production use and business outcome. The incident commander owns containment and recovery decisions, while technical, model, data, security, tool, policy, approval, and vendor owners answer for their defined controls. The incident record should identify the failed boundary, responsible owner, affected population, remediation, and executive escalation.
What is the difference between provider and deployer responsibility?
Under Article 3 of the EU AI Act, a provider develops or has a system developed and places it on the market or puts it into service under its name or trademark; a deployer uses a system under its authority outside personal non-professional activity. Article 25 can shift the provider role after rebranding, substantial modification, or a purpose change that makes the system high-risk. Article 26 assigns conditional operating duties to deployers of high-risk systems.
Can accountability for an AI agent be delegated to a vendor?
A vendor can own contracted design, service, control, incident, change, and evidence responsibilities. The enterprise business Process owner retains accountability for using the agent within the enterprise Process, including operating conditions, affected-person decisions, outcome review, containment authority, supplier acceptance, and exit. Put both scopes in the contract and internal responsibility matrix.
What does internal audit own for AI agents?
Internal audit owns its audit universe, engagement scope, criteria, sampling, reliance decisions, procedures, findings, conclusion, reporting, and follow-up verification. Management owns the agent, controls, approvals, risk acceptance, operation, incidents, and remediation. This separation supports the independent and objective assurance role described by the IIA Three Lines Model.
Who approves a consequential AI agent decision?
A named human approver decides the individual case within documented authority when human approval is mandatory. The business Process owner owns the decision framework, staffing, outcome quality, and remediation. The policy/control owner owns routing criteria, and the technical owner ensures execution waits for a valid decision record.
How should responsibility work in a multi-agent system?
Name one business Process owner for the final outcome and one technical owner for orchestration. Assign an owner to every agent, tool, identity, data boundary, policy, and vendor dependency. Authenticate each handoff, propagate purpose and delegated limits, retain action receipts, contain cascading failure, and reconcile the final Journey to every contributing owner and effect.
Points clés à retenir
AI agent accountability becomes defensible when one business Process owner holds outcome authority and every lifecycle decision, runtime control, artifact, escalation, and retained boundary has a named owner. Apply the scenario-specific variation, trace one consequential Journey, document provider and deployer facts, and preserve internal-audit independence. Use the enterprise AI agent audit framework for full fieldwork and the Agent Audit Readiness Assessment to identify missing ownership, authority, controls, and evidence.