Resumen

  • Prosimo se fundó en 2019 y recaudó al menos 55 millones de dólares en una Serie A en 2021 y una Serie B en 2022. Las ventas auditadas, la valoración y el precio de adquisición no se han hecho públicos.
  • AXI combinaba una capa central de intención, topología y análisis con bordes distribuidos para descubrir activos cloud, conectar aplicaciones, insertar seguridad y recopilar telemetría, sin poseer una red troncal física.
  • Tras anunciar la integración con VM-Series en junio de 2024, Prosimo pasó a estar bajo el paraguas de Palo Alto Networks alrededor de febrero de 2025, aunque la fecha exacta de adquisición, el precio y la correspondencia con los productos actuales no están claros.
  • El control está distribuido entre la empresa, el software de orquestación, los proveedores de nube y Palo Alto Networks. La capacidad de migrar topología, credenciales, políticas y autoridad de enrutamiento es una decisión clave para los clientes.

La independencia empresarial se perdió, pero las preguntas permanecen

No sería exacto presentar a Prosimo en 2026 como un proveedor independiente en activo. Los historiales profesionales públicos muestran que los fundadores y varios empleados se trasladaron a Palo Alto Networks en torno a febrero de 2025. La página de empresa de Prosimo indica que fue adquirida, y su antiguo CTO, Nehal Bhau, declaró posteriormente que la tecnología se había integrado en los productos de Palo Alto Networks. Estas pruebas confirman un cambio de control y la continuidad del valor técnico, pero no revelan la fecha de firma, la fecha de cierre, la forma jurídica ni el precio.

Esta corrección debe figurar al principio porque cambia el tiempo verbal de cada descripción de producto. AXI, Network Transit, App Transit, Application-driven Intelligent Results y Nebula están documentados como capacidades de Prosimo durante su etapa independiente. A menos que Palo Alto Networks publique una tabla de correspondencia de productos y soporte actuales, no deberían redactarse como productos actuales disponibles por separado. La arquitectura anterior puede subsistir como código integrado, servicios compartidos, módulos o activos de ingeniería interna tras la adquisición, pero no en la misma forma.

La desaparición de la marca no elimina los problemas subyacentes. Las empresas siguen distribuyendo cargas de trabajo entre Amazon Web Services, Microsoft Azure, Google Cloud, centros de datos privados, instalaciones de colocación, SaaS y usuarios remotos. Cada entorno tiene sus propias rutas, puertas de enlace, puntos de enlace privados, controles de identidad, servicios de seguridad, límites y reglas de facturación. Las empresas pueden ser propietarias de las cuentas sin tener una visión unificada de cómo se mueve una solicitud entre entornos.

Prosimo fue relevante porque intentó capturar y controlar ese panorama completo en una sola capa operativa.

Por lo tanto, la adquisición no es una nota a pie de página, sino el eje de todo el artículo. Prosimo construyó una capa de control multicloud que podía descubrir activos, interpretar el contexto de las aplicaciones y dirigir el tráfico hacia los servicios de seguridad. Palo Alto Networks apareció primero como socio tecnológico, insertando firewalls VM-Series en esas rutas. Luego se convirtió en el propietario de la tecnología. La frontera entre la orquestación de enrutamiento y la inspección profunda se trasladó al interior de una plataforma de ciberseguridad.

El enrutamiento multicloud es una competencia por el contexto

Una tabla de enrutamiento puede indicar si un prefijo es alcanzable a través de un siguiente salto diferente. Pero no explica a qué aplicación intentaba acceder el usuario, si se puede confiar en el solicitante, si necesita pasar por un servicio de inspección, si hay un punto de enlace privado disponible, qué ruta cloud es costosa o si la transacción falla después de que llegue el paquete. Las operaciones multicloud agrupan todo esto en un solo problema de control.

La premisa de Prosimo era que la autoridad de enrutamiento no debería decidirse solo por la alcanzabilidad de Capa 3. Su software trataba de combinar el inventario de activos cloud, el estado de la red, la identidad de las aplicaciones, la identidad de los usuarios, el riesgo, el rendimiento y la telemetría de transacciones. Esto permitía expresar políticas como conectar una aplicación específica, aislar un segmento, elegir un punto de entrada o enviar tráfico seleccionado a través de un firewall. El valor no residía en inventar nuevas rutas de fibra óptica, sino en decidir cómo combinar las rutas y servicios existentes.

Esta diferencia explica por qué la empresa utilizó el término «infraestructura de experiencia de aplicaciones». El centro de gestión no eran los elementos de red individuales, sino las solicitudes de las aplicaciones. Las VPC, VNet, subredes, hubs de tránsito y enlaces privados se convertían en componentes de una ruta de extremo a extremo, no en las unidades finales a gestionar. Con este planteamiento, los productos incursionaban simultáneamente en varios mercados: redes cloud, entrega de aplicaciones, acceso de confianza cero, aseguramiento de red, optimización de costes e inserción de servicios de seguridad.

El amplio alcance generaba tanto oportunidades como ambigüedad. Un producto que abarca varios equipos puede resolver la descoordinación que nadie aborda por sí solo. Sin embargo, es difícil de evaluar porque los equipos de red, seguridad, cloud, aplicaciones y finanzas definen el éxito de manera diferente. Prosimo necesitaba demostrar que su modelo multicloud mejoraba las operaciones sin convertirse en una nueva capa privilegiada cuyos errores se propagaran a todos los entornos.

Qué fue Prosimo y qué queda

Prosimo era una empresa privada de software de redes cloud fundada en 2019, con sede en el Área de la Bahía de San Francisco. Durante su etapa independiente, Ramesh Prabagaran fue cofundador y CEO, y Nehal Bhau cofundador y CTO. Los historiales profesionales públicos también mencionan a Linus Aranha y Pradeep Aragonda en funciones fundacionales o de ingeniería sénior, pero sus títulos exactos deben cotejarse con fuentes fechadas.

La plataforma principal era Application eXperience Infrastructure, conocida como AXI. AXI combinaba una capa de software central para la intención, la topología, el análisis y la orquestación con bordes AXI distribuidos desplegados en regiones cloud, entornos de colocación o infraestructura local adyacente. Más tarde, la oferta se organizó como Full-Stack Cloud Transit, donde Network Transit y App Transit gestionaban diferentes tipos de conectividad. AIR analizaba la telemetría para ofrecer recomendaciones operativas, y en 2024 Nebula añadió una interfaz conversacional.

Prosimo no era un operador de cloud. No poseía una red troncal de fibra óptica global que conectara todas las regiones. Las rutas podían atravesar las redes troncales de los proveedores de nube, la internet pública, circuitos privados, conexiones de colocación y redes empresariales. Tampoco era un fabricante de firewalls en el sentido en que lo es Palo Alto Networks. En la integración de 2024, el papel de Prosimo era descubrir, segmentar y dirigir, mientras que la inspección de seguridad profunda recaía en VM-Series.

