The AI Security Gap: What Hospitals Need to Know Now

AI vendors must prove their system security to hospitals. Learn how to verify data integrity and essential controls today.

Many hospital administrators struggle to validate the safety of new software. We examine how to demand clear evidence from vendors regarding what data enters the system and how it is processed. Ensuring healthcare AI security requires more than just a contract; it demands a deep look at the audit trails and technical safeguards in place.

By prioritizing AI vendor transparency, organizations can better manage risk and maintain compliance. We also discuss how to document specific changes made by the system and the controls implemented to keep patient records safe. This rigorous approach to hospital data privacy is essential for building long-term trust in new technologies.

Integrating these practices into your procurement process ensures that AI governance remains a practical, operational priority rather than a theoretical goal.

Subscribe for more insights on responsible AI, and share your biggest security hurdle below.

🎧 Listen on Apple, Spotify and more: https://signalroompodcast.com
📨 The AI Health Pulse newsletter: https://aihealthpulse.beehiiv.com/?modal=signup
📘 Beneath the Signal (my book): https://www.amazon.com/Beneath-Signal-Replace-Leadership-Healthcare/dp/B0GZPNVRCX?maas=maas_adg_6A599874CB2DA12E1ADF3BD5E6DB8463_afap_abs&ref_=aa_maas&tag=maas
💼 Hutchins Data Strategy: https://hutchinsdatastrategy.com

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome back to the signal room. I'm Chris Hutches. A quick thing before we start, I wrote a book. It's called Beneath the Signal, and it's about the human work behind trusted data and responsible AI and healthcare. Search Beneath the Signal on Amazon now and pick up your copy. Okay, here's our episode. Every AI vendor says its system is secure. A hospital has to answer a harder question, though. Can you prove it? Can you show what data entered the system, what changed, which controls ran, who approved the release, and whether the model that reached production is the model that you evaluated. And healthcare trust is not a slogan. It has to survive an incident, an audit, and a regulator. And I'm excited to come to you today with a fantastic guest. His name is Vasanth Mudavatu, a senior principal software engineer working across generative AI, machine learning, and application security products at Dell Technologies. He's joining us in his personal capacity, and the views he shares are his own. Vassanth writes about building security and compliance evidence into the delivery pipeline itself. And today we're translating that across enterprise security and really trying to answer the questions that health systems actually do have to answer. But how can a health system prove that clinical AI can be trusted with patient data and high consequences where workflows are absolutely critical? Vassanth, welcome to the Sigmaroom.

SPEAKER_02 1:25

Thank you so much, Chris. It was nice meeting you.

SPEAKER_00 1:27

So tell me a little bit about yourself and what kind of led you down the pathway to now you're dealing with AI in the healthcare space and why is it healthcare?

SPEAKER_02 1:35

Absolutely. So I've been in the IT industry for about 20 years now. So I worked for Pfizer. Um Pfizer pharmaceutical company. So I've been there for a few number of years there. So I kind of understand what it goes through behind the scenes, right? Um, in terms of I was involved in um a healthcare company migration. It's a chapstick, I believe. Uh I think it's still around. So Pfizer got that chapstick, and I that's how I got into that project. So uh I'm using Pfizer, but I'm not representing Pfizer at the moment. Um but that's my experience working in the um uh healthcare uh industry. I was there for about uh uh six, seven years now, and on top of it, I've been with many Fortune 500 companies. Uh but my current focus is on developing and deploying high impact for AI solutions, which are primarily aimed at safeguarding and preempting the Gen AI or machine learning applications from potential threats. So I focus a lot on enhancing data quality, data integrity, and how can you maximize the efficiency of the systems and eventually improve the return on the investment?

SPEAKER_00 2:55

How does the question can we trust this system change? And what evidence should a health system demand before allowing an AI tool near PHI?

SPEAKER_02 3:04

