Transcript of S5 Ep80: EP 80: Govern Before You Buy: Walter Haydock on AI Governance, Risk, and Agent Security

The first thing that a security team should spend money on is inventorying their AI systems, because if you don't know what AI systems you're using, there is basically nothing you can do from a risk management perspective that'll be effective. So inventory would be the first thing. Second of all would be looking at the built-in controls for your AI systems. And that doesn't necessarily even require spending money. Might require some man hours, but doesn't require tools. So making sure you're opted out of training, making sure you've disabled any unneeded features, making sure that you've got the right data retention settings in place. These are all very cheap things that you can do very quickly. And then after that, looking at things like AI monitoring systems, logging, auditing tools that will keep a record of what this has done over time, that Will be a good place to allocate resources for a security team concerned about AI governance.

Inside AssemblyAI, I'm Sam Dey. Most organizations respond to AI with one or two moves, do nothing or ban it. Both are wrong and both are expensive. The real answer is building a governance foundation before the risk builds up faster than you can manage it. Our guest today has been doing exactly that. Helping data and security leaders in healthcare, financial services, and enterprise software deploy AI without fear. Harvard MBA, US Marine, founder of Stackware, and the person who has been warning about agentic AI security risk since before most people knew what an agent was. Mac, tell us who we have today in our episode.

Thanks, Sam. Walter Heydock, the founder of Stackware and author of Deploy Securely newsletter. Former US Marine officer, Harvard MBA, and now one of the most practical voices in AI governance and security. He helps CXOs and VPs in highly regulated industries navigate AI risk frameworks, compliance, and governance without either banning AI or deploying it blindly. Walter, welcome to Inside Assemble AI. Thanks for joining us.

Gentlemen, thank you for having me on the show.

Pleasure. So let's get into our Q&A section. We want to start off with the governance foundation segment. So Walter, you did— you have described yourself as the AI governance architect, helping data and security leaders launch AI-enabled products without fear. In your experience working across healthcare, financial services, and enterprise software, what's the single biggest mistake organizations make when they start their AI governance journey? And why do they keep making it?

The single biggest mistake that companies make at the outset of their AI governance journey is attempting to establish a policy that is unrealistic and unenforceable. This can include things like saying, don't create intellectual property risk using AI, which while it sounds good, is very difficult to to enforce and to understand exactly what that means. Saying things like banning the use of AI entirely, that's unrealistic and impossible to do effectively in today's day and age. And then also drawing stark contrasts between models that are deployed for product-facing use cases or vendor productivity software suites, separating those into different categories can create a situation where You're applying different standards to systems that are performing the same function effectively, or you can essentially end up with 2 different governance programs entirely. So those are the top mistakes that I see, basically creating a program that is inflexible and unrealistic.

Perfect. Especially when it comes to governance, like you mentioned, that we need to keep a balance between innovation and the security, and that's where the governance layer is So much necessary for any organizations. So love your perspective, and I'm pretty sure some of the listeners following this episode would resonate to your thoughts here. Moving on to, in, for the same kind of a related question, you have publicly said organizations that respond to AI with either do nothing or ban it are both getting it wrong. So for leaders, especially who are listening to this episode, stuck in that, they're that kind of paralysis right now. So in your opinion, what does the right first move actually look like? Like how the leaders who are following this episode right now will help their organization to build a governance foundation before even shopping for a single AI tool?

When you first start deploying AI systems, an organization needs to understand what its risk appetite is for doing that. For example, if you're running a marketing agency, And you're primarily creating publicly facing content for your customers using AI tools, your risk appetite might be a little bit higher than other companies because the risks of creating content that's inaccurate, they exist. They're certainly there and shouldn't be ignored, but the impact of that risk materializing might be less severe than a highly regulated industry. For example, in healthcare, you would need a business associate agreement in place with any AI provider that's processing protected health information. And if you didn't have that in place, you're automatically incurring regulatory risk. You need to comply with things like the HIPAA Security Rule. You probably have restrictions in place on you from your customers if you're a B2B company. So understanding your risk appetite at the outset. at the outset of AI deployment is really critical to making informed and practical decisions.

No, can't agree more with you on that one, especially someone like me who's been in the healthcare industry for a long time. As you mentioned, there is a data security appetite like that we need to think about, especially into considerations when you build AI, that how we can use our data for AI implementation, even before compromising the security aspect of it, especially PII and PHI data. the organization dealing with. So before I move on to the next segment, which I would hand over to Mac, I would also like to mention to our listeners that this episode is currently running on different podcast platforms, iHeartRadio, Spotify, Apple, YouTube, and Podbean. If you like this episode, don't forget to share it with your contacts as more content on AI governance and data with esteemed guests are forthcoming. I'm going to hand over to Mac to take us the quantitative section of this episode.

