数据来源声明：本文核心分析框架来源于 Forbes Tech Council 文章 “The Expiring Enterprise: Why Every App, Agent And Automation Needs A Half-Life”（作者：Akhilesh Sharma，A3logics 创始人兼 CEO，2026年9月15日），结合 NIST（美国国家标准与技术研究院）2026年3月发布的 AI 系统监控报告，以及 CISA 2025年安全能力目录。文中对现象的分析为作者观点，不代表原文作者和机构的官方立场。

一个没人注意到的灾难正在发生

2026年9月，一家中型金融服务公司的安全审计团队发现了一件奇怪的事：一个自动化数据汇报系统，每天凌晨3点向一个已经关闭了8个月的项目组的邮件列表发送报告。没有人在读这些报告。没有人知道这个系统在运行。没有人能回答这个问题：它是否还在做正确的事情？

更令人不安的是：这个系统有访问三个内部数据库的权限，其中一个包含客户敏感信息。

这个案例不是虚构的异常——它是企业数字化进程中一个系统性的、正在加速的问题的缩影。

在 Akhilesh Sharma（数字转型领域拥有超过20年经验的 A3logics 创始人兼 CEO）看来，这个问题在2026年正在以一个新的量级爆发，驱动力只有一个：AI 让创建软件、工作流、自动化、代理的成本趋近于零。

当创建成本趋近于零，”建太多”就不再是问题。真正的危机变成了：什么都不会死。

这不是隐喻。这是一个技术治理的结构性失灵，正在每一家正在认真部署 AI 的企业内部悄悄发生。

从Approval到Accumulation：一个被忽视的治理盲区

传统的企业技术治理在解决一个问题上非常擅长：控制创建。

部署一个新系统需要申请、审批、注册、分配负责人、定义权限范围。这套流程的设计逻辑是合理的——在软件开发昂贵的时代，一个新系统意味着数月的开发周期和大量的人力投入，所以值得花时间做前期审查。

但这套治理体系有一个根本性的假设漏洞：它假设系统的生命周期与批准它的背景保持一致。

现实中，以下情况每天都在发生：

  • 设计这个自动化的工程师已经换了另一个团队，新团队没人知道这个系统存在
  • 当初为这个 AI 代理定义的业务目的（比如”分析 Q1 市场报告”）已经过去了2个季度，但代理还在每周跑着
  • 为这个系统分配的数据库读取权限，在原始业务场景之外变成了一个潜在的安全漏洞
  • 这个集成从连接3个系统扩展到了7个，依赖关系早已超出最初的批准范围
  • 负责人在年度考核后晋升，新工作繁忙，已经4个月没登录过这个系统的管理控制台

系统在继续运行。业务背景已经消失。但没有任何机制触发一个问题：这个系统还应该存在吗？

根据 Sharma 的观察，企业当前的技术治理系统存在一个结构性的不对称：创建控制严格，存续控制缺位。他把这个问题命名为”孤儿自动化”（Orphaned Automation）——那些仍在运行、但已经没有实质性负责人、也没有人真正理解它们在做什么的数字资产。

孤儿自动化不是新词。企业 IT 管理领域谈论技术债已经几十年了。但在2026年，孤儿自动化获得了一个全新的危险维度：AI 代理。

与传统的确定性自动化不同，AI 代理的行为是概率性的，且随着时间推移会在没有明显征兆的情况下发生漂移。一个”当时看起来工作正常”的 AI 代理，6个月后可能已经在以完全不同的方式处理请求——而如果没有持续监控，没有人会知道这件事正在发生。

NIST 2026报告：这不是危言耸听，是测量到的问题

如果说”孤儿自动化”还停留在实践者的经验观察层面，那么2026年3月，NIST（美国国家标准与技术研究院）发布的一份关于已部署 AI 系统监控的研究报告，给这个问题提供了系统性的技术背书。

这份报告的核心发现是：已部署 AI 系统的持续监控，是当前企业 AI 治理中最薄弱的一环。

报告识别出三个系统性挑战：

挑战1：性能退化（Performance Degradation）

AI 系统在部署后通常经历一个”时间衰减”的过程。训练数据的分布（Data Distribution）与真实世界的分布会随时间逐渐背离，这被业界称为”概念漂移”（Concept Drift）或”数据漂移”（Data Drift）。这种漂移导致决策质量在没有任何明显信号的情况下，可能在几个月内从92%的准确率悄然下滑到79%。

