Glen Ceniza, CTO at Sapiens: “We hold our agents to a higher standard than we hold people”

Glen Ceniza has spent over 25 years leading large-scale product, engineering and cloud organisations, helping businesses navigate the increasingly complicated demands of enterprise technology. As CTO at Sapiens, which specialises in digital transformation for insurers, Glen is applying his experience to the next major shift in technology, with a focus on cloud-native and AI-first platforms.

In Glen’s view, the industry may be looking in the wrong places for AI’s immediate impact. While the most attention-drawing cases involve replacing human judgement, he believes businesses underestimate what AI can do with the “decades of technical debt” that has accumulated. While configuration, migration and integration may not sound transformative, Glen sees it as “the low-hanging fruit right now”. AI can take on much of the painstaking work required to modernise legacy systems, freeing up teams from tasks that otherwise consume enormous amounts of time.

This belief is evident in Glen’s current work. Rather than chasing the widest possible use cases, his teams are starting with areas where clear, immediate gains can be found, such as the aforementioned legacy migration. And he has deliberately stopped short of full automation, to leave room for customers to choose how much human involvement they want, a view reflected in his belief that “nothing’s been abandoned”.

For Glen, AI creates genuine value only when it is grounded in the businesses it’s designed to support. This means connecting models to the data, rules and institutional knowledge that’s been built up over time. This allows AI to understand why a decision is valuable, rather than simply generating a plausible answer. As Glen puts it: “Without an ontology or data behind it, a frontier model in insurance is an expensive way to generate a very confident, very wrong answer”.

The question, then, is whether the industry is focusing on the right areas of AI’s potential. That’s why we started by asking Glen where he believes that impact is being overestimated, and where technology may be considerably undervalued.

Everyone says AI is transforming software, but where do you believe the industry is still overestimating its impact and where is it underestimating it?

Two things, and they’re related. We’re overestimating that the most visible, disruptive use cases – full automation of judgment calls like underwriting – are where the near-term value sits. We’re underestimating how much value sits in the less glamorous work of finally getting AI to tackle decades of technical debt – configuration, migration, integration. That’s the low-hanging fruit right now, and it’s resonating with customers far more than the flashier stuff. We could also be underestimating how AI might surpass the hype. This is not finite tech; it changes and improves on a weekly basis.

How has AI changed your company’s product roadmap over the past 18 months? Were there projects you accelerated, delayed or abandoned altogether?

The direction has been clear: go after the low-hanging fruit first. That’s turned out to be tech debt, not the flashy stuff – using AI on configuration, migration and integration work that’s been sitting there for years. Our migration tooling now maps legacy systems with somewhere between 80 and 91% accuracy depending on the source system, flags its own confidence level on each piece, and routes the uncertain parts to a human before anything ships. We accelerated that. On the other end, we’ve built a full set of agents that can automate underwriting – trained the same way we’d train a human underwriter, on the same field guides and rule guides – but we’ve deliberately held that back from full autopilot. Customers choose their own level of human-in-the-loop, and we’re still gauging market appetite before pushing further. Nothing’s been abandoned, but we were disciplined about not shipping a big, unsupervised underwriting agent just because we could. 

Many SaaS vendors now describe themselves as “AI-powered.” What actually separates companies creating real customer value from those simply adding AI features?

Whether the model is actually grounded in your business, not just your marketing. A model with no connection to an insurer’s data and rules is close to useless in this industry – it’ll drift, it’ll hallucinate, because it has no ontology to reason inside. What we’ve spent our time building is that ontology: forty years of codebase, data and institutional knowledge that makes a model genuinely good at insurance rather than generically good at language. That’s the difference between a company creating real value and one that’s put a chat window in front of a legacy system and called it AI-powered. We’ve also recognised that SaaS and cloud are key precursors to AI and provide the necessary underpinning to get insurers AI-ready.

What is the biggest misconception enterprise customers still have about adopting AI within business-critical software?

That the AI itself is the hard part. It isn’t anymore – model quality has moved fast enough that almost anyone can access very capable models today. The hard part, and the part enterprise customers underestimate, is what surrounds the model: the data foundation, the guardrails, the human checkpoints, the engineering discipline. Without an ontology or data behind it, a frontier model in insurance is an expensive way to generate a very confident, very wrong answer.

If you were launching your company today with AI available from day one, what would you build differently?

