The EU Code of Practice: Towards a Global Standard for Frontier AI Risk Management
Summary
Siméon Campos presented “The EU Code of Practice“ on August 20, 2025 at FAR.AI Labs Seminar.
SESSION Transcript
To go into the details a bit about SaferAI, which is the organization I founded that I'm running. SaferAI is a risk management focused organization. We advise governments, AISIs, companies like for instance we co-wrote the G42 risk management framework on frontier safety frameworks we've been doing research on. We've published a risk management framework trying to meld frontier AI practices and risk management which has now been largely improved upon by the Code of Practice. We've also done methodological work more recently to make quantitative risk modeling for AI and cyber offense methodology. This should come in the coming months. And finally we've been doing work rating companies' frontier safety frameworks. As you can see in the rating, this is the result of our rating.
So today I'm going to talk about the Code of Practice, the process that led to it, the outcome and on what principles it was built. I'm going to talk about each of the commitments and finally I'm going to talk about a more macroscopic view, what it changes for the field and how your work or somebody's work can complement it. So let's start with the process, outcomes and principles.
So the way the EU Code of Practice was developed. So the EU Code of Practice is basically a text, kind of standard, even though technically it's not a standard which helps companies comply with the EU AI Act, which is a binding regulation. And it was developed over the course of the past 10 months of pretty intense drafting with four drafts total across three working groups. The process included top leaders in the field such as METR, RAND, et cetera, included all Western frontier model developers. And it was, yeah, so there were like more than 10 workshops with model providers to ensure to take their views and it was run by nine experts in AI risk management. It is overall a highly expert-driven process. As you know, there aren't that many people who know about frontier AI, even less who know about frontier AI risk management. So this was pretty important and I think this was pretty key to what I consider a major success.
So these are the chairs, three of the nine chairs. So Matthias Samwald is a professor in Austria who's been doing good work on evals. Marta Ziosi is at the AI Governance Initiative. Alexander Zacheri was very early on the AISI in the UK. The second set of chairs is Yoshua Bengio, who I don't need to introduce, Daniel Privitera who's been doing work in Germany on AI risk management and Nitarshan Rajkumar who co-founded the AISI. The third set of chairs is Marietje Schaake who's currently a Stanford fellow who's been in the policy space, in the tech policy space for a long time, Markus Anderljung from GovAI and Anka Reuel who's a PhD at Stanford on related topics.
The result is a very comprehensive risk management text signed by leading AI labs. As I mentioned, feel free to open on your computer or on your phone the page code.practice.ai and you can go in the safety and security part. It's very readable and it's going to be the text we're going to discuss. Yeah, it's the full text. There's nothing more than this. It covers the entire risk management cycle including, it includes things like incident reporting. It's been signed by basically all most companies that matter like Amazon, Anthropic, Google, DeepMind, Microsoft, xAI, OpenAI. It is importantly very outcome focused which lets some room for potential innovation in the ways to achieve goals.
There are typically two ways to do standards. One is to say what should you do process or in terms of how you do it, the means. And there's another way which is what are the goals you're supposed to reach and then verify that the goals have been reached. Basically it uses a structure which is a structure of hierarchical commitments which limits gameability. So typically you always have a top level commitment which is something like you shall manage risk to acceptable levels through safety and security integrations and then all these sub-commitments are in service of this and why it is a good idea to do this. A good idea because it limits the gameability. Basically it's harder to optimize adversarially one single measure if this measure is not in service of the top level measure and basically I think it will have visible effects from now on to mid-2026.
It's going to be progressive because you can't ask companies to switch practices overnight. But over time with engagement I think we should see significant effect by mid-2026. In principle the enforcement for new models has started on 2nd of August but as I said it's going to be a progressive process with the office prioritizing certain areas of engagement and not others.
So a major question for any type of regulation or related is the scoping and the Code of Practice is very focused on the frontier. Basically there are a mix of a couple clauses that make this. The first is that it is in the Code of Practice they inserted this notion of safer models which is a pretty broad ranging clause which enables to imagine you're training Sonnet, Haiku and Opus at once and you're going to release the three of them. If you're capable of demonstrating safety of Opus and you apply similar mitigations to Sonnet and Haiku, the text says that basically you will have very few specific things to do on Haiku and Sonnet and most of the effort are going to go on Opus. So this is what safer models is aimed at.
The threshold of compute, which is the threshold for consideration as a part of this regulation is 10^25 FLOPs, so GPT-4 scale or greater. Chairs have been suggesting publicly to move to 10^26 FLOPs, which would be like Claude 3 or greater and which decreases substantially the amount of models that the AI office has to care about. I wanted to highlight that there are very strong taxonomies of model capabilities, propensities and affordances in this text in the annexes. I actually highly recommend it. I think it's pretty state-of-the-art. I don't think I've ever seen so good taxonomies of what are all the types of potentially dangerous capabilities, what are all the types of potentially dangerous propensities and affordances.
Maybe at the end I'll go in the text and show you if we have the time. There are four key systemic risks that have to be managed by default. Like it's not non-negotiable is CBRN, loss of control, cyber and harmful manipulation. And finally there are some transparency requirements which are to summarize, the FSF or RSPs or preparedness framework or however you want to call it, the Code of Practice calls them the safety and security frameworks, SSFs and the model reports which are basically system cards that companies have to provide to the AI office before releasing a model or when releasing a model.
Any questions if you have any uncertainty or confusion, this is your moment because now we are going to focus on go commitment by commitment.
Q: You mentioned something about seeing effects by mid-2026. Does that mean what effects are you expecting to be seeing?
So all the commitments that I'm going to discuss, I don't know. This is my rough guess. The AI office would have to say, but I'd expect that 75% of them would have to be fulfilled by mid-2026 or something like that. At least maybe more. But basically that companies who have not been doing some stuff will have to start doing this stuff by mid-2026 and the stuff in question is going to be the subject of the second. There's been this extremely weird phenomenon of companies cherry picking a bunch of different practices and no company being better than everyone else on all axes. You can see this on risk. There are companies who have persuasion, companies who don't have it, companies who have cyber, companies who don't have it. It's always like the market or something, they pick their own items. And so I think it's going to push the ceiling for everyone and of course hopefully it will push the floor for the companies that are really not doing much.
Q: Is there anyone that didn't sign?
Yeah, Meta didn't sign so far. And yeah, I think they're going to try to optimize the threshold probably as in like, I mean, try to see if there are easy interpretations of the legal text and then the AI office will have, no, that doesn't work so far. For instance, they added a button at the bottom of downloading the model which is like don't deploy in the EU market or something, which would be the easy mode. But the AI office would probably just say that that doesn't work for compliance and then there'll be a back and forth process.
Q: Meta does not sign at all?
So if they don't sign for and the AI office escalates little by little, the enforcement, discussion and actions, then the penalty, I mean, so the value, I don't know, I could see in one year, one year and a half the AI office putting fines of like 4% or 3% of global revenue.
Q: That's the penalty of Meta in general rather than general?
Yeah, of Meta in general. But that's the, even for the AI office, they prefer not to reach that stage. So they will go gradually and not do that overnight and then usually it goes to court, et cetera. So it takes a while. Cool. Any other question?
All right, so we'll now dive into the Code of Practice, commitment by commitment. So the overarching underlying piece is this thing called the safety and security framework. So this is typically like what people now call frontier safety frameworks and everyone has called differently. But the preparedness framework, the responsible scaling policies, et cetera, all these are kind of safety and security frameworks. And so the broad philosophy of the Code of Practice is like you should create a safety framework which is state-of-the-art. We'll see what it means. But basically the idea of state-of-the-art is like the AI office will update every now and then what it means to be state-of-the-art. And it enables substantial flexibility for the requirements to move with the frontier.
Basically you will have to include certain elements in the framework we're going to discuss during this whole session, many of these elements. You will have to implement it continuously along the entire model life cycle and every now and then you have to update it when there are major novelties, potentially we identify a new risk or something. The upside of this approach is that lets companies having substantial freedom over the best ways to achieve goals. So companies can still have agency in how they structure their overall SSF. And it left some possibility for innovating on how to best achieve certain goals, et cetera.
So basically the Code of Practice builds upon traditional risk management loops. What I mean by traditional risk management is that there's this interesting phenomenon where there are many industries that deal with wildly different objects like the chemical hazard, the chemical industry, aviation, nuclear, et cetera. And all these converge towards abstractions that are the same across domains. So there seems to be this general set of practices that you want to apply to manage risk independently from what is it that you're trying to manage. And of course it requires adaptation. But the high level steps are the same and that's the denomination that they use which might seem slightly unfamiliar to you.
So basically on the left the process is described at a high level. So the idea is you start with systemic risk identification. So systemic risk is the denomination for the risks I described like manipulation, cyber, et cetera. And the idea is just like you start by identifying all possible risks that your system could have, then you go into systemic risk analysis, which is, so risk analysis is the process of going in depth into each of these risks and like doing running evals on your system to check whether in fact the risks that you loosely identify are there and warrant any action or not. And then there's systemic risk acceptance determination, which is essentially you check whether after your risk analysis the risk remains sufficiently high or too high so that you have to do mitigations. So risk mitigation, in which case you have to go back to the risk identification loop before moving forward.
It covers as much as it can, the full lifecycle, as in it mandates some evaluations pre-deployment. It also covers like monitoring and incident reporting post-deployment. And yeah, it tries to also be light touch early stage in the training runs where you know that there's not much going on as long as you're testing every now and then the capabilities on like traditional benchmarks like CyberBench or whatever that are easy to run. You can be sure that like there's not too much new novel risk.
So the first stage I described, systemic risk identification, the big change compared to industry baseline. I don't know how familiar are you with industry baselines? Are you a bit familiar with like frontier safety frameworks? And okay, so basically so far there's been quite little in risk identification. Like companies have pre-selected their risks, they test for those risks, but they don't necessarily, or at least they don't report on open-ended testing, they tend to do to identify wider range of risks. And so the goal of systemic risk identification is to both have a good view of the categories of risk you're concerned about, like bio, cyber, etc. So have a good model of what are the most concerning threat models and risk models in those categories and also identify potential risk factors that could change substantially the risk profile of your system.
So one example of this is we used to live in a world pre-GPT-2 where models were not capable of doing in-context learning. And so you didn't have to price that in your potential attack surface for your models. And then suddenly it was not predictable, but there's this thing that popped which is in-context learning and then chain-of-thought, et cetera, which makes it possible suddenly for models to learn on the fly, which increases the attack surface and therefore should require you to change some of your potential risk models.
So basically I think the biggest change in terms of practices that will come from this part is like now there's a baseline risk taxonomy that everyone has to cover. As I was saying, so far labs were very frequently cherry picking. To my knowledge there's no lab except maybe DeepMind that was covering all the usual risks. But even DeepMind, I wonder if they didn't drop one. And the second thing, which I think in my opinion is a very big deal, is so far companies almost never describe publicly except Meta actually the risk scenarios they are concerned about in their frameworks. They refer vaguely to bio threats or to cyber offensive risk, et cetera, but they never say, hey, here's a 10 line description at least of one example of scenario that we have in mind when we are doing these mitigations and trying to reduce these risks, which I think is extremely key to be able to disagree productively.
So it makes it a bit hard to criticize thresholds from companies, for instance, because you do not know what is the grounding of these thresholds. And so one big change which will come from the Code of Practice is that the risk scenarios, like developing risk scenarios to ground evals and thresholds in more concreteness, will become more systematic, should become more systematic.
Any questions so far? So good.
All right, so once you identify the different threat risk models, so both potential new attack surfaces and also the pre-identified risk categories in which you want to have some views on what are the specific risk actors, et cetera, that might be threat actors that may be of interest. There's this part called systemic risk analysis which aims at basically going more in depth into what you already pre-identified. And so I think the biggest change coming from this part compared to industry baseline is that well first doing evaluations systematically with a good methodology.
I'd say evaluations is one of the areas where companies are probably most advanced, but still they do it pretty stochastically. Like Gemini 2.5 was released way before the system card was released. And it's unclear if they run the evals before. If it was just a question of internal reviewing. o3 was released and the deep research, like the deep research option, not officially called o3, but still the model was out way before the system card was out. And there are many examples. There are several examples like this. And so if the AI office managed to enforce successfully, we should see decreasingly of this and companies should pretty systematically have run their evals before releasing their model.
There are some good details as well about what specifically how the evals are run and about methodology quality for having internal and external validity, which I think is going to matter a ton, especially in the coming years with things like situational awareness, which could drastically undermine the value of evaluations.
The second thing, which in my opinion is a pretty big deal, is that the AI office mandates, the Code of Practice mandates to do risk estimation. So trying to give your best guess of what is the level of risk that in this category the level of capabilities you're tolerating corresponds to. And at first they enable semi-quantitative risk estimates, which means using orders of magnitude or intervals rather than point estimates. So saying we expect that if we do these mitigations and we implement this and we stop at ASL-3 level of capabilities, the odds of someone misusing it to kill more than a thousand people are somewhere between like 1 and 10% or something like that.
And so I think this is extremely valuable. I know that some labs have been probably doing it at least internally, but nobody is doing it externally for PR reasons. And I think it's at least extremely valuable for some governments to have that information. I doubt that in the current format this will be part of the summaries because there are still the PR issues. So we the people won't have access to this information probably in the short term at least, but at least governments will have better information, which I think is extremely valuable.
Apart from this, you can see on the right there are the five high level commitments. So companies have to basically gather model independent information. So model independent information is things like, I mean you can do research on how many risk factors of a certain kind there are in the world. For instance, you can run scaling laws to have a sense of like before even starting the training run of your system, having a rough sense of what the level of capabilities it may have, etc. So you have to conduct model evaluations. Third, you have to model the systemic risk. So basically have a more detailed fleshed out scenario that characterizes the risk. You have to estimate the systemic risk. So that I was talking about. And finally you have to conduct post-market monitoring. So things like enable people to report vulnerabilities if they are, check your API or check if there are people doing crazy things on your API like building bad weapons, stuff like this and update essentially you might have to update some stuff based on this.
All right, so this part is going fast because I don't think the systemic risk assessments changes much compared to what companies are already doing. Basically it just normalizes risk thresholds and lets room for potentially quantitative thresholds. Maybe one notable thing is like in principle it asks that you don't deploy your system if the unacceptable levels of risk are reached. And you'd think that this could be a standard given that by definition unacceptable levels of risk are unacceptable. But if you look at the latest Anthropic RSP for instance, there are other companies but I'm going to focus on them even if they are the best overall on their RSP.
Basically Anthropic's RSP has this notion of a short term safeguard. Maybe we can hit our threshold and if our long term mitigations are not ready, we can do this patchy mitigation rather than stopping. And I think my reading is that this would prevent that sort of things like being like oh, we won't stop anyway, but we will do maybe some stuff. And I think there are other companies, if I recall correctly that don't have the stop at all. I think xAI does not have the stop at all. But I'm not a hundred percent sure. Yeah.
Q: Can you elaborate on these like short term mitigations?
So an example of like what's, I mean so yeah, nothing new under the sun here. Mostly making general what companies are, something pretty close from what companies are already doing. Maybe the one detail which matters is are measurable. So far companies haven't really explicitly communicated how they measure the risk thresholds. There are varying levels of details about how they characterize them. For instance, the preparedness framework is pretty detailed. Anthropic in their model cards also sometimes refer to explicit percentage on specific studies, which is valuable. But nobody is systematically saying, hey, when we hit 70% on this, then we will stop this ex ante for all their risks. And this is good that they will have to do it. Hopefully they have done it internally, but just not communicating externally. But I could see some companies not having done it internally yet.
Safety and security mitigation section is pretty simple. As I mentioned, they are very objective focused. So basically you don't have to implement any specific mitigation. There's just a long list of mitigations you can implement. But you have to reach certain goals. And I think the most notable goal that you have to reach is essentially it does not refer explicitly to security level three, but it says something which is essentially security level three. If you have systemic risk, you have to have security level three, which is you have to be basically non-state proof, non-state actor proof. So all non-state actors should not be able to steal your weights, including insider threats.
I note this because recently Anthropic changed the definition of ASL-3 so that it does not include anymore insider threats. And so, I mean, this one is a very big deal. I'm not sure this one is going to be ready by mid-2026 because it's a very big endeavor. But I think it's going to push up a lot of companies who are currently not paying attention at all to security.
Q: Yeah, why did Anthropic say they made that change?
So officially they changed their mind about the risk model. So they said, oh, we updated and we think that being resistant to all external threats is sufficient for this level of risk. I think it might be part of the truth, but I think another part of the truth is that they made the change 10 days before the release of Opus 4. And being insider threat proof is a lot harder than being external threat proof, basically because you are essentially assuming that any of your employees may be compromised, which is a very hard mode to be operating in. And so it requires security mitigations that are probably pretty painful and pretty hard to implement and takes a huge amount of time. So probably they realized they weren't really ready for this and they preferred to not violate their commitment, which is very honorable. And so they changed their commitment so that they made it. I prefer this than them violating their commitment, but I don't like the fact that they put it all on the ground of, oh, we changed our mind of risk model rather than saying, oh, actually it was harder than we thought, something to be insider threat proof.
The Code of Practice is also mandating something like system cards basically they call it model reports, safety and security model reports and there's a bunch of stuff in there. So the governments at least should be better informed, unclear what they will include in the summary. So we'll see if that improves a lot the transparency for non-government people. But yeah, basically. So one of the major very significant change in my opinion is that now model specs are mandated. So I don't know if you know the model specs from OpenAI but it's essentially a set of rules that describe what is the model supposed to do in various contexts towards different types of actors. So for instance a model should probably be usually fully corrigible with regards to its developer. Like if its developer wants to change some rules it should comply with this but maybe it should not accept to do bioweapons for a user or something even if the user asks really hard to.
And so I think this is extremely valuable because this will provide a clear feedback loop on like if you make predictions what your model is supposed to do and then your model doesn't do this then it's pretty clear you failed and so you can improve. Whereas when you don't predict ex ante what you want your model to do you can't be surprised and so you can't improve. I think this is a pretty big deal. Then there should be more detailed justification that risks are acceptable. I think it's also significant because so far it's a bit vibes based or something like people are saying oh yeah, sounds good, you have 10 benchmarks and I think this should lead to some progress.
There should be more clarity about risk modeling which as I said should be a progress for everyone. Currently only Meta is doing a bit in the area, at least sharing a bit in the area. I think the AI office had a really really good idea which is to ask for a small random sample of inputs and outputs of model evals. So you don't want to ask companies for all their evals because there are IP concerns and stuff like this, but to check that it's reasonable and that they didn't hack anything asking for a small random sample like five trajectories or something plus notable trajectories that they observe. I think it's a really smart idea and I think other governments should take note if they ever want to do that sort of stuff because I think it's a pretty light touch way that maximizes like the information.
Q: Know if this is actually like a random sample?
Yeah, that's a great question. I mean as usual, companies can violate the law if you do it systematically, probably at some point will be caught and you will have some hell. But yeah, currently there's no like you can't put a camera or something but companies I think violate the law less than you expect or something. I've been surprised by this but I mean the larger a company is and the more conservative they tend to be in these things. There are exceptions but in the model card there should be some description of safety and security mitigations implemented and how they reach the goal set.
So that's very important actually because for instance Anthropic was initially releasing a bunch of their security mitigations in their RSP which I find extremely valuable. But they were not necessarily explaining why those things are what they made them think that this enables to reach their goal, which is a certain level of security. And I think both of these things kind of matter. I actually think having certainty that enables you to reach the goal is even more important than knowing the specific mitigations you put in place. Like in some ways I value more having someone like Sella Nevo who's an expert in cyber saying yep, I looked at Anthropic security and I think it should reach security level three than having the details of the security.
And so the AI office rightly I think put emphasis on this goal thing which is are we sure that you actually reached your goal? And there's the same question on jailbreak by the way. Companies are claiming to be putting high mitigations currently to prevent bioweapons, but it's a bit hard to trust them. Maybe they're right, but we don't know how they're making these calculations, what is sufficient and I think improving both the clarity of prediction, making fast viable predictions about we want less than one person to jailbreak per month or something and improving the value check is I think very valuable.
And finally I think this is a pretty big deal as well. There should be room for external reports from third parties in the system card. Once again unclear if it's going to make it in the publicly available summaries of the model report. But governments should have the unfiltered opinions of third party evals people which is I think very valuable.
I think one of the sections which surprised me the most overall because it's the biggest change compared to baseline is this part called risk responsibility allocation. Companies will have essentially to significantly improve their internal governance. I think it's a bit like, so if you know the preparedness framework. The preparedness framework had quite a bit of that stuff, but there aren't many other frameworks that have these things and it's unclear if it's been implemented correctly.
Q: Yeah, the first line here is system cards are no longer an option. And I think I missed why that's your wording there?
Oh, because like that's they, I mean that's, once again, you can violate the law, but in the law there is that they have to submit the system card.
Q: You mean that they're like required?
Yes. Okay. Oh, sorry. Maybe it's a French expression.
Q: Oh, wow. It sounds like you're saying like something other than oh, that's so funny.
Oh, I'm so sorry. Yeah. Correct. No, no. So I'm no longer optional. Accurate. Thank you for the live translation, Drew. I appreciate it.
Biggest changes is basically they will have to implement something which is what most industries that have some risk to manage do, like finance or aviation. Most of them have this. So there are a bunch of different things. The first is risk ownership. It's essentially the idea, pretty simple idea that even made it into XAI risk management policy, which is that if you want every single risk to be managed, you should have people who are individually responsible for each of the risks to be managed. And so it mandates that basically there's an executive responsible for each risk and it can be the same executive for several risks. But yeah, there's someone who's ultimately accountable within the org for managing a specific risk.
Then it mandates that there is actually slightly more subtle, but it mandates that there's a risk oversight committee whose sole focus is these risks. So typically in companies, if you take the CEO, he has to balance many different considerations. It's good to have somewhere in the company some body of people who have their word to say, who are just focused on risk and don't have to think about other things because there are pressures pushing in many things. It's easy to miss things if you have many other counterbalances. So it's valuable to have these kind of things. It's the equivalent I'd say of the safety advisory group that OpenAI has set up.
Then there's risk support and monitoring. So that's essentially there should be someone in the company who's accountable for putting in place the risk management process and making sure it works. Basically that's I think probably someone like the head of RSP in Anthropic, for instance. And then there's a second layer of defense, which is the internal audit function, which is these people are not directly accountable for these risk management processes, etc. But they have the freedom and the relevant information such that they can look at things and be like that doesn't work. And do feedback freely inside the companies. And that's pretty standard if you want to read more about this. In other industries there's this thing called three lines of defense which is pretty common and which is a model adopted by many different industries.
Finally there's this explicit system on safety culture. It's a bit unclear whether or not it has teeth but basically vibe wise it's pushing companies to have a culture which is more safety focused and culture who is more prone to allowing whistleblowing. TBD, how it's enforced because it's hard to enforce and text is not very, it was very, in the end it was much weaker than the initial text they had but, and it's a bit hard to see how you enforce it exactly. There are things like tone at the top, make sure the executives embody the safety aspect of the culture and prioritize it highly enough so that people in the company who are in the trenches, actually feel empowered to do safety work, et cetera.
Yeah. Does it have any like whistleblowing requirements? As in like any requirements to like allow whistleblowing or whatever? Oh right. No, no, it's, I think it's one of the biggest failures. Basically whistleblowing was there for three drafts out of the four and it died in the last draft. Probably because it was one of the companies, one of the biggest companies push I guess. I'm not sure but yeah, probably because it was. So it was cut during the last draft and so that suggests that companies really didn't like it.
Finally there's serious incident reporting. I also think it's a pretty big deal. I hope other governments are going to try to leverage this to also have the same information. Basically companies will have to report and respond to incidents and yeah, I mean currently there's no incident reporting going on or not much. There's a FMF announced the voluntary mechanism that they set up internally. But I think this should enable a broader adoption more systematic activity in the space which I think is extremely valuable for a few reasons.
I think the biggest reason is overall having a feedback loop. Basically there are companies, there are industries that progress almost entirely thanks to the quality of their incident report. Like aviation is one such industry. The incident reporting mechanism in aviation has been told to be extremely influential over how it improves safety from the eight years old world. Mostly because each incident and near misses is a good way to learn about your failures.
So for instance, one example from the aviation space is that initially with the engineering mindset, they were very focused on trying to decrease mechanical failures. And actually thanks to massive incidents, they noticed that the first order parameter responsible for most failures were humans. Like humans reacting weirdly and doing dumb stuff or being drunk or being stressed. And so they started putting, thanks to this feedback loop, they started putting a lot more emphasis on actually measuring the human failures and human time of response and how we react under stress and things like that, and optimizing the system such that humans were decreasingly a potential cause of failure. And I think kickstarting this feedback loop in AI should be extremely valuable. I think we can learn a lot from a lot of the stuff that's happening.
And yeah, so basically the ask is pretty simple. If there's a serious incident, you should report it. There are specific requirements about what kind of things. So for instance, if someone used your API to penetrate into critical infrastructure of a country, you should report it within two days. It's like less hardcore, you have more time to report, et cetera. You have to understand the causes of this thing and you have to discuss the response to incidents.
It's actually quite important because I don't know if you remember there was this White House commitments back in 2023 and there was something about vulnerability reporting. And so all companies had set up some email address for vulnerability reporting which was really good. And someone I think last year, earlier this year tested these addresses and checked if people were actually fixing the vulnerability responses. And no, they weren't fixing the vulnerabilities. And so it's good to have the report, but it's also good to have to discuss the responses.
Any questions? Yeah, it's not that bad. All the companies had this vulnerability reporting mechanism and none of them worked. Yeah, all the ones that have signed the White House commitments in 2023 at least used to have, I don't know if I downed it with the new administration, but used to have kind of vulnerability@company.com or something where you could report a problem. And yeah, I remember there was a post testing those and seeing how fast people, if they were reacting and if they were patching it and I think almost none of them were patching it. Yeah, so some of them at least were answering, but I think none of them were patching.
I mean, I'm sure they couldn't get, I think they couldn't get an answer. But I mean, I think the reason is simple. Just companies work by prioritization, right? So what happens is never like companies hate safety or something. It's just safety is not a priority. And so yeah, rather than responding, fixing vulnerabilities, you can do more other stuff. And it's always how these things work. And so yeah, I think that's one of those strengths of regulation is like it ups things in the priorities list basically. There are some companies like xAI who I think where people internally in principle are not opposed to safety is just so laser focused on scaling and doing capabilities that just like safety doesn't happen basically or happens very last minute, etc.
So it changes overall. I think it should transform the landscape significantly. I think some of the largest changes compared to before is. So I think the notion of state-of-the-art, which is in quite a few measures creates a much clearer research-to-adoption pipeline for everyone. So, so pre-Code of Practice, when you were doing research and you wanted this to have an impact, you could either try to get a lab to adopt it, which is extremely hard because if it has any cost, probably it won't get adopted. And even if it doesn't have cost, you have to have the soft power to make it happen.
Now there's this, I think much easier pipeline which is if your work is good and state-of-the-art in the domain, in the relevant domain and it's in the Code of Practice, there's a notion of state-of-the-art and the AI office notices it or you send it to them or something, then probably there are substantial chances that within 8 months or 12 months the AI office could ask it to be implemented basically. And so I think that's a pretty big deal for the field in general.
I think it also should evolve, although not fully resolved, the imbalance in bargaining power between third parties and labs. Like traditionally if you were a third party and evaluating labs, you have extremely little bargaining power. Lab, if you are too nasty or if you're too negative, labs can just not work with you. And even when they work with you, you usually have. You don't ask for too much because you're fearful of being kicked out and sort of stuff. I think this doesn't fully fix that, but it should empower third parties to potentially share more about concerns, if there are concerns and have a more sane relationship in their discussions with labs.
Another area where I'm pretty excited about the impact of this is there are some key subfields that have been ignored, usually because of their inconvenience for labs, very inconvenient in terms of PR. And I think that Code of Practice will push substantial progress on these. The risk estimation is one of these. I know some labs have been doing work internally, but the fact that nobody shares their thing makes that there's been overall pretty little progress. Whereas it's a kind of obvious question that you try to turn the results of your evals into some estimates, or at least approximative estimates of how risky your thing is. And same for risk models. It's kind of also obvious that if you're trying to measure risk, like biorisk or whatever, you want to be able to translate your biorisk eval into some specific risk models. And because no company is sharing their things on it, like at best the progress has been very siloed into a single company and maybe not as dynamic as it could have been. And at worst the state of that is pretty bad even within companies when companies are doing it.
I think it will push both the floor and the ceiling. Paradoxically I think I'm more excited for it pushing the ceiling than the floor. Whereas you could think of regulation in the opposite way. The reason is I think the worst players will tend to try to play hardball and do the minimum they can run away with. And the EU alone at least probably will struggle to fully counterbalance this. I think it's different if some other major countries start enforcing it, but EU alone I think will struggle to get those players to act fully good risk management.
But I think the ceiling is very pushable because no company is systematic because some methods are behind. And so if you create the new methods, even if at some point you end up being less influential for enforcement, the methods exist and so some other people can pick it up, etc. And one thing which has been kind of surprising to me, or surprising in terms of how much it is the case that companies will prioritize this a lot more. I was very surprised chatting with some companies representatives that yeah, just the Code of Practice was way higher in the priority list than any other type of voluntary commitments like the Seoul commitments or something I've ever talked about to them about. And yeah, those companies do care about regulation, about selling in the EU usually. So yeah, that's a pretty valuable thing.
The missing pieces of the Code of Practice, what are they and how to complement it. So one was noted earlier, it was the whistleblower protection. Unfortunately it's evidently because there's this EU separate regulation on whistleblower protection and so maybe it has some teeth, but I'd say probably, basically we should think of it. There's no mandatory whistleblower protection. And so I think other jurisdiction doing that type of work would be very valuable. And the second one is, despite there being some amount of public transparency, I think it's possible for other jurisdictions, including the US to do more ambitious and specific public transparency, like being a bit more prescriptive in what to share, et cetera, where the field scale progress and the areas where the state of the thing can be easily and drastically be improved with a way, with an avenue where there's a direct pipeline for the Code of Practice to implement it is risk modeling and risk estimation, two areas in which we're doing work. So can you chat about it? And yeah, that's it for me.