这个退化过程是静默的——没有系统崩溃，没有报警，没有错误日志。AI 代理还在正常运行，只是它的判断越来越不可靠。但由于结果是概率性的，单次输出的偏差很难被注意到，整体准确率的系统性下降需要统计分析才能发现。

挑战2：日志碎片化（Fragmented Logging）

企业 AI 系统的日志通常分散在多个层面：模型层的推理日志、应用层的业务日志、基础设施层的系统日志。这些层面之间缺乏统一的关联机制和追踪 ID，导致当你需要审查一个代理的某次决策历史时，往往发现日志要么存在于三个不同的系统里，要么根本无法关联到具体的业务结果。

对于 AI 代理特别重要的是：当代理调用多个外部工具（通过 MCP 协议或 API 集成）时，每个工具调用可能在不同的系统里留下日志，但没有一个统一视图能告诉你：在这次客户请求处理过程中，代理依次做了哪些决策，为什么做出这些决策，最终结果如何。

挑战3：监控节奏不明确（Uncertain Monitoring Cadence）

多久检查一次一个已部署的 AI 系统？这个问题在大多数企业中没有明确答案，也没有行业标准来参考。季度审计？年度审计？还是”等出了问题再说”？

NIST 报告发现，绝大多数企业在为不同类型的 AI 系统建立基于风险等级的监控频率方面，几乎是空白的。高风险代理（可以修改生产数据、影响客户决策）和低风险代理（个人工作效率工具）往往执行着相同的——或者说同样缺失的——监控策略。

这三个问题联合在一起，形成了一个经典的”治理黑洞”：系统在运行，但你不知道它在做什么，不知道它做得好不好，也不知道应该多久检查一次。

CISA的警告：权限蔓延是你看不见的企业风险

在 NIST 从 AI 技术角度识别监控挑战的同时，CISA（美国网络安全和基础设施安全局）在2025年发布的安全能力目录（TIC 3.0 Security Capabilities Catalog v3.3）中，从安全角度提出了一个高度相关的要求：

企业必须维护一份实时的用户和实体权限清单。

这个要求的实质是：每个系统、每个代理、每个自动化，它们现在实际拥有的权限，你能实时知道吗？

绝大多数企业的诚实回答是：不能。

权限通常在系统创建时定义，但随着时间推移，以下情况会让权限清单逐渐变成一个谎言：

  • 系统集成的外部 API 增加了，但权限审批只在创建时做了一次，之后的增量没有经过审批
  • 为了某个紧急项目，临时为一个代理提升了数据库的写权限，但”临时”变成了永久
  • 负责管理这个系统的人离职时，没有人执行”离职权限清理”流程，这个人的授权仍然绑定在系统上
  • 合并了另一个业务线的系统后，两套权限体系的交集从来没有人审查过

随着时间推移，一个 AI 代理的”实际权限”与”必要权限”之间的差距会持续扩大。这个差距就是攻击者的机会窗口，也是内部合规风险的积累点。

CISA 的要求用一句话概括就是：不只问系统是否被授权，还要问我们今天是否还会再次授权它。

这是一个关于权限管理的认知革命。原来的问题是”它有权限吗”（过去时的批准），新的问题是”它应该有权限吗”（现在时的评估）。这一字之差，背后是整套治理哲学的转变。

解法：给每个数字资产一个「半衰期」

Sharma 提出的解决方案，从一个简单但深刻的类比出发：放射性物质有半衰期。数字资产也应该有。

这个想法的核心是：创建可以去中心化，但持续运行必须要赚到。

具体来说，他提出了一个”时间到期限”（Time-to-Live，TTL）机制，应用于每一个数字资产：应用、AI 代理、自动化、集成。

第一步：出生时设定 TTL

每个数字资产在创建时，必须定义以下四个元素：

名义负责人：不是”财务部”或”工程团队”，而是具体到一个有名字、有联系方式、有能力决定续期/限制/退役的真实个人。”团队负责”在现实中等于”没有人负责”。

业务目的声明：这个系统具体是为了解决什么问题而存在的？一个好的业务目的声明应该足够具体，让6个月后的另一个人读到后能立即判断这个目的是否仍然成立。”提高效率”不是有效的目的声明，”自动处理每周从财务系统导出的供应商对账单并发送给采购团队审批”才是。

权限范围清单：在创建时明确记录这个系统有权访问哪些数据源、有权触发哪些操作、有权与哪些外部系统交互。这个清单在每次续期时需要重新验证。

