Navigating Privacy and AI Risk...Transactions - Rikka Law Group

AI-Savvy Lawyer·Episode 3 of 3

An incident response plan has little value when nobody knows how to carry it out during a real breach. Charlyn Ho recommends testing the plan so each person knows who to contact and what action to take.

How Smart Companies Structure Tech Deals

AI is moving faster than your legal foundation can keep up. Rikka helps growing tech companies deploy AI, protect data, and close deals without creating legal risk they didn't see coming.

In this episode of AI Savvy Lawyer, Rikka founder Charlyn Ho joins host Lisa Mosby to break down how smart companies structure technology deals without creating risks that surface later. They cover why privacy compliance is never a one-time achievement, how AI tools add a new layer of privacy and cybersecurity risk, why third-party vendors are usually where the real exposure hides, what actually separates a working incident response plan from one that just sits in a drawer, how technical architecture decisions shape what a contract needs to cover, and the open source licensing and integration-clause pitfalls that catch companies off guard.



Lisa:

Welcome to the AI Savvy Lawyer with Charlyn Ho, founder of Rica Group. Charlyn is a technology transactions and data privacy attorney who advises companies on artificial intelligence governance, complex technology agreements, and legal frameworks needed to deploy emerging technologies responsibly. I'm Lisa Mosby, and today we're talking about how smart companies structure technology deals without creating risks that show up later. Thank you so much for joining me, Charlyn.

Thank you, Lisa, for having me. You know, it's my pleasure. And what I want to know is 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. That's a great question, and it's a question that we help our clients think through all the time. So many people think of privacy as a one and done thing. They say, "I am GDPR, which is the General Data Protection Regulation of Europe.

I'm GDPR compliant, or I am HIPAA compliant, which is the healthcare privacy law on the federal level here in the U.S. but compliance is not a one-time thing. It's not like I've achieved a healthy state of being in you know our normal day of daily living. We actually have to work to it. We have to exercise. We have to eat right. It's very similar for privacy. So if you don't know where your data lives, you can't actually be compliant. A lot of the privacy laws require you to say, for example, store the data with sufficient protections based on the level of sensitivity of that data. So, for example, if it's healthcare data, you have to do things like encrypt it at rest and in transit. You can't just leave it out in the open on a Google Doc. And a lot of companies have gotten in trouble. For example, if they have raw data sitting on a laptop, and one of their employees goes to the airport, goes on a flight, forgets the laptop, and bam, all of this data is now exposed. So that's one of the challenges: is that it's not a one-time exercise; it's an ongoing thing. And data, because it's so prevalent. All of us in our daily lives as white collar workers have access to computers and tons and tons of data, and that data can be siloed across the marketing department, the IT department, the accounting department, the legal department. So when you're talking about compliance with different privacy laws, an organization needs to go and understand how all of that data across its different departments lives, how it's organized, where it's stored, who they're sharing it with, and how it's protected.


Lisa:

How do AI tools complicate both privacy compliance and cybersecurity posture at the same time?

Charlyn:

So AI is the word on everybody's lips these days. AI this, AI that, and it is truly transformative. This technology, but it also has significant risks when it comes to privacy and cybersecurity. Why is that? It's because AI tools not only provide an ability to generate output based on your prompt, but it actually takes other people's data and learns from it, and uses that information to train the AI to give you the prompt output that you're looking for. Hypothetically, you're saying summarize this document for me, and the AI is what's called probabilistic, so it's learned from 1000s, maybe even millions of other emails or documents, and learn what summarize means. And when you're putting your data into the AI, depending on what you know settings you have, what enterprise tier or lack of enterprise tier you have of that AI model, your data might be in the same repository as everyone else's data. And so, if you have, let's just say, a confidential memo to the CEO about something that you don't want to get public, if you're not careful with the data and you put it into an AI system without looking at the proper settings, and what I mean by that is like ChatGPT, Claude, Gemini, they all have settings that are labeled privacy or security or something similar, where it explains what controls you have over the data and what the model provider is allowed to do with that data. If you don't pay attention to that at all, the default is that the model can train on it, and then this confidential memo may potentially go into this larger repository, and you never know it could come out on you know somewhere else where you don't want it to be.

Lisa:

And Charlyn, why do third party agreements often become the biggest exposure point for companies when it comes to privacy and cybersecurity risk?


Charlyn:

