让AI问责制落地的六种方法

随着智能系统进入生产环境并开始采取行动，组织很快发现问责变得困难得多。与传统企业软件不同，这些工具在与数据、API和业务工作流动态交互时可能产生不可预测的结果。

SHI International数据与AI售前经理David DuChene表示："当AI出了问题，通常会被归咎于离痛点最近的人。"SHI International协助企业进行AI部署和治理。

随着这些系统在工作流中从顾问角色转变为执行者，仅靠政策已难以落实问责。IT领导者必须通过清晰的归属权、持续的可观测性、明确的升级路径以及让责任可见的基础设施，将问责直接嵌入运营体系。

以下是六种让AI问责制在生产环境中可执行的方法。

方法一：从一开始就指定直接责任人

许多企业仍将AI问责视为共同责任，但一些专家认为，当系统进入生产环境时，这一假设最先失效。

CSG（一家客户体验、计费和支付软件提供商）高级副总裁兼CIO Joe Wilson表示："共同问责不是问责，你需要一个直接负责人。"

他介绍说，在CSG，AI项目需经过涉及高管层的治理审查，并在项目启动时就指定直接责任人。Wilson还表示，公司在各业务单元和产品组中设立了"CIO代表"，以确保问责贯穿AI项目的整个生命周期。

SHI的DuChene指出，许多企业仍缺乏针对这些环境的正式问责结构。"他们可能在纸面上有责任人，但一旦系统真正出故障，一切都要重新争论，最终还是回到谁离痛点最近。"

他提出了一个诊断性问题来判断组织是否真正准备好了："如果你的AI部署明天给出了错误答案并导致业务损失，谁来写事后复盘报告？"如果领导者无法迅速回答这个问题，说明问责结构在实践中尚未建立。

方法二：在扩展部署之前建立治理体系

过去几年，许多企业在建立安全运行所需的治理和运营基础之前就部署了AI系统。DuChene表示："我们看到最大的差距是顺序问题——就像先竖起墙壁再浇地基一样。"

这种顺序错位导致后期昂贵的返工。DuChene说，团队经常发现他们缺乏数据分类系统、AI感知的身份访问控制、血缘和来源追踪、审计能力以及故障升级渠道。

Arya Labs CEO、IBM前全球AI负责人Seth Dobrin表示，治理常常失败是因为组织将其视为政策层而非嵌入运营工作流的东西。"你如何将它整合到工作流中？如果这一点没做好，它就会崩溃。"

Dobrin回忆起与一家保险公司合作的经历——该公司花了18个月构建智能系统，最终却被法务团队完全阻止部署。问题不在技术本身，而在于过程中早期缺乏治理。"他们不得不把整个项目扔掉，"Dobrin说，"如果早点开始治理，他们本可以将其引向一个能让法务说'是'的方向。"

Dobrin表示，治理不应拖慢项目，而应深度嵌入工作流，使团队能够快速推进而不会出现下游合规或运营故障。"目标永远不应该是说不，而应该是想办法说是。"

CSG的Wilson持类似观点，认为治理应帮助团队吸收复杂性而非简单限制他们的能力。他将其比作车辆悬挂系统而非刹车机制。"我们的意图不是减速，而是加速，同时在遇到崎岖路面时能够应对。"

方法三：将数据治理作为问责的基础

Wilson表示，CSG在全面扩展AI项目之前，先集中精力治理数据。这些工作始于数据同步和隐私影响评估。"基础是数据，"Wilson说，"如果我们没有干净、同步和受治理的数据，我们就赢不了这场仗。"

EnterpriseDB CTO Quais Taraki表示，许多组织低估了AI系统与碎片化的企业数据环境交互后，维持问责的难度。例如，一个汇总客户交互的AI助手可能会从从未打算供给生成式AI工具的系统中抽取受监管或机密数据。

强有力的数据治理实践——包括血缘追踪、来源追踪、分类系统和访问控制——不仅有助于预防此类问题，还能在出错时为问责奠定基础。否则，团队将难以确定AI系统访问了什么数据、输出是如何生成的，以及敏感信息是否影响了决策。

"没有血缘和来源追踪，你就无法做根因分析，"Taraki说，"你不知道该改什么，也不知道事情是如何以意想不到的方式发生变化的。"

Taraki主张问责应跟随受治理的数据产品而非组织孤岛。当归属权分散在基础设施团队、数据科学家和应用开发者之间时，故障发生后责任就难以厘清。为供给AI系统的数据产品指定清晰的责任人，有助于在整个AI生命周期中建立问责。

方法四：在AI系统内部及外部构建可观测性

