AI-Savvy Lawyer explores the intricate intersection of technology and law, offering insights into navigating AI contracts, data governance, and legal implications in the rapidly evolving world of artificial intelligence.

Privacy and Security Are the Same Problem

In this episode of AI Savvy Lawyer, Rikka founder Charlyn Ho joins host Sean O'Connor to explain why privacy and cybersecurity can't be managed as separate problems. They cover what "reasonable security" actually means under GDPR, why U.S. privacy law is a patchwork of sector-specific statutes instead of one federal law, why data mapping has to come before any privacy program works, what to check in an AI vendor contract, and what a real incident response plan needs in place before a breach happens, not during one.

Transcript

[00:01] – Welcome & Introduction

Welcome to AI Savvy Lawyer.

Narrator:

Hello, everyone. Welcome to the Charlyn Ho, founder of Rika. Charlyn is a technology transactions and data privacy attorney who advises companies on artificial intelligence governance, complex technology agreements, and the legal frameworks needed to deploy emerging technologies responsibly. I'm Sean O'Connor, and today we're talking about why privacy and cybersecurity can't be treated as separate issues and how smart companies should be approaching them together. So, Charlene, good to see you.

Charlyn:

Good seeing you too, Sean.

Privacy and Security Are Two Sides of the Same Coin

Narrator:

I know we're going to have another, you know, rich conversation. Let's start with the, you know, the why of why can separating privacy and cybersecurity into different organizational functions potentially create legal and operational exposure? Like, why should they be taken, you know, sort of hand in glove.

Charlyn:

Yeah, absolutely. The way that I look at privacy and cybersecurity is they're really just two sides of the same coin. It's sort of the way you think of if you want to be left alone in your house and have privacy in your own house, you have to live in an area that is secure and there aren't roving gangs of bandits that will come and break into your house, as an example, just to make it you know an analogy that is tied to the physical world. In the digital world, which is typically where I'm operating as a lawyer, it's really the same thing. If you want to have privacy with respect to data, you also part of privacy, in fact, is ensuring that the data is protected administratively, technically, and organizationally. And I can break down what those terms mean, but that is a cybersecurity concept. So, the the law also treats these two things as related. For example, the General Data Protection Regulation of Europe, which is somewhat like the granddaddy of these more modern consumer privacy laws that are pretty broad, pretty protective, where privacy is considered a fundamental human right, they have requirements in GDPR to ensure data has reasonable security measures applied to it, and you will be less in trouble if something happens, like a data breach, if you've applied reasonable security measures such as encryption, for example. You know, GDPR was drafted well before 2018. It took many years to kind of go through the process, and it went into effect in 2018, and since we're in 2026 now, since then a lot has happened. And if you think about even back to the early 2010s, a lot, a lot has happened in the realm of digital privacy, technology, security. So, the law is intentionally designed to be broad, where it does not specifically say thou shalt apply this specific security measure or this specific privacy measure, but rather treats the concepts as kind of intertwined, and it is up to the what they call the controller, oftentimes, which is the statutory term. It's up to the controller to decide what's reasonable and appropriate given the sensitivity of the data.

Why the Law Lags Behind the Technology

Narrator:

Got it. Yeah, it sounds like again you've said in a previous episode that you know the written law, the statutory law is often lags, and so there is often more you can do as the controller of the data to ensure its security, even though maybe it's statutorily not required, interesting stuff. What are you seeing in terms of patterns when it comes to client engagements? Right. So there's a gap where there's a gap between privacy compliance programs and the way that the operations actually handle the data.

Charlyn:

Yeah, great question. So the the way that privacy law often works is somewhat not always, but somewhat divorced from the actual technology. The reason being, lawyers and and really legislators don't often have the deep understanding of technology. So, for example, I'll just give you a very kind of crystal clear example. It doesn't apply to every technology, but one of the areas I work a lot in is blockchain technology. So blockchain is by nature decentralized, and the data is stored, quote unquote, on all the nodes that are running the particular blockchain protocol. That could be, you know in many many places around the world, but let's just take a statute again like GDPR where there are requirements to protect a grand cross border data transfer without legal mechanisms mechanisms in place, but nodes are not people and they're not companies. So when you're essentially distributing data across the world in a technologically efficient manner, that may not really make sense operationally to require nodes, so to speak, to get a contractual mechanism in between them to allow for a legal cross-border transfer. So there are times to be truthful with you as a lawyer. You're really going for the good enough solution because the perfect 100% compliant solution is just technically not possible.

Why U.S. Privacy Law Is So Fragmented

Narrator:

