A regional insurance carrier we spoke with last quarter had already picked their model. GPT-4-class, solid benchmarks, cheap enough per call. The demo took two weeks and worked beautifully: feed it a submission, get a quote back.
Then they tried to ship it. The quote had to route through carrier-specific underwriting rules that varied by state. It had to check against ACA guidelines depending on the plan type. It had to write into a CRM that three different sales teams used with three different conventions. And compliance wanted to know who approved every quote the AI touched, because insurance regulators do not accept “the model decided” as an answer.
Eight months later, they had shipped none of it. Not because the model was wrong. Because nobody had budgeted for everything around the model.
This is the pattern we see in almost every enterprise AI discovery call now, and it’s the same pattern showing up across insurance, healthcare, and general enterprise deployments: the model is the easy 10%. The other 90% is where the money, time, and risk actually live.
The Misconception: Model Selection Is the Easy Part
Most public AI discourse is about models. Which one benchmarks higher, which one hallucinates less, which one is cheaper per million tokens. This is useful information - and almost irrelevant to whether an enterprise AI project succeeds.
Model selection takes a team a week, maybe two. You run evals against your use case, pick the best cost/performance tradeoff, done. It is a solved problem with a shrinking cost curve - models get cheaper and better every quarter regardless of what you do.
What doesn’t get cheaper every quarter: your data quality. Your business rules. Your approval chains. Your security posture. Those are specific to your company, your industry, your regulatory environment - and no model release fixes them. Our research on why AI agent deployments fail found that 84% of failures trace back to problem misalignment and organizational issues, not model quality. The model was rarely the reason projects died.
Where Enterprise AI Projects Actually Spend Their Time
Break down a real deployment timeline and the split is stark. Here’s what consumes the months between “the demo worked” and “it’s in production”:
Data quality. Models are only as good as what they read. Enterprise data lives in silos - claims systems, EHRs, CRMs, spreadsheets someone’s been maintaining since 2019 - with inconsistent formats, duplicate records, and missing fields. Cleaning and structuring this is unglamorous, and it’s usually the single largest line item nobody scoped for.
Business rules. Every industry, and often every client within an industry, has rules that don’t live in any dataset the model can read. Underwriting thresholds. Discount eligibility. Regional compliance variants. These have to be extracted from policy documents, subject matter experts, and legacy code, then encoded somewhere the AI-driven workflow can enforce consistently.
Workflow orchestration. Deciding when the AI runs, what triggers it, where its output goes, and what happens on failure is an entire engineering discipline on its own - separate from the model call itself.
Human approvals. Anything with legal, financial, or clinical consequence needs a human in the loop, which means building review queues, escalation paths, and audit trails - UI and backend work that has nothing to do with prompting.
Security, observability, governance. Access control on what the AI can touch. Logging so you can reconstruct any decision it made. A monitoring layer that catches drift and anomalies before customers do. And a governance structure so unmanaged AI use doesn’t creep in through side doors.
Integration. The AI has to read from and write to systems that already exist - CRM, ERP, EHR, claims platforms - each with its own API quirks, auth model, and data schema.
Figures reflect our internal project observations across insurance and healthcare engagements - directional, not a formal industry survey.
Real Examples: Where This Actually Bites
Insurance. Every carrier has its own underwriting appetite, commission structure, and state-specific compliance rules. An AI quoting engine that works for one carrier’s ACA plans breaks the moment it hits another carrier’s rules, because the differences live in PDFs and underwriter heads, not in a database. Add CRM integration - Salesforce for one team, HubSpot for another, a homegrown tool for a third - and the “AI quoting” project becomes mostly a rules-and-integration project with a model attached at the end.
Healthcare. Clinical workflows are exception-based by nature: most cases are routine, a minority need physician judgment. AI that tries to fully automate a clinical workflow either over-escalates (killing the efficiency gain) or under-escalates (creating patient safety risk). And every hospital’s EHR speaks HL7 or FHIR slightly differently, so integration work dominates the timeline before the model does anything useful. Our healthcare legacy modernization case study is mostly this: exception routing and system integration, not model tuning.
Enterprise AI governance. Shadow AI - employees pasting customer data into unauthorized tools - isn’t a model problem either. It’s a governance gap: no approved path exists that’s as fast as the unauthorized one. Fixing it means building sanctioned tooling, logging, and policy enforcement, none of which touches which model you picked.
The Architecture Shift: AI as a Component, Not the Workflow
The failure pattern across all three examples is the same: treating AI as the workflow instead of a component inside it. When AI is “the workflow,” every business rule, approval, and edge case has to somehow be crammed into the model’s context or prompt - which is fragile, unauditable, and breaks the first time reality doesn’t match the demo.
The fix is architectural: AI becomes one step in an existing business process, not a replacement for the process. It reads validated data, applies rules encoded outside the model, writes to systems of record, and stops for a human wherever the business already requires judgment. This is the same principle we’ve written about in why agentic AI matters - the value isn’t the model acting alone, it’s the model acting correctly inside guardrails that already reflect how the business actually runs. Our agentic AI engagements spend more time on this surrounding architecture than on the agent’s reasoning loop itself.
Companies That Redesign Workflows Build Businesses
The distinction we keep coming back to with clients: companies that treat AI as a feature bolted onto an existing product build demos. Companies that redesign the workflow itself - where data flows, where rules live, where humans check in, what gets logged - build something that survives contact with production.
The model choice will keep getting easier and cheaper every quarter, for free, regardless of what you do. The workflow around it won’t fix itself. That’s where the actual project is, and where the budget, timeline, and risk should be planned from day one - not discovered eight months in, the way that insurance carrier discovered it.
Where to Start
If you’re scoping enterprise AI and the plan has a model, a prompt, and a launch date but no line items for data quality, business rule mapping, approval workflows, and governance - that plan is missing 90% of the actual project. We help enterprises in insurance, healthcare, and other regulated industries build the workflow architecture around AI, not just the AI itself. If you want a second opinion on where your project’s real cost is hiding, let’s talk.