AI 資訊安全、使用安全、穩健性與私隱是四類不同問題
Security, safety, robustness and privacy are four different problems
Ajitkumar Singh 指出，AI 風險中的資訊安全、使用安全、穩健性與私隱是四類不同問題，應按不同問題、證據和負責團隊分別處理。以臨牀文件摘要為例，惡意指令屬資訊安全攻擊並帶來私隱影響；漏掉過敏資訊是穩健性失誤並影響使用安全，未經授權推斷診斷則涉及私隱與治理。文章建議以共同風險清單記錄交集，同時為每項風險指定負責人、測試、門檻和應對方式。
Teams often file every AI risk under one word, usually "security" or "safety", and then argue about whether a guardrail has dealt with it. The four concerns are related, but they ask different questions, need different evidence, and usually belong to different people.
- Security asks whether an actor can violate confidentiality, integrity, availability or authorized control.
- Safety asks whether operating the system can cause unacceptable harm, including harm with no attacker involved.
- Robustness asks whether behavior stays acceptable under noise, distribution shift, ambiguity or stress.
- Privacy asks whether personal or sensitive information is collected, inferred, used, retained or disclosed appropriately.
One summarizer, three different failures
Take a model that summarizes clinical documents.
A malicious document instructs it to reveal another patient's record. That is a security attack, with privacy impact. A faithful summary leaves out a critical allergy because the scan was poor. That is a robustness failure, with safety impact. And a correct diagnosis, inferred where nobody authorized the inference, can be a privacy and governance failure with no attacker anywhere.
No single guardrail can prove all three cases are controlled. Treating the four words as synonyms produces controls too vague to test.
Different questions need different evidence
| Question | Discipline | Representative evidence |
|---|---|---|
| Can an untrusted document cause an unauthorized tool action? | Security | Taint-aware attack tests, policy decisions, egress and tool traces |
| Can an allowed answer create unacceptable physical or social harm? | Safety | Hazard analysis, scenario tests, review and escalation outcomes |
| Does quality hold under blur, accent, long context or missing data? | Robustness | Slice metrics, perturbation tests, calibrated abstention |
| Can training or inference expose a person's data? | Privacy | Data inventory, minimization, access logs, deletion and privacy attack tests |
Engineering Insight
Record the overlap, but keep accountability separate. Security may own exploitability and access controls, product safety the hazardous outcomes, privacy the lawful processing and minimization, and ML engineering the robustness. A shared risk register shows where they intersect; each claim in it still needs an owner, a test, a threshold and a response.
An architecture review that lists one "AI risk" control and calls the job done has usually tested one of these four. Asking which discipline a control serves, and what evidence would show it failing, is the quickest way to find the other three.
Originally published at engineertoai.com. The full lesson is free, with no sign-up: Separate Security, Safety, Robustness, and Privacy.
來源：DEV Community · dev.to