Linda Fry

Is your GRC Team generating AI slop? We are in the heyday of AI. As a tech leader, I’m inspired by the capabilities we’ve unlocked. But there is a hidden cost. In high-pressure innovation cycles, it’s easy to let AI output outpace your maturity. When that happens, you’re building your GRC strategy on sand. For a CISO or GRC Exec, AI slop is more than just annoying, it can result in a systemic failure of an organization’s safeguards. How do you know if your team has crossed the line? Look for these 5 red flags: •  The "Black Box" Defense: Your team can’t stand up to light probing on the work they produce. If your team can’t explain the logic behind why a specific control was deemed "ineffective" without saying "the model flagged it," you have a liability, not an audit trail. Accountability cannot be delegated to an agent. •  High Noise-to-Signal Ratio: Are your cross functional partners spending more time "cleaning" your risk analyses than acting on it? If they are wading through mountains of AI-generated reports just to find the three useful calls to action, the AI isn't a force multiplier. It’s a distraction. •  The Nuance Gap: AI often misses the human-in-the-loop nuances that define modern GRC. It might flag a technical non-compliance without weighting it against business priorities, or communicate the finding without taking into account specific relationship dynamics. Logic drift happens when models treat risk as a static math problem rather than a dynamic business reality. •  High Inference Tolerance: This is a term we need to get comfortable with. Is your AI agent asserting a risk remediation timeline because it parsed a real roadmap, or is it hallucinating based on generic training data? Without guardrails on temperature, your Tech Risk Management is just high-speed guesswork. •  Automating Dysfunction: Automating a broken process doesn't improve its value proposition. If you use AI to pump out controls performance and KRI reports that no one reads into a dashboard no one uses, you’ve just accelerated the rate at which you produce waste. The bottom line is that the AI bubble won’t pop because the technology fails. It will pop because the execution debt bears fruit. The difference between being a victim of the bubble and a soft landing is ensuring that your legacy is not a mountain of high-speed, automated slop. What’s the most egregious example of AI slop you’ve seen lately? (Names changed to protect the innocent, of course) #TechRisk #CybersecurityRisk #AIRisk #GRC #AIGovernance #ResponsibleAI

Most Tech Risk functions are built to be a bottleneck; I spent the last six months proving they should be an engine. I built this home office to be a sanctuary for high-stakes problem-solving because I refuse to treat GRC as a back-office administrative task. While I’m saying goodbye to my role as Director of Security & Technology Risk Management at Coinbase due to a 14% RIF, I’m grateful to keep this view as I plot my next move. As Brian’s note makes clear (link in comments), the pivot is toward a flatter model to eliminate "coordination tax" by leaders assuming up to 15 direct reports. During my six months of concentrated velocity, we didn't wait for a more efficient structure; we architected it. We restructured Tech Risk into an AI-native engine grounded in engineering principles to remain nimble and high-impact. To my team: It was a privilege to lead you. You are the talent density the industry is looking for, and you deserve a leadership hand that supports the ambitious, data-driven foundations we’ve laid together. We moved the needle through four key pillars: • Reliable and Actionable Data: Led a focused risk register data quality uplift sprint, built a self-service dashboard ecosystem, and launched AI-driven narrative risk analysis. Aligned 1LOD executive leadership on incorporating Tech Risk insights and GRC calls to action into established quarterly planning processes. • Quantitative Risk Analysis: Built foundations to measure and communicate risk in financial terms grounded in statistical concepts; achieved sophisticated analysis without the expensive third party software. • Shifting Left to Risk-Informed Velocity: Modernized our "check and challenge" capabilities to identify irresponsible risk without becoming a bottleneck to innovation. • Operational Excellence: Redesigned our org into a service model that anticipated the shift toward smaller, high-context teams managing fleets of agents. During this "no meeting week" dedicated to deep work, I was building a GRC AI Agent that cross-references decision memos against our risk, findings, policy exceptions, and incident databases. The goal is to provide authors with an intellectually honest and balanced analysis of their proposals in real-time. I’m entering this summer with a clear head and a full heart. Between working on AI projects right here in this office, maintaining a neighborhood vegetable garden in my front yard, and running for local office to serve my community, I’m staying grounded in the work that matters. If your organization is looking for an executive to bridge the gap between modern GRC architecture and AI-driven operational excellence, let’s connect. Onward. #TechRisk #CyberRisk #GRC #RiskQuant #RiskManagement #Coinbase

Hot take: LinkedIn should officially recognize an organically earned Slack emoji as a legitimate career milestone. 🏆

I have a budding theory that vertical risk teams have to be more pessimistic than Enterprise Risk teams. In my view, an ERM team exists to aggregate data, identify cross-cutting themes, and tie them to strategic objectives. At that level, the "Decision-Centric Risk Management" crowd is right: risk should be analyzed when it’s time to inform a choice. It makes sense for an ERM conversation to start with, “What are your strategic objectives, and what could get in the way of achieving them?” However, Vertical Risk teams like Tech or Cyber Risk operate in a different reality. If we start with a goal-oriented statement like "What are your strategic objectives?" the answer from an Engineering Team is usually "to deliver [Product X] ASAP" This introduces an unnecessary layer of translation, forcing specialists to sell why technical reality matters to a business dream. We can avoid this by going straight to the inherent fault lines. This approach serves as a critical diagnostic tool to prevent the common trap of conflating issues with risks. By identifying the fault lines first, we acknowledge what is already broken (the issue) before calculating how those cracks might actually jeopardize a future destination (the risk). We only tie these fault lines to strategic objectives after they've been identified. This allows us to filter out the noise - those existing issues that, while imperfect, don't actually threaten the current journey. From there, the real work begins by layering in the conflicts in prioritization. This answers the ultimate question: “Are we focusing on the right problems, or just the loudest ones?” While the "Decision-Centric" approach is vital for choosing a path, vertical risk teams must provide the "Status-Centric" reality check. If we only analyze risk when a decision is on the table, we ignore the slow erosion of the foundation that happens between those decisions. Ultimately, the two approaches serve different masters: Enterprise Risk is optimistic; it looks at how to safely reach a goal, and it informs the decision of where we are going. Vertical Risk is foundational, it looks at the structural integrity of the ship, whether it’s sailing to a destination or sitting in the harbor. It informs the decision of whether we are even fit to make the trip. Both risk teams drive data-informed decision-making, but they require fundamentally different lenses. One decides where to steer, and the other ensures the hull can take the pressure.