Thanks, Sam. Thanks, Walter. I really love the way you explained actually, but I have one follow-up on the first questions that when you mentioned about the AI governance type of it, is that something like the organizations, they have AI governance set of rules already, but they are not able to follow, or they do not even have majority of the companies that do They do not even have any AI governance at all.

Both of those situations that you described are problems. If you have a company that has no rules in place whatsoever with respect to AI, it's taking on a lot of risk from unmanaged use by employees, from people designing applications that may trigger security or regulatory red lines. And then on the other hand, there are companies that are basically one step ahead of those. that have very draconian and unrealistic policies that ban a lot of activities that employees are doing every day. And it creates a situation where there's disdain for the policy because it's obviously unrealistic, it's obviously unenforceable, and it makes people ignore it essentially. What works better is having a policy that's narrowly defined that says these are acceptable activities. We understand that you're going to do these things in the course of business. You can process sensitive information if you have these types of assurances in place. For example, if you're using ChatGPT Business or Enterprise, you have an obligation of confidentiality that the system is not processing or is not training on your confidential data. So in that case, you can process personal data, intellectual property, things like that. Now, where organizations get into trouble saying things like, you cannot use AI to process sensitive data.

Well, okay, businesses run on sensitive data. They need to process it. And that makes people just ignore the restriction outright instead of coming up with a tailored approach that actually makes sense.

Got it. Okay. Thank you for that. My next segment for quantitative risk and the Stackware approach. You built Stackware and the Deploy Securely newsletter specifically around quantitative and risk-based approaches to AI security. Most Security teams still operate on a gut feel and CVSS scores. What does a genuinely data-driven AI risk program actually look like, and how is it different from what companies think that they're already doing?

Most organizations today are still using a qualitative approach to risk management, where they'll come up with something like, there is a high likelihood of an event occurring. There is a low impact if it does occur, and therefore the risk is medium. Now, it might make sense to do that at the outset when you're just beginning to develop a risk management program, and you might be able to say, well, obviously a high risk is more severe or more bad, because severity is a different, different term, is worse than, than a low risk, but aside from that, it doesn't give you much to work with. Quantitative risk assessment looks at statistical information, for example, annual rates of occurrence of given incidents. So if there's a fault line for earthquakes where your office is, you'll generally know how frequently an earthquake will happen. It will happen every 10 years or every 50 years, something like that. You'll also know what the cost of replacing your office building will be. Entirely, or if it's damaged. So using that type of mindset to AI risk is something that can bring a lot of benefit because it lets you understand what the cost of the risk is versus the cost of the control.

So if you have a high risk, you can't tell me how much money it costs to bring a high risk down to a medium risk. You could, but you would just be making it up. Now, if I tell you I've got a $250,000 loss expectancy versus a $100,000 loss expectancy, that's $150,000 difference. If you tell me that it costs $1 million for that risk reduction, it's obviously not worth it. You shouldn't do it. It just doesn't make sense from a financial perspective. But if it costs $5,000, then that's an incredibly good risk reduction ROI and you should take it. So That is why risk quantification is so powerful. And especially because AI systems are non-deterministic, they behave in unpredictable ways, having a statistical, a probabilistic approach to risk management is even more important.

Okay. The follow-up question I have that you also have said that people, then process, then tools, that most organizations jump straight to buying software before they have the right foundation. So what's the cost of getting that order wrong? And what does the right sequence actually look like from day one?

When you're building an AI governance program, the correct order to focus on is people, then process, then tools. People are the foundation of any organization. They're the ones who are going to be making decisions. Process, I think, is where organizations spend the least amount of time, but should spend the most. And spending a lot of time on process doesn't mean having a lot of documentation. It means having a very tightly developed process that makes sense for your organization, that manages the risks you are concerned about. It doesn't mean having very long, long-winded policies that explain at length what your philosophy is on risk and things like that. You can have very short policies and procedures that are very effective. Many organizations jump straight to security tools to manage the risks that they may have identified. And oftentimes these tools just don't do anything. People won't use them. They're shelfware. And that in itself, one, creates obviously financial cost because it costs money for these tools, but also the tools themselves, if they're just sitting there and they're not performing any function. are creating their own risk surface because security tools can be hacked too. So the best approach for risk management is to look at avoidance first.

