Locking Down Corporate AI Usage Webinar [PODCAST]

← Back to All Podcasts

Locking Down Corporate AI Usage Webinar

In this episode, Jason Nadal, Besler Holdings’ and Sypher Security’s Information Security Officer, will provide us with a glimpse into the next Hospital Finance Academy Webinar, “Locking Down Corporate AI Usage,” live on Wednesday, October 7th, at 1 PM ET.

Highlights of this episode include:

• How companies deal with artificial intelligence and how they should make the decision to embrace this technology
• What the benefits and detriments of AI usage are
• What tools out there to help protect your company and your data
• What other challenges you have in keeping aware of AI usage
• How you manage third parties not directly under your control
• The key takeaways

Kelly Wisness: Hi, this is Kelly Wisness. Welcome back to the award-winning Hospital Finance Podcast. We’re pleased to welcome back Jason Nadal, Besler Holdings’ and Sypher Security’s Information Security Officer. In this episode, Jason will provide us with a glimpse into our next Hospital Finance Academy Webinar, “Locking Down Corporate AI Usage,” live on Wednesday, October 7th, at 1 PM Eastern Time.

Welcome back, and thank you for joining us, Jason.

Jason Nadal: Hi. Thanks for having me.

Kelly: All right. Well, let’s go ahead and jump in. So, we know artificial intelligence is everywhere now. How should companies deal with this and make the decision to embrace this technology?

Jason: Well, if you run a company right now, somebody on your team is likely already using AI. So ideally, that would be via an approved path that you have already set up, but maybe it’s just a browser tab they opened up at lunch, putting something in Google and getting AI results. Either way, the question is not, “Should we use AI?” It’s already embedded in a lot of the approved corporate tools that are already out there. So, the question is, “Do we know what we allow, what we forbid, and how do we keep that promise when the tools keep changing under our feet?” So those are the kinds of conversations that security and IT folks have when leadership asks for a practical plan around AI. So, over the next 10 minutes or so, I’ll walk through some of the benefits and risks. We’ll get into that a bit deeper during the webinar that’s upcoming, but this will give you a methodology of control you can actually run, some of the categories of tooling that support it, and the challenge of feature creep in tools that you’ve already approved. And we’re also going to look at how a vendor and open-source software assessment has to catch up.

Kelly: Yeah. I mean, it is really everywhere. It’s embedded in everything now, it seems like. [laughter] Yeah. It’s a lot to keep up with. So, what are the benefits and detriments of AI usage?

Jason: Sure. There’s a lot of benefits, and there’s definitely a lot of detriments as well. So, AI earns its value when it shortens the work that you’re already doing, especially that work that used to waste a lot of your time through just tedium, repeated tasks, and things like that. So, I find it really shines at drafting, summarizing, searching or researching, coding assists, and also triaging helpdesk tickets. So those are real-time gains when the data and the use case match the risk. So, in healthcare and adjacent work, that might be a little less clear. So, a nurse or revenue cycle analyst can summarize a long chart note, draft a patient letter, or speed up some prior auth paperwork. A cost report or appeals team can find patterns faster. So done carefully, ideally with this human oversight as to what’s produced, that is time returned to care and to accurate billing. But the downside is just as concrete. So, paste the wrong note into a public chatbot, and you may have moved protected health information, PHI, or something else confidential or sensitive, outside your control. So, a helpful summarizer can invent a fact, called hallucinations, that then gets treated like clinical or financial truth. There’s really a huge downside to that if it’s not checked over by humans with clinical experience. An automation that writes into scheduling, ticketing, or an EHR-adjacent system can turn a bad model answer into a real patient or operations problem. Outside of healthcare, the pattern is much the same. So, marketing could paste customer lists into a public model. Finance could paste financial forecasts. Engineering could paste source code or API keys, maybe in a hurry or just this one time, and leak information that you don’t really intend to leak. Legal can paste contract language. You get the benefit of speed, but the detriment of leaking your data, over trusting the AI, and a trail that, once it’s out there, you can’t really tidy it up after the fact. So, a key point to establishing governance is having frank discussions of what data is acceptable to this risk if it were to leak. I really can’t say that one enough.

Kelly: Yeah, I mean, I know that in marketing we use it quite a bit, but I mean, you all help us really understand what we’re really in for there. So, I know there’s a lot to keep in mind. So how do you lock this down without pretending people will stop being curious?

