Resumen

  • Prosimo fue fundada en 2019 y recaudó al menos 55 millones de dólares en las rondas de financiación Serie A de 2021 y Serie B de 2022; los datos de ingresos auditados y la información sobre valoración y precio de adquisición no se han hecho públicos.
  • AXI integraba directivas centrales, topología y análisis con edges distribuidos que captaban recursos en la nube, conectaban aplicaciones e insertaban servicios de seguridad, sin poseer el backbone físico.
  • Tras la integración con VM-Series anunciada en junio de 2024, Prosimo pasó a Palo Alto Networks alrededor de febrero de 2025; no hay constancia de una fecha exacta, el precio ni la asignación actual de productos.
  • El control sigue repartido entre la empresa, el software de orquestación, los proveedores de nube y Palo Alto Networks; por tanto, lo decisivo es si la topología, las credenciales, las políticas y las facultades de enrutamiento siguen siendo portables.

La marca desapareció, pero el problema persiste

En 2026, Prosimo ya no puede describirse como un proveedor activo e independiente. Los perfiles profesionales públicos muestran que los fundadores y varios empleados se trasladaron a Palo Alto Networks hacia febrero de 2025. El perfil corporativo de Prosimo aparece como adquirida, y el antiguo director de tecnología, Nehal Bhau, escribió posteriormente que la tecnología se había integrado en productos de Palo Alto Networks. Las pruebas muestran un cambio de control y un valor técnico que perdura, pero no revelan la fecha exacta de firma o cierre, la forma jurídica ni el precio de la transacción.

Esta evaluación debe ir al principio porque altera el tiempo verbal de cualquier afirmación sobre los productos. AXI, Network Transit, App Transit, Application-driven Intelligent Results y Nebula eran funciones documentadas de Prosimo durante su fase independiente. No deben presentarse como productos que se sigan comercializando por separado mientras Palo Alto Networks no publique una asignación actualizada de productos y soporte. Una arquitectura histórica puede seguir existiendo tras una adquisición como código integrado, servicio compartido, módulo o activo de ingeniería interno; estas formas no son equivalentes.

La desaparición de la marca no vuelve obsoleto el problema subyacente. Las empresas siguen distribuyendo cargas de trabajo entre Amazon Web Services, Microsoft Azure, Google Cloud, centros de datos privados, ubicaciones de colocation, plataformas de software como servicio y usuarios remotos. Cada entorno posee sus propias rutas, puertas de enlace, puntos finales privados, controles de identidad, servicios de seguridad, cuotas y reglas de facturación. Una empresa puede ser propietaria de las cuentas y aun así carecer de una visión unificada de cómo viaja una solicitud entre entornos.

La importancia de Prosimo radica en el intento de reunir esa visión en una capa de control común.

Por tanto, la adquisición constituye el núcleo narrativo y no un mero epílogo. Prosimo construyó una capa de control entre nubes capaz de reconocer recursos, evaluar el contexto de las aplicaciones y dirigir el tráfico a través de servicios de seguridad. Palo Alto Networks apareció inicialmente como socio técnico cuyos cortafuegos VM-Series podían insertarse en esas rutas. Más tarde, Palo Alto Networks adquirió la tecnología. Con ello, la frontera entre orquestación de enrutamiento e inspección de seguridad profunda se desplazó hacia una única plataforma de ciberseguridad.

En el enrutamiento multi-nube, el contexto lo decide todo

Una tabla de enrutamiento puede determinar si un prefijo es accesible a través de un determinado siguiente salto. Por sí sola, no explica qué aplicación quería invocar un usuario, si el solicitante es de confianza, si un servicio de inspección necesita ver el tráfico, si hay un punto final privado disponible, si una ruta en la nube es más cara que otra o si una transacción falla después de la entrega del paquete. La operación multi-nube convierte estas cuestiones en un problema de control compartido.

La tesis de Prosimo era que las decisiones de enrutamiento debían basarse en algo más que la alcanzabilidad de capa 3. El software intentaba combinar inventario de nube, estado de la red, identidad de la aplicación, identidad del usuario, riesgo, rendimiento y telemetría de transacciones. Este contexto más amplio permitía políticas que conectaran una aplicación concreta, aislaran un segmento, eligieran un punto de ingreso o dirigieran tráfico seleccionado a través de un cortafuegos. El valor no provenía de una nueva ruta de fibra, sino de la decisión de cómo ensamblar rutas y servicios existentes.

Esta diferencia explica la expresión «infraestructura de experiencia de aplicación». El concepto situaba la solicitud de la aplicación en el centro, no el objeto de red individual. Una VPC, una VNet, una subred, un hub de tránsito o un enlace privado se convertían en componentes de un camino de extremo a extremo, no en el último objeto administrativo. El enfoque situaba el producto en varios mercados a la vez: redes en la nube, entrega de aplicaciones, acceso de confianza cero, aseguramiento de red, optimización de costes e inserción de servicios de seguridad.

La amplitud generaba oportunidades y ambigüedad. Un producto que afecta a varios equipos puede resolver problemas de coordinación de los que ningún equipo se siente responsable. Sin embargo, resulta más difícil de evaluar porque los equipos de redes, seguridad, nube, aplicaciones y finanzas definen el éxito de manera diferente. Prosimo debía demostrar que un modelo entre nubes mejoraba las operaciones sin crear otra capa privilegiada cuyos fallos se propagaran a todos los entornos.

Lo que fue Prosimo y lo que queda de ello

Prosimo era una empresa privada de software de redes en la nube, fundada en 2019 en el Área de la Bahía de San Francisco. Ramesh Prabagaran fue cofundador y director ejecutivo, mientras que Nehal Bhau ejerció como cofundador y director de tecnología durante la fase independiente. Los perfiles públicos también mencionan a Linus Aranha y Pradeep Aragonda en funciones de fundación o ingeniería de alto nivel; sus títulos exactos deben vincularse a biografías fechadas.

La plataforma principal se llamaba Application eXperience Infrastructure, normalmente abreviada como AXI. AXI empleaba una capa de software central para directivas, topología, análisis y orquestación, junto con edges AXI distribuidos en regiones de nube, entornos de colocation o infraestructura local adyacente. Más tarde, Prosimo estructuró la oferta como Full-Stack Cloud Transit, donde Network Transit y App Transit cubrían diferentes clases de conectividad. AIR analizaba la telemetría y proporcionaba información operativa; Nebula añadió en 2024 una interfaz conversacional.

