Consider a supplier payment flagged by an AI system as anomalous. The evidence behind the flag is solid. The transaction pattern is inconsistent with historical behavior. The risk indicators are clear. The system has access to the relevant data, the organizational context, and the analytical capability to generate a well grounded recommendation to place the payment on hold pending review. Should it actually place the payment on hold? That question sounds straightforward. In practice it opens one of the most consequential distinctions in enterprise AI governance, and one that most organizations have not yet seriously designed for. For years the primary question in enterprise AI was whether the system could identify the right action. Could it surface the anomaly? Could it generate the recommendation? Could it retrieve the relevant policy and match it to the current situation? Those are meaningful capabilities and the investment required to build them is significant and worthwhile. Th...

A leading private bank asked us to build an AI capability to help relationship managers identify emerging risks across large portfolios. The system had access to market data, client information, historical transactions, risk indicators, and relevant policies. It was technically well designed. The retrieval architecture was sound. The recommendations it generated were consistently coherent and data supported. The problem appeared several months into production when two clients received very different recommendations from the same underlying risk signal. Both recommendations were technically defensible. Both were supported by available data. Both would have passed any reasonable audit of the system's outputs. Yet when the decisions were reviewed internally, the question that surfaced was not whether the system had the right information. It was whether the system understood the context in which that information mattered. One client was approaching a major liquidity event with a sho...

A large US health insurer managing tens of thousands of workers compensation claims annually asked us to help integrate claims processing, risk controls, and care coordination into a single platform. The integration worked. Information flowed across functions that had previously operated in silos. The platform identified cases requiring intervention earlier than the previous process had allowed, and the recommendations it generated were consistently well grounded in the available evidence. Then a claimant outcome went wrong. Claims explained their role clearly. Risk pointed to the controls they had maintained throughout. Care coordination described the recommendations they had issued at the right time. Every team had done what its function required. The documentation was in order. The process had been followed. Nobody owned the outcome. This is a different problem from unclear decision rights, though the two are related. Decision rights define who has the authority to decide. Accountab...

A global organization running transformation programs across multiple geographies came to us with a pattern that appeared so consistently it had become almost expected. One business unit had solved a complex operational issue eighteen months earlier and documented the solution carefully. A second had encountered the same underlying risk under a different name and had quietly changed its process after a regulatory finding. A third had built a governance framework specifically to prevent the kind of failure that was now being discussed in a fourth part of the organization. The evidence existed across systems, documents, incident tickets, meeting records, governance archives, and the individual expertise of people who had been through it before. When the fourth team encountered the problem, they started almost from scratch. Not because nobody cared. Not because the documentation was poor. Because the organization had no reliable way to connect the previous experience to the decision be...

A regional bank in the northeastern US had done everything right on paper. New operating model approved. Technology selected and deployed. Teams trained. Workflows redesigned. The transformation program had hit every milestone on the project plan. Leadership had been visibly committed throughout. External partners had delivered what they promised. The steering committee had received green status reports for eighteen consecutive months. Eighteen months later, the bank was still operating largely the way it always had. Not because the technology had failed. The tools were working as designed. Not because people had refused to engage. Participation rates in training and workshops had been consistently high. The gap was somewhere else entirely, somewhere the project plan had never measured and the steering committee had never discussed. Decision rights had not changed. Incentives had not changed. The reward framework still measured what it had always measured. The escalation paths that ...

A global professional services firm asked us to help deliver a digital transformation program that had already accumulated an impressive portfolio of technology investments. RPA bots were running. A compliance automation platform had been deployed. A document processing system was live. A workflow management tool was in place. Each had been evaluated carefully, piloted successfully, and approved by the right stakeholders. The program was struggling anyway. Not because any individual tool was failing. Each was doing what it had been designed to do. The problem was that the tools had been selected, deployed, and governed independently of each other. Each had its own support team, its own escalation path, its own success metric, and its own vendor relationship. The organization had built a portfolio of capabilities. It had not built the organizational capability to connect them. This pattern appears consistently across enterprises that have been investing seriously in AI and automation...

  A leading private bank and a major wealth management firm asked us to build AI systems that could improve investment decision making and surface portfolio risk earlier than existing processes allowed. The solution we designed was a RAG architecture, retrieval augmented generation, that pulled dynamically from multiple enterprise data sources, applied business rules and policy parameters, and generated recommendations a relationship manager could act on in near real time. The system was validated carefully. The data sources were approved. The model was tested against historical portfolios. The workflow was documented end to end. The systems performed well in production. Recommendations were sharper. Risk flags arrived earlier. Portfolio teams reported the tools were genuinely useful. Several months into production, a specific recommendation came under internal review. The outcome itself was not the issue. The recommendation was reasonable. The process had followed policy. What nob...