Join our webinar

How embedded insurance is changing the face of regulation & compliance

Thursday 25 May
1:00 PM CEST
Register now

Related solutions

Blog post

Scaling AI: why it's a business transformation, not just an engineering project

Topic
General
Time to read
6 minutes
Last updated
May 28, 2025
In a nutshell
  • AI isn’t just for engineering teams – it’s a company-wide shift that drives real business results.
  • From building the right team to developing the right products, it’s not about scaling for the sake of it, but about making sure AI has a measurable impact.
  • From team setup to experimentation space, here’s what works (and what to watch out for).

If you’ve been following the AI wave, you’ve probably seen some eye-watering numbers floating around. Take Sam Altman’s quest to raise up to $7 trillion to boost chips manufacturing. For context, Germany's annual GDP is just shy of $5 trillion. 

In short: companies everywhere are betting big.

Most of that money is flowing into hardware, foundation model development and scaling up software in hopes that more everyday companies will boost AI spending.

But here’s what I find interesting (hi, Thibault here – Head of AI & Transformation at Qover 👋) is that when you look at AI conversations today, most of them centre around two angles:

  • Engineering: the rise of Model Context Protocol (MCP) servers, to standardise how AI models access external tools or data sources, and feature races between tech companies (is Google’s Agentspace really a match for French scale-up Dust?).
  • Risk: will AI replace researchers? How much should we fear ‘deep research’ bots? And not to mention the regulatory side of things.

Aside from reports of big efficiency gains in software development teams and customer support centres – which Qover’s Chief Customer Officer Ed Ackerman covered in his blog post about what we learned from using AI in claims processing – what’s often missing from the conversation is business talk, i.e. real transformation.

Not just ‘How cool is this tech?’ but ‘How do we use it to dramatically improve our bottom line?’ In other words, how can companies really automate their core tasks?

That’s what we’ve been asking ourselves at Qover – and today, we’re sharing what we’ve learnt so far about adopting AI company-wide.

Lessons from our journey: how to make AI a business transformation 

1. AI is a cross-company topic, but should be spearheaded by a fully dedicated team

AI is a new muscle which needs to be trained with focus. That’s why we didn’t want it to be just a side project for the people involved. 

At Qover, we have a dedicated AI product team whose sole mission is to build our AI roadmap by prioritising impactful use cases & feature sets across the company.

That said, many people across the business also contribute indirectly to AI use cases, even if they’re not part of the formal AI team. When that’s the case, we aim to make sure the project is a real priority, not just something squeezed in after hours.

The key: whether it's one person or 10, give them the bandwidth and backing to succeed.

2. Give the team a product & business mandate, not an engineering one

Even though engineering is fundamental to achieving business goals, the goal of an AI team shouldn’t be to ‘build AI-powered features’ or ‘bring AI assistants to everyone in the organisation’.

Instead: 

  • They should be inherently product-driven, to ensure scalability of the solution
  • They should focus on core business metrics like ‘increase gross margin by X%’

If you want AI to be truly transformative, it needs to be driven by business priorities. 

impact effort matrix AI business transformation
If an AI project is below 5/10 in potential impact, leave it or delegate it outside of your core AI team. 

3. Forget the low-hanging fruit

Experimenting with easy wins can feel rewarding. But if you want a meaningful impact, you need to be rigorous.

On the impact vs. effort matrix, you should eliminate any use case that’s not at least a 5/10 in potential impact; or delegate it outside of your core AI team. 

Our simple rule of thumb for prioritising AI use cases: if this works, how much can we support the company’s growth without expanding the team? And how can we supercharge our existing team?

We’re not automating for the sake of it – we’re scaling smarter.

4. Involve subject matter experts (SMEs) from day one

It’s easy to get excited about a new, sexy way of using AI, only to realise later that it wouldn’t make much of a difference in our bottom line.

One example we had was whether to build a vector database of all of our claim outcomes so AI agents could make recommendations for new claims based on their ‘memory’ of past decisions. In the end it proved impractical. 

What if the terms and conditions have changed since then? Just because a new claim is similar to an older one doesn’t mean it should get the same treatment. Plus, we saw the AI got too bogged down in unnecessary details - even after extensive data cleaning.

To stay grounded, we test ideas quickly with real examples, align priorities directly with SMEs and deliver solutions fast using human-in-the-loop setups (so SMEs can review and refine). In the case of the claims vector database, we worked with SMEs on the care and claims teams who helped review AI outcomes during testing phases.

This approach works, but it does come with two big risks you need to manage: two-speed adoption and not leaving space for experimentation.

Webinar: AI in insurance claims and customer care

5. Watch out for two-speed adoption – and foster bottom-up momentum

If you focus only on high-priority AI use cases, you might end up with a two-speed company: some teams racing ahead with AI while others are left behind.

We’re tackling this by encouraging bottom-up AI adoption. First, we give everyone access to vetted, easy-to-use AI tools (like no-code tools to build their own custom agents).

We also host small workshops with each team on how to get the most out of these tools, and run regular AI sharing and training sessions to keep creativity flowing.

The goal is to make AI feel useful and accessible to every individual, not just the core teams.

6. Leave space for experimentation

AI is still a fast-moving space – and you should be skeptical of anyone claiming to know exactly how to make the best use of it. 

At Qover, we intentionally leave at least 10% of time for free experimentation. There’s no playbook for this, so you need to give teams space for trial and error. Some of our most exciting use cases come from people who had some spare time on the side to fool around. 

When you give people the freedom to tinker, magic can happen.

Qover AI roadmap for customer care & claims
Our AI team is scaling and deploying new use cases across the business.

Our AI operating model at Qover

We have a central AI team. Our rule is that cases must show at least a 2:1 ROI before they get greenlit – typically around automation of customer care & claims – and we prioritise those with the highest ROI potential. 

The AI team pairs up with business analysts and engineers from other teams, who allocate around 80% of their time to this joint effort. They also work hand-in-hand with other product managers, and ensure we are building our AI capabilities as products from the start.

We ship in small, reviewable chunks, so SMEs can sign off before moving to full production. And then after delivery, we measure real business impact and present it to our management team.

Conclusion: what’s on Qover’s AI roadmap for customer care & claims 

We’re just getting started.

Over the next few months, we’ll keep scaling our approach and:

  • Gradually build our AI claims & mediation tech product & deploy across our client portfolio
  • Decide whether to use new AI customer touchpoints (e.g. does voice AI provide a good customer interaction on the phone?)
  • Build up the capacity of the care and claims teams to work alongside AI agents and maintain them

In the end, it’s not about building the flashiest tools. It’s about using AI to build a better, faster, more customer-centric business.