Tras la adquisición, la expresión más segura es «linaje técnico». Las declaraciones posteriores sobre la integración destacaron el descubrimiento de activos multicloud y la aceleración del despliegue de firewalls de software para inspección de entrada, salida y este-oeste. Esto confirma que componentes importantes de Prosimo sobrevivieron. Pero no demuestra que la antigua familia de productos AXI, los paquetes comerciales y el modelo de soporte al cliente continúen sin cambios.

El problema que surgió después de SD-WAN

El equipo fundador aportaba experiencia en redes a gran escala, entrega de aplicaciones e infraestructura cloud. Prosimo también surgió de la amplia red de fundadores e ingenieros vinculados a Viptela, que desempeñó un papel relevante en establecer SD-WAN como segmento del mercado empresarial. Pero el siguiente problema era diferente. SD-WAN podía simplificar la conectividad desde las sucursales hacia las redes y aplicaciones, pero no creaba un modelo operativo único dentro y entre múltiples nubes públicas.

Las aplicaciones multicloud pueden depender de un punto de enlace web en un entorno, de una base de datos o servicios gestionados en otro, de proveedores de identidad externos a ambos, de conexiones privadas a centros de datos y de inspección de seguridad en perímetros seleccionados. Cada dependencia se representa mediante elementos nativos diferentes. Los equipos de redes ven prefijos y hubs de tránsito; los equipos de cloud ven cuentas y objetos de recursos; los propietarios de aplicaciones ven dominios y transacciones; los equipos de seguridad ven zonas y políticas de inspección.

Prosimo empezó a pensar desde la solicitud, no desde la sucursal. La pregunta era cómo un usuario o carga de trabajo podía alcanzar una aplicación con garantías suficientes de seguridad, rendimiento, disponibilidad y coste. Este marco ampliaba el objeto de enrutamiento desde un simple prefijo de destino hasta una transacción con identidad y contexto de aplicación. A cambio, exigía recopilar y mantener mucha más información que un enrutador tradicional.

El entorno de mercado también era favorable. AWS, Azure y Google Cloud estaban ampliando sus servicios nativos de tránsito y conectividad privada. Las empresas podían construir redes sofisticadas dentro de cada nube, pero las API, los objetos y los modelos de políticas diferían entre proveedores. La oportunidad de Prosimo no era reemplazar esos elementos por una red troncal propia, sino coordinarlos entre sí.

De la fundación en 2019 al lanzamiento oficial en 2021

Prosimo se fundó en 2019, pero no anunció su lanzamiento oficial hasta el 6 de abril de 2021. La ronda Serie A de 25 millones de dólares fue liderada por General Catalyst. El inversor destacó la oportunidad de ofrecer una experiencia de aplicaciones a través de múltiples nubes, en línea con la visión del fundador de definir un espacio más allá de la conectividad tradicional de sucursales.

En el momento del lanzamiento, el mercado estaba abarrotado y con fronteras difusas. Los proveedores de nube facilitaban el uso de sus propios servicios de red. Los fabricantes de SD-WAN y SASE extendían las políticas hacia la nube, los proveedores de entrega de aplicaciones optimizaban las solicitudes y las empresas de seguridad de red podían inspeccionarlas. La fuerza de Prosimo dependía de si podía unir estas funciones en una arquitectura orientada a la nube, sin pretender reemplazar todo lo que la rodeaba.

La financiación dio margen para construir integraciones, bordes de software, análisis, una organización de ventas y relaciones con socios. Pero no demostró por sí misma el ajuste producto-mercado, el volumen de ventas ni una diferenciación sostenible. El material disponible no incluye ventas auditadas, ingresos recurrentes anuales, número de clientes ni valoración. Los registros de financiación muestran que los inversores apostaron capital por una hipótesis, no una imagen completa del rendimiento.

En 2022, Prosimo completó una Serie B de 30 millones de dólares que se describió como sobresuscrita. Sumando las dos rondas claramente identificables, la financiación total asciende al menos a 55 millones de dólares. Algunas bases de datos pueden mostrar cifras mayores por duplicación de anuncios o registros relacionados, por lo que no deben utilizarse sin verificar las transacciones originales.

AXI situaba la política por encima de las nubes y la ejecución cerca de las cargas de trabajo

La arquitectura AXI dividía las funciones entre una capa central de control y análisis y bordes de software distribuidos. La capa central mantenía la intención de aplicación y red, descubría activos, construía la topología, integraba identidades, analizaba telemetría y orquestaba cambios. Los bordes AXI se colocaban cerca de las cargas de trabajo o los usuarios, permitiendo aplicar políticas sin devolver todo el tráfico a un hub físico remoto.

Esta separación recuerda a otros sistemas definidos por software, pero su objetivo era específico de la nube y consciente de las aplicaciones. El controlador necesitaba acceso a las cuentas cloud y a las API; los bordes necesitaban conectarse a los servicios de tránsito nativos, redes de cargas de trabajo, puntos de enlace privados y rutas externas. Combinar una intención global por encima de las nubes con una ejecución local cerca del tráfico relevante otorgaba una autoridad similar a la de una infraestructura.

Al mismo tiempo, esto creaba límites de implementación. Cada borde consumía recursos cloud, requería diseño de alta disponibilidad y debía ser actualizado, supervisado y protegido. La capa de control necesitaba credenciales con privilegios suficientes para descubrir activos y modificar el estado de la red. Las empresas ganaban un flujo de trabajo común, pero añadían un nuevo sistema de gestión cuya disponibilidad y corrección afectaban a la alcanzabilidad en producción.

Prosimo utilizaba ocasionalmente la expresión «redes cloud autónomas». Las pruebas respaldan la automatización, las recomendaciones y la orquestación impulsada por API, no una red que opere independientemente de las políticas humanas, los servicios del proveedor de nube y las rutas de transporte subyacentes. Los operadores seguían definiendo la intención, aprobando el acceso, gestionando excepciones y asumiendo la responsabilidad de los resultados.

El borde AXI no era un dispositivo genérico, sino una decisión de ubicación

El borde AXI podía desplegarse en VPC o VNet de la nube, en entornos de colocación o en infraestructura adyacente. Las guías técnicas de AWS mostraban configuraciones donde una VPC de borde se conectaba a las VPC de carga de trabajo a través de Transit Gateway, con posibilidad de encadenar firewalls y proporcionar acceso a usuarios remotos o sedes locales. El punto de aplicación de Prosimo se situaba dentro de la topología cloud, no en un perímetro empresarial remoto.

La ubicación determinaba no solo la latencia, sino también dónde entraba el tráfico en el dominio de políticas, qué red troncal de nube o ruta de internet se utilizaba, dónde se realizaban el cifrado y la inspección, y qué telemetría se podía recopilar. Una ubicación inadecuada generaba desvíos y costes; una ubicación correcta acortaba las rutas y mantenía el tráfico cerca de las cargas de trabajo.