There is an obsession in our industry with perfect risk quantification. We’ve all seen the debates where purists argue over specific methodologies as if they’re defending a religious text. Here is a truth that feels like a heresy to say out loud: if your math is so complex that your CISO, CRO, or Board needs a PhD to understand and defend the results, you haven't built a risk model, you’ve built a black box. Dogmatic adherence to "pure" quantification is often just a distraction from a lack of underlying data quality. When we prioritize a specific tool over pragmatic decision-making, we stop being risk leaders and start being mathematicians in a vacuum. The reality is that most organizations simply aren’t ready for advanced, automated quantification on Day One, and that is perfectly okay. Forcing high-end models onto a low-maturity culture is the fastest way to ensure your reports become compliance noise. To move from vibe-based risk to actual technical architecture, you need a roadmap that prioritizes judgment over syntax. * Phase 1: Qualitative Risk: Start with clear, plain-English conversations. If you can't explain the risk without a spreadsheet, you don't understand the risk. * Phase 2: Qualitative with Quantitative Bands: Stop using "High/Medium/Low" in isolation. Map those labels to broad financial ranges so the business has a consistent anchor for the "vibe". * Phase 3: Calibrated Estimation & Data Maturation: Train your team to identify where their own biases are masking reality. Use calibrated estimates to fill data holes while you simultaneously identify and mature the specific telemetry you need for the future. * Phase 4: Calibrated Estimation Quant with Deep-Dive "Slow" Quant: Save the heavy lifting for your strategic bets where you can afford to take the time. For the daily grind, keep it lean with calibrated estimations with some light math and maybe Monte Carlo simulations on your calibrated ranges. * Phase 5: Automated Risk Engineering: This is a living telemetry pipeline where risk scores recalculate in real-time based on actual technical gaps in your environment. Many organizations will find their "sweet spot" at the penultimate phase, and there is no shame in that. You don't need to reinvent the physics of risk to manage the daily grind. As a leader, your job is to transform GRC from a reactive cost center into a strategic engine. Don't let the purists convince you that your program is failing because you aren't using their specific flavor of math. If the goal is sustainable innovation, the best model is the one that actually informs a decision today, not the one that remains "100% compliant" but 0% useful. Don't get me wrong, high-fidelity risk quantification absolutely works, but if your organization isn't ready for that level of engineering, forcing it isn't best practice or the only way to add value. Are you building a technical architecture that scales, or are you just defending a methodology?

I'm going to commit what feels like a cardinal sin and talk about the AI bubble. We're currently in the beta testing phase of enterprise AI where many companies remain in the honeymoon period of their initial pilots. While the assets look healthy on paper because the underlying risk is masked by a rising market, I wonder if this is similar to the subprime mortgage crisis in the lead-up to '08. I'm a firm believer that AI is the future. It's the ultimate force multiplier and we should all be finding new ways to work alongside these models. BUT, history shows that market corrections follow periods where the excitement of an asset class outpaces the governance of the underlying process. In the 2000 .com boom, the market ignored the lack of real revenue. In the 2008 real estate bubble, the market ignored the lack of underlying asset quality. In 2026, the primary risk is execution debt. We're starting to see the quiet buildup of a systemic liability. Most orgs haven't yet faced a trigger event that forces them to audit their AI decisions, and they're operating on good faith, which is an incredibly dangerous risk posture for any org. We've already seen examples where organizations spend a significant amount of their saved time peer-reviewing and fixing AI hallucinations or errors in automated reports, and a logic drift leading to a cascade of errors that requires months manual auditing to fix. The impending correction is a failure of controls rather than a failure of tech. The difference between a crash and a soft landing is the GRC frameworks we build around these systems. We don't need to reinvent the wheel or create new physics. By the time the execution debt matures, when a major model shift happens or a significant compliance breach forces an audit, the companies that lacked GRC guardrails will be forced to undergo an expensive, painful, and likely public refactoring of their entire AI strategy. This is the point where the distinction between AI-enabled and AI-governed companies will determine who survives the correction. We must apply foundational GRC principles to this volatile asset. This means prioritizing model integrity WITH hype by moving toward standardized model risk management. It means treating ethical guardrails as a business moat because robust oversight is a prerequisite for long-term market access. It also requires accountable autonomy where humans govern while AI enables. GRC ensures that for every agentic decision, there is a clear trail back to a human owner. The goal is to make innovation sustainable. If we treat AI as a plug and play miracle without managing the underlying technology risk, we're building on sand. By integrating risk management today, we ensure that when the speculative hype clears, the actual value remains. We can improve quality and scale efficiency without sacrificing our ethical standards. The bubble can exhale safely because GRC is the valve. ...and, yes, this was written with the help of AI :)