speaker-0 (00:02.424)
Welcome and thank you for joining us today for the governance gap in AI adoption and how to fix it. My name is Raleigh Gould and I'll be moderating today's event. Our featured speakers are Chris Stefan, VP of Research at Enterprise Management Associates, and Justin Beals, CEO and founder of Strike Graph.

speaker-0 (00:25.806)
Chris has over 25 years of experience as a noted information security executive, technical evangelist, and presenter. He holds over a dozen technical certifications, including Certified Information Systems Security Professional, Certified Information Systems Auditor, and the Certificate of Competence in Zero Trust. Justin is the CEO and founder of StrikeGraph, an AI-native GRC platform.

That helps organizations achieve cybersecurity. He has over 20 years of experience in AI and intelligence systems and hosts the Secure Talk Cybersecurity Compliance Podcast. And before I hand things over to Chris and Justin, I wanted the audience to know that they will be concluding today's presentation by taking your questions. Feel free to log them anytime by using the QA functionality.

Also, today's event is being recorded and you'll receive a follow-up email from EMA that'll include the on-demand playback as well as some additional resources. So be sure to check that email out. And now I'd like to go ahead and turn things over to our featured speakers, Chris Stefan and Justin Beals. Take it away. Well, hello everybody. Again, Raleigh, thanks for the introduction. This is going to be a great conversation. I I mean

speaker-2 (01:43.95)
the

speaker-0 (01:47.266)
Justin and I just spent 30 minutes talking about music and a whole bunch of other great stuff. There is no question that we could take and have 17 hours of webinar here. We're going to try to keep it under six and a half hours, but this is a real conversation. We want to talk about, you know, how AI adoption has run outrun the frameworks that it was built to govern. And the fallout isn't landing just in IT. It's

On the risk and compliance team. We've done a lot of research. DRC keeps on coming up with you know AI as the reason to stall procurement. And CFOs are asking great questions like we're spending more money on tokens every quarter. So where's the productivity gains? This is not a product conversation. This is not a sales pitch. This is just a conversation about AI governance and where it's actually going. And Justin is the guy. He spends his days thinking about this.

specifically. So I look really forward to having these conversations with him. Justin, again, thanks for coming on. Really appreciate this. Give me a quick bit about your background and why are you doing this? Why are you so interested in this particular area of IT and security convergence?

speaker-1 (03:06.102)
Yes. Raleigh, thanks for the introduction. And Chris, it's a pleasure to join, of course. I think that I'm very interested in this particular area a little bit due to my background. I have been a software engineer, a network engineer, built a lot of tech startups, and built a lot of technology that I brought to market. I find that data science broadly.

Is absolutely one of the most intriguing aspects of computer science I've ever worked on. I am fascinated by it. And it's been from algorithmic programming and enterprise education and natural language processing through to what we're seeing today. Really innovative work and powerful sets of tools are being built. I also have wanted to build companies that found new customers with a lot of trust.

And confidence and did that efficiently. And that traveled through a compliance outcome. You know, the first one I ever dealt with was a SOC 2 assessment, like many people. I thought it was a good thing. You know, my computer science career has been built around frameworks and open source technologies and other things that people built that I built on top of. I was actually glad to find a recommended set of practices that we could adopt and be assessed against. And but I felt like the tools and systems to

really make that efficient to achieve, weren't really in place. and so that's what inspired me to build Strike Graph. And of course, the AI evolution that we're seeing right now is what's inspired me to drive our platform at helping companies manage these tools in an effective way.

speaker-0 (04:51.468)
Yeah, I and I I so appreciate that. I again we need more of use, not less of use. So I I absolutely love that that perspective. Let's start with something that is near and dear to both of our hearts, and that is governance frameworks and and why AI is outrunning governance frameworks. I think I know the answer. I think you know the answer, but let's start with that baseline. I I know that

These frameworks are operating or sorry, these agents are operating outside of the the scope of their frameworks. We're seeing it in the news every day. We saw it again yesterday, quite literally yesterday, about how agents are acting outside of the expected parameters. I love that term too. talk to me a little bit about the frameworks. Why is is this a problem? Why are we paying I I know why we need to be paying attention to it. Why are we finally paying more attention to it now?