El despliegue distribuido aumentaba el número de dominios de fallo a gestionar. La capacidad, la versión de software, el diseño de la zona cloud, la convergencia de rutas y los permisos de acceso podían variar entre regiones. La alta disponibilidad no se lograba simplemente ejecutando dos instancias. El controlador, las tablas de rutas cloud, los servicios de seguridad y las rutas de retorno debían compartir el mismo estado de conmutación por error.

Por lo tanto, el borde formaba parte de un sistema operativo mayor. Su valor dependía de que el descubrimiento de activos, la topología, las políticas y el análisis estuvieran alineados con el entorno cloud circundante. Tratarlo como un dispositivo virtual aislado hacía perder de vista la arquitectura que Prosimo pretendía vender.

La capa subyacente siempre fue propiedad de otros

Prosimo orquestaba el transporte, pero no poseía las rutas físicas. Las rutas de las aplicaciones podían utilizar las redes troncales de nube como AWS, la internet pública, Direct Connect o ExpressRoute, servicios de colocación, circuitos de operadores y redes empresariales. Podía elegir y coordinar rutas entre las opciones disponibles, pero no podía eliminar la latencia, la pérdida de paquetes, los dominios de fallo ni las tarifas que imponía cada proveedor.

Este límite es importante al evaluar las afirmaciones de rendimiento. El controlador podía elegir una ruta observacionalmente mejor y acercar los puntos de entrada a los usuarios. Pero no podía garantizar la prevención de fallos de un operador, interrupciones de una región cloud o latencia de dependencias externas. La experiencia de la aplicación también involucra DNS, procesamiento en el servidor, almacenamiento, comportamiento del navegador y servicios de terceros, todos ellos fuera del control total de un controlador de red.

No tener una red troncal propia no era solo una debilidad. Permitía aprovechar la infraestructura que las empresas ya habían adquirido y beneficiarse de las inversiones de los proveedores de nube. Podía llegar a regiones sin tender fibra y coordinar sistemas nativos como AWS Cloud WAN. A cambio, dependía de la estabilidad de las API, los límites de servicio, las condiciones comerciales y la semántica específica de cada proveedor.

Por lo tanto, la reivindicación no era la propiedad física, sino el control operativo. Se trataba de hacer que las subcapas heterogéneas se comportaran como un único sistema de gestión, conservando sus ventajas nativas. Si esa abstracción reducía el riesgo de dependencia o simplemente lo trasladaba a otro lugar dependía de la portabilidad de las políticas, la topología y la ubicación de los bordes.

Network Transit gestionaba la alcanzabilidad entre objetos de red

Network Transit se centraba en VPC, VNet, subredes, regiones, sedes y segmentos. Orquestaba las configuraciones de tránsito y rutas nativas de la nube para que se pudieran crear conexiones mediante un flujo de trabajo común, en lugar de configurar cada proveedor por separado. Ayudaba a satisfacer el requisito básico de las redes tradicionales: que un prefijo o segmento de origen pudiera alcanzar un destino a través de una ruta permitida.

No se afirmaba que las diferencias entre nubes desaparecieran. AWS, Azure y Google Cloud tienen diferentes objetos, límites y comportamientos de enrutamiento. Los espacios de direcciones solapados, las rutas asimétricas, los puntos de enlace privados y las restricciones de servicio específicas de cada proveedor seguían exigiendo diseño. Prosimo podía normalizar las operaciones comunes y visualizar las relaciones, pero persistían las limitaciones propias de los sistemas subyacentes.

Network Transit también gestionaba la segmentación. Mediante dominios de enrutamiento y políticas, podía aislar entornos y restringir la alcanzabilidad. El controlador necesitaba comprender dónde existían los segmentos en varias nubes y cómo las configuraciones nativas implementaban los límites. Una política expresada una sola vez podía traducirse en múltiples cambios en cada proveedor.

La ventaja era gestionar la intención en un único plano. El riesgo residía en la traducción. Si la política común y la configuración de la nube se desalineaban, las empresas podían creer que un segmento estaba protegido cuando el estado real del proveedor difería. Por ello, la conciliación, la auditoría y la notificación explícita de fallos eran tan importantes como el aprovisionamiento inicial.

App Transit convertía las aplicaciones en objetos de enrutamiento

App Transit ampliaba el modelo más allá de las subredes. Al decidir cómo un usuario o carga de trabajo llegaba a un servicio, podía utilizar el dominio de la aplicación, la identidad, el tipo de solicitud, la salud de la transacción, el riesgo y el rendimiento. Aquí es donde Prosimo intentaba diferenciarse más claramente de los enrutadores cloud tradicionales.

Una perspectiva centrada en las aplicaciones tenía sentido porque los servicios modernos no se representan limpiamente solo con direcciones fijas. Las plataformas gestionadas, los puntos de enlace SaaS y los componentes distribuidos cambian, pero el identificador de la aplicación puede mantener su significado. Las políticas que hacen referencia a un servicio o a un usuario pueden durar más que las reglas basadas únicamente en direcciones y puertos.

Este modelo requería un descubrimiento preciso. El controlador debía saber qué dominios y puntos de enlace pertenecían a una aplicación, qué dependencias necesitaba y qué afirmaciones de los proveedores de identidad eran fiables. Los mapeos obsoletos podían enviar solicitudes por rutas incorrectas y aplicar reglas de seguridad erróneas. La abstracción de la aplicación no eliminaba la necesidad de comprender el estado de la red, sino que añadía una capa de significado por encima.

La combinación de Network Transit y App Transit reconocía que las empresas viven en dos mundos. Los sistemas heredados, las subredes privadas y los controles basados en IP persisten, mientras que las nuevas aplicaciones dependen de dominios, identidades y servicios gestionados. Full-Stack Cloud Transit era el nombre del producto para operar ambos conjuntamente, sin que uno reemplazara al otro.

La identidad ampliaba las decisiones de enrutamiento y los límites de confianza

El acceso consciente de las aplicaciones requería integración de identidad. La plataforma podía utilizar el contexto del usuario o de la carga de trabajo para permitir una conexión o decidir cómo establecerla. Esto respaldaba políticas de tipo confianza cero, donde la ubicación por sí sola no justifica la autorización.

La identidad aumentaba la precisión, pero creaba nuevas dependencias. Las políticas de ruta o de aplicación pasaban a depender de los proveedores de identidad, sus afirmaciones, el estado de la sesión y la información de grupo. Incluso con enrutadores y bordes en buen estado, una interrupción de la autenticación o un cambio de atributos podía hacer fallar las rutas de red. La resolución de incidencias debía traspasar las fronteras entre las operaciones de red y las de identidad.

