Managing Data and AI Security Risks With DASF 2.0 — and a Customer Story

Summary

• DASF 2.0 framework: Databricks evolved its AI Security Framework 2.0 with input from OWASP, NIST, Gartner, and Fortune 100 companies addressing enterprise AI risks.
• Healthcare case study: CLEVER GenAI pipeline processes 1.5M clinical notes daily for veteran care while adhering to NIST 800-53 security controls.
• Cross-functional guidance: The framework provides security roadmaps for data engineers, AI practitioners, governance teams, and security leaders.

Managing Data and AI Security Risks With DASF 2.0 — and a Customer Story

Talk by Arun Pamulapati, Principal Security Engineer, Databricks ; Joseph Raetano, Director of Artificial Intelligence, US AI
The Databricks Security team led a broad working group that significantly evolved the Databricks AI Security Framework (DASF) to its 2.0 version since its first release by closely collaborating with the top cyber security researchers at industry organizations such as OWASP, Gartner, NIST, HITRUST, FAIR Institute and several Fortune 100 companies to address the evolving risks and associated controls of AI systems in enterprises. Join us to to learn how The CLEVER GenAI pipeline, an AI-driven innovation in healthcare, processes over 1.5 million clinical notes daily to classify social determinants impacting veteran care while adhering to robust security measures like NIST 800-53 controls and by leveraging Databricks AI Security Framework. We will discuss robust AI security guidelines to help data and AI teams understand how to deploy their AI applications securely. this video will give a security framework for security teams, AI practitioners, data engineers and governance teams.
Databricks Named a Leader in the 2025 Gartner® Magic Quadrant™ for Data Science and Machine Learning Platforms: https://www.databricks.com/blog/databricks-named-leader-2025-gartner-magic-quadrant-data-science-and-machine-learning
Build and deploy quality AI agent systems: https://www.databricks.com/product/artificial-intelligence
See all the product announcements from Data + AI Summit: https://www.databricks.com/events/dataaisummit-2025-announcements

FAQs

What is the Databricks AI Security Framework (DASF 2.0)?

DASF 2.0 is an evolved security framework developed with industry experts (OWASP, NIST, Gartner) to address risks in enterprise AI systems. It provides guidance for deploying AI applications securely at scale.

What is CLEVER and how does it use AI securely?

CLEVER is an AI-driven healthcare innovation that processes over 1.5 million clinical notes daily to classify social determinants affecting veteran care. It implements NIST 800-53 controls and DASF framework principles to maintain security and compliance.

Security framework for AI

This video presents the Databricks AI Security Framework (DASF 2.0) for managing AI-specific risks across the entire lifecycle. The framework includes security best practices, threat modeling approaches, and deployment guidance specifically designed for AI systems operating on the Databricks Data and AI platform.

Security framework for agents

This video shows how the Databricks AI Security Framework extends to agentic systems, addressing risks specific to autonomous AI agents. The framework ensures agents operate securely within defined governance policies while maintaining the ability to access data and make decisions autonomously.

Who should care about AI security frameworks?

Security teams, AI practitioners, data engineers, and governance teams all need to understand DASF. This video bridges these disciplines with a common language for AI risk management.

Full transcript

