8,900 萬美元的 Bug:Apple 與 Goldman Sachs 在金融 AI 上錯在哪裡

去年十月的一個週二晚上,我正坐在家中的辦公空間裡,CFPB 的新聞稿跳進了我的訊息流。Apple 與 Goldman Sachs,因處理 Apple Card 爭議的系統性失誤,被裁定支付超過 8,900 萬美元。我把那份同意令讀了兩遍。然後又讀了第三遍,因為我實在不敢相信自己看到的東西。

核心的失誤並不是什麼高深的金融工程出了差錯。也不是某個失控的演算法做出歧視性的放貸決策。問題出在一個按鈕。Apple Wallet app 裡的一份次要表單,只要消費者沒有填完,他們的帳單爭議就會消失在數位的虛空之中。數以萬計的人回報了未經授權的扣款,而系統就這樣……把它們吞了。沒有調查。沒有受理通知。沒有解決。帳單最後還是落在消費者頭上。

我以打造 AI 系統為業。我的公司 Veriprajna 專注於我們所謂的深度 AI——結合大型語言模型的彈性與形式化驗證數學嚴謹性的神經符號(neuro-symbolic)架構。讀到那份同意令時,我並沒有感到自己被印證了。我覺得反胃。因為 Apple Card 上出的每一個錯,都是可以預防的。不是靠更好的測試。也不是靠更多工程師。而是靠一種根本不同的思維方式——去思考受監管產業的 AI 系統究竟該怎麼建。

你的 Apple Card 爭議究竟發生了什麼事?

讓我帶你走一遍這場失誤,因為細節比那個上了頭條的數字更重要。

Apple 與 Goldman Sachs 在 2017 年簽下合作協議。Apple 負責整個消費者體驗——那個俐落的 Wallet 介面、訊息系統,整個前端。Goldman Sachs 則是幕後的銀行,負責核發信用、處理交易,並在出問題時調查爭議。

2020 年 6 月,Apple 對「Report an Issue」(回報問題)流程推送了一次更新。更新之前,你只要點一下可疑的交易、按下「Report an Issue」,就會被導向與 Goldman Sachs 之間、以 Messages 為基礎的對話。很直接。更新之後,Apple 加上了一份次要表單——消費者在送出第一則訊息之後,還必須完成的額外步驟。

問題就出在這裡:當人們透過 Messages 送出爭議、卻沒有把次要表單填完時,系統就把這筆爭議視為未完成。它從來沒有把這項申訴傳給 Goldman Sachs。但從法規的角度來看,這些訊息中有許多都構成《誠實借貸法》(Truth in Lending Act)之下有效的帳單錯誤通知(Billing Error Notice)。依法,它們應該在特定期限內觸發調查。結果,它們卻消失了。

數以萬計在法律上有效的消費者爭議,被一台從來沒有人做過形式化驗證的狀態機吞掉了。

我記得讀到那個細節時,我想起了每一場和金融服務高階主管的對話——他們總告訴我,他們的系統「久經沙場」。久經什麼樣的沙場?經得起「一次 UI 變更在分散式流程中引入一個死狀態」這種特定情境嗎?那不是靠單元測試和 QA sprint 就抓得到的東西。

那條毀掉一切的 2,500 萬美元條款

同意令裡埋著一個細節,我一直反覆想起。Apple 與 Goldman Sachs 的合約中有一項條款:Goldman 每讓 Apple Card 的上線延遲 90 天,就要支付 2,500 萬美元的違約金。

兩千五百萬美元。每一季。只因為晚了。

我待過那種商業壓力扭曲工程決策的會議室。我看過團隊明知還沒準備好就把東西推出去,因為延遲的代價感覺比失敗的代價更具體。但我從沒見過誘因結構被寫得這麼白。Goldman Sachs 等於是為了「謹慎」而被預先開罰。

Apple Card 在 2019 年 8 月 20 日上線。Goldman 內部團隊曾對系統的就緒程度提出疑慮。Wallet app 與 Goldman 後端之間的訊息佇列測試不足。同步協定很脆弱。但這道數學題很簡單:現在就上線、之後再修,或者付 2,500 萬美元、先修好再說。

他們上線了。接下來一年多,這套系統帶著一個從外部完全看不見的破洞在運轉。

當人們問我為什麼 Veriprajna 堅持在部署前做形式化驗證時,我就會想到這件事。「那樣不是很慢嗎?」他們問。「難道不能上線後再監控、抓到問題再說?」當然可以。你也可以不裝煞車就開車,打算靠方向盤閃過障礙物。這行得通——直到它行不通。而當它在金融服務業行不通時,受傷的是活生生的人。

為什麼沒有人發現?