Makes sense. Yeah, I mean it's that whole. I'm thinking about Senate hearings and you know like anything you're you're you're you're understanding and even the language we have for things are almost by nature backward looking, and you you don't even have the vocabulary to talk about or regulate. You know, like you said, blockchain. You know, it's like oh, we just take existing monetary rules and apply it. It's like it doesn't quite work that way, but we can adapt it. You know, this you hinted at this earlier, but the you know frameworks like CCPA or HIPAA and broader cybersecurity requirements that you know they're starting to converge in the way regulators approach data protections. I'm wondering why that is. I mean, you kind of hinted at it. I think we could guess why, but what do you have to say about that?

Charlyn:

Yeah, absolutely. So in the United States, we have what I call a sectoral approach to privacy, as compared to some other jurisdictions, for example, Europe, where they have a more omnibus approach. Although that's changing a little bit. What I mean by sectoral is, and I said this in an earlier episode, there is currently no federal privacy law, overarching kind of consumer protection focused privacy law. There's HIPAA which protects healthcare data. There's COPPA that protects children's data. There's GLBA which protects financial data. So there's a lot of privacy laws that deal with sector specific implementations. CCPA as a state level law is a comprehensive privacy law that regulates all different kinds of data, regardless of the industry. With the caveat which I'm about to get to, and you have a bit of a tension between the federal statutory regime and the sectoral kind of nature of it versus states. And California was the first, but then there was Virginia and Utah and Colorado. Now there's Texas, New Jersey, and the list goes on and on. And they're in a way adopting a more GDPR esque rule, but it only applies to the state. And CCPA, however, and all the other you know consumer privacy laws on the state level generally have exemptions for HIPAA data to resolve some of that tension. So it will say, for example, if data is PHI regulated by HIPAA, CCPA doesn't apply to that data. If this data is data regulated by GLBA as well, CCPA also doesn't apply to that data. The challenge becomes, then it takes a legal analysis and a lawyer to decide if, for example, someone's name is subject to HIPAA or GLBA or CCPA. Because, for example, my name in the context of being a patient is going to be PHI, especially if it's combined with things like my medical status or diagnoses or things of that nature, but when you have that same data field name, you asked an earlier question about the operational challenges and how that matches to law. A lot of clients that I serve have a database. You know, they have Google Docs or they have OneDrive or they have maybe they have something more formal. But are they really keeping someone's name in like 17 different repositories based on the law that's subject that's subject to potentially absolutely not, and that's again where some of the challenges of the law versus practical reality versus technology evolving so quickly and the law not keeping up; those are some of the challenges. That that's my job is to really help clients navigate this gray water and and try to keep them protected as much as possible.

Why Data Mapping Has to Come First

Narrator:

Yeah, that makes sense. I mean, we see it, you know, not just in AI, but in almost any industry where the you know the federal versus state laws are evolving at different paces, and then suddenly one's in conflict with the other, and and then within the privacy realm, where you know HIPAA versus you know you got kids versus medical, yeah, there's a lot. There's a lot of, I see where the confusion could come from. You know why is it so difficult to build a meaningful privacy program if a company doesn't know where its data lives or how it moves, the

Charlyn:

key thing to doing anything in life is to have an organized plan and a methodical way of approaching it, and it's no different with a data privacy program. Many clients of mine, when they're small, they're just fighting for survival. They don't have time to think about how to organize data, think about data retention. You know, how long should I be keeping data? What laws are it's it subject to? They're just you know fighting for survival. So the way I approach clients that are at a certain stage of life, more early stage of life, is going to be different than when I'm dealing with my large enterprise clients, that the regulators have their eye on these clients, and anything they do is going to be problematic for them. the The thing that is really important for everybody, regardless of the size, though, is what I call data mapping. I mean, data mapping is just a fancy way of saying map where your data is, for example, do you just use OneDrive, Google Drive? Do you have, for example, other tools, Otter AI, which is a note-taking tool that we use in our firm? Do you use Loom, which is another AI kind of screen record tool that we use? Every single tech platform that you use in your company is going to be collecting your data in some way, shape, or form. And data privacy is not just you yourself as a company, but it's all of these, you know, sub processors is kind of like the the term that is often used in the statutes. You know, what are your sub processors doing? What kinds of information do they have about you? And when I say you, I mean the company. And if you have to say honor a data deletion request or a data data modification request or any other data subject request, are you going to be able to know where that data subject's data lives? Are you going to be able to honor that request meaningfully, or are you not going to be able to, in which case that's a bit of a problem.

What to Check in an AI Vendor Contract

Narrator:

Yeah, I mean, you're more, I think, answered my my next question that I was thinking about. You know, the whole that's why it's so complicated. The AI tools complicate the situation because you've got all those the the subcategories, and yeah, I gotta I've gotta delete your data, but it's in six different places that I kind of forgot about, or I don't have the systems in place to to hit every to hit every one. Wow!

