Title: How to Add AI to the Enterprise Applications You Already Own: CRM, ERP, HRIS, and Project Management Author: Entexis Team Category: Artificial Intelligence Read time: 14 min URL: https://entexis.in/how-to-add-ai-to-the-enterprise-applications-you-already-own-crm-erp-hris-and-project-management Published: 2026-10-20 --- Every enterprise buyer sitting down with AI right now hits the same practical question their vendor pitch skips. "We already have Salesforce. We already have SAP. We already have Workday. We already have a project management platform half the company lives in." The vendors selling standalone AI products avoid the question because their pricing depends on you not answering it. The enterprise-app vendors selling their own AI add-ons answer it in a way that maximises their subscription. The honest answer sits between the two pitches, and it depends on which of 4 retrofit paths fits your specific application and your specific need. So how do you actually add AI to the enterprise applications you already own? That is the point of this piece. You will see what "retrofit AI" really means, without the vendor framing. You will see the 4 paths every enterprise buyer picks between (vendor-native AI add-on, chat-to-app connectors, custom AI wrapper on the vendor API, or data replication with external AI). You will see the 3 decisions that pick the right path for your specific application and your specific need. You will see the 4 places retrofit AI quietly fails in production and how to avoid each. You will see a simple wrapper pattern that lets your enterprise use multiple paths across multiple applications without a per-app rebuild. And you will see the 3 signs the AI feature your app vendor just announced is not ready for the work you would want it to do. Why does this matter more this year than a few years back? Because your enterprise app vendors have all launched their own AI SKUs. Salesforce, Microsoft, Google Workspace, Workday, SAP, Oracle, and every project-management platform now has an AI add-on with premium pricing. The pitch is unified and compelling; the delivery varies wildly. Some of these add-ons are real, mature capabilities. Others are chatbots dressed up as enterprise features. Buying without a serious evaluation of which path actually fits produces committed multi-year subscriptions to AI that does not do the work your team wanted. The retrofit conversation is the one that saves you from that outcome. The rest of this piece walks the answer in the order the questions come up during a real enterprise buying conversation. What is a retrofit? Which path fits your application? What decides the pick? What quietly fails? How do you build so the path can change? And how do you spot vendor AI features that will not deliver? Boring on purpose, because retrofit decisions are boring until they compound into multi-year subscriptions you cannot walk away from. Enterprises expected to use GenAI APIs or deploy GenAI-enabled applications in production by 2026 (Gartner, 2023) $30Per-user monthly price for Copilot for Microsoft 365 (enterprise add-on), illustrating premium AI SKU pricing (Microsoft, 2024) 23.8%Salesforce share of the global CRM software market, underscoring the scale of AI retrofits in existing CRM estates (Statista, 2023) ## Adding AI to What You Already Own, Explained What is retrofit AI, in practical terms? Retrofit AI is any approach that adds AI capability to an application your business already runs, without replacing that application. Your enterprise still uses Salesforce for the sales process, Workday for the people processes, your project-management tool for delivery. AI shows up as new features, new interfaces, or new workflows on top of what is already there. The application keeps its role as the operational system; AI extends what the application can do. Why is this a distinct category from buying standalone AI? Because the alternative (replacing your existing applications with AI-native alternatives) is almost never viable for a mature enterprise. Your business processes are wired into your CRM, ERP, HRIS, and project-management tools deeply enough that replacement is a multi-year rebuild, not an upgrade. Retrofit lets you get AI's leverage without touching the systems your business runs on. It is the only realistic path for most enterprise buyers today, and the vendor market has responded by offering multiple ways to do it. So what actually varies across the 4 paths you can pick? The path decides who owns the AI (the vendor, a third party, or your team), how the AI accesses your data (through the vendor's internal pipes, through a connector, through the vendor's API, or through a replica of the data outside the vendor), how it is priced (per seat, per query, flat, or your own infrastructure), and how much control you have over the AI's behaviour. Each path suits different situations, and picking without the sort produces retrofit AI that either does not fit the work or costs more than the value it delivers. > **The Retrofit Question:** If your enterprise app vendor's AI SKU is being pitched at you and you cannot describe in one sentence which of the 4 paths it represents, the pitch is doing marketing work rather than telling you what the product actually is. Every honest retrofit approach fits one of the 4 paths cleanly; every vague one hides which path it is on. ## The 4 Retrofit Paths to Adding AI to an Existing Enterprise Application Which of the 4 paths does your enterprise actually need for a specific application? Almost every retrofit conversation resolves into one of them once you push on the specific use case. Knowing which one you are on changes the pricing model, the control you have, the data-boundary story, and how much your team owns versus rents from the vendor. The 4 Retrofit Paths + 1 Reality Which Path Adds AI to Your Enterprise Application 1Vendor-Native AI Add-OnBuy the vendor's own AI SKU for deepest integration 2Chat-to-App ConnectorExternal AI reaches the app via connectors or MCP 3Custom AI Wrapper on the Vendor APIYour own AI layer reads and writes through the public API 4Data Replication with External AIPull data into your store, run AI on the replica, write back 5Mix Paths Per ApplicationMost enterprises end up combining paths across their portfolio Which Retrofit Path FitsPath 1 fits when the vendor's AI covers your use case and the pricing works. Path 2 fits when you want an external AI to reach the app for lighter-weight interactions. Path 3 fits when your workflow is specific enough that the vendor's AI cannot deliver. Path 4 fits when the AI needs data across multiple applications the vendor does not connect natively. Most enterprises end up mixing paths across their app portfolio. Why does the path matter so much before you commit? Because each path locks in a different set of dependencies. Path 1 ties you to the vendor's AI roadmap and pricing model. Path 2 ties you to the connector ecosystem. Path 3 ties you to the vendor's API contract. Path 4 ties you to your own data pipeline and replica infrastructure. Picking the wrong path for a specific application means fighting the wrong dependency, which usually looks like "we cannot get the AI to do X because the path we picked does not let us". ## 3 Decisions That Pick the Right Retrofit Path Once you know the 4 paths exist, which questions actually separate the right path from the vendor's preferred one? The 3 decisions below are the ones that keep showing up. Every other input (the vendor's roadmap deck, an analyst report you were sent, what a peer at another company is doing) is downstream of these 3. 02 How Much Do You Need to Control the AI's Behaviour and Data Flow? Vendor-native AI runs on the vendor's terms: their model, their infrastructure, their data-handling policies, their update schedule. That works when your governance is comfortable with the vendor's story. For regulated industries, or products with specific compliance obligations, or teams that need the AI to behave in ways the vendor did not build in, the path narrows toward custom wrappers or external AI on your own infrastructure. Answer this per use case against your specific compliance and control needs, not against a general "we trust the vendor" heuristic. 03 Does the Vendor's Pricing Model Actually Fit Your Usage? Vendor-native AI usually prices per seat, with the AI features gated behind a premium seat tier. If a small number of high-value users need the AI, that pricing works. If the AI would benefit a much larger user population, the per-seat premium scales badly and the total cost outruns the value. Custom wrappers and external AI let you pay for actual usage rather than every seat that could use the feature. Run the maths honestly before committing to path 1 at scale; the vendor's per-seat AI tier can double or triple the per-user cost of the application, and that math changes the answer. > **The Order That Matters:** Answer the context question first, the control question second, the pricing question third. Teams that answer the pricing question first often pick the cheapest path and discover it does not fit their context; teams that answer context first pick the path that actually delivers the value, and then reason about pricing on top of that. Order matters more than most enterprise buyers realise. ## 4 Places Retrofit AI Fails Quietly in Enterprise Applications What actually goes wrong with retrofit AI once it is running in production? The 4 below show up in almost every retrofit that felt clean at rollout and started causing arguments a few months in. All of them are survivable if the retrofit was picked with them in mind. Skipping them at rollout is why so many enterprise AI programmes end up with subscriptions nobody defends and results nobody celebrates. 02 The Vendor's AI Cannot Reach Data Across Its Own Platform Boundaries You expected the Salesforce AI to be able to reference your ERP data, or the Workday AI to be able to reference your CRM data. It does not. The vendor's AI sees the vendor's data cleanly and everything outside the vendor's product is out of reach. Cross-application questions your users would naturally ask (what is this customer's health score across all systems, what is this employee's project load across all planning tools) produce partial answers or the AI refusing to answer. This is a structural limit of path 1; getting past it means combining paths, usually adding path 4 for cross-application intelligence. 03 API Rate Limits That Were Fine for Regular Use But Crushing Under AI-Driven Load Paths 3 and 4 depend on the vendor's API. Regular application use produces a certain traffic pattern; AI-driven use produces a much higher one, especially if the AI is doing multi-step research across many records. Vendor API rate limits that never mattered before start throttling your AI's work. Some vendors offer higher-tier API access for AI use; others do not, or price it steeply. Model the AI's expected API traffic against the vendor's limits before you commit, and factor the additional API costs into the total-cost comparison against path 1. 04 Stale-Data Lag That Makes the AI Sound Confidently Wrong Path 4 (data replication) is the most flexible but adds a real gap: the data the AI sees is a snapshot, not the live application state. If the replication runs every 15 minutes, the AI's answers are up to 15 minutes stale. For read-heavy use that is fine; for decisions that depend on the very latest record state, it is a source of confidently wrong answers. Users lose trust in the AI's outputs quickly once they realise this. Design the replication frequency around the freshness the specific use case actually needs, and be honest with users about when the AI is looking at stale data. > **Why Retrofits Fail Silently:** All 4 of these failure modes look normal at pilot scale. Vendor pricing looks affordable; the vendor's AI answers questions that stay inside the platform; API traffic sits under the limits; replication freshness matches the pilot's pace. All 4 emerge only at deployment scale, which is exactly when reversing the path is expensive. Model the deployment scenario honestly at the sort stage; do not let the pilot's easy numbers pick the path. Retrofit Surfaces by Application Where AI Actually Lands Inside the Systems You Already Own CRM Sales & Customer - Lead scoring on real signals - Call and email drafts - Meeting notes extraction - Deal risk summaries ERP- Operations & Finance Invoice extraction and coding - PO to receipt matching - Anomaly flagging on transactions - Forecast narrative from data HRISPeople & Employee Data - Resume-to-role matching - Policy Q&A over your handbook - Performance-cycle drafts - Skill-gap analysis Project ManagementDelivery & Coordination - Status updates from activity feeds - Ticket triage and summarisation - Risk detection from tone shift - Cross-project dependency mapping Pick 1 or 2 Surfaces FirstProducts that adopted AI across all 4 applications at once produced dashboard AI. Pick 1 or 2 surfaces where the value target is clear, adopt them well, then expand. ## A Pattern That Adds AI Without Locking Yourself Into the Vendor's Roadmap So what does an enterprise look like when it retrofits AI across multiple applications on multiple paths without locking every application into a single vendor's AI roadmap? Not fancy. The shape below is the arrangement that lets your enterprise pick a different retrofit path per application, mix them cleanly, and change any application's path later without touching the user-facing interface. Every layer has one job. When the path underneath a specific application changes (and it will), the change stays contained. Architecture A Pattern That Adds AI Across Applications Without Vendor-Roadmap Lock-In User InterfaceThe place your team already works: inside Salesforce, Workday, your project tool. Users see AI features embedded in the interface they know.Layer 1 Enterprise AI InterfaceOne clean interface your applications call for any AI intent (summarise this, extract from that, recommend the next action). Vendor names live below this layer.Layer 2 Path RouterDecides per intent whether to route the call through the vendor's native AI, a chat connector, a custom API wrapper, or the data-replicated external AI backend.Layer 3 Path AdaptersOne adapter per path: vendor-native calls, connector calls, API-wrapper calls, replicated-data calls. Each speaks the enterprise AI interface into the specific path.Layer 4 Path FreedomSalesforce on vendor-native, SAP on custom wrapper, project tool on data replication. Switch any application's path later without touching the user-facing interface.The Payoff Why the Wrapper Keeps You FreeThe vendor AI landscape will keep shifting: new SKUs, new pricing, new capability, occasional deprecation. Your enterprise should not have to shift with each vendor's roadmap. The wrapper is what lets you take each vendor's best features without committing your entire AI programme to their long-term direction. Why build this pattern even if you only use path 1 today? Because the vendor's AI capability today is not what it will be in a couple of years, and the vendor's pricing today is not what it will be either. A retrofit committed to path 1 without a wrapper becomes a rewrite when the pricing shifts unfavourably or the vendor's AI fails to keep up with what your users have come to expect. The wrapper takes minimal effort upfront and buys you the option to change paths per application without touching what your team sees. ## 3 Signs the AI Feature Your Enterprise App Vendor Just Announced Is Not Ready How do you tell whether the AI feature your enterprise app vendor just launched is production-ready for your use case, or whether it is still catching up to its own marketing? The 3 signs below are the ones that keep separating real capability from announcement theatre. If you spot more than one, the feature is probably not ready for the work you would want it to do. 02 The Feature Works Only Inside the Vendor's Preferred Data Model Your enterprise has customised the vendor's application, extended the data model, added custom fields, and integrated with other systems the vendor does not manage. The vendor's AI works on the standard data model in a clean demo tenancy; on your actual customised setup, the AI performance drops sharply because it was trained on the standard shape. Ask to run the AI feature against a copy of your actual data before you commit. If the vendor either cannot or will not run that test, the feature is not ready for your specific configuration, no matter how well it works in demos. 03 The Pricing Was Announced Without Committed Volume Discounts Mature vendor AI SKUs come with clear tiered pricing at real enterprise volume. Recently-announced AI features often launch at premium per-seat pricing with no committed enterprise-tier pricing yet. This is a signal that the vendor does not have enterprise deployment data yet and is pricing to capture early demand rather than sustain long-term adoption. Buying at launch pricing usually means you paid more than the eventual enterprise tier will cost, sometimes materially. Wait for the enterprise-tier pricing to land, or negotiate hard against a proof-of-value pilot before the retail price becomes your baseline. > **The Vendor-Feature Filter:** Ask the vendor 3 things in the same meeting: introduce me to 3 production customers using this feature for my specific use case; run the feature against a copy of my actual customised data in the same session; and show me the committed enterprise-volume pricing. Vendors whose AI features are ready answer all 3 confidently. Vendors whose features are still catching up to their own announcement answer with adjectives, deferrals, or roadmap dates. ## Frequently Asked Questions Should you always start with the vendor's own AI SKU because the integration is deepest?Not automatically. The vendor's AI has the deepest integration with the platform, which matters for use cases that stay inside the platform. It also has the most vendor lock-in, the most premium pricing, and the least fit for cross-application intelligence. Start with the vendor's AI when the use case stays inside the platform, the pricing works at your deployment scale, and the vendor's AI actually solves the specific problem you have. Start with a different path when any of those does not hold. Deep integration is a real feature; it is not automatically worth the price the vendor charges for it. Can you use a chat-to-app connector for regulated data?Depends on which chat product and what the connector actually does with the data. Some connector setups keep the regulated data inside your infrastructure and only send inference-time context to the AI; others route data through the AI vendor's infrastructure. Regulated use cases require specifically verifying that the data-handling meets your regulator's requirements, not accepting general vendor claims. In many regulated cases, the chat-to-app connector path is workable if configured tightly; in some cases, only a custom wrapper or replicated-data path with your own AI backend meets the compliance bar. Verify per use case against your specific compliance obligations. How do you handle the internal politics when the enterprise app team wants path 1 and the AI team wants path 3?By anchoring the decision to the 3 questions above (context, control, pricing) rather than to which team's preference wins. When both teams answer the questions honestly against a specific use case, the right path usually becomes obvious, and the internal politics resolves around the answer rather than the preference. When the questions produce genuinely mixed signals, the wrapper pattern above lets you run the use case on both paths in parallel and let the evidence decide, which usually cools the political heat because neither team is being told they were wrong upfront. Does path 4 (data replication) work with regulated data leaving the source application?Depends on where the replica lives and how it is governed. Replicas kept inside your own controlled environment (on your infrastructure or in a cloud region and account you own) usually meet regulatory requirements because the data has not left your control zone. Replicas hosted in a third-party AI vendor's environment are a different matter and often do not meet regulatory bars. For regulated use cases, path 4 works when the replica infrastructure is owned by you and the AI runs on that same infrastructure; it does not work when the replica is owned by a third party you would not have trusted the source application to. Design the replica location against your specific compliance requirements before you commit. What if your enterprise app vendor's AI SKU is technically included in your existing licence?Then evaluate it seriously, because free capability is worth trying. The catch is that included AI features are usually the entry-level tier of the vendor's AI SKU, with feature limitations and usage caps that are fine for pilot but constraining at scale. Test what is actually included against your real use case, measure the value delivered, and use that measurement to compare against the paid AI SKU or another path. Vendor-included AI is a good starting point for the sort; it is not usually the answer for the full deployment. Should the wrapper pattern be built by IT, by a dedicated AI team, or by a partner?Depends on your enterprise's engineering capacity and how central AI is going to be to your operating model. If AI is going to be embedded in many applications, the wrapper is durable infrastructure worth building with people who will own it for the long term (whether that is IT, a dedicated AI team, or both). If AI adoption is exploratory and you want a working pattern quickly, a partner who has built the wrapper before can stand it up faster and hand it over cleanly to your team. The wrong choice is to treat the wrapper as a project rather than durable infrastructure; whoever builds it should be prepared to own its evolution as the retrofit portfolio grows. Can Entexis help you pick the right retrofit path and build the wrapper across your enterprise apps?Yes. Entexis designs and builds AI retrofits across enterprise applications (CRM, ERP, HRIS, project management, custom platforms) using all 4 paths where each one fits, and the wrapper pattern that keeps your enterprise free to change paths per application over time. That work starts with the honest conversation about the specific use cases each application should serve, the context, control, and pricing profile each one has, and where vendor-native AI genuinely earns its price versus where a different path fits better. We then design the wrapper layer, wire the adapters for each path, and hand you a retrofit foundation that can absorb the vendor-AI landscape as it keeps shifting. Reach out with which enterprise applications you already own, which use cases are the priority, and where you are being pitched vendor AI SKUs that do not quite match, and we can walk through the right retrofit approach for your specific application portfolio. For the anchor of this cluster (agent vs virtual worker vs copilot vs assistant flavour picker) that shapes what each retrofit is actually building, see: [Autonomous Agents vs Virtual Workers vs AI Copilots vs AI Assistants](/autonomous-agents-vs-virtual-workers-vs-ai-copilots-vs-ai-assistants-how-to-pick-what-actually-fits-your-business-process). For a worked example of the chat-to-app path (connecting an external AI to your existing CRM), see: [How to Connect ChatGPT or Claude to Your Existing CRM](/how-to-connect-chatgpt-or-claude-to-your-existing-crm). For the AI orchestration framework decision that shapes the custom-wrapper and data-replication paths underneath, see: [LangChain vs LlamaIndex vs DSPy vs Custom](/langchain-vs-llamaindex-vs-dspy-vs-custom-how-to-pick-the-right-ai-orchestration-framework-for-your-product). So where does that leave your enterprise retrofit strategy? Every enterprise buyer looking at AI is really choosing between 4 paths, and picking well per application decides whether the retrofit programme delivers or produces a portfolio of expensive AI SKUs nobody uses. Path 1 (vendor-native) fits deep-in-platform use cases when the pricing works at scale. Path 2 (chat-to-app) fits lightweight cross-application interactions. Path 3 (custom wrapper) fits specific workflows where the vendor's AI is generic. Path 4 (data replication) fits cross-application intelligence and use cases the vendor cannot reach. The 3 decisions above pick between them per application; the 4 silent-failure modes are what happens when the path was picked at pilot scale rather than deployment scale; the wrapper pattern lets your enterprise mix paths cleanly and change them as the vendor landscape moves. Get the paths right per application, put the wrapper in place from day one, and your AI retrofit programme evolves without being chained to any single vendor's roadmap. > **Want AI in Your Existing Enterprise Apps Without a Rewrite?:** At Entexis, we design and build AI retrofits across enterprise applications using all 4 paths (vendor-native, chat-to-app, custom wrapper, data replication) and the wrapper pattern that keeps your enterprise free to change paths per application. We start with the sorting conversation to identify which paths fit which applications and use cases, wire the adapters for each path, build the wrapper layer that isolates your team from vendor-roadmap churn, and stand up the measurement that shows when a specific application's path should change. Your team gets AI in the tools they already use, your budget matches the value each retrofit actually earns, and your programme evolves as the vendor AI landscape keeps shifting. Start the conversation with Entexis.