AI is changing the game for attackers targeting cardholder data and most businesses haven't caught up. SecurityMetrics forensic and cybersecurity experts are seeing AI-powered attacks act as a force multiplier, with ecommerce environments as the primary battleground. PCI DSS 4.0.1 wasn't written specifically for AI, but it was written to be reactive to risk.
In this webinar, you'll learn:
- The top cybersecurity trends we’re seeing in 2026 and what that means for your environment
- Which PCI requirements matter most for AI-driven risks
- Where most organizations are still exposed, even when they're technically PCI compliant
- Answers to the questions we hear most often from teams navigating AI adoption
How Does AI Impact PCI Compliance? Transcript
AI. It's reshaping how threat actors are targeting cardholder data. They are moving faster than ever and maybe faster than your compliance program can keep up with it. On today's webinar, we have some very special guests. We have Jen Stone Needs No Introduction, right? You're probably familiar with her.
And if you've ever watched any of our forensic prediction webinars that we do along with a lot of other stuff, we have Aaron Willis here from the forensic side of the house.
I'm Hef. I'm your your host. I'm on the cybersecurity side running our SOC and our threat hunting teams. I know we spend a lot of time together, Aaron.
We Talk about those forensic predictions.
It's a pretty good webinar, right?
And I want to hear more about that. How are the results for your top four forensic and cyber predictions for twenty twenty six?
How accurate are you so far?
We talked about AI as a force multiplier.
Yeah, that's been some.
Man, have we seen an increase in the amount of AI assisted attacks going on, Hef?
Yeah, the good thing is, though, us good guys are fighting back. We are absolutely deploying AI in the field to try to stay ahead of the speed at which these attacks are happening.
Half my day is spent building AI assisted forensic tools.
That's a lot of work. Yeah, that's how much time we have to spend battling this AI stuff and staying ahead of all these attacks that we're seeing.
I love that we've got these four predictions, Jen, and we were so right on the money with all four of our top predictions this year.
Yeah, we've got agentic AI that we're seeing now, bots that are going out, smart bots, things we've never seen in the past that can go out and drill holes through websites and ecommerce sites like we've never seen before.
I know the primary battleground, it seems like it's the ecommerce, it's the healthcare. We're still seeing that.
We're still seeing a lot of credential compromises happening.
Some of the basic stuff, session hijacking is still around, but all these things are being assisted by AI.
One of our other predictions that we got right was about the session hijacking and the credential compromise.
Stolen credentials are still the thing that bad guys are going after session token theft is part of it. I know we've all seen a lot of the automated MFA attack, we call it attack fatigue, because it really is.
MFA fatigue is a very real thing.
But one thing that I do want to call out is I'm blown away guys about in the news, the velocity of vulnerabilities being found and the number of zero days. It wasn't like just like a month ago, or not even a month ago, that Microsoft, like five hundred vulnerabilities announced in one week. That was insane. And then like a week before that was two hundred vulnerabilities.
Well, there's also the humorous case of Claude Mythos. Claude Mythos, yeah.
Where it was too dangerous for the public to get their hands on, and of course that just made us all want it more, right? But it found supposedly half what was it? How many exploits did it find?
Yeah.
It's like I thought it was like five thousand if I remember.
It was some insane number.
It doesn't make our job any easier. I know, Jen, I'm excited to get to your topics, but I just wanna remind the audience as well, If you'd like to see that forensics prediction webinar, you could absolutely take a look at it. It's on our on our YouTube page, and we'll include the link. But Aaron, in your world, before we get to Jen inside your world, you're doing a lot of ecommerce, a lot of forensic data investigations, something like how many cases this year alone?
Thousands of cases.
Bizarre.
E commerce cases are really what we've been focusing on.
Over two thousand of those in a And what we're seeing is that almost a hundred percent, maybe even a hundred percent of all the attacks that are happening, all the successful breaches are still happening on the merchant side. Even when they've moved over to iframes or things like that, the attackers are getting in on those websites that maybe they have a little bit less security because the merchant is depending on the security of that iframe. They're getting in and defeating those iframes through various clever techniques that are allowing them to pull the credit card data right out of the iframe.
So so damaging. I know you guys have a lot of findings. There's a lot of things that you're seeing from the shopping cart monitor.
Product that we have is phenomenal, how it's evolved from my perspective, outsider looking in, can you kind of share some of the findings that you're seeing from that in twenty nineteen?
Yeah, our shopping cart monitor, we're monitoring tens of thousands of live active e commerce sites. We're finding over one skimmer a week right now is our average.
And where is that skimmer being found? Is it in the browser? Is it somewhere else?
It's being found specifically in the browser, often on the checkout page itself, really hidden in third party code quite often, or in merchant scripts that they've included there.
But we're finding them so often now in third party plugins, code included from the database. You know, if you think about what that database is, it sits out on the server and it's not being scanned by anything, really.
So scripts in the database can sit there for a long time and you can scan the server, you never see them until they're included on the checkout page in that rendered HTML page. And so if you don't have eyes in the browser at the moment of checkout, that script may come in at the very last second. It may be triggered just by somebody entering the credit card field.
And then that script gets pulled from the database, runs for just a split second, and then vanishes into the ether.
I'm glad we're gonna dive into that a little more later, because there are so many people who don't recognize how easy it is for this attack to execute, but you're seeing it all the time.
Yeah, we're seeing stuff even in local storage on the browser.
Credit cards being stored there, malware being stored there. Really?
Yeah. Wild. Crazy. I know at SecurityMetrics, one of the really cool new pieces of tech that we introduced was Spectre AI.
I know I've heard from a lot of folks say, what is Spectre? What does it do? Can you just take a super brief moment to kind of explain what that tool is and what it's doing?
Spectre AI is kind of derivative or an enhancement over our original Spectre tool, which went out to millions of websites, would grab anything it could see on the landing page and do a quick analysis and send back any IOCs or things that we found that were one hundred percent associated with data breaches.
Spectra AI is an enhancement on that, where we actually use AI to determine if we're seeing anything malicious on that page.
It's really making those static looks a lot more intelligent.
We can pick out things now that we just didn't have the time or the bandwidth to see. We can feed that data to AI and pick out things that are hidden in code that a human eye just wouldn't be able to see.
At volume and at scale.
Yeah, at volume and at scale. And so, we're gonna share some of those findings too, and it's fascinating what Spectre AI can pick up. We've recently found hundreds of different attack vectors and malicious actors moving in ways that we've never been able to see before.
Before we get off this topic, I am dying to know that we don't get a chance to always talk and share some of the really amazing stuff that we find, but I know you've had a bunch of case studies just in the first six months of twenty twenty six. Can you take a brief moment to share maybe one or two of something that just blew you out of the water that maybe our audience would love to hear about?
One of the craziest things we saw this year, and this is just recent in the last few weeks, we found a skimmer running on a page that had all the security in place, including an agent running specifically defined JavaScript skimmers on the checkout process. And this is not a low budget skimmer.
This is one of the premier agents are That missed it.
Yeah, that flat out missed it.
And it had to do with the way the merchant was processing, how they were rendering HTML on the page. They were infecting a JSON object called NextData from the Next. Js framework.
And so in that framework, everything gets put together server side, and then as it gets pushed to the client side, it hydrates and it adds in all the little elements that the customer needs to check out.
And so they were able to bypass all of that, and they did the most crazy thing. Instead of stealing a credit card, they logged the keystrokes, old fashioned key logging. And the security software that was running the agent missed it because they were just capturing it, putting it over in local storage, and then they didn't pull it out right away. Woah. They didn't go grab it and reassemble and say, Oh, hey, we've got the credit card.
Every once in while, just reach into local storage and pull out the keystroke, pull out another one, just a little bit at a time.
And so the software that was there, the agent, completely missed it.
So if we had to summarize here, because I know we have a lot of folks in the audience that are on different sides of the business. Some folks are, you know, you're on the compliance side of the house. Some of you are on the cyber. You're really deep in the audit world. Kind of summarize for us how that threat landscape has changed. It seems like compliance auditing does not stop at all mixed with this new tech that we're rolling out.
What's that world like if you had some other Well, it's real time, is really what is happening.
The threat landscape is active, it's dynamic, it's changing.
We have agents on pages that we think are picking things up, but that agent got defeated. And we found it because we have an agentless solution.
We were able to watch things happen sort of after the fact.
And the neat thing about an agentless solution, Hef, is the attackers don't know we're there. And that's really what allowed us to find that breach we were talking about, is they didn't know we were there watching. Wow. The moment they can see that an agent is there, that gives them a whole lot of information to work around, right? They can find the holes or the chinks in the armor.
Yeah, yeah. Your team has done a phenomenal job of just finding these threat actors in the browser, in the shopping cart area. And I just say kudos hats off to what you guys been able to do for the previous six months and what's left here going towards twenty twenty seven. I know in Jen's world, Jen, the auditing world, right? What's going on?
I'm hearing rumors about confusion around PCI DSS at your point.
There is because here we have this big artificial intelligence thing happening, and people are saying, Well, 4.0.1 doesn't say artificial intelligence and address it. But it doesn't have to. Instead of saying, We need to address artificial intelligence, instead we say, In what ways are we using artificial intelligence that's already covered by PCI DSS? And it is. Let me give you a few examples, and then you'll totally start getting the pattern. For example, data.
Who's allowed to see full pan? Who's allowed full access to cardholder data? And so who are you sharing that with? Well, if you're sharing it with AI, then you've gotta have a business justification for that.
Typically, we're not gonna wanna share that. It better be internal, private, fully locked down if you are in some way having AI interact with it. So you'll think of it that way. So who's getting my data?
AI is another we've got applications and systems and human beings that need to be justified and protected in certain ways, AI falls right into that. And that leads right into requirements seven and eight, access and authorization. Right? So the access and authorization, it still has to run with least privilege, and it still has to be fully justified and authorized.
So all of the requirements there fully apply to AI.
Let's look at secure AI workflows and code. A lot of people are using code or AI to help develop code, right? Well, you still have to apply the secure software development life cycle, all of the requirements in requirement six, to whatever your AI is doing to help develop code. So I'm not gonna dive into every single one of them, but I just wanted to show you a pattern of if AI is doing a thing and it falls into a certain bucket, you have to apply those requirements to that bucket. And I I really think where people got confused was it didn't explicitly start using the words artificial intelligence, but there's it doesn't have to.
Yeah. I there seems to be a lot of confusion around two requirements in particular. I wanna take a brief moment to kind of dive in what you are seeing out in the battlefield. Yeah.
Requirement six forty three and requirement eleven sixty one. Script security and FAQ fifteen eighty eight. Yes. What what is going on in this world?
Can you decipher and clarify?
I'm so glad you brought up FAQ fifteen eighty eight because there is, and I really, my heart goes out to any merchants that have e commerce because this is, this was implemented in a confusing way, and it's critical because this is where we're seeing data actually being lost. So let me run you through it. So we we care about protecting scripts on a page because the scripts on a page are what's stealing cardholder data. Right?
So 4.0.1 came out, and originally, and the SAQ SAQA said, Hey, you have to now protect scripts on a page. And then, they said, Oh no, you don't. Or it seemed like they said, Oh no, you don't.
That's where the confusion hit.
They didn't actually say that because as we can see from FAQ fifteen eighty eight, this is still a problem, and it's still something that you need to address. And it's kind of hidden if you don't read the entire thing, you should read the entire thing.
Go and read the SAQA eligibility requirements. So criteria, the eligibility criteria.
And the eligibility criteria say that you need to protect the scripts on a page as if it were six, four, three, and eleven, six, one, but it does it in a very lightweight, oh, and by the way, you gotta do this.
Fifteen eighty eight really locks this down for us, and the council tells us you protect your SAQA environments in one of two ways. You can meet the compliance requirements in one of two ways. Either get your service provider to say that your environment is not susceptible to these kinds of attacks, which is insane.
Although, I mean, they're impossible to A couple of them did it very, very early, and then they suddenly went, Oh no.
We cannot. Because they can't.
Yeah.
Right? So that also confused people. Like, Well last year they said they would do this for me. Why aren't they doing it this year? Because they learned.
So you either have to get a very well documented written confirmation from your payment provider saying that the embedded solution protects the merchant page, or you have to implement script management and tamper detection. And that is what every Yeah. Here's why you should do it. That's why we're seeing the breaches.
I have kind of a love hate relationship with six forty three and eleven sixty one because it's so important to protect your data, and at the same time, it's really hard for a lot of merchants to understand. They felt a little bit whiplashed over, how do I accomplish this? So I get it, and it's frustrating, but it's real, and you should be doing it. There's another little aspect of it too, and that is, is this only if I most of the time people are like, well, I have an iframe.
It makes it an SAQA. Yes. That's a real clear use case for having six four three and eleven six one in place. But then there's, well, what if I do a full redirect?
Yeah.
Okay. I'm gonna tell you what the council says so that you can pass your audit, and then Erin's gonna tell you why you shouldn't skip this.
Pay attention.
Under FAQ fifteen eighty eight, full URL redirects completing the SAQA are exempt from requirements six forty three and eleven sixty one. However, that's so that you can pass your PCI. Here's what you do if you actually want be secure.
We've seen a three hundred percent increase in merchants using payment redirects because it's an easy way to get around all this stuff, Absolutely easy, yep.
And the hackers and attackers are all cheerleading it. Why? It's so much easier to defeat a payment redirect than it is an iframe. Yep. And we are seeing a corresponding increase in the number of attacks against payment redirects. Think about it, an iframe is a security box around that payment data, and an attacker has to know what they're doing to get in and defeat that iframe. What's a payment redirect?
Click. Click. It's a link.
That's all it is.
Is there anything around that link protecting it? No, the hacker just literally goes in, changes the link, and now your customer doesn't go out where they should, it stays right on your site usually, or to an attacker's site that's duplicating, mimicking the real payment checkout, that's far, far easier. And we're seeing some pretty sophisticated attacks where the payment's still complete.
Yep. That's wild.
Everybody's happy.
That's the argument that I get from my merchants is, well, everything's fine. We're still getting payments. That does not mean you have not been breached.
That's safe.
Just because the bad guys got your cardholder data doesn't mean you also didn't get it. Right? That can be used for two purposes, the intended and the not so intended.
There are so many questions that have come into us. At the very end today, we're going to take some time to try our best to answer all the questions. But if we don't get to your question, you know, you can always send it to us. You pick up the phone and call us, and we'll do our best to try to make sense of the insanity that's going on right now in the last six months. Jen, help me out and understand the requirements that are impacted by AI, the PCI requirements impacted by AI. There's quite a few. I was actually kind of blown away that there's this many.
If we could kindly start with maybe twelve point three, twelve point three one, twelve point three four, target risk analysis is a big buzzword right now.
It is. Well, targeted risk analysis is intended to look at a specific thing that you're trying to make decisions on. How often do we, for example, test for skimmers out in the wild. How frequently are we scanning a certain thing?
So it's usually around the frequency of scanning, that type of thing. Well, if you haven't gone and looked at what you said before and then asked yourself, How does AI and the acceleration of the bad guy's activities affect this decision? Then you haven't got your bases covered. So really, every targeted risk analysis should have you stop and say, Does AI affect this?
If it does, let's redo it.
So if I adopt a new AI tool in my business, should I do a TRA?
Oh, you know what? If you adopt a new tool in your business, not only should you do a new TRA for all of the ones that apply, you should also say to yourself, hey, this is a major change to my environment. And then you review all of the things that a change to your environment would trigger. So, new ASV scannings and potentially looking at your scope.
AI could expand your scope. Probably does. And so making sure, where does my AI live, and where does my PCI network, and are those in any way related? So making sure that you have updated all of the ways in which anything can interact with cardholder data, including AI, could trigger new network diagrams, new data flow diagrams.
Right?
Sounds like so much work, but it's worth It it really is.
But also, if you have AI help you, it can help.
Requirement A is MFA. You know, it's not just about knowing these new tools and having a risk analysis done. But MFA, the access to it, how has that been impacted?
Multi factor authentication is one of the most important things that we see in helping people keep the bad guys out. And yes, we all kind of get tired of having to put in a code or whatever it is that we're doing for the MFA, but it's critical for us to be able to, in some way, lock down our environment. MFA has to be everywhere across administrative and remote pathways. I recommend people do it everywhere. So anytime that you can get access to cardholder data, that's a place that you need to apply MFA.
Requirement twelve point six three is something that is near and dear to my heart, especially here at SecurityMetrics where you're talking about updating your phishing training. There is so many different types of AI generated phishing examples that are out there from the news that you could pool and share with your team, share with your employees.
Could we spend just a quick moment though on requirement twelve point eight? How has that impacted? Because I'm hearing a lot from my friends and business owners that that is a big deal to them.
Third party service providers. And a lot of people aren't even thinking, oh, this AI that I'm now using is another third party service provider. It is. And so you have to make sure that you are taking that into account as you do all of the twelve point eight sub requirements.
Okay. Jen, summarize for us. Give us a key takeaway. Would that be about the changes that you're seeing on the battlefield right now?
PCI DSS is reactive to risk related to cardholder data. And it's not that AI necessarily is creating different risks, it's accelerating the risks that exist. Because AI can do all of the current and previous threats faster. So it has to be taken into account when you consider not just what are the threats, but are the threats accelerated?
And then apply the right security controls that We're going to switch gears for a moment.
We're going to get to your questions here in just a moment at the end, but I think it's really important we address this concept of compliance as a security floor framework. It is not something new, folks. This has been around for a very long time. But from an understanding, from a practical cybersecurity strategy, it's really more important than ever when you talk about the persistency of these AI threats and how do you stay compliant. And just because you're compliant doesn't mean you're secure.
So let's dive into this. There's three tiers on this framework. What is tier one all about here? Continuous compliance, is that right?
It really involves real time monitoring, watching when it's going. Compliance is not an event.
It's a moving iceberg.
Yeah, you've got to be on top of it all the time now.
Tier two is about extending the controls, coverage for AI.
AI usage policies, do you have a lot of conversations with clients about that at all?
You know, it's surprising to me how many people haven't updated their acceptable use policies to include whether AI is acceptable or not.
A lot of people are kind of afraid of AI, and they don't want to consider it, and so they don't. Which is, that's not a good way to think about a risk. And so being willing to dive into something that's uncomfortable and say, how do I look at all of my policies and procedures, how do I look at all of my targeted risk analyses, how do I look at all of my training, And then modify it for the reality, which is AI.
Three to four years ago, all the rage of conversation was about do you an AI usage policy? Do you have that place? Now it seems like the conversation shifted more towards are you doing deepfake simulations? Are you testing for that kind of stuff?
Should be.
So tier one continuous compliance, tier two we're talking about extending controls for AI, tier three it shifts the conversation to getting a really nice baseline around PCI DSS four point zero one.
Really about knowing what's in your browser. So inventory.
Script inventory.
Script inventory. Know what's on that checkout page. In the old POS environments, we knew what was on the checkout server, and it was hard to get something in there. You had to go through all kinds of hoops to get something approved. Now, we have found hundreds, three, four hundred scripts on a checkout page.
Is a massive surface On a single checkout a single checkout page.
And if you think about that, that could be hundreds of thousands, if not millions of lines of code that all have access to the credit card data on that page.
Wow, I mean, if you are not doing targeted risk analysis scenario planning and simulations, And I mean, I know it's sometimes a struggle when you're trying to run the business day to day, but knowing what the potentials are, what are the potential doorways in your business? It's such a challenge.
Oh my goodness. All right, let's talk about before we start to wrap this up. I know we had some really good questions. They come in all the time here.
And I feel like this is the perfect venue to cover some of these questions. Let's talk about question number one. This one came in about redirecting customers and we kind of briefly touched on it. Maybe there's some good takeaways here.
Redirecting customers to a hosted payment page. We're talking about SAQA.
Are we legally required to comply with six forty three or eleven sixty one?
I love this question, it's so juicy because it has so much in it, because it used the word legally, and a lot of people think that PCI DSS is a law. It's not, it's not a law. It is a standard that is required by the payment card industry. However, if you are an SAQA merchant and you're not fulfilling your obligations by meeting that, a lot of things can happen that, including they'll take away your ability to accept credit cards.
You don't want that as a merchant. You want the ability to accept credit cards, right? I'm not saying that that's like the first thing that happens. I'm saying that if you don't become compliant, eventually there is an end stop and that's it.
So setting aside the legal thing, do you need to comply with six forty three and eleven sixty one if you redirect? According to PCI DSS, FAQ fifteen eighty eight. You are not required to. You can pass your PCI compliance without doing anything about six forty three and eleven sixty one, but I'm here to tell you it's a bad choice. Don't do this because you don't want to lose card data. You want to be secure. Please use your judgment in this and implement these things.
This is a good segue to if our merchant site uses an iframe, how do we satisfy the script protection rule in FAQ fifteen eighty eight?
Kind of a same realm. Just do it. So either get from your payment service provider that you are not don't just here's the other thing I wanna do a little bit of nuance. I got a customer that said, my payment provider said, I am an SAQA, so I don't have to do this. And I'm like, that's not what this says at all.
Just because they told you that you're an SAQA, which they were, doesn't mean you don't have to do this. They have to tell you formally in a written statement that you are not susceptible to the risks that are covered by six forty three and eleven sixty one. Nobody's doing that anymore, so you need to put in six forty three and eleven sixty one.
Next question that came in, I thought this was a pretty good one too, does an agent based protection tool fully satisfy requirements of six forty three and eleven sixty one? What are your thoughts around that?
I mean, agent based tools are absolutely better than nothing, Hef.
Yeah.
In our example, we showed how an attacker knew the agent was there. It could monitor that agent's behavior, find its weaknesses, and make an exploit for it. They're not bulletproof. They are not bulletproof. And so, absolutely, you want something in place and an agent is better than nothing, but something like an agentless solution where the attacker doesn't know what's happening, it gives them nothing to, know behavior to see, to get around.
I like the concept. We've talked about this for decades, defense in-depth. When you're pairing a client side control with external agentless monitoring like shopping cart monitor, I think that's a winning combination for answering this question.
All right, another question that came in. What qualifies as a payment page script under PCI DSS four zero one? What is this, any script?
Any script that can interact with that payment page. So that's a pretty broad label.
Payment fields, would you include that? Absolutely, payment fields. Analytic tools. Analytics tools. Marketing pixels, tag managers, I mean the list goes on and on.
It really does. Even if you have a full payment redirect, that one link may qualify as a payment page.
Wow. We had another question that came in here and that is around the notification obligations. What am I required to do under eleven six one? If an unauthorized script change is detected, what's the step? What's the process? Is there one?
Mean, you have to immediately notify. That's part of eleven point six one. Immediately.
So whatever you're using for your tools to find out that, it needs to give a notification right then. And then people need to dig into it, find out what's going on. So that's also kind of tied to other notifications, like who else needs to know besides the people who are digging into it, Is there follow on notifications? Well, yes, there's merchant agreements on who they're supposed to tell and under what timelines to let other people know that either that there was an incident that's being investigated or that there was a known breach of data. So it really depends on your agreements, so knowing those contractual agreements is pretty important in this case.
It seems like it could get really messy really quickly depending on what state you're operating in or what country you're operating in.
Is so important too, because oftentimes when we go into a forensic investigation, we find out that there were tools running that caught things that would ended it early.
And we find out nobody's paying any attention. It went to an email account that nobody's reading or they read it once a month.
Yep, you have to read those every It has to be a full conversation for it to be an immediate notification, Not just a shout in the dark.
And you have to be watching every day, reviewing those alerts every single day.
Okay, We had a couple AI questions that came in and some regulatory questions. We have to get to these. I think they're so important for the audience. If I adopt an AI powered chatbot or a search tool, I'm putting it in, embedding it in my website or there's a website trigger or sorry, will that trigger a risk assessment if I start embedding those chatbots or search tools?
Absolutely. Because it changes your environment in significant ways that you have not gone through any kind of a risk analysis for previously. So definitely it triggers risk.
Doing that TRA before you deploy is so critical.
Alright, you gotta know the boundaries, data boundaries. Let's talk about also this question came in. What specific evidence will PCI assessors look for to verify that your security training covers AI threats? What kind of evidence are you looking at?
Yeah, so a lot of times we'll say, can you give us a summary of what's being taught? What are the modules? We wanna know what are those modules, and then a little bit of detail in them to make sure that it's really covering AI related things. And especially, if we can, we'll say, is this training applicable in ways that the person getting it can apply it in their job.
So we try to look at not just are you throwing information at people, but is it something that's immediately applicable to the people who are receiving it? And then, did they actually do the training? Did they complete this training? So the best training out there has modules that are are modifiable, and then there is a usually some sort of a test associated with it, not just I push play through all of these things, but something that tells us that people are intaking the information that is necessary, and then hopefully some sorts of phishing simulators.
Simulators for any kinds of AI attacks, really.
Great question, by the way. We're going end it with one final question here, and this is a toughie, so you might need some time here to think about it for the audience and for us to answer it.
Is there an operational risk difference between employees using public AI tools versus private enterprise level AI tools? Is there a difference?
I think there is. There's a massive difference.
You mean it's not all just Claude? What, I'm using Claude. My company says I can use Claude. What are you talking about?
There's so many options out there right now from free chat GPT. Things you can just go to a browser and start using AI now. But if you think about what's happening to the data that you're entering in, you are training that chatbot that you're interacting with.
And so you can inadvertently share private data publicly, not necessarily directly, but things can leak out in indirect ways.
We've seen cases of intellectual property leaking out through these public AI chatbots, where you're entering things that nobody should know about and that AI is trained on it, then somebody else in a different country can be asking that chat bot the same thing and says, oh yeah, I know a solution for this, there goes your intellectual property.
I think that's so hard for a business owner to understand how critical it is that you give people the tools they need that are approved, that are within your boundaries of what risk you're willing to tolerate for your business success.
And I don't think that a rational response is, well, we will not use any AI in our business, because if you don't give your people the tools that are locked down and controlled by the enterprise, they're going to go use public tools. They're going to use what they can because they want that boost in productivity or that ease of understanding. And so give them the tools that are locked down, and then that you're going to reduce your risk of them going to a public non lockdown.
Heartbreaking. So there you have it, We have Jen Stone from the audit side of the house at SecurityMetrics. We have Aaron Willis from the forensic side. We've got Mihef here from the cyber side. As we wrap it up today, it's fascinating the world that we're in, right? There's no brand new compliance laws as of the recording of this video.
AI didn't change the rules. It just raised the stakes. Absolutely.
Alright. Well, there you have it, Thanks for joining us. As always, share your questions. Give us a call or or email us. Let us know. Stay compliant. That's what we do here at SecurityMetrics.
.svg)