The release meeting had business, data, technology, legal, risk and validation leaders in attendance. Every person could advise. Four were marked accountable in the project chart. Yet when the chair asked who could accept the operating consequence, reject inadmissible data or stop an unrecoverable release, the room produced six different answers.

The problem was not insufficient participation. It was an undifferentiated approval object. The meeting had combined business purpose, data admissibility, model design, control sufficiency, technical release and incident authority into one apparent decision. Functional claims pulled it apart only after the release was ready.

Business understands the decision population, workflow and outcome. Data stewardship understands meaning, provenance and permitted use. Technology understands engineering integrity, service and recovery. Risk frames risk expectations and challenges control. Legal and compliance interpret binding requirements. Validation and audit need independence. None of these facts grants one function unilateral authority over the entire system.

Decision rights must therefore attach to a bounded decision object. Every object has one owner, a proposer, any binding specifier, an independent challenger, a named constraint or veto condition, an assurer where needed, an evidence standard, service time, conflict rule, signed receipt and review trigger.

The strong rival is speed. A single empowered AI leader can make integrated choices quickly, and this is sensible for low-consequence, reversible decisions when the leader has real business authority, necessary expertise and declared constraints. Separation becomes necessary where incentives conflict, law or policy controls admissibility, assurance must be independent, or failure affects people beyond the product team’s remit.

This article’s AI rights grammar preserves integrated decisions without pretending every role has the same kind of authority. It also prevents a specialist function from becoming outcome owner by default. A forum may host deliberation; a named role signs the object.

Original synthesisGive each authority claim a precise verb

The AI rights grammar uses six verbs because approve and consult conceal materially different powers. A verb states the action a role may take, the evidence it must see and the consequence of exercising the right.

Own is singular for a bounded object. The owner has information, authority and operating access, not merely a name in a chart. Ownership includes the duty to remediate, capture outcome, respond to challenge and decide whether the object continues.

Propose creates motion without granting self-ratification. Product, business, data science or engineering may prepare the release case. The proposal identifies assumptions, alternatives and missing evidence. An owner can accept, revise or reject it within binding constraints.

Specify is stronger than advice and narrower than ownership. A data role can specify provenance and permitted-use requirements. Technology can specify recoverability and interface requirements. Risk can specify a control standard within delegated policy. A specification states its basis and admissible range so that preference does not masquerade as constraint.

Challenge is an independent test, not a second design desk. It can reveal unsupported assumptions, incentive bias, weak controls or missing populations. The challenger does not become owner by raising an objection, and the owner cannot erase a valid constraint by accepting the outcome risk.

Constrain or veto is the sharpest verb. It exists for a named legal, policy, safety, security, data-right or risk-appetite condition. It identifies who decides whether the condition is met, which evidence counts, how quickly the role must respond and where a contested interpretation escalates. An informal ability to delay is a shadow veto and weakens both speed and accountability.

Assure draws an independent conclusion after examining design or operation. A validator who selected model parameters cannot independently validate those choices. Internal audit can coordinate and rely on other assurance work, but retains the independence and evidence needed for its own conclusion.[6]

Formal authority can differ from real authority when information and execution sit elsewhere.[2] Specific knowledge also shapes where decisions can be made effectively.[1] The grammar therefore records service time and evidence access beside formal rights.

Lifecycle registerAllocate verbs across eight decision objects

The rights register decomposes the AI lifecycle into eight objects. Decomposition prevents authority over one object from spilling into another. It also makes conflict diagnosable: two functions may not disagree about one decision at all, but may be asserting valid rights over adjacent objects.

Business purpose and outcome defines the problem, intended benefit, acceptable consequence and capture owner. A business or product role owns it. Risk, legal, data and technology contribute constraints and evidence, but technical feasibility cannot establish business acceptability.

Decision population and workflow identifies eligible cases, users, human intervention, fallback and operating change. The workflow owner accepts the consequence of adoption and has authority to change work. A sponsor who cannot alter the workflow is not the real owner.

Data meaning and permitted use covers semantics, provenance, quality, purpose, access and retention. A data or legal authority can specify or withhold an input that is not admissible. The business outcome owner cannot waive a right that sits outside its mandate. The object records the legal or policy basis and the evidence needed to establish admissibility.

Model, vendor and architecture covers component choice, integration, technical fitness, portability and dependency. Technology normally owns the engineering object and proposes design options. Business owns neither implementation detail nor technical integrity simply because it funds the outcome.

