摘要
- AWS 的考验不仅仅在于其 AI 菜单的广度。对于使用 Amazon Bedrock、Lambda、Step Functions、IAM、CloudWatch 及相关服务的企业团队来说，决定性的衡量单位是可接受的操作：一个模型支持的请求，它调用正确的工具，尊重权限，留够证据，处理故障，并且足以让人类或下游系统接受。
- AWS 最大的优势在于集成。Bedrock 将托管的基座模型访问、检索、护栏、调用日志记录和评估功能带入同一云资产，该资产已经运行计算、身份、存储和运营。这减少了一些无差别的管道工作，但并未消除客户定义权限、测试异常路径、审查输出和衡量成本的责任。
- 主要的故障模式是普通的云和自动化问题，因模型不确定性而变得更加棘手：IAM 不匹配、配额耗尽、Lambda 节流、Step Functions 部分执行、陈旧的检索、不完整的日志记录、重试循环、支出失控、回退行为不明确以及审查人员超负荷。
- 商业问题不在于 AWS 能否承载该系统。而在于按每个可接受的操作计算时，托管 AI 工作流的收益是否超过平台费用、模型费用、可观测性成本、集成劳动力、锁定、重复的弹性工作和人工审查时间。
可接受的操作是分母
评估 AWS 是否适合企业 AI 工作的第一个错误是计算模型调用次数。模型调用这个单位太小，也太容易让人自满。它可能成功，而业务任务却失败。一个响应可能很流畅，但仍然无法使用，因为选择了错误的客户记录、工具缺乏权限、下游系统拒绝了更新、审查人员看不到证据，或者该操作创造的异常处理比它所替代的人工流程还要多。
更好的分母是可接受的操作。可接受的操作不仅仅是一个生成的答案。它是从请求到可用结果的完整路径：模型接收到正确的上下文，选择或支持正确的步骤，工具以正确的权限运行，结果被记录下来，成本可归因，故障路径可恢复，并且使用该结果的人或系统可以根据定义的标准接受它。这是一个更严格的衡量标准，但它决定了自动化是否改变了工作。
AWS 非常适合这项测试，因为它的 AI 服务坐落在成熟的云操作环境中。Amazon Bedrock 提供对基座模型及相关能力的托管访问。IAM 定义身份和权限。Lambda 和 Step Functions 可以执行和协调工作。CloudWatch 和 CloudTrail 可以记录操作和审计证据。S3、数据库、队列和事件服务可以保存数据并连接系统。对于已经投入 AWS 的公司来说，这种广度相较于直接拼接到单独操作栈上的模型 API 是一个真正的优势。
同样的广度也带来了核心风险。一个模型支持的工作流不是一个产品。它是一连串的模型行为、云权限、编排、检索、审查、监控、计费以及客户特定策略。每一层可能看起来健康，而可接受的操作却失败了。模型可以回答，但 IAM 可以拒绝工具。IAM 可以允许工具，但状态机在部分更新后可能失败。状态机可以重试，但如果未设计幂等性，重试会重复工作。日志记录可能存在，但未为所使用的端点启用。人工审查人员可以批准，但只因花费了太多时间，以至于自动化的经济效益荡然无存。
这就是为什么应该将 AWS 评判得更像一个操作平面，而不是一个功能目录。其价值在于使许多所需的控制措施在同一个云资产中可用。对购买者而言，其弱点是可用性不等同于一致性。客户仍需将服务转化为一个受管控的路径，以重复地产生可接受的操作。经济性计算应该包括可接受的输出、被拒绝的输出、升级、异常、回滚、重复运行、审查分钟数、日志保留、评估工作以及保持回退路由活跃的成本。
本文是关于作为 AWS 云实体的 Amazon Web Services 以及 AWS 运营的 AI 和云工作流服务。不是关于 Amazon 零售、Amazon Robotics、单个区域 AWS 子公司或客户自有应用的产品质量。AWS 可以提供模型访问及其周围的云机制。客户仍然拥有“可接受”的操作定义。
AWS 将模型选择带入云控制平面
Amazon Bedrock 为 AWS 提供了一个强大的起点，因为它使基座模型选择成为一种托管的云能力，而非单独的供应商集成。当前的 Bedrock 文档描述了一项全托管服务，可访问来自多个提供商的 100 多个基座模型，并支持包括 Converse、Invoke、Responses 和 Chat Completions 风格调用在内的 API 模式。重要性不仅在于模型的数量。还在于客户可以将模型选择、应用程序代码、身份、数据存储、日志记录和计费置于同一个云操作模型内。
当团队超越实验阶段时，这一点就很重要。在演示中，模型往往是明星。在重复性工作中，模型只是其中一个组件。团队需要决定哪个任务允许使用哪个模型，哪些数据可以发送给它，哪个用户或服务身份为该调用付费，哪个输出需要审查，哪个结果可以触发工具，以及哪些证据必须存储。Bedrock 可以提供帮助，因为这些选择可以连接到 AWS 账户、区域、IAM 角色、服务配额、CloudWatch Logs、S3 存储桶和成本工具。
该平台还提供检索和扎根功能。Bedrock 知识库可以将专有信息连接到生成的响应，使用检索增强生成，支持托管和客户自管方式，包含引用，并针对选定连接器应用文档级权限筛选。这一点很重要，因为许多企业操作并非开放式的推理问题。它们取决于当前的合同条款、工单历史、运行手册、政策、价目表、客户权限或库存记录。一个无法可靠查看正确证据的模型不应被信任来驱动真实的操作。
不过，检索并非魔术层。知识库的好坏取决于其背后的数据源、解析、索引、权限映射、更新节奏、排序和引用规范。如果错误的文档被索引，旧政策仍然存在，权限筛选未对齐，或者引用在审查中被忽略，那么 AWS 并未解决可接受性问题。它只是提供了一条客户必须治理的检索路径。
护栏创造了另一个重要边界。Bedrock 护栏可以应用内容筛选、拒绝主题、词汇筛选、敏感信息筛选、上下文扎根检查和自动推理检查。它们可以在推理期间使用，也可以通过单独的 ApplyGuardrail API 使用。这为团队提供了一种在普通应用程序代码之外定义安全与合规控制的方式。这也为采购和风险团队提供了比“模型被告知要行为端正”这一说法更具体的检查依据。
限制同样重要。护栏是控制措施，而不是每个可接受的操作都正确的证明。内容筛选可以阻止不良文本类别。敏感信息筛选可以掩蔽或阻止检测到的隐私信息。扎根检查有助于发现无依据的输出。自动推理检查可以根据逻辑规则验证内容。但企业仍须定义规则，选择检查失败时如何处理，决定是否需要人工审查，并衡量最终路径是否在捕捉足够多不良工作的同时，接受了足够多的良好工作。
换句话说，Bedrock 可以降低模型和控制平面的组装成本。但它本身无法解决可接受性标准。该标准存在于客户的任务定义中：哪些模型支持的操作是允许的，在什么权限下，有哪些证据，以什么成本，以及在置信度低时如何回退。
编排：流畅性成为负担之处
工作流问题始于系统被允许做的不仅仅是回答。Bedrock 的编排文档描述了一个模型驱动的序列，它可以组合指令、操作组、Lambda 函数、知识库、对话历史、跟踪记录和重复步骤。系统可以解释请求，选择操作或检索路径，调用 Lambda 函数或返回控制，观察结果并继续，直到获得最终响应或需要更多信息。
这很强大，因为它将 AI 从文本生成推向操作性工作。出于同样的原因，这也存在风险。一个能够在工具间进行选择的模型支持系统，必须根据工具选择、参数质量、权限边界、重试行为和结果处理进行评估。聊天窗口中的错误回答是一个缺陷。错误的工具调用可能会创建工单、更改记录、泄露数据、触发支付、开放访问或浪费云支出。
AWS 有组件来约束这一点。Lambda 可以将可执行工作隔离到函数中。Step Functions 可以使多步骤协调更加明确。IAM 可以划定哪个角色可以调用哪个服务。Bedrock 日志记录和 CloudTrail 可以创建证据跟踪。护栏和策略层可以阻止选定类别的不安全行为。这优于让模型从不受管控的脚本调用任意内部 API。
但客户必须设计模型输出与可执行操作之间的契约。仅仅说存在一个 Lambda 函数是不够的。该函数必须验证输入，检查幂等性，处理部分故障，返回结构化的结果，并暴露编排器能够理解的错误。仅仅添加 Step Functions 也是不够的。状态机必须区分可重试的错误和终端错误，知道何时补偿，保留证据并避免重复的副作用。仅仅依赖 IAM 也是不够的。角色必须匹配预期的权限，并且不能成为一个宽泛的服务账户，将模型的不确定性转化为云权限。
Step Functions 文档之所以有用，恰恰因为它不浪漫。它指出，状态可能因定义问题、Lambda 异常和瞬时问题而失败，并且当状态报告错误时，默认行为是使整个状态机执行失败。重试和 Catch 字段可以处理选定的错误，但运行时错误、数据限制问题、超时和嵌套执行行为需要明确的设计。正是这类平凡的可靠性细节，决定了一个模型支持的操作是成为可接受的工作，还是变成一堆异常。
Lambda 增加了自己的操作边界。AWS 文档解释说，Lambda 通过预置执行环境进行扩展，直到达到账户并发限制，默认的区域账户并发为 1,000 个并发执行。对于许多工作负载来说，这是一个宽松的默认值，而对其他工作负载而言则是一个明显的瓶颈。在突发性的 AI 工作流中，模型生成请求的速度可能快于下游工具、配额或数据库的吸收速度。故障可能表现为节流、延迟、部分完成或成本上升，而不是一个明确的模型错误。
可重复的答案是，将每次工具调用视为一份契约。定义允许的输入。在模型之外再次验证它们。使操作幂等。将破坏性或昂贵的操作置于明确审批之后。将读取、提议和执行权限分开。记录请求、决策、工具结果和审查人员操作。提前决定哪些故障重试，哪些升级，哪些放弃。AWS 提供了实现此目标所需的许多服务。纪律仍属于客户。
权限设计是模型可靠性的一部分
对于可接受的 AI 工作流，IAM 不是后台管道。它是可靠性平面的一部分。一个能力不足的模型支持系统会无害地失败或产生手动工作。一个能力过大的系统可能会将错误的解释转变成未经授权或具有破坏性的操作。有用区间很窄：足够的权限来完成可接受的任务，但没有足够的权限来即兴创作超出任务范围的事情。
AWS IAM 策略评估使这成为一个正式的问题。AWS 文档解释说，请求会被认证，其上下文得到处理，并且可用的策略会被评估。身份和资源策略在同账户情况下可以通过联合组合，而权限边界和组织控制会缩小有效权限集。显式拒绝优先于允许。这为 AWS 客户提供了一种成熟的授权语言，但也意味着最终权限可能是多个策略层的产物，应用团队难以随意推理。
模型永远不应成为权限的来源。它可以提议操作、准备参数或总结证据。权限应来自 IAM、应用程序策略、人工审批以及模型推理之外的业务规则。这对于涉及账户开通、网络配置、数据库修补、计费更改、安全例外、支持退款、客户数据或合规分类的工作流尤为重要。
一种实用模式是按阶段分隔角色。读取阶段可以检索记录和证据。起草阶段可以准备提议的操作。验证阶段可以检查模式、策略和成本。执行阶段只能在狭窄的角色下运行狭窄的工具。审查阶段可以决定结果是否被接受。如果工作流需要更广泛的权限，则应该要求更强大的审查路径和更清晰的日志。
这种模式花费金钱和时间。它增加了角色数量、策略审查、测试负担和异常处理。它还可能会减慢采用速度，因为快速演示使用宽泛角色就能工作，而实际版本则需要狭窄角色。但如果结果要成为可接受的工作，这项成本就不是可选的。宽泛角色可能会让第一次演示令人印象深刻，却让第一次审计令人不安。
AWS 的优势在于，许多企业已经具备 IAM 治理、账户结构、服务控制策略、资源标记和 CloudTrail 实践。在 AWS 上构建的团队可以重用这种机构力量。其劣势在于，AI 工作流可能会暴露这种力量的不均衡。一个角色混乱、标记薄弱、所有者不明确和账户边界不一致的公司，并不会仅仅因为 Bedrock 毗邻 IAM 就变得受管控。
因此，监督成本包括安全架构。必须有人决定哪些任务可以安全地自动执行，哪些需要审批，哪些只读，哪些需要双重控制，哪些必须保持手动。必须有人在服务更改后检查权限。必须有人测试被拒绝的操作是否安全失败，以及允许的操作是否未超出业务意图。这些时间应计入每个可接受操作的成本。
可观测性可用，但非自动证明
AWS 的第二大优势是证据。Bedrock 模型调用日志记录可以为账户和区域中受支持的调用收集请求数据、响应数据和元数据，目的地为 CloudWatch Logs 和 S3。文档指出，日志记录默认处于禁用状态。它还指出了覆盖范围的限制，包括通过某些端点的调用目前未被模型调用日志记录捕获。日志条目格式可以包括账户、区域、请求 ID、操作、模型 ID、身份、元数据和令牌计数。
这很有价值，因为模型支持的工作需要事后检查。团队必须能够问：谁发起了请求，使用了哪个模型，提供了哪些证据，返回了什么，消耗了多少令牌，调用了什么工具，返回了什么结果，以及审查人员为何接受或拒绝了它。没有这些记录，系统就难以改进，更难以信任。
然而，日志记录是分层的。CloudTrail 可以记录 API 活动和选定数据事件。CloudWatch 可以保存日志、指标和警报。S3 可以保存更大的记录。应用程序日志可以捕获业务决策。审查系统可以捕获接受和拒绝。完整的故事需要这些记录对齐。如果启用了模型调用日志，但工具调用未关联，审查人员可以看到答案却看不到操作。如果 CloudTrail 记录了 API 调用但未记录业务原因，审计显示发生了某事，但无法判断是否合理。如果日志保留时间太短，证据会在季度审查前消失。
可观测性也会改变成本。CloudWatch 定价取决于日志、指标、警报、模拟检查、仪表板及其他使用情况。Bedrock 定价取决于模型提供商、模态和层级。其他服务会增加各自费用。细心的团队可以高效地利用这些证据。粗心的团队可能会记录得太少以至于无法监督，或者记录得太多，使观测成为主要的成本中心。正确的数量并非一成不变。一个客户支持分类建议、一个安全例外、一个金融分类和一个云账户变更不需要相同的日志细节或保留时长。
可接受操作这个分母在此处有所帮助。团队不应该问日志记录是否“开启”，而应该问，接受一项操作以及调查有争议的操作需要什么证据。该证据应包括请求、数据引用、模型及其版本（若可得）、工具参数、权限上下文、验证结果、审查人员身份、最终操作和下游确认。然后可以依据可接受性标准逆向设计日志记录和存储。
AWS 较新的评估和可观测性能力指向了正确的方向，它们认识到实时的模型驱动工作需要跟踪、质量信号和持续评估。购买者仍应将这些视为治理的输入，而非自动的接受机制。只有当测试集代表任务、指标匹配业务损害、阈值得到强制执行且故障触发审查或重新设计时，评估分数才有用。
在可观测性密集的自动化中存在一个文化陷阱。团队可能会将可见性误认为控制。一个糟糕操作的漂亮跟踪仍然是一个糟糕的操作。一个显示低审查延迟的仪表板可能隐藏着审查人员的高度疲劳。一个令牌成本图表可能显示了模型支出，却忽略了修复异常的高薪工程师。AWS 可以使可见性变得更容易。但它不能决定哪种可见性是重要的。
配额与重试定义真实容量
AI 工作流容量不是账户可以提交的最大模型令牌数。它是整条路径的容量：模型请求、检索、工具执行、状态转换、数据库写入、人工审查和回退。AWS 文档明确指出，Bedrock 配额是账户、端点、模型和区域特定的，并且模型推理受令牌用量控制。一般参考列出了许多按模型、按区域的配额，有些可调整，有些不可。实际教训很简单：容量规划必须针对所选的模型、端点、区域和账户进行，而不是抽象地针对 AWS 进行。
这很重要，因为重复的 AI 工作通常具有突发模式。一批新的支持工单、合规审查、代码更改、销售请求或云操作可能同时到达。如果每个请求都扩展为检索、模型调用、工具调用、验证检查和审查事件，那么适度的业务积压就可能产生巨大的技术突发。第一个症状可能是排队、节流、部分完成或成本加速。
Step Functions 和 Lambda 增加了额外的配额表面。Step Functions 对请求大小、打开的执行数、Map Runs、HTTP 任务持续时间、状态转换和 API 节流都有配额。Lambda 有并发限制和函数级别的控制。这些本身不是障碍；它们是托管服务保持服务行为的方式。但系统设计者必须决定达到限制时会发生什么。工作是等待吗？还是失败？会重试吗？会通知人员吗？会防止重复操作吗？客户看到的是延迟结果还是错误结果？
在模型支持的工作流中，重试尤其危险，因为重复的步骤可能并非无害。重试读取通常很简单。重试写入、修补、工单更新、账户创建、策略更改或退款可能会复制副作用，除非操作是幂等的。重试模型调用可能产生不同的输出，除非下游契约将结果标准化。如果输入在结构上是错误的，重试失败的验证可能会浪费金钱。在配额故障后重试可能会创建一个自我放大的队列。
AWS 为团队提供了管理这些的组件：Step Functions 重试和捕获逻辑、队列、死信路径、Lambda 目标、应用程序代码中的幂等键、CloudWatch 警报和成本工具。负担在于编写操作规则。一个实时系统应该知道哪些故障是瞬时的，哪些是终端性的，哪些需要人工审查，以及哪些应该立即停止以避免成本或损害。它还应将失败的尝试记录为分母的一部分。一个产生 10,000 次模型调用和 6,000 个可接受操作的工作流，不是 10,000 个操作的系统。那 4,000 次失误解释了真实的经济性。
配额规划也会影响供应商选择。一家公司可能会发现，某个模型每令牌更便宜，但在其配额下更慢，而另一个模型更昂贵，但减少了重试或审查时间。对于某个狭窄的任务，直接的模型 API 可能更简单。当任务已经依赖 AWS 数据和 IAM 时，云原生栈可能更好。正确答案取决于工作负载。AWS 的规模是认真评估它的理由，而不是跳过容量测试的理由。
审查是隐藏的成本中心
AWS AI 工作流的商业案例常被表述为工程加速。这是合理的。AWS 发布的客户资料称，汤森路透利用 Bedrock 在其 Open Arena 平台内扩展了模型访问，将开发团队的模型部署时间从数天或数周缩短至数分钟或数小时。另一份 AWS 发布的汤森路透报道描述了具有人工验证的平台工程自动化，用于敏感操作，并报告了选定结果，例如 15 倍的生产力提升和首次启动时 70% 的自动化率。
这些示例很有用，因为它们展示了超越演示的企业实际使用。它们也揭示了不应忽视的部分：人工验证并未消失。在平台工程案例中，敏感操作仍然需要审批、审计跟踪和合规对齐。这正是严肃采用的样子。机器可以标准化和加速工作，但组织仍要决定何时必须由人来承担风险。
审查成本有多种形式。有首过审查，由人检查模型支持的结果是否可以接受。有异常审查，缺失上下文、工具失败或不确定的输出需要专家处理。有策略审查，安全或合规团队检查规则。有事件审查，不良结果被追溯到根本原因。有漂移审查，数据、模型、AWS 服务或业务规则的变化需要重新测试。这些成本可能比手动执行小，但很少为零。
购买者应衡量每个可接受操作的审查分钟数，而不仅仅是自动化率。一个自动化 70% 请求的系统，如果剩余的 30% 被清晰路由且审查迅速，那可能是优秀的。如果每个可接受的操作都需要一名高级工程师阅读冗长的跟踪记录，那可能就很糟糕。同样，一个拒绝许多操作的系统如果有防止损害作用，那可能很有价值，但如果拒绝是由于检索薄弱、指令不清晰或筛选过于宽泛造成的，那可能代价高昂。
AWS 的控制平面集成可以通过使证据更容易收集来减轻审查负担。模型调用日志可以显示身份和令牌计数。CloudTrail 可以显示 API 活动。护栏可以生成关于被阻止或扎根输出的信号。Step Functions 可以显示状态转换。IAM 可以显示角色边界。知识库可以包含引用。但审查人员仍然需要简洁的接受视图。分散在多个服务中的原始日志是证据，而非判断。
最好的审查设计将常规接受与真正的升级分开。对于低风险操作，系统可以显示源记录、提议的变更、验证检查和回滚路径。对于中等风险操作，它可能需要资源所有者的批准。对于高风险操作，它可能只准备一份建议。该设计的成本应计入 AWS 业务案例。培训审查人员理解模型不确定性、云权限和业务政策的成本也应计入。
这就是替代方案的重要性所在。手工工作劳动力成本高，但有时集成成本低。现有 SaaS 的功能可能较窄，但审查界面更具主观性。直接的模型 API 可以减少云锁定，但会增加日志记录和权限工作。内部构建可能完美契合任务，但会带来维护负担。当 AWS 的集成控制平面减少足够的管道和监督工作，从而改善可接受操作的成本时，它就赢了。当组织为广泛的栈付费，但仍需手工重建关键的审查层时，它就输了。
定价应解读为整体栈，而非单列项
Bedrock 定价不是一个单一的数字。AWS 按模型提供商、模态和服务层级呈现定价，包括标准、灵活、优先和预留等选项以及额外的特定功能费用。较新的 Bedrock 运行时和控制服务也采用基于消费的定价。CloudWatch、S3、Step Functions、Lambda、CloudTrail 事件处理、数据传输、存储和评估工作都可能产生费用。结果是整体栈成本，而非模型成本。
这并不是 AWS 独有的批评。任何严肃的 AI 工作流都有隐性成本。直接的模型 API 仍然需要日志、队列、审查工具、认证、数据检索、重试和事件处理。开源栈仍然需要计算、运营和支持。手动流程仍然需要人。AWS 的优势在于许多组件已经可用，且为云团队所熟悉。它的风险在于，添加服务的便利性可能会让总价格在流量增长前难以看清。
每个可接受操作的成本至少应包括六个板块。第一个是模型推理：输入令牌、输出令牌、模态、模型选择和层级。第二个是执行：Lambda 持续时间和并发性、Step Functions 转换、排队、存储和数据移动。第三个是检索和上下文：索引、嵌入、重排序、数据连接器、向量存储和权限。第四个是可观测性：日志、指标、跟踪、警报、仪表板、S3 保留和分析。第五个是治理：护栏、评估、策略检查、人工审查和审计。第六个是弹性：重复检查、回退模型、重试队列、灾难计划和迁移选项。
分母应该是可接受的操作，而非请求。假设一个团队提交了 100,000 个请求。如果 70,000 个成为可接受的操作，20,000 个需要手动返工，10,000 个失败或被放弃，那么真实成本不是模型账单除以 100,000。它是整体栈成本加上返工成本，再除以 70,000，且将失败视为缺陷。如果可接受的操作取代了昂贵专家工作，那可能仍有吸引力。如果它取代了便宜的现有 SaaS 任务，可能就并非如此。
AWS 的财务规模赋予了它强大的动力和资源。Amazon 报告 2025 年 AWS 部门销售额为 1287 亿美元，2026 年第一季度为 376 亿美元，第一季度 AWS 运营收入为 142 亿美元。这种规模有助于解释为什么 AWS 可以在模型访问、芯片、编排、治理、可观测性和企业支持方面进行投资。这也意味着 AWS 是一个战略平台供应商，而不是一个中立的公用事业。客户应预期强大的集成收益和显著的锁定压力。
锁定并非自动就是坏事。如果由于数据、身份、运营和开发人员已经在 AWS 上，使得在 AWS 上的可接受操作成本更低，那么留在 AWS 内可能是合理的。但购买者应该知道哪些东西难以迁移：IAM 策略、Step Functions 定义、Lambda 函数、Bedrock 特定的日志记录、知识库配置、护栏规则、评估数据、CloudWatch 仪表板和操作运行手册。一个可信的退出计划不需要廉价。它需要被理解。
客户证据有希望，但经过挑选
AWS 的客户证据支持了企业正在将真正的工作转移到其 AI 栈上的说法。汤森路透是一个强有力的例子，因为它是一家成熟的信息和工作流公司，而不是一个新奇用例。AWS 表示，汤森路透使用 Bedrock 来拓宽模型访问、支持实验，并构建带有 CoCounsel 的 Checkpoint Edge，这是一款带有内联引文的税务研究生成式 AI 应用。该案例表明，Bedrock 可以帮助大型组织使模型访问更安全、更具可重复性。
平台工程示例更接近可接受操作的框架。AWS 于 2026 年 1 月发布的博客称，汤森路透将重复性运营活动转移至一个 AI 驱动的自助服务中心，覆盖云账户开通、数据库修补、网络配置和架构审查等领域。它报告了敏感操作的人工验证和用于治理的审计历史。它还报告了生产力和自动化成果。这些说法是供应商发布的，不应被视为独立证据，但它们在方向上具有相关性。
普华永道与 AWS 的自动推理工作展示了另一种采用模式。AWS 发布的报道描述了应用于欧盟 AI 法案分类、受监管内容编排和公用事业停电决策支持的 Bedrock 护栏自动推理检查。重要的不是围绕数学确定性的营销语言。而是高风险的 AI 采用正在围绕正式化规则、可审计产物和专家人工判断来构建，而不仅仅是更自由的文本生成。
这些例子展示了 AWS 为何可信。大型专业服务、信息和平台工程团队正在将栈用于需要重视证据、策略和审查的任务。它们也展示了购买者为何应谨慎。公开证据由 AWS 及其合作伙伴挑选。它没有披露全部成本、失败尝试、审查时间、被拒绝的输出、支持负担、模型更改、配额限制、安全例外或长期维护。这是严肃使用的证明，而非普遍经济性的证明。
因此，正确的采购问题不是“其他企业是否使用 AWS 进行 AI？”它们确实在使用。问题是“我们的任务能否被足够好地定义、治理和衡量，以使 AWS 的托管栈改善可接受操作的成本？”一家拥有干净数据、强大的 IAM、成熟的云操作和清晰审查规则的公司可能会获得强大的杠杆效应。一家所有权不明、文件陈旧和手动异常文化的公司可能只是将混乱自动化。
现实的替代方案使 AWS 保持诚实
AWS 应该与几种替代方案进行比较，而不仅仅是与什么都不做比较。一种替代方案是手工工作。手工工作缓慢且昂贵，但它可以灵活、可问责且易于暂停。如果任务量低或风险高，带有更好检查清单的手动审查可能胜过复杂的 AI 工作流。
另一种替代方案是现有 SaaS。许多企业系统已经在较窄的产品内自动化了支持分类、IT 服务管理、合规审查、数据提取或云操作。专门的 SaaS 可能提供更好的审查界面和更少的集成选择。它也可能不那么灵活，更难与 AWS 原生的数据和权限对齐。
第三种替代方案是直接的模型提供商。这可以简化模型访问，有时还能改善模型功能或定价。但客户随后必须构建或购买更多的周边控制平面：身份、工具执行、日志记录、检索、评估、排队、成本归因和审查。对于已经深入 AWS 的公司，那个独立的栈可能是一种可以避免的负担。对于试图避免云集中的公司，这可能是值得的。
第四种替代方案是开源编排和自管理基础设施。这可以减少供应商锁定并增加定制化。它也可能产生持续的维护义务。团队必须保持框架、连接器、安全补丁、可观测性、测试工具和扩展行为的更新。对于一个狭窄的、战略性工作负载，且具有强大的工程所有权，这可能是明智的。对于广泛的企业平台，它可能变成一条隐藏的产品线。
最终的替代方案是做更少。并非每个任务都应成为模型支持的操作。有些工作应该保持为搜索结果、草稿、推荐或仪表板。工作流越接近更改记录系统、花钱、授予访问权或对外沟通，接受门槛就应该越高。AWS 广泛的栈可能会诱使团队连接一切。良好的治理会问，哪些操作根本值得自动化。
这些替代方案澄清了 AWS 的最佳适用场景。当任务已经依赖 AWS 托管的数据、IAM、事件处理、无服务器执行、日志和云工程团队时；当可接受操作标准可以被编码到策略和审查中时；当业务量证明投资于一条受管控的路径是合理的时，AWS 最为强大。当任务狭窄，数据在 AWS 之外，组织缺乏云治理，审查界面必须高度专业化，或者购买者更需要深度可移植性而非集成控制时，AWS 就较弱。
关注要点
第一个关注点是审计完整性。Bedrock 模型调用日志记录已有文档，但默认情况下是禁用的，并且具有特定于端点的覆盖限制。CloudTrail 可以记录重要活动，但选定的运行时数据事件需要配置。购买者应验证实际路径是否为有争议的操作、成本归因和事件审查记录了足够的证据。
第二个是权限漂移。IAM 角色、服务控制策略、资源策略和权限边界可能独立于模型支持的应用程序发生更改。上个季度安全的工作流，在账户重组、服务迁移或紧急例外之后，可能变得权限过大或不足。权限测试应成为发布和审查的一部分，而不是一次性的启动步骤。
第三个是配额行为。Bedrock、Lambda 和 Step Functions 配额是真正的设计输入。团队应该知道当模型令牌、并发执行、状态转换、HTTP 任务、下游 API 或审查队列饱和时，系统会如何表现。背压是一个特性。无声的队列增长和失控的重试是缺陷。
第四个是审查人员疲劳。系统应使接受变得更容易，而不是将专家变成日志阅读器。衡量每个可接受操作的分钟数、升级率、拒绝原因、重复的故障类别和审查人员的分歧。如果审查人员因为队列太长而习惯性地批准，那么表面上的自动化率并不是安全信号。
第五个是成本分配。Bedrock 的文档现在强调令牌计数和成本归因模式，调用日志可以暴露受支持路径的身份和令牌使用情况。这些数据应供给团队级的成本审查。如果模型支出、可观测性支出和审查劳动力无法与可接受的操作关联起来，业务案例就仍是推测性的。
第六个是回退。一个可信的工作流需要为模型不可用、配额节流、检索失败、策略不确定性、审查人员积压和下游拒绝制定计划。回退可能是一个较小的模型、一个人工队列、一个延迟响应、一个只读答案或完全停止。重要的是，回退是在故障之前设计的，而不是在故障期间拼凑的。
AWS 是可接受 AI 工作流的一个严肃平台，因为它将模型访问与企业已经使用的云控制结合起来。这是一个实质优势。它可以减少集成工作，使证据更易于保存，并为云团队提供熟悉的方式来执行权限和运营服务。但系统的强度仅取决于围绕它的可接受链。
因此，严谨的采购问题是狭窄而实际的。对于这个特定任务，AWS 能否帮助以比手工工作、现有软件、直接模型提供商、开源栈或做更少更低的总成本，产生更多的可接受操作？把模型、工具、权限、日志、配额、重试、审查和故障都算进去。如果答案仍然是肯定的，那么 AWS 就不仅仅是在托管 AI。它正在帮助将模型支持的工作转变为可接受的工作。