Gerald Kierce 是 Trustible 的首席执行官兼联合创始人。作为技术与政策领域的领导者，他长期致力于 AI 责任治理的落地。他领导 Trustible 履行其使命：帮助企业建立信任、管理风险，并遵守新兴的 AI 法规。此前，他曾担任 FiscalNote 的 AI 解决方案副总裁兼总经理，负责监督企业级 AI 产品，并在企业发展、产品、客户成功和高管运营等领域担任要职。他的职业生涯始终处于技术、监管和大规模企业执行的交汇点。
Trustible 提供一个 AI 治理平台，通过结构化工作流和文档，帮助组织梳理 AI 系统清单、评估并降低风险，并实现合规运营。该平台专为法律、合规和 AI 团队设计，旨在集中管理治理活动，将 AI 应用场景与监管框架对齐，从而在企业范围内更快速、透明地部署负责任的 AI。
从政策分析到 AI 治理：创业初衷与核心痛点
问：在创立 Trustible 之前，您在 FiscalNote 经历了从产品市场、幕僚长到领导 AI 解决方案的转变。这些经历如何让您确信 AI 治理需要一个专门的平台？在启动 Trustible 时，您最想解决的首要问题是什么？
Gerald Kierce： 我很幸运能在 FiscalNote 工作的 8 年多时间里担任多个角色，见证了它从种子轮/ A 轮阶段成长为一家上市公司。
通过这些跨职能的经验，我发现各行各业都在面临同一个问题：AI 治理本质上是一个“社会技术”（sociotechnical）问题，但大多数组织的应对方式却非常零散。团队往往将 AI 性能、安全、隐私、伦理和法律审查视为彼此独立的路径，缺乏一个统一的运营骨干将它们连接起来。当 AI 真正进入决策层时，如何将这些维度的治理意图转化为持久的执行力，是企业最挣扎的地方。
与此同时，监管环境也在发生变化。欧盟的《 AI 法案》（ EU AI Act ）等标准释放了一个信号：AI 正从实验性技术转向受监管的基础设施。我意识到，许多公司试图在 AI 系统部署之后才去匹配政策要求，而不是在设计之初就将治理纳入开发流程。
在 FiscalNote 的经历至关重要，因为我们当时正在将 AI 应用于法律和监管领域。这让我明白，有效的 AI 治理需要一种“逆向思维”：直接将政策和监管逻辑应用到 AI 系统的构建、部署和监控中。
当我们推出 Trustible 时，首要任务就是将这种理论化的治理转变为可操作的现实。我们专注于创建一个将技术行为、风险语境、责任归属和监管预期连接在一起的系统，为企业提供一个动态的 AI 记录系统（ System of Record ），确保治理能够跟上技术和监管进化的步伐。
AI 治理为何在落地阶段“熄火”？
问：根据您的前线观察，过去一年中，为什么很多治理计划在 AI 进入实际工作流和客户体验时会停滞不前？
Gerald Kierce： 一旦 AI 脱离实验阶段进入实际业务，治理停滞的原因通常是务实而非务虚的。大多数组织根本不知道如何评估与实际场景挂钩的 AI 风险。他们可以抽象地评估模型，但在“用例”层面却感到吃力——而在实际应用中，语境、影响和下游决策比单纯的技术指标重要得多。
这种问题在生成式 AI （ Generative AI ）中尤为突出。同一个基础模型可能被用于客服、内部研究或决策支持，每个场景的风险状况截然不同。如果没有结构化的评估方法，团队要么因过度谨慎而畏缩不前，要么在缺乏信心的情况下盲目推进。
此外，第三方 AI 进一步增加了复杂性。企业高度依赖供应商提供的 AI 能力，却缺乏一致的方法来评估这些系统。治理责任往往分散在法律、合规、安全和产品团队之间，缺乏明确的责任人和统一的框架，再加上仍在使用电子表格或传统的 GRC （治理、风险与合规）平台等陈旧工具，导致治理团队无法及时洞察风险的变化。
归根结底，治理停滞是因为组织在用针对“静态系统”的旧剧本去套用“动态”的 AI 系统。AI 需要持续的风险评估和与生产环境直接挂钩的工具。
迈向“第二年治理”：从启用转向持续监控
问：您如何定义“第二年治理”（Year Two Governance）？当组织从初步采用转向持续监控、漂移管理和持续合规时，会发生哪些变化？
Gerald Kierce： “第二年治理”标志着 AI 不再被视为一系列零散项目，而被视为决策的基础设施。在第一年，治理的核心是“赋能”，重点是批准用例和文档记录。
到了第二年，焦点发生了转移。问题不再是“是否应该部署”，而是随着数据、用户、供应商和法规的变化，系统能否长期安全可靠地运行。治理从“偶发性”变为“持续性”，由行为或语境的真实变化触发，而非基于日历的定期审查。
风险也变成了动态的。组织需要理解模型漂移、范围扩大或新利益相关者介入时风险如何演变。合规性也从简单的政策映射转向通过实时控制、监控信号和持续捕获的证据来强制执行。此外，真正的 AI 事件管理也将被引入，企业需要建立清晰的告警和升级机制，以便在问题演变成事故之前介入。
优先级建议：资源有限时该如何标准化？
问：面对分散的系统和有限的资源，您认为公司应该优先在全公司范围内标准化哪些治理能力？
Gerald Kierce： 优先级至关重要，以下是我的建议：
- 可见性（AI Inventory）： 首先要建立动态的 AI 资产清单。很多团队以为自己只有几个 AI 系统，结果发现存在大量“影子 AI ”和供应商嵌入的 AI 能力。
- 问责制（Accountability）： 明确谁对 AI 决策的结果负责，而不仅仅是谁开发或审查了它。
- 风险分类法（Risk Classification）： 建立一套通用的风险评估视角，无论对内建系统、生成式 AI 还是第三方软件都一视同仁。
- 证据自动化（Evidence Generation）： 我们常说“说到、做到、证明到”（Say It, Do It, Prove It）。将审批、变更和监控信号作为运营的副产品自动记录，这样在面对审计或监管询问时才能游刃有余。
展望 2026：不可或缺的治理能力
问：展望 2026 年，随着 AI 在更多业务部门扩展，哪些治理能力将成为“非标准不可”的要求？
Gerald Kierce： 到 2026 年，单纯依靠手动、偶发性的审查将无法满足监管机构、董事会和客户的要求。持续监控将成为基本门槛。
此外，供应链治理将变得不可或缺。企业必须通过统一的视角来管理内部模型和第三方插件，不能再让供应商 AI 成为治理盲点。**审计就绪的证据（Audit-ready evidence）**需要能够随调随用。
最后，治理将嵌入到 AI 的全生命周期中。它不再是部署前的一次性法律审查，而是集成到 SDLC （软件开发生命周期）、MLOps 和采购流程中的运营能力。
实战指南：无治理经验公司的头 90 天计划
问：如果您为一家已经有 AI 在线运行但尚无正式治理计划的公司提供建议，最初的 90 天应该如何安排？
- 前 30 天：获取基本可见性。 识别哪些 AI 系统正在运行，了解它们在何处影响决策，并分配明确的负责人。
- 中间 30 天：建立基础控制。 定义风险分类标准，为高风险系统引入审批关卡，并开始监控关键领域。
- 最后 30 天：从设置转向运营。 将监控集成到现有工作流中，明确问题升级路径，并确保证据记录在系统运行过程中自然积累。