Jason: So yeah, you do need this methodology. The first thing I’d say, write an AI usage statement. This is your company’s position on how AI is used. Let it have plain language that’s easily readable. And this company position will include what interactions are allowed and what are not. Who’s able to use what classes of AI? What data classes may never leave the building? It may not just be PHI or employee data. It could be financials, as we said before, or just confidential mergers and acquisition information. So, what AI interactions require a human in the loop? What happens when someone isn’t sure? They should always be trained to ask before they just paste data in somewhere. Publish this conspicuously, train on it, and make sure that people know what’s appropriate to do with their AI. Refresh it when the landscape moves. So, if you don’t have a written position, every employee is going to have their own assumptions on what is good or bad. That’s not really empowerment. That’s just risk that’s out there unmanaged. I’d also recommend don’t write this usage statement from scratch. See what others in the industry, especially your industry, are doing, and tailor what’s out there to yourself. Secondly, you should assess the AI that is in question, the AI that you want to use in any given situation. When a third party uses AI in a product that you buy, treat that as part of vendor due diligence. Ask the vendor, “Where are these models running?” Ask whether the prompts or the outputs of those prompts are retained with them or are they used for training. Ask about sub-processors. Maybe that vendor is using somebody else to do their AI work. Ask also whether AI features can write back into your system. Don’t just accept a blanket, “We’re AI-powered,” as a checkbox. You need enough clarity to decide, yes, this is an acceptable risk. No, this isn’t going to work for us. Or yes, but we need these conditions in place to feel good about the risk of using this tool. And keep logs. Review those regularly. What is not AI today might become AI tomorrow. I’m sure all of us have seen an application that we’ve used online that just, after approved, suddenly has new AI functionality. So, train your users to notice new AI functionality added to the products that they already use. Third, you want to control access to your systems. And there are different types of access that you need to be aware of all three of these and looking into where AI touches all of these. First off, private access. This is ideal if you’re using sensitive data. Your employees would then be using AI that is hosted locally within company boundaries. Private model and private instance, your network. You can still govern who can use it, what data they may feed it, and how you log that use. Just because it’s private doesn’t mean it’s unsupervised, but at least you can keep the inner boundaries of where that data can go. Next up would be public access, people reaching third-party AI sites out in the open internet. So, you decide who can get there under what policy and how that policy stays current when new sites appear every week.

So, blocking everything forever, that’s rarely an answer. But blind open access is worse. Pick that controlled path and make sure you maintain who has proper access to it. And internal access is different from private. So, this is AI that’s baked into platforms you’ve already approved. Productivity suites, especially CRMs, ticketing, EHR add-ons, collaboration tools, all of these are things that we’ve seen ripe targets to add AI functionality to. Again, the purpose is to make them easier to use, but you need to make sure you maintain the risk of that if it wasn’t there when you initially assessed that vendor. So, it could be somebody just flipped a feature flag or a vendor released a sidebar assistant. It’s not really a new public chatbot to evaluate from scratch, but there could be changes to what models are being used and the risks associated with that. So, you should treat it as a change to an approved system. You should have that same change management, the same risk review that you do for a new vendor, the same data classification questions. So, if you’re only policing public websites, you’re going to miss that AI that arrived inside your door because you’ve already let it in.

Fourth, control AI access to your data. The data classification is very important. Label what your data type is. Is this file public? Is this one confidential? Is this one regulated because it’s PHI? Ask the impact question out loud. If this data type was released, what would be the impact to our company and to its reputation? So that framing is a lot clearer to executives than just jargon. It puts them in a place where they’re actively thinking about, “Our internal secrets, if they got out to the public, how would this affect our reputation? How would this affect us financially?” If the impact is high, that data probably doesn’t belong in a public prompt, and it may not belong in a loosely governed private one either. And fifth, the last one, input sanitization. Now, this is an interesting topic out there because of how bad actors can try and subvert the normal use case. So, at a high level, this means that people and attackers are going to try to override instructions. They’re going to try and steer AI agents off policy or try to trick them into doing things that the designer never intended. So you don’t need to exploit the recipes yourself to take this seriously, but you need defenses that assume prompts and retrieved content can be hostile.

Agents should have the least privilege, and that high-impact actions or actions to highly risky data always need human confirmation. So, think about that misuse at scale. So compromised agents or automations can be turned into attack infrastructure: scraping your data; it’s spam. They could create helpers for stuffing passwords in to try and guess. Any of the sort of modern botnet abuse that you see out there with malware can also be used with AI. So, if an AI agent can browse, if it can send email, or if it can call APIs with broad credentials, we’ll treat that like any other privileged information. You want to limit the scope of what it can touch. You want to monitor what it can do, and you want to make sure you have the ability to revoke those permissions really fast when something looks wrong. Because AI attacks work a lot faster than standard kind of malware attacks where you have a bad actor that’s on the phone trying to do impersonation of people, for example.

Kelly: That’s all great advice, Jason. So, with all that being said, what tools are out there to help protect your company and your data?

Jason: Sure. Well, what’s good is that there’s a lot of options out there. I want to emphasize that those tools don’t replace your methodology. They help support it. So, you got to stick to what fits your stack of infrastructure without turning this into just a shopping list. But here’s some examples. So, AI filters and firewalls are great because they can inspect your prompts, looking for kind of manipulated input. They can look for policy violations, sensitive patterns, and unsafe instruction attempts before the data leaves. DLP, or data loss protection, for prompts and uploads. That is aimed more at people, what paste, and what files they attach to AI tools.