Prosimo no era un operador de nube. La empresa no poseía un backbone de fibra global que conectara todas las regiones. Las rutas podían discurrir por los backbones de los proveedores de nube, la Internet pública, conexiones directas, enlaces de colocation y redes corporativas. Prosimo tampoco era un proveedor de cortafuegos en el mismo sentido que Palo Alto Networks. Su papel en la integración de 2024 consistía en el descubrimiento de recursos, la segmentación y la dirección del tráfico; los VM-Series asumían la inspección de seguridad profunda.

Tras la adquisición, «continuidad tecnológica» es la descripción más precisa. La posterior declaración de integración destacaba el descubrimiento de recursos multi-nube y una provisión más rápida de cortafuegos de software para inspección de ingreso, egreso y este-oeste. Esto demuestra que componentes clave de Prosimo perduran, pero no que todo el catálogo histórico de AXI, el empaquetado comercial o el modelo de soporte se mantengan sin cambios.

El problema después de SD-WAN

El equipo fundador aportaba experiencia en redes a gran escala, entrega de aplicaciones e infraestructura en la nube. Prosimo surgió también del entorno más amplio de fundadores e ingenieros de Viptela, la empresa que ayudó a establecer la SD-WAN como categoría empresarial. Sin embargo, el siguiente problema estaba en otro lugar. La SD-WAN podía simplificar la forma en que las sucursales alcanzaban redes y aplicaciones, pero no creaba un modelo operativo unificado dentro de múltiples nubes públicas y a través de sus fronteras.

Una aplicación multi-nube puede depender de un punto final web en un entorno, una base de datos o un servicio gestionado en otro, un proveedor de identidad externo, una conexión privada a un centro de datos y una inspección de seguridad en fronteras seleccionadas. Cada dependencia puede aparecer como un objeto nativo diferente. El equipo de redes ve prefijos y hubs de tránsito; el equipo de nube ve cuentas y objetos de recurso; el responsable de aplicaciones ve dominios y transacciones; el equipo de seguridad ve zonas y políticas de inspección.

Prosimo partía de la solicitud, no de la sucursal. Lo decisivo era cómo un usuario o carga de trabajo debía alcanzar una aplicación con seguridad, rendimiento, disponibilidad y costes aceptables. Esto desplazaba el objeto de la decisión de enrutamiento del prefijo de destino a una transacción con contexto de identidad y aplicación. Al mismo tiempo, la plataforma debía recopilar y mantener mucha más información que un enrutador convencional.

La entrada en el mercado llegó en un momento oportuno. AWS, Azure y Google Cloud estaban ampliando servicios nativos de tránsito y conectividad privada. Las empresas podían construir redes sofisticadas dentro de un proveedor, pero las API, los objetos y los modelos de políticas seguían siendo específicos de cada uno. La oportunidad de Prosimo radicaba en coordinar esos servicios, en lugar de obligar a cada cliente a sustituirlos por un backbone propietario separado.

De la fundación en 2019 al lanzamiento público en 2021

Prosimo fue fundada en 2019, pero no anunció su lanzamiento público hasta el 6 de abril de 2021. General Catalyst lideró entonces una Serie A de 25 millones de dólares. El inversor describió la oportunidad como la de proporcionar una experiencia de aplicación coherente en múltiples nubes, lo que coincidía con el intento de los fundadores de definir una categoría más allá de la conectividad tradicional de sucursales.

El lanzamiento situó a la empresa en un segmento denso y aún por definir. Los proveedores de nube facilitaban el consumo de sus propios servicios de red. Los proveedores de SD-WAN y SASE extendían políticas hacia los entornos de nube. Los proveedores de entrega de aplicaciones podían optimizar las solicitudes, y las empresas de seguridad de red podían inspeccionarlas. El argumento de Prosimo se basaba en unir estas funciones en una arquitectura orientada a la nube, sin pretender sustituir todos los sistemas circundantes.

La financiación proporcionó margen para integraciones, edges de software, analítica, una organización de ventas y relaciones con socios, pero no demostraba el ajuste producto-mercado, el volumen de ingresos ni una diferenciación duradera. Las pruebas aportadas no incluyen datos de ingresos auditados, cifras de ingresos recurrentes anuales, número de clientes ni valoración. El historial de financiación muestra la confianza de los inversores en una tesis, no el rendimiento operativo completo.

En 2022, Prosimo cerró una Serie B de 30 millones de dólares, descrita como sobresuscrita. Las dos rondas claramente identificadas suman una financiación verificada de al menos 55 millones de dólares. Algunas bases de datos pueden mostrar una cifra superior si duplican anuncios o registros relacionados; dichas sumas no deben utilizarse sin desglosar los eventos subyacentes.

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

La arquitectura AXI repartía tareas entre una capa central de control y análisis y edges de software distribuidos. La capa central gestionaba políticas de aplicación y red, reconocía recursos, fusionaba la topología, integraba identidad, analizaba telemetría y orquestaba cambios. Los edges AXI se ubicaban cerca de las cargas de trabajo o de los usuarios para que las políticas pudieran aplicarse sin forzar cada trayectoria a través de un hub físico remoto.

La separación recuerda a otros sistemas definidos por software, pero los objetos eran específicos de la nube y estaban orientados a las aplicaciones. El controlador necesitaba acceso a cuentas y API de nube, mientras que el edge requería conectividad con servicios de tránsito nativos, redes de carga de trabajo, puntos finales privados o rutas externas. La autoridad de la plataforma surgía de la combinación de ambas perspectivas: directivas globales por encima de las nubes y ejecución local cerca del tráfico relevante.

La arquitectura también creaba una frontera práctica de despliegue. Cada edge consumía recursos de nube, exigía un diseño de alta disponibilidad y debía actualizarse, supervisarse y protegerse. La capa de control necesitaba credenciales con permisos suficientes para reconocer recursos y modificar el estado de la red. El cliente ganaba un flujo de trabajo común, pero añadía un sistema de gestión cuya disponibilidad y corrección eran cruciales para la alcanzabilidad de las aplicaciones productivas.

Prosimo utilizaba a veces el término «red autónoma en la nube». Hay evidencia de automatización, recomendaciones y orquestación basada en API, pero no de una red que funcione de forma independiente de las directivas humanas, de los servicios de los proveedores de nube o del transporte subyacente. Los operadores seguían definiendo las políticas, aprobando accesos, resolviendo excepciones y asumiendo la responsabilidad del resultado.

Un edge AXI era una decisión de ubicación, no un appliance corriente

Un edge AXI podía desplegarse en una VPC o VNet de nube, en un entorno de colocation o en infraestructura adyacente. La documentación técnica de AWS mostraba una VPC de edge conectada a VPC de carga de trabajo mediante Transit Gateway, con encadenamiento opcional de cortafuegos y acceso desde usuarios remotos o ubicaciones locales. El diseño situaba el punto de ejecución de Prosimo dentro de la topología de nube, no en un perímetro corporativo remoto.