El controlador también se convertía en un punto de concentración de contexto sensible. Podía contener topología, relaciones de aplicaciones, atributos de usuario, señales de riesgo y resultados de políticas. Estos datos mejoran el diagnóstico y la optimización, pero también amplifican el impacto de un acceso no autorizado. Los privilegios mínimos, los períodos de retención, la auditoría y la separación de funciones eran requisitos arquitectónicos, no añadidos burocráticos.

El enfoque de Prosimo ilustra un cambio que se extiende por toda la infraestructura. Las políticas de enrutamiento y acceso dependen cada vez más de la identidad y de la semántica de las aplicaciones. Cuanto más contexto ve la plataforma, más útiles pueden ser sus decisiones. Al mismo tiempo, esa autoridad debe ser gobernada con mayor rigor.

El descubrimiento de activos creaba el grafo que sustentaba todas las decisiones posteriores

Un controlador multicloud no puede gobernar lo que no ve. Prosimo desarrolló el descubrimiento y mapeo de activos cloud, representando VPC, VNet, subredes, aplicaciones, conexiones y relaciones de seguridad. Estas vistas respaldaban la incorporación, el diseño, la resolución de incidencias y las políticas.

El descubrimiento tenía un valor estratégico porque los activos cloud cambian fuera de los procedimientos centrales de red. Los equipos de aplicaciones pueden crear cuentas, redes, puntos de enlace y servicios gestionados mediante su propia automatización. Los diagramas manuales quedan obsoletos. Un inventario impulsado por API puede construir un grafo más actualizado, pero su integridad depende del alcance de las cuentas, los permisos, la lógica de análisis y las API del proveedor.

El grafo no era solo documentación. Era la estructura de datos para calcular enrutamiento, segmentación, inserción de servicios y optimización. Si faltaba un activo o una dependencia, cualquier conclusión construida sobre él podía ser errónea. Por tanto, la topología necesitaba procedencia: cuándo se recopiló, qué cuentas la proporcionaron, qué regiones incluye y si las solicitudes fallaron.

Este grafo también explica la lógica de la adquisición. Palo Alto Networks puede generar valor de seguridad si conoce la ubicación de las cargas de trabajo y las rutas de tráfico. Un sistema que descubre activos cloud y puede modificar rutas acorta la distancia entre la compra de firewalls de software y su colocación correcta. Las declaraciones posteriores de Bhau sobre la integración destacaron concretamente el descubrimiento de activos y la aceleración del despliegue de firewalls de software.

AIR convertía la telemetría de los bordes en recomendaciones operativas

Application-driven Intelligent Results (AIR) analizaba la telemetría recopilada por los bordes AXI. Las guías de AWS describen la visualización del tiempo de ida y vuelta, el tiempo de procesamiento, el tiempo de respuesta de la aplicación, el tipo de transacción, el riesgo y los resultados de las políticas. La plataforma podía correlacionar observaciones de usuario, red y aplicación, en lugar de limitarse a contadores de dispositivos aislados.

Esta correlación aborda problemas operativos comunes. Una transacción lenta puede deberse a la ruta del usuario, al borde, a la red troncal de la nube, a los servicios de seguridad o a la propia aplicación. Una vista entre capas permite acotar la investigación más rápido que consolas separadas y respalda recomendaciones sobre rutas, ubicación, riesgo y coste.

La calidad de las recomendaciones dependía del alcance de la telemetría y del modelo de interpretación. Los bordes solo observan el tráfico que los atraviesa. Es posible que no vean dependencias externas de la aplicación ni el estado interno del proveedor de nube. Las recomendaciones pueden ser útiles como orientación, pero no siempre demuestran la causa raíz.

La telemetría también tenía valor de gobernanza. Las observaciones históricas ayudan a explicar por qué cambiaron las rutas o las políticas. Al mismo tiempo, pueden revelar patrones de uso de aplicaciones sensibles y comportamiento de usuarios. El material público no describe completamente los períodos de retención ni la gobernanza de datos tras la adquisición, por lo que estos aspectos quedan como elementos de diligencia debida para los clientes.

AWS proporcionó la evidencia de implementación más clara

El trabajo de Prosimo con AWS dejó las pruebas técnicas públicas más sólidas. La empresa se integró con los flujos de trabajo de despliegue de AWS Transit Gateway, Cloud WAN, PrivateLink y Marketplace for Containers Anywhere. AWS publicó guías técnicas que describían la ubicación del borde AXI, la incorporación de aplicaciones, la identidad, la seguridad y la optimización.

Especialmente relevante fue AWS Cloud WAN. Ofrecía un servicio de red troncal y segmentación nativo de la nube que Prosimo podía orquestar en lugar de reemplazar. Esta configuración ilustraba el modelo cooperativo: AWS poseía la red nativa y la infraestructura global; Prosimo proporcionaba la intención multicloud, el contexto de las aplicaciones, el software de borde y el análisis.

Los flujos de trabajo de Marketplace empaquetaban el borde AXI a través de canales aprobados y simplificaban los pasos iniciales de despliegue. Pero los permisos posteriores de las cuentas, el diseño de rutas, la alta disponibilidad, la capacidad y las operaciones seguían siendo necesarios. La automatización del día cero reducía la fricción de adopción, pero no eliminaba los problemas de control a largo plazo.

Los materiales de la empresa nombraban a Flexport como caso de cliente para el uso de AWS Cloud WAN. Esto demuestra que un cliente empresarial respaldó la arquitectura, pero no constituye una auditoría independiente de la escala de despliegue, los ahorros o la disponibilidad. Los comentarios de clientes deben tratarse como ejemplos de adopción, no como pruebas de rendimiento universal.

Azure y Google Cloud completaban la afirmación multicloud

Prosimo también era compatible con entornos de Microsoft Azure y Google Cloud. La documentación del producto describía la orquestación en torno a Azure Virtual WAN, las redes de Google Cloud y las configuraciones de servicios privados. El objetivo era presentar un modelo operativo único, conservando las redes nativas de cada proveedor.

La existencia de compatibilidad no demuestra una funcionalidad idéntica entre proveedores. Las API de la nube maduran a ritmos diferentes y nombres de producto similares pueden tener semánticas distintas. Las rutas, los segmentos, los puntos de enlace privados y la inserción de servicios pueden requerir un tratamiento específico del proveedor. El material disponible no permite reconstruir una tabla de equivalencia funcional que cubra todas las regiones y versiones.

Por lo tanto, la abstracción multicloud se entiende mejor como un sistema de traducción. Podía normalizar la intención y los flujos de trabajo comunes, pero debía conservar los detalles que afectan a la seguridad, el coste y los fallos. Si la interfaz unificada oculta las diferencias de implementación al operador, la plataforma se vuelve peligrosa.

Lo mismo se aplica después de la adquisición. Palo Alto Networks puede utilizar un grafo común para desplegar seguridad en varias nubes, pero los objetos nativos que implementan las rutas siguen estando bajo el control de los proveedores de nube. Poseer la capa de orquestación no equivale a poseer la subcapa de la nube.

