Jagadish Gokavarapu, VP of Technology at Wissen, 30+ years in IT and Services, specializing in AI and digital transformation.gettyAcross enterprises, I keep seeing the same storyline: An AI pilot delivers promising results, leadership funds a rollout and progress slows when the solution hits hybrid reality—edge locations, cloud platforms and on-prem systems kept for latency, control or regulatory reasons.The technology is rarely the blocker. The blocker is the operating model: what gets standardized, who owns the data and decisions and how the solution is run week after week.When teams ask what went wrong, it’s tempting to blame the model. In my experience, the root causes are usually mundane: inconsistent timestamps, shifting sensor sampling rates, missing fields at certain sites and limited visibility into edge behavior when the network is unstable.To move hybrid AI from pilot to platform, treat the solution as a product with contracts and controls—not a one-time deployment.Why Hybrid AI Breaks Pilot ThinkingHybrid changes the rules. In the cloud, late-arriving data can often be retried; at the edge, a late packet may miss the decision window. Centralized pipelines also hide variation that appears in rollout. Two sites can label the same field differently or generate the same signal at different frequencies.These operational differences can quietly destabilize features and predictions. Teams may also see the following:• Edge inference depends on features that are only computed in the cloud, so teams may duplicate logic or accept inconsistent outputs. • Training data diverges from production because definitions vary by site (units, timestamps, missing fields, etc.). • Security, audit and change management are strong centrally but uneven at the edge (or vice versa). • A “small” rollout becomes a fleet, and patching, monitoring and version management become the dominant effort.The Practical Unit Of Scale: An Edge-Ready Data ProductInstead of thinking in terms of “a model,” I’ve found it more effective to scale an edge-ready data product: a versioned pipeline that turns raw events into a decision, runs across the edge and the cloud and can be replicated with minimal rework. It includes the data contract, consistent feature logic, the inference package and the feedback loop that shows when reality has changed.The Operating Model BlueprintWhat does this look like in practice? Let's take a look at three key tenets:1. Placement: Decide What Runs WhereFor each use case, make placement a deliberate decision—not an assumption. I use three questions: What latency is required? What happens when connectivity drops? How sensitive is the data? The answers usually lead to a split design: fast, local inference at the edge with centralized training, governance and cross-site analytics in the cloud.In my experience, the following are good placement rules of thumb:• Edge: This should include time-critical decisions, offline tolerance and local filtering.• Cloud: This should include aggregation, experimentation, training and centralized policy enforcement.• Both: These cases involve edge inference plus a controlled cloud learning loop (evaluation, retraining and redistribution).2. Governance: Make Controls RealIn hybrid programs, governance fails when it stays abstract. The goal is not more documentation; it’s enforceable controls that travel with the data product across sites. Across regions, privacy, retention and residency requirements must show up in routing rules and access patterns.A useful reference point is the NIST AI Risk Management Framework, which emphasizes governing, mapping, measuring and managing AI risks across the system lifecycle.For most organizations, those controls should become practical checkpoints rather than abstract policy statements:• Assign who approves schema changes, who triages quality issues and who can promote a model version.• Define a testable data contract and version it.• Enforce least-privilege access for people and services across the edge and cloud.• Capture which data, features and model version produced a prediction.3. Operability: Run It Like A FleetEdge deployments fail quietly when you can’t see them. Before optimizing costs, standardize what you observe and how you respond. The easiest way to reduce surprises is to agree on a small set of operational signals and a disciplined rollout process.Similarly, the Azure Well-Architected Framework treats observability as a core operational practice, recommending that teams capture telemetry, metrics and logs to validate design decisions and guide improvement.At minimum, I would make the following operating signals and release practices consistent across every site:• Standardize logs and metrics across the edge and cloud, so incidents aren’t site-specific mysteries.• Look for golden signals, including lag, error rates and drift.• Conduct controlled releases that include canary rollout, rollback and version pinning.A 30-60-90-Day Plan To Turn One Pilot Into A Platform PatternI like to use a 30-60-90-day plan to convert one successful pilot into a repeatable platform pattern:1. Days One To 30: Define the decision, latency target and placement. Lock in the input contract and agree on what “done” means.2. Days 31 To 60: Implement controls like validation, routing/residency rules, least-privilege access and lineage. Put a simple change process in place for schema and features.3. Days 61 To 90: Operationalize for a fleet, leveraging standard logs, a few key metrics and controlled rollouts. Rehearse failure modes before expanding to more sites.A Quick Operating Model ChecklistHybrid AI scales when leaders standardize the basics: placement rules, enforceable governance controls and a fleet-ready operations rhythm. If those three are clear, teams spend less time reworking pipelines and more time improving decisions.Before scaling your next use case or location, use this checklist to confirm your operating model is ready:• You have one page per use case.• You have a versioned data contract with automated validation at ingestion.• There is a clear promotion path for model versions, including rollback.• You use the same logs/metrics everywhere.• You have defined offline behavior for edge locations.Make Reliability A Design RequirementMost organizations don’t need more pilots—they need repeatable patterns. Hybrid AI becomes durable when reliability is treated as a design requirement, with consistent contracts, clear ownership and operational visibility at the edge.Once those are in place, scaling to the next site looks less like a reinvention and more like a rollout.Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?