Legal and compliance investigations
Kyriakos Tempriotis described an AI-supported legal and compliance investigation workflow, reporting a saving of roughly 20 hours per case. The way he introduced it was as useful as the result: the work began with public court judgements, then progressed to historical internal conflict-of-interest declarations before live investigations.
That sequence gave people a way to build confidence while the sensitivity of the material increased. The report’s chapter on data ownership follows the connection between access, trust and the willingness to use a tool. It is a useful starting point for teams deciding how to introduce AI into work involving confidential information.
LEO Pharma: trust in field-team development
Steve Hopkins discussed the conditions needed for people to use call recordings as a development tool. Individual recordings were for the rep’s eyes only, with a clear boundary around their use for performance management. That ownership mattered because the quality of the information depended on people being willing to record their real conversations.
He also described reps starting calls before switching on the recording, so the agenda-setting part of the conversation disappeared from the data. A tool could be available and technically functioning while capturing an incomplete picture of the work. His advice on adoption was to make it part of existing habits, including field visits and cycle meetings. The report’s discussion of behaviour change brings those lessons together.
Jazz’s EVA: involve reviewers early
The report describes how Camino and Harish Kumar involved reviewers from the start of the work on Jazz’s EVA. The approach helped the project through strict compliance requirements because those conversations happened while the workflow was being designed.
For a pharma team developing an AI use case, this is a practical reason to bring the people responsible for review into the early decisions about data and workflow. The EVA example sits alongside the other data-ownership discussions, where access rules and user trust shaped whether a tool could become part of everyday work.
Working through scientific literature
In André Schütte’s scientific-data workshop, participants tested how a Categorise prompt could produce structured material for a Prioritise prompt to work on. That connection between steps gave the room a practical way to think about triaging large collections of papers.
The scientific-data workshop output sets out the Categorise–Prioritise–Extract pattern and the tasks people wanted to apply it to, including literature reviews, congress abstracts, HCP insights and competitor intelligence. Participants also used AI to critique their prompts, making the exercise a cycle of testing and revision.
Building tools around a team’s own work
The workshop led by Ana Roibu and Caz Canavan explored target builds including a congress insight dashboard, an SOP alignment tool and an insights-to-PowerPoint workflow. Participants worked through code, prompts and Copilot adaptations, adjusting their approach to the tools they could use. The workshop summary records what they explored and where they wanted to take it next.
In the vibe-coding workshop with Rosie Humphreys and Robin Jones, groups produced interactive outputs in ten minutes, often with no previous coding experience. Their builds included an MSL insights analyser, a sales aid for a fictional product and an interactive explanation for HCP conversations. Describing a need, trying the result and reacting to it gave people a way into building something themselves.
The work around the technology
Across the day, the examples kept returning to the people who owned the workflow and the decisions around it. Christina Busmalis of Databricks framed the effort as 10% model, 20% data and technology, and 70% people. Steve’s recording example and the early review work on EVA showed how those organisational choices could affect what happened after a tool became available.
For the workshops, the next step was to keep testing the approach against a real task. The AIP2 guide to AI agents in pharma follows that question into choosing a workflow, assistant or agent, and deciding what it should be allowed to do.