La ubicación influía en algo más que la latencia. Determinaba dónde el tráfico entraba en el dominio de políticas, qué backbone de nube o ruta de Internet utilizaba, dónde se producían el cifrado y la inspección, y qué telemetría podía recopilar la plataforma. Un edge mal situado podía provocar desvíos o costes adicionales; uno bien situado podía acortar la ruta o mantener el tráfico cerca de la carga de trabajo.

La distribución aumentaba el número de dominios de fallo que gestionar. La capacidad, las versiones de software, el diseño de zona de nube, la convergencia de rutas y los permisos de acceso podían diferir según la región. La alta disponibilidad significaba más que dos instancias: también el controlador, las tablas de enrutamiento de la nube, los servicios de seguridad y las rutas de retorno debían reflejar un estado de conmutación por error coherente.

Por tanto, el edge formaba parte de un sistema operativo más amplio. Su valor dependía de que el descubrimiento de recursos, la topología, las políticas y el análisis se mantuvieran coherentes con el entorno de nube circundante. Quien lo considerase una appliance virtual independiente estaba pasando por alto la arquitectura que Prosimo pretendía vender.

La red subyacente seguía en manos ajenas

Prosimo coordinaba el transporte, pero no poseía la red subyacente ni el camino físico. Una ruta de aplicación podía utilizar el backbone de AWS o de otro proveedor de nube, la Internet pública, Direct Connect o ExpressRoute, colocation, una conexión de operador o una red corporativa. La plataforma podía elegir entre las opciones disponibles y orquestarlas, pero no podía eliminar la latencia, la pérdida de paquetes, los dominios de fallo o los modelos de precios de esos proveedores.

Este límite es crucial para las afirmaciones de rendimiento. Un controlador puede elegir una ruta observablemente mejor o acercar el ingreso al usuario, pero no puede garantizar que un operador no falle, que una región de nube permanezca disponible o que una dependencia externa responda con rapidez. La experiencia de aplicación incluye además DNS, procesamiento del servidor, almacenamiento, comportamiento del navegador y servicios de terceros fuera del control directo del controlador de red.

La ausencia de un backbone propietario no era sólo una debilidad. Prosimo podía aprovechar la infraestructura que las empresas ya pagaban y beneficiarse de las inversiones de los proveedores de nube. Podía llegar a regiones sin desplegar fibra propia y coordinar sistemas nativos como AWS Cloud WAN. El precio era la dependencia de la estabilidad de las API, las cuotas de servicio, las condiciones comerciales y la semántica específica de cada proveedor.

Por tanto, la pretensión de la plataforma era el control operativo, no la propiedad física. Debía unificar redes subyacentes heterogéneas en un sistema gestionado, conservando sus ventajas nativas. Si la abstracción reducía el lock-in o simplemente lo desplazaba, dependía de la portabilidad de las políticas, la topología y el despliegue de los edges.

Network Transit regulaba la alcanzabilidad entre objetos de red

Network Transit se centraba en VPCs, VNets, subredes, regiones, ubicaciones y segmentos. Coordinaba los objetos nativos de tránsito y enrutamiento de la nube para que los equipos pudieran construir conectividad mediante un flujo de trabajo común, en lugar de configurar cada proveedor por separado. El producto satisfacía el requisito de red convencional: un prefijo o segmento de origen debe alcanzar un destino a través de una ruta permitida.

Esto no pretendía hacer desaparecer las diferencias entre nubes. AWS, Azure y Google Cloud ofrecen objetos, cuotas y comportamientos de enrutamiento distintos. Los espacios de direcciones solapados, las rutas asimétricas, los puntos finales privados y las fronteras específicas del proveedor seguían exigiendo ingeniería. Prosimo podía normalizar operaciones comunes y mostrar relaciones; los sistemas subyacentes conservaban sus propias restricciones.

Network Transit también asumía la segmentación. Los dominios y políticas de enrutamiento podían separar entornos o limitar la alcanzabilidad. El controlador debía entender dónde existía un segmento a través de las nubes y cómo los objetos nativos implementaban la frontera. Una política formulada una sola vez podía desencadenar múltiples cambios específicos del proveedor.

La ventaja era una interfaz unificada para la definición de políticas. El riesgo residía en la traducción entre el modelo común y las configuraciones nativas de la nube. Si la política común y la configuración de la nube divergían, la empresa podía creer que un segmento estaba protegido mientras el estado del proveedor decía lo contrario. La conciliación, la auditoría y los mensajes de error claros eran tan importantes como el flujo de trabajo de provisión inicial.

App Transit convertía la aplicación en el objeto de la decisión de enrutamiento

App Transit ampliaba el modelo más allá de las subredes. Podía incorporar el dominio de la aplicación, la identidad, el tipo de solicitud, el estado de la transacción, el riesgo y el rendimiento para decidir cómo un usuario o carga de trabajo alcanzaba un servicio. Era el intento más claro de Prosimo por diferenciar la plataforma de un enrutador de nube convencional.

La perspectiva de aplicación era útil porque los servicios modernos no siempre se representan limpiamente mediante direcciones fijas. Los servicios gestionados, los puntos finales SaaS y los componentes distribuidos pueden cambiar, mientras que la identidad de la aplicación sigue siendo significativa. Una política que haga referencia al servicio o al usuario puede ser más duradera que una regla basada únicamente en direcciones y puertos.

El modelo requería una correspondencia precisa. El controlador debía saber qué dominios y puntos finales pertenecían a una aplicación, qué dependencias necesitaban y en qué afirmaciones del proveedor de identidad se podía confiar. Un mapeo desactualizado podía dirigir una solicitud por la ruta equivocada o aplicar la regla de seguridad incorrecta. La abstracción de la aplicación no eliminaba la necesidad de comprender el estado de la red; añadía otra capa semántica encima.

La combinación de Network Transit y App Transit reconocía que en las empresas conviven ambos mundos. Los sistemas heredados, las subredes privadas y los controles basados en IP persisten, mientras que las aplicaciones más nuevas dependen de dominios, identidad y servicios gestionados. Full-Stack Cloud Transit era el nombre del producto para operar conjuntamente estos modelos, no para sustituir uno por otro.

La identidad ampliaba la decisión de enrutamiento y la frontera de confianza

El acceso orientado a las aplicaciones exigía la integración de la identidad. La plataforma podía utilizar el contexto del usuario o de la carga de trabajo para decidir si se establecía una conexión y cómo. Esto respaldaba una política de confianza cero, donde la mera ubicación no constituía una prueba suficiente de autoridad.

