Michael Berns entered AI through a mentoring relationship that worked both ways. Around 2012, while supporting startups through his London Business School network, he met an AI company. He could help with business questions, market entry and working with financial institutions. In return, the founders introduced him to a technology that would change the direction of his career.

That exchange gives his conversation with Dr. Christian Mühlroth on Innovation Rockstars a practical starting point. Speaking from his work in AI and FinTech at PwC, Berns discusses applications in financial services, healthcare and investigations into exploitation. These are accounts of projects and experiences from the interview period, rather than a review of current products. Across them, he returns to a consistent question: how can a system help people make sense of information they would otherwise struggle to examine and connect?

Move the discussion beyond having AI

Berns describes a shift in the conversations he was having with organisations. Interest in implementing AI was giving way to more detailed questions about how it should be used, including ethics and responsible deployment.

His emphasis is on usefulness. A system does not have to resemble a human to provide valuable insights. The relevant question is whether it can help with a particular task and fit the conditions in which people will use it.

He also argues that advisers should gain experience inside their own organisations. His team’s work included helping colleagues handle routine tasks and become more familiar with digital ways of working. That experience could inform conversations with clients.

For R&D teams, the distinction changes the starting point. A broad ambition to use AI needs a more precise account of the problem, the information available and the decision someone will make with the output. Without that connection, enthusiasm can stay detached from implementation.

Help specialists find what deserves attention

In financial services, Berns describes work involving large volumes of internal communications. The aim was to identify patterns that could warrant investigation, including potential misconduct that had been difficult to spot through limited sampling.

His account includes information spread across different conversations and moments in time. Connecting those pieces can be difficult for someone reviewing messages or recordings individually.

He recalls instances where a proof of concept surfaced material an institution wanted to investigate further. The distinction is important: an indication that deserves review is not the same as an established finding of wrongdoing.

The broader product lesson is about the place of analysis in a workflow. A useful output gives an expert a reason to look more closely. Its value depends on whether that person can interpret it, assess the context and decide what to do next. Producing a signal is only part of that process.

Treat access to data as part of development

The healthcare example brings a different constraint into view. Berns describes work intended to bring information from records and scans together so specialists could consider findings in a fuller context.

The account centres on helping professionals identify something that might warrant further attention or referral. Berns is describing support for a specialist’s work, with the surrounding information and operational process forming an important part of the proposed value.

What is clear in Berns’ recollection is the effort required before the technical work could become useful. Discussions with the organisations involved and permission to use data took considerable time.

“It took a lot of work to get there over several years”

That is an implementation lesson a development plan can easily underestimate. Access, collaboration and a workable role for the system need attention alongside model development. A promising technical idea does not make those dependencies disappear.

Berns also describes trying to understand the interests of patients, hospitals and insurers. The proposed solution had to make sense across those perspectives, rather than optimise one isolated part of the process.

Understand the context before transferring a capability

Another example concerns technology used to support investigations into human trafficking and exploitation. Berns recalls learning about pro bono work connected with Thorn during an interview for an earlier role. The possibility of applying technical capabilities to that problem made a strong impression on him.

He describes systems intended to help investigators work through unstructured information and identify material worth examining. The organisational challenge resembles the other examples at a broad level: specialists have limited time, while the information available can be extensive and difficult to connect.

That similarity should not obscure the differences. The people involved, the data and the consequences of an error vary substantially across applications. The episode is most useful as a prompt to investigate those conditions, rather than a claim that a method can be transferred unchanged between industries.

The same technical capability may support several kinds of work. Making it useful still requires understanding the particular setting and the people responsible for acting on its output.

Learn through involvement

Berns’ optimism about AI is accompanied by a qualification: its effects depend on how it is used. His advice to people unfamiliar with the field is to get involved directly and learn through practical exchange.

“That changed my career, my life, my future outlook”

That experience remains his most memorable innovation moment. It gave him a different view of areas he already understood, including compliance, risk and financial services. He could bring business knowledge to the conversation while learning from people with different technical expertise.

For leaders considering AI opportunities, that is a useful model of preparation. Start with a problem you understand, work with people who can challenge your assumptions and investigate what implementation would require. The technology becomes more meaningful when the team can explain who it helps, what information it needs and how its output will be used responsibly in real work.