Los equipos de seguridad de Databricks y Google afrontan una nueva disyuntiva en la defensa con IA

Databricks ha publicado una nueva guía de seguridad centrada en un conflicto: la IA puede acelerar la defensa, pero solo cuando los equipos confían en los datos y la automatización que la sustentan. Para las organizaciones que evalúan implementaciones de Databricks y Google, la propuesta va más allá de la analítica. Databricks quiere que el lakehouse se convierta en una capa operativa para los datos de seguridad, las investigaciones, la ingeniería de detección y la respuesta asistida por IA.

La guía llega en un momento en que los equipos de seguridad replantean el sistema de gestión de información y eventos de seguridad, o SIEM, que tradicionalmente centraliza los registros y las alertas. Databricks sostiene que la telemetría fragmentada, la retención costosa y los flujos de trabajo desconectados impiden a los defensores usar la IA de forma eficaz. Su respuesta propuesta sitúa los datos empresariales gobernados en el centro y permite después que analistas y agentes de IA trabajen sobre ese contexto compartido.

Esta posición enfrenta a Databricks con algo más que los proveedores consolidados de SIEM. Cuestiona la idea de que los datos de seguridad deban permanecer dentro de una plataforma de seguridad especializada. Google Security Operations, Microsoft Sentinel, Splunk, CrowdStrike y otros proveedores también están incorporando investigación y respuesta impulsadas por IA. La competencia se está convirtiendo en una elección entre una suite de seguridad integrada y una plataforma de datos más amplia adaptada para la defensa.

Lo que Databricks realmente ha puesto sobre la mesa

El anuncio es un plan estratégico para las operaciones de seguridad, no una evaluación comparativa de producto validada de forma independiente.

Databricks publicó su ebook para líderes de seguridad el 2 de septiembre de 2026. La guía presenta una arquitectura de datos unificada como base de la ciberdefensa moderna. Su argumento central es que las organizaciones no pueden implementar agentes de seguridad fiables mientras sus registros, identidades, alertas y contexto empresarial permanezcan separados.

La empresa describe tres cambios conectados. Los equipos de seguridad deberían consolidar más telemetría, hacer que la analítica sea accesible más allá de los grupos especializados de ingeniería e introducir agentes de IA dentro de flujos de trabajo gobernados. Este enfoque convierte el lakehouse en algo más que almacenamiento a largo plazo. Se transforma en un espacio para la detección, la investigación, el enriquecimiento y determinadas actividades de respuesta.

La guía para líderes de seguridad destaca varias cifras de clientes y del sector. Databricks afirma que el 72% de los ejecutivos de seguridad encuestados tienen dificultades con los datos aislados. También señala que Arctic Wolf procesa ocho billones de eventos de seguridad cada semana.

La guía indica que Rivian redujo en un 60% los costes relacionados con SIEM después de modernizar su arquitectura de datos de seguridad. Otro ejemplo afirma que los equipos implementaron reglas de detección entre cinco y seis veces más rápido. Estas cifras ilustran el argumento de la empresa, pero requieren una interpretación cuidadosa.

Databricks no presenta cada cifra como una comparación controlada entre entornos de seguridad equivalentes. La combinación de cargas de trabajo, las políticas de retención, la dotación de personal, el volumen de datos y los contratos vigentes pueden afectar sustancialmente al resultado. Una implementación exitosa para un cliente no establece una tasa de ahorro universal.

La señal útil es el patrón detrás de los ejemplos. Los equipos de seguridad quieren una retención más prolongada, telemetría más amplia y acceso más rápido a datos contextuales. La economía tradicional de los SIEM puede presionarlos a filtrar información antes de la ingesta o a trasladar registros antiguos a almacenamiento separado.

Esa división genera fricción operativa. Un analista que investiga un acceso sospechoso podría necesitar alertas de endpoints, historial de identidades, registros de auditoría en la nube, propiedad de activos y actividad de aplicaciones. Si esos registros se encuentran repartidos entre varios sistemas, una investigación automatizada hereda las mismas brechas.

