Enterprise AI Systems Endure When CIOs Build A Harness Around The Model

Enterprise AI conversations fixate on the model: which one is smartest, which is cheapest, which just leapfrogged the rest. For CIOs, it's the wrong target. With models now turning over on a monthly cadence and sliding toward commodity status, the thing that determines whether an AI system is reliable, auditable, and durable is the architecture wrapped around it. That harness, rather than the model itself, is where the enterprise value lives.

Craig Airitam is a veteran technology executive and Chief Information Officer with roughly three decades of experience across enterprise architecture, data strategy, and IT leadership. He has led modernization and digital transformation efforts spanning e-commerce, data platforms, API-driven service layers, and analytics, most recently as a CIO in the transportation sector and earlier in senior enterprise architecture and engineering roles across the technology and staffing industries. Airitam brings a builder's skepticism to a technology whose defining trait is the one that serious enterprise systems can't tolerate: unpredictability.

"The models are becoming more commoditized. Putting a harness around them is the only way to get the consistency and predictability an enterprise system requires," he said. In a landscape where local models running on the user's own machine, open-weight options, and narrow purpose-built models now sit alongside the brand-name generalists, Airitam believes betting the system on any single one is a race to keep pace with a space that never stops moving. That framing reflects a broader shift in enterprise AI, where executive direction and system design increasingly matter more than the tool itself.

• Anatomy of a harness: Airitam describes a harness as an abstraction layer that governs the full contract between the AI and everything around it. "I think of a harness as all of the guardrails, all of the schema definitions, all of the observability and the auditing that needs to happen to make sure that the system the AI is a part of delivers the right result to the right user. That needs to be both input and output, not just one way." Context and memory technologies live in the harness too, external to the model but central to nearly every enterprise system built around one.

• Complexity compounds: The harness Airitam suggests is not a fixed thing, but grows with the sophistication of the system it governs, and multi-agent architectures raise the bar sharply. "If you have multiple agents all talking to each other, the more complex this harness needs to be," he noted. Each agent needs its own harness, each has to monitor itself, and something or someone has to monitor the interactions between them.

The enterprise threat Airitam is most emphatic about is one that hides inside a system that still appears to be functioning. "Drift is your silent killer," he said. Drift, which can lead to real business impacts like lost ROI and increased customer churn, is especially insidious because the degradation is gradual and invisible. "It can happen slowly or it can happen very quickly, but you need to be looking out for it." Airitam's method for catching model drift deliberately sidesteps the impossible task of decoding the model's reasoning.

• Govern the contracts, not the logic: Rather than trying to understand how the model thinks, Airitam governs what goes in and what comes out. "Every prompt leads to a decision and ultimately an output. You need to understand what data is going in and what data is coming out," he said. "With this input, I expect this output. I'm getting different outputs. Is that okay?" The discipline turns a black box into something measurable at its edges, governing the boundary rather than the interior.

• When one percent becomes five: The value of watching those boundaries is that over time, it converts a vague worry into a specific, actionable threshold. "It happens one percent of the time. Or, it was one percent, and now it's up to five percent, and I'm a little concerned. Let me put a human in the loop and make sure that this is appropriate," Airitam explained. "It's possible the drift is actually a smart and appropriate thing, but you can't just assume that." The breach is the trigger, and the human is the judge of whether the change is acceptable or dangerous.

To make the reliability risk tangible, Airitam points to an experience nearly every AI user has had. "We've all used Gemini or ChatGPT, and it did something you thought was awesome. Then you go back the next day or next week, do the same thing, and it's not quite as awesome. You wonder why." It's a harmless quirk in casual use that becomes something else entirely at enterprise scale in a production system that touches the business. "With this kind of probabilistic technology, it will answer the same question differently over time. Maybe it's 90/10, maybe it's 85/15, but if that wrong answer is inappropriate or detrimental to your business, that can be catastrophic," Airitam said. The remedy is to define a harness of expected inputs and outputs, measure against them continuously, and act the moment the system stops being predictable.

• Swapping the engine, keeping the car: The harness delivers its biggest strategic payoff at the moment a CIO wants to change models, a problem Airitam thinks few teams have thought through. "Swapping out a model without a harness is suicidal. You can do it, but you need to do a lot of work." With a strong harness in place, the change resembles onboarding a new hire into an established role. "You're swapping out the brain that makes the decisions, but you're not swapping out how the information comes to that brain and what gets output from it," he said. 

Even with the harness doing the heavy lifting, Airitam is clear that a model swap demands the same disciplined evaluation CIOs already apply to vendor and build-versus-buy decisions. He outlines five key steps. First, retest everything against the established contracts before trusting the new model. Second, check the economics. "It may sound like this other model's cheaper, but the way it answers certain questions may actually be more expensive," Airitam pointed out. 

The third step he advises is probing the edges. "Some models are purpose-built for certain things and may be really good at that, but you may be asking it to do something it's not good at. So you need to check the boundaries." Next is running an A/B deployment, keeping the old model in production while introducing the new one and gathering metrics to analyze how it's behaving. Finally comes scaling the new system, but only based on evidence. "Once you feel like that test is performing on par or better, then I'd get more comfortable and scale that up," Airitam said.

He's careful not to oversell the ease of the swap, only its feasibility when the foundation is right. "I don't think it's trivial, but I do think it's doable if you have a harness that covers all those edges, has the observability, and is ready to take that on." In his view, that's the line between an enterprise AI system engineered to last and one that subtly degrades until it fails. The model will keep changing. The harness is what endures.