在算法合規(guī)實踐中，不少企業(yè)會遇到一個實際問題：同一套算法既用在 APP 上，又部署在網(wǎng)頁端，這種情況能合并備案嗎？結(jié)合現(xiàn)行法規(guī)要求和實操經(jīng)驗，答案是 “可以，但有前提”。關鍵在于把握 “技術同源” 與 “平臺差異” 的平衡，既滿足監(jiān)管要求，又提高備案效率。
現(xiàn)行法規(guī)對算法備案的界定，是以 “服務類型” 為核心，而非看載體是 APP 還是網(wǎng)頁。因此，跨平臺算法要合并備案，需滿足三個核心條件：
主體必須統(tǒng)一
備案主體得是算法的實際運營方，且 APP 與網(wǎng)頁的運營主體要完全一致。比如某電商平臺的商品推薦算法，無論在其官方 APP 還是 PC 網(wǎng)頁上運行，只要都是該電商公司直接運營，用戶協(xié)議、隱私政策的主體也統(tǒng)一，就符合主體要求。如果存在子公司代運營等情況，需額外提供關聯(lián)關系證明和責任劃分承諾書，明確主備案方的責任。
算法得是 “同一套”
APP 和網(wǎng)頁端用的算法必須同源 —— 模型結(jié)構(gòu)、核心邏輯、訓練數(shù)據(jù)得完全一致。實操中，這需要通過技術文檔來證明：比如提供算法流程圖，標注清楚跨平臺調(diào)用的核心鏈路；附上代碼版本控制記錄（如 Git 提交日志），證明兩端部署的是同一套代碼；甚至可以提供性能測試報告，說明不同終端的算法輸出結(jié)果一致性。
平臺差異要講清楚
即便算法同源，APP 和網(wǎng)頁的服務形式、功能細節(jié)難免有差異。備案時必須如實說明：比如 APP 端支持離線緩存推薦結(jié)果，網(wǎng)頁端依賴實時加載；或者 APP 側(cè)重短視頻推薦，網(wǎng)頁端更側(cè)重長文內(nèi)容。這些差異不影響合并備案，但需要在材料中列明各平臺的訪問地址（如 APP 的應用商店鏈接、網(wǎng)頁域名）、用戶規(guī)模，以及算法在不同終端的適配方案（如響應式設計如何保證推薦邏輯穩(wěn)定）。
對企業(yè)來說，合并備案最大的價值是 “降本提效”，但操作上需要做好材料整合。
效率提升體現(xiàn)在哪里？
最直接的是材料復用。算法原理說明、安全自評估報告等核心文件只需做一份，不用為 APP 和網(wǎng)頁重復編寫。比如某資訊平臺的內(nèi)容推薦算法，其 “用戶畫像構(gòu)建邏輯”“內(nèi)容匹配規(guī)則” 等核心說明，對 APP 和網(wǎng)頁端是通用的，只需在材料中補充兩端的差異化細節(jié)（如 APP 如何利用設備傳感器數(shù)據(jù)優(yōu)化推薦，網(wǎng)頁如何通過 Cookie 記錄偏好）。
從審核周期看，合并備案能減少重復審核，通常比分開備案縮短 30% 左右時間。常規(guī)備案流程約 2-4 個月，合并備案大多能控制在 3 個月內(nèi)。
具體怎么操作？
第一步是整合技術文檔。在算法說明里加一章 “跨平臺部署方案”，講清楚兩端如何共享核心模型（比如通過云端 API 同步數(shù)據(jù)）、前端如何適配（如 APP 用原生 SDK，網(wǎng)頁用 JavaScript 接口）。
第二步是規(guī)范填報信息。在備案系統(tǒng)的 “服務形式” 里，同時勾選 “移動應用程序” 和 “網(wǎng)站平臺”，分別填寫 APP 的應用商店鏈接（如蘋果 App Store、華為應用市場）和網(wǎng)頁的 ICP 備案號、域名。
第三步是補充風險防控細節(jié)。不同平臺的安全風險點不同：APP 端要說明本地數(shù)據(jù)存儲的加密方案（如 SQLite 加密）；網(wǎng)頁端要講清楚 XSS 攻擊防護（如內(nèi)容安全策略配置），這些都得在自評估報告里單獨列明。
實際操作中，算法部署可能更復雜，這些場景需特別注意：
混合架構(gòu)怎么備案？
如果算法采用 “云端核心模型 + 終端輕量化運行”（比如 APP 和網(wǎng)頁都調(diào)用同一云端 API，但本地有簡單推理），備案時要提供云端 API 的接口文檔（含參數(shù)、響應格式），以及終端 SDK 的技術說明，證明核心邏輯仍由云端統(tǒng)一控制，終端只是適配層。
用到第三方技術怎么辦？
若跨平臺算法調(diào)用了第三方能力（如接入大模型 API），除了主算法的備案材料，還得附上第三方的算法備案編號和合作協(xié)議，明確雙方在算法合規(guī)中的責任劃分。比如某教育平臺的智能答疑算法，既用了自研的推薦邏輯，又接入了第三方大模型，備案時需同時提交自研部分的技術文檔和第三方的備案證明。
多語言版本要額外說明嗎？
如果網(wǎng)頁或 APP 有中英文等多語言版本，需在 “服務對象” 中注明覆蓋范圍，并提供語言模型訓練數(shù)據(jù)的來源證明（如公開數(shù)據(jù)集的授權(quán)協(xié)議），避免被認定為 “不同算法”。
合并備案的材料要兼顧 “通用性” 和 “差異性”：
核心材料不能少
營業(yè)執(zhí)照、算法負責人的身份證明和工作證明（需體現(xiàn)管理職責）、算法自評估報告（含公平性測試、數(shù)據(jù)安全措施）、跨平臺架構(gòu)圖（標注各終端的調(diào)用鏈路），這些是基礎。
平臺差異材料要補充
APP 端需提供應用商店上架截圖、隱私政策鏈接；網(wǎng)頁端要附 ICP 備案證明、SSL 證書；如果有小程序，還得加微信 / 支付寶的接入?yún)f(xié)議。
后續(xù)管理要跟上
算法更新后，若只是參數(shù)微調(diào)，可在年度報告中記錄；若模型結(jié)構(gòu)變了，得重新備案。另外，備案編號要在 APP 的 “關于我們” 和網(wǎng)頁底部顯著位置公示，且鏈接要能跳轉(zhuǎn)至國家網(wǎng)信辦的公示頁面，比如某視頻平臺就在兩端的設置頁專門做了備案信息專區(qū)。
金融、醫(yī)療等領域的企業(yè)要更謹慎：
金融行業(yè)需額外滿足銀保監(jiān)會的算法風控要求，比如信貸推薦算法要附風險模型的驗證報告；醫(yī)療領域的 AI 輔助診斷算法，得提供衛(wèi)健委的倫理審查證明，這些都得在跨平臺備案中一并提交。
某頭部內(nèi)容平臺的跨平臺推薦算法是這么做的：
技術上，用 “云端 Transformer 模型 + 終端嵌入式推理”，APP 和網(wǎng)頁通過統(tǒng)一 API 調(diào)用核心模型；
材料上，除了常規(guī)文檔，還加了性能測試報告（對比 APP 的 GPU 推理和網(wǎng)頁的 WebGL 推理延遲），以及兩端的隱私保護方案（APP 用差分隱私，網(wǎng)頁用 Cookie 加密）；
最終順利通過合并備案，備案編號在公示信息中明確標注 “服務形式：移動應用、網(wǎng)站”。
關注微信訂閱號