Risk classification and control standard assigns category, tolerance and required control properties under policy. First-line ownership remains with the business or product. Risk may specify and challenge within its mandate, but becomes a conflicted second product team if it designs daily workflow and threshold choices.

Validation and evidence sufficiency determines whether evidence supports the claim for the intended context. The validator owns its conclusion and must remain separate from the design choices it evaluates. Validation can find evidence insufficient without inheriting the business outcome.

Release and production change decides whether a tested configuration enters or expands production. Technical release authority can reject an unrecoverable change. The product owner decides whether the supportable change advances the outcome. High-consequence releases may need both objects signed rather than one generic approval.

Incident, stop and retirement defines detection, immediate restriction, customer or regulator response, remediation and removal. Incident command can exercise temporary authority. The product or workflow owner retains accountability for consequence and remediation, while a declared safety, legal or risk condition can trigger a stop.

IT governance research treats decision rights and accountability as an organisational design problem rather than a technology checklist.[3] Work separating decision initiation and implementation from ratification and monitoring also helps explain why proposal, ownership and assurance should not collapse into one verb.[4]

Negative controlReplace the RACI mirage with an executable clause

A RACI can help show participation, but it cannot distinguish specification from challenge, a lawful veto from advice, or assurance from approval. Marking business, data, technology and risk accountable does not create integration. It creates several signatures without a decision owner.

In the RACI mirage, the business sponsor approves the value claim, technology approves production readiness, data approves its pipeline and risk approves controls. The release proceeds because every column is green. When the decision quality declines, each role points to the object it signed and no role can restrict the whole operating consequence.

The typed clause starts with one object: release this credit-decision support configuration to a named population. It names a product owner, an engineering proposer, data and security specifications, independent risk challenge, an unrecoverable-release veto held by technology, independent validation assurance, and escalation to named executives within a service time.

A signature is a receipt, not a ceremonial approval. It records the object, version, evidence considered, constraint status, exceptions, owner decision and next review trigger. If the object changes, the old receipt remains historically true but cannot govern the new configuration.

The technology-as-business failure occurs when a working service enters production without a workflow owner accepting consequence. Reliability, scalability and recovery evidence may be excellent. The absence is business authority over use, intervention, outcome and benefit capture. Technical release can be necessary without being sufficient.

The business-overreach failure is the reverse. A sponsor cannot instruct the team to use a dataset whose purpose, provenance or rights remain inadmissible. The business owns the outcome object, not every input. The data or legal specifier records the condition and its basis; if it cannot be resolved, the release stops or uses a different input.

NIST assigns lifecycle risk outcomes across governance, context, measurement and management, including defined roles, representative evidence, monitoring and independent review.[7] The Playbook offers voluntary actions that can be allocated to these rights without pretending one universal role design.[8]

Line boundariesSeparate ownership, challenge and assurance without isolating expertise

Independent challenge needs proximity to evidence and distance from the incentives it tests. Isolation creates late surprise; participation in design creates self-review. The rights contract gives challengers early access to the object, assumptions, data and tests while withholding ownership of the proposal and outcome.

First-line business and product roles own the use, outcome and controls in operation. A second-line risk role sets or interprets policy within delegated authority, challenges the first line and monitors the risk view. Internal audit provides independent assurance over governance, risk management and control. The lines coordinate, but their conclusions do not merge.

Risk-as-owner is a structural failure. When risk designs the workflow, selects operating thresholds and decides daily exceptions, first-line responsibility becomes ceremonial. Risk also loses a credible position from which to challenge whether those choices work. The correction returns outcome and operating choices to the first line while retaining any binding risk specification and escalation.

Validation conflict follows the same logic. A validator can advise on evidence design without choosing the model’s parameters or optimising the final configuration. If practical scarcity requires deeper participation, the receipt discloses the conflict and assigns independent review elsewhere. Calling a conclusion independent does not make it so.

The current supervisory model-risk guidance emphasises effective challenge, validation, governance and internal-audit boundaries, including conflicts and the need to adjust practices to context.[9] Banking governance principles similarly distinguish board, senior management, control and audit responsibilities.[10]

Independence is not a reason to create a serial queue. The owner provides evidence in a reusable form; challengers declare questions early; assurance reuses work only when its quality, scope and independence are sufficient. Service time, escalation and expiring requests prevent challenge from becoming an unbounded delay.

Constraint designTurn shadow vetoes into narrow declared conditions

