跳到正文

2026年09月01日AI 版

6 条 · 3 个来源

头版

行业动态OpenAI

律师事务所 Gilbert + Tobin 如何借助 OpenAI 治理和扩展 AI
法律所规模化采用AI的关键在治理而非工具,CEO主导值得效仿。

Gilbert+Tobin 的首席执行官(CEO)若要把人工智能(AI)规模化,要决定的不是再选一个工具,而是先立起 CEO 主导的治理承诺与人类问责制,否则责任真空会比部署速度更早暴露。

展开全文

依据

材料里,Gilbert+Tobin律师事务所把AI(人工智能)规模化应用的关键放在治理架构,而不是单一工具选型;其CEO(首席执行官)主导的承诺机制用来保证自上而下的战略一致性。机制是:严谨治理加人类问责制,把生成式AI(可生成文本等内容的人工智能)限定为辅助人类专业判断的工具,避免算法自动决策造成责任真空。代价也写明了:治理流程可能削弱部署速度并增加管理成本,但法律行业高责任属性使这笔权衡被视为必要。材料同时给出适用边界:该模式对组织内部流程成熟度和资源投入要求较高,小型律所可能难以复制。案例把瓶颈指向与技术匹配的权责分配体系,而不是技术采纳率。

没写清 材料没有给出Gilbert+Tobin实际部署的模型、工具数量或用例规模,所以无法判断治理承诺在多大范围内被执行。

下一步 下一步可核对Gilbert+Tobin是否公开其AI用例清单与人类复核节点。

行业动态

2

  1. 行业动态Simon Willison

    wrapture 介绍
    wrapture 项目用包装器模式降低代码迁移成本,但引入间接层,或增学习门槛。

    负责给既有 Python 服务接 OpenTelemetry 的团队,可以先用 wrapture 的 TOML 配置只包一个类来试,不必先动业务代码;但若现有测试靠断言调用次数与参数匹配,则继续用 unittest.mock,binding 的间接层会让失败点变模糊。

    展开全文

    依据

    Graham Dumpleton——wrapt、mod_wsgi 和 New Relic Python agent 的作者——说,wrapture 把 wrapt 的 monkeypatching(运行时替换已有函数)思路扩到测试与追踪两件事上。Simon Willison 称它既能替代 unittest.mock,也能给已有项目加 tracing,并给出配置式写法:声明 capture、[[observe]] 的 target 与 name、[[sink]] 输出到 trace.jsonl。测试侧,wrapture.binding(Gateway, "charge").on_call.returns(...) 直接换返回值,transforms_result 则在原方法返回值上改一笔,两者都作用于 OrderService().place(500) 内部调用的 Gateway().charge()。Dumpleton 说这是他的第一个全 AI 驱动项目,每一行代码和文档都由 AI 在指导下写,并强调这不同于 vibe coding:设计由他定,AI 只是产出手段。Simon 提醒项目只有几周大。文章页脚的标签计数(python 1,284、ai-assisted-programming 407、testing 95、pytest 25)是 Simon 博客自己的标签量,不是 wrapture 的采用量。

    1. 写 TOML 捕获配置
      启动
    2. 运行被观测程序
      写入
    3. 落到 trace.jsonl
    配置式 tracing 的三步:TOML 配置、运行、JSONL 落盘。

    没写清 材料没给 wrapture 的运行时开销、与其他 mock 库共存的兼容边界,也没有采用量。

    下一步 读 wrapture 文档的 OpenTelemetry 章节,确认它要求的采集器与 Python 版本。

  2. 行业动态Simon Willison

    引用 Andrew Digby 的话
    引用同行观点而非原创内容,编辑部需核实信源价值再决定是否采用。

    这改变的是简报编辑部这次的取舍:与其把「325 只幼鸟」当成一条独立资讯采用,不如先核实 Simon Willison 转引的 Andrew Digby 原话出自哪份官方通报,再决定是照转还是换一手信源。

    展开全文

    依据

    Andrew Digby 说,今年这批雏鸟已经长成 juvenile(亚成体,即离巢但尚未性成熟的个体)并已计入种群,他把这称为今年最好的消息。这条内容目前是 Simon Willison 在个人博客引用页上收集的一句话,原始通报出自哪家机构、哪天发布,材料没有交代。可对照的数字是:1995 年只剩 51 只 kākāpō(材料中标注为 critically endangered species,极危物种),今年繁殖季的雏鸟是 325 只。机制上,编辑部拿到的只是「博客转引保育人士」这一层,不是保育项目自己发布的一手统计;51 是历史存量,325 是本期新生个体数,两者不是同一口径,不能当同一条增长曲线读。

    • 1995 年剩余 kākāpō51 只
    • 今年繁殖季幼鸟325 只
    1995 年剩余数与今年繁殖季幼鸟数并列,口径不同,只作对照。

    没写清 材料没说当前 kākāpō 的种群总数是多少,也没说 51 与 325 是否同一统计口径。

    下一步 下一步可核对的是这条引用的原始出处:Andrew Digby 所属保育机构的官方种群通报里,今年新增幼鸟数是否写明 325 只。