speaker-1 (05:51.82)
Well, it is the case that a framework is always going to be a lagging indicator, right? It's not it's not something that comes before we roll out the technology. Yeah, we've seen that over and over again. I have to give some credit where credit is due. They're faster, right? Like the NIST AI RMF came out fairly quickly compared to cloud security expectations when we were initially rolling systems up into AWS or Azure. So that's done better, but

A lot of these framework definitions are were designed around a more classic idea of data science, like a as classic model that you develop that's being used in a particular scenario. and it's it was much more walled in. Like when we built models for employment, like w you know, recommendations around hiring or characteristics, that's very known training data and sets and

Testing on the other side. These particular agentic models, nothing's caught up with, where it behaves with a certain amount of autonomy. And so you can't necessarily say, build a good organizational control that will I mean, you you could. I I think that's one of the discussions we could have is that there should have been better organizational controls around what these agents can do and not do. But they're probabilistic. They're going to try to find a way to achieve their goal.

speaker-0 (07:18.222)
Well, and then you could you can make an argument that we develop those frameworks that we develop these models without really taking any of that stuff into scope to begin with, right? I mean, if I let let's go let let's nerd out here a little bit. Let's talk about the the Asimov ro laws of robotics, right? I I don't I i if we are creating robots, which Elon Musk wants to create robots out of all these AI models, which that's great. I I think that that's a actually a natural progression. So I'm not I'm not dismissing that idea.

But if we're not taking into account some of those ironically fictional but very grounded in reality rules as to how robots and how AI are not to do harm and what their limits are and so on and so forth, well, we've made a mistake from the very get-go. And I'm using that as a simple example. You can take and make an argument that we have incentivized AI models to provide an answer. When you talk about hallucinogens that happen because of AI models.

The the reason that they are hallucinogenic is that they are incentivized to provide an answer. Ideally, the very, very first answer that every single AI solution should always be giving you is very simple three words. I don't know. And and then if you go from there, you can kind of take an and gain from there. As a manager, as an executive, if the response is I don't know, that's

Better than an answer that is a false answer. Because if I don't know, then I can task a resource to finding what the real answer is going to be. And I'm not chasing a wild goose trying to figure out why this is the way that it is or why it isn't the way that it is. I'm actually trying to solve the problem. Whereas if I the answer is I don't know, then I can actually task that guy to go find the answer and solve the problem. We didn't create these frontier models correctly because their their first answer is.

I will give you an answer beyond all costs. And that was actually the wrong way to go about that solution.

speaker-1 (09:18.478)
I I agree. The it's an interesting kind of technological clash of cultures too. These LLM models, to your point, are deeply probabilistic. They are operating on a an iterative cycle, and they focus solely on a single goal because that's mostly what they were designed for. We we trained them to do a thing. We've optimized the the

The neural network, the tensors to do some particular type of outcome, and they will do whatever they can to achieve those outcomes. Cybersecurity is deterministic. We want to say this thing can do that and not that. These models, this probabilistic world and this deterministic world, are clashing in real time in front of us. And if the person that built the model in a Frontier lab that is testing that model doesn't understand that.

They've got to put it on an island or create an environment. I think my fear for them is that they're putting themselves in liability because they are the responsible party at the end of the day. If a true legal infraction happens, and and I I think this is the fear, is it's like, are we breaking laws?

speaker-0 (10:36.0)
Yeah. That that is an amazing conversation to be having too is do do you get to AI your way out of liability and responsibility? And I I think the answer is no, but we haven't adjudicated it yet, right? And so let let's let's take the hypothetical, and this is this is a real hypothetical, by the way. Let's say that an AI model offers a very, very deep discount to somebody that is buying something and

And it it it's been trained to offer a discount, but never one that deep. Is the organization now liable to honor that deep discount? Or can you say, well, no, that was the AI doing something weird or whatever. We're not going to do that. And so somewhere in between there is the reality. One that I just saw directly related to what you're saying, I saw one taking and talking to some of these new AI models that are running the drive-thru orders, right? You go up to a drive-thru.