So third party agreements are actually part of a broader umbrella that I would call vendor management. So Let's just say back in the olden days, when you were delivering mail by paper on horseback, you would deliver the mail from one person to the other person. It was a very streamlined and simple kind of transmission of data. Nowadays, when you talk about the internet, you have data sitting in multiple different repositories with multiple different third-party vendors. Just to give you an example, even on this podcast that I'm doing right now, I'm using my Lenovo computer, but I'm using a Chrome browser, and we're using a certain podcast recording software. All of those are different third parties, and they're all touching the data. Not to mention Verizon or Comcast, whoever the internet provider is, that data is ultimately transmitted through their pipes, you know, their cables to the end destination or multiple destinations. So, third-party agreements or third-party paper are critical to manage this web of vendors. And a lot of regulators in the privacy space are much more cognizant of the fact that many things relating to privacy and cybersecurity don't happen at the high level of the company that actually gets in trouble at the end of the day. For example, Target had a big data breach, you know, a few years back. So did Home Depot. It wasn't necessarily them themselves that had the breach. It was one of their vendors, and that's why it's really, really important to have a kind of trusted transactional lawyer that helps you understand that web of relationships and make sure that if and when that incident happens, because as we said in the last episode, it's not if with data breaches. Unfortunately, it's when you want to make sure that you have that legal protection.

Lisa:

And what does a technically sound incident response protocol actually look like compared to one that only works on paper.

Charlyn:

So that's a really great question. You have policies and procedures in place, and that's a critical portion. I'm not diminishing the importance of having a data breach response policy or an incident response policy beforehand. What does that mean? That means, how do we even know that there's a data breach? What types of monitoring are we doing? There are different types of things, for example, antivirus software. There's also penetration testing, vulnerability management. There are different technical ways in which we can keep an eye out on vulnerabilities in the digital realm. So that's one. It's just having the the right tools, the right technology, and the right partners. You know, many companies, unless they're specifically in the cybersecurity space, need to work with a vendor in order to accomplish this. Number two is if a breach is identified, what do you do? So who do you talk to? You know how does the information spread? Does it go to you know if a lower level person in the organization learns about it, who do they report to in their chain of command? And then if the CEO learns about it, who do they talk to about remediation? So hopefully the plan means that it's already known who's gonna get reporting, how the chain of command works, and you have a cybersecurity vendor or forensics vendor investigator on speed dial, so that when that happens, you can get someone right away to come in and mitigate the breach. Because if it's sort of a an ongoing situation, you don't want that data to continue to be flowing out. You want to have someone who's an expert in this come in and patch the breach. But the paper simply provides the plan. If you can't execute on the plan, that's where things break down. And so there are these helpful things called tabletop exercises, where you can simulate a breach and go through the motions just the same way as you would train for any event. You would actually kind of simulate it in real life, so that you have the practice of when and if that incident does happen, it's not the very very first time people are digging up this policy that's been sitting in a drawer for 10 years.

Lisa:

Why do technical architecture decisions made before lawyers are involved often create problems in technology transactions later?

Charlyn:

I would actually say that it's not only problems; there are opportunities as well. But technical architecture or the technical backbone of any technology is going to be critical when you bring in the lawyer to understand how you can manage your risk. So, for example, if you are procuring an AI system, and many organizations these days are procuring, you know, AI systems through either the major cloud providers, the major LLM providers, you know the clouds, the Microsofts, the OpenAI's of the world. There's so many tools out there that are either proprietary large language models, or they're what we call a wrapper that's built on these foundational models. Understanding how those tools all fit together are super important. And just to bring this into a case study as an example, hypothetically, if you are using let's just say a billing software for AI to track your time as you're doing work, and instead of manually recording, I spent an hour on this, I spent two hours on this. This AI is living on your computer and looking at all the. You're doing and basically using AI to predict what time entries should be associated with that task. And let's just say this billing AI provider works on top of OpenAI. So now you have two layers of different third parties that are touching this data, and this could basically mean that your entire computer, whatever it is you're doing, is visible to this AI. What is the AI provider going to do? You have the billing AI software provider at the first level, and then the foundational level you have OpenAI in this example. And where is that data going? Are there restrictions on what they can view? Let's just hypothetically say you're not doing work, and you're at your office, but you're doing something that you're not supposed to be doing. What can that billing software provider do with that data? Are they allowed to say hypothetically report a crime? Are they allowed to reveal that information to your boss? I mean, these are the types of things that all depend on the technical infrastructure, and as a lawyer, you really have to understand that in order to properly manage risk,

