Every architecture has a floor — a minimum set of properties below which the system cannot meet its obligations. For software, the floor might be correctness and security. For clinical devices, it is safety and efficacy. For care AI — AI systems that make or support decisions in the care of dependent patients — the floor has a specific shape determined by the accountability obligations that care imposes.

Care AI systems generate the appearance of accountability readily. There are dashboards. There are logs. There are audit trails. What is harder to determine, and what matters far more when an adverse event triggers a formal review, is whether that appearance corresponds to the four necessary proofs any accountability record must support.

Proof one: identity. The accountability record must be able to prove, to a standard that survives legal and regulatory scrutiny, that the recommendations generated by the care AI system were generated in response to data from the specific patient those recommendations were applied to. This is harder than it appears. Weak identity proxies — wristband scans, room-level sensors, face recognition under uncontrolled conditions — establish presence, not identity. A recommendation based on the biometric readings of a patient whose identity has not been cryptographically established is not an accountable recommendation. It is an accountable-looking recommendation built on an unverifiable assumption.

Proof two: authority. The accountability record must prove that the care AI system was authorized to do what it did — that the action taken or recommendation made was within the scope of consent given, by a person or proxy with the legal standing to give it, at the time the action was taken. This is not a static proof. Authority in care is dynamic: patients can withdraw consent, proxies can supersede prior authorizations, clinical scope can change. The authorization record must be continuous, not just a single enrollment event, and must survive challenges about whether the authorization in place at the moment of action was valid.

Proof three: time. The accountability record must prove when each decision was made and acted on. This is not about timestamps — it is about verifiable timestamps: time assertions anchored to an authoritative time source in a tamper-evident way, so that the chronology of events can be independently verified. Without verifiable time, the accountability record is a narrative, not evidence. It can be asserted, not proved. In care settings where the sequence of events in an adverse incident is often disputed, the ability to prove that sequence independently of the parties' testimony is not a technical nicety — it is the difference between a record and evidence.

Proof four: reasoning. The accountability record must make the AI system's decision logic legible to the people who need to evaluate it: clinicians, quality committees, regulators, legal counsel. This does not require interpretability in the computer-science sense. It requires that the record contain enough of the decision inputs, the triggered protocols, the flagged anomalies, and the considered alternatives to support a coherent narrative of why the system did what it did. A log that records outcomes without the reasoning that produced them is a transaction log. An accountability record must capture the decision.

These four proofs are not independent. They depend on each other. Identity without verifiable time creates a record that proves who was in the room but not when. Authority without identity creates a record of consent without a verifiable subject. Reasoning without either produces a decision tree floating in an evidentiary vacuum. The accountability floor requires all four simultaneously, or it is not a floor — it is a set of accountability-shaped objects with structural gaps between them.

The post-quantum transition makes this harder and more urgent in equal measure. All four proofs depend on cryptographic primitives. Identity credentials, authority attestations, timestamp signatures, and audit trail integrity all rely on classical algorithms that will be broken by large-scale quantum computers. A care AI system that meets the accountability floor today but defers post-quantum migration will find, at some future point, that the entire evidentiary structure of its accountability record is cryptographically insecure — not just new records, but all records generated since deployment. The floor is not just a software and process question. It is a hardware and cryptographic one, and the window to build it correctly is before the quantum threshold, not after.

Systems that cannot demonstrate all four proofs do not have an accountability gap. They have an accountability appearance with no floor beneath it. That is not a risk to manage. It is a structural failure that a review process, after an adverse event, will expose — at the worst possible moment, for the people least able to afford it.

每个架构都有其底线——低于这一底线，系统便无法履行其义务。对于软件而言，底线可能是正确性与安全性；对于临床设备而言，底线是安全性与有效性；对于护理AI——为依赖性患者的照护做出或支持决策的AI系统——这一底线的形状，由护理本身所施加的问责义务所决定。

护理AI系统很容易制造出问责的表象。有仪表板，有日志，有审计记录。然而更难判断、在不良事件触发正式审查时也更为关键的，是这种表象是否对应于任何问责记录必须支持的四项必要证明。

第一项证明：身份。问责记录必须能够证明——达到能够经受法律和监管审查的标准——护理AI系统生成的建议，是针对该建议实际作用于的特定患者的数据而生成的。这比表面看起来要难。弱身份代理——腕带扫描、房间级传感器、非受控条件下的人脸识别——确立的是在场，而非身份。一个基于身份未经密码学确立的患者生物特征读数而生成的建议，不是一份有问责保障的建议；它是一份建立在无法验证的假设之上、看起来有问责保障的建议。

第二项证明：授权。问责记录必须证明，护理AI系统被授权执行其所执行的操作——所采取的行动或给出的建议，在执行时属于所获同意的范围之内，且该同意是由具有合法授权资格的人或代理人给予的。这不是静态的证明。护理中的授权是动态的：患者可以撤回同意，代理人可以取代先前的授权，临床范围可以改变。授权记录必须是连续的，而非仅仅是一次性的注册事件，且必须能够经受对行动发生时所持授权是否有效的质疑。

第三项证明：时间。问责记录必须证明每项决策的作出和执行时间。这不是关于时间戳的问题——而是关于可验证时间戳的问题：以防篡改的方式锚定到权威时间来源的时间断言，使事件的时间顺序能够被独立核实。没有可验证的时间，问责记录就只是一个叙述，而非证据；它可以被主张，但无法被证明。在护理场景中，不良事故的事件顺序往往存在争议，独立于各方证词来证明这一顺序的能力，不是技术上的锦上添花——它是记录与证据之间的分界线。

