Cognitive Responsibility Diffusion™ started long before agentic AI — the first time a tax exception was approved by someone who was Consulted on the decision rather than Accountable for it.
The site has already covered Cognitive Responsibility Diffusion™ at machine scale — the condition in which an automated agent executes a determination that a human remains formally responsible for but can no longer fully reconstruct. That version of the framework is real, and it is where the risk compounds most visibly. Chapter 11 of Real-Time Tax Transformation traces the same diffusion back to its origin, a much older and more familiar failure: a governance structure built around function names — Tax owns the tax position, IT owns the system — rather than around the specific decision points where those functions actually hand a transaction to each other.
RACI is the discipline that is supposed to prevent this, and it fails almost every time for the same reason: the letters get applied loosely under delivery pressure until the distinctions between them collapse. Responsible is the role that does the work, and it fails the moment it is assigned to a team rather than a named role, because a team-level Responsible belongs to whoever happens to notice the work needs doing. Accountable is the single person who answers for the outcome, including when a system produced it without human review, and it fails in one of two ways: assigned by default to whoever has "tax" in their title regardless of whether they had visibility into the upstream conditions, or left entirely unassigned at the boundary between two functions, because that boundary sits between them and neither claims it. Consulted means input required before a decision, not after it, and it fails when a change reaches a live system with Tax merely notified rather than involved. Informed means notified of the outcome with no decision right attached, and it fails in both directions — downgrading functions that should have had real input, and burying genuine notifications in a change log nobody reads at the point it mattered.
Chapter 11's four data categories make the point concrete. Master data — customer registration status, product classification, entity tax profiles — is typically maintained by Finance or an MDM team but defaults to Tax as Accountable by title, even though Tax controls neither the maintenance process nor the system validation that should catch a blank field. Transaction data — generated by Operations at the point of a sale or delivery — creates a gap that is the most commonly unowned position in the whole model: nobody is Accountable for whether what Operations generated and Finance recorded was correct at the specific moment it needed to be, rather than correctable later during a return cycle a real-time environment no longer allows. Contextual data — delivery confirmations, proof of service, pricing basis — is generated by Operations or Finance for operational reasons and routinely discarded once that operational purpose is served, with nobody accountable for the fact that it was also, quietly, the evidence a tax position depended on. Integration syntax — the mapping between an internal ERP field and the value the ASP transmits — is the highest-risk boundary of all, because IT does not know the tax consequence of a mapping change and Tax does not know its technical consequence, and a document can pass every structural validation while still transmitting the wrong meaning.
None of this requires a machine to be operating unsupervised. It requires two functions, a shared decision, and no single person answering for where their work meets. The diffusion Chapter 11 describes is what happens when accountability is assigned to a title on an org chart instead of to the actual point at which a decision is made — a condition that predates any agent, and one that makes the machine-scale version worse rather than separate from it. An enterprise that has never closed this human-scale gap has nothing solid to hand off to the automation layer when it arrives. It carries the diffusion twice over: once in the org chart, and once again in the system built on top of it.