Okay, absolutely. I mean, this is definitely a burning problem. How can you trust AI, right? Especially in terms of the PHI, right? It's even more uh critical. So most health systems they secure the pipeline, right? But to leave the engine unguarded, right? So what I mean is the pipeline is the infrastructure, right? So most people they get confused between the infrastructure security versus the AI security. The AI security is more focused on the model security itself, right? So the clinical AI security must govern data inside the inference loop itself. So the what do you mean by inference loop is that's where the patient context, the reasoning of clinical decisions, and the raw PHI data they come together. So you need to implement the security and governance around that data. You protect the pipeline, which is requesting uh prompt engineering requesting a prompt and then response, that isn't no longer enough. So you need to focus on the model safety the most. So most clinicians they they're already using some of the AI tools, right, to draft nodes or I know, but the PHI, the information is could be actively leaking outside the perimeter, right? So while we focus on the infrastructure, the PHI could be leaking through the models and data poisoning and all that we can cover in detail. Um so it's already there, it could be happening. So when somebody says, My systems are safe, my question would be, is your model safe? Your system is safe, I get it. Your system doesn't break, I get it. But the data that you're working with, you're letting the model play with the data, and you're letting the model help you make the decisions. So that is where the governance and security must be in place.

SPEAKER_00 5:03

So I think traditionally, at least at a high level, people understand that the concept of row-level security, privileged access, things like that. Talk a little bit about what that difference looks like in terms of practically what are some things that you have to do that are just different.

SPEAKER_02 5:19

That's true. So um having access to data is one aspect of it, but think about this very rights. As you work with the data, the AI will get smarter and smarter. And the smartness of AI is on how your quality of data is improving.

unknown 5:37

Right.

SPEAKER_02 5:37

Right. So that's the area of concern. Now I can work with an AI, I can train the model to give an unsafe clinical uh response. Right, so I can always do that. So having access to the system is one aspect of it, but it's very important to understand who is training the model, who has access to the data, and who is training the model. So that's where the data poisoning uh will come into picture. Now that an insider could be doing it, or an attacker from outside who has access to this could be doing it. So I can give an example as well. So let's say there is a malicious insider who has access to uh the patient records. Every time you interact with the model, like the person can inject a hidden text into the record. And that hidden text could alter, could or for it to be to take an example, it could suppress an allergy warning, right? So whoever the clinician is doing it, they look at the output, but in that output you will not see the allergy information uh brought over by the AI. So that's something that's called data poisoning. So that's something that can be done. And um and the other thing is from outside, I can, if I'm interacting with the model, I can do a prompt injection, right? So I can upload a file. It looks like a file, but it has some hidden instructions that could manipulate the data itself. So that's where the zero trust coming, zero trust security come into play. But end of the day, the goal should always be to sanitize both input and the output layers.

SPEAKER_00 7:18

Let's kind of shift a little bit um to where you have to be able to produce evidence on it. I know you talk a little bit about cryptographic attestation in plain English, but maybe help us understand conceptually what is that? What does it look like? What's being attested to, uh, who is attesting?

SPEAKER_02 7:36

So there are two things, right? So one is um the every interaction with to with the model has to be safeguarded, right? So you need to put guardrails in place. Now you can, when you say cryptographic attestation, whose point of view are you talking about? Is it from the system point of view or from a uh uh an auditor or somebody?

SPEAKER_00 7:59

There's the technological piece of it, but then also in plain English, how are you explaining it and who's the person who's gonna be able to sign off on it? Because I think when you're talking about having to produce evidence, you know, who's gonna attest to it? Uh as a chief data officer, I might be on the hook for it, but right now I don't think I understand it enough to.

SPEAKER_02 8:16

Correct. So it's definitely a challenge. To attest the data is definitely a challenge because the rate at which the data is being produced is beyond, that's why people are people are creating so many data centers around the world. No data is useless. So they'll have to grab as much data as possible, and they'll also have to make sure that um they use the digital signatures. I think that's what the attestation is more about. So use the digital signature to to prove your identity and an authenticity of the data. So it's definitely a challenge because um uh having a cleaner data is absolutely essential, but at the same time, the rate at which the data is being produced, and um uh so that's where the policies come into the picture. So, what we have uh what I have done for one of the systems is to set up those policies in place. Anything that comes in must go through these checklists. And that checklist has after talking to our internal compliance, compliance team, auditing team, and any other external compliance that we need to meet. So all those requirements have to be taken, have to be considered, and then you approve that particular data set to get into it. So that's the CDO's job is not an easy job. I know it's going to chase the heart of everything that's going to be built on top of it. So yeah.

