Thank you for the introduction. My name is Michiel Stoop. I am responsible since 1st of May within Philips for cybersecurity in our business and regions. And earlier this year I was also assigned to take the lead on securing AI. So my question to all of you is who is really excited about AI? So please raise your hand if you're really excited.
Okay, cool. Who's really concerned about AI? You can also raise your hand. And who is for both maybe? So please don't raise your hand. Excellent. So today I will zoom in my presentation how we look at this from Philips today because tomorrow it can be different of course. So first about, one thing I want to say is like I am not an AI expert because anyone is currently an AI expert because we all try to understand how AI actually works and also what the impact is of course on security. But first quickly about Philips.
Philips is a company that we founded in 1891 in the south of the Netherlands called the city Eindhoven, where it's founded by Frederik Gerard and Anton Philips. And since then we are improving people lives with steady flow groundbreaking innovations. And as products come and technology change, that's also for Philips as a company. So Philips nowadays is a company which builds products and software only for health technology. But Philips is still about one thing, creating meaningful innovations that improves the people lives.
It's our purpose to improve the people's health and well-being through meaningful innovations. And we improved the life of 2.5 billion people a year by 2030. And that's all driven by AI technology because we want to give new ways to improve healthcare and reach more people. So in Philips, we have a responsible AI office that needs to ensure that we have safe, secure, and responsible use of data for our AI. So they are teaming up with many stakeholders in Philips organizations to define our AI principles. So here are the stakeholders I mentioned.
And I'm from security, so I only zoom in to the security part for today, and I will not discuss any of the other AI principles. Now what about AI? Probably you know all the movie, The Good, The Bad, and The Ugly. So that also means for AI, we have the good things that bring speed, velocity, and power. Probably have this mentioned many times on the conference. There's one thing was bad about AI, there's the lack of built-in security. So that means that there is a lot of risks and we have a lot of concerns. So I sit together with the team and we were looking at like, okay, what is AI?
So we try to decouple it. And we started first this time with the identity, to say it like that. And we have on the left side, that's the assisted AI. Probably you're using JDBT or Copilot. They're using it as a tool. And from security, we need to ensure that we are using it safe, compliant, all these tools that protect our data. But then we have also where you as a person have probably many other agents doing your work. So you give them instructions. So you're moving to the team mate. So you have multiple team members doing your actual work for you.
And from security, we need to ensure that those agents are controlled and that they are governed system access. And then you have the autonomous part. So the autonomous part is like we are outsourcing, like to our managed service provider, but in this case, to agents all the work. And in the first two scenarios, there are still the human in the loop. But on the other side, in the last one, there are only human oversight. So those agents are interacting with each other and we need to make sure that they operate safely, transparently, and under strict governance.
When we started to look at AI, we were first only at the assisted work. And I'm talking about just a few months ago. But AI is accelerating so fast in Philips that we already are having people who have it running as teammates, but even we are the autonomous part already. So it's really hard for security for us to get in control of all this. When we sit together also with the team, it's like we try to understand the next slide.
Okay, what's then the concept of AI and in which domains do we need to divide it? So we have a defensive part and we have the offensive part. The defensive part we defined into user AI security, where we need to discover and govern the AI tool usage. So we need to know within Philips which AI tools are used, which we bought in our company, which should be used. So what we also want here is that people only use Philips credentials with Philips approved AI solutions, which are managed by our company, and then process the data net.
So people are not allowed to use public AI and use your company credentials and process your data. They are also not allowed to use your personal credentials in the public AI and process Philips data. Then the second one is about assistant AI and agentic AI, where we need to do monitoring and prevention of the unsafe actions. And I will zoom into that part today mostly. And then you have the underlying layer, that's the infrastructure part, which supports the AI systems. Then on the offensive side, we have AI red teaming, where you need to test the model behavior and simulate attacks.
But if you're looking into the responsibilities, our responsible AI office, which is one of the first slides, they are second line. So they're really looking at the discover and govern part and also need to make aware to our people how they should process it. We are from group security, so we are second line. So we are covering all these areas and we have different teams which are looking at all these aspects. And then we have our business. So because the business, they are procuring those solutions and start to use it.
So they also need to ensure that they comply to our security requirements, which have been defined by group security. And I will zoom into that during my presentation. And then we have IT security. And IT security needs to ensure that the AI solutions used within IT comply to the guidelines which are defined by group security. If you're looking into AI, then we can divide it into assistant AI, which I mentioned, and agentic. The assistant AI is really for the users. And the agentic part is mainly used by our developers.
On the left side, we have a better understanding of what the people are doing, who is doing what, and what they have done. But on the right side, on the agentic part, it's for us really hard to trace because there's more black box. So actually, it's really hard to control. So it could be that we have an increased threat and misuse of potentials here. So what we want to say here is like, also now with the gen AI and agentic AI, it also becomes more blurred, because the assistant AI has nowadays also agent capabilities. So they also get powerful.
As a father, I always compare it with my growing up my child. So I give him guardrails. And I hope always that my kids will stay within these guardrails. So if he's going to school, for example, probably you all know, there's always one bad child in your class. And you don't want that your kids would interact with this child.
But yeah, you cannot really prevent them. So you give him guardrails so that he still can interact with this bad child, but that he will be still a good child and not become a bad child. The same applies for agents. You don't want that your agent will become a bad agent and potentially leak your company data. If you're looking at the assistant AI, in the assistant part, those agents, they are running on your behalf. And in the agentic part, we really want at Philips that they have their own identity.
On the left side, but the assistant AI, we cannot do that, because the products are not built in by default that they have their own identity. So here the agents run on your device using your identity with your permissions. And on the right side, with agentic AI, the agents should run in the cloud with their own identity and their own permissions. One of the things what we are currently exploring with our responsible AI office, how can we block generative AI, assistant AI solutions and agentic AI on, for example, which run on devices?
Because if cloud flow, for example, is not allowed, we don't want that people are installing these on these devices to manage it. If you go one level deeper about assistant AI and agentic AI, we divide it into different capability layers. I'm going to explain LLMs, the RUG and MCP tools. I think that has been discussed many times. But for security, it's really important with the large language model, we must control what it can say. And if you're looking into the RUG, where it's the search engine, we need to control which information it can access.
And the MCP tools, which is a universal adapter to integrate to our data sources, we need to control which actions the assistant can take. So what we said, OK, to mitigate the risk with the 10,000th of MCP service, which exists, which one we need to validate and which one are allowed. So we need to put controls in place. And if you're looking into the agentic AI part, we need to control what it can decide and automate.
So, for example, if I ask like, hey, I want to travel to Berlin to the conference of EIC, then I maybe did not mean that you need to actually book it. You need to only provide me the options. And then I should make a decision. So we really need to control. And those agentic AI have also capabilities that's called nowadays skills. And we have to be careful with the skills that they are not, that we are not introducing skills in the Philips organization, which are providing a risk.
So we need to have a skilled approved repository and only those skills can be used and all others needs to be denied. When we sit together with the team, we also like, OK, now we see many layers. So there's a, if you add all of these layers to each other, there can be an enormous blast radius of an attack. So if you're looking into the LLM itself, that's not really risky because yet only has impact on the data which you are processing. But by adding each of these layers, it can have potentially an organization wide impact. Why?
Because the applications which you have in your organization are probably already misconfigured or they have overprivileged access and that will become visible with AI. But that's not an AI problem itself. It's already something in your organization which you did not well manage. With the AI part, it really will become visible. If you're looking into the agentic part and we also said like, OK, if people are using those agents, especially our developers, we want that they will use sandboxes. So in their developer workflows. So Philips is a very complex company.
I probably apply for many others, but there is no one operating model which will fit for our developers. So we look like, OK, which sandboxes exist and I group them a little bit together so we can define from security what are the minimal requirements, how to configure these securely, those sandbox environments. And we really want that there is a separation between the agent identity and the sandbox because the sandbox should have their own agent identity. So we can keep the blast radius really small.
So now I explained about the concept, the risk, which we saw, but then also asked the teams like, OK, but what does the AI architecture look like? Because I want to understand what AI actually look from it and what are then the risks. So we defined an AI architecture and on the next slide, I will show you a very simplified version of it. So we define it in C6 layer, but actually you have four. You have the identity layer, the agent layer, the data memory layer and observability.
So which is actually what, and then the data memory is like which data is restored, stored or retrieved and observed what has been done. So we map it really to the OWASP, the NIST and the ISO. And we questioned really ourselves, is this a security risk or not? Because in the OWASP, NIST and ISO, there are many risk mentions which are not directly related to security and we are from security. So I only want to focus on the risks which are directly related to security. And we need to understand this.
So we also later on need to get a good understanding which controls we need to define and how we are going to mitigate these risks. So the next thing what I did with the architects like, OK, this is really good, but then we also need to define a maturity model. And a maturity model is based on the capability and maturity model. So on the left side, this is a simplified version of the maturity model. So we have on the left side of the domain. So think about identity and access security, data and input protection, the runtime and the trust and monitoring.
You're missing here the governance part because that's not actually only for security. So then you have the domains, you have the capabilities and the capabilities are measured against functions and functions from level one to three to five. So with this model, we can actually measure where we are today and where we want to be in the future and which controls we need to implement or capabilities we need to implement to the threats and the risk identified, which I showed you on the previous slide. But also the other risk which we have, which I explained to you in the concept.
Now, what was our approach? Because we are still late in the game, of course, we're always running behind the facts. So what we are doing is like, okay, we were evaluating solutions like JTPT, which has been Philips or Copilot. So I understand it's like, okay, if we are going to buy more AI solutions, what are then the proof points where they need to comply to? So what do we want to secure? And there are already many proof points defined in your company before you buy solutions, but we were looking specific for AI and these we need to add.
Here I show you only a few AI solutions, but we have in Philips many others to think about, for example, with Windsurf and there are many others. Now we have defined our proof points. So if we then know that those AI solutions the business want to acquire or buy are okay from security perspective, then we have the implementation part. And the implementation part is related to our security management framework. In our security management framework, we define our controls, our requirements and our baseline where the solutions need to comply to.
And then of course you have the actual implementation. So we also need to have an application security configuration baseline. So you can measure if and check if those solutions are properly implemented within Philips organization. So with this approach, we get more in control what needs to be done, what in Philips. And we also get a better understanding which controls we need to place.
Now, this is about the roadmap. So what we have done, I'll explain to you the foundation. Now we have the slide which shows like a security vision on it. We defined our architecture viewpoints, the risk which we identified, the controls, the maturity model, also for procuring AI solutions. And then what's currently ongoing. So we are working still together with our responsible AI office to get an understanding really which applications are allowed and which one are blocked. And that's not easy to implement because we don't know which are AI solutions are actually bought by our company.
So first we need to do more investigation because not everything is registered. Before we will enable this policy and we will break things in the Philips company. We also need to define, design a security patterns so we can integrate those AI services and the models. We are publishing the white paper for the AI maturity model. And then also what we want to do, we are currently doing is evaluating all the security vendors. So we understand how we need to mitigate the risk which we have identified.
And according to our maturity model, we also teaming up with Copenhagen Gold to gain insight from analysts of course. So we can then change our vision maybe. And then you have to operationalize. So as I mentioned, blocking the unauthorized access, aligning with the SOC to implement monitoring and logging, support the business as well because they are buying AI solutions. But we also need to support them if they want to secure them. So they're also buying solutions. So we need to help them there. And then of course which I explained earlier is about the MCP.
We need to implement a gateway so we control which MCPs are allowed. And we need to define a template so we can measure if the applications are properly configured. So thank you. That was my presentation for today. Feel free if you have any questions to reach out to me during the talk.
