Welcome everybody. We're really looking forward to give you our perspective today on how you might turn the EU AI Act into a competitive edge for your company. So, we'll try to give you a few different perspectives on this today and that's why I'm also joined by a few colleagues. So, Ulrik Tunisko is here to give a perspective from the legal side and we'll be joined by Jakob Kamby as well from Karma Advocate and Paul Schmidt. And then Michel is here and in the end will give us his perspective from a more of a practitioner perspective as an AI developer. How it actually is to work with this legislation. Ulrik Tunisko, Ph.D.: Yes. So, thank you guys. So, just a quick overview of what we will be covering today. So, first of all, I'll give just a quick fly-in to the EU AI Act and where we actually are right now with this. Then Jakob and Ulrik is going to give their perspective from the legal side on this risk terminology, which is really core of the regulation. And then finally, as mentioned, Michel will give his perspective as a developer actually working with some of this and implementing it in practice. But first, just setting the scene. So, why do we even have the EU AI Act right now? And I believe one reason is the emergence of generative AI because you can ask we have had AI around for a really long time already. back to the 60s, we were talking about artificial intelligence. But what happened the last couple of years is that we had generative AI, we had chat GPT and a bunch of other applications. And this is starting to blur a little bit more in the lines between what is human work and what is work created by machines. So, this creates a requirement somehow for regulating this. Of course, it also creates a bunch of opportunities. technologies for companies. And when I work with different organizations. We basically see two pathways to value in this. One is the personal productivity. So, all the tools that you have as an employee that make you more efficient in your day-to-day job. And the other aspect is companies that are making completely new products or services or rethinking their business models using some of this technology. And we'll get back to that in a moment because that actually relates a little bit to how the EU AI Act is also implemented. So, just a few words on the act itself. So, it's actually passed already in 2024 in August. So, it's been around for a little while now. And what might be a little bit confusing in this is that it's getting implemented in different stages. And as you see on this timeline, we had a set of new requirements that came into force around policies and literacy. And then when we zoom ahead into 2027, you'll see the full regulation coming into force. So, of course, there's no time to wait. You should be started already now looking into what this means for you. And you should be preparing for the full implementation in 2027. All right. So, what is it actually, this EU AI Act? So, one way to explain it at least is that it takes this risk-based approach that we are going to hear a little bit more about later. But I think when I work with organizations, I see this as a huge benefit actually to follow this and create this inventory of all the different AI systems that you have running in your organization. It also sets some requirements to how you should educate your employees in safe and ethical use of this. And overall, it's going to give you a much better risk view of what risks are your organization exposed to with the different AI systems that you are maybe already putting into place or planning to put into place over the next years. And if we relate it to something, we might know a little bit. Because this AI Act is actually inspired by a lot of existing legislation that is out there and that we as EU citizens are used to have as kind of a safety net around us. So, one is the product responsibility. So, one is the product responsibility and the other is the safety responsibility towards employees. So, if we start with the product responsibility, then me as a consumer, if I go into a store and buy a toy for my kid, I kind of expect that it doesn't have toxic chemicals in it. And this is kind of the same logic that's applied to the EU AI Act. So, if you are a developer of AI systems, that is being exposed to consumers, there's an expectation that you ensure that this product is safe and not harmful to use. And the same goes for your employees. So, when you develop these internal productivity tools that make employees more efficient, there's an expectation in this EU AI Act that make sure that they have the right education and they're trained in the right way so that they are not being exposed. So, to some kind of risk or harm from using these systems. So, to me at least, that makes total sense and a lot of good inspiration here on how we might build AI systems in a better and more ethically correct way. So, I mentioned this risk terminology is really core and that's why we dedicated a certain portion of this webinar also to deep dive into this. And for that, I would like to invite Julek on stage and a little bit later we'll be joined by Jakob Kampi from Paul Smith, Kamauk and Kaden as well. Thank you for that, Nikolaj. So, as Nikolaj mentioned in this next part, we will dive into the so-called risk terminology and methodology of the EU AI Act. But before we do that, I would like to establish a few basics. As such, I will shortly cover purpose of the Act, the main features of the Act and then we will move into the risk categorization. Then Jakob will dive into how to actually manage this thing in real life. In short, the purpose of the EU AI Act is to ensure that AI is safe, credible and ethical. The EU AI Act is kind of special because it's fairly rare that the EU bases legislation on specific technology instead of sectors, for instance. And as we have demonstrated on specific technology instead of the EU AI Act. And as we have demonstrated on this slide, the EU AI Act interlinks with a lot of different laws and standards. For the sake of time, I will not go through all of them, but a few worthy mentions are the GDPR, the NIST II that most of you have likely heard of by now, foundational human rights, etc. Another good example is the new ISO standard, 42001, which directly overlaps with the EU AI Act when it comes to governance and management of AI. So in other words, this new Act actually happens within a web of other legislation and standards. Moving on, the main features of the EU AI Act is that it affects first and foremost the entire value chain. That means everything from the organizations providing and building the AI systems and tools all the way to the consumers and users of those systems and tools. Secondly, it is what is called human-centric. Secondly, it is what is called human-centric. That means that its focus is on ensuring that AI creates results that are beneficial to society as a whole. For instance, that could be in terms of security, privacy, justice and environment. Thirdly, it is what is called human-centric. Thirdly, it is what is called human-centric. Thirdly, it introduces this requirement that Nikolai mentioned before called AI literacy. This means that people using AI must have adequate skills to do so safely, responsibly and ethically. And then fourthly, it is risk-based. And as such, the EU AI Act introduces four risk levels, as we have also demonstrated on this slide. Unacceptable risk, high risk, limited risk, and low risk. And before we dive into what actually constitutes or what kind of AI goes into each risk level, I want to say a few words about the importance of these risk levels. In essence, they are essential because they decide what specific requirements are imposed for which kind of AI. And Jakob will elaborate on that in a little bit. When defining a risk level, generally, the Act looks at how harmful the specific AI can be to society. So let's try to dig a bit more into that. If we start at the top of this pyramid that we have illustrated here, what is unacceptable within the meaning of the Act is AI that is a threat to foundational rights, fundamental rights. That could be social scoring, exploiting vulnerabilities, and biometric profiling of individuals, as examples. Moving down a rung on the ladder. Moving down a rung on the ladder. The next category is high risk. That could be, for instance, critical infrastructure and impact on fundamental rights. For instance, transports, asylums, other critical parts of the society. Within limited risk is where we will likely find most of the everyday use of AI, so to speak. That constitutes, for instance, generative AI, large language models. This also includes chatbots, chat GPT, things like that. And then within the low risk category that falls outside the purview of the Act. We have other types of AI that could be AI-empowered spam filters, calendar tools, computer games, and apps. And also AI, in some cases, where there's no personal data. So now having given you this very quick overview, I want to invite Jakob to the virtual stage to help us translate these risk levels and requirements into something that is actually manageable in practice. And Jakob has already been introduced by Nikolaj. But just to recap on that, Jakob is a partner in the law firm, Paul Schmidt, and is specialized in, among other things, AI and data protection. I hope that's a good enough introduction, Jakob. But please take it away. Thank you, Uleg. And thank you. Great to be here. And hi to all you guys in the studio. So I'm invited to talk about this slide. And as has been said in this webinar, when we look at the AI Act, one needs to recognize that this is a product-oriented act. Not like GDPR, which has rights for the data subject, not like GDPR, which has rights for the data subject, the AI Act aims to ensure that the AI taking into use in the union should comply with certain product requirements. And as you said, Ulrich, the way that the legislators done forward with this act is we have risk classes. So we have some practices that are prohibited, banned from being taken into use. Most of them sort of give the, it's sort of obvious that you don't want to take them into use. But some of them would need interpretation. So for most of the users of AI, it will be very obvious that you don't want to take them into use. So what is left? The high risk and the low risk. What one needs to understand is that most systems taken into use are low risk. Actually, the act has found that most of the AI that you want to put into practice in your business will be low risk. However, some systems are defined as high risk and not like GDPR, where we have risk assessment to define whether something is high risk. In the AI act, we have a system is high risk. And what do they put on this part of high risk? It's two levels. One is the products where AI is built into certain products that needs to comply with other EU regulations. For instance, medical devices, for instance, for instance, for instance, for instance, and where they either control or do act as a safety feature in that product. The other category is certain AIs that can have a significant impact on services, as you mentioned already. And for these high risk systems, there's a body of very thorough requirements going into, as the slide says, documentation, risk management, management, human oversight, human oversight, and also you have the compliance framework where the vendors, the providers would have to document their compliance. So for high risk, there will be a lot of requirements and the users, the deployers will have to assess these compliance requirements and documents and put it into practice according to that. Thank you very much for that introduction, Jakob. And I have a few questions in terms of how to actually manage this. So looking at these requirements in practice, and from what I hear you saying is that high risk is where the bulk of the work will be. How could organization manage this thing without creating too much extra bureaucracy and building it into their existing frameworks? You mentioned the GDPR frameworks? You mentioned the GDPR before. Do you have any thoughts on that? Yes, of course. Great question. And obviously, many organizations strive to not build another compliance animal, a big animal in the forest. Well, what most organizations will start on is defining how much high risk systems do we have in our store, in our business, and what kind of systems encompass AI. Because as going forward, many products and many systems will have a level of AI in them. And obviously, we need to build a roadmap to ensure that we have a clear picture of where do we use AI and what level of risk does that AI have. And as you mentioned, going forward from there, you can say, what do we have of existing compliance framework, either the ISMS as the information security, management system, or the ISMS as the information security management system. So you have privacy-oriented, where you have privacy-oriented, where you have the ability to produce data protection, impact assessments, and so on. And for the product-oriented businesses, we have some product safety and quality assurance management divisions that are used to complying with the EU regulation on products. So many organizations go forward in two steps. One, identify what kind of AI do we have? and what risk level are we on? And two, what do we have of existing compliance frameworks and can we put the requirements into the relevant places? That's a very good perspective, Jakob. Thank you for that. And I think we have time for one more question before we hand the mic over to Michel. So speaking of how to sort of implement this in practice, do you have any thoughts on what could be good metrics to use to ensure human oversight over high-risk AI and any good tips to get started on that if it's not something that you're measuring right now in the organization? That's a very important question. Human oversight is required for the high-risk systems, but even when we talk about low-risk systems, we have to have human oversight. In the GDPR, we have rules regarding automated decision-making, and if we make automated decisions that impacts the data subject, we have a body of further requirements for doing that. So we have to have a clear picture of when we do automated decisions and do we have the human oversight. some of the elements of human oversight we know is that you have to look into competence of the people doing the oversight. You have to look into the training of the people doing the oversight, and you have to consider technical limitations. Technical limitations would be to prompt the user or to restrict them from doing something without presenting the oversight. And the training and the competence obviously goes into what kind of people's do we have in the organization doing the oversight. And what kind of training do we provide. And obviously, if you miss out on the training or the people perspective, you will have the risk that you are suddenly doing automated decisions or not complying with the requirements of doing the human oversight. Thank you so much for that, Jakob. And that actually includes our section. And now I will pass the word on to Michelle. who has been knee-deep in AI implementation and will give us some more practical tips. Thank you, Ulrik. And as you said, I will try to present a pragmatic approach for us as AI developers on what this means for us in practice day to day. So for this, we want to look into operational resilience for AI. And this builds on top of the development frameworks that we already have as developers. But then also there are some things that come on top. First thing that we see is here all the way to the left, the business impact assessment. So what happens if your AI system breaches confidentiality, integrity, or availability? On top of this, second step, AI criticality. So where is the AI essential? And then what happens if it fails? The third step is the risk assessment. And we heard a lot from Ulrik already. So we're not going to deep dive into that too much. But then the next step is the operational and technical resilience. So having fallback options for us on the tech side, but then also for the business so that they have a business continuity plan when AI solution fails. And lastly, transparency and training. And lastly, transparency and training. We already heard a bit about that. And this is a huge part of the act. But let's jump right into the sub points. So business impact assessment. You can think about this as your launch pad for your AI projects. It is very essential for identifying and evaluating the potential effects that the solution you're building can have on your organization. But this also includes solutions that you're building can have on your organization. But this also includes solutions that you buy from the vendor or supplier and not just the ones that you build in your own organization. We heard that already as well. So the question that you answer is, can the core business operate if the tool fails? The first domain that we have to look into here is the confidentiality. So we want to ensure that the sensitive information and AI outputs are only accessible to those who are authorized to see it. So authorized to see it. So in the assessment, you will answer questions about the potential loss of competitive advantage, but then also the perception of your organization in the public image. The second domain is the integrity. So here we want to ensure that the information we're displaying is accurate, consistent, and trustworthy, and that it cannot be altered without any authorization. So it is about the ability to make the ability to make the correct decision and the legal requirements and obligations that you have to other stakeholders. And that will be also part of the questions in this part of the assessment. Then we have the availability. And here we want to ensure that the authorized users can reliably access the information and the systems when they need them. So we have to talk about possible financial loss and the day-to-day running operations. And all the next steps in the act that we see here are built on this business impact assessment from a practical view. The next one is the AI criticality. Here we want to map where the AI underpins business processes. And then we want to judge what a failure could mean. Is there a threat to the operations? Could new vulnerabilities be opened up with this failure? And then we want to evaluate how dependent the operations the operation is on the certain AI system. So we want to ask where is AI essential? What if it fails? And that will be the critical list you will have to look into. Third step, the risk assessment. And as I said, we will not dive too deep into this one now. So now operational resilience on the tech part, but also on the business part. As developers, we already have solid development frameworks. We already have solid development frameworks. You may know it from machine learning operations or also your Gen AI operations. And these frameworks are good and we should keep them also. On top of that, the act requires us to have a solid layer of governance and compliance though. So the normal procedure, we experiment, we train, evaluate, we deploy our systems, we implement transparency measures and continuous monitoring. And then we have the feedback loops with also our humans in the loop. But on top of this, we want to have early warning systems that point towards the operations teams so that they know what happens if a solution fails and then can have fallback options once on the tech side and then also on the business side. What is their continuity plan if a solution fails? And then last but not least, again, transparency and training. It is important. It is important to disclose of when and how AI is used. We have to explain the AI-driven decisions. And we have very transparent and open communication about the data sources we are using and also what are the system limitations. So for you as organizations, it's important to get your stakeholders in early in the process, have a good engagement, have accessible feedback mechanisms to show what might be the problem. be going wrong in the system, be going wrong in the system, be going wrong in the system, also from the organization, and then have the ongoing education about the different AI capabilities. So again, it's a big part of the act. It is about bridging the gap between the technical solutions and then on the other side, it's business users. And with this, my part ends and I will hand over to you, Nikola again, for the next steps. Thank you so much, Michel. And I really hope this has given you a few good perspectives on how the EU AI Act can actually be a benefit for you and your organization and not just an annoyance. So we hope to have presented you the perspective that it's going to help you follow basic guidelines and best practices for developers. We hope it has helped you understand how this can can build an understanding of the risk landscape that your organization has and the exposure you're facing with implementing different kinds of AI systems. And finally, it should also give you a framework on how your employees should be trained and educated. And I can see we have a number of questions in the chat. Unfortunately, we don't have time to take them in this session, but we will get back to you on those questions afterwards. And also to mention the slides that you have seen today will be shared with all of you. And if you're curious to learn more about this topic, we actually have a couple of really good articles as well on our website. You can go in and check out and you see the first link is on this slide and we'll share all of it with you afterwards. And then, of course, you're always very welcome to reach out to any of us on the slide here, both us from the implement side and Jakob from Paul Smith, Karmel, Albuquerden. Thank you so much for tuning in today. Have a lovely Wednesday.