 All right. Good afternoon everyone and welcome to our next EDW session called build an information architecture for AI with IBM cloud pack for data, which will be presented by Emma is at hand and I'm sorry, Michael hand and Emma Tucker. I'm sorry. Michael is distinguished research leader for IBM and Emma is AI governance leader IBM cloud and cognitive software for IBM as well. All audience members are muted during these sessions so please submit your questions in the Q&A window on the right of the screen and our speaker will respond to as many questions as possible at the end of the talk. So let's begin our presentation now. Thank you and welcome our speakers Michael and Emma. Let's give them some claps. Thanks, John. Thanks. So I'm Michael hind and I live in IBM research and we're going to talk to you about some of the things that IBM is doing around AI governance. If you were here early in the day, we had a session with RBC where we talked about AI governance in general the general topic and now we get to focus a little more on what IBM is doing here. I'll turn it over to you, Emma. Thanks. And I'm Emma Tucker and I've been working with Mike. So he's looking at this AI governance from an IBM research point of view methodologies, understanding what open source technologies we can build as well. And then I've been working on how do we build tools to support AI governance and make sure that you're successful. And so today we'll get a sneak peek into both sides of why each of our teams have been building in this space. So I wanted to set us up a little bit with the IBM perspective around AI governance and trust to the AI. So we view the larger initiative as trusted AI. How do you trust the data you use and the AI that you build using that data? And so it kind of has three components. So understanding ethics and how you should build out your AI strategy and all of that would be surrounded by tooling and the technology that you use. And that's kind of where my personal focus is and then also around making sure you have an ecosystem and open source ecosystem, diverse ecosystem of tools that you are using in order to accomplish governance. And so moving into the next one. And so at IBM, we kind of view this trusted AI as having three different parts of it. There's first, or not first, it's kind of no order really, but trust in data. So that's we've been talking a lot about data strategy, data governance here, but then also trust in AI models. How do you make sure that the models that you build using that data are trustworthy, that they're not biased, that they're meeting your business goals that you've set out for it. And then also trust in the processes that you have built around in the workflows that you have in the life cycle that you have around AI models. And so, Mike, you can take it away from here and talk a little bit about what we've built. So we've been working on four distinct areas, and there's actually other areas as well, but the ones that are most visible right now are these open source initiatives in the first three columns. So the first one is looking at the issue of fairness or bias in AI. There's been a lot in the press, good and bad about various companies that have had issues with bias in their AI systems. And so what we did is we took what the scientific community has done in this space, ways of detecting bias and also potentially mitigating bias. And we put it together in a common framework, a common open source toolkit, which is a bunch of Python code or R code that will be able to measure bias and then have a bunch of options for mitigating bias. This is open source, this is bleeding edge. It is a way for practitioners to give feedback to researchers and also for researchers to feed out cutting edge technologies that are publishing in top conferences and practitioners can try them out. We spent a lot of time on documentation and examples, because we know that this is not necessarily accessible to everyone. And so we want to make sure that we can sort of bring these two communities of researchers and practitioners together. This complements nicely IBM's product in the space called OpenScale, which is an industry enterprise ready platform that allows you to monitor for bias and also explainability. This one here is more of a, you know, cutting edge bleeding edge sort of sandbox where people can can play with ideas and a large a larger collection and diverse techniques. And it has a Slack channel and a Slack channel that will allow people to collaborate and ask questions and learn. So even if you don't want to play with the code, you might want to join up on the Slack channel. Right now there's almost 1000 people that are on that Slack channel communicating answering questions and so on. The second pillar is explainability, which I mentioned a second ago. And that's looking at the problem of, you know, how can you find out if what you're, why your AI model is making a decision and get some insight. And if you think about that problem, it's a very hard problem because explaining for humans is actually hard. It depends on who you're talking to. And so in that toolkit, we also have a bunch of different explain explainability techniques that have different strengths and weaknesses. And again, same kind of thing with lots of documentation tutorials and so on. The next one is looking at the problem of robustness. This is a scenario where an adversary is trying to sort of trick your model or understand things about your model, understand maybe where the decision boundaries are. And there's been a whole research community working in this space of trying to defend from these attacks. And so once again, this toolkit is bringing these all together in the same place. It's very, very popular and you can see there's lots of notebooks and examples and so on. And then the last pillar is what we're going to focus on in this session, which is this idea of fact sheets. This is looking at the space of transparency, which is very much related to governance. This is not an open source toolbox yet. It's a website with a lot of information. I'll walk you through that. And it's going to feed exactly into our product. And Emma will show you sort of the beginning of that in the last five minutes of the session. So if you just bear with me for a second, I just want to go to the website. So you can of course view this yourself. If you just search for fact sheets 360, this website will come up. So what is it? There's a lot of information here. And then the first thing I should answer is, you know, what is a fact sheet? What are we talking about? And the way to think about it as a fact sheet is it's a way of getting transparency for your model development process. So let's say, for example, you just acquired a new company and that new company has an AI model. And you're trying to figure out, you know, how good is this model? What was it trained on? Did we detect bias? What's the accuracy of it? All kinds of information you might want to ask. It would be nice to have some kind of document or some collection of information that tells you the answers those kinds of questions. Right. So a fact sheet is basically that kind of information. And just to make it a little more concrete over here, we have various examples of real models that are all publicly available. And you can click on one and get an idea for the kind of information. Okay. So take a little while to load here. Okay. There we go. So, you know, at a high level, you can see there are these different categories, all different things you might be interested in. And then you can see on the right, you know, this goes on for a while, a very detailed piece of information about the model. This is particularly relevant in industries that have a validation requirement like in financial industries where they'll have a separate role, a model validator that's trying to look at these kinds of issues because they really want to control risk and mitigate risk. And so this is an example of that. But before I go into other examples, I just wanted to touch on a few topics. So the first, you know, am I saying a fact sheet is sort of a bunch of questions and then you answer that and you're done? Or is it something else? And the answer is it's more general than that. It's often we make an analogy to something like a nutritional label where in your mind you say, okay, I get it. That's the most important information about, in this case, packaged foods. In our case, it would be an AI model. But what's implied there is some kind of standard. And we feel right now that there's not going to be sort of one standard that's going to fit all uses. In some cases, you'll care about, let's say, bias. In other cases, you may not. In some cases, you almost always care about accuracy, but the way you measure accuracy may vary from situation to situation. So our view of a fact sheet is this sort of malleable idea of it's the information that your consumers, whoever they want to be, want to see. Right? So that consumer could be a regulator. Maybe you have to convince them that you're doing things well and you're mitigating risk. Or maybe it's actually one of your customers who wants to see how your model was trained because they're concerned about something. Or maybe it's a model developer on your team that is now looking at reusing a model. And they're not sure exactly if it's safe to reuse this model. So they want to know some information about that. Each of those use cases may have a slightly different view on what facts are important. So we feel that a fact sheet can deal with all of those, but you want to tailor it to those particular use cases. And that raises the next question. So if a fact sheet is this sort of general mechanism, how do I go about building one? I don't have these set of questions, these magic set of questions I should answer. What do I do? And that gets to this section here called methodology. And it's basically a methodology for creating a fact sheet. It's an idea that basically says, here's a process that we think you should go through with the appropriate stakeholders to understand, to get to a point where you're actually producing something that someone wants. So if you're familiar with user-centric design, it's basically using that idea. So the first step is to understand who your consumer is, why you're building this fact sheet, who actually wants it, and what do they want? What does the regulator want? Talk to the regulator. Find out exactly what they want. And then understand, okay, that's great. Maybe some information that they want, you can't produce. It's just it's not possible. Maybe it's going to be giving away too many IP secrets. So there's this tension between producing information that your consumer wants, and also understanding what can be produced. And then the methodology goes on, and there's actually a paper that talks about it further, where you're creating a template. A template is basically the set of questions tailored to a use. You go and fill it out and use a lot of iteration here. So there's more detail. There's some dimensions you may want to think about in understanding which of these so-called facts, which are these atomic information about a model you want to record. And you can look at this at your leisure in terms of methodology. The second thing I want to mention is governance. And this is the thing that's quite interesting. And we hear from many, many customers a real sincere interest in this space. And that's the ability to control and relate to that, understand what's happening as you build models. So there's a nice little video. I think it's three minutes here that explains what we're productizing. But I'll just go through this briefly over here. So here's a typical life cycle where you've got a business owner, a data scientist, a model validator, and an ops person. So your life cycle may differ. You may have more roles. But this is kind of the basics. Someone requests an AI model. A data scientist goes and creates it. She sends that to a model validator who does testing and QA, looking at risks. And then if all goes well, things get deployed. Unfortunately, in practice, there's a lot of iteration going backwards. That's kind of a very simple life cycle. And what we see is that each of these personas actually have interesting information about the model development and deployment process. Even the business owner who's not building a model, they're requesting the model. They have some really useful information that can be used by consumers of this model, such as what was the purpose of this model? What's the risk level to the enterprise of this model? And so on. And so our view is you would collect this information from each of these personas, even runtime information, what happened, and collect that in some central place. And then you can actually serve that up in various ways to various stakeholders. So if you noticed above, we had four stakeholders. And down here, we actually have six people consuming. And that's to signify there are other people outside the life cycle who might be interested in this, such as a chief risk officer or a regulator or even a customer. And to make this concrete, let me just go through an example. We'll go down to here. Sorry, this one right here. This is just a snippet of a fact sheet. And what it shows here is sort of four different dimensions, four different ways of measuring the goodness about the model. So one of them is performance, and we have four different ways of doing that. Another is about fairness or bias. Another is about robustness. And another is about explainability. And what you see in these columns is for that same model, basically different data sets that are testing the model on these dimensions. And you see these values and it doesn't matter what the values mean. But what's happening is as you move to the right, going from the data set, test data set from the data scientist to the one the validator used to the actual live traffic, you see things change. And in this case, they don't change too much. But the idea is you'd be able to track this and see if our processes are working well. You know, generally what a data scientist is trying to do is test the model in a thorough way that would be predictive of the model's power when it actually gets deployed. And if you see those values kind of matching up, then you say, OK, I think we've got a process that seems to be working, at least working well right now. And this could be something you track over time. OK, just give me a second here. So there's a lot more information and also links down here to, you know, IBM offerings in this page. There'll be more coming in the upcoming months. And I just want to point out in the examples, there's one over here that's a mortgage evaluated one with a governance slant. Right. So the idea here is this fact sheet was actually created automatically by a research prototype to basically collect these facts. And you can see there's many, many, many, many things. It's that, you know, that abstraction I showed you before with the people. But here you actually can see the details coming out and you can see some of them were collected with our product open scale. And then lastly, before I turn it over to Emma. This website also contains a lot of other information, you know, links to papers, news coverage and is also over 24 hours. If you're having trouble sleeping, you can see a lot of videos that came from from IBM research on this topic of transparency and governance. Just overviews on AI in general, trusted AI in general, things about fairness, explainability and so on. And then finally on the right here, there is links to these those toolboxes I mentioned earlier in case you didn't copy down the URLs, you can get there pretty easily. So I will stop over to Emma to talk you through some of the some of the things we'll be seeing in the product. Great. Thank you, Mike. All right, I'm going to show you how we've envisioned this becoming part of the product of cloud pack for data. So cloud pack for data is our platform for data in AI and includes a lot of different applications within it, depending on your use case. And so we imagine that it's especially if you're a financial services company, and you have to follow SR 117 and set something up around model risk management, where your model validators are kind of a separate organization, or perhaps you're already doing that anyway because you want to have this validating group from the data scientists who build your AI models. Then you might start with this kind of model entry saying, okay, we want to build this model, data scientists will take it, and then we'll go through the validation process. And so right now you're looking at an offering called open pages in cloud pack for data. And this is what we use for the AI lifecycle management of being able to understand exactly what step we are at in the process and be able to capture metrics along the way. And so as part of that, we might have started a review so you can see we have this initial validation process that we've already started. And so a model validator will then want to go into, and Mike had mentioned it, watch an open scale, our offering for capturing a lot of these metrics automatically. And being able to monitor your models in order to evaluate AI model before it goes into production. So in this case, we're looking at this German Chris credit risk model in pre production. So open scale will capture a lot of those metrics that you saw Mike share that came on the fact sheet. Now we believe that a fact sheet is more than just explainability of each transaction, but showing these metrics that you capture in a single evaluation and over time. So as well as who does what is all kind of part of this fact sheet and view of what your model is doing. And so in open scale we're able to see the key metrics that we captured automatically. And this is taking advantage of a couple of those open source tools that Mike had shared in order to capture fairness and explainability, and even to help the bias different algorithms. So I'd be able to dive into one to better understand, you know, this is really low, what's going on, how many counts of risk or no risk have we seen. And then I can even go back and I would be able to compare this to a challenger model because you need to make sure that you are putting your best foot forward and that there aren't any other models that could be doing a better job. So this does look like our pre pod model a model might be doing better but it really depends on your organization standards. If this even meets the bar this is blow threshold so I wouldn't I wouldn't approve it at this point, but it also depends on your business KPIs and the specific ones that are critical for your organization. And that's also the most important part is making sure you choose the right KPIs and metrics to follow for your AI model. Otherwise you might be introducing something that you're not quite aware of or maybe hurting in ways that you didn't expect it to happen. And so the fact sheet is a way in order to capture what's important and all of these automatic metrics that we can do in open scale. But from here a model validator might approve and that would mean that you would update the process within open pages and move it at one point back into production. And so once an AI model is in production, it's best to be able to continue to monitor it over time and be able to capture all of these metrics and see what might have changed. So you can see the threshold went below or the fairness metric actually went far below the threshold that we have set. So we'd be able to get alerted and do a review sooner rather than later and be able to actually click on details to understand exactly what might have happened at that moment and the different outcomes that we got. You can go into each evaluation if it makes sense. But then also we showed you a document that IBM Research had kind of come up with and you can produce a similar report here within open scale. And it's really important that you be able to have kind of something that you can keep in hand because this will show over time so you can create a report maybe on a regular basis and be able to see historically how things are changed and I do have it here. But also oftentimes organizations will have a regular committee meeting where you review the AI models on some kind of regular cadence, whether it be every quarter every six months depending on the classification and impact of the AI model. And make sure that it's still meeting your business goals that isn't showing or below threshold in the bias or whatever it is that's really important to your organization. And so you would be able to share this report beforehand with everybody so that you have a chance to review before understand the training data and the features that are used as well as all these metrics that we've captured and you would be able to then use the dashboard to dive in and even get explainability of each transaction of the model. Because this is what we traditionally think of when we think of explainability. What was the outcome of every single transaction, but we're challenging our customers say that explainability is so much broader than that. It's about the entire AI lifecycle. What's the purpose? What data assets did you use? What metrics have you captured over time right now? What are your thresholds? What's important to you and all the information like that? And so that's what we have today in Cloud Pack for data in order to capture this fact sheet view of all your AI models. So I'll switch it back now. Looks like we have about five minutes left and we can go to questions. While we're waiting, Amber, I was wondering if you could talk about how this relates to data governance. Yeah, I and I've come from the data governance portfolio and I'm working on now what we do around AI models and we're actually trying to use a similar motto. We say know your data, trust your data, use your data when it comes to data governance. And so you in order to get to the AI model, it's really expanding on that. And oftentimes we even see maybe some organizations will start out with having a CDO and some head of data science. But as you mature, you bring that together and the CDO starts to own the data science pieces as well. And so that's where data and AI governance are kind of two pieces in the same pod and that you have to have data governance in order to say that you're governing your AI models, because you need to be able to trust the data that was used that was high enough quality that it wasn't biased. What was used be able to show that it followed the proper data privacy rules as well that you understood it was the right data asset. But then also be able to expand your policies. So just how we have policies that we need to write up around how to use data assets in the organization also have similar policies and glossary in order to put context around your AI models. Right. And I think one of the challenges and I wonder if you can comment on this is that when you're talking about policies, your governance, you need to have something, I guess, concrete. This probably gets into the glossary because I could think a policy might be I should not use data in any bad use cases. I could write that down. But it might be hard to implement. Maybe you can talk a little about that. Yeah. And that's where we're so you might see it and similarly and data governance and so you can explain and be descriptive with your policies. But then we also have ways and cloud pack for data for automating those policies for anonymizing data and following data privacy. And so we're researching ways that we can do similar policy automation with AI models and what that actually looks like on that type of asset within cloud pack for data. But it's really that's where having an AI ethics board within your organization and setting up a clear AI strategy is where you'll kind of nail out some of those details and regulations that are coming up. There was you release their proposal for their regulation today. So if you want to go research that we'll have a post about it on our site. But also, you know, feel free to go and research it because it clearly defines some use cases that you can't use you AI for. Great. All right. Thank you, Emma and thank you, Michael for this great presentation. It does not look like we have any questions for you. But if the audience does have any other questions later, I recommend that they find you on your speaker pages and you can continue networking from there. All right, thanks everyone and have a great day. Thank you all. Bye bye.