So there are 4 techniques, accept, mitigate, transfer, avoid. Avoidance is always the simplest approach. So if you can just delete data or not use a tool and get assurances that the vendor has deleted your data, then you are getting rid of that risk. for almost no cost, and potentially you're removing the subscription or license fee for that tool to begin with. So risk avoidance is something that I would encourage teams to look at when they're looking at their process for AI governance.

Okay. Absolutely. Yeah. For the next segment, the Marine Corps meets AI governance, I'm going to pass it over to Sam.

Thanks, Mac. Before I jump onto the next segment, I do have one follow-up question on that people, process, and tools approach that, Walter, you laid out. Do you suggest that the organization at any level, whether it's a small or medium or even big, large enterprise, they all should follow that same approach? Or a small organization need to tweak that approach a little bit in terms of building their AI governance as opposed to a big enterprise?

Organizations of every size should follow the the order of people, process, tools when building their AI governance program. Whether you're a massive Fortune 500 and you have thousands of people and dozens of tools that you're considering using or deploying to help manage your risk, or if you're a very early stage startup that only has a few people, going by people, process, and then tools will ensure that you have the right foundation in place, that you have the correct skills, that you have the right ways of doing business. And then when only those 2 are solidified, or only when those 2 are solidified, do you worry about the technology by buying or building tools.

Thank you, Walter. Now, in this segment, we would like to focus on your journey a little bit. You came from the US Marine Corps before Harvard MBA and building an AI security program. And you also applied the Marine Corps Decide, Communicate, Act framework directly into building AI governance program. How does that military decision-making model translate to organizations that often can't even agree on who owns the AI risk?

A huge problem that I encounter with AI governance is the accountability by committee mindset that many organizations Now, having an AI governance committee is not necessarily a bad idea. Bringing expertise from different cross-functional domains, technology, legal, privacy, ethics, security, that makes sense. What doesn't make sense is creating a scenario where everyone has a vote and/or someone has a veto on the deployment of a given AI system because Then it creates a question as to who's ultimately accountable. If a committee approves an action, if something goes wrong at the end of the day, who is ultimately accountable? To me, it's not clear. So in the military, there's always one person who's accountable. That's the commanding officer. That person will have a staff of logistics, intelligence, communications, operations, things like that. Those people will advise the commander. But the commander makes the ultimate decision. And if something goes wrong, it's the commander's responsibility. I think that's the way that companies should think about AI governance and deploying artificial intelligence systems securely. A cross-functional business leader, the person who is accountable for the business outcome, should be the person who makes the decisions about risk management. Now, that person should take the advice of security, privacy, and legal teams.

But those latter teams should not be in a position to veto the deployment of any given AI system. And that's because if you give them a veto power, I would say they should always veto the deployment of an AI tool because from their perspective, it's always increasing the risk to the organization from a security, legal, privacy perspective. However, if we always worried about those types of risks and never considered the business outcome, then we would never do anything. There would be no companies. So my recommendation is that business leaders should own the accountability for AI deployments. They should make the final decision. And they should take into account the recommendations of risk advisors from security, privacy, and legal.

Makes sense. Thank you for that, Walter. And that, I would like to piggyback on that same question to be a little bit more precise. As you mentioned about that, there should be a clearer direction about who is going to own that. So I'm going to use some titles. Is it the Chief Information Security Officer or the Chief Data Officer or even Chief Technology Officer, or there's some new title? Who should actually own AI governance in a larger organization among those job titles or the designated people? And what happens when nobody wants to take that responsibility? If something that you can share from your past experience dealing with the, say, to the executives in terms of building AI governance?

Who owns AI governance is a very important question to answer. I'll start by defining it. So AI governance is the practice of managing risk related to non-deterministic systems. That doesn't mean ownership for that risk or accountability for those non-deterministic systems. That should be a business leader who's making those decisions. Governance is the practice of determining what recommendations you're going to make, and then assigning accountability for making those decisions. I've seen AI governance fall on 5 different groups of people in companies. First of all are the security teams. There are some reasons to use them. They're usually familiar with risk management frameworks and they often have the mindset of managing risk in place and control design, things like that. I've also seen privacy teams do it. They are obviously concerned with the impacts to individuals and to personal data from AI use. Legal teams sometimes will own it. They're more focused on the contractual and regulatory side. Sometimes they might not be as familiar with the technical details of AI systems. I've seen data science teams themselves own it. This can be a little challenging because while they are technically capable and will understand the systems the best, They aren't necessarily in the place of worrying about the risk as much as other people are.

