{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidf3ko3cppo3ahrearvvmu6phmnsemuzl5evkf3m7ncxgzrd5ima4",
    "uri": "at://did:plc:qz6ohvpdsdvv5kniizyfz25y/app.bsky.feed.post/3mncswbkewnd2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiehjuu5kgyck4nwpsgmkgj2qslkga3dtpqnvq4x5wkukuijg3ilsy"
    },
    "mimeType": "image/jpeg",
    "size": 711618
  },
  "path": "/article/4179488/vibe-coding-an-ai-governance-platform-forced-me-to-rethink-governance-itself.html",
  "publishedAt": "2026-06-02T11:00:00.000Z",
  "site": "https://www.cio.com",
  "tags": [
    "Artificial Intelligence, Data Governance, Data Management, IT Governance, IT Leadership",
    "NIST AI Risk Management Framework",
    "EU AI Act",
    "OWASP’s Top 10 for LLM Applications",
    "MITRE ATLAS",
    "Want to join?"
  ],
  "textContent": "For most of my career, governance operated on the assumption that technology evolves slowly enough for oversight processes to keep pace.\n\nPolicies are written. Architecture reviews happen. Security teams validate controls. Compliance mappings are documented. Audit cycles verify implementation.\n\nThat model worked reasonably well for traditional enterprise systems.\n\nIt breaks down quickly once AI enters the environment.\n\nI realized this while vibe coding a production AI governance platform almost entirely through direct collaboration with Claude. What started as a technical experiment became much more significant. The process forced me to confront how quickly AI compresses the distance between concept, deployment and operational risk.\n\nI have spent more than 30 years in cybersecurity building security practices, advising regulated organizations and working across governance, ransomware readiness, penetration testing and security operations. Over the last two years, one issue kept surfacing repeatedly in executive conversations:\n\nOrganizations knew employees were using AI, but they had very little visibility into where it was happening, what data was being exposed or how decisions influenced by AI were being validated.\n\nThe problem was not theoretical.\n\nEmployees were already integrating AI into day-to-day workflows faster than governance processes could adapt.\n\nThat became impossible to ignore once I started building with AI directly myself.\n\n## AI compresses governance timelines faster than organizations expect\n\nI am not a modern software engineer.\n\nI learned to code decades ago, then spent most of my career focused on security leadership, consulting and operational strategy. Like many executives, I eventually moved away from hands-on development because my role shifted toward organizational leadership and technical oversight.\n\nAI changed that equation almost immediately.\n\nInstead of handing requirements to development teams and waiting through traditional engineering cycles, I could work directly with the model myself.\n\nI would describe a capability. Claude would generate code. I would test it. Break it. Refine it. Iterate again.\n\nThat loop repeated thousands of times during development.\n\nThe speed difference was dramatic enough that it forced me to rethink some of my assumptions around governance entirely.\n\nAt one point during development, I asked Claude to estimate what a traditional engineering effort might have looked like for the platform we had built. Based on the codebase size, integrations, compliance workflows, governance features and operational capabilities, the estimate suggested a traditional U.S.-based engineering effort could have required more than 20 engineers, multiple years of development and potentially tens of millions of dollars in fully loaded cost.\n\nWhether the estimate was directionally perfect is almost beside the point.\n\nThe execution compression is real.\n\nThat compression creates governance consequences most organizations are not prepared for.\n\nTraditional governance models assume enterprise technology evolves slowly enough for architecture reviews, security assessments and compliance oversight to keep pace with implementation.\n\nAI breaks that assumption.\n\nCapabilities evolve faster. Integrations happen faster. Workflows change faster. Employees adopt tools faster. Shadow AI spreads faster.\n\nThe largest governance risk I encountered during development was not hallucination.\n\nIt was governance lag.\n\nThe platform evolved faster than traditional governance processes naturally operate.\n\nThat forced me to rethink governance as a continuous operational discipline instead of a periodic review process.\n\nThis is one of the reasons frameworks like the NIST AI Risk Management Framework and the emerging EU AI Act matter so much right now. Both acknowledge something many organizations are still struggling to operationalize AI systems require ongoing governance because their behavior, usage patterns and risk exposure evolve continuously.\n\nBuilding with AI made that reality impossible to ignore.\n\n## Building with AI exposed the real governance problem\n\nThe second major realization came from how the models behaved operationally.\n\nThe models were simultaneously extremely capable and confidently wrong.\n\nNot obviously wrong. Plausibly wrong.\n\nSometimes Claude would generate elegant code that referenced nonexistent functions. Sometimes logic appeared operationally sound while quietly introducing security risk. Sometimes compliance mappings looked correct while subtly misrepresenting implementation requirements.\n\nThe dangerous part was not hallucination itself.\n\nThe dangerous part was synthetic confidence.\n\nOutputs often looked authoritative enough that less experienced operators might never challenge them.\n\nThat changes governance fundamentally.\n\nTraditional enterprise systems generally behave deterministically enough to validate periodically. AI systems behave probabilistically. Outputs are influenced by prompting, context windows, user interaction, model updates and external data sources.\n\nThat creates a very different operational governance problem.\n\nThe more I built, the more obvious it became that AI governance cannot remain document-centric.\n\nPolicies matter. Committees matter. Review processes matter.\n\nBut governance without runtime visibility becomes governance theater.\n\nMost organizations currently approach AI governance through static control structures:\n\n  * Acceptable use policies\n  * Steering committees\n  * Procurement reviews\n  * Periodic assessments\n  * Compliance documentation\n\n\n\nThose are necessary foundations.\n\nThey are not operational governance.\n\nOperational governance requires visibility into how AI is actually behaving inside the environment.\n\nThat visibility challenge is much larger than most organizations currently understand.\n\nTraditional DLP architectures were designed around obvious exfiltration patterns:\n\n  * Large file transfers\n  * Suspicious destinations\n  * Malicious behavior\n  * Bulk exports\n\n\n\nShadow AI rarely behaves that way.\n\nMost of the time, it looks like productive employees trying to move faster.\n\nA developer troubleshooting code through a public model. A finance employee refining contract language. A marketing team generating customer-facing content. An analyst uploading sensitive business data into an unsanctioned workflow.\n\nNot malicious insiders.\nNormal business behavior.\n\nThat creates a governance challenge traditional security architectures were never designed to handle.\n\nThe more I built, the more I realized AI governance required at least five operational dimensions:\n\n  * Policy\n  * Procedure\n  * Implementation\n  * Testing\n  * Training\n\n\n\nMost organizations currently stop at policy.\n\nPolicy without implementation visibility is ineffective. Policy without testing creates false confidence. Policy without training collapses under productivity pressure.\n\nMost importantly, governance without observability fails operationally.\n\nThis is why work from organizations like OWASP’s Top 10 for LLM Applications and MITRE ATLAS is becoming increasingly important. They move governance discussions closer to runtime behavior, attack surfaces and operational controls instead of treating AI strictly as a policy problem.\n\n## The organizations that operationalize governance early will shape what comes next\n\nBuilding a production AI governance platform through vibe coding changed how I think about AI entirely.\n\nNot because AI replaced engineering teams.\n\nNot because models became magically intelligent.\n\nBecause building with AI exposed how quickly traditional governance assumptions stop working once AI becomes operational inside a business.\n\nMost organizations are still treating AI governance as a future-state problem.\n\nIt is not.\n\nEmployees are already using AI throughout the enterprise whether leadership has visibility into it or not. That means the real governance question is no longer, “Should we allow AI?”\n\nThe real question is, “How do we operationalize governance around systems already influencing business decisions?”\n\nThat requires much more than documentation.\n\nIt requires runtime visibility. Human accountability. Evidence validation. Testing. Trust boundaries. Continuous monitoring. Operational controls.\n\nMost importantly, it requires leadership teams to engage directly enough with the technology to understand where traditional governance assumptions begin to fail.\n\nThat was the unexpected lesson from vibe coding the platform myself.\n\nThe closer I got to the technology; the less theoretical governance became.\n\nAnd the more convinced I became that the organizations operationalizing AI governance now will shape what enterprise AI looks like over the next decade.\n\nThe ones waiting for governance frameworks to fully mature before engaging are probably going to inherit systems, workflows and risks they never truly controlled.\n\n**This article is published as part of the Foundry Expert Contributor Network.**\n**Want to join?**",
  "title": "Vibe coding an AI governance platform forced me to rethink governance itself"
}