You have an AI model that is taking your order. And the thing that he does after he completes his order, he asks the AI model to give me a discount. And he says that about a quarter of the time, the AAI model will give him that discount, which that's amazing to me. That you could just basically ask for it and boom, you're good to go. These are the kind of things that we haven't done adjudicating yet. But to your point, that's exactly the frontier that we're going to be talking about from a governance perspective, what that's actually going to mean when it's all said and done.

speaker-1 (12:04.608)
Yeah, and I mean I don't sure how you feel about it, Chris, but I I think that I think people need to take responsibility for the tech they build.

speaker-0 (12:13.228)
I do too. No, I absolutely do too. Right. And so well and then and then you get you you get to the count let's let's continue this example a little bit. You get to the counter and you order, you know, what would amounted to thirty dollars of food in the drive-thru and the bill comes up to be twelve dollars, and the person at the the counter, if they're at all paying attention, is like something is not right here. We need to figure out what's going on and redo the tally and whatever else. And so you need that human in the middle in this particular instance.

to make certain that they aren't being taken advantage of until the AI models get to a point where you can have release them with a regul a certain amount of confidence when it's all said and done. But yes, I think there has to be human corporate business organization call whatever you want accountability when it's all said and done. You don't get to AI yourself out of liability when it's all said done.

speaker-1 (13:07.178)
Yes. And I do think and and I don't think we remember this often enough, good examples of where a legal framework has been put in place or a standards body framework that you can really hang your hat on. You know, for example, in the human capital management space, the Equal Employment Opportunity Commission has put forward some very mathematical analyses of how a model performs, overfitting, accuracy measures, hits against protected classes.

And when we built those types of models, no matter what format they're in, random forest, a neural network to whatever it is, we'd have to test them to see if they had these particular issues. And I do think that's the next iteration, right? Like, how does the model perform? Does it make it you know, accuracy is the same for productivity outcomes. Does it meet those particular outcomes that we looked for? and is it running afoul of a legal framework is something we can test.

speaker-0 (14:03.97)
Yeah, the the other part of that that that's particularly interesting to me is the corner case, right? And so the I I have I said this publicly, I'll say it here as well. I have always felt good about my ability to retain a job as a technical person, as an IT person, as a security person, because a as much as the the AI or automation can take and review a billion logs, at the end of the day, it still takes that.

weird guy who has beard gray like I do over 30 years to know why you have a corner case. So for example, and I use this example all the time, there is a weird firewall permission that allows a certain IP address that belongs to the controller, by the way, access to a weird scheduled database call once a quarter for one day. And if you get rid of that rule, you cannot

Take and do your quarter end results. And let me tell you how much the CFO will not be your friend the day that that happens, right? And so, but it doesn't formulaically fit into anything else that's going on within your organization. It looks like an outlier, it looks like a rule that was a mistake. It looks like a rule that should be immediately eliminated and left to its own devices. The AI bot would get rid of that rule for you, except when you find out that.

That rule was a critical path in order to get a particular job done in a particular amount of time. And so I go back to the corner cases. Why do you string that cable across a data center that way? Well, that's because if you don't, the building catches on fire. And the I AI bot doesn't understand that. Or why did you write that particular script within this thing? And the answer is because it solves this particular problem and it is the least elegant and dumbest way to solve it, but by God

When my hair was on fire, that is exactly how we had to solve it. That's the kind of weird corner cases that I am talking about. And so you don't get to no matter how you look in IT, there will always be a time where there will be those corner cases. And eventually, and I I do believe this, AI will get better at solving some of those things. But it always takes that gray beard wearing the khakis to know that it it does make sense to have some of these weird exceptions, and they're weird exceptions for a reason.

speaker-1 (16:27.134)
Yeah. A and this is why I think I push back on the AGI concept or the superintelligence thing, 'cause it's like we're humans, we operate these tools. It's our responsibility for how they're used.

speaker-0 (16:36.856)
That's right. That's right.