La identidad aumentaba la precisión y creaba otra dependencia. La política de enrutamiento o de aplicación dependía ahora del proveedor de identidad, de sus afirmaciones, del estado de la sesión y de los datos de grupo. Una ruta de red podía fallar por la indisponibilidad de la autenticación o por un cambio de atributo, aunque los enrutadores y los edges funcionaran correctamente. La resolución de problemas debía cruzar la frontera entre la operación de red y la de identidad.

Además, el controlador se convertía en un punto de concentración de contexto sensible. Podía almacenar topología, relaciones de aplicación, atributos de usuario, señales de riesgo y resultados de políticas. Este conjunto de datos mejoraba el diagnóstico y la optimización, pero ampliaba las consecuencias de un acceso no autorizado. Por tanto, el privilegio mínimo, la retención, la auditoría y la separación de funciones eran requisitos arquitectónicos, no añadidos administrativos.

El enfoque de Prosimo ilustra un cambio más amplio en 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 una plataforma, más útiles pueden ser sus decisiones, y con más cuidado debe controlarse su autoridad.

El descubrimiento de recursos creaba el grafo del que dependía cada decisión posterior

Un controlador entre nubes no puede gestionar lo que no ve. Prosimo desarrolló un descubrimiento de activos en la nube y mapas de VPCs, VNets, subredes, aplicaciones, conectividad y relaciones de seguridad. Estas vistas apoyaban la incorporación, el diseño, la resolución de problemas y las políticas.

La captura era estratégicamente importante porque los paisajes de nube cambian al margen de los flujos de trabajo centrales de red. Los equipos de aplicaciones pueden crear cuentas, redes, puntos finales y servicios gestionados mediante su propia automatización. Los diagramas mantenidos manualmente quedan obsoletos. Un inventario basado en API puede generar un grafo más actualizado, pero su integridad depende de la cobertura de cuentas, los permisos, la lógica de análisis y las API de los proveedores.

El grafo no era mera documentación, sino la estructura de datos a partir de la cual se calculaban el enrutamiento, la segmentación, la inserción de servicios y la optimización. Si faltaba un recurso o una dependencia, todas las conclusiones basadas en él podían ser erróneas. Por tanto, la topología necesitaba pruebas de procedencia: momento de la recopilación, cuenta de origen, regiones cubiertas y solicitudes fallidas.

El grafo también ayuda a explicar la adquisición. Palo Alto Networks puede generar valor de seguridad adicional si conoce dónde se encuentran las cargas de trabajo y las rutas de tráfico. Un sistema que descubre recursos en la nube y puede modificar rutas acorta el camino desde la compra de un cortafuegos de software hasta su colocación correcta. Bhau destacó más tarde expresamente el descubrimiento de recursos y la provisión acelerada de cortafuegos de software.

AIR derivaba recomendaciones operativas de la telemetría de los edges

Application-driven Intelligent Results, abreviado AIR, analizaba la telemetría de los edges AXI. La documentación de AWS describía información sobre el 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 el resultado de la política. La plataforma podía correlacionar datos de usuario, red y aplicación, en lugar de mostrar contadores de dispositivos aislados.

Esta correlación abordaba un conocido problema operativo. Una transacción lenta puede deberse a la ruta del usuario, al edge, al backbone de la nube, al servicio de seguridad o a la propia aplicación. Una visión entre capas puede acotar la búsqueda más rápido que consolas separadas y respaldar recomendaciones sobre ruta, ubicación, riesgo o coste.

La calidad de una recomendación dependía de la cobertura de telemetría y del modelo de interpretación. Un edge sólo veía el tráfico que lo atravesaba. Las dependencias externas de la aplicación y los estados internos del proveedor podían permanecer invisibles. Una recomendación podía señalar una dirección sin demostrar la causa.

La telemetría también tenía valor para la gobernanza. Las observaciones históricas podían explicar por qué había cambiado una ruta o una política. Al mismo tiempo, podían revelar información sensible sobre el uso de aplicaciones y el comportamiento de los usuarios. El material público no describe completamente la retención y la gobernanza de datos tras la adquisición; estos puntos siguen siendo parte de la diligencia debida de los clientes.

AWS ofrecía la implementación documentada más clara

El trabajo de Prosimo con AWS generó las pruebas técnicas públicas más sólidas. La empresa era compatible con AWS Transit Gateway, Cloud WAN, PrivateLink y el flujo de trabajo de despliegue de Marketplace for Containers Anywhere. AWS publicó una guía sobre la colocación de edges AXI, la incorporación de aplicaciones, la identidad, la seguridad y la optimización.

AWS Cloud WAN era especialmente significativo. Proporcionaba un backbone nativo de nube y un servicio de segmentación que Prosimo podía orquestar en lugar de sustituir. Esta arquitectura mostraba el modelo cooperativo: AWS poseía la red nativa y la infraestructura global; Prosimo aportaba directivas entre nubes, contexto de aplicación, software de edge y análisis.

El flujo de trabajo del Marketplace simplificaba el primer paso de despliegue al empaquetar el edge AXI a través de un canal autorizado. El trabajo posterior sobre permisos de cuenta, diseño de enrutamiento, alta disponibilidad, capacidad y operaciones seguía existiendo. La automatización del día cero puede reducir el esfuerzo de instalación sin eliminar el problema de control a largo plazo.

Una referencia nominal a Flexport respaldaba el caso de uso de AWS Cloud WAN en el material corporativo. Demuestra que un cliente empresarial apoyó públicamente la arquitectura, pero no constituye una auditoría independiente del alcance, el ahorro o la disponibilidad. Por tanto, los testimonios de clientes deben considerarse ejemplos de adopción y no una prueba general de rendimiento.

Azure y Google Cloud completaban la oferta multi-nube

Prosimo también era compatible con Microsoft Azure y Google Cloud. El material de producto describía la orquestación de Azure Virtual WAN y los objetos de red y servicio privado de Google Cloud. El objetivo era un modelo operativo común, manteniendo la red nativa de cada proveedor.

La compatibilidad con estas plataformas no demuestra funciones idénticas. Las API de nube maduran a ritmos diferentes, y nombres de producto comparables pueden ocultar semánticas distintas. Las rutas, los segmentos, los puntos finales privados y la inserción de servicios podían requerir un tratamiento específico del proveedor. Las pruebas disponibles no permiten elaborar una matriz completa de comparación funcional para todas las regiones y versiones.

Por tanto, la abstracción multi-nube se comprende mejor como un sistema de traducción. Puede estandarizar directivas y flujos de trabajo comunes, pero debe conservar los detalles que afectan a la seguridad, los costes y las interrupciones. Una plataforma se vuelve arriesgada cuando la superficie parece uniforme y las diferencias de implementación quedan ocultas a los operadores.

