Español

Snowflake Compró Natoma. Microsoft Lanzó Agent 365. Anthropic Abrió Túneles MCP. Este Es el Patrón para el Roadmap de Gobernanza de Agentes

Diagrama de tres control planes MCP de Snowflake, Microsoft y Anthropic compitiendo por el roadmap de gobernanza de agentes del CTO

Tres grandes proveedores empresariales se han movido en la gobernanza del Model Context Protocol (MCP) en 30 días. La pregunta para el CTO no es cuál ganará. Es si usted reconoce el patrón antes de que llegue su próximo ciclo de renovación.

Qué Compró Realmente Snowflake

El 27 de mayo de 2026, Snowflake anunció un acuerdo definitivo para adquirir Natoma, una plataforma de gobernanza MCP empresarial construida específicamente para agentes de AI. Según el comunicado de prensa de Snowflake, la operación añade tres capacidades al stack de Snowflake: un registro verificado de servidores MCP, una capa de identidad y un plano de políticas de acceso.

Lo que eso significa en la práctica: los Cortex Agents, Snowflake Intelligence y Cortex Code de Snowflake pueden ahora acceder a apps SaaS empresariales, bases de datos, APIs, nubes privadas virtuales (VPCs) y sistemas on-premises a través de una única superficie de gobernanza. Las plataformas de AI de terceros obtienen el mismo acceso. Cada acción de un agente es auditable, cada conexión está controlada por políticas y cada servidor MCP debe pasar por el registro antes de que un agente pueda usarlo.

El blog técnico de Snowflake enmarca la motivación con claridad: la adopción de MCP ha introducido gobernanza fragmentada, actividad de shadow AI y riesgo de exfiltración de datos a medida que los agentes se multiplican en los sistemas empresariales. Natoma convierte el data warehouse en el tejido de gobernanza, no solo en el almacén de datos. La cobertura de CIO calificó la operación como una apuesta a que la gravedad de los datos atrae las decisiones de gobernanza hacia donde ya reside su data warehouse.

Datos Clave

  • Snowflake anunció su intención de adquirir Natoma el 27 de mayo de 2026, añadiendo un registro verificado de servidores MCP, una capa de identidad y un plano de políticas de acceso a su stack (comunicado de prensa de Snowflake, 2026).
  • La operación de Natoma es el tercer gran movimiento de gobernanza MCP en una ventana de 30 días: Anthropic lanzó sandboxes auto-hospedados y túneles MCP el 19 de mayo, Microsoft posicionó Agent 365 como el control plane de AI el 28-29 de mayo, y Snowflake cerró la ventana el 27 de mayo.
  • Tres capas de plataforma distintas compiten ahora por ser propietarias del control plane de agentes: la capa de datos (Snowflake), la capa de productividad (Microsoft) y la capa de modelos (Anthropic).

El Patrón de Adquisición MCP Que la Mayoría de los CTOs Aún No Están Nombrando

Diagrama de las tres capas del control plane MCP con Snowflake más Natoma destacando la capa de datos

La trampa no es elegir al proveedor equivocado. La trampa es tratar cada uno de estos movimientos como un anuncio de producto aislado en lugar de verlos como un único patrón que se despliega en secuencia.

El patrón es este: todos los grandes proveedores de plataformas empresariales están compitiendo por ser propietarios del control plane de MCP, no porque MCP sea técnicamente maduro, sino porque quien establezca la propiedad de la gobernanza ahora definirá las reglas de compras durante los próximos cinco años de adquisición empresarial de agentes.

Los tres actores representan tres apuestas estructuralmente distintas sobre qué capa se gana el derecho de ser el ancla de gobernanza.

Capa de datos (Snowflake más Natoma). La apuesta aquí es que la gravedad de los datos gana. Las empresas ya concentran datos sensibles en su warehouse. Si la gobernanza sigue a los datos, el operador del warehouse se convierte en el aplicador natural de políticas para cada agente que toca esos datos. El registro, la capa de identidad y el plano de políticas de Natoma caen directamente en ese campo gravitacional.

Capa de productividad (Microsoft a través de Agent 365). La apuesta de Microsoft, anunciada a finales de mayo a través de Agent 365, es que la capa de flujo de trabajo empresarial posee la gobernanza porque los agentes derivan su valor de los flujos de trabajo. Si los agentes viven en Microsoft 365, Teams y Copilot Studio, entonces el tejido de identidad y políticas ya entretejido en Entra ID y Azure es el hogar natural para el control de agentes. La suite de productividad ya sabe quién es el usuario, qué está autorizado a hacer y a qué sistemas puede acceder.