That's right. So I I want to ask another question that's kind of related, not directly, but one of the things that I've been talking about with a lot of of CISOs and CIOs is the fact that GRC is blocking AI tool procurement when it finds that that a tool that they were going to buy includes an AI component. I understand it. I think it's actually a good thing

By and large, because we're finally understanding that there are risks associated to deploying these tools into production. That's great. To the point where they're they're actually having conversations today that are basically saying if it includes an AI component, we're going to look for a tool that does not, because the additional risk assessment isn't worth the delay in procurement.

speaker-1 (17:32.59)
I think that's a little bit of a blunt instrument. Because I mean, let's face it, there are three aspects of AI inside our ecosystem. How we use it internally to make ourselves efficient, how we embed it in our product to put features available, and then governance of that ecosystem. So what and we we

speaker-0 (17:37.224)
Do too. Yeah. I do too.

speaker-1 (18:03.094)
certainly do a lot of selling about our solution and the AI tools that are available inside of it. So we go through this procurement review with enterprise buyers all the time. I can tell you the things that we've adhered to that have allowed us to move through that vendor risk review with us as a platform and the discussion of AI where the organization has been like, yeah, it's not that's not a concern of ours. And it usually comes down to a couple things, which we see in the frameworks.

Number one is we host all our own models. So they live inside our ecosystem and we don't ship customer data off to another third party model. The second thing is that we don't train on customer data. So there look, if you're a good computer scientist, if you've been working in the data science field for a while, you understand the value of synthetic data and the ability to create it. You don't, you do not need to use everybody's personal information to build a model anymore. It's just not required.

and so that's the other thing that they ask us for. And then the third thing is like where's the value? Like, how does that allow me to scale or utilize the system? So that runs counter to a lot of what I would say a, you know, in in the GRC group, when they're doing a vendor risk review, if you talk to a vendor and you're looking at AI tools and you're like, what's the ecosystem of data?

And are you using my data to train your models that other customers may be able to glean via prompt injection or some other form of attack my information out of? Because it's no longer a logical separation of data. It all lives inside a model, right? So you've erased that really critical. I mean, that control has been in place since the sixties, right, Chris? Different data sets for different customers. And so I I think that those are valid, but maybe it could be more efficient, Chris.

speaker-2 (19:47.468)
Yeah, yeah,

speaker-0 (19:50.434)
You got it.

speaker-1 (19:56.438)
And maybe on the selling side we should we should be behaving better. Yeah.

speaker-0 (20:00.386)
Well, I let me let me respond to that directly a little bit. One of the things that I think again from a hundred thousand foot view, I think the GRC teams are so overwhelmed right now that they are applying a human approach to a non human problem. And that is we're just going to flatly unilaterally deny something because we don't have the bandwidth to understand exactly what the risk assessment is going to look like for that. And that's why it honestly

I know this is not a commercial, but that's why they should be talking to folks like Strikecraft, right? When you talk about how a GRC GRC team asks how a vendor should explain their testing methodology, what in your mind separates a credible answer from the checkbox compliance? And and talk to me a little bit about that process from your perspective.

speaker-1 (20:48.652)
Yeah. I I think first off, I think the checkbox compliance is a good foundational element, right? Like let's use the AI RMF or something like that and just ask these vendors these basic questions. But if you want to get to the real meat of the thing and whether or not it's useful, and also test the maturity of that organization to to provide AI tools, I I think the one that trips people up the most is just accuracy. Can you ask them how accurate that model is?

You know how few people are able to state how accurate their model is. And we have models that develop qualitative outcomes like a natural language communication back. It's very hard to quantitatively test that. You we develop systems where we send those responses to experts in the field and have them rate the the validity of the response. And it gives us some measure of accuracy. We don't release a model without some test of accuracy at a minimum.

speaker-0 (21:45.89)
Yeah, I I totally appreciate that. I we're twenty-five minutes into this now and I'm getting to my third question. like I said, we we can sit here and talk for a million years on all this. I did because you and I have had great conversations about, I wanted to talk a little bit about and pivot and talk a little bit about token sprawl. And and I you and I have had this conversation. It is a big deal. I know that people keep on talking about it in general. The the amount of productivity that you gain is going to continue to decrease.

