AI tools that help people create documents and move knowledge work forward faster are becoming everyday business tools, much like Excel and Word in the mid-1990s. A successful pilot can show that employees save time. Connecting AI to the processes the business depends on creates a deeper commitment.
Once a workflow relies on a provider’s models, integrations, and commercial terms, changing direction can involve more than choosing a different tool. It may require rebuilding connections, retraining employees, and reassessing how sensitive data is handled.
The decisions made while scaling AI will shape the organization’s options later. Leaders need to understand what those commitments will cost, where their data will go, and how the architecture will accommodate change.
AI Token Pricing: What Happens When Usage Scales?
Included usage allowances and discounted pricing can make early adoption relatively inexpensive. As organizations move into production workflows and enterprise agreements, they need to understand which usage is included, which is metered, and how costs change when allowances or discounts expire.
The distinction between general productivity tools and differentiated business workflows matters. Switching a productivity tool can be relatively straightforward, much like moving from Google Sheets to Excel, although integrations and established working practices can complicate the move. A workflow built around one vendor’s models and proprietary features is harder to relocate.
Consider an agent that searches for prospects in global markets around the clock. It may make repeated model calls, process large amounts of context, and retry tasks. That activity can generate token costs a small pilot never exposed. Once the workflow becomes integral to sales operations, the organization may have less negotiating flexibility when pricing changes.
Identify token-heavy workflows before scaling them. Match each use case to an appropriate model and estimate costs at expected production volumes, including repeated calls, retries, and the amount of context processed. A more expensive model may be justified for a complex task, while a simpler one may meet a contained requirement.
Those same workflows also determine what business data AI can reach. Cost and data sovereignty need to be evaluated together.
Data sovereignty follows the workflow
As AI reaches deeper into business systems, data sovereignty becomes a central decision: where data is stored and processed, which jurisdictions apply, and who retains control over access and use.
Keeping an ERP system on-premises does not, by itself, mean a connected AI workflow keeps its data within the same boundary. Prompts, retrieved business data, outputs, and logs may pass through services operated by different providers. Organizations need to understand those paths before connecting sensitive enterprise information.
Regulatory requirements also differ by jurisdiction. The European Union has established a comprehensive, risk-based AI framework, alongside existing data protection requirements. In the United States, companies must navigate applicable federal requirements and a developing patchwork of state and local rules. Competition among frontier model providers adds pressure to release new capabilities quickly, making it important for enterprise buyers to establish their own governance.
Confirm the contractual controls governing retention, third-party access, and model training. Use those answers to choose platforms and integration methods that can accommodate changing business needs and regulatory requirements.
Vendor ecosystems that box companies in
Oracle, SAP, and other large software vendors are adding AI models from outside partners to their platforms. Embedded capabilities can simplify adoption, but the available models and customers’ ability to choose or substitute them vary by offering.
Before building around those capabilities, understand what belongs to the application, what depends on an external model provider, and what would need to change if either relationship ended. Review the specific service’s data-handling terms rather than assuming that every AI capability within a vendor’s portfolio operates the same way.
The scope of the workflow matters too. Agentic AI may need to work across ERP systems, customer portals, and sales outreach. One vendor’s platform may not cover everything the enterprise needs, so companies can end up stitching together multiple tools.
When a process spans several applications, the question becomes how to connect their capabilities without inheriting a separate set of dependencies from each one. Ask whether changing the model provider would require rewriting the workflow, replacing integrations, or moving data. Model choice at purchase should translate into flexibility after deployment.
Turn AI sprawl into coordinated action
Applications increasingly come with their own AI capabilities, creating overlapping tools and interfaces. Few companies need a separate chat interface in every application. For workflows that span systems, the value comes from coordinating those capabilities into a system of action.
Model Context Protocol (MCP) connections or other integration methods can provide access to tools and data. Orchestration, permissions, and monitoring determine how the workflow operates. People oversee agents that perform defined tasks, with approval points, exception handling, and clear accountability.
Cross-system workflows deserve close attention because they can become strategic to the business and generate substantial token usage. Some may need to remain intentionally separate from any single vendor’s roadmap. Contained tasks, such as checking an order status or answering a customer portal question, may be well served by the AI built into that application, provided its access controls, accuracy, and costs meet the business’s requirements.
Start with the process the business needs to improve, then decide which capabilities should remain inside an application and which should operate across systems. That architectural choice also affects how much new functionality becomes embedded in the existing software estate.
Improve the process without deepening the dependency
Order validation at a manufacturing company illustrates the decision. If gaps in a legacy ERP system have kept the process highly manual, the company could build the missing capability inside the ERP or place it outside the system through an interoperability layer.
Building new code deep inside a legacy ecosystem can increase the amount of functionality that needs to be transitioned during a future modernization. An interoperability layer can use established native integration methods to connect with the ERP, while agentic workflows operate outside it. That separation can make the new capability easier to retain when the underlying platform changes, although integrations and data mappings may still need adjustment.
This approach gives organizations that have intentionally preserved stable systems a way to improve business processes while keeping the core environment in place.
It can also change the business case for a larger migration. Once long-standing pain points are resolved, CIOs should reassess whether the remaining benefits justify the investment, whether its scope should change, or whether the improvements create room to defer it. Each step should deliver value on its own and inform what comes next.
Start with friction the business can measure
Moving from a legacy ERP version to the latest release or the cloud can cost millions of dollars. Organizations need a sequence of improvements that fits their resources and priorities.
Begin with a high-friction use case that has created sustained strain on the business. Establish what the process costs today, where delays occur, and which errors matter. Then determine whether AI, conventional automation, or a combination offers the best improvement. Repetitive, rules-based work may be better handled by conventional automation. AI is most useful where interpreting information or adapting to context adds value.
The right path will differ by organization. Some want to sustain their current systems for as long as possible. Others are modernizing applications and leveraging PostgreSQL, where extensions such as pgvector can support vector similarity search for AI applications.
The operating model belongs in that decision. Internal teams may have the expertise to support PostgreSQL, but ongoing operations can compete for the resources needed to complete a modernization project. Enterprise support can help address that capacity gap. Staffing plans should also account for experienced support professionals who may retire over the next five to 10 years.
A successful implementation needs people who can maintain the integrations, oversee agent behavior, and respond when something goes wrong. Planning those responsibilities early helps the business sustain the improvement after the initial project ends.
Plan your AI roadmap with Spinnaker
The next AI investment should improve a business process while preserving control over data, costs, and future technology choices. A successful pilot gives leaders evidence to work from. Scaling it requires a plan for the commitments that follow.
Spinnaker Support provides independent third-party support for Oracle, SAP, VMware, and JD Edwards, along with Enterprise Software Support for PostgreSQL. Through Spinnaker OpenPath™, Spinnaker works with CIOs to keep core systems stable and secure while identifying where AI and modernization can deliver business value.
Planning your AI roadmap for 2027? Talk with Spinnaker about the systems you need to sustain, the workflows you want to improve, and the choices you want to preserve.