這正是縈繞在我心頭的問題。地球上兩家技術最頂尖的公司——擁有傳奇工程文化的 Apple,以及擁有量化火力的 Goldman Sachs——竟然沒有一家注意到,成千上萬筆爭議正掉進一個黑洞?

我認為答案在架構上。這套系統被設計成一場接力:Apple 顧前端,Goldman 顧後端,訊息在兩者之間流動。但沒有人負責那塊介於兩個系統之間的空間。沒有人為以下情況建立形式化模型:一筆爭議進入了狀態 A(「訊息已送出」),卻從未抵達狀態 B(「表單已完成」),這時該發生什麼事?在一台設計良好的狀態機裡,那是你會明確處理的轉移。在 Apple Card 的系統裡,那是一個沒有人規範、因此也沒有人監控的缺口。

大約一年前的某個深夜——我和團隊正在為一位客戶打造合規流程,我們的工程師 Priya 提出了類似的發現。她當時在為一套文件審查流程建立狀態轉移模型,結果找到一條路徑:只要第三方 API 逾時,送件就可能無限期卡在「待補資料」的狀態。那不是程式碼的錯誤。程式碼完全照著它被交代的去做。那個錯誤出在設計上——一個規格從未考慮到的狀態。

我們之所以抓得到,是因為我們使用形式化驗證工具——具體來說,我們把工作流程建模成狀態機,再交給 SMT 求解器窮盡地檢查每一條可能的路徑。求解器幾秒鐘就找出了 Priya 的那個死狀態。而在 Apple Card 的系統裡,那個死狀態在正式環境跑了好幾個月。

Apple Card 的失誤不是程式碼的錯誤。程式碼完全照著它被交代的去做。錯誤出在設計上——一個沒有人規範、因此也沒有人監控的狀態。

為什麼不乾脆用 GPT 來做就好?

我經常被問到這個問題。有位投資人在一次募資會議上,幾乎是一字不差地這樣問我:「為什麼你們不乾脆拿 TILA 法規去微調 GPT-4,讓它來處理爭議?」

我深吸一口氣。然後我反問他:「如果 GPT-4 告訴消費者他的爭議已經解決了,但實際上那筆爭議根本沒被傳給銀行,責任該由誰承擔?」

他答不上來。其他人也答不上來,因為這個問題正好戳中我所謂「超大提示詞」(mega-prompt)式 AI 在受監管產業中的根本問題。你拿一個大型語言模型,把相關法規全塞進它的脈絡視窗,然後期望它每件事都處理得對。沒有治理層。沒有形式化驗證。沒有任何數學上的保證,能確保系統的輸出與法律一致。

在 Apple Card 這個案例裡,失誤是一個分散式狀態機中的邏輯錯誤。套一層 LLM 外殼不會修好它——反而可能讓事情更糟。想像一個 LLM 信心滿滿地告訴消費者「您的爭議已提交,正在調查中」,而現實是,這筆爭議根本沒離開過 Apple 的伺服器。那不是假設。那就是幻覺在金融情境中的樣子,而它令人不寒而慄。

那些熱門的財經科普網站,以及廣為流傳、談論 AI 進入銀行業的內容,幾乎無一例外地漏掉了這個區別。他們談 AI 如何「自動化」合規,彷彿困難的部分是讀懂法規。困難的部分不是讀懂它們。困難的部分是證明你的系統在每一種可能的情境下都遵循這些法規,包括那些你還沒想到的情境。

若想更深入了解 Apple 與 Goldman 這場失誤如何對應到具體的法規違失與架構缺口,我寫了一份互動式分析,逐段剖析這份同意令。

「可證明正確」到底是什麼意思

當我說 Veriprajna 打造「可證明正確」的合規系統時,我指的不是「測試做得很徹底」。我指的是在數學上被證明過。這兩者有差別,而且這個差別至關重要。

測試檢查的是特定情境。你寫一個測試說:「如果使用者提交爭議並完成表單,就驗證它有送達 Goldman Sachs。」這個測試通過了。很好。但你並沒有測試這種情境:使用者提交了爭議,卻沒有把表單填完。或者他們填完了,但網路把封包丟了。又或者兩筆爭議同時抵達,其中一筆覆蓋掉另一筆。

形式化驗證檢查的不是情境。它檢查的是性質。你定義一個性質——「每一筆提交的爭議最終都必須進入調查狀態」——然後由數學求解器窮盡地證明:這個性質在系統的每一種可能執行中都成立。每一條路徑。每一個邊界情況。每一種競爭條件。只要存在哪怕一個反例,求解器都會找出它,並精確告訴你系統可能如何失效。