SPEAKER_00 9:45

I just think about how different it is between having a typical software development lifecycle versus having a model that's evolving, like AI is going to do. What are some of the elements that actually can are carried in that help you to be able to discern the level of accuracy and security that you've got in place that maybe are a little bit different from the typical things that people would be accustomed to?

SPEAKER_02 10:11

Yeah, it's definitely a challenge that every organization is dealing with. We need to establish that role-based access control. So you have to protect your systems from insiders and outsiders at the same time. Unfortunately, that's how things are. So outsiders is a different uh problem altogether, but insiders, you need to make sure that uh proper rollback policies are in put in place. So you need to identify the systems first and then identify the roles that you would want the users to have. A role could be like I am a I'm a leader, right? I want to see everything. Right. That's fine. You can see everything, but he cannot do anything. He can only see the data. Now, like auditor, I can only see the data. Now I am owner of certain portions of data, then I can I can have read and write access to the data. So we need to establish those roles beforehand and make sure you go through proper leadership, uh, approval chain and get it approved, and then start implementing your systems. And then you need to find the users who are qualified to for each of those roles, assign them, and then implement the systems to find the users and then get them access. So when someone some user is trying to access the system, system should be smart enough to figure out okay, who is this person and what level of access uh person has, and only show that data. Don't show anything else beyond that. Right.

SPEAKER_00 11:40

Talk a little bit about what your experience has been, you know, working with leaders, and you know, there's a tendency if they get a certain level of information that they just get they want to trust, which is fantastic in some senses. But where are some things that you see could be problematic because they might get a false sense of security before they really should?

SPEAKER_02 11:58

Yeah, so that's another common pitfall. Um, since AI is producing data so rapidly, and our analytical systems are getting so advanced day to day, right? So data that you see now is not going to be the same in next five minutes. It's going to change. The assessment of AI is going to change. The assessment is a non-deterministic approach. So there might be a new parameter that that's thrown in into the model, and it could change the whole analysis altogether. So that's something that takes a lot of effort for us to put the guardrails in place and make sure the model's response is always in standard format, and not have multiple places for the leaders to go and look for data. They should come to one central location, and that should be the source of truth. The moment you look at multiple locations and data is going to be mismatched, maybe by 5-10%, that might cause a big issue later. Again, we don't know. So we avoid having duplicate uh points, viewpoints for the leaders. Come to one central location, consume the data from there, and then make whatever decisions you need to make.

SPEAKER_00 13:12

Just because we get to a point where we're comfortable on day one, that doesn't mean it's going to be stay safe. And I kind of want to go back to a concept you've already mentioned, which you know, the data poisoning and prompt injection. Maybe just help a CISO and a CMIO understand what you're talking about there and what does that actually mean and what do they need to know?

SPEAKER_02 13:32

Yeah, so data poisoning uh happens when the data set, so as AI models become better and better, you're saying it becomes better and better, but they become better when they have a better quality data, right?

SPEAKER_00 13:47

Right.

SPEAKER_02 13:47