Lo mismo se aplica tras la adquisición. Palo Alto Networks puede utilizar el grafo común para colocar controles de seguridad en varias nubes, pero los proveedores de nube siguen controlando los objetos nativos que implementan la ruta. La propiedad de la capa de orquestación no otorga la propiedad de la red subyacente de la nube.

El producto evolucionó de la conectividad a un modelo de ciclo de vida

En 2023, Prosimo describía flujos de trabajo para diseñar, construir, solucionar problemas y operar redes multi-nube. El producto iba más allá de la configuración de túneles o puertas de enlace individuales. El descubrimiento de recursos respaldaba el diseño; la orquestación creaba conectividad; los mapas y la telemetría ayudaban en la resolución de problemas; las políticas y los estados históricos apoyaban la gestión continua.

La perspectiva del ciclo de vida ampliaba el círculo de compradores potenciales. Los ingenieros de redes podían utilizar la topología y el análisis de rutas; los equipos de plataforma de nube, incorporar cuentas y servicios; los equipos de seguridad, verificar la segmentación y la inspección; los equipos de migración, planificar cambios; los equipos de FinOps, examinar el impacto en el enrutamiento y la salida de datos. El valor de la plataforma aumentaba cuando varios grupos accedían al mismo conjunto de datos.

Una base de datos común puede desencadenar conflictos de gobernanza. Una plataforma central puede mostrar que la configuración nativa de un equipo de nube se desvía de la política corporativa. La organización debe decidir qué sistema es vinculante y quién autoriza la corrección. El software por sí solo no resuelve esta cuestión institucional.

El modelo de ciclo de vida también aumentaba los costes de cambio. Cuando un controlador gestiona el grafo de activos, las políticas, la telemetría, la ubicación de los edges y las integraciones de automatización, su sustitución exige algo más que cambiar una conexión. El cliente debe exportar o reconstruir el modelo operativo. Prosimo prometía reducir la fragmentación de la nube al tiempo que creaba la posibilidad de una dependencia del controlador.

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

Prosimo describía la segmentación desde la capa 3 hasta la 7. A nivel de red, los dominios de enrutamiento y los segmentos determinaban qué subredes o ubicaciones podían comunicarse. En niveles superiores, la identidad de la aplicación, el contexto del usuario y las propiedades de la transacción podían refinar la regla.

El modelo de capas podía reducir la brecha entre la zona de red y la política de aplicación. Un servicio de negocio podía autorizarse aunque se bloqueara la conectividad amplia de subred a subred. A la inversa, una ruta de red alcanzable podía denegarse si la identidad o el contexto de aplicación no coincidían.

Esto no convertía a Prosimo en un cortafuegos de nueva generación completo. La integración con Palo Alto Networks en 2024 separaba las tareas: Prosimo orquestaba rutas, segmentación e inserción de servicios; los VM-Series realizaban la inspección profunda. La distinción es importante porque el control de políticas y la aplicación de la seguridad fallan de manera diferente.

Un segmento solo es eficaz si se representan todas las rutas relevantes. Una ruta desconocida, una excepción nativa de la nube o una inserción de servicio fallida pueden eludir el control previsto. Por tanto, para garantizar la seguridad era necesario comparar la política declarada con el estado real del proveedor de nube y el tráfico observado; no bastaba con la vista de configuración del controlador.

La inserción de servicios vinculaba el control de enrutamiento con la economía de los cortafuegos

Al diseñar la seguridad en la nube hay que decidir dónde se realiza la inspección. Los cortafuegos centralizados pueden simplificar las políticas y reducir el número de appliances, pero generan backhaul, concentración y presión de escalado. Los cortafuegos distribuidos permanecen más cerca de las cargas de trabajo y reducen cierta distorsión de rutas, pero multiplican el despliegue, las licencias, las actualizaciones y la operación de políticas.

Prosimo admitía ambos patrones en la integración con VM-Series. Las políticas podían dirigir tráfico seleccionado a través de un punto de inspección central o mediante cortafuegos distribuidos en las VPC de aplicación. El controlador actualizaba las rutas circundantes mientras Palo Alto Networks proporcionaba la función de inspección.

Esto convertía la orquestación de enrutamiento en algo comercialmente valioso para un proveedor de seguridad. Un cortafuegos de software no puede proteger el tráfico que nunca le llega. El descubrimiento de recursos, la ubicación y los cambios de enrutamiento reducen el esfuerzo de insertar la capacidad de seguridad adquirida en una ruta activa. Este es un motivo estratégico plausible para que Palo Alto Networks adquiriera la tecnología de Prosimo.

Al mismo tiempo, se ampliaba el radio de impacto del controlador. Una política defectuosa puede eludir la inspección, crear bucles, provocar enrutamiento asimétrico o desactivar una aplicación. Las comprobaciones de estado del sistema, los cambios graduales, la simulación, la auditoría y la reversión son necesarios porque un error en la inserción de servicios es a la vez un evento de red y de seguridad.

La asociación de 2024 no debe considerarse retroactivamente como una adquisición

Prosimo y Palo Alto Networks anunciaron la integración con VM-Series el 12 de junio de 2024. El comunicado describía una solución técnica y comercial conjunta, pero no afirmaba que Palo Alto Networks hubiera adquirido Prosimo. Quien trate el anuncio como prueba de propiedad está fusionando dos eventos distintos.

No obstante, la asociación creó un puente. Prosimo pudo mostrar cómo su sistema de enrutamiento y políticas facilitaba el despliegue de los VM-Series en varias nubes. Palo Alto Networks pudo evaluar la tecnología en una integración real antes de la posterior transición de la empresa. Las pruebas públicas no describen el proceso de adquisición; afirmar que la asociación se diseñó formalmente como paso previo a la adquisición sería especulativo.

A principios de 2025, los perfiles de los fundadores y empleados habían cambiado. La página de la empresa mostraba más tarde un aviso de adquisición. A finales de 2025, Bhau declaró que la tecnología se había integrado por completo en productos de Palo Alto Networks. En conjunto, estos documentos respaldan la conclusión de la adquisición, pero dejan abiertos los mecanismos legales.

La secuencia es importante para la precisión editorial y para los clientes. Una asociación significa dos proveedores, dos estructuras de soporte y una frontera de integración definida. Una adquisición puede desplazar hojas de ruta, datos, contratos y autoridad hacia una sola empresa. La transición modifica algo más que la marca, aunque la ruta técnica parezca inicialmente similar.

Nebula hacía accesible el grafo topológico mediante una interfaz conversacional

Prosimo presentó Nebula en febrero de 2024 como parte de una suite de IA para redes multi-nube. El asistente debía responder en lenguaje natural a preguntas sobre redes solapadas, costes, estado de rutas, violaciones de políticas de seguridad y otras condiciones reflejadas en el grafo y la telemetría de la plataforma.