A shadow veto exists when a role can halt progress through delay, repeated requests or informal escalation but cannot state the condition it owns. The product team cannot plan around it, the role cannot be held to a service time, and leaders cannot distinguish a binding objection from preference.

A declared veto clause names five elements. The condition states the exact breach, such as absent lawful purpose, release without tested recovery, exposure above delegated appetite or failed independent evidence. The basis links it to law, policy or assigned authority. The evidence test states how the condition is established. Service time sets a response window. Escalation names the role that resolves interpretation without waiving a non-waivable obligation.

Narrowing a veto does not weaken control. It makes a legitimate stop faster and more defensible because evidence and authority are known. It also prevents an objection about one input from quietly vetoing a different business object. Where the condition concerns only an inadmissible dataset, the owner can choose another source without reopening the business purpose.

Reversibility changes the rights design. A low-consequence configuration with tested rollback may use delegated release authority and review after operation. An irreversible or high-consequence action requires stronger evidence, an earlier challenge and a tighter stop route. Delegation remains bounded by the consequence, not the prestige of the owner.

Operational resilience principles connect governance with critical operations, dependency, tolerance, continuity and learning.[11] The rights register uses those connections to make release and incident authority executable, while avoiding a broad claim that every control function owns resilience.

The escalation route records what can be decided at each level. Factual evidence gaps return to the proposer. Policy interpretation goes to the policy owner. Conflict between valid business and risk choices goes to the executive holding delegated trade-off authority. Legal prohibition is not escalated as if it were a risk preference.

Worked successSign the credit-decision support objects separately

A credit-decision support capability prepares evidence and a recommendation for an authorised credit officer. The business purpose is better-supported, timely decisions for a named population. The workflow owner signs purpose, population, human authority, fallback and outcome capture. The capability does not own the lending decision.

Data stewardship specifies source meaning, provenance, purpose, quality and retention. If a proposed behavioural dataset lacks an admissible purpose or reliable provenance, the data or legal authority withholds that input. Business can change the proposal or population, but cannot accept the data breach on behalf of affected people.

Technology owns model, vendor and architecture integrity and proposes the release configuration. It can stop a release whose recovery, security or service dependency fails an explicit engineering condition. This right is not authority to decide that the lending workflow or outcome is acceptable.

Risk owns the classification and delegated control-standard object. It specifies required human intervention, evidence retention, monitoring and escalation properties, then challenges the product’s implementation. It does not select the commercial threshold or design the officer’s daily workflow.

Independent validation owns its evidence-sufficiency conclusion. It evaluates representative performance, limitations, stability, human use and control evidence without selecting the parameters being tested. A qualified conclusion identifies the bounded gap and population rather than becoming a vague refusal to approve AI.

The release receipt joins, but does not merge, these rights. The product owner signs business release for the named configuration and population. Technology signs recoverability and service fitness. Data signs admissibility. Risk records control-standard conformance and challenge. Validation records its conclusion. Any exception states owner, expiry and compensating action.

Incident rights are prepared before release. Operations can isolate a failing service. The workflow owner can shift cases to the manual route. Data can stop an inadmissible feed. Technology can roll back. A named incident authority coordinates action, and the product owner remains responsible for affected decisions, remediation, communication and value consequences.

The EU AI Act assigns distinct obligations to providers, deployers and other actors, with requirements including risk management, human oversight, quality management and deployer duties for applicable high-risk systems.[12] The worked map is an organisational design synthesis, not a claim that those functional titles are prescribed by the Regulation.

Original synthesisResolve the conflict at the level of the decision object

The Decision-Rights Conflict Resolver starts by naming the object and consequence. A broad object such as approve the AI system is likely to contain several distinct owners and constraints. The resolver tests whether the object should be narrowed before it considers who has the strongest functional claim.

A proposed owner is credible only when it owns the downstream outcome, can change operation, has access to relevant evidence and can remediate or stop. Seniority and sponsorship are insufficient. The capture owner also matters: a product role that cannot alter workflow, demand, staffing or service scope cannot own a claimed productivity outcome alone.

Functional claims are translated into verbs. Business may own purpose and propose population. Data may specify admissibility. Technology may propose architecture and veto an unrecoverable release. Risk may specify a control standard and challenge implementation. Validation may assure evidence sufficiency. A conflict often disappears when valid claims attach to different verbs.

