The AI Governance Brief

Keith Hill
  • 5.0 (1)
  • MANAGEMENT

Daily analysis of AI liability, regulatory enforcement, and governance strategy for the C-Suite. Hosted by Shelton Hill, AI Governance & Litigation Preparedness Consultant. We bridge the gap between technical models and legal defense.

  1. AI Governance Failure: You Don't Know Your Own Organization

    1D AGO

    AI Governance Failure: You Don't Know Your Own Organization

    Seventy-five percent of HR leaders report that managers are overwhelmed and not equipped to lead change. But before you dismiss this as a middle management problem, consider: by the time information reaches the CEO, it has been filtered, softened, and "customised to cater to superiors' expectations" at every level. Researchers call it "interpreting upwards." You're not leading the organization you think you're leading. You're leading the organization people want you to believe exists. And that organization is a fiction. In This Episode: The CEO Bubble Is RealGartner 2025: 75% of managers overwhelmed and unequipped to lead changeCEIBS research: Information is "interpreted upwards" at each level—filtered, softened, divorced from ground truth66% of employees hide aspects of themselves from senior leaders80% of C-suite executives "cover" with almost everyone around themYou Cannot Move an Organization You Don't UnderstandThe org chart is a legal fiction—necessary for compliance, useless for understanding how work gets doneThe 80/20 reality: 20% of people drive 80% of influence—and they're not always the people with titlesWith just 20 influential employees identified through ONA, companies can reach 70% of the entire organizationThe Seven Types of Informal PowerExpertise-Based Power (technical knowledge, organizational memory)Reputational Power (track record, reliability)Relational Power (access to key people, social capital)Cultural Gatekeeping (control over "how things are done here")Information Brokerage (bridging disconnected groups)Resource Control (informal control over budgets, tools, access)Positional Proximity (closeness to decision-makers)Network Position Metrics That MatterDegree Centrality: Direct connections—ability to spread information or resistance quicklyBetweenness Centrality: Bridge between disconnected groups—the brokers with cross-silo perspectiveEigenvector Centrality: Connected to other highly connected people—systemic influenceWhy Your AI Governance Initiative Will FailYou'll launch through formal channels targeting formal authorityYou'll miss the informal systems that actually determine what people doPredictable arc: announcement → compliance → erosion → irrelevanceWells Fargo, Boeing: Executives were the last to know about problems employees understood clearlyYour Seven-Day Action Plan: Days 1-3: Map one network—ask 15 people across levels: "When you need to get something done outside the normal process, who do you go to?" Days 4-5: Schedule three skip-level conversations two to three levels down Days 6-7: Identify one gap between the organization you thought you had and the organization you actually have Ready to see your actual organization? Understanding informal power structures isn't optional for AI governance success. It's the foundation everything else depends on. organizational network analysis, informal power structures, executive blindness, AI governance failure, organizational psychology, skip-level meetings, change management, CEO bubble, interpreting upwards, informal influencers, psychological safety, organizational intelligence

    18 min
  2. CRA COUNTDOWN: Change Management: From Paralysis to Progress

    6D AGO

    CRA COUNTDOWN: Change Management: From Paralysis to Progress

    Six months ago, I worked with a healthcare technology company that had everything CRA compliance requires on paper: executive sponsorship confirmed, steering committee formed, product inventory complete, SBOM tools selected, documentation templates created. Six months of planning. Six months of meetings. Six months of preparing to prepare. When I asked how many products had achieved conformity-ready status, the answer was zero. They had mistaken planning for progress. And September 2026 was now six months closer. In This Episode: Why Knowledge Isn't the Barrier—Execution IsCRA requires simultaneous changes across Engineering, Product, Security, Legal, Quality, and DocumentationEach function has competing priorities and limited capacityWithout structured change management, organizational capacity overwhelms and implementation stallsThe Three-Phase Implementation RoadmapPhase One (Now → Early 2026): Governance, inventory, SBOM infrastructure, documentation systemsPhase Two (Mid-2026 → September 2026): PSIRT operationalization, vulnerability reporting workflows, 24-hour response verificationPhase Three (Late 2026 → December 2027): Complete documentation, conformity assessment, EU Declaration preparationQuick Wins That Build MomentumWeek 1: Executive sponsor announcementWeek 2: Single business unit inventoryWeek 3: First compliant SBOMWeek 4: Pilot product risk assessmentWeek 6: Control mapping to existing frameworksWeek 8: Complete documentation package for pilot productWeek 12: Tabletop vulnerability exerciseOvercoming the Five Resistance Patterns"We don't have time" → Explicit deprioritization decisions"This isn't my responsibility" → RACI matrix clarity"We already do this" → Evidence-based gap analysis"The deadline is far away" → Phase gate accountability"Let's wait for regulatory clarity" → Risk-based implementationThe Cost of Delay (Quantified)20 months remaining allows phased implementation14 months remaining requires 30% faster implementation8 months remaining requires 2.5x resource multiplicationNotified body calendars are filling NOWTalent competition is intensifyingFrom Project to Operational DisciplineDecember 2027 isn't the finish line—it's the starting lineSBOM generation must become permanent pipeline capabilityVulnerability monitoring must become continuousDocumentation must be maintained as products evolveConformity must be reassessed when products change materiallyYour Fourteen-Day Action Plan: Days 1-3: Formalize executive commitment with documented engagement cadence Days 4-6: Identify specific individuals for CRA work with time allocation Days 7-9: Select three quick wins achievable in 90 days with owners and dates Days 10-12: Define Phase One milestones with specific completion dates Days 13-14: Prepare and distribute program kickoff communication Deliverables: Documented executive commitment with engagement cadenceNamed resource allocation with sponsor approvalSelected quick wins with owners and datesPhase One milestone scheduleProgram kickoff communicationReady to convert knowledge into action? The First Witness Stress Test reveals where your organization stands today—and builds the implementation roadmap that converts planning into progress. Stop preparing to prepare. Start executing. CRA implementation, CRA change management, compliance program execution, CRA roadmap, September 2026 compliance, CRA quick wins, compliance momentum, CRA phase gates, regulatory implementation, CRA operational discipline, compliance transformation, CRA program management

    33 min
  3. CRA COUNTDOWN: Episode 6: Healthcare and Finance: Your Sector-Specific Compliance Maze

    FEB 10

    CRA COUNTDOWN: Episode 6: Healthcare and Finance: Your Sector-Specific Compliance Maze

    A healthcare technology CEO told me last quarter that she wasn't worried about CRA because her products were medical devices regulated under MDR. She was half right. Her Class IIa infusion management system is indeed exempt from CRA product requirements. But the cloud platform that aggregates patient data from those devices? Not exempt. The mobile application clinicians use to monitor alerts? Not exempt. The integration APIs that connect to hospital EHR systems? Not exempt. Her MDR exemption protected one product. Her ecosystem has seventeen products in CRA scope that nobody was tracking. In This Episode: Healthcare: Why Your MDR Exemption Is Narrower Than You ThinkMDR exempts medical devices with medical purpose—not the digital ecosystem surrounding themCloud platforms, clinician dashboards, mobile alert apps, integration APIs: likely in CRA scopeThe proposed MDR revision (COM(2025)1023): enhanced cybersecurity requirements coming for certified devicesRadio Equipment Directive (RED) overlay for WiFi/Bluetooth-enabled productsFinance: Why DORA Doesn't Satisfy CRADORA is entity-level regulation (your organization's ICT risk management)CRA is product-level regulation (products placed on the market)Your mobile banking app needs DORA compliance AND CRA compliance—separatelyFinancial industry exemption requests have not prevailedThe Silo Problem in Both SectorsHealthcare: MDR teams lack DevSecOps velocity; IT Security lacks regulatory documentation expertiseFinance: DORA teams don't address product-level compliance; product teams operate outside regulatory structureResult: competent functional performance producing collective compliance failureThe Integration OpportunityISO 27001 implementations provide ~60% CRA requirement coverageHealthcare: Extend MDR QMS to cover CRA requirementsFinance: Map DORA ICT controls to CRA essential requirementsOrganizations aren't starting from zero—they're closing specific gaps from established foundationsSector-Specific Implementation PathsHealthcare: Ecosystem inventory → QMS extension → Notified body harmonization → RED overlayFinance: Product-vs-entity analysis → DORA-CRA mapping → Evidence integration → Dual reportingYour Fourteen-Day Action Plan: Days 1-3: Exemption analysis with documented regulatory rationale Days 4-7: Existing framework inventory (MDR QMS, DORA ICT, ISO 27001, NIST CSF) Days 8-11: Control mapping—CRA requirements vs. existing controls Days 12-13: Gap prioritization by examination risk and implementation effort Day 14: Integration strategy documentation for executive approval Deliverables: Exemption analysis with documented rationaleExisting framework inventoryControl mapping showing CRA coverage percentageGap prioritization with preliminary roadmapReady to map your regulatory overlaps? The First Witness Stress Test includes sector-specific analysis—mapping your existing MDR, DORA, or ISO 27001 controls against CRA requirements to reveal how much coverage you already have and where genuine gaps remain. Stop duplicating compliance effort. Start integrating it.  CRA MDR exemption, healthcare CRA compliance, financial services CRA, DORA CRA overlap, medical device regulation cybersecurity, CRA ISO 27001 mapping, integrated compliance framework, CRA healthcare ecosystem, fintech CRA requirements, connected medical devices, regulatory integration, CRA control mapping

    29 min
  4. CRA COUNTDOWN: Who Owns This? (The Accountability Nobody Wants)

    FEB 9

    CRA COUNTDOWN: Who Owns This? (The Accountability Nobody Wants)

    I recently facilitated a CRA readiness meeting with a mid-size medical technology company. Present: the CISO, the VP of Engineering, the Chief Product Officer, the General Counsel, and the VP of Quality Assurance. I asked a simple question: "Who owns CRA compliance for your flagship monitoring platform?" Forty-five seconds of silence. Then the CISO said, "I assumed Product owned it." The CPO said, "We thought it was a security matter." The VP of Engineering said, "Legal never told us it was our responsibility." The General Counsel said, "We've been waiting for someone to tell us what Legal's role should be." That platform ships to thirty-two EU countries. Nobody owns its compliance. In This Episode: The Accountability Diffusion ProblemCRA compliance touches eight functions—when everyone owns it, no one owns itEach function optimizes for its own objectives; no function optimizes for CRA specificallyCompetent functional performance producing collective compliance failureThe Four Accountability GapsProduct lifecycle ownership discontinuity: who owns the product across 5+ years of support?Cross-functional requirement translation: who converts CRA language into engineering specs, test cases, documentation requirements?Evidence aggregation: who integrates outputs from multiple functions into examination-ready packages?Conformity declaration authority: who signs, and do they have visibility into actual compliance status?The Three-Level Accountability SolutionExecutive Sponsor: Named executive accountable for compliance outcomes—resolves resource conflicts, ensures priority, provides board visibilityCRA Program Owner: Operational coordination, roadmap management, cross-functional alignment, consolidated status reportingProduct Compliance Owners: Named individual accountable for each product's conformity, documentation completeness, evidence maintenanceThe Steering Committee ModelCross-functional decision-making body, not a status meetingResolves conflicts individual functions cannot resolve aloneWeekly during implementation, bi-weekly during steady stateChaired by Program Owner, executive sponsor attends monthlyThe RACI FrameworkProduct inventory: Product Management (R), Program Owner (A)Risk assessment: IT Security (R), Product Compliance Owner (A)SBOM generation: Engineering (R), Product Compliance Owner (A)Technical documentation: Engineering/Tech Writing (R), Product Compliance Owner (A)Conformity testing: Quality Assurance (R), Product Compliance Owner (A)EU Declaration of Conformity: Legal (R), Executive Sponsor (A)Five Governance Pitfalls to AvoidAssigning ownership without authorityOver-centralizing execution (creates bottlenecks)Treating CISO as default owner (CRA is product safety, not just security)Failing to define product-level ownersGovernance without executive commitmentYour Fourteen-Day Action Plan: Days 1-3: Confirm executive sponsorship with explicit CEO/executive team discussion Days 4-6: Identify/appoint CRA Program Owner with defined authority Days 7-9: Form Steering Committee, define membership and meeting cadence Days 10-12: Assign Product Compliance Owners for every in-scope product Days 13-14: Develop RACI matrix for key CRA activities Deliverables: Documented executive sponsorshipAppointed Program Owner with defined authorityFormed Steering Committee with scheduled meetingsAssigned Product Compliance Owners for all in-scope productsRACI matrix defining cross-functional accountabilityReady to establish CRA governance? The First Witness Stress Test includes governance assessment—identifying accountability gaps, mapping current ownership patterns, and recommending structures that convert functional activity into compliance outcomes. Stop assuming someone owns it. Start documenting who does. CRA governance, CRA accountability, compliance ownership, CRA program owner, executive sponsorship compliance, RACI matrix CRA, CRA steering committee, product compliance owner, regulatory accountability, cross-functional compliance, CRA organizational structure, compliance governance framework

    29 min
  5. CRA COUNTDOWN: Episode 4 -Documentation That Actually Survives an Audit

    FEB 5

    CRA COUNTDOWN: Episode 4 -Documentation That Actually Survives an Audit

    In January 2025, a German market surveillance authority examined twelve IoT manufacturers under existing CE marking requirements. Four couldn't produce documentation within the required timeframe. Three produced documentation that failed to demonstrate conformity. Two had documentation so disorganized examiners couldn't determine what had been tested. Only three manufacturers—twenty-five percent—provided documentation that satisfied examination. And this was before CRA requirements took effect. Market surveillance authorities won't inspect your codebase. They won't interview your developers. They won't observe your security practices. They will examine documentation—and documentation alone. In This Episode: What Market Surveillance Actually ExaminesArticle 31: Authority to require documentation demonstrating conformityArticle 54: Ten-year minimum retention requirementWhy engineering documentation doesn't satisfy regulatory requirementsThe Four CRA Documentation Annexes DecodedAnnex II: User information requirements (manufacturer ID, security risks, update sources, vulnerability reporting contact)Annex V: EU Declaration of Conformity (the legal attestation creating personal liability)Annex VII: Technical documentation (risk assessment, design specification, test results, production process, vulnerability handling)Annex VIII: Conformity assessment procedures (documented internal assessment for Default category)The Five Documentation Gaps That Fail ExaminationRisk assessment without design traceabilityEvidence chains without version controlProduction process without conformity maintenanceVulnerability handling without product-specific recordsSupport periods without formal definition or notification mechanismDocumentation as a System, Not a CollectionDocument identifiers and explicit cross-referencesTraceability matrices linking requirements → risks → design → tests → evidenceIntegration with engineering workflows for automatic evidence generationDistinct documentation ownership separate from engineering ownershipRetention infrastructure designed for ten-year horizonsThe Six Required Documentation TypesProduct Risk Assessment (with treatment decisions referencing design)Design Specification (with requirement traceability matrices)Test Plan and Results (with requirement coverage matrix)Production Process Description (with continuous conformity evidence)Vulnerability Handling Record (with timeline documentation)EU Declaration of Conformity (with authorized signatory)Your Fourteen-Day Action Plan: Days 1-3: Documentation inventory for priority product Days 4-6: Gap analysis against CRA requirements using six document types Days 7-9: Traceability assessment—trace one requirement through full evidence chain Days 10-12: Workflow integration analysis—identify automation opportunities Days 13-14: Documentation roadmap draft with prioritized improvements Deliverables: Documentation inventoryGap analysis against CRA requirementsTraceability assessment identifying where evidence chains breakPrioritized documentation roadmapReady to assess your documentation gaps? The First Witness Stress Test includes comprehensive documentation assessment—revealing where your evidence chains break, where traceability fails, and what examination would expose. The organizations that discover gaps internally can remediate. The organizations that discover gaps during examination cannot. MAKE AN APPOINTMENT WITH ME TO PREPARE YOUR DOCUMENTATION APPROACH https://calendly.com/verbalalchemist/30min CRA documentation requirements, CRA technical documentation, Annex VII documentation, EU Declaration of Conformity, market surveillance examination, compliance evidence, regulatory documentation, CRA audit preparation, ten-year retention, risk assessment traceability, conformity assessment documentation, CRA Annex II user information

    33 min
  6. CRA COUNTDOWN:The Technical Requirements Nobody Understands

    FEB 4

    CRA COUNTDOWN:The Technical Requirements Nobody Understands

    Your engineering team has probably told you they're "mostly compliant" with CRA technical requirements. They're not lying—they just don't know what compliance actually means. The CRA's Annex I contains twenty-one essential cybersecurity requirements. When I assess mid-size organizations against these requirements, typical coverage is eight to eleven. Not because engineering isn't competent. Because the requirements demand capabilities most organizations have never built. In This Episode: The Twenty-One Essential Requirements DecodedThirteen product security requirements: security-by-design, data protection, access control, operational security, and update capabilityEight vulnerability handling requirements: the infrastructure that enables September 2026 complianceWhy "appropriate level of cybersecurity based on risks" means documented risk assessments with traceable design decisions The SBOM Reality CheckYour package manager export captures 2-3 of 7 required data elementsBSI TR-03183-2 mandatory elements: component name, version, supplier identification, unique identifier (Package URL/CPE), cryptographic hash, license information, dependency relationshipsWhy partial SBOM coverage equals non-compliance DevSecOps as Compliance EnablerOrganizations with mature DevSecOps address 12-17 of 21 requirements through existing pipeline integrationThe three persistent gaps: SBOM completeness, documentation formality, vulnerability handling process maturityYou don't need new tools—you need to configure existing tools for CRA evidence generation The Five-Phase Implementation PathPhase 1: Evidence inventory (2-4 weeks)Phase 2: SBOM infrastructure buildout (4-8 months) — THE CRITICAL PATHPhase 3: Documentation formalization (3-6 months, parallel)Phase 4: PSIRT establishment (2-4 months)Phase 5: Conformity assessment preparation Executive Liability and Technical RequirementsConformity declarations signed without verification create personal exposureDiscovery scenarios: incomplete SBOM → missed vulnerability → customer compromise → presumption of defectivenessEngineering builds infrastructure; executives verify it meets requirementsYour Fourteen-Day Action Plan: Days 1-3: Evidence inventory initiation—list all security tools and processes Days 4-7: CRA mapping exercise—requirements matrix against evidence sources Days 8-10: SBOM capability assessment—test seven-element generation on one product Days 11-12: Vulnerability response timeline analysis against 24/72-hour/14-day requirements Days 13-14: Gap prioritization and preliminary roadmap Deliverables: Evidence inventory mapping current capabilities to CRA requirementsSBOM gap assessment identifying missing elementsVulnerability response timeline analysisPrioritized gap list with preliminary roadmapReady to assess your technical CRA gaps? The First Witness Stress Test maps your existing DevSecOps capabilities against all twenty-one Annex I requirements—identifying where you have evidence, where you have gaps, and what closing those gaps actually requires. Stop guessing at coverage. Start measuring it. CRA Annex I requirements, SBOM compliance, Software Bill of Materials, BSI TR-03183-2, DevSecOps CRA compliance, vulnerability handling requirements, PSIRT product security, CRA conformity assessment, security by design, twenty-one essential requirements, CRA evidence generation, cryptographic hash SBOM

    30 min
  7. CRA COUNTDOWN: What Exactly Is In Scope? (And Why You Probably Don't Know)

    FEB 3

    CRA COUNTDOWN: What Exactly Is In Scope? (And Why You Probably Don't Know)

    A medical technology company's compliance team was confident they had three products requiring CRA attention. After completing the inventory exercise, we identified twenty-three. Twenty had no documented compliance owner. Twelve had never undergone security assessment. Four required third-party conformity assessment from notified bodies already signaling capacity constraints. Their eighteen-month timeline became a resource crisis in a single meeting. Most organizations underestimate CRA product scope by sixty to seventy percent on initial assessment. In This Episode: What "Products with Digital Elements" Actually MeansSoftware products: applications, SaaS platforms, mobile apps, SDKsHardware with embedded software or firmwareRemote data processing solutions—the cloud backends your products depend on are part of the product The Three Gap Patterns That Destroy Compliance TimelinesLegacy product gap: systems in "maintenance mode" still generating revenue still have CRA obligationsComponent product gap: APIs, SDKs, and libraries distributed through package managers require independent classificationCloud infrastructure gap: you cannot outsource compliance responsibility to your cloud provider Why Exemptions Are Narrower Than You ThinkMDR-certified medical devices may be exempt—but patient data platforms receiving their data are notNon-commercial open-source exemption doesn't cover commercial products using open-source dependenciesExemption assumptions require documented regulatory basis, not organizational convenience The Four-Tier Classification SystemDefault category (~90% of products): internal self-assessment with proper documentationImportant Class I: identity management, VPNs, SIEM systems—harmonized standards or third-party assessmentImportant Class II: operating systems, firewalls, HSMs—mandatory notified body involvementCritical: hardware security boxes, smart meter gateways—highest scrutiny with cybersecurity certification Why Classification Determines EverythingConformity assessment pathway drives timeline and budgetNotified body capacity is finite—organizations engaging early secure assessment slotsEU 2025/2392 Implementing Regulation clarifies component vs. integrated product classificationYour Fourteen-Day Action Plan: Days 1-3: Revenue-based product identification with Finance Days 4-6: Technical architecture expansion with Engineering Days 7-9: Customer relationship validation with Customer Success Days 10-12: Exemption analysis with documented regulatory basis Days 13-14: Preliminary classification against Annex III and IV criteria Deliverables: Comprehensive product inventoryExemption register with documented rationalePreliminary classification matrixReady to discover your actual CRA scope? The First Witness Stress Test includes comprehensive scope determination and classification analysis—revealing the products hiding in plain sight and the conformity assessment pathway each requires. Stop assuming. Start inventorying.

    27 min
  8. CRA COUNTDOWN: The Deadline They're Not Telling You About

    FEB 2

    CRA COUNTDOWN: The Deadline They're Not Telling You About

    While your competitors build compliance roadmaps around December 2027, a hidden deadline eighteen months earlier will determine who maintains European market access—and who loses it. September 11, 2026 activates mandatory twenty-four-hour vulnerability reporting to ENISA. Most mid-size organizations cannot meet that timeline because they lack the Software Bill of Materials infrastructure required to identify affected products. That infrastructure takes twelve to eighteen months to build. Do the math. In This Episode: The September 2026 Compliance CliffWhy vulnerability reporting obligations activate sixteen months before full CRA complianceTwenty-four-hour ENISA notification requirements for actively exploited vulnerabilitiesThe Log4Shell lesson: organizations with SBOM infrastructure responded in hours; those without took monthsThe Four Gaps Destroying Compliance TimelinesProduct inventory failures: most organizations cannot answer "how many products with digital elements do you sell in EU markets"Classification confusion across Default, Important Class I, Important Class II, and Critical tiersSBOM systems capturing two of seven required data elementsDocumentation infrastructure that cannot survive regulatory examinationPersonal Liability ExposureEU Product Liability Directive 2024/2853: presumption of defectiveness for non-CRA-compliant productsDiscovery scenarios: every security investment decision becomes evidence in litigationHealthcare MDR intersection: connected ecosystems surrounding exempt medical devices may still be in scopeFinance DORA overlap: dual compliance requirements most organizations haven't integratedThe Six-Element Governance FrameworkProduct inventory and classification processesDocumented ownership from design through end-of-lifeAutomated SBOM generation as a build gateCRA-compliant documentation systemsTwenty-four-hour vulnerability management workflowCross-departmental steering committee with executive sponsorshipYour Fourteen-Day Action Plan: Days 1-3: Conduct complete product inventory across all EU market offerings Days 4-7: Preliminary classification against four-tier CRA framework Days 8-10: Map current ownership and identify accountability gaps Days 11-14: Assess SBOM generation capability against seven required data elements The Stakes: €15 million or 2.5% of global annual turnover for non-compliance. No CE marking means no European market. The organizations that dominate EU markets in 2028 are the ones that started preparing in 2025. Ready to assess your CRA exposure? The First Witness Stress Test delivers a comprehensive gap analysis of your current readiness against September 2026 vulnerability reporting requirements and December 2027 full compliance obligations. Stop guessing. Start preparing.   SCHEDULE AN APPOTINMENT: https://calendly.com/verbalalchemist/discovery-call EU Cyber Resilience Act, CRA compliance, September 2026 deadline, SBOM Software Bill of Materials, CE marking requirements, vulnerability reporting, ENISA notification, product liability directive, digital product compliance, European market access, cybersecurity regulation, mid-size company compliance

    24 min
See All (27)

About

Daily analysis of AI liability, regulatory enforcement, and governance strategy for the C-Suite. Hosted by Shelton Hill, AI Governance & Litigation Preparedness Consultant. We bridge the gap between technical models and legal defense.

Information

  • Creator
    Keith Hill
  • Years Active
    2K
  • Episodes
    27
  • Rating
    Clean
  • Copyright
    © 2026 Keith Hill