El activo valioso no era la interfaz de lenguaje en sí, sino el contexto estructurado entre nubes que había debajo. Un modelo generalista no puede diagnosticar una ruta o un segmento privado que no ve. Nebula podía aprovechar el inventario de activos, la topología, las políticas y las observaciones que Prosimo ya recopilaba. Esto convertía la inversión previa en un grafo común en relevante para AIOps.

El acceso conversacional podía hacer que los datos complejos fueran más accesibles para más operadores, pero también podía generar una confianza equivocada si una respuesta omitía un activo no compatible, malinterpretaba la pregunta o trataba una recomendación como una acción autorizada. Los cambios de alto riesgo seguían necesitando controles deterministas, límites de permisos y revisión humana.

Prosimo mencionaba posibles mejoras como una reducción del tiempo medio de resolución del 60 al 80 por ciento y una disminución de más del 60 por ciento en los costes de red en la nube. Estas cifras procedían de afirmaciones de la empresa en un anuncio de producto. Las pruebas disponibles no incluyen una metodología independiente ni una línea base de clientes que demuestre validez general. Pueden citarse como beneficios propuestos por Prosimo, no como hechos de mercado medidos.

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

El mismo anuncio de 2024 presentaba la arquitectura de Prosimo como útil para las cargas de trabajo de IA. Los sistemas de IA distribuidos pueden requerir acceso a datos privados, conexiones entre nubes y centros de datos, controles de cumplimiento y un enrutamiento que tenga en cuenta el comportamiento de la aplicación. Estos requisitos encajaban con el modelo existente de activos, políticas y rutas.

La denominación no modificaba la red subyacente. Prosimo seguía dependiendo de las redes de nube, los operadores y la infraestructura del cliente. La empresa no proporcionaba computación GPU ni software de desarrollo de modelos. Su posible papel era la capa de conectividad y seguridad para datos y servicios distribuidos.

El posicionamiento de IA era estratégicamente comprensible porque el valor de una topología entre nubes aumenta con datos y servicios más distribuidos. También era una categoría de marketing introducida poco antes del fin de la actividad empresarial independiente. Los documentos no demuestran ingresos separados por productos de IA, despliegues productivos nominales ni resultados de carga de trabajo auditados.

La conclusión duradera es que la telemetría multi-nube puede convertirse en una base para operaciones asistidas por máquinas. La pregunta actual sobre el producto es si Palo Alto Networks ha conservado este contexto y cómo lo hace accesible. La información pública disponible a la fecha de corte no ofrece una respuesta completa.

El modelo de negocio vendía software para infraestructura que Prosimo no poseía

El negocio independiente de Prosimo era un modelo de suscripción de software y servicios, no un modelo de operador. Los clientes desplegaban edges AXI en sus entornos y conectaban cuentas de nube con la capa de control. Los ingresos procedían probablemente de licencias o suscripciones, soporte, servicios profesionales y actividades de socios de canal; los precios concretos y las métricas contractuales no se hicieron públicos en las pruebas disponibles.

El modelo podía escalar sin fibra propia. Una plataforma de software coordinaba muchas regiones de nube y entornos de cliente. Sin embargo, esto no permite extraer conclusiones sobre los márgenes brutos. El soporte de ingeniería para las API de los proveedores, el ciclo de vida de los edges, las integraciones de seguridad y la provisión empresarial puede ser costoso, mientras que los recursos de nube consumidos por el edge probablemente los pagaba el cliente y no el proveedor.

Prosimo utilizaba los marketplaces de nube, los socios de integración y de canal, así como referencias nominales de clientes para llegar a las empresas. Estas relaciones no son equivalentes. Una ficha en un marketplace demuestra una vía de adquisición y despliegue. Una integración técnica demuestra que dos sistemas pueden combinarse en condiciones definidas. Una cita de cliente ofrece una referencia. Ninguna de ellas prueba por sí sola el número de clientes de pago o los ingresos recurrentes.

La amplitud de la oferta podía aumentar la complejidad de ventas. Los equipos de redes, seguridad, nube y aplicaciones podían beneficiarse, pero la responsabilidad presupuestaria podía ser difusa. El producto necesitaba un responsable de presupuesto que financiara una capa de control común, en lugar de financiar operaciones separadas para cada nube y cada equipo.

Socios, clientes e inversores desempeñaban papeles diferentes

Amazon Web Services era a la vez proveedor de red subyacente y socio de comercialización. Azure y Google Cloud eran entornos compatibles. Los proveedores de identidad suministraban el contexto de autenticación, mientras que los proveedores de cortafuegos realizaban la inspección. Los servicios de colocation y los operadores podían alojar o conectar los edges. Los socios de canal podían diseñar y operar los despliegues.

Flexport apareció como referencia nominal de cliente en el material sobre AWS Cloud WAN. La referencia muestra interés empresarial en la arquitectura, pero no revela el alcance completo, la duración ni el valor comercial del despliegue. No debe servir como representante de toda la base de clientes.

General Catalyst lideró la Serie A y estaba vinculada a la gobernanza a través de su papel de inversor. Inversores relacionados con WRVI o Celesta aparecían en el material corporativo; las comunicaciones posteriores de Prosimo mencionaban una participación destacada adicional, incluida una denominación vinculada a BlackRock, cuyo vehículo de inversión exacto no se determinó en la investigación. Estos documentos muestran una base de financiación bien conectada, no una tabla de capitalización completa.

Palo Alto Networks ocupó la posición más decisiva: de socio de seguridad en 2024 pasó a ser el comprador a principios de 2025. La secuencia muestra cómo una dependencia del ecosistema se convierte en una relación de control cuando un participante compra la capa de software que coordina la ruta hacia su producto.

Se recaudaron al menos 55 millones de dólares; el resultado económico de la venta de la empresa sigue siendo desconocido

La financiación verificada consiste en una Serie A de 25 millones de dólares en abril de 2021 y una Serie B de 30 millones de dólares en 2022. El total asciende a al menos 55 millones de dólares. Las pruebas aportadas no incluyen una tabla de capitalización auditada ni información sobre la valoración, la estructura de deuda o rondas de financiación posteriores.

El precio de adquisición no se ha hecho público ni se ha confirmado de forma independiente. Sin conocer el precio, el resultado no puede clasificarse de forma responsable como prima estratégica, compra modesta de tecnología, adquisición de talento o venta forzosa. La integración continua del producto demuestra valor tecnológico, pero no revela el rendimiento para los inversores o fundadores.