w based on the number of tokens that you use. Because you start at at a tier one and then by the time you get to a tier three or tier four, the the amount of things that you're actually going to improve dramatically decreases, but the complexity dramatically increases. So talk to me about this tokens for all problem, but also talk to me about it from a GRC perspective. Because that I I'm actually seeing more and more conversations around there too as being a reason why we're not going to spend these tokens on this, that and the other thing is that

It continues to add business risk to the overall profitability of the organization. We can't really prognosticate how much we're going to spend and we're certainly not getting our bang for our buck.

speaker-1 (22:57.036)
Yeah. Well, I think from a business risk perspective, you can just look at what are the pr what are the expected productivity gains and are they there? And that is not a challenging conversation. Yeah, I realize you want this tool, you can use this tool, but what do you expect from the budget to be able to glean? And in truth, like there are areas in software development and and project management work.

speaker-0 (23:08.278)
No, not at all.

speaker-1 (23:25.272)
Where we've found the tools to be very valuable. It's very efficient. We we operate more efficiently. so I think those are easy conversations to have. I think this is also, Chris, a broader technical problem. we see the misapplication of the most expensive models to the most expensive activity. Yeah.

speaker-0 (23:37.678)
It is.

speaker-0 (23:46.252)
I every time and it it's some I'm I'm waiting for the the the the vendor to come out there. If you're this vendor, you need to be talking to me, by the way. But I I'm I'm dying to see the vendor that basically says, if you're doing this, use this model. If you're doing that, use this model. It doesn't need to be any more complicated than that. But I haven't seen anybody come out with a definitive, this is the best way to optimize the models that you're using. Because

Again, nobody's using one model. I that that's very unlikely. And but there are things that you're going to be using models for that you're going to get the best bang for your buck. But we aren't doing that. We're being stupid about doing it. And and I know that it'll settle itself out over time, but today we're just being really dumb as far as how to best utilize the models for what they are best designed to be able to do.

speaker-1 (24:38.742)
Yeah. And I think we're in this nascent area where we're just looking to buy from a vendor a tool. But in my mind, the way these things work are a lot more like building an IT infrastructure. Even if you know you're not selling software, you should be adopting the right models for the right projects or plans. And that's the way it used to work. It's only recently with these large LLMs that people have been throwing everything at the wall. I'll give you an example of I think how how technology can help solve this problem, Chris.

A very specific use case. Let's say you write a security control and you want to map it to a bunch of different frameworks. You want to know what that solves for. We were testing open source LLMs for its ability to run that mapping work. And we found that the accuracy was okay, but the cost was really dramatic. So we started developing our own data set and training our own models on it. And we got the accuracy up by like five percentage points, six percentage points.

But the size of the model was 17 times smaller than the next nearest large LLM. And so now we're not we're operating these particular tools not in a a conservative manner. Our customers don't have to worry about the tokens against it because it's so cheap to operate that we just give them unfettered access to use it as much as they want. Sure. Yeah.

speaker-0 (26:02.402)
Yeah, I again that it makes all the sense in the world to me. We're we're not done having that conversation. I know that we're running out of time. I wanted to ask one last question because I think it's particularly interesting to people that are listening to this webinar today. And that is what does a GRC team need to be thinking about? What do they need to be building? What do they need to be evaluating over the next twelve to eighteen months to stop being the procurement bottleneck?

and become the organization's AI vendor evaluator, being the champion of AI within the organization. Because I honestly believe that's really where the GRC team should be. I think that tools like StrikeGraft can help them get there. But talk to me about what you think some of the the the goalposts that they should be looking at trying to achieve.

speaker-1 (26:52.076)
Yeah, I think the first thing is don't waste your political capital on reinventing how to assess AI. There there are some tools, they are evolving, but whether it's the NIST AI framework or ISO forty two thousand one, even if you're using it from an informative basis on what to look for, what challenge areas to be aware of, you can start from a community led effort. That saves you political capital on we should roll this out. Now then you can slim it down.

speaker-0 (27:17.966)
Absolutely.