You can look at secure gateway controls for some of the public sites. That’s how you allow or block access to third-party destinations, like a whitelist. And you can keep that list maintained. You want to log and monitor your AI use to know who used what, when, and with what data sensitivity signals, and whether that matched policy. And you can also look at identity and single sign-on gating for the private models. So even though it’s private AI, you’re still going to need to have authentication, authorization, and preferably single sign-on. So, access follows that same identity and policies that you have for that as your other internal tools. Now, again, none of these replace judgment. But they make the policy enforceable, and especially they make the exceptions more visible by bringing them to your attention.

Kelly: No, thank you for sharing those tools with us. Those are great. So, what other challenges do you have in keeping aware of AI usage?

Jason: [laughter] Well, here’s the challenge that keeps security teams awake, existing approved tooling. So, we said that before with the vendors. And we’ll get into that more with the webinar as well. But it’s a real risk when you have something already approved and they just added AI, either publicly or even silently. Last year’s CRM didn’t have a generative AI sidebar. And this year’s update does. EHR add-on ships smart summarize. A collaboration suite turns on meeting transcription and AI notes by default. So, these are all common situations we’ve seen. Feature creep means that your old approval letter is incomplete. So, you have to build a habit of, whenever an approved vendor ships AI, reopen that assessment. Don’t wait for an incident to discover the new button. And train your people to look out for things that appear.

Kelly: Yeah, it sounds like training your people is probably the most important thing there to look for those things. So, you mentioned third parties. So how do you manage third parties not directly under your control?

Jason: That is also a very tough one. So, the key couple of ones that come to mind would be with product engineering and with procurement. So here you have, on one side with product engineering, you have code tools. A lot of times, open-source packages are included there. And procurement, again, here’s the vendors that have AI functionality kind of baked in and not at the forefront, where they’re just adding it in later. So for managing the third-party risk, look at every SaaS contract and every integration to determine whether AI is somewhere in that path, where that data is going, and who the sub-processors are. Look into what happens if the vendor’s model provider changes terms overnight. Put some AI questions into your vendor questionnaires and your security review checklists, and actually make decisions based off of those.

On the other side of things, when you’re looking at managing your embedded open-source software libraries, a lot of modern products pull in the AI-related dependencies that you might not know just from the package that you’re pulling in. So, some model SDKs, vector libraries, agent frameworks, those dependencies inherit the supply chain risk like any other library, plus some new ones. You could have unexpected outbound calls, default logging or licenses that don’t match your appetite for risk. You want to have inventory on those. You want to dig deeper and have some tooling that looks into those dependencies and also analyze risk of those. Pin versions so that you know that the version that your libraries are using is the one that doesn’t introduce more than you had already identified. Look out for vulnerability advisories. Don’t let an AI SDK become that side door into production data.

Kelly: Yeah, I mean, it sounds like managing the third parties is a whole job all in itself. So, Jason, what are the key takeaways here?

Jason: Well, I’ve got several here. If you remember nothing else from the discussion, these would be the ones to look at first, right? You want to write that AI usage statement. What’s allowed? What’s forbidden? Make sure you ask first. You want to assess AI wherever it shows up: new vendors, old vendors, look for new feature flags. You want to separate your public, private, and internal access and govern those. Change management. You want to classify your data with an impact question. What’s the reputation and company harm if these data types were leaked? You want to sanitize your inputs and constrain any agents. You want to assume bad actors will get access to it and don’t give free rein. Make sure that scope is limited for attacks. Use tooling categories to help enforce and observe. There are your filters, DLP, logging, identity, gateway controls, all the extra tooling. You want to revisit approved tools when AI appears. Again, that’s with vendors or with software libraries, so look at that for that feature creep in your vendor tools. And you want to extend your vendor and open-source review to AI dependencies. Third-party vendors and libraries would both count there. So, AI is going to keep showing up in places you already trust. This lockdown isn’t about scaring people off the tools, but it’s about knowing the rules and enforcing them where you can. And stay curious enough to notice when the product on your feet grew some extra tentacles overnight. So that’s the biggest takeaway you should go back to your leadership with. Have these conversations about what you have, how you’re using it, and manage those risks for AI. It’s critical before an incident happens. And you want to work with your security team on their security incident playbook to make sure you have reactions to some of these bad actor situations or rogue agent situations.

Kelly: That’s all great advice. Thanks for sharing those key takeaways with us. And thank you so much for joining us, Jason, for giving us this glimpse into the Hospital Finance Academy’s free Webinar, Locking Down Corporate AI Usage. Join us live on Wednesday, October 7th, at 1 PM Eastern Time. And as a bonus, you can also earn CPE. Thanks again, Jason.

Jason: Thank you.

Kelly: And thank you all for joining us for this episode of The Hospital Finance Podcast. Until next time…

[music] This concludes today’s episode of The Hospital Finance Podcast. For show notes and additional resources to help you protect and enhance revenue at your hospital, visit besler.holdings/podcasts. The Hospital Finance Podcast is a production of Besler Holdings.

If you have a topic that you’d like us to discuss on The Hospital Finance Podcast or if you’d like to be a guest, drop us a line at contact@besler.holdings.

---

---