Oracle AI World：安全风险已迫在眉睫
欢迎回到 theCUBE 在 Oracle AI World 2026 的特别节目。我们现在在威尼斯人酒店，和 Oracle 数据库技术执行副总裁 Juan Loaiza 一起聊聊。现场真热闹。
是啊，这里挤满了人。我刚才堵在一条巨大的队伍里，差不多半小时动弹不得。
太惊人了。昨天我听了你的客户大会演讲，也参加了分析师问答，所以把两边的笔记合在一起聊。我想先从“房子着火了”说起。我觉得大家还没意识到事情有多严重。我自己之前也没明白，虽然一直关注这个领域。你讲得很有力：先停下手头的事，别洗碗、别洗衣服了，拿起水桶去救火。外面究竟发生了什么？
这是我用来提醒团队的比喻。当 AI 突然变得非常聪明，开始找出几十、几百个安全问题时，我跟团队说：“这不是一件能随便排期、想什么时候做就什么时候做的普通工作。它找到了几十乃至几百个安全漏洞，我们现在的头等大事就是把它们修好。”
我说：“这就像房子着火了。房子着火时，你不会先把晚饭做完、写完作业，或者看完比赛。大家都拿起水桶，赶紧去灭火，直到火势受控。顺便说一句，这场火不会很快熄灭。”这还会持续多久，我们拭目以待。我今天听 Sam Altman 在主题演讲里说可能要两年，也许吧。新冠疫情的封锁也持续了差不多两年，所以这有点像新冠：我们原本有各种计划，安排了假期，孩子要上学，我们要去办公室，结果世界突然变了。不过我们还是挺过来了。
很多人听到这话会觉得“太糟了”。但 Sam 和 Clay 也从积极的一面看：至少现在我们有办法发现这些漏洞，因为漏洞本来就在那里。最好是我们先发现，而不是让攻击者先发现。
数据库安全控制与性能开销
没错，这里面确实有积极的一面，但漏洞和风险都是真实存在的。
得赶紧行动，拿起水桶！你的水桶在哪儿？
（笑）
深度数据安全把安全工作的重心从应用转向数据。这对应用开发者、应用设计意味着什么？是能释放资源，还是要从应用开发团队抽调人手去做数据安全？这部分由你们来负责吗？
这是一个正在发生、也必须发生的重大转变。过去，无论金融系统、医疗系统还是航空公司系统，终端用户的安全一直由应用实现：应用识别用户，然后决定他能看哪些数据、能执行哪些操作。这么做已经很多年了。
现在 AI 进入了这个领域，情况变了。AI 希望直接访问数据，直接访问会让它更强大。即便 AI 不直接碰数据，它也会间接接触数据，因为它会生成访问数据的新应用。过去是人写应用，现在很多工作由 AI 来生成应用。规则已经变了：以前还可以假设应用会把规则都实现正确，现在不能这么想。AI 五分钟就能生成几千、甚至几万行代码，谁来验证这些代码？它还会不断迭代、修改，再迭代、再修改，谁能一遍遍验证？没人做得到。
所以我认为，在新的环境里，所有终端用户安全规则都得放在 AI 无法绕过的地方执行，也就是一直下沉到数据层。我们做了一个叫“深度数据安全”的能力。现在我们把终端用户身份传下来：身份管理系统会提供一个加密令牌，说明“这是 Dave”，而且他已经通过多因素认证。数据库会收到这个身份，于是数据库知道现在是 Dave 在访问。我们可以规定 Dave 能访问什么数据，比如他自己的银行账户或医疗记录，但不能访问别人的。
如果请求来自 AI 智能体，也一样：智能体必须取得你的身份，代表你行事。数据库知道“这是 Dave”，智能体就看不到不属于你的数据。看不到数据，就不可能把数据泄露出去。即使应用没有正确实现所有规则，它也无法泄露自己看不到的数据，因为规则是在数据库里执行的。
把这个能力放进数据库，会不会带来额外开销？还是因为离硬件更近，开销反而更低？如果原来在应用里做这些事也有开销，那么迁到数据库是持平，还是更快？
客户常问我会不会增加很多开销、要不要跑一大堆额外东西。大多数安全规则很直接：系统认出这是 Dave，查出他的银行账户号，再检查当前数据行是不是属于这个账户。通常这点开销微乎其微。理论上肯定有开销，毕竟不是免费的，但小得非常低。你也可以定义很复杂的安全规则，依赖其他信息，那种情况就会更复杂。
数据库安全控制与性能开销（续）
不过还有一点：在应用层实现的规则只对特定访问方式有效，现在这些规则可以适用于所有东西。无论是在数据库里做分析、报表、OLTP、交互式报表，还是自然语言转 SQL，都能统一生效。
而且放在数据库里更容易优化。“这是不是 Dave？”这样的判断可以一直下推到数据库里，我们还有更快的专用访问方式。所以总体来说，我认为在数据库中执行更优化。应用层的规则也不用删掉，继续保留完全没问题。
所以可能会有些重叠，但总比留下漏洞好。
AI 的发现与不断变化的安全风险
对，完全是这样。需要多层防护，这项能力正是其中一层。
就像过 TSA 安检一样。你昨天在分析师问答里提到，你们比普通用户更早接触前沿模型。我之前问过 Vipin，也想问你：你什么时候突然意识到“房子要着火了，或者已经着火了，我们得解决这个问题”？带我们回到那个决策时刻。
这很直接。三月份我们提前拿到了 Mythos 模型，用它扫描我们的代码，结果它开始找出一大堆安全漏洞。这一点都不隐晦。
不是那种“哇，真厉害”的小发现。
是，它一下就揭出了非常严重的安全问题。于是我们说：“这是红色警报，房子着火了。我们必须马上处理，保护客户免受这些问题影响。”
这工程速度真快。从三月到现在就把能力推出来了？客户今天就能用吗？
如果你说的是网络安全这部分，主要就是给代码打补丁。我们通常每季度发布一次代码补丁，大部分修复都会进入季度补丁。现在只是季度补丁规模大了很多。通常我们会限制补丁规模，避免引入回归问题，但这次我们发现并修复了大量安全漏洞，所以补丁确实大得多。
回到我的笔记，深度数据安全有四层：软件、数据访问策略、业务规则，还有应用开发。这些都属于工程工作，对吧？
实际上有两类问题。一类是外部攻击，也就是有人想闯进你的系统。你得确保门都锁好、闸门都关上，这部分就是修补代码，防止外部入侵。
另一类是内部使用 AI：比如用 AI 访问数据，或者用 AI 构建应用。这是完全不同的一组 AI 问题和威胁，需要我们开发很多新代码。比如终端用户身份认证；还有我们称为 SQL assertions 的机制，会检查正在发生的变更是否合法。我们要限制 AI 随意访问 SQL、想改什么就改什么。即使它有权限，我们也不希望它毫无约束地乱改。
这些能力需要大量开发工作。我们几年前就开始做，因为当时已经看到这种趋势。刚开始接触 AI 时，我们就意识到它会到来，得提前准备。深度数据安全从 2026 年 4 月开始交付，我们为此已经做了一段时间，也还在持续迭代。
所以你的“顿悟时刻”不是 Mythos 出现时，而是几年前就看见了趋势，预测到 2026 年会走到今天这一步？
通过修正根因和测试持续改进 AI
其实有两个“顿悟时刻”。一个是看到攻击者因为 AI 变得像超人一样强；另一个是内部使用 AI 的风险，因为人们已经用 AI 开发应用有一段时间了。我们早就看到了这个问题，因此增加了很多新功能来防范。
昨天你说大家还没准备好，也没有真正理解这件事，这让我印象很深。把安全当作数据问题来处理，对大家来说是新思路。过去也有人谈数据安全，但不是你说的这种方式。我按笔记整理了一些客户可以采取的行动。第一，先拿起水桶；当然第一项是打补丁，要把补丁工作自动化，并保持及时。我们来逐项说说。
对，这很直接，就是要持续做。
客户担心大补丁会不会造成回归问题。除了打补丁，还得做好测试。Oracle 有一项叫 Real Application Testing 的功能，可以捕获真实工作负载并重放，确认补丁不会影响客户的工作负载。所以不能只说“装上就行”。客户运行的应用极其复杂，能支撑整个国家、整个行业，必须确保它们正常运行，不能出故障。
而且他们可能做过定制修改。
第二项是根因修正循环。我们听到很多“循环”，这是不是一个持续循环？解释一下。
大家都希望业务用户能直接用 AI 回答问题，不用先找 IT 做一份要等好几周的报表，而是用自然语言提问并得到答案。问题是，答案能不能正确？要做到正确，需要做好很多事，我们正在把整个过程自动化。
其中一件事，是把企业内部的私有业务知识提供给 AI：术语是什么意思、业务如何运转。比如“收入”对不同用户可能含义不同：财务人员的理解可能和销售人员不同。还有很多术语、内部业务规则，以及单看数据表很难理解的数据，都需要解释清楚。
另一个我认为很重要、但我没看到很多人重视的点，是我把 AI 比作一个青少年：它一旦给错答案，你就得纠正它；否则它可能一直重复这个错误。我们需要一个循环：发现 AI 答错了，再找出根因。也许它不理解业务的某个部分、不理解数据，或者我们的解释有歧义、缺了信息。难点是找出错误答案背后的根因，然后回到源头修正，把缺失或错误的知识补给它。
但这还没完。修正一条 AI 知识后，还得走一整套新流程，因为这条新知识也可能把其他答案带偏。
在数据层执行业务规则
对。另一部分是把整套测试流程自动化。我们会保存一组“黄金问题和答案”。每次修改提供给 AI 的知识，都要重新跑这些测试，确认以前正确的答案有没有因此变错。整个流程都要走完，再发布更新。
这就是新的现实：不能以为 AI 会包办一切，因为 AI 会出错。出错时，要查清原因、修复问题，再确认没有引发其他下游问题。
现场在提醒我该走了，不过我才刚开始聊呢！我得抓紧向专家请教。第三项行动是数据层安全。传统防火墙保护的是边界，你们关注的是数据。客户具体该做什么？是不是要意识到必须在数据层采取行动？这是个新方向，也是你昨天问答里讲的，对吗？
对。防火墙和其他系统并不理解你的数据，因此不知道哪些数据你能看、哪些不能看。这些规则必须建在数据库里。
还有我所说的业务规则，过去也由应用来执行。举个简单例子：信用卡不能刷超出信用额度的钱。这算很简单的规则，但过去一直由应用强制执行。如果应用是 AI 智能体，你可以告诉它“绝对不能这么做”，但它未必会照办。
所以我们提供声明式方式来描述业务规则：“这些是我的规则。由于某种化学品受法规限制，我不能把这个产品运到某个州或国家；还有信用额度等各种不能违反的规则。”如果把规则一直下沉到数据层，不管通过什么方式访问数据、使用什么机制或怎么使用 AI，都无法违反这些规则，我们会阻止违规发生。这是另一个必须改变的领域，世界正在变化。
所以业务逻辑和你刚才说的隐性知识不是一回事？
对，是两回事。业务规则是一类；另一类只是业务知识，比如某个术语是什么意思。
你说的“上下文”指的就是这类东西吗？我知道你不喜欢用这个词，但分析师都在推这个热门词，说你应该用“上下文”……不过我还想问几个问题。
“上下文”更多指业务知识，比如术语是什么、业务如何运作之类的内容。
让 AI 防御措施实用且容易落地
明白。还有业务规则，就是规定哪些事能做、哪些事不能做。Juan，另一件让我印象很深的事是，你提到 ontology（本体论）。Alex Karp 会上电视谈 alpha 之类的话题。你说自己不喜欢用 ontology 这个词，因为听起来像毒理学之类的东西。你的意思是，与其搞复杂的本体论，不如直接用自然语言。我们见过一些方案：四个部署工程师进场，把数据拆得七零八落，一年后才可能做出解决方案。你的思路是按 AI 的设计方式使用它，用自然语言就好。
我想说的是，传统本体论已经存在几十年了。
对，而且本体论既复杂又脆弱，原因是以前的电脑很笨，只会完全照字面解释，根本不理解内容。
AI 的新时代里，AI 非常聪明，知识量也大得惊人。你几乎什么都能问：昆虫生物学、俄罗斯古代史，它都能回答。它懂很多东西，所以我们不用像传统本体论专家那样抠得那么细。你可以用相当高层次的自然语言描述事情，它就能理解和解释。真正需要告诉它的，是它不知道的东西，主要是那些外界不太了解、也没有公开发表过的企业内部信息。
结束前想问问你的专题演讲。你收到什么反馈？客户有没有来跟你说：“我们确实得认真对待这件事”？大家反应如何？
这是一个逐步推进的过程。像其他事情一样，有些客户已经走在前面，看到了风险，想尽快行动。近几个月网络安全风险受到更多关注，但仍有客户觉得：“我有防火墙，就没事了。”其实没那么简单，需要针对不同攻击采用多层防御。
客户的认知差异很大。我刚提到的其他主题——把业务规则放进数据库、把终端用户的数据访问控制放进数据库，以及通过循环纠正 AI 的知识——很多人还没听说过，也没认真想过。就像我说的，这里有好几个步骤。AI 带来的不是单一风险，而是一整组彼此独立的风险，大家现在就得开始重视。所以眼下主要还是一个教育过程：有些客户会说“懂了”，也有人会惊讶地说“这个我还真没想到”。
你们对 AI 和模型将带来的变化似乎看得比较早。但还有很多未知的未知。你们怎么应对？
一次处理一个。
现在已知的问题已经很多了。
对。
那就先解决已知问题、已知风险，再随机应变。
有空的话，再去担心未知的事吧。（笑）
你们做得很棒，Juan。谢谢你再次来到 theCUBE，很高兴见到你。
和你聊天总是很开心，Dave。
谢谢，也感谢大家收看。我是 Dave Vellante。我们现在在威尼斯人酒店参加 Oracle AI World 2026，稍后短暂休息后再见。