So, and you may have the whole world in front of you, but you may not need the whole world, right? You just need a portion of that data. So that's where the data sets come into play. So you pick the data set that suits your use case, and then you train the model. Now you train the model today, and tomorrow you will get a new, more improved data, and you have to keep training the model to keep revisiting the decisions that were made. And then so that the fine-tuning of that data set or that model, that is the place where the data can be poisoned. Right? So, so when I'm trying to train my data set, I can inject something and that could cause an issue. So I was giving an example earlier. So if an I can in an attacker can inject a hidden text in the file, which could alter a clinical decision, right? Which would completely ignore the allergy warnings for that patient. And the clinician will never know, they will never have access to the data because the AI has processed so much data, all of the patient's records, which is impossible for one clinician to go through it and figure out okay, he had an he or she had an allergy warnings a couple of years ago. And if that warning is missed, then the decision, the clinical decision, is going to be completely different. And that could cause some serious problems. So that's where the data poisoning uh comes into picture. Then the prompt injections happen when whoever is accessing or talking to the system, right? I can inject in my prompt. Let's say I want to see, I'm a clinician, I want to see your data, then I can simply ask, okay, give me Chris's data, plus I can add some more to it, which is absolutely rubbish. It doesn't make any sense. For us, if you read it, it doesn't make any sense. But for model, it needs to interpret, it needs to understand, okay, there is a legitimate question, plus there is an extra text. The model is not going to ignore it. Yeah, it's going to consider it. And if that's that extra text is telling the model to do something else, it might do it. So that's the injecting. So you this is a prompt injection. So you're asking the right question plus more. But the model does not stop at just the questions, it's going to read the whole input. So that's the prompt injection. Again, this is a direct prompt injection, and there is an indirect prompt injection that can also be done where I can send some hidden instructions, you know, to manipulate the patient history itself. So it's a completely unintentional, but the model can interpret in such a way and then uh uh and then it it can cause problems. So that's where the zero trust for prompts come into picture. So every prompt that the user is submitting must be validated before going to the model, and every response coming from the model has to be validated, and the response and the request must be paired together and again validated. So because the response can be true, but the prompt is something else, right? So you cannot validate them in silo. You have to pair them and validate that okay, the user is asking for somebody's records. Is the user authenticated? Is he or she authorized to request for those details? All that role-based access control and pairing up with what was asked and what is model responding together. These are the guardrails that must be put in picture. So the CISOs uh should be focusing on uh creating that proxy layer or a gateway to monitor all the whatever all the transactions that are coming in and out of the model.

SPEAKER_00 17:38

What are some of the things that you would tell people they should be thinking about to reduce those risks as much as you can? Um, particularly because the systems can actually retrieve records and write back to workflows, trigger other things. Uh it's much more real-time than maybe we're used to.

SPEAKER_02 17:53

Okay, right. So that's where the prompt engineering comes into picture. Basically, it's all it means is um the prompt is the question to the model. Make sure it is very clear. There is no scope for ambiguity there. You know, exactly you should ask exactly what you want. Okay. If you leave it open, then be prepared to be surprised, right? The model can hallucinate, it doesn't fully understand the scope of your question. So make sure. So we need to train folks on prompt engineering how to request for exact um information. So that's definitely a key. And then every time you get a response from the model, since it's a human interaction now, the expectation is you need to validate the response. Did the model give you what you asked for? If not, then give some feedback to the model that this is not the response that you're getting. And if the model gives more than what you want, then still you need to give them the feedback. So if there is no user feedback, then the model is not going to learn from your interaction. And it could be giving much more details to some other user, which is not at all required. And that's how the data leak will happen. Uh, that's a data leakage. You might get your records, plus you'll also be getting my records, uh, my information. It all depends on who is asking and what. So we need to educate the users definitely on how to ask the question and how to validate a response, and how do you provide the feedback to improve the model?

SPEAKER_00 19:28

So if you don't mind, could you say a little bit more about the prompt engineering and the importance of making sure that you're providing training to team members?

SPEAKER_02 19:36