So they might not be the best advisors from a risk perspective. And then I've even seen dedicated AI governance functions in larger companies, which I think is an interesting idea. It allows people to specialize in AI-specific risks and makes them a more neutral party while at the same time it does add organizational complexity and of course, cost. So I've seen organizations run AI governance in several different ways, and there's not necessarily one way to do it. It depends on how your company runs and how you think it's best to manage that risk.

Thank you, Walter. And for the next segment, I would like to pass it over to Mac.

Thanks, Sam. Thanks, Walter, for the clarifications. Yeah, I completely agree with you because I have seen that most of the orgs I have worked with, there is a big AI governance team committee, I would say. And there are multiple teams. There is a representation, but some of them don't even are like, they're not even qualified enough to be the part of it sometimes I have seen. And sometimes I have seen even though they are like, they are making it, but there is not proper the governance rules. So, and that is actually going to start them that when it comes to innovation. So I, and, and I know that we already touched upon these things, the first segment a little bit. For my next segment is EU AI Act versus US approach. So you have been very much vocal on the EU AI Act versus the US regulatory approach. So arguing that US heavier regulatory posture may impede the economic growth while the US Lighter touch could accelerate innovation. So as we move deeper into 2026, how is that gap playing out and what does it mean practically for companies operating across both the markets?

Both the European Union and the United States have had a series of challenges when it comes to AI governance regulation over the past year. The European Union came out with their EU AI Act, which was passed into law, published in the journal in August of 2024, which set some requirements for high-risk AI systems, which are supposed to come into effect in a month. There has been a political agreement by the EU to postpone those requirements until the end of 2027. And I view that as a major loss of regulatory credibility from the EU. They came in with a very heavy-handed approach and then didn't have all the required prerequisites in place. For example, the harmonized standards that tell companies how to essentially comply with the EU AI Act. None of them have been formally published in the European Union's journal. So none of them are essentially officially blessed by the EU, which makes it extremely difficult for companies to understand exactly how they are supposed to meet the requirements of the EU AI Act. Now, on the US side of things, at the federal level, we've taken the approach of minimal regulation, and now the Trump administration is actively targeting state-level laws for litigation, specifically Colorado.

Their SB 24205 was recently repealed in the face of a lawsuit from xAI and the Department of Justice. So that has created a strange situation where the federal government is actually suing to block state-level laws from coming into effect successfully in the case of Colorado. Now, I don't necessarily think that having the federal and state governments battling each other in the courts is a good idea. What I do think is a good idea is the path that a state like Texas has taken with the Texas Responsible AI Governance Act. That law prohibits certain types of activities that I think most people would be opposed to, for example, child abuse or intentionally discriminating against people based on protected characteristics. So showing motive, not just accidentally doing it through an AI system. While Texas has that in place, it's not putting out a very set, a very heavy set of requirements with respect to attestations or disclosures or opt-outs or things like that. So I think Texas has an interesting middle ground in terms of AI governance, and I would love to see the broader United States take a similar approach and have a standardized set of rules for the entire country.

So one follow-up with that, that do you believe that so much restrictions on AI Regulatory Act by EU, does it hamper the AI innovation?

Absolutely. Regulation will slow innovation. The question is whether the delay or the impedance of innovation is worth the protections that you are creating for people as a result of the regulation. I think Europe's at an interesting perspective, in an interesting place because they are not the seat of most AI innovation. Most of it is happening in the United States and China. So Europe is in a privileged position where they can essentially apply brakes and guardrails to AI innovation, but they're not necessarily the ones where their industry is going to suffer as a result. So they are in a different place than the U.S. where if we apply strict guardrails to AI development and innovation, then that's just going to move elsewhere and mostly to China, which could have major economic and national security implications.

Okay. Yeah. The NIST AI Risk Management framework has become the go-to reference for US organizations, and you have helped companies implement it in AI, in the practice. Where does the NIST AI RMF actually work well, and where does it fall short? And what do companies need to build on top of, top of it that the framework doesn't give them?