Los productos se ampliaron de la conectividad al ciclo de vida

En 2023, Prosimo ya describía flujos de trabajo para diseñar, construir, resolver incidencias y gestionar redes multicloud. Los productos iban más allá de establecer túneles y puertas de enlace. El descubrimiento de activos respaldaba el diseño, la orquestación creaba las conexiones, los mapas y la telemetría ayudaban en la resolución de incidencias, y las políticas y el estado histórico respaldaban la gestión continua.

Este marco de ciclo de vida ampliaba los compradores comerciales. Los ingenieros de redes podían utilizar la topología y el análisis de rutas; los equipos de infraestructura cloud podían incorporar cuentas y servicios; los equipos de seguridad podían verificar la segmentación y la inspección; los equipos de migración podían planificar cambios; y los equipos de FinOps podían examinar el impacto de las rutas y la salida. Cuantos más grupos utilizaban la misma evidencia, mayor era el valor de la plataforma.

La evidencia compartida también crea conflictos de gobernanza. Una infraestructura centralizada puede revelar que las configuraciones nativas de los equipos de cloud difieren de las políticas corporativas. La organización debe decidir qué sistema es el autorizado y quién aprueba las correcciones. El software por sí solo no resuelve este problema institucional.

La narrativa del ciclo de vida también aumentaba los costes de cambio. Cuando un controlador retiene el grafo de activos, las políticas, la telemetría, los despliegues de borde y las integraciones de automatización, reemplazarlo supone más que trasladar circuitos. Los clientes deben exportar o reconstruir su modelo operativo. Prosimo vendía la reducción de la fragmentación de la nube, pero podía crear una dependencia del controlador.

La segmentación abarcaba desde la alcanzabilidad de red hasta las políticas de aplicación

Prosimo promovía la segmentación desde la Capa 3 hasta la Capa 7. A nivel de red, los dominios de enrutamiento y los segmentos determinaban qué subredes y sedes podían comunicarse. En las capas superiores, la identidad de la aplicación, el contexto del usuario y las características de la transacción refinaban las reglas.

El modelo en capas podía reducir la brecha entre las zonas de red y las políticas de aplicación. Permitía, por ejemplo, bloquear el tráfico entre subredes amplias y al mismo tiempo permitir solo servicios de negocio específicos. A la inversa, una ruta de red podía ser alcanzable, pero denegarse si la identidad o el contexto de la aplicación no eran adecuados.

Esto no convertía a Prosimo en un firewall de última generación completo. La integración con Palo Alto Networks en 2024 separaba las responsabilidades: Prosimo orquestaba las rutas, la segmentación y la inserción de servicios, mientras que VM-Series realizaba la inspección profunda. Esta distinción es importante porque el control de rutas por políticas y la aplicación de seguridad fallan de manera diferente.

Un segmento solo es efectivo si se han expresado todas las rutas relevantes. Las rutas desconocidas, las excepciones nativas de la nube o una inserción de servicio fallida pueden eludir los controles previstos. Por tanto, la garantía requiere comparar las políticas declaradas, el estado del proveedor y el tráfico observado, en lugar de confiar únicamente en la pantalla del controlador.

La inserción de servicios vinculaba el control de rutas con la economía del firewall

En el diseño de seguridad en la nube, hay que decidir dónde realizar la inspección. Un firewall central simplifica las políticas y reduce el número de dispositivos, pero puede provocar desvíos, concentración y presión de escala. Los firewalls distribuidos se sitúan cerca de las cargas de trabajo y reducen la distorsión de las rutas, pero aumentan el despliegue, las licencias, las actualizaciones y la operativa de políticas.

Prosimo admitía ambas configuraciones mediante la integración con VM-Series. Las políticas podían enviar tráfico seleccionado a un punto de inspección centralizado o a firewalls distribuidos en las VPC de las aplicaciones. Palo Alto Networks proporcionaba la capacidad de inspección y el controlador actualizaba las rutas circundantes.

Esta arquitectura convertía la orquestación de rutas en algo comercialmente valioso para un proveedor de seguridad. Los firewalls de software no pueden proteger el tráfico que no reciben. El descubrimiento, la ubicación y las actualizaciones de rutas reducen la fricción operativa entre la compra de capacidad de seguridad y su inserción en las rutas de producción. Es una razón estratégica plausible para que Palo Alto Networks absorbiera la tecnología de Prosimo.

Al mismo tiempo, amplía el radio de influencia del controlador. Una política errónea puede eludir la inspección, crear bucles, generar enrutamiento asimétrico o detener aplicaciones. Un fallo en la inserción de servicios es tanto un incidente de red como de seguridad, por lo que se requieren comprobaciones de salud, cambios graduales, simulación, auditoría y reversión.

No se debe retrotraer la alianza de 2024 al momento de la adquisición

Prosimo y Palo Alto Networks anunciaron la integración de VM-Series el 12 de junio de 2024. El anuncio describía una solución técnica y comercial conjunta, pero no mencionaba la adquisición de Prosimo por parte de Palo Alto Networks. Interpretar ese anuncio como prueba de propiedad confunde dos acontecimientos distintos.

No obstante, la alianza sirvió de puente. Prosimo pudo demostrar que su sistema de rutas y políticas facilitaba el despliegue de VM-Series en múltiples nubes. Palo Alto Networks pudo evaluar la tecnología a través de una integración real antes de la posterior migración corporativa. El material público no describe el proceso de adquisición, por lo que afirmar que la alianza fue diseñada como una fase formal previa a la adquisición sería una especulación.

A principios de 2025, los historiales profesionales de los fundadores y empleados habían cambiado. La página de la empresa mostraba posteriormente el estado de adquirida. A finales de 2025, Bhau declaró que la tecnología se había integrado completamente en los productos de Palo Alto Networks. Estos registros combinados respaldan la conclusión de que hubo una adquisición, pero los procedimientos legales permanecen sin aclarar.

Este orden es importante tanto para la precisión editorial como para los clientes. Una alianza implica dos proveedores, dos organizaciones de soporte y límites de integración claros. Una adquisición puede transferir la hoja de ruta, los datos, los contratos y la autoridad a una sola empresa. Aunque el camino técnico sea inicialmente similar, la migración cambia algo más que la marca.

Nebula convertía el grafo de topología en una interfaz conversacional

En febrero de 2024, Prosimo presentó Nebula como parte de su AI Suite para redes multicloud. Este asistente estaba diseñado para responder preguntas en lenguaje natural sobre el estado representado en el grafo y la telemetría de la plataforma, como solapamiento de redes, costes, salud de rutas y violaciones de políticas de seguridad.

El activo útil no era la interfaz de lenguaje en sí, sino el contexto estructurado multicloud subyacente. Un modelo genérico no puede diagnosticar rutas privadas o segmentos que no ve. Nebula podía aprovechar el inventario, la topología, las políticas y las observaciones que Prosimo ya recopilaba. La inversión previa en un grafo común se vinculó así con las operaciones asistidas por IA.