Un lakehouse modifica el límite entre almacenamiento y análisis. Puede conservar registros estructurados junto con información menos estandarizada, al tiempo que admite SQL, Python, aprendizaje automático e intercambio de datos gobernado. Databricks denomina a esta arquitectura una plataforma unificada para datos, analítica e IA.

La empresa también promociona Agent Bricks, su entorno para crear agentes de IA específicos de un dominio. En las operaciones de seguridad, un agente podría resumir alertas relacionadas, recuperar actividad histórica o ayudar a redactar lógica de detección. El agente sigue dependiendo de permisos, contexto fiable y una ruta de aprobación definida.

Esta distinción es importante. La guía no demuestra que los agentes de IA puedan reemplazar de forma segura a los analistas de seguridad. Muestra cómo Databricks quiere que las organizaciones preparen sus datos y su gobernanza para una mayor automatización.

Es una afirmación más acotada, pero también más trascendental. Si las empresas aceptan esa premisa, las decisiones de arquitectura de seguridad se acercan al equipo de plataforma de datos. La adquisición de SIEM pasa a ser, en parte, una cuestión de formatos de almacenamiento, catálogos, acceso a modelos y contexto empresarial reutilizable.

Por qué las implementaciones de Databricks y Google importan ahora

La historia de Databricks y Google importa porque la defensa con IA abarca ahora la plataforma de datos, los controles de la nube, los sistemas de identidad y los proveedores externos de modelos.

Databricks opera en Google Cloud desde que las empresas anunciaron su asociación en 2021. La asociación en la nube original destacaba la analítica integrada, el aprendizaje automático, la facturación unificada, el soporte para identidades de Google y un acceso más sencillo a los datos.

Desde entonces, las implicaciones de seguridad se han ampliado. Un workspace de Databricks puede utilizar servicios de almacenamiento, redes, identidad, cifrado y auditoría de Google Cloud. Los equipos de seguridad también pueden analizar telemetría dentro de Databricks sin tratar a la plataforma como la única fuente de protección.

La guía actual de Google Cloud describe la seguridad como una responsabilidad compartida entre Databricks, el cliente y el proveedor de nube. Ese límite es esencial cuando una organización traslada más datos de seguridad al lakehouse.

Google Cloud protege su infraestructura subyacente y proporciona controles para identidades, redes, almacenamiento y cifrado. Databricks protege su plataforma gestionada y ofrece capacidades a nivel de workspace. Los clientes siguen siendo responsables de los permisos, la clasificación de datos, el aislamiento de cargas de trabajo, el comportamiento de las aplicaciones y muchas decisiones de configuración.

Un conjunto de datos de seguridad unificado no elimina esos límites. Los hace más visibles. Las investigaciones pueden correlacionar acciones entre sistemas, pero los administradores aún deben entender qué control corresponde a cada operador.

Por ejemplo, Databricks en Google Cloud admite federación de identidades, inicio de sesión único, conectividad privada, claves gestionadas por el cliente y registros de auditoría en la nube. Estos controles pueden reducir la exposición cuando se configuran correctamente. También pueden crear puntos ciegos cuando los equipos asumen que otra parte ha cubierto el requisito.

Por tanto, la expresión databricks google puede describir varias decisiones de compra distintas. Una organización podría usar Databricks para analítica mientras mantiene Google Security Operations como su SIEM principal. Otra podría trasladar la telemetría histórica a Databricks. Una tercera podría crear detecciones directamente sobre los datos del lakehouse.

Estos diseños implican riesgos diferentes. Un almacén secundario de analítica no necesita todos los flujos de trabajo presentes en una consola de seguridad principal. Un sistema que gestiona triaje en vivo, contención automatizada y evidencia regulatoria exige garantías operativas más estrictas.

Google también está avanzando en su propia pila de seguridad y control de agentes. Su marco de identidad de agentes de 2026 incluye identidad, gestión de accesos, gateways, barreras de protección y defensa en tiempo de ejecución para software autónomo. Esto se superpone con el problema de gobernanza que Databricks aborda desde la capa de datos.

La superposición crea tanto cooperación como competencia. Databricks se beneficia de la infraestructura de Google Cloud y puede atender a clientes que ya han invertido en identidades y almacenamiento de Google. Sin embargo, Google también vende una plataforma de operaciones de seguridad que compite por la telemetría, la atención de los analistas y las cargas de trabajo de automatización.

