By Sanjeeve Kumar Gajadi | Lead Consultant and SAP Enterprise Architect
Agentic AI changes the governance problem. A conventional model may recommend an answer; an agent can interpret a goal, construct a plan, select tools, retrieve information, call systems, write data, and adjust its next action from the result. The risk is therefore not limited to whether an output is accurate. It also includes whether the system was entitled to act, whether it used permitted data, whether a person could stop it, what happened when conditions departed from the plan, and who remained accountable.
CIOs should not treat these questions as late-stage compliance checks. They are architecture decisions. Before an agent enters production, the enterprise should assign five decision rights: authorization, data access, human intervention, exception handling, and accountability. Each right must have a named owner, enforceable controls, and evidence that can be reviewed after the event. Together, they form a practical boundary between useful autonomy and unmanaged delegation.
Why Decision Rights Matter
Many AI governance programs start with principles such as fairness, transparency, safety, privacy, and accountability. These principles are necessary, but they do not tell an identity service whether an agent may issue a refund, tell an integration layer which application programming interface may be called, or tell an operations team when to suspend an automated workflow. Decision rights convert governance intent into operational authority.
The approach aligns with the direction of established governance frameworks. The NIST AI Risk Management Framework organizes risk work around governance, mapping, measurement, and management. ISO IEC 42001 establishes an organizational management system for responsible development and use of AI. The European Union AI Act emphasizes risk management, data governance, technical documentation, record keeping, human oversight, accuracy, robustness, and cybersecurity for covered systems. These frameworks create the management context. Enterprise architecture must translate that context into controls that operate at runtime.
A decision right is not merely a role on a responsibility chart. It answers three questions: who may decide, what conditions constrain the decision, and what evidence proves that the decision was applied. If any of these elements is missing, the organization may have a policy but not an effective control.
Decision Right 1 Authorization
The first question is simple: who is permitted to delegate which actions to an agent? Authentication proves the identity of a user or workload. Authorization determines what that identity may do. Agentic AI introduces an additional layer because the system may choose a sequence of actions that the user did not specify step by step.
The business owner should define the permissible objective and action boundary, while security and architecture teams encode that boundary through identity, access, workflow, and integration controls. Authority should be specific to the use case. An agent authorized to draft a purchase request should not automatically be authorized to approve it, create a supplier, or release payment.
A practical authorization design includes:
- Action tiers based on business impact, reversibility, financial value, and legal consequence.
- Least-privilege identities for agents, tools, and sub-agents rather than shared human credentials.
- Time-limited and purpose-bound delegation, with explicit limits on transaction value, geography, customer group, or system scope.
- Separation of duties so that one agent cannot initiate, approve, and conceal the same material action.
- Immutable records of the requesting user, delegated objective, tools invoked, approvals obtained, and final action.
The core test is whether the organization can explain why the agent was allowed to perform each consequential action. A broad service account and a generic approval are not sufficient evidence.
Decision Right 2 Data Access
An agent can combine information from multiple sources, retain context, and pass content to external tools. Data access must therefore cover more than read permission. It should define which sources the agent may query, which fields it may see, whether it may write or update records, how long memory may persist, and whether retrieved content may be sent to another model or service.
The data owner remains responsible for approving use of the data. The platform team implements technical enforcement. The AI product owner must show that the purpose of access matches the approved use case. Controls should be sensitive to classification, residency, consent, confidentiality, intellectual property, and contractual restrictions.
Minimum architecture expectations include source allowlists, row- and field-level access, masking of sensitive values, retrieval filters, provenance capture, retention limits, encrypted transport and storage, and controls that prevent prompts or tool outputs from silently becoming long-term memory. Where an agent writes data, the design should distinguish drafts from authoritative records and should preserve the prior state for rollback.
The key question is not whether the model can technically reach the information. It is whether that access is necessary, proportionate, traceable, and revocable for the declared purpose.
Decision Right 3 Human Intervention
Human oversight becomes meaningful only when the organization specifies where a person can pause, approve, redirect, or terminate the process. A statement that a system is human supervised is weak if the reviewer receives insufficient context, has no time to assess the action, or cannot reverse it.
The business and risk owners should decide which actions require human approval. Enterprise architects should then position intervention points before irreversible or high-impact actions. Examples include employment decisions, changes to customer entitlements, legal commitments, regulatory submissions, financial transfers, safety-related instructions, and modifications to production systems.
Oversight should be proportional. Low-risk, reversible activity may be monitored after execution. Moderate-risk activity may require sampling, thresholds, or approval by exception. High-impact or difficult-to-reverse activity should require approval before execution. The interface presented to the reviewer should show the proposed action, source data, relevant uncertainty, policy checks, alternatives considered, and likely consequences. A reviewer should be able to reject the action without being forced to redesign the entire workflow.
Human intervention must also include emergency controls: a kill switch, the ability to revoke credentials, the ability to isolate a tool, and a defined procedure for resuming service safely.
Decision Right 4 Exception Handling
Agents operate in changing environments. A tool may be unavailable, returned data may conflict, an instruction may be ambiguous, a policy check may fail, or an apparently successful action may produce an unexpected downstream result. Exception handling determines what the system does when the planned path is no longer trustworthy.
The operational owner should approve the exception policy, with input from security, risk, legal, and the relevant business function. The default behavior should depend on impact and reversibility. For consequential actions, failure should be safe: stop, preserve state, record the reason, and escalate. Repeated retries or improvisation should not substitute for an approved recovery path.
The design should include confidence or validation thresholds where appropriate, circuit breakers, retry limits, idempotency controls, transaction rollback, alternate routing, incident classification, and escalation service levels. It should also distinguish technical failure from policy failure. A timeout may justify retrying; a denied policy check should not.
Testing must cover more than the normal path. Teams should simulate missing data, conflicting instructions, compromised tools, excessive permissions, prompt injection, unexpected tool responses, partial transaction completion, and loss of human availability. The result should be evidence that the system fails within an acceptable boundary.
Decision Right 5 Accountability
Accountability answers the question that remains after every automated decision: who owns the outcome? The phrase “the AI decided” is not an acceptable operating model. The enterprise delegates activity to a system, but it does not delegate responsibility.
A workable model assigns several connected accountabilities. The business owner is accountable for the purpose, expected benefit, and customer or operational outcome. The AI product owner manages the lifecycle and control implementation. The data owner approves data use and quality expectations. The technical owner maintains the platform and integrations. Risk, security, privacy, and legal functions provide independent challenge within their mandates. Operations owns monitoring, incident response, and service continuity. One named executive should remain accountable for the complete use case.
Accountability depends on evidence. The organization should retain the approved use case, risk classification, model and tool versions, instructions, data sources, policy checks, human approvals, actions taken, exceptions, monitoring results, incidents, and changes. Evidence should be searchable and understandable without reconstructing the system from application logs alone.
The purpose of this record is not documentation for its own sake. It enables oversight, root-cause analysis, regulatory response, internal audit, and informed decisions about whether the agent should continue operating.
A Compact Decision Rights Matrix
| Decision right | Primary owner | Minimum control | Required evidence |
| Authorization | Business owner | Purpose-bound authority, least privilege, action limits and separation of duties | Delegation record, approvals, identity and action log |
| Data access | Data owner | Approved sources, field controls, masking, provenance, retention and write restrictions | Access approval, data lineage, retrieval and change records |
| Human intervention | Business and risk owners | Risk-tiered approval, pause, override and emergency stop | Reviewer context, approval or rejection, override and stop records |
| Exception handling | Operational owner | Safe failure, retry limits, rollback, escalation and incident response | Exception reason, state preserved, escalation and resolution record |
| Accountability | Executive use-case owner | Named lifecycle roles, monitoring, assurance and periodic review | Use-case file, control results, incidents, changes and review decisions |
Turning the Model into an Operating Practice
CIOs can implement the five decision rights through a short sequence of architecture and governance activities:
- Inventory the agentic use case. Document the objective, users, data, models, tools, APIs, actions, memory, dependencies, and affected stakeholders.
- Classify the risk. Assess impact, reversibility, scale, autonomy, sensitivity of data, legal significance, and the ability of affected people to challenge an outcome.
- Assign the five rights. Name the person or role that may approve each right and record conditions that would require reassessment.
- Encode the controls. Implement decisions through identity, data platforms, API gateways, workflow engines, policy services, observability, and incident-management tooling.
- Test normal and abnormal behavior. Validate the expected path, boundary conditions, adversarial inputs, unavailable tools, conflicting information, partial failure, and emergency shutdown.
- Review evidence continuously. Monitor actions and exceptions, sample outcomes, test controls, investigate incidents, and reauthorize after material changes to models, tools, data, or scope.
This sequence should be part of the delivery lifecycle, not a separate governance lane. Architecture review establishes the boundaries; engineering implements them; operations observes them; and assurance functions test whether they remain effective. Changes to an agent’s tools, authority, data, or autonomy should trigger renewed review because they may alter the risk even when the underlying model is unchanged.
The CIO Agenda
The central question for agentic AI is not whether an enterprise will permit autonomy. It is where autonomy begins, where it ends, and who has the authority to define that boundary. Organizations that answer those questions explicitly can move faster because delivery teams know which actions are permitted, which controls are mandatory, and what proof must be retained.
The five decision rights provide a practical foundation. Authorization constrains delegated power. Data access limits what the agent may know and change. Human intervention preserves meaningful control. Exception handling keeps failure within a designed boundary. Accountability ensures that responsibility remains with the organization. When these rights are assigned, implemented, and evidenced, governance becomes part of the architecture rather than an approval added after the system is built.
References
National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework AI RMF 1.0, NIST AI 100-1, 2023. https://doi.org/10.6028/NIST.AI.100-1
National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework Generative Artificial Intelligence Profile, NIST AI 600-1, 2024. https://doi.org/10.6028/NIST.AI.600-1
International Organization for Standardization. ISO IEC 42001 Artificial intelligence management systems, 2023. https://www.iso.org/standard/81230.html
European Union. Regulation EU 2024 1689 laying down harmonised rules on artificial intelligence. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
Sanjeeve Kumar Gajadi is a Lead Consultant and SAP Enterprise Architect at HCL Technologies Limited. He has more than 18 years of experience across enterprise architecture, SAP platforms, data and integration architecture, cloud transformation, digital operating models, and responsible AI governance. The views expressed in this article are his own.