TTL（首次强制续期时间）：TTL 的长度应该反映系统的”后果严重性”——

  • 个人工作效率工具，无敏感数据访问 → 年度审查（12个月 TTL）
  • 部门级自动化 → 半年审查（6个月 TTL）
  • 跨系统集成，有读取敏感数据权限 → 季度审查（3个月 TTL）
  • 可修改生产数据、财务数据或客户数据的代理 → 月度审查（1个月 TTL）+ 持续实时监控

第二步：运行期间持续收集续期证据

这是 TTL 制度能够真正发挥作用的关键：续期审查必须基于证据，而不是负责人的主观记忆或善意判断。

为此，每个数字资产在运行期间需要持续产生可供审查的数据：

使用遥测（Usage Telemetry）：这个系统实际上被谁在使用，使用频率是多少，是否存在使用量归零但系统仍在运行的状态。一个从来没有人依赖的系统，是退役的优先候选。

结果监控（Outcome Monitoring）：系统在做什么样的决策，这些决策是否在预期的质量范围内。这一点特别重要：NIST 报告特别强调，”使用量高”不等于”运行正确”。一个被频繁调用但持续产出低质量结果的 AI 代理，比一个从不被使用的代理实际危害更大。

依赖关系状态（Dependency Status）：这个系统依赖的外部 API、数据库、其他系统的状态是否发生了变化。如果上游数据源的格式已经改变，而这个代理没有相应更新，它的输出可能已经失效，但表面上看起来仍在正常运行。

Kill Switch 有效性验证（Kill Switch Verification）：能随时停止这个系统的机制是否仍然有效。这一点听起来简单，但在实践中经常出现问题：负责人已经离职，停止系统的凭据存在他的个人账户里；或者系统的停止按钮在另一个团队的系统中，但没有文档记录如何找到它。

第三步：到期时强制续期或退役

当 TTL 到达时，系统进入”待续期”状态。负责人必须在规定时间内提交续期证明，覆盖以下五个维度：

  1. 持续使用证据：有真实的人或系统在依赖它，使用量数据可验证
  2. 结果合格证据：输出质量在过去周期内符合预期的标准，有监控数据支撑
  3. 权限最小化证据：当前权限范围已经是执行业务目的所需的最小集合，没有遗留的”超额”权限
  4. 依赖关系更新：外部依赖关系已经完整审查，没有失效或未记录的依赖
  5. Kill Switch 验证：停止系统的机制有效，并且文档化存储在至少两个授权人能访问的位置

如果负责人无法提供这些证据，或者在 TTL 到期后规定时间内（通常2-4周）没有响应——系统自动进入”受限运行”状态（只读，不能触发新的操作），然后根据预设规则进入退役流程。

这个机制的关键哲学转变是：默认状态从”持续运行直到被明确停止”，变成了”需要持续赚到运行权”。

第四步：组织层面的指标化

TTL 制度要真正在企业内部落地，需要有人负责追踪执行效果。Sharma 建议首席信息官和首席技术官将一个新指标加入技术健康仪表盘：

孤儿技术比例（Orphaned Technology Rate，OTR）——没有活跃负责人、使用遥测归零、或超过 TTL 未续期的数字资产，占总数字资产的比例。

这个指标目前几乎不存在于任何企业的标准报表中。但它可能是衡量企业 AI 治理成熟度最直接的指标之一——比”已部署 AI 代理数量”或”AI 投资回报率”更能反映企业是否真正在负责任地管理它的 AI 系统。

CISA 指导原则中明确指出，健康的企业安全状态要求实时了解每一个活跃权限的来源。OTR 是这一要求的可量化呈现。

真实的风险层次：从低风险到灾难性

Sharma 的分析框架中，孤儿自动化的风险不是均匀分布的。理解这个风险分层，有助于企业决定从哪里开始建立 TTL 制度。

低风险孤儿（可控，但需要清理）：个人工作效率工具，只有创建者本人使用，没有外部数据访问权限。这类孤儿的主要代价是存储空间浪费和技术资产清单混乱，不会产生安全或合规风险。

中风险孤儿（需要关注，有潜在漏洞）：部门级自动化工作流，有读取内部系统权限但没有写入权限。这类孤儿的风险是权限持续存在，如果相关账户被入侵，攻击者可以通过这个孤儿系统持续访问内部数据而不被发现。

