详细内容或原文请订阅后点击阅览
当代理删除生产数据库时
另一天，另一个例子是人工智能代理“作恶”并做了人类操作员不希望它做的事情。总而言之，PocketOS 的创始人 Jeremy (Jer) Crane 正在使用 Claude 来执行一些日常数据库维护。然后，克劳德继续删除生产数据库和托管在其云中的所有备份 [...]
来源:O'Reilly Media _AI & ML另一天，另一个例子是人工智能代理“作恶”并做了人类操作员不希望它做的事情。总而言之，PocketOS 的创始人 Jeremy (Jer) Crane 正在使用 Claude 来执行一些日常数据库维护。然后，克劳德继续删除生产数据库以及云提供商 Railway 托管的所有备份。值得赞扬的是，铁路公司成功恢复了丢失的数据。初始删除耗时不到10秒；我确信恢复需要更长的时间。让我们看看我们可以从所发生的事情中学到什么，以及为什么人工智能实际上只是现有问题的放大器，而不是原因本身。
我们知道这件事是因为杰尔在事件发生后写下了这件事。首先，在出现问题后花时间反思很重要；这就是我们学习的方式。与世界分享你的错误可能很困难，但这为我们所有人创造了互相学习的机会。其次，我见过很多人在 PocketOS 和 Railway 上公开扣篮。我猜这些人都没有经历过在这样的事件中发生的纯粹的恐怖和恐慌。那种感觉就是你只想大地张开，将你整个吞没。这种感觉我以前只经历过一两次，而且我不想重复这种经历。
Railway 的功劳之一是他们拿回了 PocketOS 的数据。如果您使用有效凭证通过 AWS、Azure、Google Cloud 或其他平台上的 API 要求删除，那么该数据就会消失——当然，除非您有自己的备份。 AWS 等人。没有维护客户数据的备份来防范客户错误。这是每年提醒您研究 3-2-1 备份策略的提醒。
我们可以从所发生的事情中了解到什么？好吧，对于所有关于这如何是人工智能的错误的讨论，我们这里有一个更简单的例子，说明常见的系统弱点被意外地和快速地利用。