AI工具

2

  1. AI工具OpenAI

    医疗机构现可将 EHR 及其他行业数据接入 ChatGPT
    数据接入虽提升诊疗效率,但隐私风险与集成成本需权衡。

    已有标准化数据接口的医院信息科主管现在要选:把 EHR 接入 ChatGPT 写进本期预算,还是先只批一笔合规评估的钱。数据系统老旧的小诊所没有这个选项,它们的瓶颈在录入质量,不在接不接。

    展开全文

    依据

    OpenAI 在公告里说,医疗机构现在可以把电子健康记录(EHR,即医院内部保存病历的系统)和其他行业数据接到 ChatGPT。机制是把分散的数据源收进一个对话入口,临床医生不必再跨系统检索患者上下文与医学研究,省下的时间落在单次问诊的决策环节。代价转到医院一侧:敏感健康信息要过 HIPAA(美国健康保险流通与责任法案)等标准的审计与安全改造,这笔支出和流程适配由采购方出钱出人。另一处限制在输入端——若录入有误或字段不全,模型对 EHR 的解读可靠性随之打折。因此收益只对已有标准化数据接口的机构成立,集成前的风险评估是它能不能用的前提。

    没写清 材料没给集成成本的具体金额与落地周期,也没说明该功能覆盖哪些国家或模型版本,这两项不能替它补上。

    下一步 下一步可核对 OpenAI 是否发布商业伙伴协议(BAA)文本或 HIPAA 合规说明,并列出适用机构范围。

  2. AI工具Hugging Face

    介绍 @huggingface/kernels:用于本地 AI 的 200+ WebGPU 内核
    本地推理别只盯模型,HF这批WebGPU内核才是浏览器跑大模型的关键基建。

    浏览器端推理团队选型时,把 @huggingface/kernels 的 207 个 WebGPU 内核列为必评项,而不是只对比模型文件和运行时;这直接决定你在不同 GPU 上能否稳定复用同一套算子契约。

    展开全文

    依据

    Hugging Face 的 WebAI 团队(Nico Martin、Joshua Xenova)说,他们发布 @huggingface/kernels,并在 huggingface.co/webgpu-kernels 放出 207 个 WebGPU 内核,采用 Apache-2.0 许可。机制是:浏览器推理最终会拆成矩阵乘法、归一化、卷积、注意力原语、量化、数据布局变换等 GPU 操作;WebGPU 是浏览器访问 GPU 的可移植 API,WGSL 是写这些 shader 的通用语言。可移植不等于高性能,同一个操作在不同加速器上,workgroup 大小、内存访问模式、向量化、数据类型和融合策略都会改变结果。Hugging Face 把每个内核做成独立仓库:manifest.json 管输入输出和形状推导,test.json 管正确性用例,bench.json 管基准和调参用例,*.wgsl.jinja 管参数化 shader 模板。这样内核可发现、可测试、可基准、可版本化,上层运行时不用靠无版本文件 URL。配合 Fleet 浏览器端 GPU 测试套件,每次运行可按同意贡献私密证据,帮助发现错误结果和病态慢例、改进内核变体。

    • 标题200+ WebGPU Kernels
    • TL;DR207 WebGPU kernels
    标题写 200+,TL;DR 写 207,展示内核数量的两个口径。

    没写清 材料没给 207 个内核相对原生 WebGPU 手写 shader 或现有运行时在端到端推理上的加速比,也没列出具体浏览器/GPU 组合的通过清单。

    下一步 去 huggingface.co/webgpu-kernels 抽查 207 个内核是否都附带 manifest.json、test.json、bench.json,再用 Fleet 在你的 GPU 上跑一次。

精选深读

1

  1. 精选深读OpenAI

    通往 Astra 之路:关键能力与前沿安全防护
    Astra成首个达临界网络安全门槛的模型,加固释放值得部署方细究。

    Astra 拿到「首个过网络安全临界门槛」的定位后,真正要做决定的是打算把它接进高危自动化任务的部署方:先算清安全加固换来的输出多样性收窄与推理开销,自己这条业务线扛不扛得住,再谈用不用。

    展开全文

    依据

    OpenAI 在 Path to Astra 一文里把 Astra 定为自家 Preparedness Framework(发布前按能力分级、触发对应防护的评估框架)中首个达到关键网络安全能力门槛的模型,即安全防护在发布时被认定足以覆盖该级别风险。机制上这不是能力单边拉高,而是门槛触发后防护必须先到位,评估从理论推演转成实战判定。代价落在部署方:加固常以限制输出多样性、增加推理开销换取,而官方没给这两项的量级,所以泛化对话场景用它是亏的,只有高危自动化任务才撑得住这些约束。

    没写清 材料只说门槛覆盖关键网络安全场景,没说 Astra 具体触发了哪几类滥用路径,也没给加固带来的开销与输出限制范围。

    下一步 看 OpenAI 是否公开 Astra 在该门槛下的具体评估项清单与对应的部署限制条款。