A build decision most companies are not actually ready to make
Travelers, the roughly 49 billion dollar property and casualty insurer, has spent 2026 promoting TravelersLLM, a proprietary large language model trained on millions of internal documents and tested against tens of thousands of insurance-specific questions drawn from underwriting, claims, and service operations. The model recently picked up recognition through the CIO 100 Awards, and Travelers has been vocal about the cost savings of running a domain-specific model instead of routing every query through a general-purpose frontier model. On the surface, this reads as a straightforward build-versus-buy win for the build side.
Underneath that headline is a harder truth for any enterprise leader eyeing the same move. Mojgan Lefebvre, Travelers' executive vice president and chief technology and operations officer, was explicit about the precondition: "There's no way on Earth that we could be doing what we're doing with AI today if we hadn't been making investments in modernization." TravelersLLM is not the achievement. It is the payoff of infrastructure and data work that started well before anyone at the company was talking about large language models.
Hybrid by design, not by compromise
Travelers did not build TravelersLLM to replace frontier models across the board, and that distinction matters. The company runs a hybrid architecture in which applications route insurance-specific queries to TravelersLLM and send broad reasoning, research, and coding tasks to commercial frontier models. Lefebvre summarized the design principle as using "the right model for the right problem," with the underlying model choice largely invisible to the end user, who should simply experience the best available intelligence for the task at hand.
That architecture is deliberately defensive as well as efficient. By keeping frontier models in the loop for general-purpose work, Travelers avoids the trap of over-investing in a proprietary model that would need constant retraining to keep pace with rapidly improving commercial alternatives. It also reduces vendor dependence: no single AI provider sits in the critical path for every workload. For a company with 30,000 employees and workloads spanning underwriting, claims, and customer service, that flexibility is close to as valuable as the cost savings themselves.
The scale that makes proprietary models economically rational
A proprietary large language model is expensive to build and maintain, and it only pays for itself at sufficient query volume and data scale. Travelers runs 70 percent of its compute in the cloud and generates nearly 49 billion dollars in annual revenue, which gives it both the transaction volume to justify a domain-specific model and the balance sheet to absorb the upfront training and evaluation cost. The model was trained on millions of company documents and validated against tens of thousands of domain questions, a scale of curated data that took years of governance and cleanup work to assemble.
This is the part of the story that gets lost when TravelersLLM is presented simply as an AI cost-cutting win. Most enterprises evaluating whether to build a proprietary model do not have millions of clean, well-labeled internal documents ready to train on, nor the compute scale to make the ongoing maintenance cost worthwhile. Without that foundation, a build decision modeled on Travelers is likely to produce a smaller, weaker model at a higher relative cost than simply routing more traffic through a well-chosen commercial provider.
What modernization actually bought Travelers
Lefebvre's framing puts the causality in the right order: modernization investment came first, and it made the AI project possible, not the other way around. That sequence is easy to state and hard to execute, because modernization spending rarely produces a headline the way a new AI model does. Data cleanup, system consolidation, and cloud migration are the multi-year, low-glamour projects that get deprioritized when budgets tighten, precisely because their payoff shows up years later in a project like TravelersLLM rather than in the quarter they were funded.
Enterprise leaders should take this as a warning against sequencing their AI strategy backward. Announcing an AI build initiative before the underlying data and infrastructure work is done is a common pattern, and it is the pattern most likely to produce an expensive, underperforming model. Travelers' experience argues for the opposite order: fund the unglamorous modernization work on its own merits first, and treat any resulting AI capability as an option to exercise later, not a deliverable to promise up front.
The decision every CTO actually has to make
The build-versus-buy question in enterprise AI is usually framed as a single choice, but Travelers' hybrid model shows it is better understood as a routing decision made continuously, workload by workload. The company did not choose to build instead of buy. It chose to build a narrow, high-value layer on top of a foundation that still relies heavily on commercial frontier models for everything outside that narrow layer. That is a materially different decision than a full proprietary build, and it carries a materially different risk profile.
For most CTOs, the immediate question is not whether to build a TravelersLLM equivalent. It is whether their data and infrastructure maturity would support one if they tried, and if the honest answer is no, whether that gap is worth closing before the next AI initiative gets greenlit. Travelers spent years closing that gap quietly. The companies that skip that step and go straight to the model are the ones most likely to be writing a very different kind of AI story a year from now.