I’d build the ontology and the data brain before a single customer-facing feature. That’s the part that took us longest, and it’s the part that actually makes models useful in a specific domain like insurance, so I wouldn’t wait to get to it. I’d design it to leverage fit-for-purpose models from day one, too – teams of small, specialised agents each doing one job well, instead of one heavyweight model trying to do everything. And I’d build the audit and human-in-the-loop layer into the architecture itself, not bolt it on once a regulator or customer asks for it.

How is AI changing the role of your customers? Are you replacing repetitive work, augmenting decision-making, or fundamentally changing how people do their jobs?

Mostly augmenting, with real automation showing up in specific, bounded places. We’ve built agents that automate underwriting the same way we’d train a person – on the field guides and rule guides underwriters already use, with specialist agents for things like medical risk, fraud risk or application error, and human-in-the-loop available wherever a customer wants it. What’s changing isn’t just speed, it’s consistency: give an agent the same scenario five times against the same rule guide, and it makes the same decision five times. You can’t say that about a person, and for risk assessment, that consistency is valuable in its own right, separate from any productivity gain.

What has been the hardest challenge in bringing AI capabilities into your products? Technology, data quality, customer trust, regulation, pricing or something else?

Staying in control of our own codebase, honestly, more than data quality or trust, though those matter too. Coding models are good enough now that it’s tempting to let them generate huge volumes of code and just ship it. The risk isn’t that the code is wrong – current tools are quite good – it’s that you produce so much of it, so fast, that your own engineers no longer understand what’s in your system. That’s much harder to walk back than a bug. We’ve had to be deliberate about keeping people surveying and signing off on what AI produces, even when it slows us down, because losing that understanding of your own codebase is the real risk.

There’s growing discussion around AI agents replacing traditional software workflows. Do you see the future as applications becoming collections of intelligent agents, or will conventional interfaces remain central?

We’re building towards swarms of specialised agents rather than one all-knowing agent, and I think that’s the more durable architecture – not a single “sledgehammer” model trying to do everything. For underwriting, instead of one uber-agent, we built compartmentalised sub-agents – one for document intake, one for fraud assessment, one for subrogation – each running a fit-for-purpose model. That maps naturally onto how underwriting teams of human specialists already work. The interface doesn’t disappear, but it becomes more like a control tower where a person can see what each agent decided and step in, rather than a screen where a person does the work themselves.

How do you balance innovation with responsible AI? Where do you draw the line between moving quickly and ensuring customers can trust the outputs?

We hold our agents to a higher standard than we hold people. Every decision an agent makes gets logged – something we’d never realistically get a human underwriter or claims adjuster to do with that consistency – and we’ve built an Agent Studio so customers decide exactly where they want a human checkpoint, from full autopilot to a review at every step. We’re deliberately conservative about which model does what: lightweight, fit-for-purpose models for contained tasks, not a frontier model let loose across an entire workflow. And on the engineering side, we resist what I’d call the poison apple – shipping ten times faster because a coding model lets you, at the cost of losing real understanding of your own codebase. Speed that costs you control isn’t speed you can trust.

Beyond productivity gains, what business outcome are your customers most excited about when they invest in AI?

Consistency in decisioning, more than raw speed. An agent trained on the same rule guide will make the same call on the same scenario every time, which you can’t promise with people, however good they are. For an industry whose whole business is accurately assessing risk, that reliability is worth more to a lot of our customers than the hours saved on data entry, though they’ll happily take that too.

Looking ahead three to five years, what part of today’s SaaS experience do you think will disappear because AI makes it obsolete?

The manual grind of migration and legacy configuration work. Our migration tooling gets to somewhere around 80 to 90% accuracy today depending on the source system, and a person still has to sift through the rest, sometimes for months. In a year or two I’d expect that accuracy to get very close to 100%, and once it does, most of the manual mapping and configuration work insurers have quietly lived with for years simply goes away. The interesting question then is whether people stay as disciplined about checking the last few percent as they are today, when they know it isn’t perfect.

If you could give one piece of advice to another SaaS executive planning their AI strategy today, what would it be?

Don’t reach for the sledgehammer model for everything, and don’t let your engineers either – fit-for-purpose lightweight models for contained tasks cost a fraction of a heavyweight model and often perform just as well, and that discipline compounds fast at scale. But the bigger piece of advice is about your codebase, not your model bill: resist the temptation to ship ten times faster just because AI lets you generate that much code. The moment you stop understanding what’s actually in your system, you’ve lost control of it, and that’s a much harder hole to climb out of than moving a bit slower would have cost you.