We'll slowly get started. I think we are at time. All right. Um before we get started in a minute, uh I'll do a quick poll. Um in the room, tell me if you are raise your hand if you're a data engineer. Excellent. Wow, that's great. Um data science model developers. Good. Right. Um anybody who is into infrastructure deployments, production, right? And the last one is um security, governance. Nice. You are my people. All right.
I'm in security. I was u more into ML AI uh for a long time. And this talk is actually the goal of this talk is to bring you all together have provide you a common language and uh make sure you know when you talk about certain things um you know what you're talking about and the other team understands. Um so that's the intention. So we'll we'll uh get officially started. We this is the poll I wanted to do and we are going to touch on all these um areas of AI and uh we will be going deep and um the talk is going to be more uh to provide you with the content not necessarily help you understand everything but make sure you have the resources when you go home back to your work and hopefully next week um you would have enough things to kind of you know kick off some uh discussions in your team in your with your team or like you know plan some projects and see how you want to assess security of your AI system and then hopefully you know improve security right ultimately um when we talk about data intelligence u in a in the context of organizations like yours it is putting your data which is one of the most valuable asset that you have in front of your data science which is either a model or your you know your own homebuilt ML uh you know model uh which is going to be more of your digital twin and then combining those two things and getting value right so without putting your data in front of these models um you are not going to get the data intelligence you're going to get general intelligence so it's going to tell you what it would tell your competition it would be the same answer that it would give you like when you are talking about models but when you put your data in front of these models you're going to get the specific answers that you are looking for and hopefully would be helpful for you right so we will um get started here with I am um principal security field engineer at data bricks I've been with datab bricks for seven years doing primarily u you know ML sec ops and helping customers build on data bricks in a secure way both from the general general platform perspective but also with AI security.
With me is our esteemed customer. Introduce yourself. Hey everyone, I'm the I was the AI lead at the VA on the summit platform uh where I integrated and completed the uh first generative AI pipeline at VA and got it successfully into production. And uh actually been part of our work group as uh going into the content and he's being humble. He helped a lot on the uh compendium that we delivered to everybody to use which is um in that in that compendium he helped with list 853 mappings uh which he'll be focusing on.
So as part of the work that we did about um you know over a period of one and a half year um we built something called database a security framework. The motivation for this is to produce something for community. Um I think it's Google doing the scripting which may be helpful uh at the bottom. I I just saw that. Um so it's a community help uh by community. uh we within the data bricks we have about 30 people contributed to this work and outside data bricks I would say another 40 50 people either as a reviewer as a contributor including himself uh contributed to this work.
The goal was to produce something that is u generic enough for anybody who is practicing data and AI can take advantage of this. Of course, we are datab bricks. So, if you happen to be data bricks customer, we leave you with the specific controls um with datab bricks documentation links or tutorials or configuration so that you can immediately jump on and check your environment or make sure somebody in your team knows about this and they configure in a way or practice in a way that is prescribed by us.
Uh if you're using data bricks for uh data and AI, right? So all of the work that we did is publicly available. It was published a few months ago. Uh the first one is the white paper itself. It'sund 105 10 pay 110 page uh document. Um my joke is that if you you can put that in in front of notebook LLM, make a podcast, listen to it on your commute. Um but the most useful one would be executing line by line because we distilled that u large white paper into um a simple easy to understand and uh something to practice.
But the most important one is the compendium itself. It's a Google uh publicly available Google sheet. You can find the link from the white paper to that. You can download that. It is also available available as um Microsoft 360 document. If that is what you use, you can download that. And in that everything that I'm going to talk about, we put like an we go at length about each of the risks, controls, descriptions about those and mappings which I'm going to show you briefly in the document.
Right? So as part of u the framework we wanted to give a map a picture of AI because when we talk about AI security you hear like you know a lot of um noise around there on Twitter uh sometimes you know somebody publishes a PhD paper saying that they kind of you know compromised a model that is all well and good it's important that somebody is doing that but when it comes to enterprises is you need to understand what are the risks that are relevant with respect to an AI system not just a specific model that you may or may not be using and what you should be doing with those uh how you should be addressing those risks right so what we did was to make all the different types of teams that I kind of earlier did the poll on um how should data engineer think should think about what their responsibility is as part of being this in this AI system What should be the um you know data science teams the uh people who bring models into their environment um what they should be doing what should be devop dev sec ops should be doing and also what should be the admins and security teams the governance team should be uh thinking about as they implement so we identified uh 12 different components that makes up an AI system which I'll show you in a bit and then we with at each one of those 12 components the blue numbers are uh the component numbers we identified uh specific risks.
So these risks are by studying different standards like was LLM top 10, NIST 853, CS N CSF 2. 0 Whoa. And um might class might attack. We took everything and then we started placing them right like you know where where would this risk belong and then we documented the risk. What is the implication of having that risk? What would be even like if you're doing if you're an assessor what should what would be the business impact if you leave that risk in the system and then you can even work with your risk team to figure out like what would be the financial implications if you have that risk in the system.
And then that's where most of the standards and um you know I would say um recommendations kind of take you up to but as a practitioner as having hundreds of thousands of customers practicing you know data and AI with our platform we also want to give you controls like you know what what controls would mitigate those risks if you deploy those in a in a in a way um you know how to reduce that risk is the purpose of this paper and we identified 64 controls which are also available able as part of the paper.
Right? So this is the uh the comprehensive kind of you know high level I would say picture of AI where everything for the AI starts at the um at the right or on on your left there where you start with the data you do data prep. You know this is where your data engineers come into picture. they will be taking in taking in this data and then extracting uh the columns and making sure they it's clean and you know extracting features and then they create data sets or like you know clean files whatever that is as you produce you need to catalog them make them available um you need to govern them label them and you need to uh have some kind of um you know security controls um masks masking of the data um and you need to have those in a in a way that it is discoverable but at the same time it has the necessary um authentication and authorization.
So that is the first group which I talked about like as four blocks into AI system. So that's where the data engineering side of the responsibility kind of relies on right. So when you have that data then you start thinking about you know thinking about AI. So this is where you either build your custom traditional ML models from the data or you take the data do some kind of rag and use some external models that are available either um as an endpoint like an at Azure OpenAI or you know um other like anthropic models or you may use one of the foundational models that we curated and red teamed and make make them available as part of our databicks platform.
So you get to those models and you put some data in front of that model, right? And then you make this model as a service as part of your serving infrastructure, right? You're going to either bring that model, build that as part of your own uh deployment and make that available to the applications or you will just call a model endpoint that is hosted by somebody else. Right? Once this model is in operation or the model agents are in operation in your infrastructure, they continuously are going to need the act access to the data one way or the other to make most recent fresh decisions on your um on your own enterprise data.
Right? That is going to come in the process in the form of either rag or you're going to the agent is going to call in to do a vector search or it is going to call into uh a a catalog to a quer do to do a query to answer certain questions. So there is continuous um you know conversation going on between these AI systems and the data systems that you have. So in this process as you interact with these through applications and users on the on the on your on your far right here all of that needs to be monitored.
You need to have some kind of auditing happening on your AI system. Who called what when kind of prompt was sent in? what kind of response went in and you know everything in between that's happening like if there is some kind of um you know authentication failure you want to log that uh because maybe they don't have access they're trying to u you know reach into that right so that's your monitoring side and as these systems are being used there will be some feedback coming like you know somebody is giving continuously a response to a prompt saying they like this uh response or not or somebody may be teaching the AI to do something else.
So that needs to go back as uh the reinforcement learning with human feedback back into your um data set, right? that becomes a fresh data that again goes back into the AI so that like an AI is becoming um you know improved and better over a period of time and you're going to host all of that on top of some kind of you know platform with your own um CI/CD process and your own DevOps um so that you have these operations that are happening on that platform.
Okay. So this is kind of high level picture of AI and at each one of those 12 components that are in blue we you will see um the actual cataloging of risks that we did. So the number next to that blue number which is in an alert with you know 11 in component one and number number of risks in uh component component number two as four. These are the risks that are identified by various standards um that we wanted to make sure are well known to our customers and they are going in with Isopen.
You may and as you can see it kind of stands out. It was not um you know an accident. It was not something uh we we uh you know planned in a way that these numbers but as you can see at both ends you have the higher number of risks. So as the data is flowing in your enterprise is either gathering the data from other organizations like you know if you are you know a um you know loan processor you may be getting credit scores from third party right what if there is some data poisoning there or like you know you are crawling some uh data sources so at the at the at the source of the data there is um there is lot of you know possible compromises risks that can happen.
Um, and people are usually keeping those systems a bit more loose as opposed to the systems in the middle. And then on the other end where you are actually exposing your applications, there is again um higher number of risks uh because there can be prompt injection happening from the from the inference requests here uh on the uh inference side on the integration side. Um there can be abuse of credentials happening um or like you know there can be um you know privileges that are not set right where some of the enterprise applications um that should not be h giving giving access to um some of the employees maybe they are exposing because those endpoints are staying in the plane um plain side or maybe uh you don't have um you know some kind of perimeter security like u you know IP list or private link so your endpoints are there open in the internet.
So you need to think about how you protect those. So as you as you can see those risks spread across but the risks tend to be more on the on the either ends of the a system right. So you may say like you know okay I understand they are there but what is the full comprehensive list? This is the list of risks that we cataloged and in the Excel sheet that you would be able to access any anybody can access those uh it's publicly available document that we delivered as a compendium at each one of those risks you would be able to um identify who else is talking about this which standards are calling for you know um educating yourself with about these risks you will find that and um you can see the ones in the dark color are like you know traditional cyber security risks.
These are the things that you should be thinking of anyway. Whether there is AI involved or not, if you're doing business intelligence, BI applications or simple ETL, you would still need those controls or you would still need to think about those risks, right? And the one in the ones in the red are influenced by the novel risks because of AI getting introduced into your platform. So you need to think about some of them may be like you know in the new form like prompt injection.
We are familiar with SQL injection but it takes different shape. So there are few items out there which are taking different shape but may be known to uh you in a different shape and form. So but the important uh aspect the reason of this listing is that first we need to know comprehensive list of risks. Once we know what risks are there and where they may appear and how they are relevant to your use of AI like for example one of the things you would see uh in the list is model theft.
Um that is something subject to like if you build the model if you if you pour in your uh you know intelligence or your team's process to build that model and if it is your enterprises propriaratory model then you need to worry about model theft right but if the model that you are think that is in discussion is um you know anthropic model in the shared responsibility you don't you don't need to worry about if that model is going to be stolen by somebody that is the respons responsibility of Anthropic.
You need to be concerned about the credentials that you have for your organization to access Anthropic and those credentials are not stolen. Those credentials saved properly or secured properly and used by right people so that you don't pay extra money for those credentials being abused or being shared and are being um are lost. Right? So not every risk that is listed here applicable to every use case. So you need to think of how you're using AI like you know which risks apply to you based in the shared responsibility model and which risks are applicable to um the vendor and our different team right so in the worksheet we mapped each one of those risks to the way you use AI like you know is it pre-training of your own ML or it are you using external model so we kind of tag them so that you can filter down on those on those risks Okay.
So now this is the important piece. Now that we understand those risks, how do I um implement the controls that are necessary to mitigate those risks? Right? So as you can see in the list by just by looking at the name, there is no data bricks product or data bricks capability in the control. The reason is we wanted it to be applicable to anybody who is practicing AI. Single sign on setting up single sign on multiffactor authentication is something that we call on the data and AI platform and a data and AI system.
How you implement in data bricks is up to our documentation. How you implement that in another uh platform is going to be based on that vendors. But the important piece is do you have the necessary authentication authorization controls on the AI system and it goes all the way to AI gateway uh and so on and so forth. Right? So that the idea is to give you the comprehensive list of controls and the each one of those risks that you saw in the previous u slide is mapped to respective controls and these are the databris uh platform capabilities that are going to help you um implement those controls that you have seen if you happen to use data bricks if you're not using data bricks you should ask your vendor like you know hey I am I want to deploy a specific control can you help me find you So how I can arrive at a a specific control right?
So these are like you know by using certain u platform capabilities number of controls that you get and uh again for each one of those controls we in the worksheet that you are going to walk away with you would find documentation links so that you know what we are specifically talking about uh for each one of those controls. So to summarize with the for database a security framework you will be able to start with a use case and then look how you're going to you know what how you're going to basically use AI like are you doing predictive ML are you doing foundational model so on so forth and then you can filter in the worksheet what what specific risks that you should be thinking about right so that is going to be the risk that less than 62 to the max like you know risk that we documented.
Once you identify the risk hopefully maybe there there are 40 or 35 risks that are going to come because based on how you're basically practicing uh or using that specific AI model. Now you're going to look at what controls would mitigate those risks. So you would be able to identify those controls and then find the documentation links and make sure if they're out of the box from datab bricks you can basically you have them.
If they are configuration you need to go and make sure you harden the workspace with that specific configuration. If it is implementation you need to identify how to implement with the documentation that we provide and make sure you kind of understand that uh those specific controls that we talk about. Some are ML process, some are basically simple way of using databics platform and then you will be able to deploy those controls.
So with that I'm going to um give mic to who actually helped uh a project by being part of DF and also by using this at his um at veterans affairs. So he would walk you through the process of how they met NIST 853 control um and then summarize the process that they followed so that if you are in similar situation or similar environment you will be able to learn from that and hopefully be able to practice that. Yeah, for those just joining us I'm a computer scientist and AI researcher.
Um, I led the effort on DASIF to map the NIS special publication 853 controls uh with DASIF and I use that as an overlay to help where NIST lets us down. And what I'll do next is walk through uh the 12 steps essentially. I I chose you know just one part of the each 12 just to talk through it and I I look at it through the lens of a federal assessor. So usually um you know these are high stakes environments department of defense the VA is a high stakes environment with veteran data healthcare data and the assessor comes in and they'll ask specific questions if you're following the cyber security guidance and you have to show evidence so it's all evidence-based.
So what I did when I did this mapping was I looked to see where NIST was strong like with access controls and then I found where DASF really shined and for the last several years as an AI lead in the a in the AI space for federal government I just found it increasingly difficult to take executive level input about guidance on you know the strategic level guidance for AI and implementing it and then getting it right down into the tactical uh controls that we needed and this is where DAS have really came in to help.
So let's walk through some of those. All right. So again, um, the clever pipeline, the clever pipeline, we chomp on around 1. 5 million TIU notes a day. And those those notes are used for um to to identify 20 types of clinical events uh including those that impact mental health, uh, medication safety, and broader social risk factors for veterans. Um it it's an enormous task. I I want to give a big shout out to and Dr. who led that effort.
Uh but implementing it and getting into production fell to me and so I had to stay one step ahead of the security cycle uh because you know most of the folks in cyber security don't know anything about AI. They don't know the risks and they they they're the party of no. You know, especially in the federal landscape, it is very difficult to get AI capabilities instituted. The chief AI officer is like, rahrh, let's get this done.
The siso is like, uh, no, not on my watch. You know, we're not going to do it. So, you have to show them where the risks are. And DASF does a really great job outside of NIST on how to do that. All right. So the clever pipeline. Um, does it build? Yeah. Yeah. Okay, let me just build it. All right. So, I just went over the clever pipeline. 1. 5 million notes a day. We we chomp on that in a Spark infrastructure. It cost us something like 15 bucks a day.
And then when we overlay it with an LLM for the social construct, it's like another five bucks. So this is where cloud computing really comes in and helps because we are really doing some serious work. Uh but to get that into production like I said was really difficult. Um so when we're scaling um you know generative AI in the federal space two categories uh emerge very quickly. you know, we've got the traditional cyber security risks and then we have, you know, that deal with access control, encryption, audit trails, and then you have the AI native risk that is very new and very foreign to the cyber security team.
You got things like model hallucination, data uh poisoning, and adversarial prompts. And so, NIST 853 gives us a strong foundation, but it wasn't written with the LLM's foundation models and multimmodal AI in mind, right? So, NIST uh you know this is where DASP comes in the model explanability, the prompt injection resilience, the data set lineage and the continuous evaluation. Um so we applied this full mapping to Clevver.
We're going to go into that. So you saw the sort of chart and Arun talked a little bit about you know each one of these. I'm going to go into depth. Now what I did was our chief AI officer at the VA was very involved in the AI use case catalog. So he he wanted to know how this would be applied to all of them. So we just started rack and stacking the use cases. We started with clever but AI assistant was another one that had a whole different set of risks that we had to address.
So let's start with the first one. Insufficient access control. And I love the way this is laid out because it's in steps. you start with the raw data. Now, um the we begin um the same way a federal assessor would. So, we got to ask the questions what access controls are in place and you got to provide evidence. How are they authenticated and authorized? And then are the controls suitable and federated and policy aligned and this gives us a strong start here.
So AC1 sets policy. AC2 manages accounts for user life cycle. AC3 for enforcing access decisions. AC6 for implementing least privilege. That's a big one. You know, you got to pay pay the piper each time you want to do something. Uh IA2 identification and authorization. But while this works well for general IT systems, it's really not enough for specific access patterns. So the um the dassive ones comes in and shines on specific uh cyber security controls.
So um on the AI stack, I'm sorry, I got to look at these notes because it's very detailed. So DAFF 1 and two, you implement SSO and MFA and group based inheritance. That's really important, but it works really well with AC1 because now you're seeing the mapping. So the cyber security folks are like, "Oh, okay. So we have this under control already. We're already doing that. And then DAS of 3 and four IP allow lists and private links.
Private links don't show up too much in the AC controls, but it does here in DASF. DASF 5 enforce granular access control and secure sharing of models. NIS doesn't do anything dealing with models at all. And this is where DASF shines again. DASA 59 and 55 leverage clean rooms, right, for collaboration and audit logs. So without strong access control at the raw data level, you're not building a very firm foundation. So your AI system is vulnerable from the start.
So you got to start there. So the next one is pre-processing integrity. So the this so we have to ask two core questions here. Are the transformations accurate and reproducible? Um, a lot of times the a federal auditor or assessor won't see what's behind the scenes. So, you have to figure out a way to show the evidence. And so, a great way to do this, and I'm going to give a a hat tip to MLFlow. MLFlow is a great way to, you know, as you're doing your experiments and your evaluations to record each step in the phase for DASF.
So in this one we use the NIS controls SI7 and AC6 and that you know ensures that the software in information integrity is good but that's where uh this is where DASF 2. 0 shines again. Um DAFF 7 and DASF 11 enforce data quality checks and lineage capture. Now in in the NIST ones it we don't really do a lot about lineage. uh DAS of 15 and 16 provide structured tools to explore the and secure data during pre-processing.
No notice at all in the NIST framework to do the pre-processing. Uh DAS of 42 this is where it starts introducing datacentric ML ops and LLM ops. Again, NIST doesn't have any concept of that whatsoever. So federal assessors are at a loss on how to do that. DAS of 52 and 55 use source control and audit logs uh which is really important. You you want to preserve those immutable records. So the assessor would be pretty happy about that.
So the next one, next risk is data poisoning and NIS talks a little bit about it uh but we have to address it again as an assessor and we ask some questions like how are the data sets validated before training or what mechanisms exist to detect and isolate corrupt data or are you tracking provenence and lineage of fine grain level and this controls start uh with SI7 help ensure data integrity uh and that works pretty well.
Um, but S SC28 ensures data is protected at rest. It doesn't speak to model contamination at all and that's where DAS again shines. So the stakes are pretty high. You know, you're trying to build a foundation here at the data level to ensure your AI is working as designed. So as we keep moving through uh we get next next to uh risk lack of tra traceability and transparity for the model assets. So this is really important.
You want to be able to assess u you know the full life cycle visibility from data collection to the model deployment and it becomes impossible to ensure uh the trust and accountability and reproducibility. Right? These are sort of the governance risks that we have to worry about. And so some of the assessment questions you might want to ask yourself is can you trace every transformation that the data set has gone through or the model has gone through?
Um do you have oversight into the changes made to the training pipeline model parameters and artifact version? again MLflow comes in and that's what I use all the time to just trace you know what's going on with the data set how I changed it how I trained the model so if the answer is no and you haven't done that then you have introduced a major blind spot and potentially a non-compliance uh system now I have one chief AI officer that I'm working with right now he's all about evaluating the model and you know what are the model details you know how was this evaluated ated did you have a human in the loop?
So NIST again gives us AU6 which is audit review and logging and then SI12 handling and retention of information. These controls help but they don't go far enough with the versioning lineage and model asset governance at the speed of AI development. Yeah. So maybe let's show the worksheet. Um so there are like for each one of the risks that are there in the um in the uh compendium built a you know a comparison and a contrast and the process.
Um so with that what we what we did was if you look at the compendium which is this worksheet that you are going to uh be able to download right so at the risk level you have access to first of all all the risk set right so each risk description and then you can see what controls are needed to mitigate that risk so which is going to be in the other sheet which is here in this sheet. Um and then the actual applicability of that risk based on your use of AI, how you are basically um taking advantage of AI so that you know if this is applicable to your use case, your way of deploying uh or not.
All right, I just realized we can only show slides, I guess. Thank you. Yeah, suffice to say those steps are really important to kind of unearth the uh risks that you're going to go through for any of your AI use cases. The uh AI use cases are really important to go step by step through that process to unearth these risks and then provide those controls because then you show the federal assessor which controls you're putting in place and what maps back to the NIST framework.
Now, I'll be talking with the NIST team next week about integrating some of the dash of controls into the next uh NIST special publication 800, probably Rev 6. So, um because it doesn't really handle uh anything to do with AI. So this was me painstakingly going through and mapping each one to showcase where we're kind of missing for AI because the speed at which the adoption of AI is happening is just overburdening any federal standards, right?
So I don't know if anybody in here does uh you know federal compliance, but it is a it's a rough crew to try and get your AI capabilities through but DASF comes in and really helps out and shines and helps to unearth the risk. So you have this sort of risk catalog and then you apply those controls and then you provide the evidence to the assessor. Then you get that full atto and then your AI is in production. That is probably one of the hardest things to do.
Yeah. All right. We are back to sharing the screen. Sorry. So here is the worksheet that we wanted to show you. And for each one of these risks that was going through, the risk description, whether that specific uh what controls you would be needing to mitigate the specific risk and then you will see like you know whether that risk is applicable to certain type of um use of AI and then the risk impact, business impact and you will see the mappings to the standards.
So you will see like you know who else is talking about this risk and this is what um the NIST 853 mappings are going to um the mappings that is talking about right so sorry I didn't mean to interrupt you you can take it from here I just want to kind of call that these these things are not um and also for the controls right like you know for each one of these controls you can see um the datab bricks documentation links and how to deploy a specific control.
And you will see here again the standards that are talking about this and n53 that is the um full mapping of the work that is talking about. Now will they have access to the PowerPoint? Oh yeah, they will be able to get So once you download the presentation you can click on all these links. These are resources that you have. Yeah. the question banks that I created. I have full question bank about 102 questions that you can ask your your own ML ops pipeline to see where you're missing see if there's any gaps in your risks.
Um so we got what five minutes left. Do you want to ask questions? Yeah. Now let's go to the summary one and then uh we'll we'll conclude. Yeah. Okay. So what did we do? So for the VA, we mapped the NIST uh 853B with the DASF overlay to help us get across the finish line for a production environment that helps veterans. And so um you know, right now it the company that I'm working at now, I'm taking the DASIFF overlay and I'm integrating it into our compliance tool so we can do continuous ATOS.
So that's that's the key here is to get these AI capabilities into production faster because it is taking a long time. So those control mappings um are really important. That's I guess that's the key point. I started by asking a question like you know based on your role in your organization the goal with the overall um database I security framework and all the mapping is based on where you are in your organization in the AI system.
We wanted to give you you know first of all a common language when it comes to a security when you're talking about like you know certain risks or certain controls hopefully now by using this framework you have a way of communicating with your security teams your governance teams uh your risk teams making sure like when they ask questions you have the ability to show them that you are you have deployed certain controls or you are in the process of um deploying or proving that you deployed so that they can actually think of moving your workloads or your AI applications into production because in a regulated industry you need to have certain um level of you know deployed control proof set so that you can actually move into production or like be compliant with certain data sets or certain AI applications.
Uh without that you will be either uh at best you are going to be slow to production and in some scenarios they will say the cyber cyber teams or the risk teams um or like you know governance teams they're going to you're going to keep on running into no you cannot do that and our hope and our goal with this is to kind of enable you with how to get to get to those control sets and make sure you deploy those control sets by working with various personas within a within your organization.
And so we're at time so take one question or two questions. Um so this is the summary slide for you all with the project that was on. Uh what challenges they had, what solutions and how they overcame the those uh challenges and what kind of results they got. Uh you can see that. But while we wait on that slide, if there are any questions, we would love to answer one or two questions here and we'll stand outside to uh address any specific questions that you may have.
All right. Thank you all.

Learn more about the Databricks Data and AI platform.