Skip to main content

Sponsored by: Capital One Software | Utilizing Context and AI for Cost Optimization & Security

Summary

  • Capital One Software presents research showing how context graphs—combining business metadata, stakeholder data, and technical lineage—drive measurable cost savings compared to manual data system optimization on the Databricks Data and AI platform.
  • This video covers AI-powered data management use cases including query optimization with 20% performance gains and duplicate pipeline detection using semantic similarity across enterprise environments.
  • The security portion details five enterprise AI compliance gaps, PII discovery methods ranging from regex to LLM scanning, and format-preserving tokenization integrated into a medallion architecture on Databricks.

Sponsored by: Capital One Software | Utilizing Context and AI for Cost Optimization & Security

Watch: Sponsored by: Capital One Software | Utilizing Context and AI for Cost Optimization & Security
Managing data systems at scale often leads to hidden inefficiencies and risks that can impact business performance. Capital One will share research on how to leverage context-aware AI to drive significant cost savings compared to manual optimization and strengthen data security posture of large-scale systems. Attendees will gain actionable insights into the role and impact of context on data cloud optimization and security.
Talk By: Jeff Chou, VP of ML/AI, Capital One Software ;

Chapters

FAQs

What is a context graph and how does Capital One use it for data optimization?

A context graph connects nodes, edges, and business metadata to provide a holistic view of data systems covering stakeholder relationships, cost, and security dimensions. Capital One Software uses this graph to drive AI-powered query optimization and root cause analysis across large-scale enterprise data environments.

What cost savings did context-aware AI deliver in the query optimization use case?

According to Capital One's research presented in this video, context-aware AI achieved 20% query performance gains in a specific optimization use case compared to manual approaches. The broader argument is that significant savings are achievable when AI has access to rich contextual data about system usage and business intent.

How does the system detect and eliminate duplicate data pipelines?

Capital One's approach uses semantic similarity to identify pipelines performing the same or overlapping functions across a large enterprise. By representing pipelines as semantic embeddings and comparing them, the system surfaces redundant work that manual reviews would miss at scale.

How does Capital One approach PII discovery and data security compliance?

The security architecture covers a spectrum of PII discovery methods from simple regex scanning to LLM-based scanning for nuanced sensitive fields. Remediation uses format-preserving tokenization integrated into the medallion architecture on the Databricks Data and AI platform, preserving data utility while protecting sensitive information.

Full transcript