传统企业监控系统主要设计用于追踪正常运行时间、基础设施健康和应用性能。AI带来了不同的挑战：追踪推理路径、决策链和行为漂移。

CoSAI（安全AI联盟）成员、参与AI安全和智能体身份标准工作的Nik Kale通过他所说的"调查图谱"来描述这一挑战。这是一条推理轨迹，展示AI系统观察到了什么、访问了哪些工具、得出了什么结论以及最终采取了什么行动。

"当出现问题时，第一反应总是问'AI为什么做那个决定？'"Kale说，"坦白说，这是错误的问题。正确的问题是'系统实际上做了什么？'"

这一区别越来越重要，因为AI故障很少仅源于模型本身，而是从模型、凭据、API、工作流、策略和下游系统之间的交互中产生。

"模型没有行动，"Kale说，"模型周围的系统在行动。"

这种更广泛的问责视角也在改变IT领导者对可观测性的思考方式。企业不再孤立地监控AI模型，而是越来越需要洞察这些模型所交互的系统，包括数据源、API、应用、安全控制和下游工作流。

在实践中，这始于对提示词、模型输出、工具调用、数据访问事件和智能体操作的全面日志记录。结合传统的应用和基础设施遥测数据，这些日志创建了AI系统行为和决策原因的可审计记录。

当IT领导者试图识别未经授权的AI使用时，这种可见性尤为重要。虽然治理政策定义了员工应该使用哪些工具，但可观测性有助于揭示他们实际在使用哪些工具。异常的数据访问模式、意外的API调用、流向外部AI服务的流量以及敏感数据的不明移动，都可能是影子AI的迹象。

即使是治理良好的组织，当员工在批准的工作流之外采用未授权AI工具时也会陷入困境。"如果是影子IT，我们甚至不知道它的存在，"DuChene说，"我们不知道我们的什么数据被输入其中、如何被使用、如何被分发。"

通过将可观测性扩展到AI模型之外的企业环境，IT可以更早发现这些活动、更快调查，并减少影子AI造成的问责空白。

方法五：建立"升级"和"停止"机制

最重要的问责问题可能不是AI系统能看到或做什么，而是它何时应该停下来寻求帮助。

Kale表示，这通常是企业AI部署中最不成熟的部分。"大多数企业已经想出如何监控AI系统，但没有人真正构建第三块——系统何时真正停下来求助？"

Kale主张，企业需要为生产环境中运行的系统建立明确的升级路径、人工决策点和清晰的停止机制。"你不想要橡皮图章——你需要人在回路中，"他说，并补充道这个人应该被具名指定且有权说不。

Wilson表示，事件响应流程也需要演进，因为AI故障的表现与传统IT中断不同。"传统IT事件通常是上下场景——要么正常运行要么宕机，"他说，"AI故障更微妙。"

模型可能逐渐漂移，输出可能随时间退化，工作流可能开始产生意外结果而系统在技术上并未故障。Wilson表示，这导致越来越需要涉及法务、沟通、安全、审计、业务团队和IT运营的多学科响应流程。

方法六：像对待员工而非软件那样对待AI系统

一些企业仍像管理传统应用那样治理AI。但Kale认为，AI系统的行为更像员工而非确定性软件。

"你不能部署一次就完事，"他说，"像员工一样，它们需要持续的监督。"

这种持续监督正在成为核心问责职能。员工不会被雇佣、培训后就无限期地放任不管。管理者会监控绩效、提供反馈、评估职责变化，并在行为偏离预期时介入。Kale认为AI系统越来越需要类似的对待。

传统软件通常可以在发布时审查和批准，因为其行为在版本之间保持相对稳定。AI系统则不同——模型会演进，提示词会改变，检索系统会更新，智能体可用的信息也在持续变化。

这一挑战不仅限于内部开发的系统。企业还必须监控所依赖的第三方AI服务。不仅供应商模型会自行演进，供应商还会在幕后更新软件和功能。"我们上个季度批准的供应商，这个季度在功能上已经是另一个供应商了，"Kale说。

因此，问责不能在系统部署后就结束。必须有人持续负责监控性能、审查变更、评估风险，并确定系统是否继续在可接受的边界内运行。Kale指出，CoSAI的AI共享责任框架是正在兴起的努力之一，旨在厘清企业、软件供应商、模型提供商和基础设施运营商之间的责任。

取得最大进展的组织正在发现，问责不能在纸面上分配后就束之高阁。随着AI系统变得更加自主，问责正成为一种嵌入数据治理、可观测性、升级流程和持续监督中的运营能力。对IT领导者而言，挑战不再是定义责任，而是让责任可执行。