呢個現象而家有咗個名:「苦工轉移」(toil shift)。AI唔係消滅咗工作,而係將啲工作由「創造階段」搬咗去「驗證、測試同修補階段」 。Black Duck嘅說法好直接:「大多數機構生產AI代碼嘅速度快過佢哋審查、保安同管治嘅速度」
。
如果報告入面有個結論,係工程主管一定要行動嘅,就係呢個:管治就係嗰個「ROI倍增器」 。有管治同冇管治嘅團隊之間嘅分別,唔係些微差距——而係直接決定咗你係「攞到效率紅利」定係「眼白白睇住佢喺罅隙度漏走晒」。
呢度講嘅「管治」唔係官僚主義。而係指有明確定義嘅政策,包括:可以用邊啲工具、AI生成代碼要點樣審查、必須通過咩保安關卡、同埋邊個最終對產出負責。就係「開發者鍾意用咩就用咩」同「開發者喺一個有結構、可審計嘅流程管道入面,用經審批嘅工具」之間嘅分別。
令管治更加複雜嘅,係「影子AI」嘅興起——即係開發者違反公司政策,或者喺公司政策範圍外擅自使用AI工具。Black Duck發現,18%嘅機構報稱影子AI係一項重大、未受管理嘅風險 。當開發者以個人層面採用好似Cursor、Windsurf或者Claude Code呢類工具,而冇經採購部門或者保安審查,機構就會對自己嘅攻擊面(attack surface)失去視野
。
管治漏洞喺供應鏈方面,就變成咗實實在在嘅漏洞。Black Duck嘅研究——包括佢哋相關嘅《2026年OSSRA報告》——揭示咗三個同AI編碼助手特別相關、互相關聯嘅風險:
「授權洗底」(License laundering)。 用開源Repository訓練出嚟嘅AI助手,可能會生成嚟自「Copyleft」來源嘅程式碼片段,但又冇保留返原本嘅授權資訊 。2026年OSSRA報告發現,三分之二被審計嘅程式庫都存在授權衝突——係報告有史以來最高嘅比率
。機構可能喺唔知情嘅情況下,推出咗一啲佢哋根本無權使用嘅Code。
依賴爆炸(Dependency explosion)。 每個程式庫入面嘅開源组件數量,按年增加咗30%,而每個程式庫嘅平均漏洞數量更加激增107% 。AI編碼助手加速咗呢個趨勢,因為佢哋組合解決方案嘅速度更快,而且訓練語料庫更廣泛——意味住每個AI生成嘅功能,都可能拉入一啲開發者根本冇明確揀過嘅依賴套件。
Black Duck嘅發現唔係個別例子。差唔多同一時期公佈嘅多個獨立調查,用更細緻嘅數據深化咗呢個信任危機:
呢啲調查得出嘅共識異常一致:開發者冇咗AI工具唔得,但又冇辦法完全信得過佢哋。生成同驗證之間嘅鴻溝,已經成為咗新嘅瓶頸。
Black Duck開出嘅藥方唔係空泛理論。報告指向一系列具體措施,正係呢啲措施區分咗嗰30%有全面管治嘅機構同其他機構:
Black Duck份報告並唔係反對用AI編碼助手。佢係想指出,用咗AI但又冇相應管治,係會自毀長城。當97%團隊以前所未有嘅速度生成緊程式碼,但得30%有基建去管理佢嘅時候,成個行業基本上係喺度「開空頭支票」。
管治同效率提升之間嘅關聯——90%對比44%——令到商業案例變得好清晰。先起好防護欄嘅機構,先至真正攞到AI承諾嘅生產力。冇咁做嗰啲,就會不停重複發現:喺鍵盤度慳返嘅時間,最後都係要喺審查隊列度還返晒出嚟。
Comments
0 comments