[00:07] Thanks everyone. I hope you all had a great lunch. My name is Jeff Chow. I'm part of Capital One Software and today I'm going to be talking about utilizing context and AI for cost optimization and security applications. It was great to
[00:19] see this morning Ali's talk his keynote about context and AI and agent so I'm glad this talk is on theme with the overall direction of where Databricks is going. Um a little preface the goal of this talk
[00:32] is to give a little it's a it's a high level talk but it's hopefully the goal is to give you all kind of a a real world anchoring of how do you actually use context for an actual use case and so it's not terribly deep but it's
[00:45] not super high it's kind of right in the middle that's kind of my goal. So a little introduction my name is Jeff I'm the VP of product for AI and ML for Capital One Software. For those of you don't know Capital One Software is not the bank we are
[00:59] tied to it but we actually have a different mandate we're a separate business unit where we're trying to commercialize internally built software applications and sell sell it to other commercial entities. So we are actually
[01:11] a software service provider. Okay so for today's agenda today I'm going to be talking about the problem which is how do you manage large scale data systems at scale it's very
[01:23] complicated we have a lot of lessons that we've learned at Capital One and lessons we've learned at some of our customers as well. One of the big missing links is context graphs that's bullet number two I'm going to talk about that give you some
[01:35] kind of really high level teaching lessons of you know how do you actually use it at a really high level and then I'm going to go into two big use cases which is for which is context for AI for data management and cost management and
[01:47] then AI for use cases in data security and then I'll kind of wrap it up with take with key takeaways. All right so the high level problem probably many of you work for many large enterprises here. Um the big problem is
[02:01] managing large-scale data systems is very complicated, right? It's not just a technical thing. It's not just is my column right? Is my schema correct? It's actually many, many things such as stakeholders, uh volume, cost, and
[02:14] security, and many other icons that are not here, right? The stakeholder one is particularly challenging. That's just people, your boss, your coworkers, other teams. It can be very messy how you actually manage data at scale.
[02:27] So, based on internal research, these are some of the top three pain points that we've observed in data management. Um one is inefficient cost and resource waste, you know, are you overutilized? Are you running Do you have any redundant pipelines? Are you being
[02:40] efficient with your resources, especially if you're running Databricks at scale? Uh second one is dead asp- dead assets and data sprawl. Many of you probably have redundant uh pipelines or bunch of S3 buckets or tables that no one has
[02:53] touched in years, you know, employees come and go, and so there's just a lot of redundancy or a lot of waste in enterprises. And the last one is root cause analysis blindness. A lot of you probably spent time firefighting pipelines trying to figure out what's
[03:06] going on or or systems that are down, and how do you figure out how to fix it? So, uh some quotes from uh some of our customers and internal stakeholders um of some real-world pains. Um the first one is talking about um that there's so
[03:20] many ways to program or write up a query to get the answer, meaning there many ways to write a query or an application, and so there's a lot of sprawl going on. And so, is is are we being efficient with our queries? Is it one big question. The second one is trying to be
[03:34] more proactive versus reactive. No one wants to get a call at 2:00 in the morning. How do we be more pre- proactive so we can prevent things from happening versus, you know, getting yelled at uh in the middle of the night. And the third one is um what is the
[03:47] business value of of all of our infrastructure? Of course, we are all businesses. We need to build stuff to move the business forward and we can't get lost in kind of the fun technical AI side. We have to kind of pull back and say, "Hey, what is
[03:59] the actual business value of what we've built?" And that is not always easy, especially at large enterprises where things can can get buried.
[04:11] So, in today's data management and cost ecosystems, there are a lot of dashboards and systems, including the systems that we build. We can look at cost trends or utilization heat maps or lineage. These are all great, but these are all kind of you know, context on an island if you will. These are bits and
[04:24] pieces of information that you've probably personally had to piece together, you know, what's going on, what's the cost, how should we fix this thing, what's going on? You have to jump around a bunch of different systems to kind of understand what's going on,
[04:36] right? This is kind of the state of the world today. It's a bunch of disparate information that we have to kind of piece together. And of course, in reality, like I mentioned earlier, there are many other issues that you have to take into account if you want to fix something or
[04:49] make a decision at the enterprise level on your on your on your enterprise data systems, such as cost, historical runs, business value, end application, etc. So, a decision is very very hard in a
[05:02] large enterprise. That's probably I'm probably preaching to the choir on that one. So, lately, as evidenced by this morning's keynote and kind of the whole world about AI and data, context is king, context is queen,
[05:16] context is really the next forefront of data management that we see. And the goal of this talk is to kind of illuminate some examples that could help. So, this was a really popular blog that went viral on LinkedIn by Jaya
[05:28] Gupta. She's a partner at Foundation Capital. It's a great blog, very high-level, but it just kind of pushed the hype and the energy around context graphs, thinking that, "Hey, it can be helpful for a cross-system synthesis when you have to
[05:40] get information from many different stakeholders." Or if you have exception-heavy decisions when it's very you know, dependent and it's kind of gray. It's not very black and white if you make should make a certain decision.
[05:52] Or maybe you have precedents from past decisions. You have to look back in the past on how you handled something you know, a year ago for example. Or exception heavy logic that lives in people's head. The internal expert is always a very real problem. Everywhere
[06:05] I've worked, there's always one person who knows everything and you have to kind of go to that person cuz he or she is the expert, right? So, let me back up a little bit and and this is a bit of a little you know,
[06:17] context graph 101. This is like one example of how you can you know, very on a very basic level use this stuff. So, let's just look at this very fun example. Let's say we had a context graph like this.
[06:29] And a context graph is not anything inherently new. They've been around for many decades. Graphs are obviously very old things. And so, what you see here is let's say in that gold box is let's say a table that you have like a revenue
[06:41] table, right? And then you can see that it has lines and and add nodes and edges to other things related to that table such as the lineage or looking at what data contracts do you have? Who's
[06:54] the producer? Who's the consumer? Who's the line of business? But the key thing is that the edges and nodes are described through natural language, right? You have words like the what you see there is literally what it is. It is words describing the
[07:07] relationship to other assets, right? And obviously with AI and LLMs, it's all about words and language. That is how you have to traverse and search and figure out what's going on, right? So, the better and more descriptive your graph is, the
[07:20] more words you're using, the more accurate it is, the better your graph is, the better your AI can go and figure out what's going on. One spoiler alert, maintaining this graph at scale and making sure it's accurate and up-to-date, that's actually some of the real real-world challenges
[07:33] of how to actually do this at scale. But we'll table that for another day. All right, so let's get into a fun example. So, let's say you have a simple question, right? Let's say you have the question, "What sound does an animal make?"
[08:20] The second agent, you have to have a validation agent to see, "Hey, did did we answer the question?" And so, obviously cat and dog is not a sound, so the answer is no. So, then a third agent will say, "All right, search adjacent nodes. Can we answer it now?" And so, if you
[08:32] kind of go back to this to this graph, you can see that some of the edges were described as sound. And so, the AI agent will say, "Well, that sounds like it's a about right. So, let me go down that path and let me go find the sound." And then you can see that it can actually
[08:44] find meow and woof, right? So, the idea here is that you have a graph, it's described with words, and you have agents that are basically traversing the tree, trying to search and find the answer to your question. And this is kind of the the the basic idea of how
[08:57] you actually physically use a a knowledge graph to to answer questions. So, one of the first use cases that we looked at at Capital One was, "Hey, you know, we write, you know, an uncountable number of queries every
[09:09] day that are running in production, right?" And the question is, are our queries even efficient, right? This is obviously kind of the, you know, is your code correct and is it is it cost-effective? And to optimize a query, here's like a
[09:22] very simple one. There's nothing terribly special about this query. Um but, you know, it's more than just looking at the syntax. You know, everyone in this room can copy and paste the syntax and send it to Claude or ChatGPT and say, "Hey, optimize this
[09:34] thing." The that's easy. The hard part is actually getting the context around it cuz it's not just the syntax of the query, right? You have to look at um the partition uh the the partitioning, you
[09:46] have to look at the warehouses, you have to look at the session ID, and you look at historical runs if it's a production run. Um there's a lot of things that you have to include in the context if you want to optimize a query to make sure that it will still work in the future.
[09:59] And so, this is just one example of, you know, some of the the context that you have to grab. So, what we built at Capital One Software is kind of a query optimization flow where the first step is you gather the
[10:11] context, the inputs, right? So, obviously, you get the query text, and then you have to get all the historical metadata, you have to get the broader usage metadata, for example, the tables that are upstream, you have to look at all of the other queries that are hitting the same table, you have to look
[10:23] at the historical query profile. There's a lot of information context you want to grab. Um you send that to the model, and then that outputs an answer, and then you have to do some checks to make sure that the syntax is correct, is the column
[10:35] consistency there, and a bunch of other checks to make sure that it looks about right. But, you're still not done yet. Now, you have to actually run it and see, "Hey, did it actually work? Does it actually output the same output results as before?" I I want to make sure that if I
[10:48] change a query, I'm not going to actually change the outputs. And so, you have to do a validation step. So, you have to run it and then see if it's if it actually is correct and accurate, and then you can see, "Hey, did the cost go down? Did the speed go down?" etc.
[11:02] We actually had one of our uh customers use this, and they had one of their uh queries go down by 60% in latency. This is a IoT application, and so, it was really great to see um them im- improve the latency of their
[11:14] IoT devices, um which is great to see. So, just a recap, basically, you have to start with kind of a deep metadata analysis, go beyond the surface level, create query proposals, then then do
[11:27] intelligent management to make sure that your your query is is looks right, and then you have to uh do analysis and validation to make sure that your your analysis is correct.
[11:39] Um so, that's just query optimization. And just to give you all some results that we had. So, we did a quick test on 30 actual production queries that we run, and we had about 95% syntax
[11:51] accuracy. Um and then we got about a on average about a 20% performance improvement um with our queries. So, it was kind of great to see on real production queries, not just kind of academic examples.
[12:06] Um the other area that we are that we were exploring uh was called something we're calling duplicate pipelines. And so, like many enterprises, we have millions of pipelines that are running every day, and this is just a an example DAG, for example, of a pipeline. And you
[12:21] might say, "Well, there if you look at this DAG, some of these nodes are actually redundant, and you can actually kind of consolidate or squish two of these nodes together cuz they do the same thing." And so, um this will save you a lot of uh cost
[12:34] because you're basically eliminating an entire query run, right? And so, the goal is can you actually go back and find redundancy not just the entire DAG, but within a DAG, do you have redundancy there? And so, that's where we found a lot of
[12:46] um kind of waste in our systems. And this is not so trivial. Of course, there's just a simple case of, you know, what's the table, what's the query, are they the same? That's the trivial case. In reality, what we found is it's much more subtle. Like, they're 98% similar,
[13:00] 95% similar. Maybe it's the same query and same table, but the author is different. So, does that matter? Or the line of business is different, does that matter? Or or actually I needed two nodes because I needed two different table output tables. So, it's not so
[13:12] simple. It it sounds simple to kind of find identi- identical uh segments of your DAG, but in reality, the context is very important. And so, again, this is where context is needed because it's not just Again, it's not just matching the
[13:25] syntax. You have to actually fully understand what is this pipeline doing, who wrote it, who uses it, does it logically make sense to kind of merge nodes, right? So, again, I'm just kind of showing the application of context
[13:37] that making decisions like this are incredibly complicated, especially at an enterprise in production. Um So, the other big application that, you know, we're looking at and many other kind of outside vendors are
[13:49] looking at is root cause analysis. Um the dream system is looking at, you know, maybe your input is like, "Hey, the dashboard sales revenue A is failing. Why? What should we do about it? Who do we talk to?" As you can imagine, that that's that's a
[14:02] conglomeration of many different factors, not just technical, but also uh the stakeholders. Who actually uses the thing? Who manages it? Who created it? And the the dream goal is you have some sort of AI and context system that can
[14:14] output not just the technical explanation for why what the failure is, but then the business context, which is that, "Hey, yes, this dashboard is failing. By the way, the sales team needs this pipeline to run cuz they wake
[14:26] up every morning at 9:00 a.m. to look at this dashboard. So, you better fix this before 9:00 a.m., right? Or sorry, 8:00 a.m." Um and that kind of context can really help you right-size the fix, you know? If no one If it's creating a dashboard that no one looks at for
[14:40] another week, then, you know, we'll get to it in a couple days, no big deal. But if you know that, "Oh shoot, the entire revenue sales team needs this thing by 8:00 a.m.," then, you know, you might have a late night call. And so, that kind of syntax is really important in in
[14:53] context. Um this is a kind of a fun one. It's it's a a bit higher level, but one other problem that we're seeing is in a large enterprise, you have data producers and data consumers, and they're often two
[15:05] different teams, right? And so, now the question is, does everyone know what they're doing? Like, why did the data producer create and prepare a certain table? They might have a list of requirements, but the end application is
[15:17] completely lost to them. And that can cause a lot of friction. For example, let's say someone wants to look at um something simple like, "Hey, I want to reduce the size of this warehouse." A pretty innocuous thing that hopefully
[15:30] shouldn't be a big deal. Uh but maybe they're missing the context that, "Hey, actually the dashboards, if you do that, you go from a medium to a small, that's you can do that, but the dashboards are going to be are going to load slower. By the way, 50,000
[15:43] customers are already complaining that we're too slow, and they're going to be more upset, and we might actually lose revenue, right?" And so, the right half of that of this slide can kind of show you that if you don't have all the business context of what the downstream
[15:55] implications are, how can you make the right technical ones, even very simple ones like just changing the warehouse size um by a small amount can have downstream impact. And that is really hard to get
[16:07] at a company. That that that's really hard to kind of gather all in one place. Um all right, I'm going to switch gears here. So, that's kind of data management and cost management. Now, I'm going to kind of switch gears towards AI and data
[16:20] security. Um and so, looking at this category, there are five main areas um that we see uh that are that are concerning enterprises today in security. Um a big one that you might have heard
[16:32] in the in the industry is something called shadow AI. This is basically um honestly, a lot of employees using Claude or any kind of agentic system, building shadow agents. They're just building stuff cuz
[16:44] let's face it, there's a lot of hype, and it's just a lot of fun to go build stuff right now. And so, um I think this is a really interesting distinction that it's not just the outward-facing, you know, large production AI system. It's actually the
[16:56] inward-facing, you know, you might have 5,000 data engineers and data scientists all playing with Claude, creating crazy systems. How do you know what everyone is doing, right? And so, that internal look is actually what shadow AI is
[17:09] talking about. And it's it's kind of an interesting case. It's probably many of us in this room, me included, is guilty of kind of playing around with AI cuz it's a lot of fun. Um the second one, data not the model is the risk surface. You know, AI, everyone
[17:22] probably just use a third-party AI and really it's kind of the data is the risk. You know, am I putting sensitive data into the model? Am I sending it out to Claude or ChatGPT or something like that? Um the third one is runtime is where it breaks. That's where a lot of concern
[17:35] is, where your agents are running and is it It's making decisions. It's accessing systems in real time and that's really where a lot of concern is. Um agent access control is one big area that a lot of folks are kind of focusing
[17:48] on, ABAC or not RBAC. Understanding like what's the intent? What is this agent trying to do? Um and and does it does it have the right access control um before it accesses sensitive data. And the last
[18:00] one is the lineage and chain of thought auditing. This is a really interesting one where um especially for those of us in regulated industries, understanding what's the lineage of our agents, what data is it accessing, is it useful? Um
[18:13] and and understanding kind of the history and the purpose of the agent is a big security concern. So today, enterprises are deploying agents faster than they can see them or govern govern them or approve what data
[18:25] they touch. And so this was a nice report from Gartner um where they basically predict that um and show that agents agent discovery and data path lineage and audit auditable
[18:37] explainability are some of the big concerns um with a lot of enterprises today. And so some interesting numbers that Gartner uh pulled out uh are really interesting. I think the the 80% one is stuck out at
[18:49] me. They are basically predicting that 80% of agent deployments will be non-compliant with AI privacy laws by 2029. This one is a interesting one for those of us in kind of regulated industries, how are laws and regulations going to
[19:02] change in the next few years? AI is so brand new. Um my I my guess is there's going to be a lot more, you know, crackdown from the the government as we kind of saw with Mythos, right? Um what else is going to
[19:14] happen in the in the future? Um and so this is going to be really interesting. But Gartner is basically predicting there's like going to be a lot of loss of control of AI in the next few years just cuz of the sprawl and the growth of
[19:26] it all. So I'm going to quickly go through the gaps that Gartner kind of identified. They're saying gap number one is nobody can inventory the agents that are already in production. I think some of the features that were talked about this
[19:38] morning from Ali in the uh and the keynote are really great like the Unity AI gateways kind of one way to kind of wrangle this mess, you know, put everything through one system is is kind of one common approach that we that I've
[19:50] seen personally. Um gap number two is that the risk surface is the data is the data path behind the model, not the model itself. So it's all about the data. AI the model itself is not scary. It's like I don't
[20:02] know what these agents are doing with our sensitive data. Gap number three, regulators want a chain of work audit trail that today's tooling cannot produce. So this one's looking a little bit kind of predicting into the future that regulators might actually want an audit trail, you know,
[20:15] historical log of what what what are your agents doing? And you have to then legally have to send that out. Maybe. I'm just kind of speculating, of course, but I think this is a very real area of questions that, you know, what what's
[20:27] going to happen in terms of laws for AI in the next few years. Um and then four access control is the number one attack vector and our back alone cannot handle agents acting on
[20:39] behalf of users. And so this is a big concern that access control of your agents, it's not just the you know, one strategy as well just inherits the permissions of whoever created it. Um that might work maybe, maybe not.
[20:52] Depends on your use case. Um but this is a big area of concern for a lot of security uh enterprises. And then last one, lineage is a very big question. What is it doing? Where's it coming from? Where did it get grab the
[21:04] data from? Um also did it grab from the third-party services. That's where a lot of data leaks happen, you know, getting data from the outside. All right. So, those are kind of a summary of kind of the from Gartner and
[21:16] the industry of where is where are the main headaches and concerns of enterprises? Uh, I'm going to for the remaining chunk of this talk, I'm going to talk about the data part. So, how do we focus on on and make sure that data
[21:29] is secure? And so, in data secured in data security in the most simplest ways uh, to think about it, there are two huge steps, right? First, you got to find the sensitive data. So, where where are the
[21:41] social security numbers? Where are the credit card numbers? Where's the person Where's the personal PII information? And then step two is then you have to secure it. You have to lock it up and protect it. How do you make sure that that's happening? So, I'm going to talk about the first
[21:53] part, which is finding and scanning and classifying. How do you find the sensitive data? And so, this is a really great example of how do you use context to improve scanning and classifying? And so, um, in the real world, for those of you
[22:06] in the kind of regulated spaces, there's kind of a a spectrum of scanning. Meaning, sometimes you can it's really simple. It's just there's a table and it's all social security numbers. It's
[22:18] pretty straightforward. You can just use regex at scale, super cheap to find and redact or tokenize or encrypt that column, right? It's very easy to find social security numbers, for example, in a table. That's on the very easy side.
[22:31] And then you have it on the right-hand side, you have very hard cases where maybe it's like an image of an image of a PDF from 1982, right? That how do you know what is in that document that was scanned? That's a
[22:43] really hard one. You can't use regex. You probably need some image processing. Or maybe it's not a social security number. Maybe it's a strategic decision, like we're going to expand to Europe. And how can that be expressed in many
[22:56] different language or language or paragraphs um, or how can it be pieced together in a larger context? So, you can imagine that, you know, it goes from simple to complex from left to right and then everything in between.
[23:08] And you can use regex on the left, you can use machine learning in the middle, or and then on the right you can use maybe SLM small language models or LLM large language models to kind of attack the big ones. The problem is, well, why don't you just
[23:21] throw the most aggressive algorithms you have on everything? The problem is the following. If you're a large enterprise, you have hundreds of petabytes of raw data every day that you're processing. And it's really a cost versus accuracy problem. So, you don't want to throw,
[23:34] you know, cloud code at everything. Um, that would cause the, you know, actually might be a good time to do invest in Anthropic because that would help their revenue massively if all of us in this
[23:46] room started throwing LLMs scanning every byte that we have. And so, the question is, can you use the context to filter and kind of pick, you know, do a an algorithm router to help you decide, "Hey, this is probably going to be a
[23:58] really easy one. You should just use regex." Or or like, "Oh shoot, this is really hard. Um, you should use something more aggressive and more expensive." And so, you need something to help you do that trade-off of cost versus accuracy. And it's all about
[24:10] context, for example, like, "We know these kinds of files give us trouble. We know these kind of tables give us trouble. We know these kind of tables are easy." And that kind of context can help you be much more efficient.
[24:22] All right, so that's kind of the scanning and classifying side. So, once sensitive data is identified, then remediation is necessary. So, let's say I found the table or I found the PDF that has sensitive data and now I want to secure it. And so, there're a couple
[24:35] major ways of doing it, right? Access control, you can just restrict access to that table. You can mask or redact it, that's just, you know, yanking the the information, or you can encrypt it. Um, and these are all great, but they all
[24:47] have some limitations, right? So, access controls, well, what if you need access to the table? So, that's not that's not that's off the table. Masking or redaction, you you completely remove a column, that might hurt you if you want to do some sort of analytics on that
[25:00] data. And similar for encryption, you might lose referential integrity if you're you're starting encrypting your column. So, depending on your use case, these may or may not work for you. And so, at Capital One, we actually uh
[25:12] champion a a system that uh is called Data Vault, which is a tokenization solution. And so, basically, the idea here is, let's say you start out with a social security number, and if you use our Data Vault uh tokenization API, you
[25:25] can then basically convert it from the real one to a format-preserving tokenized version. And now, you can once you've tokenized it, and it's format-preserving, so it still looks like structurally like a social security
[25:37] number, but obviously, the numbers are all scrambled. And then now, you can take that data, and now you can store it. And this is actually one of the main uh uh techniques that Capital One takes to protect the data at rest. And so, the
[25:49] idea is ideally, you take all of your sensitive data, and you tokenize it all, and now it's ready to go, and you can safely use it downstream for any AI or analytics applications that you need. Or data sharing, for example.
[26:02] And so, we ran uh a study with PwC to look to see, hey, does does tokenization and format preservation um actually help with AI and ML use cases? And so, we showed that um
[26:14] with unstructured data use case, you can actually get comparable accuracy. So, in the middle column, uh on the white, you actually see the accuracy of an ML and AI model uh or an ML model that with just raw data was about 89% accurate,
[26:27] and then with tokenized data, it was 85% accurate. So, if you're a data scientist, you might be nervous to kind of encrypt or tokenize your data cuz you might think, well, I need the column. If if your use case suits it, you can
[26:39] actually be both safe, and you can do analytics on your data. And that's kind of the the win-win scenario here. And the same thing for the structured use case, where we got about 99.7% accurate accuracy with tokenization. So,
[26:51] this is really the use case here is hey, you might be a data scientist or a data engineer, you might be working with AI, and you need to secure your sensitive data, but you also need to actually use it. How do you get the best of both worlds? Tokenization is kind of our
[27:03] solution that we found that that works really well. All right. So, I'm going to in the last chunk of this talk, I'm going to go over a quick demo use case. So, let's say you're a East West Bank, and um you have
[27:15] some information that you want to you want to protect at rest and then use that on stream. So, um let's say we can just kind of jump straight into it. So, let's say this is kind of how we do it at Capital One. This is Data Vault in
[27:27] action. Let's say you have your tables in your bronze in your bronze tables. This is kind of again your raw data. And using the APIs, you can send it to Data Vault, and then it'll actually tokenize it into your silver tables. So, now your
[27:40] silver tables have the tokenized versions, and your bronze tables have the raw data, right? So, any downstream applications hopefully are just using the silver tables alone. And so, here it is uh this is a real screenshot of the uh solution in
[27:53] Databricks. Apologies, I don't have a zoom in here. Um but, you can see on the top is basically the bronze table, where you can see um some of the information up top is basically the raw columns like the the um like the raw information. And
[28:06] then, if you tokenize it and then send it to Databricks, then inside Databricks all you see is basically the secured scrambled versions inside Databricks. And so, this is how you kind of protect and make sure um any kind of downstream
[28:18] analytics or analysis that you want to do is all tokenized and protected, so that your your data your team of data scientists can kind of work on the data. Um same thing for unstructured data. Uh apologies again, it's hard to see uh if
[28:31] you're in the back, but here's like a call log essentially. And so, you can actually go into this text file, and there are um Sorry, you can't see the my laser, but there are social security numbers uh laced all throughout the chat logs. And
[28:44] you can actually go into these unstructured data files and swap out the tokenized uh swap out the social security numbers for a tokenized version. So, it doesn't just have to be in a table, it can actually be in a text file. And then here it is in a PDF as
[28:57] well. So, in the top paragraph, I'm talking about Sarah Miller here, a fictional user, their social security number on the left, which is the raw data, and then on the right and you can see it gets scrambled and tokenized. And
[29:09] the beauty of tokenization is you can actually reverse it. So, if downstream someone says, "Hey, I actually need to see the raw information." You can actually reverse the tokenized value here and actually get the raw value if you need it if you need that kind of access. So, tokenization is kind of the
[29:22] solution that we found that gives us the most versatility. All right. So, this this is the end of my talk. And so, basically, a couple key takeaways that hopefully you can see
[29:34] that global context is essential for decision-making. And preserving context is really important both from a data management and cost and security. And you can see with the DataBolt tokenization solution, we were able to
[29:46] to basically preserve the integrity, we can preserve the reference the referenceability of the tokenization tokenized value. And so, preserving context is very critical to help to help
[29:58] accelerate any decision processes you want to make. The second one is AI accelerates optimization through context graphs. So, um anytime you need to make a decision or you want to change something, having
[30:10] more context is always better. And really, that's basically all we heard at the keynote this morning is that more context the better and organizing the information, making it easier to retrieve makes life a lot easier. And then the last one,
[30:22] tokenization balances security with AI utility. So, if you want to you want to balance of both best of both worlds, you want to be secure and you want to run AI ML applications, then tokenization is a great solution for that.
[30:35] Um that's it. And if you want to see a live demo of DataBolt Uh, and other things that we're building at Kaplan Software, please check us out at booth number 202. We also have a social event
[30:47] at the top floor of the Marriott, um, later tonight. Um, it's got great food and drinks, so if you want to come chat and chit-chat with us, um, come check it out. You can go to the booth and get more information on
[30:59] exactly where it is. Um, but just a quick plug on on that event. Um, thanks so much. Appreciate it and enjoy the rest of Summit. Thank you.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.