El acceso conversacional puede abrir datos complejos a más operadores. Sin embargo, si se omiten activos no cubiertos en las respuestas, se malinterpretan las preguntas o se tratan las recomendaciones como operaciones aprobadas, se puede generar una falsa confianza. Los cambios de alto riesgo seguían requiriendo controles deterministas, límites de autoridad y confirmación humana.

Prosimo indicó que se podía reducir el tiempo medio de recuperación entre un 60% y un 80% y los costes de red en la nube en más de un 60%. Estas son afirmaciones de la empresa en anuncios de producto. El material disponible no incluye metodologías independientes ni líneas de base de clientes que demuestren su aplicabilidad general. Pueden citarse como beneficios presentados por Prosimo, pero no como hechos de mercado medidos.

Las cargas de trabajo de IA eran un nuevo caso de uso, no una prueba de nuevo mercado

El mismo anuncio de 2024 posicionaba la arquitectura de Prosimo como útil también para cargas de trabajo de IA. Los sistemas de IA distribuidos pueden requerir acceso privado a datos, conectividad entre nubes y centros de datos, controles de cumplimiento y enrutamiento que refleje el comportamiento de las aplicaciones. Estos requisitos se alinean con los modelos existentes de activos, políticas y rutas.

El cambio de nombre no modifica la subcapa. Prosimo seguía dependiendo de las redes de los proveedores de nube, los operadores y la infraestructura del cliente. Tampoco proporcionaba computación con GPU ni software de desarrollo de modelos. Su función prevista era ser la capa de conectividad y seguridad alrededor de los datos y servicios distribuidos.

El posicionamiento en IA tenía sentido estratégico, ya que cuanto más se distribuyen los datos y los servicios, más valiosa se vuelve la topología multicloud. Al mismo tiempo, era una categoría de marketing introducida justo antes de que la empresa cesara su operación independiente. El material disponible no muestra ventas de productos de IA por separado, implementaciones nominales en producción ni resultados de cargas de trabajo auditados.

El argumento duradero es que la telemetría multicloud puede servir como entrada para operaciones asistidas por máquina. La pregunta actual sobre el producto es si Palo Alto Networks ha conservado ese contexto y cómo ofrece las capacidades. Las pruebas públicas hasta la fecha de corte de la investigación no proporcionan una respuesta completa.

El modelo comercial vendía software sobre infraestructura que no poseía

Durante su etapa independiente, Prosimo era un negocio de suscripción de software y servicios, no un modelo de operador de telecomunicaciones. Los clientes desplegaban los bordes AXI en sus propios entornos y conectaban sus cuentas cloud a la capa de control. Los ingresos probablemente dependían de licencias o suscripciones, soporte, servicios profesionales y actividad de canal, aunque los precios exactos y las métricas contractuales no se han hecho públicos en el material disponible.

Era un modelo que podía escalar sin poseer fibra óptica. Una sola plataforma de software podía coordinar numerosas regiones cloud y entornos de clientes. Sin embargo, no se puede inferir la estructura de margen bruto solo a partir de esta arquitectura. El mantenimiento de las API de los proveedores, el ciclo de vida de los bordes, las integraciones de seguridad y el soporte a la adopción empresarial conllevan costes, y es posible que los recursos cloud consumidos por los bordes corrieran a cargo del cliente, no del proveedor.

Prosimo accedía a las empresas a través de los mercados cloud, socios de integración, canales de venta y casos de clientes nominales. Estas cosas no son el mismo tipo de evidencia. Una ficha en un mercado demuestra una vía de adquisición y despliegue. Una integración técnica demuestra que dos sistemas pueden combinarse en condiciones definidas. Los comentarios de clientes muestran ejemplos de adopción. Ninguno de ellos, por sí solo, prueba el número de clientes de pago ni los ingresos recurrentes.

La amplitud del alcance pudo aumentar la complejidad de las ventas. Los equipos de red, seguridad, cloud y aplicaciones podían beneficiarse, pero el propietario del presupuesto no siempre estaba claro. El producto necesitaba un comprador que financiara una capa de control común, en lugar de permitir que cada equipo gestionara su nube por separado.

Socios, clientes e inversores ocupaban posiciones diferentes

Amazon Web Services era a la vez el proveedor de la subcapa y un socio de integración para la salida al mercado. Azure y Google Cloud eran entornos compatibles. Los proveedores de identidad suministraban el contexto de autenticación y los fabricantes de firewalls proporcionaban la inspección. Los operadores de colocación y telecomunicaciones podían alojar y conectar los bordes, y los socios de canal podían diseñar y operar las implantaciones.

En el material de AWS Cloud WAN, Flexport aparecía como caso de cliente nominal. Esto demuestra que una empresa se interesó por la arquitectura, pero el alcance total de la implantación, la duración y el valor comercial no se desprenden del material disponible. No debe utilizarse como indicador representativo de toda la base de clientes.

General Catalyst lideró la Serie A y participó en la gobernanza como inversor. Los materiales de la empresa mostraban inversores relacionados con WRVI o Celesta, y comunicaciones posteriores de Prosimo mencionaban una participación inversora destacada con nombres vinculados a BlackRock, aunque el vehículo de inversión exacto no se ha resuelto en la investigación. Estos registros apuntan a una base de capital influyente, pero no a una tabla de capitalización completa.

La relación más importante fue con Palo Alto Networks. En 2024 era un socio de seguridad; a principios de 2025 se convirtió en el adquirente. Esta secuencia muestra cómo una dependencia del ecosistema puede transformarse en una relación de control cuando compra la capa de software que orquesta las rutas hacia sus productos.

Recaudó al menos 55 millones de dólares, pero se desconocen los términos económicos de la salida

La financiación confirmada es de 25 millones de dólares en la Serie A en abril de 2021 y 30 millones de dólares en la Serie B en 2022. La suma asciende al menos a 55 millones de dólares. El material disponible no incluye una tabla de capitalización auditada, valoraciones, lista de deuda ni rondas de financiación posteriores.

La contraprestación de la adquisición no se ha hecho pública ni se ha verificado de forma independiente. Sin precio, no es posible clasificar de manera responsable el resultado como una prima estratégica, una adquisición tecnológica limitada, una compra de talento o una venta forzosa por dificultades. El hecho de que la tecnología se siguiera integrando en los productos indica valor, pero no revela los rendimientos para los inversores ni para los fundadores.

No se deben atribuir a Prosimo los ingresos o la cuota de mercado posteriores a la adquisición de Palo Alto Networks. Una vez que una startup deja de ser observable por separado, no hay ventas, beneficios ni segmentos de clientes independientes que analizar. Un propietario más grande puede desplegar la tecnología ampliamente, al tiempo que hace menos visibles sus aspectos económicos individuales.