Lisa:

how do data flows determine which provisions companies need in their technology agreements?

Charlyn:

So, data flows are really important to understand how you can structure the agreement. The reason is because privacy laws often create obligations based on the role that an entity or a person plays with respect to that data. As an example, like the California Consumer Privacy Act has this role called a business and this role called service provider. The business is the entity that is actually collecting the data, has the relationship with the consumer. For example, let's just say it's my my law firm, Rica Group. So if we're collecting the data from from one of our clients, we know what that data is. We have control over that data. We choose how to store it, how to share it, how to protect it. But let's just say we use Google or Gmail as our email provider. You know, Google and their product Gmail could be what's called a service provider to us. They are the ones that are just holding the data. They're the ones that are providing a service, and they're only processing the client's data for the purposes of allowing us, the law firm, to provide legal services. They're not taking that same data and then going off and doing whatever they want with that data because data is the new oil, or maybe not even new data is like oil; it has tremendous value. But if you have an oil spill, it also creates tremendous risk. So understanding how that data is flowing, then that really sets you up as a privacy lawyer for understanding how the laws apply. Just to give you one other quick example, if you're storing data in the United States, but that data is from somebody in the EU, there's a possibility that you would have to protect that data with certain legal mechanisms that Europe requires in order to permit that data of the European Union data subject to come over to the United States. So, without understanding those data flows, you wouldn't be able to do that as a lawyer.

Lisa:

And Charlyn, what kinds of risks can arise from open source licensing that companies don't always anticipate when building their tech stack?

Charlyn:

Open source licensing is really, really powerful. It basically means that software is out there for free, and you can use it without paying for it. I mean, that's a gross oversimplification, but at the heart of it, that's what open source means. That allows people to benefit from the crowd to basically understand from all the great developers out there in the world what is the best code to use for different purposes, and you can go and just copy that code and use it in your own product, but it's it's free in money, but not necessarily free of obligations and free of risk. So what I mean by that is there are different types of open source licenses that require different things. There are certain types that are generally called copy left or viral licenses. That basically means if you use a code that is licensed under a copy left license, you cannot put that code into your code base without then making your entire software that utilizes that code also free and also subject to that same license. That's why it's called viral because that license from the original open source code follows you. So if you're spending a lot of money to try to develop a software and you want to sell it, you don't necessarily want to inadvertently use open source that is subject to these requirements because then that limits your ability to commercialize your overall your overall product, even if that code that you use was just one small part of that bigger project.

Lisa:

Charlyn, here's where I want to wrap this up today. Why can integration clauses become so important in technology contracts, particularly when it comes to what isn't written into the agreement?

Charlyn:

When people come to the table and. Discussing a del, it's usually not with lawyers involved. It's hey, CEO of X company, I run Y company. I love what you're doing. Let's partner together, and a discussion ensues. It could be over text messages, it could be over phone calls, it could be over Zoom, it could be over Microsoft Teams, but all of those discussions can create misunderstandings sometimes, and if one CEO says, "Hey, you actually told me you would do X, Y, and Z, and you didn't do X, Y, Z. I'm going to sue you, that could be a problematic thing to happen if there's no integration clause in the ultimate agreement that the two parties sign. To translate that, what an integration clause is, it basically says that this agreement, this written document, supersedes any prior oral or written communications about this subject matter, so that all of those past discussions that happened over at the coffee shop or happened over text messages, unless they're memorialized in the written agreement. They no longer matter and they no longer count, and that's that's super important because if you're talking big dollars, you want to be crystal clear what it is you've agreed to, and that's why again it's important to have a lawyer or somebody you trust that understands commercial contracts and technology to make that document and that contract as comprehensive as possible, and ensure that there are no misunderstandings.

Lisa:

Charlyn, I want to say thank you for your insights today. This is a complicated issue that almost every company needs to be aware of, and it's very new to most of us. So thank you so much for the work that you're doing to help us all.

Absolutely, thank you so much, Lisa, for having me.

That's it for today's episode of AI Savvy Lawyer. If you'd like to learn more about Charlyn Ho and the work that her team does at Rica Group, visit rica group.com. And if you enjoyed this conversation, we invite you to subscribe to the show and share this episode with someone who may need it today. We'll see you next time.