SAS’s Jared Peterson says enterprise AI’s real challenge is production: integration, human oversight, quality data and open architecture, with Pune owning core Viya R&D.
Two years ago, enterprise AI meant demos. Today, the harder question is how to put it into production without losing control. For Jared Peterson, Senior Vice President of Global Engineering at SAS, that shift is already visible. Customers now ask how to operationalize AI rather than whether to try it.
In this conversation with CIO&Leader, Peterson explains why integration debt, more than cost or trust alone, stalls most pilots. He is clear about where humans must stay in charge, especially in model design. He also says agents inside SAS Viya are human-driven today, not fully autonomous.
He discusses why SAS bet on synthetic data with Data Maker, how it keeps that data statistically honest, and when it makes sense for CIOs facing data-residency rules. On architecture, he reflects on the trade-offs of moving Viya to microservices and says open file formats have never cost SAS a sale.
Peterson also talks about the SAS engineering center in Pune, which has grown to 1,000 employees and owns core platform components rather than just doing delivery work.
The result is a grounded view of what enterprise AI needs once the excitement fades: governance, quality data, and engineering discipline.
CIO&Leader: The experimental phase of agentic AI is ending, and a governance-and-trust phase is beginning. What specific signal are you seeing inside SAS’s engineering org, or from customers, that convinced you the shift is real rather than a talking point?
Jared Peterson: I’ll approach the questions from both perspectives you mentioned: the internal perspective within SAS, specifically in engineering, and the customer perspective. Because we’ve moved beyond the experimentation phase, that’s especially clear in conversations with customers. A couple of years ago, when I would meet with customers, the sentiment was always, “Okay, we’ve got a lot of demos and proofs of concept going, but we’re struggling to translate that into real value.” I think “governance and trust” is the phrase you could use as the basis.
I would also describe it more as operationalizing—actually moving from, okay, we’ve got a demo, to something real. That’s where you want to call it governance and trust. So let’s talk about it from both perspectives. From an engineering perspective, a recent example is the work we’ve been doing on using AI, generative AI, and agentic AI to respond to or anticipate cybersecurity threats.
We had several projects across many teams trying to figure out whether to use large language models to identify vulnerabilities in our software and suggest fixes. We had a bunch of experiments going, with varying degrees of success. The evidence that we’re in a different phase is that we’ve now centralized those efforts.
We have one standardized tool and one standardized approach that we’re now using across our engineering teams, and we’re seeing the value of no longer being distributed across all these different demos. On the customer side, the shift is clear: we’re having a very different conversation than we were a couple of years ago, and we see that in the progress and excitement around something like the SAS Viya MCP server. It’s an open source project. It provides an MCP server that sits alongside SAS Viya. Our customers are excited about it.
We see this changing customer conversation, which tells me customers are interested in having that capability alongside Viya, meaning we’re in a different phase. The fact that this is changing the tenor and sentiment of the conversation in very positive ways tells me we’re in the space where people assume we’ll be using these tools and operationalizing them.
CIO&Leader: If decisioning is increasingly automated, we can argue human expertise matters more, not less. Practically, where in the pipeline—model design, output review, and escalation—does SAS insist a human stays in the loop, and how do you resist pressure to automate that step away too?
Jared Peterson: First, we’re going into a lot of specifics. It’s important to realize that the Viya platform and our solutions are so broad that the notion of where we demand human involvement or encourage human involvement really scales with the complexity and importance of the decision we’re trying to make with our analytics. You can imagine wildly different use cases to which Viya can be applied. But if I take the kinds of things that you’ve laid out—model design, output review, and escalation—where would we demand or strongly encourage human involvement?
Definitely, model design and the design phase are areas where human judgment is invaluable. When you’re training a model that’s going to make a prediction, you’re inevitably trying to weigh factors like whether your training data is valid and whether you’ve unintentionally introduced bias that could have a negative outcome on some population.
These are value judgments that you’re going to want a human involved in. Even with amazing tools for automation, such as building modeling pipelines and automatically creating modeling tournaments to figure out the best model for the data you’ve got, humans still review the output.
They review all metrics, the model’s accuracy and quality, and ultimately decide whether to promote the model and put it into production for the rest of its life cycle.
Now, the other areas that you noted, like output review or escalation, are areas where we don’t necessarily require a human to be involved. Still, our tools make it very straightforward and common to involve a human. For example, you’ve got some loan underwriting decision in an intelligent decision flow, and in certain cases it’s normal to escalate that to a human reviewer for further review. So we make that very straightforward.
And then the last thing I would say is that, sitting underneath all of this, one of the things our customers come to SAS for and one of the things I expect from us and our platform is a strong layer of security and governance so we understand everything that’s happening along the way and who did what, whether it was automation or a human.
CIO&Leader: A lot of enterprises shipped agentic pilots in 2024-25 that never made it to production. From an engineering leadership seat, what’s the most common reason they stalled: trust, cost, integration debt, or something else?
Jared Peterson: First, let’s think about the timeline, because you’re right that many of those pilots never made it into production. I would call those pilots more Gen AI pilots than agentic pilots, because the notion of agentic is more recent than that timeline. But that’s semantics. And we say, okay, well, why did those pilots stall out?
What comes to mind is integration debt. When you’re trying to operationalize something, that’s closest to the realities I experience. It is non-trivial.
Integration debt is non-trivial in most production use cases, from having a pilot to actually having something in production. It tends to involve where your data is, what systems you need to integrate with, and all of those types of things. And so that gets out of hand very, very quickly. That last mile is probably the hardest thing. Now, of course, cost has been part of the equation.
But the cost side of the equation has changed and is changing dramatically. It feels like every day. The Anthropic, OpenAI and Microsoft are changing their pricing models regularly as they try to figure out how to make money from the technology. But you are constantly weighing, okay, based on what I’m spending, is the ROI on the other side of this? Does that make sense? So cost is a factor. But that’s probably not the primary reason things have not made it into production.
It’s just the complexity of that. In any normal enterprise, going from ‘I’ve got this thing working on some engineer’s workstation’ to ‘I’ve actually got it making a loan underwriting decision in real time when somebody goes on a website’ are very different things.
CIO&Leader: What does “governance” look like in the SAS Viya architecture for an autonomous agent: audit trails, kill switches, human sign-off gates? Walk through one concrete example of how a control fires.
Jared Peterson: It’s important to distinguish among capabilities that are in SAS Viya today, what users do today, and capabilities we envision for a future state of Viya.
When I think about SAS Viya today and the agents in Viya I wouldn’t describe those agents as fully autonomous. All agents in Viya are, by definition, driven by humans. There’s some human interaction that is governing that agentic behavior.
There could be a copilot-style desk chat interface that an agent sits behind, interfacing with the human. In today’s state of SAS Viya, there really isn’t a notion of fully autonomous agents running wild.
I mentioned the SAS Viya MCP server earlier. We absolutely have customers that are using that MCP server to interface with Viya as a tool. In that case, the autonomous agents would exist outside of Viya, maybe in a harness like Claude, which uses the SAS Viya MCP server and reaches into Viya.
But in that case, Viya is just a tool, and any concerns about whether there’s a kill switch for that agent would be external to Viya in today’s state. In the future state, we are exploring how to extend Viya into a more agentic development platform, where we would build more autonomous agents. And so those would be future-state questions that we would need to think through.
And of course, when you think about SAS and our philosophical approach to customer trust and what customers look to us for, if we’re ever going to release something like that, we’re going to have to provide the proper governance and human control such that all agent behavior can be monitored and logged and those kinds of things. But that’s not the current state of Viya.
The last thing is, in the current state of Viya, when you are using the SAS Viya MCP server, you have an agent to interact with Viya as a tool. That MCP server, the way it’s configured and how it works, means the agent is acting on behalf of a user. By definition, their capabilities are scoped to whatever the privileges are of that user, and All of the interactions that users have, even if they happen through an agentic approach, are audited in the same way that a user’s behaviour would be if they were using a user interface within Viya itself. If I think about a use case today, again, it’s not a fully autonomous use case, but a common one where you would have an agentic interaction; intelligent decisioning is the tool that comes to mind.
And intelligent decisioning is where you encode very deterministic decision logic and decision flows. The most relatable example is often a loan underwriting decision. You come to a web interface for a bank or financial services organization, you provide a set of information, that information flows through a decision flow, intelligent decisioning models fire as different nodes, and then a decision comes out at the end.
And those sorts of interactions, decisions, and decision flows could be triggered by an agentic interaction or by anything else. That’s an attempt to answer the question while separating the current state of SAS Viya from the things we think about for the future state of SAS Viya.
CIO & Leader: SAS Data Maker just went live on the Microsoft Marketplace. What was the trigger for building it now—was it customer demand outpacing real-data access, a regulatory deadline, or an internal need inside SAS’s own model development?
Jared Peterson: The reason for it going live is the reason for us building it. We actually acquired a company called Hazy a couple of years ago. We used their technology to augment much of the work we were already doing internally to develop SAS Data Maker. I wouldn’t describe it as any of the things that you listed. Instead, I would describe it as us looking at the market, understanding the limitations that customers tend to run into, and saying, “Okay, well, in the future, customers are going to benefit more, or customers are going to demand AI models making decisions on behalf of humans.” High-quality data will be necessary. And based on our experience, we know that customers often don’t have enough data to train a model properly, or maybe they’re in some regulatory environment.
The types of things you’ve listed, but because we understand those realities, we decided to make a bet. We’re saying, okay, this future is going to involve lots of AI, lots of models. If that’s going to be true, users are going to need more high-quality data, which means in many cases they’re going to need to create it synthetically. And so, we should have an offering in that space.
And so that’s the thinking that led us to that acquisition, what led us to the development of SAS Data Maker, and it’s us as a company making a bet on where we see the future going.
CIO&Leader: Privacy, scarcity, and regulation are pushing synthetic data into the infrastructure layer. But synthetic data has its own failure mode: models trained on it drifting from real-world distributions. How does SAS validate that Data Maker’s output stays statistically honest over time?
Jared Peterson: We validate that by putting a range of accuracy metrics in front of the user. They can review a single-column histogram, distributions across two columns, and relationships between tables, such as a primary key relationship to another table, to see how those distributions play out. We provide many rich metrics in the Data Maker interface and then let the user tune the model parameters used to create the synthetic data to influence those distributions.
The way we’re keeping it statistically honest is by putting all this in front of the user, giving them the tools to adjust what needs improvement, and putting it in the user’s hands to decide how they want to proceed.
CIO&Leader: For a CISO or CIO in India or the Gulf weighing data-residency rules against the need for large training sets, what’s the actual case for synthetic data over federated learning or on-prem real-data pipelines?
Jared Peterson: This is a fascinating conversation in the market, and it’s why I’m so interested in it: it’s an area of strength for SAS. In many ways, the market is coming back to us. When I think about why a CIO with data residency rules would choose synthetic data over another method, such as on-prem real data, I think back to some of the points I mentioned earlier. If you have enough on-prem data and it is not subject to privacy constraints due to the regulatory environment you’re in, such as financial services or healthcare, that can be applicable.
If you don’t have any security concerns and you have enough real data to train a model that achieves an accuracy level satisfactory for your use case, then by all means, that’s the best case. But the reason a CIO would be interested in synthetic data is that often that best case doesn’t exist because of the things I’ve already mentioned. You’re in a regulatory environment where people who can see the data and people who need to train the model may be different. Or you don’t have enough data to build an accurate model. So by no means are we saying that synthetic data should be used for everything; it should replace the need for on-prem data.
There are going to be lots of cases where these other approaches just aren’t going to work because of certain limitations. In those cases, synthetic data is going to be the right option or the right play.
CIO&Leader: You’ve overseen Viya’s shift to cloud-native, CI/CD-driven delivery. What was the hardest architectural trade-off in that migration—and is there anything about the old monolithic SAS approach you still miss from an engineering standpoint?
Jared Peterson: There are a couple of areas I could go into, but the one that comes to mind is the shift to a microservices architecture. That shift was nontrivial for us because we went through many cycles trying to figure out the right level of granularity for a microservice. Was it too small? Was it too big? And when you’re moving things into microservices, you are optimizing for things that are important when you’re thinking about software as a service.
You want to be able to update things independently. You want non-disruptive updates. Those realities are true, but our challenge is that we also support customers who deploy on-premises, while Viya is completely cloud-native. Some of those traditional benefits of a microservice architecture remain relevant to us, but we have to keep complexity in check for on-premises deployments. That shift took a long time for us to get our heads around philosophically and to build the same level of pace and acceleration in developing those things.
And so then, if I think about one of the things that I miss, it’s interesting. A microservices cloud-native approach, academically, promises the notion of GAC and independent updates. Things are completely disconnected from each other, but in practice, while that can be true, it often isn’t. We found significant cross-cutting changes we needed to make. So if we’re evolving something around a security standard, updating a third-party library, changing a programming language, or moving from supporting a particular database, those large changes across the entire platform were, in many cases, easier to make in a monolithic architecture than in this kind of microservices distributed architecture, which is counterintuitive to what you would think about and read about in an academic sense.
And now we’ve gotten a lot better at that as an organization over the years, and we’ve mostly got it figured out. But yeah, I know you’re probably aware this is a very hotly debated topic in really nerdy engineering circles on the internet: Did the industry maybe over-rotate on this cloud native microservices approach? You’ve got really large companies.
One is Shopify, the e-commerce company, which is known in the industry as still having a monolithic architecture. I can understand, based on some of the complexities we’ve navigated, why they would take that approach. There are lots of days where I’d love to entertain the monolith. Still, one of the benefits that have come from the microservices architecture, when talking about all that with the MCP server, is that much of the work we did in microservices and the APIs around those microservices has enabled significant acceleration in things like MTT. That’s a really long-winded answer to a good question.
CIO&Leader: SAS has taken a public stance on open file formats. Why does that matter competitively, given the pull toward proprietary AI stacks elsewhere in the industry, and where does open architecture actually cost SAS a sale?
Jared Peterson: There’s never a case where supporting open file formats cost us a sale. If anything, I think the reverse is true. Think about SAS in our history. It’s no exaggeration that in many cases, we created the entire space, the entire industry that we play in. And so we’re known; if you go to a lot of our customers that have been using SAS successfully for years, they’ve got a lot of our proprietary data formats behind their operations. As the competitive landscape and open source analytics have evolved, our customers are actually demanding that we support other file formats, not that they want us to move away from proprietary data formats.
They want the same thing to be true of other software vendors they work with. That’s why companies like Databricks, Microsoft with its Fabric platform, and Snowflake all use open file formats such as Parquet and Iceberg. Customers expect that. So there’s no sense in which embracing open file formats costs us a sale. If anything, it’s leading customers to consider doing more with us.
For some recent examples that show this, a technology we’ve talked about a lot, and the rest of the world has also talked about in the space of open file formats, is DuckDB, which can read all these open file formats like Parquet. We have several customers, especially in the financial services space, who are seeing enormous gains in the storage footprint required for their data sets when using an open file format like Parquet compared to some of our proprietary legacy file formats. Those storage footprint improvements are prompting different financial conversations about saving money on storage by moving to these open file formats. So now that they can have that conversation with SAS, they now have a different conversation with us, right?
Instead of saying, “okay, I’ve got to move away from SAS to get those gains,” they now say, “okay, I can keep all of this wonderful SAS investment I have; I can flip it over to using these open file formats, recognize those storage footprint improvements, and everybody wins.”
CIO&Leader: You’re building out engineering talent in India and the GCC. How are you structuring those teams differently from a traditional offshore-delivery model? Are they owning core Viya R&D, or mainly scaling execution around it?
Jared Peterson: Our teams here in Pune cover the full breadth of the Viya platform, both on the platform and solution sides. I can’t think of an aspect of our software portfolio that isn’t influenced by teams here in Pune; how teams here in Pune work and how they’re organized will vary slightly depending on where they’re situated within that portfolio.
Before we get to some specifics, let’s take a step back and think philosophically about how we view teams here in Pune, as well as teams at our Cary headquarters in the States and at our other R&D center in Glasgow, Scotland. The notion and the word that I use is always autonomy.
Regardless of what teams are working on here in Pune, whether they own a product or application, or whether they are working on a component of some larger product or application, which can vary across where they’re situated, we want to create autonomous teams such that all of the roles necessary for delivering a unit of value are situated here in Pune.
The last thing we want is a development team here in Pune waiting on a product manager back in Cary, or needing to work with someone in Glasgow for testing and validation. Occasionally you run into edge cases where we’ve got to do that for some reason, but we’re always trying to minimize those cases. We want autonomy as much as possible. Then that autonomy allows you to build around it.
And then that’s where you get to ownership. We have many areas, especially on the platform side, where entire core services and components are owned by teams here in Pune. Whether that’s all of the underlying file-storage capabilities, all of our backup and restore technologies for Viya, or how we’re evolving multi-tenancy, all of that work happens here. Then, when you move into our solution portfolio, you’ve got entire parts of that portfolio like our industrial’s portfolio, which is entirely here in Pune. We’ve had a lot of success with that. The center here recently surpassed 1,000 employees, and we’ve celebrated it. I don’t know the exact numbers over the last couple of years while I’ve been traveling here, but the center has grown dramatically.
The teams here are always pushing for more. They always want the next level of ownership. And we’ve got lots of areas in the portfolio where they’ve got exactly that.