Esta tensión no es inusual en el software de nube. Las plataformas se integran con frecuencia en la capa de infraestructura mientras compiten en niveles superiores de la pila de aplicaciones. Los compradores deberían evaluar qué sistema se convierte en la fuente autorizada para detecciones, casos, aprobaciones de respuesta y retención de evidencias.

La arquitectura también afecta a la portabilidad. Databricks destaca los formatos de datos abiertos y la operación multinube. Google Cloud enfatiza los servicios integrados y los controles nativos de la nube. Las empresas pueden valorar ambos, pero esos objetivos no siempre conducen al mismo diseño.

Un formato de almacenamiento abierto puede facilitar la reutilización de los registros de seguridad. No hace automáticamente portátiles las reglas de detección, los flujos de trabajo de incidentes o los playbooks de automatización. Estos activos de nivel superior suelen depender de esquemas y API propietarios.

Esto deja a los líderes de seguridad ante una pregunta más precisa. No están eligiendo entre apertura e integración en abstracto. Están decidiendo dónde aceptar especialización, dónde exigir portabilidad y dónde la gobernanza debe mantenerse coherente.

La verdadera competencia es la capa de datos frente a la suite SIEM

Databricks apuesta por que el control de los datos de seguridad importará más que la propiedad de la consola tradicional de analistas.

Un SIEM convencional combina ingesta, normalización, búsqueda, detección, alertas, investigación y generación de informes. Su valor proviene de integrar esas funciones en un único flujo de trabajo centrado en la seguridad. Su debilidad aparece cuando el volumen de datos crece más rápido que los presupuestos o la capacidad operativa.

Databricks aborda el problema desde la dirección opuesta. Parte del almacenamiento de datos escalable, herramientas de procesamiento abiertas, gobernanza centralizada y aprendizaje automático. Las funciones de seguridad se construyen después sobre esa base.

Este modelo puede ayudar a los equipos a conservar telemetría sin procesar para investigaciones posteriores. También permite unir registros de seguridad con contexto empresarial. Un inicio de sesión inusual resulta más útil cuando los analistas pueden conectarlo con el rol de un empleado, un dispositivo gestionado, el propietario de una aplicación y cambios recientes de acceso.

La defensa impulsada por IA se beneficia de ese contexto. Un modelo que recibe únicamente el título de una alerta y unos pocos campos de eventos dispone de evidencia limitada. Un agente gobernado que puede recuperar historial autorizado tiene más posibilidades de producir un resumen útil.

Más datos no garantizan una mejor respuesta. Una normalización deficiente puede generar identidades contradictorias, eventos duplicados y cronologías engañosas. Los equipos de seguridad aún deben mantener esquemas, controles de calidad, linaje y lógica de detección.

Aquí es donde los proveedores de SIEM conservan una ventaja. Proporcionan contenido específico de seguridad, interfaces de investigación consolidadas, conectores, gestión de casos e integraciones de respuesta. Muchos clientes prefieren estas capacidades empaquetadas antes que ensamblarlas en una plataforma de datos de propósito general.

Google Security Operations ofrece analítica de seguridad a escala de nube e inteligencia de amenazas dentro de un entorno operativo dedicado. Microsoft conecta Sentinel con sus productos de identidad, endpoints, productividad y nube. CrowdStrike está ampliando los datos de endpoints y amenazas hacia una plataforma de seguridad basada en agentes.

Splunk aporta una gran base instalada, amplias integraciones y años de contenido de detección. Palo Alto Networks y otros proveedores de seguridad también están consolidando datos y automatización. Databricks entra en un mercado donde los compradores ya se enfrentan a afirmaciones de plataformas que se solapan.

La posición más sólida de Databricks no es el reemplazo inmediato. Es la ventaja arquitectónica. Las organizaciones pueden usar el lakehouse para reducir la duplicación de telemetría, conservar más historial, enriquecer las investigaciones y probar flujos de trabajo asistidos por IA sin trasladar todos los procesos operativos de una vez.

