Anitha Krishna

I strongly support View B: Do not implement the change View A sounds like, just so that the company can make more money, its ok for customers to experience trouble. Operational mistakes have invisible costs that balance sheets don't capture. When a shipment goes wrong, the customer, who did nothing to cause it, suddenly has work to do: repacking boxes, making calls, waiting around, dealing with frustration. If a company chooses a path that creates more of these problems, they're essentially deciding their customers should absorb the expenses the company won't. Errors have a way of always flowing downstream - One workflow change leads to many problems. A 10% jump in wrong shipments triggers a chain reaction: more returns arrive, support teams get swamped, replacement requests drain reserves, and staff morale suffers as errors stop being treated as exceptions. The organization doesn't just face a higher error rate—it faces all the downstream consequences, spreading across every function that touches the supply chain. Ocado — Warehouse Automation Fire (2019) Ocado is a UK-based online grocery company widely regarded as one of the most technologically advanced e-commerce operations in the world. Its highly automated warehouses use AI, robotics, and sophisticated coordination algorithms to process grocery orders at speed. It has been genuinely innovative and largely successful. In May 2019, a fire broke out at its Andover warehouse facility — one of its most advanced automated fulfillment centers. The fire was caused by a robot collision, where three robots operating within the automated grid collided and generated a spark that ignited a fire in the structure. The blaze burned for three days and destroyed the facility entirely. The investigation pointed to coordination errors within the automated system — the AI-driven traffic management among the robots had allowed a scenario to develop that human oversight would have caught or interrupted. The financial cost was approximately £110 million. The facility had to be entirely rebuilt. Thousands of customer orders were disrupted for months. The speed of the system(quite literally as well) was also the speed at which a small error became a catastrophic one. Ocado used AI to go faster — faster warehouse throughput and the speed gain was real. The error or quality problem that accompanied the speed was treated as manageable, secondary, or solvable later. But the problem was never solved later until a significant damage had occurred. The errors were not isolated incidents. They were systemic outputs of systems that had been optimized for the wrong objective — speed or scale without a binding quality constraint — and they propagated at exactly the speed the AI was designed to operate at. While Ocado appeared in the View A section of this analysis because of its 2019 warehouse fire. It belongs to View B as well, because of what it did afterward. Following the Andover fire, Ocado did not simply rebuild the same system. It conducted a thorough root cause analysis, redesigned its robot collision detection and traffic management algorithms, and implemented enhanced physical and software fail-safes before reopening and before deploying similar systems in new facilities it was building for international retail partners. It also slowed down the licensing rollout of its technology to retail partners. This was a commercially costly decision — delays in partner deployments meant delays in licensing revenue — but Ocado's leadership concluded that deploying an unverified system into partner facilities would be more damaging than the delay. What unites Ocado and several more companies like them - Shopify, Wayfair etc is a shared institutional belief that the quality of the outcome is the product, not just the speed of the process. Each of them built structures — quality gates, parallel validation, phased rollouts, human verification checkpoints — that made speed gains conditional on accuracy being maintained or improved alongside them. Most importantly none of them had to spend years and hundreds of millions of dollars rebuilding customer trust after a preventable quality failure — which is the hidden cost that never appears in the original business case for moving fast. Rather than a binary choice between implementing or rejecting the change, the leadership team should consider a structured, phased rollout that makes speed gains conditional on quality performance. Phase 1 — Controlled Pilot Deploy the AI-recommended workflow change in a single warehouse zone or shift, covering roughly 5 to 10% of total order volume. Measure both speed improvement and error rate simultaneously and rigorously. Phase 2 — Root Cause Analysis of Errors (Parallel to Phase 1) While the pilot runs, a separate team investigates exactly what is causing the increased errors. Is it a scanning step being skipped? A labelling sequence that is ambiguous under time pressure? A picking path that creates confusion with similar SKUs? In many cases, the error increase is not inherent to the speed gain — it is a specific, fixable flaw in how the AI designed the workflow. Finding and correcting that flaw may allow the speed benefit to be retained without the quality cost. Phase 3 — Modified Rollout With Quality Gates If Phase 2 identifies correctable causes, implement the modified workflow at 30 to 50% of volume with a hard quality gate — if the error rate exceeds a defined threshold, say 2% above baseline, the rollout pauses automatically. This creates accountability and prevents normalization of errors during scaling. Phase 4 — Full Deployment With Continuous Monitoring Full rollout proceeds only if quality metrics are holding. At this stage, real-time dashboards tracking both speed and accuracy are non-negotiable. The AI system itself should be retrained to optimize for both metrics jointly, not speed alone — because the original recommendation was generated against an incomplete objective function. Speed without an accuracy constraint was always going to produce this result. The core principle of the phased approach is that the AI gave a technically correct answer to the wrong question. It was asked how to go faster, and it found a way. The leadership team's job is to ask the right question — how to go faster without compromising quality — and send the system back to work on that instead. Thanks, Anitha