Capa de modelos (Anthropic a través de sandboxes auto-hospedados y túneles MCP). El movimiento de Anthropic, lanzado el 19 de mayo, es un argumento diferente: ejecutar el entorno de ejecución del agente dentro del perímetro de seguridad del cliente. Los sandboxes auto-hospedados y los túneles MCP de Anthropic permiten a los agentes empresariales acceder a sistemas privados a través de una única puerta de enlace de salida, sin exposición de firewall entrante. El proveedor del modelo se convierte en el ancla de confianza porque controla dónde ocurre el razonamiento y cómo se accede a los sistemas privados.

Ninguna de estas apuestas es incorrecta. Las tres son coherentes. Pero no son compatibles como única capa de gobernanza, y los tres proveedores presentan la suya exactamente como eso.

El CTO que se comprometa con el control plane de una sola capa antes de que el patrón se estabilice arriesga construir una arquitectura de gobernanza que funciona hasta que un ciclo de renovación crea un momento de dependencia que no vio venir.

Por Qué el Argumento de la Capa de Datos Es Diferente

El argumento de Snowflake merece un análisis propio porque es estructuralmente distinto al de los otros dos.

El argumento de la capa de productividad (Microsoft) y el de la capa de modelos (Anthropic) se basan ambos en efectos de red a través de las relaciones de software existentes. El apalancamiento de Microsoft es que sus empleados ya viven en Teams y Outlook. El de Anthropic es que sus desarrolladores ya construyen con Claude. Ambos argumentos dicen: ya nos confía X, ahora extienda esa confianza a la gobernanza de agentes.

El argumento de Snowflake es diferente. Dice: su gobernanza debería seguir a sus datos porque sus datos no se mueven. Los registros empresariales sensibles residen en el warehouse. Los requisitos de cumplimiento normativo ya están ligados al warehouse. Los controles de seguridad ya envuelven el warehouse. El registro y el plano de políticas de Natoma no le piden que extienda confianza a una nueva superficie. La adjuntan a una superficie que ya es de confianza.

Ese argumento es estructuralmente más sólido de lo que puede parecer en un briefing de producto. No requiere que usted crea que Snowflake es la mejor empresa de AI. Solo requiere que crea que la gravedad de los datos es real y que su equipo de cumplimiento siempre preguntará "¿dónde viven los datos?" antes de aprobar cualquier acción de un agente.

Pero no confunda "estructuralmente coherente" con "estratégicamente seguro". Aceptar el argumento de gobernanza en la capa de datos de Snowflake implica aceptar a Snowflake como el punto de aplicación de políticas para cada agente en su stack, incluidos los agentes construidos sobre infraestructura no perteneciente a Snowflake. Eso es una centralización arquitectónica significativa, independientemente de lo limpio que sea el argumento.

Para un framework sobre cómo evaluar el riesgo de dependencia del proveedor en la capa de gobernanza, el artículo sobre soberanía de AI y dependencia del proveedor cubre el patrón de dependencia con más detalle.

La Prueba de 4 Preguntas para Cualquier Control Plane MCP

Antes de comprometerse con el enfoque de gobernanza MCP de cualquier proveedor, ya sea la adquisición de Natoma por Snowflake, Agent 365 de Microsoft o la arquitectura de sandboxes de Anthropic, aplique estas cuatro preguntas.

1. Registro verificado de servidores MCP: ¿quién garantiza que un servidor MCP es seguro de instalar? Un control plane de MCP necesita una lista firmada y gestionada centralmente de servidores aprobados. Pregunte a cada proveedor: ¿cuál es el proceso para incluir un servidor en el registro? ¿Quién lo audita? ¿Qué sucede cuando un servidor registrado se ve comprometido? La respuesta le dice si el registro es un mecanismo de seguridad real o un elemento de verificación del producto.

2. Modelo de identidad: ¿el agente hereda la identidad del usuario, su propia identidad de servicio o ambas? Esta pregunta tiene consecuencias significativas a largo plazo. Si el agente hereda la identidad del usuario, tiene acceso a nivel de usuario a todos los sistemas a los que ese usuario puede acceder. Si usa su propia identidad de servicio, necesita un modelo de permisos separado. Si usa ambas (identidad delegada para algunas acciones, identidad de servicio para otras), necesita claridad sobre exactamente qué acciones usan qué modelo. Las respuestas ambiguas aquí son un riesgo de gobernanza, no una brecha de producto.

3. Motor de políticas: ¿dónde se evalúa realmente "el agente X puede realizar la acción Y en el sistema Z"? El motor de políticas es la lógica en tiempo de ejecución que determina qué está autorizado a hacer un agente en un contexto dado. Debe ser centralizado (para evitar la fragmentación de políticas entre sistemas), auditable (para poder reconstruir decisiones) y suficientemente rápido para no introducir latencia que haga inutilizables los agentes. Pregunte a los proveedores dónde se ejecuta el motor de políticas, cómo se actualiza y si la evaluación de políticas es síncrona o en caché.