我們使用像 Imandra 這樣的工具,它讓我們得以打造出本質上是合規邏輯數位孿生的東西。這個孿生體與正式系統並行運作,一旦正式環境的程式碼嘗試執行任何偏離已驗證模型的動作——例如因為 UI 步驟未完成就丟棄一筆爭議——系統就會即時攔截。

這正是那種能在任何一位消費者受到影響之前,就抓出 Apple Card 這個錯誤的做法。在設計階段,SMT 求解器就會立刻指出:「CompletedFormB」這個變數在 TILA 之下並不是必填欄位。傳輸邏輯要求它,但法律並不要求。這種不一致是一個可被證明的缺陷,而它會在部署之前就被標記出來。

我們真正打造的架構

我想具體說明「深度 AI」合規系統在實務上長什麼樣子,因為關於「AI 驅動合規」的空泛宣稱,本身就是問題的一部分。

Veriprajna 採用多代理架構。與其讓單一的巨型 AI 包辦一切,我們部署的是角色與邊界都明確定義的專職代理。與其說像是聘了一位天才,不如說像是組建一支團隊:每個人都有專屬的工作,而且有主管在檢查他們的成果。

受理代理(Intake Agent)負責處理雜亂、屬於人的那一部分——解析自然語言寫成的爭議。當有人寫下「我從來沒在西雅圖買過這杯咖啡;那天我人在倫敦」時,這個代理會萃取出關鍵實體:交易、商家、日期,以及主張的性質。這正是 LLM 真正發光的地方。

但接下來——這也是我們與我所見過的每一種「外殼式」做法分道揚鑣之處——萃取出的資訊會交給一個符號式政策引擎(Policy Engine),它不預測、也不猜測。它會依據聯邦法律的一階邏輯編碼來評估這筆爭議。這則訊息所含的資訊,是否足以構成 TILA 之下有效的帳單錯誤通知?這個引擎不做估計。它做證明。

工作流程代理(Workflow Agent)強制執行操作的先後順序。驗證代理(Verification Agent)執行即時的數學檢查。稽核代理(Audit Agent)把每一次互動都記錄在我們所謂的「玻璃箱」裡——對監理機關完全透明。

而最關鍵的,哨兵代理(Sentinel Agent)專門監控那種扼殺了 Apple Card 系統的死狀態。如果一筆爭議停留在「已提交但未傳送」的狀態超過預先定義的門檻,哨兵不會等著某個人去發現。它會自主判斷現有資訊是否足以往下推進,將其打包,並透過已驗證的通道傳送出去。

在一套為絕對合規而建的系統裡,決定一筆爭議是否有效的是法律——不是 UI。如果消費者已經告訴你有一筆未經授權的扣款,那麼表單沒填完是你的問題,不是他們的問題。

為什麼時效是法律要求,而不是效能指標

這件事還有另一個面向,是大多數技術討論完全忽略的。在金融合規裡,時間就是法律。Regulation Z 不只要求你必須調查爭議。它要求你必須在特定期間內發出受理通知,並在 60 天內解決爭議。Goldman Sachs 之所以被罰,部分原因就是他們沒有在這些期限內寄出受理通知。

我的團隊花了好幾個月,發展出我們稱為「符號式延遲」(Symbolic Latency)的分析方法——一種在數學上證明分散式系統在最壞情況下仍能於法規期限內完成工作的方法。不是平均情況。不是「第 95 百分位」。是最壞情況。

傳統監控告訴你的,是你的系統是不是曾經很慢。符號式延遲告訴你的,是你的系統是不是可能會很慢。如果 UI 程式碼的一項變更,使最壞情況下的處理時間超出 60 天的法規期限,這次部署就會被自動駁回。你不是事後才知道。你是在上線之前就知道。

我還記得我們內部為了「這種嚴謹程度到底有沒有必要」而起的爭論。我的一位工程師——一個在某大型雲端服務商待過多年的聰明傢伙——強烈反對。「你為了一個可能永遠不會發生的情境,替部署週期硬加了好幾週,」他說。我指著 Apple Card 的同意令。「它發生了,」我說。「發生在 Apple 身上。發生在 Goldman Sachs 身上。發生在數以萬計什麼錯都沒犯的消費者身上。」

在那之後,他就沒再爭了。

若想看我們形式化驗證做法的完整技術剖析,包括用於延遲上界的 Performal 方法論,請參閱我們的研究論文。

「可是這要蓋太久了」

大家總在這一點上反駁我,而我理解為什麼。Apple Card 幾個月就上線了。而一套經過形式化驗證的合規架構,在充滿老舊系統的環境中要達到完整最佳化,需要 18 到 36 個月。在一個競爭對手每週出貨的世界裡,那感覺像是一個世紀。

