Showing Posts From
Change management
- 10 Jun, 2026
The Organizational Change Nobody Plans for When AI Goes Into Production
Technical AI programs plan for model performance, infrastructure reliability, and user adoption. The change management plans in most AI programs cover communication, training, and rollout support. These are necessary. They are not sufficient. What does not make it into the program plan is the organizational change that AI deployment actually creates: changes in who makes decisions, where accountability sits, and how existing roles need to adapt. These changes are not side effects of the technical program — they are the substance of what AI deployment means for how the organization operates. And they tend to surface six to twelve months after go-live, in the form of confusion about accountability, conflict between roles that now overlap, and resistance from functions that feel their judgment has been displaced. Addressing these changes proactively requires treating AI deployment as an organizational design question, not just a technology one. The decision rights problem AI systems are good at making or informing decisions that humans previously made alone. When an AI system produces a recommendation — in credit assessment, in demand forecasting, in HR screening, in customer prioritization — the human who used to make that decision now has a different role. They are either ratifying the AI's recommendation, overriding it, or working alongside it in a way that requires a new kind of judgment. This changes the nature of the role without changing the job title or the org chart. The credit analyst who used to run the full assessment is now running exception management. The demand planner who used to construct forecasts is now reviewing and adjusting AI-generated ones. The recruiter who used to screen applications is now reviewing a pre-filtered shortlist. These are not simpler jobs. In some respects they are harder — they require a different kind of expertise, specifically the ability to evaluate AI outputs critically rather than produce analysis independently. The people in these roles may have been selected and developed for the original capability profile, not the new one. Organizations that do not address this explicitly produce two failure modes. People who struggle with the new role either resist the AI system — finding reasons not to use it, overriding it more than the data warrants — or over-defer to it, approving AI recommendations without the critical review that the accountability structure requires. The accountability gap When a decision goes wrong in a human-only process, the accountability is reasonably clear. When a decision informed by an AI recommendation goes wrong, the accountability is murkier, and organizations that have not thought about it in advance tend to discover this in a difficult situation. Was the decision wrong because the AI recommendation was wrong? Or because the human failed to apply appropriate judgment to a valid AI recommendation? Or because the system was deployed in a context it was not designed for? Or because the training data did not reflect the conditions that produced this specific case? None of these questions have clean answers in an organization that has not set up the accountability structure deliberately. The result is attribution conflict: the AI team points to the human decision-maker, the business function points to the AI system, and nobody has clear accountability for remediation. Defining accountability for AI-informed decisions before deployment is one of the most important organizational design questions in any AI program. It requires a clear statement of where human judgment is required, what escalation looks like when the AI recommendation is overridden, and what the process is for determining whether a decision-quality problem is an AI problem or a human judgment problem. The capability shift The capability an AI system replaces does not simply disappear from the organization's needs — it transforms. The expertise required to interpret and challenge AI outputs is often closely related to the expertise required to produce the underlying analysis manually. But they are not the same skill, and the transition period between the two is where the most significant organizational risk sits. In the immediate period after AI deployment, the organization typically has people who are capable of doing the work manually but are still learning to use the AI tool effectively. This is manageable. The medium-term risk is more significant: if the organization stops developing the underlying manual capability because AI handles it, and the AI system underperforms or becomes unavailable, the recovery is slower than anyone anticipated. This is not an argument against AI deployment. It is an argument for being deliberate about which capabilities the organization maintains independently of the AI system and which it allows to atrophy as AI performance becomes reliable. The role boundary conflicts When AI tools augment work across function boundaries — a customer-facing AI system that pulls from data owned by multiple departments, an AI planning tool used by both finance and operations — the organizational boundaries that existed for human work do not automatically translate. Who decides what data the AI system uses? Who is accountable if the AI produces an output that reflects poorly on a specific function? Who decides when the AI recommendation should be overridden? When the AI generates recommendations that one function disagrees with, what is the escalation path? These are organizational design questions dressed as AI governance questions. They arise because AI systems do not respect the lines between functions in the same way that human roles do. The AI pulls on data from wherever it can reach and produces outputs that may reflect or implicate multiple functions simultaneously. The organizations that handle this well have addressed it before go-live: clear data ownership, a governance structure for the AI system that is recognized by all the functions it touches, and escalation paths that do not depend on functional boundaries that the AI system has already made ambiguous. The human-in-the-loop question Most AI programs that include human review in their design treat it as a quality control mechanism: the human checks the AI output before it is acted on. This framing is correct but incomplete. The human in the loop is also, and more importantly, the locus of accountability for the decision. If the human review is a checkbox rather than a substantive check, the accountability protection is illusory — the organization has the appearance of human oversight without the substance. Regulators, clients, and courts are unlikely to accept "a human reviewed it" as a sufficient defense for a poor decision if the review process was not meaningful. What meaningful human oversight looks like — how long it should take, what the reviewer is expected to assess, what training they need, what recourse they have when they disagree with the AI — needs to be specified in the organizational design of the AI system, not left to individual judgment. What to take from thisMap how AI deployment changes existing decision rights before go-live. The people whose roles are affected need to understand the new expectation before the system is live, not after they have defaulted to the wrong behavior. Define accountability for AI-informed decisions explicitly. The accountability structure needs to specify where human judgment is required, what override looks like, and how decision-quality problems are attributed and remediated. Assess the capability implications of AI deployment over a three-to-five year horizon. Identify which capabilities the organization intends to maintain independently and which it is comfortable allowing AI to own. Address function boundary conflicts before deployment. The organizational design questions created by AI systems that cross functional lines need governance structures that all the affected functions recognize. Human-in-the-loop design needs to specify what meaningful review looks like, not just that review occurs. Checkbox oversight creates accountability risk, not accountability protection.
Read full article