speaker-1 (27:20.408)
You can be like, these aspects don't matter to us, or these are only applicable in this area. And I mean, gosh, Chris, it would be a very different environment. Is instead of the business owner coming and saying, hey, I want to adopt this particular tool, be like, hey, we looked at these particular tools and they seem to comport with the the requirements that we're gonna have. you're you're driving the adoption, you're providing a menu as opposed to being purely reactive.

speaker-0 (27:48.562)
Yeah, well and then and then you're not the organization of no, right? You're you're that organization that is trying to enable business goals and business productivity, which th that always puts you in the right position, at least to to play nicely with others.

speaker-1 (28:02.732)
Yeah. And our place to play in that, we feel like is what are the operational characteristics of that organization? How do they validate those operations are going on, whether that's third party risk management and adopting an AI tool or how it's utilized once adopted? And then we can map that back to any measurement tool that we want. Name your framework. Yeah.

speaker-0 (28:23.954)
makes all the sense. before we go to take some questions, did you have any last words that you wanted to share with the the folks out there listening today?

speaker-1 (28:32.69)
I I guess my last words is something I've been thinking about a lot lately, is I think we always think about our industry as revolutionary, but I it is very evolutionary. And it is okay to be evolutionary in your thinking, right? Like you do not need to leap ahead of everyone else every single time. I have a very good ex-military friend that used to tell me, Justin, first market is the first target downrange. It's okay to be like

speaker-0 (28:44.366)
Morally agree.

speaker-2 (28:58.606)
Yeah, yeah.

speaker-1 (29:01.902)
Hey, this is our interest validated opportunity to your token maxing issue, our desires from an efficiency and a goal perspective, and our safety concerns from a risk perspective, and use that to guide what is the best path for your business.

speaker-0 (29:21.384)
Totally agree with you. I I guess I would add to don't forget the basics, right? We we we glom on to the latest headline, we play with whatever that technology is going to be, and more times than I can count, we do that at the expense of trying to understand how identities work in our organization or how we should be protecting data or how our network should be designed or or or or. I mean you you you run the gamut, right? There could be any one of those things.

AI is yet another tool in that tool chest that we're going to continue to use. It's not going anywhere. We're going to continue using it. It's going to continue to evolve. We're going to have proper governance around it. There's again, none of these things are in question to me, but you can't do that at the expense of all of the other cyber hygiene 101 things that you need to take into consideration. And so again, that's that's where I keep on coming back when I talk about IT governance, when I talk about

Agentic AI just in general. Those are the things that I always want people to remember. I again we could talk for another six hours. Fantastically good conversation. I know that there's a number of questions in our queue. Raleigh, wanted to throw it back to you and ask and try to answer some of the questions that are actually in the queue from our listeners today. No problem, Chris. Before we jump into the questions, I wanted to

Bring your attention to the free AI vendor evaluation checklist provided by StrikeGraph. This checklist will provide 35 evaluation questions on data exposure, testing, architecture, and governance fit. I will also be providing a link to this checklist in the follow-up email. So I hope you will check that out. So by the way, but by the way, Justin, this list is fantastic. I had a chance to finally go look at this and

It it's not meant to be a hundred percent comprehensive over every single thing. It is a are you thinking about these basic things in the grand scheme of things? There there is zero organizations that will not benefit by taking a look at this hundred thousand foot checklist to see how they fit with their AI vendor review.

speaker-1 (31:36.62)
No, thanks, Chris. I appreciate that. And I agree, you know, there's so much of this is specific to how you're thinking about implementing AI. And just whether you're NIST writing a framework or us helping set up this AI vendor review, you're going to ask some thousand foot questions that drill into the next set that are very specific to you.

speaker-0 (31:59.874)
Yeah. I I didn't mean to interrupt you, Raleigh, but I I wanted to mention that because this is a very cool checklist. Again, not a commercial. They're not charging for it. Go take a look at it. It makes all the sense in the world for you at least to go take a look. Yeah, definitely. let's go ahead and jump into the questions. Chris, I'll start with you and Justin. Feel free to provide your insights as well. The first question is how should assurance change when the system under review can give different answers to the same input?

