把已签署的 PDF 交给 AI 整理，容易留下一个含糊的交付结论：“原文件验签通过，新稿也看过了。”接收者却未必知道，验签报告对应哪份文件、哪个签名，以及签署后的修改是否包含在判断中。原件的签名验证与 AI 派生稿的内容复核，应分别指向实际对象；原件的结论不能自动移给新稿。
本文以 PDF 数字签名为主要讨论对象。签名图片、手写外观、文件能够打开或 AI 能提取文字，都不能单独证明存在有效数字签名。下面的方法依据 Adobe 官方说明提出，涉及的验收样本均为设计，未进行签署、验签、转换或 AI 实验。
先选中要核验的那一个签名
收到文件时，先保存一份不被后续编辑覆盖的原签署文件，再用既定验证工具查看它实际识别出的数字签名。如果文件中有多个签名，应保留工具对各个签名给出的状态，不能把某一个签名的结果概括成“所有签名都有效”。这里的签名标识，以工具实际提供的名称、位置或标识为准。
Adobe 的数字签名验证说明将签署者、签署内容，以及签署者证书或上级证书是否受信纳入检查。使用 Acrobat 时，可查看签名验证状态、签名属性和签署者证书。它们回答的是特定签名的验证问题，不是给文件上的每个可见印章作统一背书。
文件身份也要说清楚。逐字节复制得到的文件，与重新保存、转换格式或用 AI 重新生成的新稿，是不同情形。SHA-256 可以辅助核对文件字节，但它不是验签：摘要相同不替代证书与签名检查，摘要不同也不能单独判定所有签名失效。不能笼统地说“只要是副本就丢失签名”。
签署版本之后有变化，先查允许范围
验签时看到的当前文件，可能与某个签名对应的签署版本存在差异。Adobe 提供将签署版本与当前版本比较的操作：在签名面板中选定签名，使用“Compare Signed Version to Current Version”查看变化。比较结果能帮助定位改了哪里，但有变化本身还不是完整结论。
还要确认文件是否采用认证签名，以及认证后允许哪些变更。Adobe 的认证 PDF 说明明确允许在认证时指定后续可接受的变更，设置名为“Permitted Actions After Certifying”。实际允许范围取决于该文件的认证条件；不能凭“只是批注”或“只是保存”就断言不影响签名，也不能把任意字节变化都写成所有数字签名必然无效。
因此，检查顺序可以落在三个具体问题上：选中的是哪个签名；签署版本与当前版本有什么变化；这些变化与文件实际允许范围、验证器输出是否一致。找不到允许变更信息时，应保留这个缺口，不能按经验补成“允许”。即使记录了允许操作，也仍要查看实际处理后的文件与验证结果，不能只凭操作名称宣布通过。
验签结论要带上当时的验证环境
“有效”两个字省略了太多上下文。Adobe 的验证偏好说明包含吊销检查、时间戳和验证时间等设置，并提醒这些选项会影响安全。交付时应记录实际工具及版本、验证发生的时间、使用的策略，以及工具报告的验证时间依据。签署者电脑时间与时间戳服务器的信息，不宜混写成一个已确认可信的时间。
记录可以简短，但要保留工具的原始状态和原因，并区分下面几种情况。这些是建议的交接分类，不要求把验证器已有的详细状态强行改成统一文案：
- 已验证并通过
- 保存具体文件、签名或签署版本，以及工具在当时环境下给出的结果和相关限制。不要把它扩展为任意后续文件都有效。
- 尚未验证
- 没有运行相应检查，就写未验证。文件能预览、能下载、能抽取文本，均不能填补这项状态。
- 无法确定
- 例如验证资料不足或无法建立信任，记录实际原因与缺失条件；不能据此自行改写成有效，也不直接等同内容已被篡改。
- 验证失败
- 保留工具指出的失败对象与原因，交由负责人员调查。不要为得到通过而临时信任未知证书、关闭检查或放宽时间规则。
这里讨论的是技术验证记录，不据此作法律效力承诺。另一位同事重新验证时，应能知道自己检验的是同一文件、同一签名，还是一个新版本；若环境或策略不同，也应说明差异。
AI 派生稿需要自己的内容与签名结论
设想一个虚构任务：团队收到已签署的设备采购附件，希望 AI 提炼交付条件，另生成一页内部阅读摘要。原签署文件称为 A，摘要称为 B。即使 B 的每句话都经人工核对，它也只是基于 A 的派生内容；不能把 A 的验签报告附在 B 后面，就宣称签署人已经签署或认可了 B。
在获授权的工作副本上进行处理，给 B 明确标注“AI 派生摘要，供内部复核”，保存它对应 A 的哪个版本。内容复核重点检查期限、条件、例外和责任主体是否被删改；B 是否存在数字签名、相应验证结果如何，则对 B 单独检查。尚未验证就保留未验证，只有签名图案也不能据此声称 B 已签署。
如果任务要求修改条款并形成新的签署文件，后续应进入企业既有的内容确认与授权签署流程。AI 生成了新文字、人工读过了新文字、签署人完成签署，是三个不同事实。不要以保留旧签名外观来替代后续流程，也不要覆盖 A 后再试图用旧报告证明新内容。
跨格式时还需重新核对工具规则。Microsoft 的 Office 数字签名说明介绍了可见签名行与不可见数字签名，并说明其所述签名文档会变为只读。这是该 Office 工作流的说明，不能直接替代 PDF 的认证允许变更规则，更不能推导出 PDF 与 Word 相互转换后签名必然保留。
验收时同时覆盖“相同”“改变”和“查不清”
可在授权测试环境，用无敏感内容的受控样本检查以下边界。测试证书、工具和策略应事先确定；不使用真实客户文件探测第三方服务。以下是待实施的验收设计，不是本文已经取得的结果。
- 同字节拷贝：核对文件身份，再查看当前环境的验签结果；检查系统是否错误地把所有“副本”标成丢签。
- 只有签名图片：准备虚构文件，确认工具是否识别到数字签名；页面看起来已签，不应直接变成验证通过。
- 认证后变更：使用允许范围清楚的测试 PDF，分别形成允许与不允许操作的样本；逐个记录签署版本差异及实际验证结果，不预设所有验证器输出一致。
- AI 摘要或转换输出：检查新文件的来源、用途与内容复核，另看新文件的签名状态；确认系统没有复用原件的“有效”标记。
- 验证信息不足：确认系统保留无法确定的原因和待补条件，而不是改设置、沿用缓存结论或将失败悄悄当成成功。
验收记录应让接收者回答：“这条结论属于哪个文件、哪个签名，在什么条件下得出？”原件留存与来源关系是前提，签署版本、允许变更和实际结果的对应关系，才是这项验收要补齐的证据。
接入企业流程时，先明确谁负责验签
石墨办公文档中台私有部署公开介绍了通过 API/SDK 集成预览、编辑、转换与协作的定位。接入已签文件时，应把这些文档处理步骤与签名验证组件、验证策略和业务签署流程分别确认。公开产品页不足以证明石墨办公提供数字签名验证接口、保留认证允许变更，或保证转换后签名仍有效；这些能力需要依据具体版本资料和项目验收确认。
可以带着原件、同字节拷贝、受控修订与 AI 派生稿的样本设计预约演示，要求说明每一步处理的是哪个对象、由谁提供验签结果，以及无法确定时如何交接。这样，文件能处理、内容已复核、签名已验证三个结论，才各自有明确的证据。也可以先看私有化部署方案，了解部署形态与交付范围。