Yeah, absolutely. I mean, white coding is a thing. Uh, that's a term. Wipe coding, you just prompt and it's going to give you a bunch of code, bunch of code, and can spin up an application in a few minutes or a few hours. So um I would say creating or developing is no longer the niche skill, right? You need to fully understand what you're developing and what's the problem that you're trying to solve, and understand the data that you're going to work on. If you have access to a confidential information like in the medical industry, then you have to make sure that all the guardrails are put in place. So you need to understand the security principles, you need to understand what is shift left security means. Security is not an afterthought, it has to be imbibed in the design, starting from the design. So you need to see that's a concept called secure by design, SBDs. So you need to design your system first. The AI will develop what it thinks the best. But you need to know what exactly to tell AI what exactly it should do. So that's where the design comes into picture. You design first, but before you need to understand the security fundamentals, understand the security first, design it, include all the principles in it, and then feed that to AI, then AI will give you a system, but you also need to develop test scripts to ensure there is no data leakage and make sure you're prompt. So prompt engineering comes into play once you have the design in place, then the prompt engineering will come to develop the application. Now, if you're asking AI to design, which most people do, which is absolutely fine, but if you don't understand what the design is, then rest assured it's going to be a mess. It might look good, but when it comes to functionality, it's going to be a mess. So understand the security by design and understand the prompt. How can you engineer the prompt so you will always get accurate response from the model and validate the response from the model? Do not accept blindly, do not trust the model response blindly. Validate it and test it yourself. So make sure all the policies and guardrails are in place. So that way you can limit the attack surface. All we are trying to do is limiting the attack surface. After all the guardrails, still there could be a data leakage happening, still somebody could attack your system. All you're trying to do is reducing the attack surface.

SPEAKER_00 22:18

Now you've got to be able to defend how the system is governed, which gets to the whole governance conversation, which is no longer going to be just an academic exercise. Maybe we talk a little bit about what kind of governance we're talking about that can survive an audit compared to the kinds of governance that we're used to, where it may not be so tight. And we're just looking at a policy, but we're not actually looking at how it's being implemented operationally.

SPEAKER_02 22:45

Right, right. So two points here, right? So one is the compliance auditing, and how do you ensure your systems are guarded? So things are slightly changing, not slightly. They have changed a lot in the sense that most compliance and auditing are post-activities. But now with AI being so powerful, everything is near real time. Every response and every prompt, the auditors can see it. Anyone can see what was a prompt, what was a response, and everything. So the security operations are significant, highly critical, I would say. So you need to put in the AI security gateway. That's what I've been talking about between the model and the user. So you must have that architecture in place. You need to inspect the inbound requests and outbound responses to make sure that only authorized people are receiving the information and the information that they are receiving is going through all the policies, all the compliance or auditing policies that are put in place. So to define those policies, it might take a while for folks to uh for the policies to mature because it's completely new for everybody. So the faster they put it in place, uh the more uh trustworthy the AI systems will start becoming. If there is a human in the loop, then we have to be aware of the fatigue. The fatigue in terms of if you don't trust the system and if you're asking a human to review the clinician, for example, in one hour that person will receive 1,000 uh assessments from the AI, right? So you will not have time to go through all that. So that's another fatigue that we need to be aware of. So our systems become more and more uh secure and mature, the human in the loop uh will have the burden will be reduced.

SPEAKER_00 24:43

Who is authorized to raise the flag and say, hey, time out? We can't proceed, we have to solve some problems. But how do you get to that point? And what are some of the things that you see that have been affected to get an organization prepared for that?

SPEAKER_02 24:55

Absolutely. I mean, this is critical. If you're talking about large businesses, then they have multiple business lines, and it's going to be a mess. It's hard to find one person who is a master of all the business lines. So, what we have seen is they form this AI governance board where you'll have you'll nominate somebody from your business line to be on the board, and that's where the collective decisions are will be made. And of course, on that board, we'll have technical representations who are running the AI platform, building AI systems, and then you have business folks coming in from each business line, and then you'll have compliance, your auditor, your legal plays a crucial role. So everybody will be placed on that, and that's where the all the big decisions are will be made around how do we govern the data, how do we protect the data, and how do we bring in new models? What are the guardrails that we need to put in place and how quickly we can switch a model from another tomorrow? The model that we are using for one year might have a serious uh vulnerability, right? So that was found out many months later. So, how fast can we switch uh that model to something more secure? So, all those decisions they'll have to be made by a collective uh team. Uh, we call it as AI Governance Board, and those are the guidelines that will trickle down to the rest of the teams and they'll make the decisions accordingly.