Los ingresos y la posición de mercado de Palo Alto Networks tras la adquisición no deben atribuirse a Prosimo. En cuanto la startup dejó de ser observable por separado, ya no había un segmento independiente de ingresos, beneficios o clientes que analizar. Un propietario más grande puede hacer que la tecnología esté más disponible, al tiempo que hace menos visible su importancia económica independiente.

La ausencia de un comunicado formal de adquisición es en sí misma relevante. Normalmente, los clientes, empleados e investigadores utilizan este tipo de comunicados para determinar el momento, el soporte y la justificación estratégica. Aquí, el estado debe reconstruirse a partir de perfiles profesionales, una etiqueta en la página corporativa y una declaración posterior del fundador. Esto basta para corregir el estado de la empresa, pero no para inventar detalles de la transacción.

La competencia procedía de plataformas, nubes y desarrollo interno

Prosimo competía con plataformas especializadas en redes multi-nube 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 un modelo de «hazlo tú mismo», en el que las empresas utilizan directamente infraestructura como código, servicios de tránsito del proveedor, tablas de enrutamiento y cortafuegos. Cada alternativa resolvía diferentes partes del mismo problema.

Un controlador especializado podía ofrecer un modelo de topología y políticas entre proveedores. Un diseño nativo de nube podía reducir la dependencia de terceros y estar estrechamente adaptado a un proveedor. Un servicio basado en operador podía proporcionar transporte físico. Una plataforma SASE o de seguridad podía unir conectividad y aplicación. El desarrollo interno podía preservar el control, pero aumentaba el esfuerzo de personal e integración.

La diferenciación de Prosimo residía en la combinación de tránsito de aplicación y de red, edges distribuidos, orquestación nativa de nube, topología, telemetría e inserción de servicios. Esa misma amplitud dificultaba las comparaciones. Los compradores debían probar los servicios de nube, las rutas, los sistemas de identidad y los patrones de seguridad concretos que pretendían utilizar, en lugar de comparar nombres de categorías.

La adquisición modifica el marco competitivo. Prosimo ya no tiene que triunfar como proveedor independiente, pero su tecnología debe demostrar su valor dentro de Palo Alto Networks. Lo decisivo es si el descubrimiento integrado de recursos y la orquestación de enrutamiento mejoran la provisión de los productos de seguridad de Palo Alto Networks y si los clientes aceptan la dependencia de la plataforma resultante.

Los servicios nativos de nube eran a la vez base y sustituto

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN y los servicios de red de Google Cloud ofrecían a las empresas potentes opciones nativas. Prosimo dependía de estos servicios y, al mismo tiempo, competía con su uso directo por parte de los clientes.

Esta relación creaba una frontera móvil. Si un proveedor de nube añadía enrutamiento global, segmentación, acceso a servicios privados o políticas centralizadas, algunas funciones de terceros resultaban más fáciles de replicar de forma nativa. Al mismo tiempo, cada nuevo servicio nativo añadía otro objeto que un controlador entre nubes podía descubrir y coordinar. Los avances de los proveedores de nube podían reducir parte del valor de Prosimo y, a la vez, aumentar la necesidad de traducción entre proveedores.

El factor decisivo era tanto organizativo como técnico. Una empresa que operara en una sola nube y con un sólido equipo de ingeniería interna podía preferir herramientas nativas. Una empresa multi-nube con equipos fragmentados podía preferir un plano de control común. Una organización regulada podía preferir un plano de control y evidencia independiente, aunque temiera las credenciales privilegiadas y la concentración de datos.

Ninguna arquitectura eliminaba el lock-in. Las herramientas nativas aumentaban la dependencia de las API y la semántica de un proveedor de nube. Un controlador entre nubes aumentaba la dependencia de su grafo, sus políticas y su software de edge. La pregunta pertinente era si esa dependencia era visible, portable y adecuada al modelo operativo de la organización.

Los fallos podían producirse en el controlador, en el edge, en las API de nube, en el sistema de identidad o en la red subyacente

La arquitectura distribuida de Prosimo reducía la dependencia de un hub de tráfico, pero creaba múltiples dominios de fallo interconectados. El servicio central podía fallar o contener directivas obsoletas. Un edge podía fallar o quedar aislado. Una API de nube podía rechazar parte de un cambio. El proveedor de identidad podía caer. La red subyacente podía perder capacidad o tomar una ruta inesperada. Un cortafuegos insertado podía agotar sus recursos.

Los fallos parciales son especialmente difíciles. Un proveedor puede aceptar un cambio de enrutamiento mientras que otro lo rechaza. Entonces, el estado pretendido por el controlador difiere del estado real de la nube. El tráfico puede volverse asimétrico o eludir la inspección. Un sistema fiable necesita conciliación, operaciones idempotentes, cambios graduales, estados de error claramente señalizados y una reversión que tenga en cuenta el comportamiento de cada proveedor.

Las pruebas públicas describen la disponibilidad y la optimización a alto nivel, pero no incluyen un estudio independiente de inyección de fallos, un historial completo de incidentes ni resultados de nivel de servicio generalizables. Por tanto, las afirmaciones sobre resiliencia deben vincularse a la arquitectura documentada o a experiencias de clientes nominales.

La adquisición introduce otro dominio de fallo: la continuidad del producto. Los clientes deben saber qué consola, qué API, qué imagen de edge, qué modelo de políticas y qué organización de soporte sustituyen al histórico sistema de Prosimo. Una integración de código técnicamente exitosa puede generar riesgos de migración si las fronteras comerciales y operativas no están claras.

Las credenciales de nube 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 de nube. Un inventario de solo lectura podía funcionar con permisos limitados; los cambios en rutas, segmentos e inserción de servicios exigían permisos más amplios. El controlador se situaba así en el plano de gestión privilegiada, aunque no poseyera las cargas de trabajo.

Un compromiso de las credenciales podía exponer la topología o permitir cambios generalizados. Un error de software o de operación podía propagar políticas por varias nubes. El riesgo crecía con la utilidad de la plataforma: cuantas más cuentas y servicios pudiera gestionar, mayor era el radio de impacto potencial.

Las empresas necesitaban roles de privilegio mínimo, credenciales separadas para el descubrimiento y la modificación, aprobación multiparte, auditorías completas, rotación, revocación de emergencia y una ruta de recuperación que no dependiera exclusivamente del mismo controlador. El material público no contiene una evaluación de seguridad completa e independiente; estos puntos siguen siendo controles de despliegue necesarios y no garantías de producto verificadas.

El grafo de telemetría era igualmente sensible. Podía exponer nombres de aplicaciones, estructura de red, políticas, relaciones de usuario, estado de rutas y patrones de costes. La gobernanza posterior a la adquisición debería aclarar dónde se almacenan los datos, a qué productos de Palo Alto Networks pueden acceder y cómo se migraron los permisos de los clientes existentes. El estado público no responde a estas preguntas.