4. Registro de auditoría: ¿puede reconstruir exactamente qué agente hizo qué, sobre qué registro, en nombre de quién? "Registro de auditoría" no es lo mismo que "logs". Un registro de auditoría responde preguntas de causalidad: ¿por qué realizó el agente esta llamada a la API, qué datos recuperó, qué autorización utilizó y qué cambió como resultado? Si la historia de auditoría de un proveedor es "obtienes logs del servidor", esa es una respuesta diferente a "obtienes un flujo de eventos estructurado con vinculación causal a la acción del usuario original". Sepa cuál de las dos está comprando. El recurso sobre registros de auditoría para acciones ejecutadas por AI cubre cómo es una arquitectura de auditoría lista para producción.

Para el framework de evaluación más amplio, la orientación sobre compuertas de aprobación de AI y revisión de proveedores es un complemento útil.

Preguntas Frecuentes

¿Qué es la adquisición de Natoma por parte de Snowflake?

Natoma es una plataforma de gobernanza MCP empresarial que añade un registro verificado de servidores, una capa de identidad y un plano de políticas de acceso a los despliegues de agentes de AI. Snowflake anunció su intención de adquirir Natoma el 27 de mayo de 2026. La operación le da a Snowflake un tejido de gobernanza que permite que Cortex Agents y plataformas de AI de terceros se conecten a sistemas empresariales a través de una única superficie de control auditable, sin requerir que los agentes eviten los controles de seguridad existentes del data warehouse.

¿Por qué los control planes de MCP se han convertido repentinamente en el campo de batalla de compras en 2026?

MCP, el Model Context Protocol, es el estándar emergente para cómo los agentes de AI se conectan a herramientas y fuentes de datos externas. A medida que la adopción de agentes empresariales se acelera, quien controla la capa de políticas que rige qué agentes pueden conectarse a qué sistemas obtiene un apalancamiento significativo en las compras. Tres grandes proveedores (Snowflake, Microsoft, Anthropic) han realizado movimientos distintos en la gobernanza de MCP en 30 días. La carrera no es sobre si MCP es maduro. Es sobre establecer la propiedad de la gobernanza ahora, mientras el estándar se está formando y las empresas aún no se han comprometido con una arquitectura.

¿Cómo deberían los CTOs evitar quedar atrapados en la capa de MCP de un único proveedor?

El primer movimiento es escribir su propio rubric de evaluación del control plane de MCP usando las cuatro preguntas anteriores antes de evaluar a ningún proveedor. Eso le da criterios neutrales respecto al proveedor. El segundo movimiento es inventariar qué agentes en su organización usan actualmente MCP y qué superficie de control ya tocan. Si la mayoría de sus agentes conectados a MCP se ejecutan a través de Microsoft 365, ya está parcialmente en el campo de la capa de productividad aunque no haya tenido esa intención. Hacer eso visible le permite tomar una decisión arquitectónica intencionada en lugar de heredar una por adopción de productos.

Qué Deben Hacer los CTOs Este Mes

Cuatro acciones concretas que cuestan menos que un ciclo completo de evaluación de proveedor pero establecen la postura de gobernanza que necesita:

  • Escriba un rubric de evaluación del control plane de MCP de una página. Use la prueba de cuatro preguntas anterior. Una página obliga a priorizar. Compártalo con sus equipos de seguridad y compras antes de que cualquier proveedor haga una presentación. De esa manera, evaluará las propuestas de los proveedores según sus criterios, no los de ellos.

  • Inventaríe qué agentes usan actualmente MCP y qué superficie de control tocan. Esto no requiere una auditoría completa. Pregunte a sus responsables de ingeniería: qué agentes están en ejecución, cuáles usan conexiones MCP y qué capa de identidad o políticas del proveedor gestiona esas conexiones hoy. La respuesta probablemente le sorprenderá.

  • Programe una conversación de 30 minutos con cada uno de los tres proveedores antes de su próximo ciclo de renovación. No una demo del producto. Una conversación sobre la arquitectura de gobernanza. Lleve las cuatro preguntas. Hágalas de forma específica. La capacidad del proveedor para responder con claridad, no solo con fluidez, le dice mucho sobre la madurez real de su historia de control plane.

  • Mapee sus agentes al framework de clasificación de datos. Antes de que se autorice cualquier conexión MCP en producción, el agente debe saber a qué nivel de clasificación de datos está accediendo. El recurso sobre clasificación de datos para acceso de AI cubre cómo construir ese mapeo. Sin él, las evaluaciones del control plane anteriores son decisiones de política sin superficie de aplicación.

El patrón se mueve rápido. Pero la respuesta correcta no es elegir al primer proveedor que parezca creíble. Es establecer su propio framework de evaluación mientras las tres opciones siguen siendo genuinamente accesibles.

Más Información