La ausencia de un anuncio formal de adquisición también tiene significado. Clientes, empleados e investigadores suelen obtener de esos anuncios información sobre el momento, el soporte y la lógica estratégica. En este caso, el estado debe reconstruirse a partir de historiales profesionales, la indicación en la página de la empresa y declaraciones posteriores de los fundadores. Es suficiente para corregir el estatus de empresa independiente, pero no para inventar los detalles de la transacción.

Los competidores eran plataformas especializadas, nubes e ingeniería interna

Prosimo competía con plataformas especializadas de redes multicloud como Aviatrix y Alkira, con proveedores de redes empresariales y SASE, y con los servicios nativos de AWS, Azure y Google Cloud. También competía con modelos de bricolaje en los que las empresas utilizan directamente infraestructura como código, servicios de tránsito de los proveedores de nube, tablas de rutas y firewalls. Cada opción resolvía una parte diferente del mismo problema.

Los controladores especializados pueden ofrecer un modelo único de topología y políticas para varios proveedores. Los diseños nativos de la nube reducen la dependencia de terceros y se alinean estrechamente con un solo proveedor. Los servicios asistidos por operadores pueden suministrar transporte físico. Las plataformas SASE o de seguridad pueden integrar conectividad y aplicación de seguridad. La ingeniería interna mantiene el control a costa de aumentar el personal y el trabajo de integración.

La diferenciación de Prosimo residía en la combinación de tránsito de aplicaciones y de red, bordes distribuidos, orquestación nativa de la nube, topología, telemetría e inserción de servicios. Esa misma amplitud dificultaba las comparaciones. Los compradores tenían que probar los servicios de nube, las rutas, los sistemas de identidad y las configuraciones de seguridad que realmente utilizaban, en lugar de comparar nombres de categorías.

La adquisición cambia el marco competitivo. Prosimo ya no necesita ganar como empresa independiente, pero su tecnología debe demostrar valor dentro de Palo Alto Networks. La comparación relevante es si el descubrimiento y la orquestación de rutas integrados mejoran el despliegue de los productos de seguridad de Palo Alto Networks y si los clientes aceptan esa dependencia de la plataforma.

Los servicios nativos de la nube eran la base y también la alternativa

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN y las redes de Google Cloud ofrecían a las empresas potentes opciones nativas. Prosimo dependía de ellos y, al mismo tiempo, competía con la posibilidad de que los clientes los utilizaran directamente.

Esta relación creaba una frontera móvil. A medida que los proveedores de nube añadían enrutamiento global, segmentación, acceso a servicios privados y políticas centralizadas, algunas de las capacidades de terceros se volvían más fáciles de replicar de forma nativa. Al mismo tiempo, cada nuevo servicio nativo añadía más objetos que un controlador multicloud debía descubrir y coordinar. El avance de la nube podía reducir parte del valor de Prosimo, al tiempo que ampliaba la necesidad de traducción entre proveedores.

Los factores determinantes no eran solo técnicos, sino también organizativos. Una empresa con una sola nube y una sólida ingeniería interna podía preferir las herramientas nativas. Una empresa multicloud con equipos fragmentados podía valorar un plano de control único. Las organizaciones de sectores regulados podían apreciar una capa de evidencia de terceros, pero preocuparse por las credenciales privilegiadas y la concentración de datos.

Ninguna arquitectura elimina por completo la dependencia del proveedor. Las herramientas nativas aumentan la dependencia de las API y la semántica de una sola nube. Los controladores multicloud aumentan la dependencia del grafo, las políticas y el software de borde. La pregunta útil era si esa dependencia era visible, portable y se ajustaba al modelo operativo de la organización.

Los fallos podían originarse en el controlador, los bordes, las API de la nube, la identidad o la subcapa

La arquitectura distribuida de Prosimo reducía la dependencia de un solo concentrador de tráfico, pero creaba múltiples dominios de fallo que interactuaban. Los servicios centrales podían caerse y retener intenciones obsoletas. Los bordes podían fallar o quedar aislados. Las API de la nube podían rechazar partes de un cambio. Los proveedores de identidad podían interrumpirse. La subcapa podía perder capacidad o tomar rutas imprevistas. Los firewalls insertados podían agotar sus recursos.

Los fallos parciales resultan especialmente difíciles. Un proveedor puede aceptar una actualización de ruta y otro rechazarla. En ese caso, el estado de intención del controlador y el estado real de la nube divergen. El tráfico puede tomar rutas asimétricas y eludir la inspección. Un sistema fiable necesita conciliación, operaciones idempotentes, cambios graduales, estados de error explícitos y una reversión que tenga en cuenta el comportamiento de cada proveedor.

Las pruebas públicas describen alta disponibilidad y optimización a alto nivel, pero no incluyen pruebas de inyección de fallos independientes, registros completos de incidencias ni resultados de nivel de servicio universales. Por lo tanto, las afirmaciones de resiliencia deben vincularse a la arquitectura documentada o a implantaciones con nombres de clientes.

La adquisición introduce otro dominio de fallo: la continuidad del producto. Los clientes necesitan saber qué consola, API, imagen de borde, modelo de políticas y organización de soporte reemplazan a los sistemas anteriores de Prosimo. Incluso si la integración de código es técnicamente exitosa, el riesgo de migración persiste si los límites comerciales y operativos no están claros.

Las credenciales cloud convertían al controlador en parte del plano de gestión crítico

El descubrimiento de activos y la orquestación requerían acceso a las cuentas cloud. Los inventarios de solo lectura podían obtenerse con permisos limitados, pero la modificación de rutas, segmentos e inserción de servicios exigía permisos más amplios. En consecuencia, el controlador se situaba dentro del plano de gestión privilegiado, aunque no fuera propietario de las cargas de trabajo.

Si las credenciales se veían comprometidas, la topología podía quedar expuesta y se podían permitir cambios generalizados. Un error de software o un fallo del operador podía propagar políticas a varias nubes. Cuanto más útil se vuelve la plataforma, mayor es el riesgo. Cuantas más cuentas y servicios puede gestionar, mayor es el radio potencial de impacto.

Las empresas necesitaban roles con privilegios mínimos, separación de credenciales para descubrimiento y modificación, aprobación por múltiples personas, auditoría completa, rotación, revocación de emergencia y rutas de recuperación que no dependieran exclusivamente del mismo controlador. El material público no incluye evaluaciones de seguridad independientes completas, por lo que estos son controles necesarios en la implantación, no garantías del producto.

El grafo de telemetría es igualmente sensible. Puede revelar nombres de aplicaciones, estructura de red, políticas, relaciones de usuarios, salud de rutas y patrones de costes. La gobernanza posterior a la adquisición debería aclarar dónde se almacenan esos datos, qué productos de Palo Alto Networks pueden utilizarlos y cómo se transfirieron los derechos de los antiguos clientes. Las pruebas públicas hasta la fecha de corte no responden a estas cuestiones.