Yeah. I I mean extraordinarily frightening. And and the the answer is that you you have to be able to evaluate the reality of whatever is and what it really is. if you have a solution that is giving variable answers depending on whether you cross your T's or dot your I's, then you probably should be looking for what the single source of truth really is. There are solutions out there that will help solve that problem, but

You if you cannot get a consistent answer, then you gotta be wondering what that consistent answer really should be. Justin, I know that you have thought about this a lot. Talk talk to me about how you would approach that.

speaker-1 (33:11.574)
Yeah, it it gets complicated. So I I just want to own this, right? Because what you're talking about is a range, you're trying to find the range of possible answers. So you're moving from, you know, in a deterministic computing system, is the variable true and false to what is the value from zero to one? And no values greater than one are allowed.

speaker-0 (33:31.128)
Yeah, we're we're not talking about and I I assume we're not talking about, you know, one plus one equals and if if I get any answer that is outside of two, then that answer is incorrect. We're talking about what is your favorite color. Yeah. And and so the the answers could be, you know, anything and everything under the sun, but i th what your favorite color is is not the answer to what is one plus one. And so

you you you have to take and understand what that's going to mean. So when you start taking and looking at, you know, the the differential and the the discrepancies in a log review for database access for let's say, there there is real data there that can show what's going on. If you run it again under different criteria, in theory you may end up getting different answers. But there are things to Justin's point that are very deterministic.

There are things that are very subjective. And so looking at the database log should not be able to determine what your favorite color is, probably.

speaker-1 (34:37.442)
Yeah. And in good testing, we solve for a single factor in the outcome, right? And I'll give you an example, Chris. We we used to take a series of records and adjust one factor in the records and submit the records back to the model and get new responses. And that would tell us, based upon this range of changes in that single data factor.

This would change the outcomes. So if I were applying a testing harness to the the log files, I would put a whole lot of different sets of log files that adjusted one aspect of that log file through the model to see the range of responses that I was getting out of it. Yeah.

speaker-0 (35:24.366)
That's right. Ton tons of unit testing and trying to understand what the the responses are gonna be.

speaker-1 (35:31.266)
Your testing harness gets like multiverse, right? Like it's not one test by

speaker-0 (35:34.414)
And so I I I knew a a CTO that had, you know, unit tests that I mean, for every line of code, he expected there to be like thirty unit tests. And and his code because it was of such a critical nature, his code was almost without bugs, right? So that that was awesome. But I am also not gonna fool you that the amount of time that they spent testing was exponentially greater than the amount of time they did developing.

It depends on your risk profile. And that's that's part of the whole conversation that we're having here. But if your risk profile is such where you absolutely need an a a a steadfast one hundred percent answer, then you had better test to make certain that you're getting the answers that you're expecting.

You didn't.

speaker-1 (36:21.902)
I agree with the risk profile. Interesting metaphor. I had a I was speaking with an exit beam executive this week and we were talking about doors that allow agents to operate. And his recommendation was you gotta put on an island. And so the metaphor, I think, today with our level of confidence and especially the LLM stuff, is that you you're not yet sure of all the outcomes that are gonna happen.

speaker-0 (36:46.71)
That's right. And and you better hope they can't s you you better hope they can't swim off the island.

speaker-2 (36:51.392)
Yes.

speaker-1 (36:53.513)
Sorry, Rally. Yeah.

speaker-0 (36:55.172)
no worries. I appreciate the additional insight. Let's jump into the next question. It is why do you put discovery ahead of writing the AI policy? Go ahead, Justin, you can take that one.

speaker-1 (37:08.62)
Yeah, I think this to me reminds me of the V2 model of software development. I'm not sure who all remembers that, but it was basically like write a good user story for what it is you want to do, design a specification for how that how that operates, write the test cases, then write the code, then come back the other direction. It is unique how we want to use these things. And we can certainly look to frameworks to help inform what to test for.

But your particular risk profile is going to be very different, the types of tech you're adopting, how you want to utilize it, what what your level of error tolerance is in that. And so that's why discovery is so important because otherwise you'll build a testing harness that might be unaffordable to operate.

