Preetpal Singh

At Xebia, I work with teams trying to move AI out of experiments and into production use. A lot of that comes down to modernizing the systems they already have and figuring out where AI genuinely fits into how work gets done, whether that is in software development, customer operations, or internal decision-making. My focus is making sure these systems hold up once they are live, rather than staying trapped in pilot mode. The most expensive projects I see are usually the ones that looked great in a demo, but nobody ever really modeled what it would cost to run them in the real world.

I am closest to enterprise AI systems that are moving beyond experimentation and into operational workflows, especially agentic systems, AI-enabled software engineering, governed knowledge assistants, and modernization programs where AI is embedded into existing platforms and decision flows. At Xebia, that includes helping companies use tools like Claude across their business, bringing AI into how software gets built, and setting up systems where AI can support and hand off tasks across different tools. A big part of the work is making sure all of this runs in a controlled way, with clear visibility and human oversight. Agents don’t need to see everything in one place, but whatever they are touching has to be something teams can trust.

Most of my time goes into helping large enterprises turn AI ambition into something that actually works in day-to-day operations. These environments are complex by nature, with older systems, scattered data, and real accountability tied to every decision. I’ve seen this play out in very practical ways. For example, when AI is introduced into software development, it can improve speed and quality, but only when it is integrated into how teams already build, test, and release code, not layered on top. One thing I keep telling people is that productivity is really a property of the whole engineering system, not individual developers, so if you only speed up the coding part, you’re only working on a small slice of what actually takes time. In another case, turning thousands of internal documents into something teams can use in the moment can dramatically reduce decision time, but only if the system is connected to the right data and easy to trust in real workflows. Once AI becomes part of operations like these, it has to be reliable, traceable, and easy to step into when needed, because there’s no room for ambiguity once it’s live.

Production AI starts to look very different once it’s running inside real workflows. The model is usually the easiest part. The friction shows up in everything around it, like inconsistent data feeding into it, dependencies on systems that were never designed to work together, and unclear ownership when something goes wrong at 2 AM. If a response is off or a decision needs to be reversed, teams need to know exactly what happened and how to step in without slowing everything down.

Another pattern that comes up often is that AI doesn’t really clean up a process, it tends to amplify whatever is already there. If a team is in good shape, AI makes them noticeably better, and if a team is already struggling, AI tends to make those problems more visible, not less. The other thing I’d add is that most of our governance was really built around humans, because humans will notice something looks off and fill gaps with judgment. Agents don’t do that. They just act on what they find, and they do it fast. So teams that take the time to straighten out how the process actually works before introducing AI end up with something they can trust and hold up beyond the demo stage.

I’ve seen the impact show up when AI is forced to deal with how work actually happens inside a company. One example is scaling AI across engineering teams, where the challenge isn’t getting it to work once, it’s getting hundreds of developers to use it in a consistent way without breaking how software gets built and released. What happens a lot is that individual developers genuinely feel faster and they’re finishing more tasks, but when you look at how much makes it to production, the numbers haven’t really moved. The bottleneck just shifts somewhere else. Another example is governing agentic systems across an enterprise, where multiple AI-driven decisions are happening at once and you need a clear way to track what happened, why it happened, and who steps in when something goes wrong.

In more regulated environments like compliance or healthcare, the bar is even higher. AI can speed up decisions and reduce manual work, but every output has to stand up to scrutiny, which means the system around it matters as much as the model itself. The pattern that keeps coming up is that once AI is part of a live workflow, it exposes everything that wasn’t working well before, from data gaps to unclear ownership, and that’s where these systems either scale or stall.

More attention will go into how AI decisions are tracked, explained, and corrected once they’re part of everyday operations. For example, in environments like compliance or claims, teams need to be able to trace exactly how a recommendation was generated and step in quickly if something needs to be adjusted, because those decisions carry real consequences. In systems where AI is working across multiple steps, even a small inconsistency can create downstream issues that take time to unwind. Speed on its own isn’t really the win people think it is, because if the system underneath isn’t stable, you’re just making mistakes faster.

What I’m seeing already is teams spending more time building ways to surface what’s happening in real time, whether that’s understanding why a certain output was generated or giving operators a clear path to intervene without disrupting the entire process.

One thing I think leadership teams really underestimate is that the hardest part is usually the change, not the technology. Model performance gets a lot of attention early, while the harder questions around governance, integration, monitoring, failure handling, traceability, and adoption show up later, even though those are often the factors that determine whether AI scales or stalls after a promising demo. The other thing is that AI isn’t really something you bolt onto how you already work. It’s closer to adding a new team member, and once you start thinking about it that way, the questions you ask about data, roles, and accountability all start to change.

Start with a business workflow where the value is clear, define the operational shift you want to see, and instrument it from the beginning so you can measure throughput, latency, accuracy, adoption, and business impact in production. I’d really push people to prove something works before scaling it, because a lot of AI adoption right now is measured through licenses, usage dashboards, or how developers feel about a tool, and that isn’t the same thing as showing it truly moved a business outcome.

Build governance, data readiness, and accountability into the architecture early, because AI becomes much easier to scale when teams treat it as an operating capability rather than a standalone experiment. Honestly, the companies that do well with this over time aren’t necessarily the ones spending the most, they’re the ones being most honest about where they are and what it’s really going to take. That lesson has been consistent across intelligent automation, modernization, and agentic AI programs.