SPEAKER_00 26:26

One of the things I know that you urge leaders to do is to plan for complete data loss. Talk a little bit about what you talk you're trying to get uh organizations to think about from a leadership standpoint, getting into the right posture for a hospital that can't afford to go dark, but these risks do exist and maybe are a little bit more heightened now with the technologies we're talking about.

SPEAKER_02 26:49

Yeah, absolutely. I mean, that is another serious concern. So the models can go rogue. It's it's hard to predict, right? And uh when leaders are budgeting for model costs, compute, or infrastructure, or licenses, what we have noticed is there is an underestimation of um headcount that is required to continue the oversight, right? So in a hospital industry, they cannot simply go offline, right? If there is a data loss, it doesn't mean that hospital is going to go, or it cannot go offline. Right. So they need more of a graceful degradation for a fallback mechanism that is put in place, and it could be going back to your older way of doing it, the manual workflows, but that process should be in place all the time, and uh uh which was already tested, right? It's been tested for so many years. We're trying to transform now, but the current workflows are have been tested. So they have tested, they're time tested, and they are working. And now we have to make sure that it still stays there as a fallback option when something goes wrong uh and which is out of our control. And the other thing would be the impact radius, um right. So health systems they must map exactly which workflows are depending on which models, right? So so a single safety issue doesn't take down the entire operations itself, right? So as long as we have that map in place, so we know which model went dark and we can quickly substitute with it, or we can quickly fall back to human-in-the-loop mechanism. I think that uh that would be essential. And those decisions, I mean, as you said, it's a disaster recovery basically, they're all disaster recovery drills, so that must be in place for any system that is using AI. So it's a mandatory. You so you cannot go live or go to production or release a system without a DR plan in place. That cannot be happening. And the leaders must be made aware that to run the system with uh AI infrastructure plus your fallback mechanisms, this is how much it's going to cost, and they need to uh plan accordingly.

SPEAKER_00 29:15

But there's this critical continuity piece of it becomes a little bit more um significant when you're dealing with restarting after something like that. Just because we're talking about models in the sequence where things are processing becomes even, I think, a little bit more significant. Am I right?

SPEAKER_02 29:32

No, it's absolutely. I mean, the sequence in which you start is going to change. The key point here is data. The data is not going to change, only the model is going to change. This is the model is how we interact with the data. So it's the middle layer that's broken. So that the fallback option should consider this as well, right? So now you have access to the data. The data is not going to go anywhere. Data, again, data you have data replications and all that VR for the data itself. That's another process. So you should have all those in place. So even if model goes out of the picture tomorrow, you still have access to the latest and latest data. And you fall back to your older ways of manual workflows, they'll have access to the data and everything. So they'll have to continue to leverage how they used to do before.

SPEAKER_00 30:24

From your experience, what are some of the things that leaders should be looking for and essentially just demanding some evidence before they make a commitment? What are some of the things that you would tell them to kind of pressure test the vendor security or you know, whatever governance claims they might make?

SPEAKER_02 30:39

Yeah, so things are changing rapidly. So earlier we used to have the luxury of time. Now it's not the case because if I test something today, it might become irrelevant tomorrow. That's how fast things are moving. I mean, we talked about the MCP servers and all, they were not there a year ago. They just came in out of nowhere and it's normalized now. Everybody's talking about MCPs. Now nobody's talking about MCPs, but they're all using MCPs. And the transition just happened so fast, right? So that's the point here. Even for the leaders, it's be very challenging for them to time test something. But what we can do is once if your design of your systems are secure at the design level, and you can you can bring in a new tool. And of course, before you bring in a new tool, you bring in a more uh uh non-production environment, you test it out there, and then you bring it in. But the time that we used to get before is not been given anymore. It has to be done in days, right? You test it, your system has to be so smart that they stress test the new vendor API or vendor tool, stress test it, security test it, and then push it in and just integrate with your uh existing uh architecture and then keep looking on it, keep an eye on it, just keep looking at the vulnerabilities, make sure all your security scanners that are in place are capable to handle this new tool in place. So um so those are the things that being considered at the moment.