The NIST AI Risk Management Framework is voluntary self-attested way for identifying and managing AI risks. It provides a framework for inventorying, for assessing, for testing and evaluating, and applying expert review to AI systems. Where it is less helpful is in the details. It doesn't tell you what an acceptable range of parameters for an AI system are. It doesn't tell you who should be in charge. It doesn't tell you what your risk register should look like. It gives you a higher level set of principles under which to operate. I have seen the NIST AI Risk Management Framework most usefully integrated with something like ISO 42001, which is an international standard for AI governance and allows for external auditors to attest, to certify that your company is following a prescribed set of practices. Now, it has disadvantages. It's a little stricter. It's a little more prescriptive, but that's not necessarily a bad thing because it lets you come up with a set of practices that you can tell your customers you are following and give them confidence that you are managing AI risk responsibly. So the NIST AI RMF and the ISO 42001 framework can work together, and I think that is often an optimal course for many organizations.

Okay. So apart from ISO and then just to implement the NIST AI RMF, is there any technological aspect, the organization or process-wise that the companies need to consider first to implement NIST?

There are no technical prerequisites for implementing ISO 42001 or the NIST AI Risk Management Framework. You can do both if you are simply using AI tools, if you are developing AI products, if you're considering using artificial intelligence, they are technology agnostic and stage agnostic in terms of sophistication. So I think they're useful and flexible in that respect.

Okay. Thank you. For the agentic AI security, the next segment, I'm going to pass it over to Sam.

Thanks, Mac. Definitely enjoying this conversation and Walter, it seems like you have a lot of knowledge about some of the governance frameworks that our listeners definitely getting benefited from by worth listening to this episode. So I appreciate all your thoughts and also sharing all the information over here. Now for this particular segment, I have only one question, and that is mainly about something that you wrote, which you call it like AI canaries. The idea is that the agents browsing the internet could be prompt injected with malicious commands. So in your opinion, how has that threat evolved as agents becoming more capable, more connected, and more trusted with real actions like sending emails, executing code, and accessing databases?

The risk of indirect prompt injection from malicious canaries that AI systems encounter has only accelerated over time. As AI agents have become more powerful. So I was actually just chatting with a healthcare security leader today, and he was explaining to me some of the restrictions that he was unable to put into place, for example, with ChatGPT's workspace agents. So you can only block certain domains that you don't want your agent visiting. You can't set up an allow list of sites for which it can only visit. And that would essentially create an infinite array of different sites that were not on your block list that the agent could travel to potentially process malicious commands. So that's exactly the type of challenge that companies are facing today. I think we're going to see an acceleration of this problem because right now the challenge is, can you prevent the agent from conducting inferencing on these malicious commands, which Would have a, an impact, but it would essentially be a one-time impact. Once the damage is done, it's done. I think we're going to see an even greater problem as AI agents start training in re— in near real time on the data that they're processing from the internet.

And if that happens, then you could subtly see an agent poisoned. And then maybe the damage isn't immediate. Maybe it's not apparent, but rather over time. The model continues to evolve and there's that hidden piece of data that was trained on that's malicious that will only become apparent at some later point once the model has evolved many times and maybe other models have been trained on it. Maybe synthetic data has been created by that model and that can be extremely expensive. And I think that will be a big problem going forward.

Yeah, no, definitely. As that's one of the things we definitely, the enterprise organization, especially The leaders who are listening to this episode need to consider as how they are putting the guardrails to ensure that AI agents are still under the control. And maybe that's where human in the loop is gonna come into the picture, where although we are implementing some AI agents, but we are still gonna keep the human in control to make sure the AI agents are not going rogue. What do you think about that, Walter? Is the human in the loop still critical? Considerable in that aspect of not letting the agents go and do something or even removing production database and stuff.

Human in the loop is an important control for AI agents. And I break it down into 3 different categories. Which one is right will depend on the sensitivity of the data, the timeliness during which the decision needs to be made, and also the reversibility of the decision. So the first type of human in the loop that I talk about is default deny. That means unless a human approves something, the AI agent can't do its desired action. So if you're talking about a surgical procedure and the agent is being overseen by a human doctor and there's a robot that's about to make an incision, I think default deny makes sense for that case because you want a human expert. Now, in the middle case, in terms of sensitivity and timelines, you have default allow where unless a human acts within a given timeframe, then the AI agent can take the action that it's proposed. And I think autonomous vehicles are where this makes the most sense. If you have an AI system that says, I'm going to slam on the brakes in the next 2 seconds unless you you stop me, that's a case where you do want the system to slam on the brakes on a car unless a human stops it, because most of the time the AI system is going to want to correctly hit the brakes.