If ownership and challenge sit with the same incentivised role, the route separates first-line ownership from independent challenge. If a stop right has a legitimate basis but vague scope, the route narrows and formalises the veto. If several owners are valid because the object combines purpose, data and release, the route splits it and joins the resulting receipts.

The stop route is not a request for a larger forum. It applies when no role has real authority, data or purpose is inadmissible, a binding condition lacks an interpretation owner, or high consequence meets missing evidence with no safe escalation. The next decision is to resolve authority or redesign the proposal before operation.

The positive route confirms one owner and typed inputs. It remains available for high-consequence decisions only when evidence, independence, admissibility, service time, escalation and receipt are strong. Consequence changes the burden of proof and delegation, not the principle of singular ownership.

The final rights clause is versioned. It records the object, owner, every operative verb, constraint basis, evidence standard, response clock, escalation, signature and review condition. A policy, population, vendor, workflow or authority change can reopen it. The operational register therefore describes current authority rather than preserving a historical organisation chart.

ISO/IEC 42001 provides an AI management-system standard, while the OECD AI Principles include accountability and robustness across the lifecycle.[13][14] The resolver supplies one practical allocation mechanism inside such broader systems; it is not a substitute for applicable law or organisational mandates.

ConclusionMake authority as specific as the decision

AI decision rights fail when broad functions are treated as owners of one undifferentiated system. Business, data, technology, risk, legal, validation and audit hold different expertise, incentives and mandates. Their legitimate claims become compatible when attached to bounded objects and precise verbs.

The six-verb grammar distinguishes ownership from proposal, binding specification, independent challenge, constrained veto and assurance. The eight-object register applies those verbs across purpose, workflow, data, architecture, risk standard, validation, release and incident or retirement. A forum can connect the objects, but each receipt has one owner.

The design is faster because service time, evidence and escalation are part of the right. An owner knows which inputs bind. A challenger knows when and how to respond. A veto holder can state the exact condition. An assurer can preserve independence without arriving after the decision.

The difficult boundaries remain explicit. Risk does not become product owner by setting a standard. Technology does not decide business acceptability by proving reliability. Business cannot waive data rights beyond its authority. Validation cannot design and independently approve the same choice. Multiple approval signatures cannot substitute for a person able to remediate and stop.

Some conflicts require separation; others require decomposition. High consequence may justify an independent line and a narrow veto. A broad AI approval usually needs to split into purpose, admissibility, technical and release objects. Unresolved authority or inadmissibility is a stop condition, not an invitation to manufacture consensus.

The operational rights register changes when evidence, policy, population, vendor, workflow or real authority changes. That makes the organisation’s formal rights track how decisions are actually made. Clear authority is not the absence of cross-functional work. It is the condition that allows expertise, constraint and independence to work together without losing the owner.

Evidence spineReferences

1. Jensen, M. C. and Meckling, W. H. (1995), ‘Specific and General Knowledge, and Organizational Structure’, Journal of Applied Corporate Finance, 8(2), 4–18. doi:10.1111/j.1745-6622.1995.tb00283.x.
2. Aghion, P. and Tirole, J. (1997), ‘Formal and Real Authority in Organizations’, Journal of Political Economy, 105(1), 1–29. doi:10.1086/262063.
3. Weill, P. and Ross, J. W. (2004), IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press. Harvard Business Review Store.
4. Fama, E. F. and Jensen, M. C. (1983), ‘Separation of Ownership and Control’, Journal of Law and Economics, 26(2), 301–325. doi:10.1086/467037.
5. Institute of Internal Auditors (2026), ‘Statement of Position on the Three Lines Model’. IIA statements of position.
6. Institute of Internal Auditors (2024), Global Internal Audit Standards. IIA Standards.
7. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AIRC Core.
8. National Institute of Standards and Technology (2023), ‘AI RMF Playbook’. NIST AIRC Playbook.
9. Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency and Federal Deposit Insurance Corporation (2026), ‘Revised Guidance on Model Risk Management’, SR 26-2. Federal Reserve.
10. Basel Committee on Banking Supervision (2015), Corporate Governance Principles for Banks. Bank for International Settlements.
11. Basel Committee on Banking Supervision (2021), Principles for Operational Resilience. Bank for International Settlements.
12. European Union (2024), ‘Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence’, Articles 9, 14, 17, 25 and 26. EUR-Lex.
13. International Organization for Standardization and International Electrotechnical Commission (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO standard record.
14. Organisation for Economic Co-operation and Development (2024), ‘OECD AI Principles’. OECD.AI.