高风险孤儿（立即处理，存在真实危害）：可以写入生产数据库、触发业务流程、发送外部通信的自动化系统。这类孤儿可能在无人监督的情况下静默地执行错误的业务操作——错误地更新客户记录、重复触发采购订单、向错误的受众发送通知。

灾难级孤儿（致命风险，法律责任）：有访问敏感个人数据、金融数据或医疗数据权限的 AI 代理，且决策影响真实个人。这类孤儿的”性能退化”不只是业务效率的下降，而是可能产生歧视性决策、违规披露信息、或影响真实人的真实权益。在 GDPR、CCPA 等隐私法规下，企业可能对孤儿代理的决策承担直接的法律责任，即使创建这个代理的人已经离职了5年。

这个风险层次图告诉我们：TTL 制度不需要一步到位覆盖所有数字资产。企业应该从高风险和灾难级孤儿开始，建立基本的续期审查机制。这不需要改变整个 IT 治理体系，但可以显著降低最严重的风险敞口。

为什么这在2026年变得更紧迫

有人可能会问：孤儿自动化不是一个古老的问题吗？为什么2026年这个问题突然变得更紧迫？

答案来自三个叠加的结构性变化：

变化1：创建速度的指数级增长

2024年以前，一个自动化工作流需要一个懂代码的工程师花数天时间来设计和实现。2026年，一个不懂技术的业务人员可以用自然语言，在 Claude Projects、Microsoft Copilot Studio 或 Salesforce Agentforce 中，花20分钟创建一个能连接多个企业系统的 AI 代理。

当创建门槛降到这个程度，企业每月新增的数字资产数量从数十个变成了数百个。但管理这些资产的人力、流程、工具，没有同步扩容。孤儿自动化的积累速度因此呈指数增长。

变化2：权限复杂性的结构性跃升

传统自动化的权限相对简单：读几个数据库，写一个报告。权限图是线性的。

但 AI 代理通常需要访问更广泛的工具和系统。MCP 协议的普及使得一个代理可以同时连接十几个外部工具：日历系统、CRM 数据库、代码仓库、电子邮件、Slack、财务系统……每一个连接都是一个权限节点，每一个权限节点都是一个潜在的风险点。

当权限图从线性变成网状，人工审查的难度超出了大多数 IT 团队的实际能力。

变化3：AI 决策的概率性和漂移性

传统软件的决策是确定性的：给定相同的输入，输出永远相同。这让监控相对简单——观察输出的一致性就可以发现问题。

但 AI 代理的决策是概率性的，且会随着输入数据分布的变化而漂移。一个今天”工作正常”的 AI 代理，在外部环境发生变化（用户行为模式改变、外部数据源更新、上游系统修改了 API）后，可能在毫无预警的情况下开始产出质量下降的结果。

这意味着孤儿 AI 代理的风险，远高于孤儿传统自动化。一个无人监管的传统自动化脚本，最坏的情况是持续做相同的错误事情。一个无人监管的 AI 代理，可能在6个月后做的事情已经与创建它的初始意图完全不同——而且输出看起来仍然”合理”。

反驳：TTL制度会不会扼杀AI创新？

对 TTL 制度最常见的反对声音是：如果每个数字资产都需要定期续期审查，这不是又在制造我们本来想用 AI 消除的官僚主义负担吗？

这个担心是合理的，但它混淆了两个不同的问题：创建的自由度和存续的责任。

TTL 制度从不阻碍创建。一个人仍然可以在20分钟内用自然语言创建一个 AI 代理。TTL 制度要求的是，在创建的同时，明确谁来负责这个代理，它应该做什么，以及什么时候需要检查它是否还在正确地做这件事。

这个要求的执行成本，与后果严重性成正比。一个只有自己使用的低风险个人工作流，年度审查就足够了，增加的负担可能不超过每年填写一份10分钟的表格。

真正需要高强度治理的，是那些能访问敏感数据、能修改生产系统、能影响客户决策的代理。对这些系统的严格 TTL 制度，不是官僚主义，而是负责任的工程实践——就像金融行业对重要系统变更要求变更控制委员会审批一样。

而且，Sharma 提出了一个更深刻的反驳：如果一个代理真的有业务价值，提供续期证据应该是简单的。使用量数据是真实的，结果质量是可测量的，负责人是清晰的。

如果续期证据难以提供——没有人在用它，没有人能说清它在做什么，没有人知道如何停止它——这本身就是这个代理不应该继续存在的最有力证明。

TTL 制度不是扼杀创新，而是迫使企业回答一个被长期回避的问题：这个数字资产，真的还值得存在吗？