Un enfoque por fases también facilita medir el rendimiento. Los equipos pueden empezar por optimizar el coste de los registros o realizar búsquedas históricas de amenazas. Pueden comparar la velocidad de las consultas, la cobertura de detección, el esfuerzo de ingeniería y el gasto operativo total con el sistema existente.

La siguiente fase podría trasladar detecciones seleccionadas a Databricks. Los ingenieros de seguridad pueden gestionar la lógica mediante prácticas de desarrollo conocidas, incluido el control de versiones y las pruebas. Las alertas pueden seguir fluyendo hacia un sistema consolidado de gestión de casos.

Un reemplazo completo exige más pruebas. Un SIEM principal debe admitir una ingesta fiable, detección de baja latencia, continuidad en las investigaciones, requisitos de auditoría y coordinación de respuestas. También debe seguir siendo utilizable durante incidentes que afecten a otros sistemas empresariales.

Databricks presenta Lakewatch como un SIEM abierto y basado en agentes construido sobre la plataforma de la empresa. La dirección del producto deja más clara la intención competitiva. Databricks quiere pasar de respaldar el análisis de seguridad a controlar una parte mayor del flujo de trabajo operativo.

Ese cambio presiona a los proveedores tradicionales en materia de costes de retención y acceso a los datos. También presiona a Databricks para cumplir expectativas específicas de seguridad. La fiabilidad de una plataforma de datos es necesaria, pero un sistema operativo de defensa conlleva responsabilidades adicionales.

La capacidad de negociación del comprador proviene de separar las afirmaciones en capas verificables. La economía del almacenamiento puede evaluarse independientemente de la calidad de detección. La productividad de los agentes puede evaluarse por separado de la seguridad de la respuesta. La portabilidad puede probarse en los niveles de datos, consultas, reglas y flujos de trabajo.

Los responsables de seguridad también deberían controlar el trabajo oculto. Una plataforma puede reducir la presión de las licencias mientras aumenta el trabajo de ingeniería. El mantenimiento de esquemas, el desarrollo de conectores, el ajuste de detecciones, los permisos y el soporte de guardia deben formar parte de la comparación.

Por eso la propuesta de Databricks es más relevante que otro anuncio de funciones de IA. Reabre la frontera entre la infraestructura de datos empresariales y el centro de operaciones de seguridad. Esa frontera ha moldeado durante años los presupuestos y flujos de trabajo de seguridad.

La defensa impulsada por IA hereda un problema de gobernanza de IA

Los mismos agentes que acortan las investigaciones también pueden acelerar errores, accesos no autorizados y respuestas con supervisión deficiente.

Databricks presenta la gobernanza como parte de la arquitectura, en lugar de como un paso de cumplimiento independiente. Unity Catalog controla el acceso a los datos y los activos de IA. Unity AI Gateway gestiona el tráfico hacia modelos y servicios de herramientas.

La guía de gobernanza de IA de la empresa indica que la puerta de enlace puede enrutar solicitudes de modelos y de Model Context Protocol. También puede aplicar límites, ejecutar políticas y registrar el uso entre distintos proveedores.

Model Context Protocol, o MCP, es un estándar que permite a las aplicaciones de IA conectarse a herramientas y fuentes de datos. En un entorno de seguridad, un servicio MCP podría exponer inteligencia de amenazas, funciones de gestión de tickets, registros de activos o herramientas de respuesta aprobadas.

El control centralizado ofrece una ventaja práctica. Una organización puede gobernar un modelo externo, un agente de programación o un servicio MCP a través de la misma capa de acceso que utiliza para otros activos de datos. Databricks afirma que esto puede incluir modelos de Google, Anthropic y OpenAI.

Algunas capacidades siguen en beta. Databricks describe políticas de servicio que pueden permitir, denegar o requerir aprobación para solicitudes según su contenido. El estado de vista previa es importante cuando se espera que esas políticas eviten la exposición de datos sensibles o el uso peligroso de herramientas.

Ningún responsable de seguridad debería tratar una protección beta como la única barrera para proteger una acción de respuesta en producción. La defensa requiere controles superpuestos. Las restricciones de identidad, las herramientas con alcance limitado, las puertas de aprobación, los registros, los límites de velocidad y las acciones reversibles deberían reforzarse mutuamente.