SPEAKER_00 32:19

So as you're evaluating uh solutions in vendors in this space, um is there a particular dimension that you think is uh maybe better as a leading indicator or one that's significant enough that if something doesn't check a box in one dimension, it's just not going to work no matter how many other boxes it checks.

SPEAKER_02 32:41

Yeah, absolutely. Um so as we talked about earlier, the technology is rapidly advancing. I might need uh three things from the vendor, and they are only capable to deliver two. And I do compare other vendors. Uh, the other vendor might be able to deliver all the three, right? Yeah. But for me, the decision making is what is your research capability? Are you capable to keep yourself up to date, do your research on what's happening in industry, and keep updating your tool for me. Tomorrow, in a month or so, I may have six more requirements. And if you don't have that capability, the research capability, and then how quickly you can provide me those six, then uh yeah, I will not go with somebody who has all the features ready now versus somebody with strong research capabilities plus just few features available because I have to look current and future. So that was not the case before. Earlier, we were just looking at okay, I need three, you got three, all right, you got a deal. But now, no, it's not the case. I need three, you got two, I'll take it, but show me your research capabilities. So, this is the research capabilities, and then I'm sold.

SPEAKER_00 33:56

Yeah. It really is the nature of whether you're picking the right partner. If you could identify a safeguard that would be practical for a health system to put in place, you know, this quarter, understanding how the pace is moving, what would you tell them that they should be putting in place now to help them to be as proactive and protect as well protected as they can be?

SPEAKER_02 34:16

Yeah, absolutely. So the research capabilities of our vendors is extremely crucial. For some, we become the design partners because it's hard to anticipate what's coming next. Right? The best we can do is protect the current systems and keep trying to break it ourselves, right? If you can break your system by yourself, then there you go, you found a new vulnerability. Now, can your vendor or somebody do that for you if they are allowed? If they're allowed, they'll do that for you. If not, then you share the results with them and they'll give you a solution or they'll upgrade their tool to identify that. So the desired partnership is extremely crucial. So you find the right partner with the right skill set, you would want to be with that team, right? So every time you change your vision, you make sure you communicate to the vendor so they are aware, okay, this is the direction in which this company is trying to move. Now, what all how can we support it? Now, if you don't have the capability, they'll have to get the capability and then continue to be with us throughout and help us achieve our visions.

SPEAKER_00 35:24

Yeah, absolutely. Well, as we kind of land here, if people want to follow up with you, you know, just to get to know some of the things that you're passionate about, learn about your writing, where can they find you?

SPEAKER_02 35:35

Uh you can connect me on LinkedIn. Uh, you can search my name, Vasanth Maduvatu, you'll find it, or you can comment on one of my articles that I've been publishing on Forbes, Forbes Technology Council. So you can find me there as well.

SPEAKER_00 35:48

Well, thank you so much. And you know, for the audience, I'll make sure that you have all the information in the show notes. I learned a ton from you. So thank you so much for just coming on the show today and teaching me some things.

SPEAKER_02 35:59

Absolutely, Chris. Thanks so much for your time. And uh, really wanted to share what my learnings are with the wider audience. But thank you so much for giving me the opportunity. And I hope next time we talk, we'll talk more on the agents and how agents come into play. Now we talked about the human in the loop, but as we advance, I think it's gonna be more and more agents doing a lot of the work, so it'll be interesting to see how things work in the next six months.

SPEAKER_00 36:24

So we could probably talk in a month and have a whole other set of things to talk about.

SPEAKER_02 36:28

Yeah, yeah, absolutely. Awesome.

SPEAKER_00 36:31

Well, for my listeners, so thank you all for tuning in. Uh, that's gonna do it for this episode of the Subir Room. I'll see you next time. And please stay curious, stay on top of things, keep learning, and I'm out for now. Thank you.