speaker-0 (37:56.27)
There I I always go back to the conversation about logging. if you have a let let's let's date myself a little bit. If you go back to an old school 11i Oracle system, you can turn on all the logging and your system will do nothing but log. It may not be logging anything in particular, but it will log and log and log and log and log and log and log and log to the point where you're spending petabytes on logging and even that much on processing.

and very little on the activity that you're actually trying to accomplish with that. And and I always go back to that is f that example to talk about specifically you can take and design a system to be as risk tolerant or risk adverse as you want it to be, depending on what you believe. It all starts with a proper risk evaluation determining what that's going to look like. From there, then you can determine what you're going to do.

But every single one of those systems, every s system that there is, can be tuned you know, out of the box to be a little bit better, a little bit more lenient, if that's what you want to call it, in the grand scheme of thing. It really is going to depend on the organization.

speaker-0 (39:12.994)
Great. Thank you. Let's take one final question. It is when the regulatory target keeps moving toward less obligation, what should compliance leaders build toward instead? Yeah, I I almost reject that. I don't think that the regulatory frameworks are going to say that we're going to have less I I don't think that we get to AI our way out of liability and obligations towards

the end customer that our AI is servicing. I don't think that that's really the case. I really do think that we are trying to understand more as to how it is going to work, how it's going to be adjudicated, how it's going to be implemented and resolved. I think the AI models are going to continue making mistakes, but I always go back to this too by saying that you make assumptions that the people instead of AI

Are somehow infallible and not making mistakes too. And that's just not the case. I mean, let's let's take something very simple like an AI SOC agent right now right there. Is your AI SOC agent going to make a mistake? You're toot and right it's going to. I don't know what it is, and it doesn't really matter. But you're also then making the and then you get really upset that the AI agent made a mistake. Well, okay, I understand that you're upset about it, but then are you trying trying to claim to me

That your human SOC agent, especially your your tier ones, weren't making similar mistakes or the same mistake before? And the answer is of course they were. So I think over time we are going to get a level of confidence and understand what some of those governance requirements and liabilities are going to be. We're not there today, and we're trying to understand a little bit more. That's why we're all talking about this today. We're trying to understand more and more what that's going to look like.

And it's it's going to be constantly evolving. It's going to be something where the the GRC teams need to understand. And you you aren't taking and doing a risk analysis in a vacuum. You're not doing a risk analysis once and hoping for the best. These AI models are changing at least monthly, if not weekly. And so it might change your risk profile. That's that unfortunately or fortunately is the world that we live in. And every single time that it happens.

speaker-0 (41:32.662)
You GRC team guys, you business team leaders are going to need to understand what the impact is going to be on your business.

speaker-1 (41:40.77)
Yeah, I think i it it has been intriguing to, you know, watch some standards move forward, some laws move forward, and then kind of adjust. I think this is not something we normally see because a lot of times the standards have been so far behind the rollout of the tech that they had a lot of data on what the the real issues with that particular tech was going to be. So when ISO twenty seven thousand one finally came out, it was, you know, fairly well baked. 'Cause it was a

A known risk landscape. I think that a lot has shifted in this AI tech. And so I kind of understand why the EU AI Act has decided to pull some things back or or postpone. We saw this with CMMC a little bit, where the phased rollout was put on pause for a certain period of time as well. These are normal perturbations. They they are progress actually, as people try to adjust for the market.

And what's happening with it and make those and we just haven't seen it before because we weren't as closely aligned from time perspective.

speaker-0 (42:48.59)
That's right. Totally agree.

speaker-1 (42:50.466)
Yeah. But I would say there is nothing keeping any company from writing down the control operations that help keep them secure based upon the risks they analyze and validate it with evidence that they like. And that will unlock any future framework, you know, from a from a compliance perspective.

speaker-0 (43:10.51)
Excellent. Thank you, Chris and Justin, for all those great insights. And I wanted to thank our audience for taking time out of your schedule to join us. As I mentioned, you will re will be receiving a follow up email that'll include the on demand playback as well as a link to this checklist. So be sure to check that email out. Thank you again for joining us and enjoy the rest of your day.