但讓我重新算一遍這道數學題。Apple 與 Goldman Sachs 花了好幾年打造並推出 Apple Card。然後又花了好幾年收拾後果——內部調查、監理檢查、法律費用、聲譽損害,最後還有 8,980 萬美元的罰款與消費者賠付。那個「快」的做法一點也不快。它只是把速度堆在前面,把災難堆在後面。

我們的分階段部署做法承認現實。你沒辦法把一家銀行的核心系統直接拔掉。從 1980 年代就一直在跑的 COBOL 主機不會一夜之間消失。所以我們分層整合:稽核既有架構、打造一個智慧型 API 閘道、讓 AI 系統以影子模式運行以驗證舊系統的輸出,再隨著形式化證明逐步累積,慢慢把決策權移轉過來。

第一階段——評估與形式化建模——需要 14 到 20 週。到這個階段結束時,你就擁有一個合規邏輯的數學模型,能夠抓出那種折磨 Apple Card 的死狀態錯誤。那不是 36 個月。那是不到五個月,就能得到一套從根本上更安全的系統。

改變我對這件事看法的那一刻

有一個特定的時刻,我一再回想。那大約是八個月前,我們正在為一家金融服務客戶做概念驗證。我們把他們的爭議處理流程建模成一台分散式狀態機,並執行整套形式化驗證。

求解器找到了十一個死狀態。

系統中有十一條路徑,會讓消費者的申訴卡住,既得不到解決,也不會觸發任何警示。這家客戶的工程團隊已經跑這套系統跑了三年。他們處理過數百萬筆交易。他們有監控儀表板、有告警系統、有季度稽核。而這一切,沒有一項抓到過這十一個破洞。

當我把結果攤在他們面前時,整個會議室安靜了下來。他們的合規長——一位在銀行監理領域待了二十年的女士——看著螢幕說:「有多少消費者掉進那些狀態裡?」

我們不知道。他們也不知道。這正是分散式系統中死狀態的可怕之處:如果沒有人在盯著它們,它們就是隱形的。受影響的消費者也許打過客服電話,被踢來踢去,最後放棄了。也可能他們到現在還在為自己從沒刷過的帳款付錢。

這就是 Apple Card 的失誤從內部看起來的樣子。不是一場戲劇性的爆炸。而是一種緩慢、無聲累積的傷害,沒有人看得見——直到監理機關硬把那個黑箱撬開。

未來五年會是什麼樣子

CFPB 對 Apple 與 Goldman Sachs 的處分不是孤立事件。它是一場監理清算的開端——清算科技公司如何處理金融基礎設施。隨著銀行業務愈來愈深地嵌入其中——嵌進手機、嵌進 app、嵌進那些原本並非為金融服務而設計的平台——「大多數時候能運作」與「可證明始終能運作」之間的落差,就變成以數億美元計的責任。

我想到我最常聽到的那個質疑:「對大多數金融系統來說,形式化驗證不是殺雞用牛刀嗎?」而隨著時間過去,我的答案愈來愈簡單。Apple Card 是全世界最受矚目的消費金融產品之一,由兩家工程資源近乎無限的公司打造。如果連他們都無法透過傳統的測試與監控,抓出爭議處理流程裡的一個死狀態,你憑什麼認為你的系統會不一樣?

這個產業正在走向我所謂的「絕對合規」(Absolute Compliance)——合規不再是打勾的例行公事,而是一種架構性質。在這樣的系統裡,對法律的遵循不是事後才去驗證的東西,而是部署之前就先證明的東西。在這樣的系統裡,UI 與法規之間的落差,不是靠人的警覺來彌合,而是靠數學上的確定性。

「先上線、之後再修」的時代,與全球金融「搬動金錢、保護人們」的要求彼此不相容。Apple Card 已經證明了這一點。問題只在於:這個產業是在下一筆 8,900 萬美元罰款之前學到教訓,還是之後。

我們正在 Veriprajna 打造那個未來。不是因為它容易——分散式金融系統的形式化驗證是真的很難,任何告訴你不難的人都是在推銷東西。而是因為,另一條路的下場,就是我們在 2024 年 10 月看到的:全世界最有實力的兩家公司、一個壞掉的按鈕,以及數以萬計的人,被迫替自己從沒刷過的帳款買單。

那不是技術問題。那是工程倫理問題。而解方不是更好的監控,也不是更快的修補。而是打造在建構上就正確的系統——那種由數學保證、任何消費者的爭議都絕不會消失在虛空之中的系統。

那 8,900 萬美元的罰款已經付了。真正的代價,是被打破的信任。要重建它,光靠承諾不夠。它需要證明。