An AI system handles thousands of transactions successfully. Then one unusual case requires human intervention. A specialist reviews the evidence. A decision is made. The exception is resolved. The workflow continues. What happens to what the organization just learned? This is the gap that enterprise AI architectures almost universally leave unaddressed. The system records that an exception occurred. It may record the final disposition and the timestamp. In more mature implementations it records who made the decision and what action was taken. But recording an event is not the same as creating organizational memory, and that distinction matters considerably more than most governance frameworks acknowledge. An exception is rarely just an operational interruption. It is frequently a signal. It may reveal that a business rule needs refinement because the original conditions it was designed for have shifted. It may show that two policies interact in an unexpected way when they are appli...

  A leading payment bank deployed automation bots to process hundreds of depository transactions monthly. Standard cases ran cleanly. Business logic applied correctly. The system identified incorrect entries, made routing decisions, and generated confirmation letters at volume with exactly the accuracy the bank needed. Then a transaction arrived that fell just outside the approved threshold. The customer profile was inconsistent with available history. Two policies appeared to conflict. The evidence was present but incomplete. The model was technically capable of generating a recommendation. Whether it was equipped to handle what it was seeing was a different question entirely. The system knew how to process the normal path. Nobody had designed the exception path with the same precision. This is the gap that appears repeatedly across enterprise AI programs as systems move from advisory to operational. Enterprise AI is genuinely capable of handling defined patterns at scale and spee...

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...

A global financial services organization once asked us to review an incident that had triggered far more internal discussion than the incident itself. The issue had already been resolved. The system was functioning normally again. The business impact had been contained. Yet weeks later, senior leaders were still debating what had happened. Not because nobody cared. Because everybody cared. Technology had logs. Operations had reports. Risk had assessments. Compliance had approvals. Every team could produce evidence supporting its own perspective. Every team could explain what it owned and what it had done. What nobody could produce was a single coherent explanation of the decision path that led to the outcome. The logs existed. The reports existed. The evidence existed in fragments. The decision pathway did not exist at all. The organization did not have an accountability problem. It had an evidence problem. We had seen a sharper version of this earlier in a fintech engagement running A...

A leading private bank asked us to build an AI platform that could sharpen investment decisions for its wealth management clients. We implemented a RAG architecture with vector embeddings and LLM integration, the kind of system that retrieves relevant market intelligence, reasons across portfolio context, and generates recommendations a relationship manager can act on quickly. The results during the pilot phase were strong. Recommendations were more precise. Risk flags arrived earlier. Client portfolio performance metrics moved in the right direction. Six months after deployment, a question nobody had asked at the start became unavoidable. When the model flags a risk and the portfolio manager does not act on it, who owns that outcome? The technology team built the model and maintained the architecture. The investment team received the recommendations and made the final calls. The risk function had signed off on the controls. Compliance had approved the process. A major wealth managemen...

Every Successful AI Pilot Creates a Hidden Liability A large US insurer once asked us to help modernize how claims got processed. RPA bots went in, two legacy systems got replaced with one platform, and the pilot numbers looked excellent, faster intake, fewer manual touchpoints, happier claims adjusters in the room where it was tested. Everyone in that room had reason to be pleased. The metrics were real, the adjusters were not exaggerating their relief, and on paper this looked like exactly the kind of automation story organizations like to tell about themselves. Eighteen months later, that same pilot was still running in exactly one regional office. The model had not gotten worse. Nothing about its performance had changed. What changed is that scaling it meant pulling in people who were never part of the pilot, a budget owner who had to fund the rollout, a compliance team that suddenly had to sign off on something that used to be a contained experiment, an operations lead who had to ...

Most enterprise AI governance conversations I sit in on still treat "the model" and "the system around the model" as the same thing. A risk committee asks whether the AI is safe, someone answers with a benchmark score, and the conversation moves on. It is a comfortable shortcut, and it is also the reason so many governance frameworks fail the moment an agent gets real access to a real environment. Anthropic gave the industry an unusually clean way to see why that shortcut breaks down. In late May 2026, the company published a long engineering account of how it contains Claude across its three agentic products, claude.ai, Claude Code, and Claude Cowork. It is candid in a way corporate security writing rarely is, naming specific incidents, specific failure rates, and specific architectural choices that did not work the first time. Read against the backdrop of April's decision to hold back Claude Mythos Preview after it engineered its own way out of a sandbox dur...