Originally published on NextFuture
Bạn cài một app trợ lý giọng nói cho Mac, thấy dòng "runs on-device" trên landing page và cấp luôn quyền microphone. Hai tuần sau, không ai trong team trả lời được transcript cuộc họp nội bộ đang nằm ở đâu. Bài này là checklist audit data path chạy trước khi cấp quyền, dựng từ phân tích của một dev đang tự làm loại app này.
"Local" là nhãn, data path mới là sự thật
Tác giả bài viết nói thẳng: một trợ lý giọng nói có thể chạy trong native Mac window mà vẫn gửi audio, prompt hoặc memory đi nơi khác. Anh không coi "private" là nhãn của model, mà là thuộc tính của toàn bộ data path — gồm audio capture, transcription, planning, speech generation, retained history, permissions và mọi optional network integration. UI native không chứng minh được gì về chuyện dữ liệu có rời máy hay không.
5 câu hỏi phải trả lời trước khi cấp quyền
Raw microphone audio đi đâu?
Transcription chạy local, external, hay configurable?
Screen context và conversation history có thể rời khỏi máy không?
Cái gì được lưu, lưu bao lâu, và xoá bằng cách nào?
Interface có hiện một off-device request trước khi request đó xảy ra không?
Tiêu chí loại của tác giả rất gọn: nếu sản phẩm không trả lời rõ năm câu này, thì nhãn privacy đang gánh phần việc mà kiến trúc không làm. Dùng đúng năm câu đó làm form đánh giá vendor, thay vì đọc trang marketing.
Local path và optional external path phải tách rõ
Tác giả mô tả sản phẩm của chính mình (Pace) chạy speech recognition, planning, vision, text-to-speech và retrieval trên Apple Silicon, với conversation memory, screen observations và meeting artifacts nằm lại trên Mac. Đây là claim của tác giả về sản phẩm của họ, không phải kiểm định độc lập — nhưng cách đặt ranh giới thì đáng copy: external planner phải có consent, phải hiện trạng thái off-device, và phải ghi một local audit record. Câu đáng mang đi hỏi mọi vendor: lựa chọn external không bao giờ được trở thành silent fallback. Khi model local fail, app tự gọi cloud hay dừng lại và hỏi bạn?
Quyền macOS là một phần của privacy
Một app local vẫn cần microphone, accessibility, screen recording, contacts, calendar, reminders. Local processing giảm lượng dữ liệu truyền đi, nhưng không xoá nhu cầu explain, grant, review và revoke từng quyền. Nguyên tắc tác giả dùng: cấp quyền nhỏ nhất, đúng thời điểm capability tương ứng thực sự cần — không cấp cả cụm lúc onboarding.
Và đây là ranh giới trung thực nhất trong bài: không app local nào hứa được rằng mọi optional integration là network-free. Tải model, fetch một URL, gọi external MCP server, chọn cloud planner — tất cả đều dùng network. Lời hứa dùng được thì hẹp hơn: boundary phải explicit, controllable và auditable.
Nếu assistant của bạn gọi tool: capability thay cho API key
Cùng vấn đề, lên một tầng. Tác giả Agent Firewall chỉ ra API key là binary — có hoặc không, và nếu key của finance agent bị leak thì người giữ key có thể rút sạch tài khoản. Hướng thay thế là capability có constraint và thời hạn: theo tác giả, một capability payments.send giới hạn dưới 100 và hết hạn theo ngày, revoke là chết ngay, request replay bị reject. Thư viện của họ chặn ở hai boundary, HTTP và MCP: verify capability, bind vào agent identity, check constraint, chống replay trước khi execute.
Làm gì tuần này
Mở app trợ lý bạn đang dùng và tìm tài liệu trả lời năm câu hỏi trên; câu nào không có tài liệu thì mặc định coi câu trả lời là "dữ liệu ra ngoài". Với agent nội bộ đang giữ API key dài hạn, đổi sang token có expiry và scope hẹp trước — việc này làm được trong một buổi. Thứ đáng theo dõi tiếp: app nào chịu hiện off-device state ngay trong UI, vì đó là tín hiệu kiểm chứng được, khác hẳn nhãn "on-device" trên trang chủ.
This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.
Top comments (0)