<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[Mark]]></title><description><![CDATA[Product Strategist @ FDA | LLM & Algorithmic Governance specialist. I turn ambiguous gov-tech requirements into tangible AI solutions. 10+ years leading digital transformation in high-stakes, regulated spaces (DoD, FDA). Let's build the future.]]></description><link>https://newsletter.markgingrass.com</link><image><url>https://substackcdn.com/image/fetch/$s_!CNag!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8b60c820-4c60-40c2-bcb7-e7d7dd94e30c_1024x1024.jpeg</url><title>Mark</title><link>https://newsletter.markgingrass.com</link></image><generator>Substack</generator><lastBuildDate>Sun, 10 May 2026 09:49:21 GMT</lastBuildDate><atom:link href="https://newsletter.markgingrass.com/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[Mark]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[markgingrass@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[markgingrass@substack.com]]></itunes:email><itunes:name><![CDATA[Mark]]></itunes:name></itunes:owner><itunes:author><![CDATA[Mark]]></itunes:author><googleplay:owner><![CDATA[markgingrass@substack.com]]></googleplay:owner><googleplay:email><![CDATA[markgingrass@substack.com]]></googleplay:email><googleplay:author><![CDATA[Mark]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[The AI Solution Trap]]></title><description><![CDATA[Federal agencies are spending real money on AI without asking the basic questions. The result: expensive tools layered on broken processes.]]></description><link>https://newsletter.markgingrass.com/p/the-ai-solution-trap</link><guid isPermaLink="false">https://newsletter.markgingrass.com/p/the-ai-solution-trap</guid><dc:creator><![CDATA[Mark]]></dc:creator><pubDate>Fri, 08 May 2026 20:25:11 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!CNag!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8b60c820-4c60-40c2-bcb7-e7d7dd94e30c_1024x1024.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>I tried to have an LLM write this post for me. It failed.</p><p>The draft was cleaner than mine, but it was hollow. Every sharp point got softened into a &#8220;balanced perspective.&#8221; Every real opinion got buried under caveats. It sounded polished, professional, and completely forgettable. Like most AI-written commentary, it used all the right words and said almost nothing.</p><p>The federal AI space has the same problem. Real money chasing solutions. No patience for basic questions: What problem are we solving? Who is this for? What changes if this actually works?</p><p>That&#8217;s how you end up spending serious money to automate confusion.</p><h2>The Speed Trap</h2><p>The program managers are usually the quietest people in the room. They see the weak requirements, the bad assumptions, and the missing data. They know what&#8217;s actually broken.</p><p>But by the time they&#8217;re in that room, the decision has already been blessed three levels up. The budget is allocated. The contract vehicle is picked. Staying quiet and buying the tool is the safest career move left.</p><p>So that&#8217;s what happens. Leadership gets movement. Vendors get paid. Agencies get a modern interface on top of a broken process.</p><p>A broken process that now demos better.</p><h2>The Process Problem</h2><p>This is where most of the waste lives.</p><p>Federal agencies are layering expensive technology onto workflows that should&#8217;ve been simplified, redesigned, or deleted years ago. Instead of asking whether a process deserves to exist, they ask how AI can be inserted into it.</p><p>One team uses AI to scrape updates from a tracker and generate a 40-slide deck. Leadership uses AI to summarize that deck into three bullets. Someone uses AI to draft a reply: &#8220;Thanks, keep going.&#8221; At every step, work is being done, time is being saved, and none of it creates value.</p><p>It&#8217;s the digital equivalent of putting a turbocharger on a shopping cart.</p><p>Automating waste doesn&#8217;t make it strategic. It just produces useless output faster and with more confidence. When something actually goes wrong, nobody trusts the polished dashboard. They call the person closest to the problem and ask what&#8217;s happening.</p><p>That should tell us everything we need to know.</p><h2>The Ownership Trap</h2><p>When agencies buy AI, they aren&#8217;t just buying software. Unlike a legacy system that fails the same way every time, an AI model degrades. It drifts. Inputs change, policies change, user behavior shifts &#8212; and a model that worked on day one quietly becomes wrong at scale.</p><p>If the contract is weak on data rights, the agency ends up paying for a capability it can use but can&#8217;t control. That&#8217;s how the duplication loop starts. One office pays to develop a model. Another office has the same need, but the implementation is locked in a vendor&#8217;s proprietary stack. It can&#8217;t be reused.</p><p>The government buys the same answer twice.</p><p>If you can&#8217;t inspect it, retrain it, or fix it without calling the original vendor, you don&#8217;t have a solution. You have a rental with a degradation clock running in the background.</p><h2>The Talent Gap</h2><p>Upskilling efforts in the federal AI space are mostly theater. The gap isn&#8217;t closed by hiring a few specialists or teaching staff to prompt a chatbot. Prompting isn&#8217;t strategy.</p><p>The people agencies need are the ones who understand how these systems behave in production &#8212; how they fail, how they drift, when to shut them off. People who can maintain a model through a recompete, an ATO renewal, a policy change, and two rounds of staffing turnover without losing the thread of what it was built to do.</p><p>That talent walks out the door. A contractor team builds something promising, leadership celebrates, and a few months later the expertise is gone. The PM is left holding a tool they can operate on a good day but can&#8217;t troubleshoot when the outputs start looking wrong.</p><p>The organization didn&#8217;t build capability. It outsourced the brain and called it progress.</p><h2>The Work Comes First</h2><p>Cut the process before you automate it. If a workflow improves when you remove two steps, those steps never needed a model &#8212; they needed a leader willing to delete them.</p><p>Define what you&#8217;re actually buying. Not &#8220;AI capability.&#8221; A result. Faster grant reviews. Fewer manual reconciliations. Shorter time from intake to decision. If the outcome can&#8217;t be stated in plain English, the acquisition is too vague to survive.</p><p>Secure real ownership. Data rights, retraining rights, documentation. If the agency needs to call the vendor to understand what the system is doing, it doesn&#8217;t own the solution. It&#8217;s just paying for access.</p><p>A prototype is easy. A production system that survives a policy change, an audit, and a change in administration is hard. That&#8217;s where the actual work gets done.</p><p>We keep buying complexity because clarity is harder to defend in a budget hearing. Saying &#8220;we deleted two approval steps and cut processing time in half&#8221; doesn&#8217;t land the same way as &#8220;we deployed an AI-enabled workflow modernization platform.&#8221; But one of those actually solved something.</p><p>The hard part isn&#8217;t buying the AI. The hard part is knowing when not to.</p><p><em>The views expressed here are my own and do not represent any federal agency.</em></p>]]></content:encoded></item><item><title><![CDATA[The Certificate Warning Nobody Reads]]></title><description><![CDATA[Federal IT security theater: how certificate click-throughs became compliance artifacts that protect auditors, not systems.]]></description><link>https://newsletter.markgingrass.com/p/the-certificate-warning-nobody-reads</link><guid isPermaLink="false">https://newsletter.markgingrass.com/p/the-certificate-warning-nobody-reads</guid><dc:creator><![CDATA[Mark]]></dc:creator><pubDate>Fri, 08 May 2026 13:36:14 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!CNag!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8b60c820-4c60-40c2-bcb7-e7d7dd94e30c_1024x1024.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>You&#8217;ve seen it. The browser throws up a wall of text, &#8220;Do you trust this certificate?&#8221; followed by a string of hex digits that are meaningless to humans. You&#8217;re on a government computer. You&#8217;re inside a federal building.</p><p>You click <em>yes</em>.</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://newsletter.markgingrass.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">This Substack is reader-supported. To receive new posts and support my work, consider becoming a free or paid subscriber.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p>Of course you click yes. Name one person who doesn&#8217;t.</p><p>This screen only exists so somebody can prove you clicked it. The ATO (Authority to Operate: the formal authorization a federal system needs before going live, issued after a security assessment package is reviewed) package has a control that says users must validate certificate trust. The system records the click and calls that a control. Nobody in that chain ever stopped to ask whether clicking yes changes anything.</p><p>That&#8217;s not security. That&#8217;s paperwork with a button. Worthless.</p><p>Click <em>yes</em> enough times and it becomes muscle memory. Which means the one time the warning actually matters, a legitimate attack could happen.</p><p>A warning everyone ignores isn&#8217;t a safeguard in any sense. It&#8217;s camouflage for bean counters. The auditor gets the screenshot. The attacker gets the goods.</p><h2>Why the Popup Exists</h2><p>Here&#8217;s how it usually goes. Someone stood up TLS inspection (<strong>Transport Layer Security</strong>: the protocol that encrypts network traffic between a client and a server). Nobody pushed the root certificate cleanly to managed devices. The browser complained. So the workaround became policy: click yes, carry on. Six months later, nobody remembers why the warning appears or whose job it is to fix it. It&#8217;s just part of the environment.</p><p>The popup isn&#8217;t adding any value.</p><h2>This Is the Standard Playbook</h2><p>The cert warning isn&#8217;t a one-off failure. It&#8217;s how federal IT security operates.</p><p>The annual security awareness training everyone clicks through in under an hour to clear the compliance flag? Same mechanic. The forced password change cycle that kept government sticky-note suppliers in business for a decade? Same mechanic. The enterprise-wide Zero Trust mandate in the strategy document while users manually bypass session hygiene every morning? Same mechanic.</p><p>In every case, a real security requirement got translated into a user interaction that nobody takes seriously. The box gets checked. The behavior doesn&#8217;t change.</p><p>It&#8217;s cheaper to make 80,000 people click through nonsense than to fix one broken enterprise service. So nobody fixes the service. Federal IT has spent two decades building for the audit and breaking for the mission. If a control generates a log, a screenshot, or a completion record, it survives budget cycles. If it requires fixing the underlying infrastructure, it gets deferred.</p><h2>What the System Rewards</h2><p>Nobody gets promoted for eliminating the popup.</p><p>The Authorizing Official signs a Risk Acceptance, documents the residual risk, and calls it managed. The control owner gets credit for the artifact. The help desk absorbs the tickets. The user absorbs the risk. The fix request dies in the intake queue.</p><p>This is what happens when control owners can pass audits without owning user behavior. The program office buys the system. Enterprise IT breaks the trust chain. Security signs off on the control language. Nobody owns what the user sees on the other end.</p><p>When the breach happens &#8212; and the logs show the warning appeared six hundred times and the user clicked through every single one &#8212; nobody is responsible. It was documented. The user was informed.</p><h2>We Blame the Wrong People</h2><p>We call it a workforce problem. Users don&#8217;t take security seriously. They click through warnings without reading them.</p><p>We designed it that way.</p><p>We built systems that produce compliance artifacts instead of secure behavior, then blamed the people who adapted to the environment we built. The annual training is forgettable by design &#8212; anything longer doesn&#8217;t clear the flag on time. The cert warning is ignorable by design &#8212; if it blocked access, it would generate more tickets than IT could handle. Every friction point that was too inconvenient got softened into a checkbox and called a control.</p><p>The workforce is doing exactly what the system trained them to do.</p><h2>The Control Was Fake From the Start</h2><p>If your security control depends on a user interpreting a certificate thumbprint, you don&#8217;t have a security control. You have a ritual.</p><p>A real control removes the decision from the user. It&#8217;s rare enough that when it fires, people notice. It doesn&#8217;t need to explain itself with a wall of hex digits no one will ever read.</p><p>The warning was fake the day it shipped. All it ever protected was the agency&#8217;s ability to say it tried.</p><p><em>The views expressed here are my own and do not represent any federal agency.</em></p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://newsletter.markgingrass.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">This Substack is reader-supported. To receive new posts and support my work, consider becoming a free or paid subscriber.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div>]]></content:encoded></item></channel></rss>