Charlyn:

Yeah, if you don't mind, I just want to kind of go back to one of the themes earlier that we spoke about in episode one, which is the contract. If you're procuring AI technology for your company, one of the really important things is going to be understanding data export, data retention, and data deletion. So, if you have an AI tool, how are you going to get your data out of that tool? Once you export that data, let's just say you you export it onto your own hard drive. That doesn't mean that the AI tool doesn't have a copy of it, right? Data can be copied and have there could be multiple copies in many different places. So retention and deletion are a separate issue, and then you have to understand how these data retention, deletion, and export provisions relate to confidentiality, because you know, in those agreements, the ideal outcome would be all of your data is your confidential information, not to be used for any other purpose besides providing the services to you. And then you also need to understand if some of that data is personal data versus non-personal data, then there's going to be other things in the privacy cybersecurity realm that we just talked about that may apply to a subset of the data, but not all of the data. So that's that's again where my experience is is kind of helping companies navigate through some of these challenging questions and the operational realities of implementing a legally compliant program.

Building an Incident Response Plan That Actually Works

Narrator:

Got it. Okay, so I want to I want to steer us towards maybe a little bit more of the the practical or tactical with the time we have left. You know, so I'm a you know I'm a company. I've evaluated my vendor agreements. I've made sure that you know I understand some of those points you just mentioned that they're included. You know the export of data and the deletion and and what processes are in place, but oh my God, something goes sideways, right? And there's a there's an incident, and so I'm curious. You know, what does a technically sound incident response protocol actually look like compared to one that you know only works on paper? Like it's one thing to, you know, write down what we're going to do, but as you said, there's often a gap between what's on paper and what the organization or the enterprise is actually practically capable of.

Charlyn:

Very good question, and that is something that I wrestle with a lot. First and foremost, this sounds really, really simple, but have a data incident response plans. Some companies do not have one, and when the occasion strikes, they say, "Crap! What am I supposed to do? Who do I call? And they're frantic about it, which is never a good state of mind to be in when you're trying to make significant decisions, particularly as data breeds. Is something that in in our privacy world they say it's not if it's going to happen it's when it's going to happen which is a terrifying prospect for me as a law firm owner because a lot of law firms have been the subject of ransomware attacks and because we hold lots of information of clients it makes us attractive targets, but many lawyers, even though we have a duty of competence to stay on top of technology, in I don't know, I mean not to bash on lawyers as a whole, but I would say, generally speaking, we're not the best at keeping up with technology, and so having an incidents response plan, firstly, is is very important. The second thing is to have those relationships built beforehand that you'll need if you have an incident. For example, a forensics person that can come in a cybersecurity firm, in other words, that can come in and go and do the technical things like put up a firewall or patch, you know, the software that has a bug, or identify what data has been exfiltrated, if any. You'll want to have that person like engagement letter with them signed. You don't want to be trying to negotiate rates and and details of engagement in because they're going to have you over a barrel if you're in the middle of an incident. They're going to be able to command whatever they want of you, because you're in a bad position to negotiate. So you want to have that relationship in place. Then you'll probably also want to have, you know, in your response plan numbers to call or websites to visit. For example, if you are being extorted, you know, you want to contact the FBI. There are certain numbers that you can report these incidents to the government, and I know there's movement in the in the government space to reduce potential liability if you report this because people are scared. They don't want to say, "Ah, this happened to my company, and then have a lot of liability by almost admitting that perhaps something they did was wrong. So those are just a couple of the basic points that I would say at the very high level of what to do.

Narrator:

Yeah, I love that. A have a plan, and then B just the idea of okay, let's almost like it's like war games. Like let's just walk down the list of if we had to put this plan into action. Okay, wait a minute. Who is the forensics firm we're working with? We don't have one. Oh well, why don't we get one under contract? Bring them in the loop. They know what kind of systems we've got here, so they can actually respond even more quickly. You know, beyond just negotiating a contract. Obviously, if they understand what you're running and where you're running it, etc. they can put they can put a solution in place probably that much quicker. Fascinating stuff, loving it, Charlyn. Loving it. Well, listen, we're out of time, which happens. Good to see you.

Charlyn:

You as well. Thank you so much, Sean. I really appreciate your time.

Narrator:

Yeah, we'll we'll talk again. Thanks for everyone for for tuning in. That's it for today's episode of the AI Savvy Lawyer. If you'd like to learn more about Charlyn Ho and the work her team does at Rica Group, visit the website rica group.com. And if you enjoyed this conversation, don't forget to like, leave a review, and subscribe to the show so you don't miss the next episode. I'm Sean O'Connor. Have a great day.

Narrator:

Thanks for watching. Be sure to hit that like and subscribe button, and leave us a review in the comments.