La revisión humana también necesita una definición precisa. Exigir que un analista apruebe cada sugerencia puede preservar el control, pero podría recrear la cola que se suponía que la automatización debía reducir. Permitir una autonomía amplia puede mejorar la velocidad mientras aumenta el impacto de una decisión errónea.

Un diseño práctico divide las acciones por consecuencia. La recuperación de información de solo lectura implica menos riesgo que desactivar una cuenta. Redactar una regla de detección es distinto de desplegarla. Poner en cuarentena un único endpoint es distinto de cambiar una política para toda la red.

Cada categoría necesita su propio límite de autorización. Las acciones reversibles y de alta confianza pueden recibir más automatización. Las acciones ambiguas o de alto impacto deberían requerir evidencia adicional y aprobación explícita.

La exposición de datos genera otra preocupación. Un agente de investigación suele necesitar actividad de usuarios, detalles de dispositivos, registros de aplicaciones y contexto organizativo. Esa combinación puede revelar información personal o empresarial sensible, incluso cuando cada fuente parece inocua por separado.

Databricks afirma en su documentación sobre confianza en IA que los proveedores de modelos asociados no almacenan prompts ni respuestas. También indica que los permisos de Unity Catalog regulan qué datos pueden enviar sus funciones de IA.

La documentación reconoce que los modelos pueden alucinar o producir respuestas incorrectas. Esa advertencia es especialmente importante en seguridad, donde un resumen fluido pero inexacto puede desviar una investigación o implicar erróneamente a un usuario.

La recuperación consciente de permisos reduce el acceso no autorizado. No demuestra precisión factual. Los equipos necesitan evaluaciones basadas en patrones reales de incidentes, entradas adversarias, telemetría incompleta y pruebas contradictorias.

La inyección de prompts añade otro riesgo. Un atacante podría introducir texto malicioso en un ticket, campo de registro, repositorio o documento que un agente recupere posteriormente. Si el sistema trata ese contenido como una instrucción, el flujo de trabajo de investigación puede ser manipulado.

Las políticas de gobernanza pueden filtrar algunos ataques, pero una defensa fiable también depende de la separación arquitectónica. Los datos recuperados deben seguir considerándose no confiables. Las herramientas deben aplicar la autorización fuera del modelo. Las acciones sensibles no deberían depender únicamente de una decisión generada.

La auditabilidad se convierte en la prueba final. Los equipos necesitan registros que muestren a qué datos accedió un agente, qué modelo los procesó, qué herramientas se llamaron y quién aprobó el resultado. Sin esa cadena, la revisión de incidentes y la evidencia regulatoria se vuelven difíciles.

Esto también es relevante para el trabajo de conocimiento fuera del centro de operaciones de seguridad. Los equipos que usan una base de conocimiento de IA se enfrentan a preguntas similares sobre permisos, calidad de las fuentes y trazabilidad. La seguridad eleva las consecuencias, pero el principio de gobernanza sigue siendo el mismo.

Databricks ha reunido componentes creíbles para este problema. La empresa no ha demostrado que cada cliente pueda combinarlos para crear una defensa autónoma segura. Ese resultado depende de la disciplina de implementación, la medición y la responsabilidad operativa.

Tres señales mostrarán si la estrategia funciona

La próxima prueba no es otra demostración de IA; es evidencia de que Databricks puede mejorar la defensa sin trasladar los costes y riesgos a otra parte.

La primera señal es un rendimiento de clientes comprensible de forma independiente. Databricks necesita más casos de estudio que definan la referencia inicial, la carga de trabajo, el alcance del despliegue y el período de medición. Un porcentaje sin esos detalles atrae atención, pero ofrece una orientación limitada.

Los responsables de seguridad deberían buscar cobertura de detección, tiempo medio de investigación, tasas de falsos positivos, profundidad de retención y esfuerzo total de ingeniería. Las afirmaciones de costes deberían incluir el trabajo de migración, el mantenimiento de conectores, la infraestructura y la dotación de personal.

Si los clientes mantienen una telemetría más amplia y al mismo tiempo reducen tanto el tiempo de investigación como el gasto operativo, Databricks tendrá un caso más sólido. Si los ahorros dependen de una ingeniería personalizada sustancial, el argumento resulta menos convincente para equipos más pequeños.