第四项证明：推理。问责记录必须使AI系统的决策逻辑，对需要评估它的人——临床医生、质量委员会、监管机构、法律顾问——清晰可读。这不需要计算机科学意义上的可解释性，而是要求记录包含足够的决策输入、触发的协议、标记的异常以及考虑过的备选方案，以支持一个关于系统为何如此行动的连贯叙述。一份只记录结果而不记录产生结果的推理过程的日志，是一份交易日志。问责记录必须捕捉决策过程。

这四项证明并非相互独立，而是彼此依赖。没有可验证时间的身份，只能证明谁在场，却不能证明何时在场。没有身份的授权，只能证明存在某种同意，却没有可验证的主体。没有前两者的推理，不过是一棵漂浮在证据真空中的决策树。问责底线要求同时满足全部四项——否则它就不是底线，而是一组具有问责外形但彼此之间存在结构性断层的对象。

后量子过渡使这一切更加困难，也同样更加紧迫。四项证明全部依赖密码学原语。身份凭证、授权证明、时间戳签名和审计记录完整性，均依赖于将被大型量子计算机破解的经典算法。一个今天满足问责底线但推迟后量子迁移的护理AI系统，将在某个时刻发现，其问责记录的整个证据结构已在密码学上失去保障——不仅是新记录，而是自部署以来生成的所有记录。底线不仅仅是软件和流程问题，它是一个硬件与密码学问题，而正确构建它的窗口在量子门槛到来之前，而非之后。

无法同时证明这四项的系统，不存在问责缺口——它们拥有的是没有底线支撑的问责表象。这不是一个需要管理的风险，而是一个结构性失败，将在不良事件发生后的审查中被揭露——在最糟糕的时刻，由最无力承担后果的人来面对。

每個架構都有其底線——低於這一底線，系統便無法履行其義務。對於軟件而言，底線可能是正確性與安全性；對於臨床設備而言，底線是安全性與有效性；對於護理AI——為依賴性患者的照護作出或支持決策的AI系統——這一底線的形狀，由護理本身所施加的問責義務所決定。

護理AI系統很容易製造出問責的表象。有儀表板，有日誌，有審計記錄。然而更難判斷、在不良事件觸發正式審查時也更為關鍵的，是這種表象是否對應於任何問責記錄必須支持的四項必要證明。

第一項證明：身份。問責記錄必須能夠證明——達到能夠經受法律和監管審查的標準——護理AI系統生成的建議，是針對該建議實際作用於的特定患者的數據而生成的。這比表面看起來要難。弱身份代理——腕帶掃描、房間級感測器、非受控條件下的人臉辨識——確立的是在場，而非身份。一個基於身份未經密碼學確立的患者生物特徵讀數而生成的建議，不是一份有問責保障的建議；它是一份建立在無法驗證的假設之上、看起來有問責保障的建議。

第二項證明：授權。問責記錄必須證明，護理AI系統被授權執行其所執行的操作——所採取的行動或給出的建議，在執行時屬於所獲同意的範圍之內，且該同意是由具有合法授權資格的人或代理人給予的。這不是靜態的證明。護理中的授權是動態的：患者可以撤回同意，代理人可以取代先前的授權，臨床範圍可以改變。授權記錄必須是連續的，而非僅僅是一次性的註冊事件，且必須能夠經受對行動發生時所持授權是否有效的質疑。

第三項證明：時間。問責記錄必須證明每項決策的作出和執行時間。這不是關於時間戳的問題——而是關於可驗證時間戳的問題：以防篡改的方式錨定到權威時間來源的時間斷言，使事件的時間順序能夠被獨立核實。沒有可驗證的時間，問責記錄就只是一個敘述，而非證據；它可以被主張，但無法被證明。在護理場景中，不良事故的事件順序往往存在爭議，獨立於各方證詞來證明這一順序的能力，不是技術上的錦上添花——它是記錄與證據之間的分界線。

第四項證明：推理。問責記錄必須使AI系統的決策邏輯，對需要評估它的人——臨床醫生、品質委員會、監管機構、法律顧問——清晰可讀。這不需要電腦科學意義上的可解釋性，而是要求記錄包含足夠的決策輸入、觸發的協定、標記的異常以及考慮過的備選方案，以支持一個關於系統為何如此行動的連貫敘述。一份只記錄結果而不記錄產生結果的推理過程的日誌，是一份交易日誌。問責記錄必須捕捉決策過程。

這四項證明並非相互獨立，而是彼此依賴。沒有可驗證時間的身份，只能證明誰在場，卻不能證明何時在場。沒有身份的授權，只能證明存在某種同意，卻沒有可驗證的主體。沒有前兩者的推理，不過是一棵漂浮在證據真空中的決策樹。問責底線要求同時滿足全部四項——否則它就不是底線，而是一組具有問責外形但彼此之間存在結構性斷層的對象。

後量子過渡使這一切更加困難，也同樣更加緊迫。四項證明全部依賴密碼學原語。身份憑證、授權證明、時間戳簽章和審計記錄完整性，均依賴於將被大型量子電腦破解的經典演算法。一個今天滿足問責底線但推遲後量子遷移的護理AI系統，將在某個時刻發現，其問責記錄的整個證據結構已在密碼學上失去保障——不僅是新記錄，而是自部署以來生成的所有記錄。底線不僅僅是軟件和流程問題，它是一個硬體與密碼學問題，而正確構建它的窗口在量子門檻到來之前，而非之後。

無法同時證明這四項的系統，不存在問責缺口——它們擁有的是沒有底線支撐的問責表象。這不是一個需要管理的風險，而是一個結構性失敗，將在不良事件發生後的審查中被揭露——在最糟糕的時刻，由最無力承擔後果的人來面對。