And in the case where it's, where it's wrong, then the human can override it. But most of the time you want to hit the brakes. And if you don't, if you take a default deny approach, then you might have a car accident. So that's where default allow might make sense. And then finally, there would be post-hoc review. Where the AI agent is automatically making decisions and it's logging the results in a register. And then on a set cadence, maybe weekly, monthly, you can go back and look at how it's performing and then decide whether to tune the system, whether to apply those first 2 types of human in the loop, or to just let it continue on. So if we're talking about routing network traffic, that would be a good situation to use post-hoc review because you You don't need a human to make a decision about where to send a given pixel in a video conference because if it goes to the wrong place, it's not that big a deal. So those are the 3 types of human in the loop that I talk about. And I think all of them are appropriate to consider with AI agents.

Yeah. No, thank you. Thanks for your detailed response and especially breaking down the different types of segregation that we should consider in terms of keeping human in the loop in your AI governance framework, especially In terms of controlling the AI agents. Now for the last segment and to wrap up this episode, I'm going to pass it over to Mac.

Thanks, Sam. Thanks, Walter. So I really love the way the conversation is going. For this last segment, I'm going to ask you about the budgetary stuff. So for example, let's say for a CISO or security leader who has budget to spend on AI security this quarter or next quarter, what should they do first? What should they do second, and what should they absolutely not spend money on yet?

The first thing that a security team should spend money on is inventorying their AI systems, because if you don't know what AI systems you're using, there is basically nothing you can do from a risk management perspective that will be effective. So inventory would be the first thing. Second of all would be looking at the built-in controls for your AI systems. And that doesn't necessarily even require spending money. It might require some man hours, but doesn't require tools. So making sure you're opted out of training, making sure you've disabled any unneeded features, making sure that you've got the right data retention settings in place. These are all very cheap things that you can do very quickly. And then after that, looking at things like AI monitoring systems, logging, auditing. Tools that will keep a record of what the system has done over time, that will be a good place to allocate resources for a security team concerned about AI governance. Okay.

Thank you. For the last question in this episode is that you have built a free 5-day email course on AI security through Stackware, covering cybersecurity, compliance, and privacy for AI deployments. What's the one concept from that course that surprises people most? Something they assumed they already understood, but they actually didn't.

The biggest misconception that people have about artificial intelligence security compliance is that running a model on your own hardware or on an infrastructure as a service platform is not necessarily more secure than a software as a service platform. And many old school security and technology people will say that I can't trust it unless it's running on my hardware. Well, I would say, okay, understood. But there are a lot of costs that you incur by running things on your own hardware. You need to account for the physical security of it. You need to make sure that you have disaster response, that you have fire suppression, that you have power supply, that you have encrypted local disk encryption. All these things are challenging for companies to implement if they're not a data center company. And even data center companies have these challenges too. So I would say automatically defaulting to saying, hey, I'm going to run it on my hardware or run it on infrastructure as a service, which many people treat as their own hardware, but it's definitely not. I would say I would recommend avoiding that. And For most companies, software as a service deployments make the most sense.

For others with certain types of bespoke needs, you may need to run your AI locally, or it may be more cost effective if you are a specialist and if you know exactly what you are doing.

Yeah, I think that's a great suggestion to start with the SaaS first and then probably to go for the cheapest option first, not just hit the banks first. So thank you so much, Walter, for this conversation. And for the closing section, I'm going to pass it over to Sam.

I cannot hear you, Sam.

I apologize. Walter, this has been exactly the kind of conversation our audience needs. Practical, no hype, with real frameworks behind it. The governance before tool message alone is worth the whole episode. And thank you for sharing all the tidbits and your wisdom around governance framework. Now, especially for our listeners, I would like to know that how do they reach out to you? Where can they find you? If they want to continue this conversation, or if they want to know more about your organization, Stackware.

The best place to find me is on LinkedIn. I'm Walter Heydock. I'm the only one there. Send me a direct message. And if you are in healthcare, financial technology, or B2B software and need help, I'll be happy to chat with you about what Stackaware can do.

Thank you, Walter. So for our listeners, if you're a CISO, CTO, or security leader trying to figure out how to deploy AI without getting burned, Walter's work is some of the most actionable content out there. So feel free to reach out. And just wanted to remind before we wrap up this episode, subscribe to Inside Assemble AI on YouTube, Spotify, Apple, Amazon Music, and iHeartRadio. We bring you the practitioners who have already built these programs, not the, just the people talking about AI. Until next time, keep learning, keep building, and remember, In AI security, deciding late is still deciding, just badly. This is Inside Assemble AI, where AI, deep tech, and science meet storytelling. Thank you everyone for listening.

Thank you.

Thank you.