不只是理论：企业已经在为此付出代价

TTL 制度还只是少数企业采用的先进实践，但孤儿自动化的代价已经开始显现在各类安全和合规事件中。

根据 Reco Security 2026年发布的《企业 AI 状态报告》，被调查的企业中有80%的 AI 工具缺乏 IT 部门的监管和可见性——这意味着大多数企业的孤儿自动化问题不是例外，而是规则。

这80%的数字背后是一个结构性现实：AI 工具的采用速度已经超过了企业 IT 和安全团队的管理能力。

Shadow AI（未被授权或未被登记的企业 AI 使用）的研究数据进一步放大了这个担忧：在一些大型企业中，CEO 级别的管理者知道并在使用的 AI 代理数量，已经超过了 IT 部门追踪到的 AI 代理总数的10倍。这个10倍差距，是企业孤儿技术问题最直观的量化呈现。

当 Anthropic 本周宣布其内部有约30,000个 AI 代理同时在工作（处理公司26%的 AI 研发工作），这对企业界是一个信号：规模化 AI 代理部署即将从 AI 研发实验室溢出，进入每一家认真对待 AI 的企业。届时，孤儿自动化的规模管理将从”先进实践”变成”必要的生存技能”。

这对企业意味着什么

从战略层面看，TTL 制度不仅仅是一个技术治理工具。它是企业在 AI 代理大规模部署时代，建立可信任计算基础（Trusted Computing Foundation）的核心机制。

当客户、监管机构、合作伙伴问”你们的 AI 代理做了什么决策，为什么做出这个决策，谁对这个决策负责”时：

一家有 TTL 制度的企业能够回答：每个代理有明确的负责人，每个负责人对代理的当前行为负责，每个代理的权限范围是最近一次续期审查确认的最小必要集合，每个代理的 Kill Switch 经过验证，随时可以停止。

一家没有 TTL 制度的企业只能回答：我们有很多代理在运行，我们尽力保证它们都是合规的，但我们没有办法告诉你每一个代理当前的状态。

这两个回答之间的差距，在2026年，正在从”最佳实践分类”变成”企业法律和监管责任边界”。

NIST 报告的结论是直接的：无法监控的 AI 系统，无法为其行为提供问责。在 AI 代理开始做出有实质影响的决策——批准信贷申请、筛选求职简历、分配内部资源、触发采购订单、处理客户投诉——的时代，无法问责的自动化，是一个企业无法承受的制度性风险。

2026年最困难的 AI 挑战，不是创建足够强大的 AI 代理。这个问题已经基本被解决了——工具已经可以在几分钟内创建出能处理复杂任务的代理。

最困难的挑战，是在 AI 代理大规模扩散之后，如何保持对它们的有效控制。

给每个数字资产一个半衰期——这个想法足够简单，简单到可以在一页纸上解释。但它的实施，需要整个企业从”创建文化”转向”存续责任文化”。这可能是未来2年内，企业 AI 治理领域最重要的、也是目前最被忽视的一项基础性工作。

参考资料

  1. Akhilesh Sharma, “The Expiring Enterprise: Why Every App, Agent And Automation Needs A Half-Life”, Forbes Tech Council, 2026年9月15日
    • URL: https://www.forbes.com/councils/forbestechcouncil/2026/09/16/the-expiring-enterprise-why-every-app-agent-and-automation-needs-a-half-life/
    • 来源类型：行业实践者观点文章，A3logics（数字转型服务商）
  2. NIST (美国国家标准与技术研究院), “New Report Challenges Monitoring Deployed AI Systems”, 2026年3月
    • URL: https://www.nist.gov/news-events/news/2026/03/new-report-challenges-monitoring-deployed-ai-systems
    • 核心发现：已部署 AI 系统监控面临性能退化、日志碎片化、监控节奏不明确三大挑战
    • 来源类型：美国联邦政府机构官方报告，credibility=high
  3. CISA (美国网络安全和基础设施安全局), “TIC 3.0 Security Capabilities Catalog v3.3 (Volume 3)”, 2025年7月
    • URL: https://www.cisa.gov/sites/default/files/2025-07/CISA TIC 3.0 Security Capabilities Catalog v3.3 (Volume 3).pdf
    • 关键要求：维护实时用户和实体权限清单（maintain a current inventory of user and entity permissions and authorizations）
    • 来源类型：美国联邦政府安全机构指导文件，credibility=high