I strongly support View B - Keep humans in control of implementation. Bex position states that either trust the AI to act, or lose competitive advantage. But this is not true at all, the real question is not whether humans should be involved — it is how that involvement is structured so it adds genuine value without any negative impact. Some of my arguments from my research for always keeping human in control 1.The Siemens Example actually proves View B. The Siemens automation did not happen in an autonomous environment. This is attributed to predictive analytics and digital twins, with human oversight(not to autonomous AI implementation ). At Siemens' Amberg facility, AI-based vision systems detect micro-defects in real time — but they flag potential issues for human verification, not autonomous correction. Siemens' new AI agent architecture allows users to retain complete control, selecting which tasks they wish to delegate to AI agents (https://www.businesswire.com/news/home/20250512053219/en/Siemens-Introduces-AI-Agents-for-Industrial-Automation). Siemens' own documented approach is built on human-AI collaboration with explicit human control over what gets delegated (Siemens - https://press.siemens.com/global/en/pressrelease/siemens-introduces-ai-agents-industrial-automation). 2. The important part to note in the argument is "Right Safeguards in Place", this is left undefined. If meaningful safeguards are required for autonomous AI to work safely, then the question becomes — who designs, monitors, and updates those safeguards? Humans do. Which means human oversight isn't removed — it is simply moved upstream or relocated. The accountability loop still exists. 3. In our interconnected and interdependent world the term "benefit often outweighs risk" is not acceptable when the downside is irreversible/reputational/social-ethical issues. Consider the below example for Benefit outweighing risk: The Feb-March 2017 a crisis broke when The Times of London revealed that major advertisers' ads were appearing next to videos filled with hate speech and extremist content on YouTube. None of the companies featured in the reporting were aware their ads were appearing next to this content. Every brand that was contacted said they were "really shocked" to find their ads there. How the Algorithm was Operating The brands were using a technique called programmatic advertising, which places ads next to consumers or potential customers no matter where they are on the web. The system was serving ads to the user, not buying space on individual web pages — so it had no awareness of the content context it was placing ads into (CBC Radio - https://www.cbc.ca/radio/day6/episode-331-barkley-marathons-youtube-boycott-debit-cards-for-famine-aid-2004-red-sox-champs-and-more-1.4045494/companies-are-boycotting-youtube-because-their-ads-are-showing-up-next-to-hate-filled-and-extremist-videos-1.4045499). This is the core lesson for the AI autonomy debate: the algorithm was highly confident it was reaching the right audience. It was. But it had no visibility into a dimension it wasn't measuring — reputational and ethical context. What Google Was Forced to Do Google issued tougher ad policies, increased control for marketers and hiring spree to review offensive content. So essentially they were going back to human review into a process that was entirely running on algorithm confidence. Google subsequently manually reviewed more than a million videos to improve its flagging technology, and began working with more than a dozen organizations including the Anti-Defamation League to inform its policies — human judgment that no confidence threshold had previously incorporated 4. Not everything should be executed at top-speed. Human review does not mean slowness, or a delay to competitiveness, it is used for due-diligence, accuracy and compliance. 5. Accountability Cannot Be Absorbed by Efficiency Gains - Efficiency gains from a system optimizing the wrong objective are not gains — they are institutionalized errors delivered faster at greater scale. If a person had made the same error as the AI, then would there be no legal implications on this person? What if this AI system was a healthcare system that predicted who needs extra care and wrongly flagged genuine unwell patients as not needing extra care? or other known issues like the Apple Credit Card algorithm that offered lower limits to women? The absence of human review made it nearly impossible to explain or defend these outcomes to regulators. So sometimes it help to take a deliberate and informed decision on AI implementations. The below Tiered approach will help in making choices: Tier 1 Full autonomous implementation: Low risk · Easily reversible · No customer or compliance exposure Tier 2 Shadow mode — implement, then approve: Moderate risk · Reversible within 24–48h · Limited external exposure Tier 3 Mandatory human review before any implementation: High risk · Difficult to reverse · Regulatory, financial or customer exposure Tier 4 Executive or board-level sign-off: Critical risk · Irreversible or systemic · Full legal, ethical and reputational exposure View B does not argue for slow, bureaucratic approval of every micro-decision. It argues that meaningful human oversight, proportionate to risk, is non-negotiable — and that the organizations with the strongest long-term AI track records are precisely those that maintained it.

I strongly support View B : Wait until the organization is ready. Wait does not mean resisting change, but a case for gradual implementation View B prioritizes change management alongside technical merit. The concern is not the validity of the AI's recommendation, but the recognition that implementation quality is as consequential as the recommendation itself. A projected 25% improvement yields no benefit if the deployment fails. Some points supporting View B 1. Change failure rates are catastrophically high: McKinsey and Prosci estimate that 50–70% of change initiatives miss their intended outcomes, with adoption failure and resistance consistently cited as the primary drivers. Technology soundness does not automatically imply success. If people are not onboarded, not fully consulted and their opinions and expertise not incorporated with the AI recommendation, then people could circumvent the change and execute it incorrectly or revert to old ways of execution so pretty much there is no real gain. 2. Skepticism from managers isn't irrational — it reflects a reasonable wariness toward systems that are still earning their credibility. When AI recommendations are imposed without explanation or validation, organizations learn the wrong lesson: that AI is something that happens to them, not something they can understand and engage with. That perception poisons future adoption. The opposite is equally true — a recommendation that lands through a transparent, well-staged rollout builds the kind of trust that makes the next initiative easier to champion. So improvements only count if they last. When teams don't understand the reasoning behind a change, they have no foundation to diagnose problems or adjust as circumstances evolve. Real buy-in isn't about consensus or comfort — it's about transferring understanding so people can sustain and build on what's been put in place. Some real world examples where companies adopted View B in AI domain: 1. When KPMG introduced AI tools, they didn't lead with ambition — they led with restraint. By starting with lower-risk applications and scaling incrementally, they created the conditions for trust to develop organically: feedback was gathered, governance improved, and skeptics had the chance to see the system perform before it was applied to higher-stakes decisions. Trust in AI isn't something that can be asserted or argued into existence — it has to be earned through visible, reliable performance in controlled conditions. 2. H&M — Pilot First, Scale After Proof: H&M's approach to AI deployment is notable less for its ambition than for its discipline. Operating across 72 countries, 177,000 employees, and nearly 5,000 stores, the organization has little margin for rollout failure — and their process reflects that. Deployment follows a fixed progression: Proof of Concept, limited market piloting, and full-scale industrialization only after both preceding stages have been validated. A 2025 energy management initiative illustrates the model in practice. A six-store Madrid pilot integrated AI with existing IoT sensors and building controllers, producing a 14% cut in lighting and HVAC demand over eight weeks. Despite the strong early results, H&M didn't compress the timeline. They completed validation, ran a two-day override protocol training for local facility managers, and staged the expansion — 30 stores before the full 90-store cluster. The principle is straightforward: a promising result justifies the next phase of validation, not a skip to full deployment. There's a pattern in the evidence: the organizations that took time to prepare their people — not indefinitely, but deliberately — are the ones whose results held. The one that prioritized speed over readiness are remembered with a cautionary note. View B does not suggest stalling indefinitely but a structed path to lasting success: Validation: Have the internal experts review the AI recommendation. Build credibility. Pilot: Implement the changes to small subset if possible or a small department. Gather the feedback and analyse the outcomes Training and Communication: Use these learnings to create trainings and manuals to explain why the changes rather than what Gradual Rollout: Roll out to other teams/systems/entire process in tranches, with support and monitoring. Refine: There are always cases that would have been unexpected or outliers or first time occurrence, see how they can be managed/handled and include that in future improvements. This approach may take a couple of weeks more than immediate implementation, but rest assured the improvement will actually get realized. There's an irony embedded in the evidence — organizations that take the time to implement change properly tend to reach their target outcomes sooner than those that prioritize speed above all else. Thanks, Anitha

I strongly support View A — Roll back immediately The product we have built is a representation of what we stand for and that every customer is important to us. Below are my view points listing why rolling back immediately is the path I would choose: 1) Rolling back the fix, demonstrates to customers that we care and provides reassurance. It shows that we are ready to accept our mistakes and shall never compromise on product quality and always prioritze product reliability. Customers usually trust products that openly speak about the mistakes and also state what is being done to correct it. Covering-up or even allowing a small percentage of users to face the fallout displays a biased attitude towards the affected customers. It will definitely generate a negative word-of-mouth, media attention and viral social posts that can drive potential customers away. Rolling back the changes immediately, restores customer confidence and trust, than doing a gradual mitigation of the problem. Example: During lockdown a major food-delivery app launched a UI change that caused booking failures for a minority group of people in a large city; This caused problems for people living in certain areas whereby the app could not locate the areas and hence food could not be delivered at all. Imagine the trauma especially for those who were in quarantine already suffering from Covid! The trust was definitely eroded. The company had to eventually roll back the change to stop further reputational damage and ensure to restore reliability. 2) Issues with the product could lead to data corruption especially if in financial or legal domain. The product defects can lead to data loss, duplicate transaction and even regulatory breaches. Immediate rollback can limit such serious legal exposure. Example: This is a sample situation whereby if a financial payment gateway upgrade led to malformed transaction metadata for say ~7% of users, the impact can still be very high. Allowing such defects to fester assuming that only a small percentage of users are impacted can easily draw regulatory ire and public flak. This will easily cause the remaining 93% also to doubt the product. 3) Small defects can easily cascade into larger system failures. If the issue cannot be resolved right-away then reverting to the previous version is the best way to prevent the issue growing into a large unstable system. 4) When a faulty feature is allowed to continue then the number of customer service calls, refunds, claims will increase. Rolling back changes can stop the support surge and limit any financial exposure. 5) In highly sensitive and critical contexts, the product has to be 100% defect free every time an upgrade is rolled out. For e.g. A firmware update for Medtronic’s SynchroMed II implantable infusion pump was pulled after reports that it caused intermittent sensor misreads on a subset of units (not all units were affected), and the vendor halted the OTA update to prevent patient‑safety risk. Reported issues surfaced in 2023–2024 and the vendor halted the over‑the‑air (OTA) firmware rollout once intermittent sensor misreads were identified. Rolling back the firmware update perhaps saved many lives! My stance is therefore that when a product defect is identified then Roll back immediately, especially when the issue threatens user trust, data integrity, legal exposure, safety, or even when you cannot reliably isolate the affected group. Use the rollback instead to assure customers. This will restore confidence and also gives time to deploy a correct and well tested fix. Thanks, Anitha