Hello everyone and welcome to this afternoon's session called AI Transformation from Risk to Value. We're so happy that you chose to tune in and what we would like to do today is try and describe to you how AI as we all know it's all the hype but it's moving very quickly from being something quite experimental and future oriented to something now that organizations are actively trying to fit into their processes and into the way of working. But for the majority the question somehow still remains how do I actually do it? Not whether or not to do it but how? When we talk to leaders across organizations there are a couple of questions that keep resurfacing and we would like to take you through some of these today. How do you get started without getting lost in the hype? How do you build momentum? How do you move from curiosity and prototypes into something that is actually used within your organization? The reality of these things is that the implementation span is quite wide and the considerations that leaders face are plenty. You could look at it as a trade-off between personal productivity gains for an individual employee and also looking at it from a business process efficiency perspective talking about very specific AI systems and frameworks that you adopt across an end-to-end process. But still how do I start? And that's the conversation for today. There are two primary paths, the personal productivity and the process efficiency where most companies venture down either one or the other but maybe there's value to be had in the coupling. What's less obvious to the majority of leaders seems to be what leads to the business value in the longer term. So with a very modern technology there's still something to say for how the adoption pans out and how we build or buy tools that our employees want to use in the longer term. As a part of the session today we'll share some portions of a practical story from one of our clients of how AI moved from being seen actually as quite a large risk or threat to the processes and to the technology stack to becoming something that can support and sustain business value over time within real processes even globally. What it takes to make this happen. The story is from a global life sciences company but we'll try and turn these learnings into best practices and advice for you as we go along the way. As we move through the next 30-35 minutes or so for this session please add your perspectives and your questions in the chat. We might answer some of them along the way in the chat so keep an eye on it and otherwise we will answer as many of them as we can on the go. When we look at the client and the case that we will take you through, they have been on this journey for just under 18 months. And they're seeing adoption rates ranging from 50 to 80% slightly tool dependent and process dependent but maintaining these impressive adoption rates already now quite a long way in. So, I will start by welcoming two of my colleagues who will help us venture out into this conversation ranging between personal productivity gains and business process efficiency gains. And Axel and Bacelan over to you. So, Axel, when AI sort of first enters this conversation, what do organizations actually react to? I think when we start having these type of conversations, organization doesn't necessarily push back on AI or innovation just for the sake of it. What tends to be or surface are real and valid concerns. Concerns about misuse of information, data leakage, quality and control. And I think they have possibly been shaped by what they have seen elsewhere. From organizations that are perhaps too eager and ruling out AI too fast without enough guardrails. And I think underneath this lies a bigger question. Can we control AI usage in our organization? And for some, the safest answer has felt obvious. Let's wait, let's restrict and let's not move too fast. But I think over time, what has also stood out as another risk. And that's the risk of doing nothing. Because the world around us is moving. AI is no longer just a hype. It's something very real in some organizations. So, this isn't consultancy theory anymore. Expectations are shifting. Competitors are moving. And soon enough, if you haven't already, I think most leaders in an organization realizes this cannot just be on the let's wait and let's deal with it later list. So, when you face leaders today and you start talking about some of these risks and what they sort of have a fear for allowing this technology in over a threshold or a firewall or whatever it might be into a critical business process perhaps. Where do we meet them typically? Is it already when they've decided to do the implementation? Are we seeing them beforehand? Where does the risk element come into play? I think the risk element for most organizations is regarding their own internal data. Because in most cases, it contains then their customers or client sensitive data, which of course you don't want to be leaked anywhere on the web. There's plenty of enough bad players out there who can use it against you. So, I think we can start anywhere in that conversation. But I think it's perhaps a good thing to start already when you think about a use case or an AI idea. If you want to go down the path of process specific AI. Okay. So, that's a lot. When you meet leaders today and they start to, well, maybe not realize that AI matters. I think that, you know, the news will say that a plenty. But when they know that they no longer have the choice but to start to move, what is it that you see changing? What sort of shifts in the conversation and becomes the real challenge that they want to overcome? So, I think what shifts usually in the conversation is what you also pointed out. So, it's not anymore if we should use AI in the organization. But it becomes a lot more practical and a lot more about how do we actually bring them this AI and actually get our people to start familiarizing with it and start using it in their daily base. And then I think that basically comes with the fact that you start building the trust. You start building some foundations in your company. You change the way of working. You create some small habits for different teams, for different task groups. And that's pretty much how I think you should look at it. Does this journey depend on whether or not you're a leader or an employee? Is there a difference in what we think people need to go through? When you talk to the leaders, is that a surprise? So, I think there is a little bit of a difference how you should approach it. And I think it should go both ways. So, I think we see a lot of great use cases that are coming sort of bottom up. So, great use cases that you wouldn't be able to discover as a leader. But you should really listen to your team when they are bringing them in. But from the other perspective, then I think also as a leader, you have a huge responsibility how you react for these use cases when they bring it up to you. And how you kind of show the good example how you engage with these technologies. Do you see leaders that are curious about their own personal use of AI? I think what we see is that most leaders are really curious. And they actually spend a lot of free time even to try out some of these tools. So, I think we are at a time when I see also partners in our company doing some vibe coding, which they never touched before. So, I think the curiosity is really there. And then the question is how do you channel it downwards in your teams? Yeah. Do you guys think that that kind of helps remove some of the risk conversation? When leaders are exposed to the technology themselves, how is that playing into this fear or risk paradigm? Yeah, I think it can remove the risk because that can create a safe space if the leaders are also showing some good example. But I think from the other perspective, it's also important that the leaders also show how to use it the right way because there is still a risk. So, I think that it's becoming also the leaders responsibility to make sure that we have the right sandboxes for experimentations. And then we are getting close to the sensitive data that you also mentioned. We build up some kind of mechanism that can cope with the new use cases that touch those sensitive data sources to know how to deal with those situations. Great. Axel, you mentioned a couple of buzzwords here. Yeah. So, consultancy theory, what are you meaning by that? Yeah, you're right. I guess I used consultancy theory. Well, what I mean by it is that AI has become now very concrete in at least my opinion. Whereas a few years back, many of the conversations we were having were quite conceptual. You talked about ideas or possibilities of what AI might be able to deliver for you as an individual or as a company. But what we see today is that that's changed because organizations are building capabilities, moving away from use cases to actual implementation and starting to see real value in their efforts. So, the barrier now is no longer a lack of success stories, examples or best practices. It's knowing how to start and starting in the right way. So, that's why the path that we will take you through later on matters. Because if you get the wrong start, you can quite quickly create fatigue and a lot of disconnected experiments. I think you call it pilot purgatory in OPEX. But if you get the right start, then you build momentum that's lasting and that has a great impact on the journey ahead. So, how do you see a shift in the way when we met leaders, let's say a couple of years ago, sort of after the initial wow factor of ChatGPT and the curiosity that naturally spun off of that. So, we also know organizations that basically blocked it and said, no, that's just not for us. We can't use that. You can't access it from corporate environments. And then into this logical need for experimentation. How is the conversation with the leaders changing? If you move away from this consultancy theory, how is that shaping the conversations differently? I think it's, for us, it's been a little bit going away from, as you will talk later about, Beltlon, sort of shiny demos and just showing this is the most advanced, best thing ever. And going more into, okay, what is the business problem we're actually trying to solve? So, we'll look at the business process, the technology that might help it, and then the people in the process. Because if you just go for the fanciest and wildest technology, it might not suit the use case that you're trying to solve. There might be a big discrepancy. Yeah. Cool. If you had to just kind of try and pinpoint a little bit, we will get to the case in just a second and try and make it even more concrete. But what is the structure that sort of helps turn some of these things into practical, applied conversations instead of only leadership, roadmap, ideation type conversations? Just a couple of words. Yeah. So, I think it's down to these two lanes. So, if you can start experimenting with both. So, first of all, how do you provide this base, which is the first lane, so this generic AI foundation that can really bring AI close to your employees. So, it can start building the trust, start kind of putting for the future use cases the adoption, because they get to know the technology early on. And then on the other side, you also start looking into this process-specific AI lane, which is a lot more about how to grab things from the process side. So, how can we bring AI into specific processes? And there, you really don't think about the technology first, but more try to map out what are the business problems and then try to fill it in with some AI capabilities. So, do you feel like that it's actually shifted from, well, I know the theme of today is from risk to value, but has it moved into something that is becoming more legitimized as a tool in the toolbox to be a problem solver on equal terms with other technologies that are perhaps more known? That's a great question. I think it's still a different technology to some extent, because it got a very different hype compared to other technologies that we've seen in the last years. And I think that also creates a different way how we should approach it, because I think what we also saw often is that the expectations can also be sort of over and beyond. So, I think it's still sort of important that people also understand the technology itself to some extent. And of course, probably none of us will be an expert how these large language models are really working if you go down to the building blocks. But if you are a bit more aware of what is it good for, what is it less good for, then I think it also meets a bit better what is feasible from a technological perspective from the other side. Like, what are these expectations that the business might over-expect that this black box will just solve it? Great. Great. Okay. So, this is where we're going to ask you guys to help us to take the conversation to the next level. So, for example, you will help make these two paths between individual productivity and business process efficiency in a world where leaders are seeing AI as not just a hype, but a helpful friend, and try and make this concrete and go through the next use case. Thank you. So, now I want to add a few more words to these two paths that we've been talking about earlier. So, the first lane is the generic foundation, how you build AI as a generic enabler in your organization. This is again where AI becomes familiar. This is where people can learn how to use it responsibly. They can learn what it is good at, what it is less good at, where is it even allowed to use, and what are the things that you have to handle a bit more carefully in regards to the technology. This is also the place where the organization has a chance to remove the friction and the kind of fear around the AI technologies. Where at the same time, it's also the place where you can help colleagues to learn how to use it safely and avoid data leakage, respect GDPR, that Excel also mentioned earlier, and other compliance requirements, while still keep the innovation in a practical way. So, this is what builds the trust, the habits, and creates this reusable foundation. Then the second lane is the process-specific AI. This starts not with a shiny demo, as you also mentioned, which I really love to do, by the way, coming from a technical background. But it really starts somewhere else from the real business pain points. So, processes can be slow, they can be inconsistent, they can be dependent on individual experience. And these are all places where AI can step in and try to help in some ways. So, the key message is really this. You do need the foundation to be able to scale well in the future, but you don't need to wait for it to be perfect before you start exploring the process-specific second AI lane and do custom pilots. I will also highlight that when you are working on the second lane, so in the process-specific AI lane, ideas should never be considered only as demos or pilots as their main goal. Because what we see is that if you treat something as a pilot, it will actually stay a pilot forever. So, you should build for quick tests, of course, still, but with the mindset of wanting to scale it in the future. And overall, the strongest learning really happens when these two lanes begin to merge and begin to converge. And that's where you can start using the strengths from the two sides into each other. And one of the first major places where we had this happen, that the two lanes merged together, was around deviation management. Yes. So, let me start with walking you through this story. And even if you're not from the life science industry, the underlying challenge is very relatable. A deviation is essentially a process exception. Something didn't go as expected. And when that happens, the organization has to investigate it, they have to document, involve the right people, follow the right rules, and make sure the outcome is consistent and of high quality. And it's worth pausing a moment on why this matters. Because deviations happen every day in every company. But for life science manufacturers, it's absolutely critical to handle it correctly. Because quality and consistency are directly tied to product quality and ultimately patient safety. They're also foundational to trust. In a CDMO model, customers are trusting you with their products, their processes, and their reputation. And what makes deviation management particularly challenging is that it's really not only a single task. It's more a chain of different steps, roles, sides, and decisions. So deviations are just cross-functional by nature. They rarely sit within one role or one team. They require a coordinated execution across teams such as the quality team, operations, or manufacturing. And it also goes across sites quite often. This means that there are different handovers over the process, many steps, different input-output formats that users have to provide. And there are different internal rules and best practices that might be specific to the given site that we are at. So from a system and workflow perspective, this is basically a process with a lot of different moving parts. And with a lot of context that people need to get right each and every time. And at the same time, they also need to know the latest version of guiding documents, working instructions, and organizational knowledge, which also makes it even more challenging. And when you look at deviation management across the life science industry, there are a few challenges that tend to come up again and again. And that pattern was visible in this CDMO as well. Firstly, there was variation in how work was carried out. Across templates, levels of detail, and how the guidance, as Bethelan alluded to, was interpreted. And this made consistency harder to achieve at a scale in an organization this large. Secondly, because the process itself is complex and spans many steps and handovers, even small differences in how people approach individual steps can add up over time. These findings help clarify the opportunity for us and the CDMO. How do you support people through this process in a way that makes it easier to work consistently and reliably? And one reason we were able to move quickly is important. The generic lane, as Bethelan talked about earlier, was already in place. So we didn't need to spend time on basic infrastructure, core IT processes, or reopening legal and platform discussions. That groundwork was already done. Which meant we could focus fully on the business problem, the people in the process, and how to leverage AI technology. Now, before getting into the bit more technical setup, one thing mattered a lot, and that was how we designed the solution. We started with a small group of SMEs, who are really close to the process, and who really deeply understand how deviations are written today in practice. That can be based on your site, based on the different process steps, or the role that you are taking when you are writing the deviation reports. Then process experts mapped the current state, and with a very frequent cadence, we built quick prototypes to make ideas tangible. That turned the design into a dynamic and very iterative process, instead of a few large workshops, followed by a month of isolated development, that we used to do in the IT scene before. And that is also very much how we like to work in implement, what we call a collaborative consulting, where the solution really evolves together with the people who will actually use it later on. And here I also need to note that with the tools available today, you can move really extremely fast in these early prototypes and in these early stages. I have to also add that you have to be sort of independent from the organizational data, but if you can kind of look at the idea first, then the prototype creation can be extremely fast. So you can get concepts, flows and interactions quickly out, which makes it much easier to keep the momentum and react to the feedbacks that are coming from the users. The Monsar solution became testable. We expanded the SME group to a larger size. And the feedbacks also broadened with this bigger size. So that meant that we are not only focusing here to the functionality and to the core logic, to the brain of the solution, but we also had a lot of feedbacks coming on the flow, on the wording, on how intuitive each steps felt. So basically around the user experience, which is extremely important too. And that continued all the way to the go live and also up to the day. So we are still getting feedbacks and we are still reacting on them to make the tool even better day by day. And because we already had the generic AI foundation in place, we could focus a lot more on the solution design rather than the basic infrastructure. But again, the first thing was crucial to have. Then now at this point, you can ask that, okay, then what is the kind of engine under the solution? So what was the final solution design ending up being? And I would start by saying that there are many different agentic frameworks available today, which was also our aim to be, used in this solution. And there are a lot of interesting discussions just on this topic, like how to choose the right framework, especially because the landscape is moving extremely fast. So if anyone wants to go a bit deeper on this afterwards, I'm really happy to further discuss it. But for this specific case, the key decision was somewhat simple. We really wanted to have full control and maybe a little bit less advanced autonomy in regards to the models. The reason is that in process like deviation management, too much model freedom quickly can become difficult to explain for that reason, difficult to trust and difficult to adopt to from the user's perspective. So instead of going towards a fully autonomous setup, we built our own framework with a more supervised approach. You can see now here on the slide, the simplified and anonymized mockup that is quite similar to the actual final user interface that we deploy to our users. On the right hand side of it, you can see that there is an editor type of view, and this is where users can basically author the deviations. And this is where under the editor field, users can also get guided actions directly in the workflow through these action buttons, as we call it. So instead of starting from a blank chat and trying to figure out what to ask, you can trigger the most relevant AI support right where you are in the process. And that support is contextual. So it actually also depends on the site that you belong to. It depends also on the right step where we are at now. And it also depends on the user role, how you log into the tool. And this makes it much, much easier to get started and also to understand through this customized user experience. But at the same time, we also didn't want to remove the flexibility. So that's why you can also see the left side that looks more like a chat interface. We wanted to give users the way that they can refine a request. They can ask some follow up questions or they can also explore a specific direction or topic in more details. So all in all, this means that we ended up with, you could call a hybrid model, which has both the guided interactions as the default choice for users, with chat as a flexible extension on top of it. And I can say that from the user tests from early on, that turned out to be a very important design choice, because guided interaction was often just the better default because it lowered the friction, increased the trust, while the chat still remained valuable when users wanted to go deeper. So the point here was not to build, again, the most advanced AI setup that is possible at the time when we started to build the tool. It was a lot more to be able to support people through a very complex process in the way that feels predictable for them, understandable, and just genuinely useful. So at this point, what really matters is how these AI capabilities are used in the process to support people in doing the work, and ultimately help them produce better reports. So we developed several capabilities, but I'll focus on a few selected ones, all designed to address the existing pain points people experienced when working with the deviations. One of the key parts was helping users stay aligned with internal guidance. So instead of having to search for SOPs or work instruction from the document database, the relevant guidance was brought directly into the workflow, exactly at the step where it mattered. Another part was writing support, to help improve clarity, structure, and consistency. And this turned out to be especially valuable in this organization, where many people are non-native English speakers, while deviation reports are always written in English. And in this context, even relatively simple support, such as rephrasing, improving grammar, and making text more consistent, becomes very powerful when it's placed directly in the flow of work. The third part was more intuitive access to historical deviations, being able to quickly look up similar past deviations through the usage of retrieval augmented generation, also known as RAG. This gave people a stronger basis for judgment, especially when analyzing historical patterns or trends. So the key point is this, the system wasn't there to replace people, it was there to support them, with the right context at the right time, as they moved through the process, and that provided strong and tangible results. We saw faster and smoother writing and reviewing cycles, consistent and standardized outputs across roles and locations, and less dependence on individual experience because of the always available guidance. And together, this meant better support through what is a complex multi-step process. But this is also where a hard truth shows up. Even the best solutions will struggle to deliver real value unless people actually adopt it. Let's now hear a few of your reflections and questions together with Chris. Thank you so much to all of you who are posting questions in the chat. I have now been furnished with an iPad, so we can have a look at what you guys are putting in here to us. And I think, Bertil, at least to the three of us, and probably definitely also to the users and viewers sitting out there, you're the more technical background of the three of us at least. So there's a slightly more technical question here that's been asked that I think is really relevant, especially in this day and age. For a long time, it says the industry has relied on the cloud for hosting of these technologies. Do you see a trend towards local or on-prem hosting of the models? That's exactly a great question to ask these days. I think we definitely see a trend that goes towards that. And I think maybe one reason is that the compute is becoming really powerful day by day. So even though these models are also extremely heavy to host, now I think we are at the time that there are a lot of LLMs that are giving very reasonable results from the open source space. You can also see that some of the bigger players also move towards that. So now OpenAI also has their own model that you can host yourself. Gemini also has now a version that can be hosted. So I think it's definitely a direction. And maybe another part of it which is less technical is also sort of the political landscape that maybe you don't have to very deep into. But I think just given the current political landscape out there, it also, I think, urges a lot of companies to think about the sovereignty part. So are we trusting these cloud providers with all our data when it comes to these models and inferences happening in different servers? Or are there some specific task areas where we maybe want to lock it to some local models? So it can also still be a hybrid setup perhaps, but it's definitely a direction that should be explored by a lot of companies. Well, the whole theme of the conversation is risk to value. So it's a new risk, at least, that's popping up. Axel, there's one here that I think is right up your alley. Do you still see the organizations needing to retain manual process knowledge when an agent replaces parts of a process so that they can step in if the agent fails due to changes in data, context, or the condition of the process? Definitely. I think it's, for most companies, I would say it's maybe too early to go fully autonomous. And it's always good to keep that sort of experience and knowledge in-house with people because there will be a time when you need to update a process. And if you can't explain it to an agent, you might need someone who can then help explain it to the agent. So I still very much think that you can't just shut down your internal competence and just lay all of your trust in the system. But for sure you can do most of it, but still keep the internal knowledge. Okay, great. So now there is one here that is a great segue into our next little conversation because it's about adoption, but it actually has a cool angle to it that I just want to touch upon. Would you say that the bigger risk is not just adoption, but also governance and compliance when AI then replaces or partly replaces a process? How do we handle this governance discussion in terms of the processes? I would say it depends on the industry. Some industries require more manual and human in the loop, such as the life science industry. I guess in less regulated industries, potentially easier to loosen up a little bit on the governance. I don't know if you have a different perspective. I think it's an interesting time because maybe you do also have to rethink the governance around some processes. Because I think whenever we created these structures in organizations, it was always really like tailored towards humans. And now that they can actually come in and help in maybe sub parts of those processes, I think it's also an interesting time maybe to zoom out a little bit and look at our governance structure and how our operational setup is to make sure that we can also now have this collaboration between humans and AI in a very smooth way that is still governed the right way. But we don't force the human-oriented kind of governance rules on AI because it works slightly different. Yeah. Okay. But I want to talk about the value generation because that's a significant part of the whole leadership discussion, at least here. But Bacilent, you said in the very beginning, value is not just about the solution. So even you as a technical profile, what do you mean when you say that? Yeah. So what I really mean there is that the value comes from two things. So one is the impact and the second is the adoption that we just started to discuss here. So I think it's very important that if you don't have users who are actually adopting to your solution, then it can be very powerful in theory, but that value will still stay theoretical in a way or limited. Yeah. So that's why it's important to maybe think about these two lanes again, because if you are very successful in the first lane, so the generic AI foundation, then it means that people are getting used to how to use AI. They are embedding it in some small tasks. So you can actually improve the initial reach and you can really like anchor the adoption well, but it might be also limited from the use case perspectives. So that's where the second lane can come in. So if you have an organization that very mature in the second lane, so process specific AI use cases, then maybe it's a bit harder to deal with the adoption, especially if you don't have the first lane in place the right way. But that's where the impact can be much, much larger per user, but it's for a smaller user baseline. So that's where again, we get back to the same conclusion that if you can do the two lanes together, then you can actually foster the adoption very well. You can reach out to the whole organization. And then on that, like you can start building this more siloed use cases that are more advanced to a specific process, to a specific user group. Yeah. And Axel, how does this even translate into business value? Like this is a common question. Yeah, good question. I think if we were talking in simpler terms, sorry about that, we at Implement believe that real value comes from the multiplication of impact and adoption. And by impact, I'm referring to what's the output that the solution can offer. In our case with the deviation management, we saw a 20% efficiency gain in writing and reviewing deviations. But at the same time, you also need to consider adoption, how many people are actually using it. And for the deviation management, we saw that around 50% of the targeted user group are using and have adopted to the solution. So the key point is that you only realize the true value when you combine the two. If you only go for high impact, but you have very low adoption, that's not going to move the needle. And on the other hand, if you have high adoption with little impacts, then that's not going to do it either. So in essence, you need both of them, not one or the other. And what do you think are some of the key considerations in actually making the adoption happen? Like everybody can be AI curious, but that's not the same as saying that I want to use it in my work all day, every day. No. I think to unlock sustainable adoption and then Indian also sustainable business value, you need more than just the technology. So we need to consider the human aspect in all of this and help to reshape the workflows so that the new way of working feels natural. And we need to put people at the center of both the design of the solution and change management with intent. And I think our learnings can roughly be put into four key points. It's to build habits that stick. You need to onboard and upskill your employees to make sure that AI becomes a natural day, natural way of how you do the work, not just an extra step you do right before leaving out the door. Secondly, you need to communicate what matters. There's a lot of communication going on in all of organizations, but it's really important to show the why and spotlight the success stories and how the journey is being carried out in the organization. Thirdly, we'll talk about leading the change. So I'm not only talking about the C-suite or VPs. We need to empower leaders at every level because that sets the tone and creates a lot of energy and excitement in the organization. So it's about empowering everyone throughout the organization and all of the teams. And lastly, I would say also that you need to measure what matters. So you need to agree on the specific and measurable KPIs that then can guide your journey throughout. If you need to adopt something over here or something doesn't work over here, then you can track it and make sure that you're constantly updating the way that you do adoption. Okay. And, Batalan, again, from the technologically product and implementation heavier side, are there any additional perspectives to think of? When you start to venture down the path towards hopefully high adoption. But, yeah. Yeah. So maybe what we also mentioned a bit earlier that the high expectations are there for the technology. So make sure that you also set the right way how to measure those KPIs. So I think that's something that we miss often in these projects to think from early on how to measure it and then how to then basically act up on it. Great. Great. That's all we have time for in this very short period of time. But if we are to leave you with three things today, then let them just be these. It's not too late to start. It just matters how you start. And secondly, building this generic AI foundation and exploring the process specific alley, there don't have to be competing choices. And I think it's very clear for us after having done some bouts of these conversations that the two paths both can and should reinforce each other over time to help you get to value faster. And third, that the real value of AI doesn't come from the model or the algorithms that you deploy, but when you allow for it to become a part of how the work gets done. Thank you so much for choosing to spend a little bit of your day with us today. Thank you.