La adquisición desplazó una capa neutral respecto a la nube hacia una plataforma de seguridad

La posición independiente de Prosimo le permitía presentarse como una capa común por encima de las nubes y los servicios de seguridad. Con Palo Alto Networks como propietario, los incentivos cambiaron. La tecnología adquirida podía facilitar el despliegue de VM-Series y otros productos de Palo Alto Networks. Esto puede crear una experiencia más integrada, pero también plantea preguntas sobre el soporte a servicios de inspección de terceros.

La propiedad no demuestra que la neutralidad haya desaparecido. Los documentos no contienen una matriz de socios actual ni una arquitectura de producto actual. Sin embargo, cambian la pregunta que los clientes deberían hacerse. Hay que comprobar si el controlador de enrutamiento permanece abierto a varios proveedores de seguridad, si las políticas y la telemetría son exportables y si la optimización favorece la cartera del propietario.

La declaración de integración hacía hincapié en la inspección de ingreso, egreso y este-oeste. Esto sugiere que la topología y la orquestación de Prosimo pasaron a formar parte de un sistema de provisión de funciones de seguridad, pero no demuestra que las funciones históricas de App Transit, el acceso de usuarios, la optimización de costes o todos los flujos de trabajo de red en la nube persistan como capacidades separadas.

Se trata de un patrón de infraestructura frecuente. Una startup abstrae un difícil problema de coordinación; un gran proveedor de plataformas compra la abstracción porque aumenta el uso y el control de su producto principal. El comprador obtiene una vía más rápida hacia la provisión. El cliente puede ganar integración y perder parte de su independencia del proveedor.

La asignación actual de productos es la mayor laguna de información

La información pública confirma la adquisición y la integración, pero no contiene una correspondencia completa de AXI, Network Transit, App Transit, AIR y Nebula con los productos o SKU actuales de Palo Alto Networks. Tampoco hay plazos de soporte heredado, procedimientos de migración ni una comparación funcional para la continuidad del producto.

Esta laguna impide una evaluación del producto en el presente. Las descripciones históricas explican lo que Prosimo construyó y por qué era importante, pero no dicen qué funciones están disponibles, licenciadas o soportadas hoy. Las recomendaciones de despliegue actuales deben basarse en la documentación actual de Palo Alto Networks, no en comunicados archivados de Prosimo.

La falta de correspondencia también limita el análisis estratégico. Una asimilación completa del grafo topológico y de la capa de orquestación sería diferente del uso selectivo del descubrimiento de activos y la colocación de cortafuegos. Lo primero daría lugar a un amplio servicio de control multi-nube; lo segundo utilizaría Prosimo sobre todo para acelerar la provisión de funciones de seguridad. La declaración del fundador apoya la continuidad de la tecnología, pero deja abierta esa frontera arquitectónica.

Un futuro documento de producto, una guía de migración o un estudio de caso de cliente podrían resolver gran parte de la incertidumbre. Hasta entonces, la formulación precisa es: según un cofundador, la tecnología de Prosimo se ha integrado en productos de Palo Alto Networks; el alcance y el empaquetado del producto no están verificados.

¿Quién controla el enrutamiento multi-nube?

Ninguna parte controla la totalidad de la ruta. La empresa posee las cuentas, define los objetivos de negocio y el diseño de las aplicaciones, y asigna las credenciales. Un controlador entre nubes puede capturar la topología, traducir políticas, elegir rutas y modificar el estado de enrutamiento nativo. Los proveedores de nube controlan las API, los servicios de tránsito, los puntos finales privados, el backbone y muchos dominios de fallo. Los operadores y proveedores de colocation controlan otras partes del transporte. Los servicios de seguridad deciden si se permite el tráfico inspeccionado.

Prosimo aspiraba a la posición intermedia más útil estratégicamente: no poseía la red subyacente, pero pretendía controlar el grafo y la traducción de políticas por encima de ella. Quien controla esa capa puede decidir qué activos son visibles, cómo se representan los segmentos, dónde se colocan los edges, qué servicio inspecciona el tráfico y qué telemetría se considera vinculante. Eso es el control operativo del enrutamiento, aunque la fibra pertenezca a otro.

Tras la adquisición, Palo Alto Networks posee la tecnología restante de Prosimo y decide cómo se integra, empaqueta y desarrolla. Los proveedores de nube siguen siendo soberanos en sus entornos; la empresa puede revocar las credenciales o elegir otra arquitectura. Sin embargo, la salida puede resultar costosa si la topología, las políticas y los flujos de trabajo operativos se han vuelto dependientes del controlador.

Por tanto, la respuesta es estratificada y no absoluta: la empresa autoriza; el controlador coordina; los proveedores de nube y los operadores transportan; la plataforma de seguridad aplica. La historia de Prosimo muestra que la propiedad de la capa coordinadora puede cambiar sin que una cuenta de nube o una ruta física cambie de dueño.

Fuentes principales

Por qué Prosimo sigue siendo relevante tras la adquisición

Prosimo captó un cambio real en la infraestructura. El objeto de la operación de red se está desplazando del dispositivo y el prefijo hacia la aplicación, la identidad, las dependencias de servicio y el grafo de políticas. Las API nativas de la nube hacen que el estado de la red sea programable; los edges de software distribuidos hacen que el punto de aplicación sea móvil. Un controlador con visibilidad sobre varias nubes puede coordinar acciones que ninguna consola de nube por sí sola puede ejecutar.

La empresa también mostró los costes de esa coordinación. Una capa común necesita credenciales privilegiadas, mantenimiento continuo de API, descubrimiento preciso, traducción semántica, telemetría y disciplina operativa. Puede reducir el trabajo fragmentado y crear un nuevo punto de concentración. El mismo sistema que simplifica el enrutamiento puede ampliar el radio de impacto de una decisión errónea.

La adquisición por parte de Palo Alto Networks hace más visible la cuestión del control. La red y la seguridad convergen en la inserción de servicios, el descubrimiento de cargas de trabajo y el control de políticas. Un proveedor de seguridad que conoce la topología y puede modificar rutas no se limita a inspeccionar el tráfico que se le presenta; puede influir en qué tráfico llega a la inspección y dónde.

Por tanto, Prosimo no debe considerarse una marca independiente fracasada ni una prueba de que una sola plataforma haya resuelto el problema multi-nube. Su contribución duradera fue la definición del grafo entre nubes como infraestructura. La pregunta pendiente es si ese grafo, dentro de una empresa de seguridad más grande, sigue siendo lo bastante transparente, portable y controlable para merecer la confianza de los clientes.