背景
這份筆記整理自警政「M化整合查詢 APP」與其所屬的 M-Police 警用行動載具介紹課程。核心主軸是：M-Police 把原本分散在不同系統、需要回到內勤電腦查詢的警政資料，整合到第一線員警的行動載具上，讓員警在盤查、臨檢、交通稽查、反詐騙受理與查緝逃犯時，能即時查人、查車、查帳戶、查場所並取得風險警示。課程後半段進一步延伸到車輛風險辨識（疑似權利車、AB車、偽造車牌）、場所／車輛盤查的犯罪關聯分析，以及人臉辨識功能因個資疑慮而下架的教訓，並反覆強調「因公查詢」與查詢留痕是這套系統能否合法運作的關鍵。
知識架構圖
警政科技行動化
├─ 一、載具層：M-Police 警用行動載具
│ ├─ 類似公務用行動小電腦，非私人手機
│ └─ 由警政機關配發、控管、稽核
│
├─ 二、APP 層：警政內部 APP 生態系
│ ├─ NPA Store：警政內部下載平台（一般手機無法下載）
│ ├─ M化整合查詢：查人、查車、查帳戶、查警示
│ ├─ 電子舉發：交通違規電子開單（搭配藍牙攜帶型印表機）
│ ├─ 車牌辨識（車辨）：自動掃描車牌並比對後端警示
│ └─ 電子巡簽：QR Code／NFC 巡邏簽到
│
├─ 三、資料層：後端多系統整合
│ ├─ 人口、戶籍、身分照片、駕籍
│ ├─ 車籍、失竊車、協尋車
│ ├─ 通緝、逃犯、失蹤人口
│ ├─ 刑案資料、毒品高風險人口、治安顧慮人口
│ ├─ 婦幼通報、兒少協尋、性侵害加害人、保護令
│ ├─ 165 警示帳戶
│ └─ 疑似權利車、AB車、疑似偽造車牌、持械紀錄
│
├─ 四、勤務應用層
│ ├─ 查人／查車／查帳戶／查場所
│ ├─ 場所盤查（設定地點、包廂）
│ ├─ 車輛盤查（設定車號、登錄駕駛與乘客）
│ ├─ 跑馬燈重大警示（查捕逃犯、脫逃人犯等）
│ └─ 線上查詢／離線查詢（後端連線 vs 載具暫存資料）
│
└─ 五、法制與管理層
├─ 因公查詢原則（不得查自己、親友、無關民眾）
├─ 查詢紀錄留存與稽核（需能提出勤務或案件佐證）
├─ 警察職權行使法身分查證程序（第 6、7 條）
├─ 個資保護（人臉辨識功能已因爭議下架）
└─ 權限控管與使用目的限制串聯邏輯：為什麼會這樣設計？
第一線員警在盤查、臨檢、交通稽查、反詐受理與查緝逃犯時，需要即時掌握人、車、帳戶、場所的風險資訊 → 過去這些資料分散在不同系統，需回到內勤電腦逐一查詢，效率低且容易延誤現場判斷 → 因此警政署建置 M-Police 行動載具與 NPA Store 內部 APP 平台，把常用查詢整合到行動端 → M化整合查詢一次輸入身分證字號／車號／帳號，即可比對多個後端資料庫（人口、車籍、通緝、毒品、165 警示帳戶等） → 車牌辨識、電子舉發、電子巡簽則進一步把「大量重複性的現場作業」自動化、電子化 → 場所盤查與車輛盤查把「同一時間同一場所出現的人」記錄下來，形成日後犯罪關聯分析的基礎資料 → 但查詢能力越強、可觸及的個資越敏感，就越需要「因公查詢」「查詢留痕」「警職法程序」等法制與管理機制來約束 → 最終在效率與合法性之間，形成一套受控、可稽核的行動警政查詢生態系。
重點摘要（可放入實習心得）
本次實習課程介紹 M-Police 警用行動載具與其中最常用的 M化整合查詢 APP。M-Police 可理解為第一線員警使用的行動版警政工作站,透過內部的 NPA Store 下載警政專用 APP（M化整合查詢、電子舉發、車牌辨識、電子巡簽等）,這些工具共同構成警政勤務行動化的基礎。
M化整合查詢的核心價值在於「整合」與「即時警示」：員警輸入身分證字號、車牌號碼、車身／引擎號碼或銀行代碼與帳號後，系統會連結後端資料庫，一次比對人口、戶籍、相片、車籍、駕籍、通緝、逃犯、毒品人口、刑案資料、165 警示帳戶等多項資訊，並用跑馬燈、紅字等方式主動推播重大警示（如查捕逃犯、脫逃人犯、高風險對象），避免員警在時間有限的現場漏看關鍵資訊。系統也區分線上查詢（即時連後端、資料完整）與離線查詢（載具暫存資料，用於網路不穩或後端停機時），但離線查詢在恢復連線後仍可能回傳紀錄，並非完全不留痕跡。
課程後段延伸到車輛風險辨識：疑似權利車（車籍登記車主與實際使用人可能分離，例如車輛經當鋪、抵押或動產擔保後多次轉手）、AB車（真車車牌被另一台車仿冒使用，短時間內同車號出現在不合理距離即產生異常線索）、疑似偽造車牌（來自民眾申訴、報案或員警回報的異常通行紀錄）。這些警示都只是「疑似」性質,員警仍須進一步查驗車身號碼、引擎號碼與牌照狀態,不能僅憑系統提示直接認定違法。場所盤查與車輛盤查功能則讓員警可以把同一包廂或同一車輛內出現過的人員記錄下來,形成日後犯罪關聯分析的基礎——例如某人事後被查獲毒品,系統便能回溯其曾與哪些人同場出現,協助追查共犯或毒品來源。
最後,人臉辨識（即時相片比對）功能的下架是本次課程中很重要的一個教訓:過去該功能可拍攝現場人臉、產生特徵值並與國民身分證相片資料庫比對,推薦相似人選,但因為曾發生濫用爭議(用於篩選外貌),加上涉及生物特徵與個資保護疑慮,該功能已下架。這提醒警政科技的設計必須同時考量法律要件(如警察職權行使法第 6、7 條身分查證程序)、比例原則與個資保護,不能只以技術可行性作為使用依據。整體而言,M-Police 與 M化整合查詢展現警政工作從桌機化、紙本化走向行動化、即時化與整合化的趨勢,但查詢能力越強大,就越需要嚴格的因公查詢原則、查詢留痕與法律界線來規範使用。
事實查核與用語修正表
| 口述用語／原內容 | 核實結果 | 報告寫法建議 |
|---|---|---|
| M-Police 是警用行動載具 | 已確認，公開資料使用「M-Police 警用行動載具」名稱 | 可直接寫入 |
| 電子舉發可結合 M-Police 載具與藍牙攜帶型印表機 | 已確認，審計部資料指出電子舉發系統結合行動載具與藍牙印表機以提升製單速度與正確率 | 可直接寫入 |
| NPS Store（口述誤稱） | 應為 NPA Store | 警政署英文縮寫為 NPA，APP 僅能在警用載具／內部環境下載 |
| 165 是「警示帳戶」（口述曾誤聽為「智障帳戶」） | 已確認，正式名稱為 165 警示帳戶 | 應寫「警示帳戶」，並說明是風險或案件關聯提示，不等於直接認定犯罪成立 |
| 「權力車」（口述） | 應修正為「疑似權利車」 | 屬勤務用語，非精準法條名詞；正式概念可連結動產擔保交易法之動產抵押、附條件買賣、信託收據占有等 |
| 「AD車」（口述） | 應修正為 AB車 | A車為合法真車，B車為仿冒 A車車牌的車；正式法律問題對應道路交通管理處罰條例第 12 條（使用偽造變造或矇領牌照、牌照借供他車使用等） |
| 疑似偽造車牌可直接認定犯罪 | 需修正 | 僅為勤務警示，仍須員警進一步查驗車身號碼、引擎號碼、牌照狀態等證據 |
| 離線查詢不會留紀錄 | 需修正 | 離線查詢僅為當下未連線，恢復連線後仍可能回傳查詢紀錄，並非完全不留痕跡 |
| 道路交通管理處罰條例第 21 條、第 35 條 | 已確認方向正確 | 第 21 條：無照、駕照資格不符、吊扣吊銷期間駕駛等；第 35 條：酒精濃度超標、吸食毒品或類似管制藥品後駕駛 |
| M-Police 曾有人臉即時相片比對功能，後已下架 | 已確認，媒體報導指出該功能因個資濫用爭議於 2021 年下架 | 應強調現行身分查證仍須依警察職權行使法第 6、7 條程序,不可直接以人臉辨識取代查證程序 |
| 人臉辨識可在現場直接掃描 | 需修正 | 身分查證應先以詢問、請其出示身分證明文件等方式進行；仍無法查證時，才可能依法帶往勤務處所查證，不可逕行生物特徵蒐集 |
敏感內容書寫提醒
| 類型 | 可以寫 | 不建議寫 |
|---|---|---|
| 查詢範圍 | 「系統整合人口、車籍、通緝、刑案、警示帳戶等多項資料，供第一線查詢參考。」 | 實際查詢畫面截圖含真實個資、真實證號或帳號 |
| 警示帳戶 | 「165 警示帳戶是為偵辦刑案需要而通報之風險提示，非直接認定犯罪成立。」 | 「警示帳戶就是詐騙犯」等絕對化寫法 |
| 疑似權利車／AB車 | 「這些是勤務警示用語，仍須員警進一步查證。」 | 把「疑似」寫成「確定」、「已認定」 |
| 人臉辨識 | 「該功能因個資疑慮已下架，身分查證應回歸警職法程序。」 | 描述如何規避稽核或繞過查證程序的具體方法 |
| 因公查詢 | 「查詢須基於勤務或案件需要，並會留下可稽核之紀錄。」 | 實際帳號密碼、內部下載路徑、未遮蔽個資畫面 |
三個反思點
- 這套系統最大的價值不是「查得到」,而是「查得快、警示得即時」。 跑馬燈、紅字警示的設計,體現了在時間壓力極大的臨檢／盤查現場,把最重要的風險資訊主動推播給員警,比單純把資料攤開讓員警自己找更實用。
- 場所盤查與車輛盤查把「一次臨檢」變成「長期可回溯的關聯資料」,這是資料驅動辦案的具體例子。 但這也代表每一筆盤查紀錄本身都是敏感個資,如何保存、誰能調閱、保存多久,都是值得進一步了解的治理問題。
- 人臉辨識功能下架的案例,是「技術可行 ≠ 可以做」的最佳教材。 它提醒我,警政科技的每一項新功能,除了工程上能不能做到，更要先問是否符合法律要件（如警職法的合理懷疑、比例原則）與個資保護規範，這也是資訊人員在設計系統時必須具備的法遵意識。