La adquisición trasladó una capa neutral de nube al interior de una plataforma de seguridad

Como empresa independiente, Prosimo podía posicionarse como una capa común que abarcaba nubes y servicios de seguridad. Con Palo Alto Networks como propietario, los incentivos cambian. La tecnología adquirida puede facilitar el despliegue de productos de Palo Alto Networks, como VM-Series. La experiencia integrada puede mejorar, pero surgen nuevas preguntas sobre la compatibilidad con servicios de inspección de terceros.

La propiedad por sí sola no demuestra la pérdida de neutralidad. El material disponible no incluye una lista actual de socios ni la arquitectura del producto. Pero lo que los clientes deben preguntar cambia: si el controlador de rutas está abierto a múltiples proveedores de seguridad, si las políticas y la telemetría se pueden exportar, y si la optimización favorece la cartera de productos del propietario.

Las declaraciones de integración destacaban la inspección de entrada, salida y este-oeste. Este énfasis sugiere que la topología y la orquestación de Prosimo se han convertido en parte de un sistema de despliegue de seguridad. Sin embargo, no demuestra que el antiguo App Transit, el acceso de usuarios, la optimización de costes y todos los flujos de trabajo de redes en la nube subsistan como funciones separadas.

Se trata de un patrón recurrente en infraestructura: una startup abstrae un difícil problema de coordinación; una gran empresa de plataforma la adquiere porque esa abstracción puede aumentar el uso y el control de sus productos principales. El comprador obtiene una vía de despliegue. Los clientes obtienen integración, pero pueden perder parte de su independencia frente al proveedor.

La tabla de correspondencia con los productos actuales es la información que más falta

Los registros públicos confirman la adquisición y la integración, pero no muestran completamente cómo se corresponden AXI, Network Transit, App Transit, AIR y Nebula con los productos o SKU actuales de Palo Alto Networks. Tampoco se han hecho públicas las fechas de fin de soporte de los productos anteriores, los procedimientos de migración ni una tabla de continuidad funcional.

Esta laguna impide una revisión de los productos actuales. Las descripciones históricas pueden mostrar lo que Prosimo construyó y por qué fue relevante. Pero no pueden indicar qué funciones están actualmente disponibles, bajo qué licencia y con qué soporte. El asesoramiento actual sobre implantación requiere la documentación vigente de Palo Alto Networks, no los anuncios anteriores de Prosimo.

La tabla de correspondencia ausente también limita el análisis estratégico. La absorción completa del grafo de topología y la capa de orquestación es diferente de un uso selectivo limitado al descubrimiento de activos y a la colocación de firewalls. Lo primero crea un amplio servicio de control multicloud; lo segundo acelera principalmente el despliegue de seguridad. Las declaraciones de los cofundadores respaldan la continuidad técnica, pero no resuelven este límite arquitectónico.

La futura documentación de productos, las guías de migración y los casos de clientes podrían resolver gran parte de la incertidumbre. Hasta entonces, la formulación precisa es que, según los cofundadores, la tecnología de Prosimo se integró en los productos de Palo Alto Networks, pero el alcance y el empaquetado no están verificados.

Quién controla el enrutamiento multicloud

Ningún actor controla por sí solo toda la ruta. Las empresas gestionan la propiedad de las cuentas, la intención de negocio, el diseño de las aplicaciones y las credenciales que otorgan. Un controlador multicloud puede descubrir la topología, traducir políticas, seleccionar rutas y modificar el estado de las rutas nativas. Los proveedores de nube controlan las API, los servicios de tránsito, los puntos de enlace privados, las redes troncales y muchos dominios de fallo. Los operadores de telecomunicaciones y los proveedores de colocación gestionan otros segmentos de transporte.

Los servicios de seguridad deciden si permiten el tráfico inspeccionado.

Prosimo apuntó a la posición intermedia más valiosa estratégicamente: no poseía la subcapa, pero pretendía poseer el grafo y la traducción de políticas por encima de ella. Quien controle esta capa puede decidir qué activos son visibles, cómo se expresan los segmentos, dónde se ubican los bordes, qué servicios inspeccionan el tráfico y qué telemetría se considera autorizada. Esto equivale a una autoridad práctica de enrutamiento, aunque la fibra óptica pertenezca a otros.

Tras la adquisición, Palo Alto Networks posee la tecnología restante de Prosimo y decide su integración, empaquetado y desarrollo. Los proveedores de nube conservan la soberanía dentro de sus entornos, y las empresas pueden revocar credenciales y elegir otra arquitectura. Sin embargo, si la topología, las políticas y los flujos de trabajo operativos dependen del controlador, la salida resulta costosa.

La respuesta, por tanto, no es absoluta, sino por capas. Las empresas otorgan la autoridad, el controlador coordina, las subcapas de nube y operadores transportan, y la plataforma de seguridad aplica las políticas. La historia de Prosimo muestra que la propiedad de la capa de coordinación puede cambiar, aunque los propietarios de las cuentas cloud y de las rutas físicas sigan siendo los mismos.

Fuentes principales

Por qué Prosimo sigue siendo relevante después de la adquisición

Prosimo captó un cambio real en la infraestructura. La unidad de operación de red está pasando de los dispositivos y prefijos a las aplicaciones, las identidades, las dependencias de servicios y los grafos de políticas. Las API nativas de la nube hacen que el estado de la red sea programable, y los bordes de software distribuidos permiten trasladar el punto de aplicación de las políticas. Un controlador con visibilidad sobre múltiples nubes puede coordinar operaciones que no se completan en una sola consola de nube.

La empresa también puso de manifiesto los costes de esa coordinación. Una capa común requiere credenciales privilegiadas, mantenimiento continuo de API, descubrimiento preciso, traducción semántica, telemetría y disciplina operativa. Al tiempo que reduce el trabajo fragmentado, crea un nuevo punto de concentración. El mismo sistema puede simplificar el enrutamiento y amplificar el radio de impacto de una sola decisión errónea.

La adquisición por parte de Palo Alto Networks hizo más visible el problema de control. Las redes y la seguridad están convergiendo en torno a la inserción de servicios, el descubrimiento de cargas de trabajo y las políticas. Un proveedor de seguridad que conoce la topología y puede modificar las rutas no se limita a inspeccionar el tráfico que se le presenta, sino que también puede influir en qué tráfico llega a la inspección y por dónde.

Por lo tanto, no hay que ver a Prosimo como un fracaso de marca independiente ni como la prueba de que una sola plataforma resolvió el multicloud. Su contribución duradera es haber definido el grafo multicloud como infraestructura. La pregunta que queda es si ese grafo, ahora dentro de una gran empresa de seguridad, mantiene la transparencia, la portabilidad y la gobernabilidad que los clientes necesitan para confiar en él.