La segunda señal es la madurez de las operaciones de agentes gobernadas. Las políticas de servicio, los controles de aprobación, las restricciones de herramientas y los registros de auditoría deben ir más allá de las demostraciones. Los compradores necesitan un comportamiento documentado ante fallos, ataques y evidencia ambigua.

Una validación útil mostraría a un agente encontrando contenido recuperado malicioso sin seguirlo. Otra mostraría una acción de respuesta bloqueada porque la identidad solicitante carecía de permiso. Los equipos también necesitan procedimientos claros de reversión y revisión de incidentes.

Si estos controles pasan a estar disponibles de forma general y superan pruebas adversarias, se refuerza la tesis de defensa impulsada por IA. Si las salvaguardas críticas siguen siendo vistas previas o requieren un trabajo personalizado extenso, la autonomía debería mantenerse estrictamente limitada.

La tercera señal es la respuesta competitiva. Google, Microsoft, Splunk, CrowdStrike y Palo Alto Networks ya controlan flujos de trabajo de seguridad importantes. Pueden ajustar modelos de retención, abrir el acceso a los datos, ampliar la gobernanza de agentes o profundizar las integraciones en la nube.

Google merece especial atención porque es tanto un socio de infraestructura como un competidor de plataformas de seguridad. Un cliente de databricks google puede combinar sus servicios, pero los planos de control superpuestos pueden generar una propiedad poco clara.

Una interoperabilidad más estrecha respaldaría a Databricks. Los datos de seguridad podrían seguir siendo portables mientras las alertas, los casos, la inteligencia de amenazas y las acciones de respuesta se mueven a través de interfaces definidas. Los compradores obtendrían capacidad de elección arquitectónica sin reconstruir cada flujo de trabajo.

Una agrupación más estricta de plataformas podría debilitar el caso. Si los proveedores consolidados combinan una economía de almacenamiento aceptable con agentes de seguridad maduros, los clientes podrían preferir una única suite operativa. Durante los incidentes, la comodidad y la responsabilidad suelen importar más que la elegancia arquitectónica.

Los responsables de seguridad no necesitan elegir una arquitectura final de inmediato. Pueden probar el modelo de Databricks frente a una carga de trabajo cara o fragmentada. La búsqueda histórica de amenazas, el análisis de auditoría en la nube y el desarrollo de detecciones ofrecen puntos de partida acotados.

El piloto debería preservar el flujo de trabajo existente y, al mismo tiempo, generar mediciones comparables. Los equipos deberían definir el éxito antes de mover datos. También deberían registrar el trabajo necesario para normalizar la telemetría y mantener fiables las detecciones.

Una revisión útil plantea cinco preguntas. ¿El nuevo sistema conservó más datos relevantes? ¿Los analistas investigaron más rápido? ¿Mejoraron las detecciones? ¿Disminuyó el esfuerzo operativo total? ¿La gobernanza siguió siendo comprensible?

Las respuestas mostrarán si el lakehouse se está convirtiendo en una capa operativa de seguridad o simplemente en otro destino para los registros. También separarán el valor de la IA del valor del almacenamiento, que los proveedores suelen presentar juntos.

Databricks ha identificado una limitación real. Los agentes no pueden compensar datos de seguridad fragmentados, inaccesibles o mal gobernados. Su guía ofrece a los responsables de seguridad una razón para reconsiderar dónde residen esos datos y quién los controla.

La cuestión sin resolver es la confianza operativa. ¿Puede una empresa de plataformas de datos ofrecer la fiabilidad, el contenido de seguridad, los controles de respuesta y la responsabilidad que se esperan de un sistema de defensa de primera línea?

Para los equipos que evalúan una arquitectura databricks google, el siguiente paso es una comparación mesurada, no un reemplazo inmediato. Elijan un flujo de trabajo de investigación, definan sus permisos y registren los resultados de referencia. Después, prueben si el contexto unificado mejora las decisiones sin ampliar el acceso ni aumentar el trabajo oculto. Esa evidencia importará más que la cantidad de agentes en una demostración de producto.