Resumen

  • Prosimo se fundó en 2019 y recaudó al menos 55 millones de dólares en las rondas A (2021) y B (2022); no desveló ingresos auditados, valoración ni precio de adquisición.
  • AXI combinó intención, topología, análisis centralizados y bordes distribuidos que detectan activos en la nube, conectan aplicaciones e incorporan servicios de seguridad, sin poseer infraestructura física de red.
  • La integración de VM-Series anunciada en junio de 2024 precedió la transición de Prosimo a Palo Alto Networks cerca de febrero de 2025; ninguna fuente precisa la fecha ni el precio de adquisición, ni el mapa de productos actual.
  • El control sigue repartido entre empresas, software de orquestación, proveedores de nube y Palo Alto Networks; por tanto, la portabilidad de la topología, los datos, las políticas y la autoridad de enrutamiento se convierte en la prueba crítica para los clientes.

La empresa desapareció antes de que desapareciera el problema

No se puede presentar a Prosimo con exactitud como un proveedor independiente activo en 2026. Los registros públicos muestran que sus fundadores y varios empleados se fueron a Palo Alto Networks alrededor de febrero de 2025. La identidad corporativa lleva también la etiqueta “Adquirida”, y el exdirector de tecnología, Nehal Bhau, escribió posteriormente que la tecnología se integró en los productos de Palo Alto Networks. Las evidencias confirman el cambio de control y la persistencia del valor técnico, pero no precisan la fecha de la firma ni del cierre, ni la forma jurídica o el precio de la operación.

Es necesario situar esta corrección al principio porque modifica el tiempo verbal de cada afirmación sobre el producto. AXI, Network Transit, App Transit, Application-driven Intelligent Results y Nebula fueron capacidades documentadas de Prosimo durante su etapa independiente. No deben presentarse como productos actuales que se venden por separado, a menos que Palo Alto Networks publique un mapa de productos y de soporte contemporáneo. La arquitectura histórica puede subsistir tras la adquisición en forma de código integrado, servicio compartido, módulo de software o activo de ingeniería interno, pero estos resultados no son equivalentes.

La desaparición de la marca no convierte el problema subyacente en algo obsoleto. Las empresas siguen repartiendo cargas de trabajo entre Amazon Web Services, Microsoft Azure, Google Cloud, centros de datos propios, ubicaciones de colocation, plataformas de software como servicio y usuarios remotos. Cada entorno tiene sus propias rutas, pasarelas, puntos finales, controles de identidad, servicios de seguridad, cuotas y reglas de facturación. La empresa puede poseer las cuentas, pero carece de una visión unificada de cómo transita la demanda entre ellas. La importancia de Prosimo radica en su intento de proporcionar esa visión.

Por consiguiente, la adquisición constituye el eje de la historia, no su conclusión. Prosimo creó una capa de control multinube capaz de descubrir activos, interpretar el contexto de las aplicaciones y dirigir el tráfico a través de servicios de seguridad. Palo Alto Networks apareció primero como un socio técnico cuyos cortafuegos VM-Series podían insertarse en esas rutas, y más tarde se convirtió en propietario de la tecnología. La línea divisoria entre la orquestación del enrutamiento y la inspección profunda se trasladó al interior de una única plataforma de ciberseguridad.

El enrutamiento multinube es una pugna por el contexto

Una tabla de enrutamiento puede indicar si un prefijo es accesible a través de un siguiente salto, pero no explica qué aplicación quería alcanzar el usuario, si quien solicita el acceso es de confianza, si un servicio de inspección debería ver el tráfico, si hay disponible un punto final privado, si una ruta en la nube es más cara que otra o si la transacción falla después de que el paquete llegue. Las operaciones multinube convierten estas preguntas en un problema de control compartido.

La tesis de Prosimo era que la autoridad de enrutamiento debía apoyarse en información que fuera más allá de la alcanzabilidad de capa 3. Su software intentaba reunir el inventario de las nubes, el estado de la red, la identidad de la aplicación, la identidad del usuario, el riesgo, el rendimiento y la telemetría de las transacciones. Ese contexto más amplio permitía expresar políticas como conectar una aplicación concreta, aislar un segmento, elegir un punto de entrada o dirigir tráfico seleccionado a través de un cortafuegos.

El valor no procedía de crear una nueva ruta de fibra, sino de decidir cómo componer las rutas y los servicios ya existentes.

Esta diferencia explica que la empresa utilizara la expresión “arquitectura de experiencia de aplicación”. La frase situaba la solicitud de la aplicación por encima del componente de red individual. Una VPC, una VNet, una subred, un hub de tránsito o un enlace privado se convertían en un componente de una ruta de extremo a extremo, no en el objeto final de la gestión. El enfoque empujó al producto hacia varios mercados a la vez: redes en la nube, entrega de aplicaciones, acceso de confianza cero, aseguramiento de la red, optimización de costes e inserción de servicios de seguridad.

Esa amplitud generó oportunidad y ambigüedad al mismo tiempo. Un producto que toca a varios equipos puede resolver fallos de coordinación que ningún equipo posee por sí solo, pero también resulta difícil de evaluar, porque los equipos de redes, seguridad, nube, aplicaciones y finanzas utilizan definiciones de éxito distintas. Prosimo tenía que demostrar que un único modelo multinube mejoraba las operaciones sin convertirse en otra capa de privilegio cuyos errores afectaran a todos los entornos.

Lo que era Prosimo y lo que queda de ella

Prosimo era una empresa privada de software de redes en la nube, fundada en 2019 y con sede en el área de la bahía de San Francisco. Ramesh Prabagaran era cofundador y consejero delegado, mientras que Nehal Bhau era cofundador y director de tecnología durante la etapa independiente. Los registros públicos también identifican a Linus Aranha y Pradeep Aragonda en funciones fundacionales o de ingeniería sénior, aunque sus denominaciones exactas deben vincularse a trayectorias profesionales fechadas.

La plataforma principal era Application eXperience Infrastructure, conocida como AXI. AXI empleaba una capa de software centralizada para la intención, la topología, el análisis y la orquestación, con copias de AXI Edge distribuidas en regiones de nube, entornos de colocation o infraestructura local adyacente. Más tarde, la empresa organizó la oferta bajo el nombre de Full-Stack Cloud Transit, de modo que Network Transit y App Transit abordaban distintas categorías de conectividad. AIR analizaba las métricas y ofrecía información operativa, y Nebula añadió una interfaz conversacional en 2024.

Prosimo no era un transportista de nube. No poseía una red troncal global de fibra que conectara todas las regiones. La ruta podía atravesar las redes troncales de los proveedores de nube, la Internet pública, circuitos directos, enlaces de colocation o redes empresariales. Tampoco era un proveedor de cortafuegos en el mismo sentido que Palo Alto Networks. Su papel en la integración de 2024 era el descubrimiento, la segmentación y el enrutamiento, mientras que VM-Series se encargaba de la inspección de seguridad profunda.

Tras la adquisición, la descripción más segura es “linaje tecnológico”. La declaración posterior sobre la integración destaca el descubrimiento de activos multinube y la aceleración en el despliegue de cortafuegos virtuales para inspeccionar el tráfico de entrada, salida y este-oeste. Esto prueba que se conservan componentes importantes de Prosimo, no que el catálogo histórico de AXI, su paquete comercial o el modelo de atención al cliente continúen sin cambios.

El problema que vino después de SD-WAN

El equipo fundador procedía de experiencias en redes de área amplia, entrega de aplicaciones e infraestructura en la nube. Prosimo también nació del ecosistema más amplio de fundadores e ingenieros vinculados a Viptela, la empresa que ayudó a consolidar la SD-WAN como categoría empresarial. Pero el problema siguiente era distinto. La SD-WAN simplifica el acceso de las sucursales a las redes y las aplicaciones, pero no crea un modelo operativo único dentro de varias nubes públicas y entre ellas.

Una aplicación multinube puede depender de un punto final web en un entorno, de una base de datos o un servicio gestionado en otro, de un proveedor de identidad externo a ambos, de una conexión privada a un centro de datos y de una inspección de seguridad en perímetros seleccionados. Cada dependencia se puede representar con un objeto nativo diferente. El equipo de redes ve prefijos y hubs de tránsito; el equipo de nube ve cuentas y relaciones entre recursos; el responsable de la aplicación ve dominios y transacciones; el equipo de seguridad ve zonas y políticas de inspección.

Prosimo partió de la demanda, no de la sucursal. La pregunta era cómo debía un usuario o una carga de trabajo alcanzar una aplicación con un nivel aceptable de seguridad, rendimiento, disponibilidad y coste. Este encuadre desplazó el tema del enrutamiento, que pasó de ser solo un prefijo de destino a ser una transacción que transporta contexto de identidad y de aplicación. También obligó a la plataforma a recopilar y mantener mucha más información de la que necesita un enrutador tradicional.

El momento era oportuno. 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 proveedor, pero las API, los objetos y los modelos de política seguían siendo propietarios. La oportunidad de Prosimo consistía en orquestar esos servicios, en lugar de obligar a cada cliente a sustituirlos por una red troncal privada y separada.

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

Prosimo se fundó en 2019, pero no anunció su lanzamiento público hasta el 6 de abril de 2021. General Catalyst lideró una ronda de serie A de 25 millones de dólares en el momento del lanzamiento. El inversor describió la oportunidad desde la perspectiva de ofrecer experiencia de aplicación a través de las nubes, en sintoní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 mercado abarrotado y con fronteras inestables. Los proveedores de nube facilitaban el consumo de sus propios servicios de red. Los proveedores de SD-WAN y SASE extendían las políticas a los entornos de nube. Las empresas de entrega de aplicaciones podían optimizar las solicitudes y las empresas de seguridad de redes podían inspeccionarlas. El argumento de Prosimo se basaba en reunir estas funciones en una arquitectura orientada a la nube sin pretender que sustituiría todos los sistemas perimetrales.

La financiación dio a la empresa espacio para desarrollar integraciones, bordes de software, analítica, organización comercial y relaciones con socios, pero no demostró el encaje producto-mercado, la escala de ingresos ni la diferenciación sostenible. Las evidencias presentadas no incluyen ingresos auditados, ingresos recurrentes anuales, número de clientes ni valoración. El historial de financiación muestra el compromiso de los inversores con una tesis, no una imagen completa del rendimiento operativo.

En 2022, Prosimo cerró una ronda de serie B de 30 millones de dólares que se describió como sobresuscrita. Las dos rondas claramente identificadas suman un total documentado de al menos 55 millones de dólares. Algunas bases de datos muestran una cifra mayor cuando duplican anuncios o registros relacionados; esos agregados no deben utilizarse sin conciliar los hechos subyacentes.

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 el trabajo entre una capa centralizada de control y análisis y bordes de software distribuidos. La capa centralizada conservaba la intención de aplicación y de red, descubría activos, construía la topología, vinculaba identidades, analizaba métricas y coordinaba los cambios. Los bordes AXI se desplegaban cerca de las cargas de trabajo o de los usuarios, de modo que aplicaban la política sin obligar a cada ruta a regresar a un hub físico lejano.

Esta separación se asemeja a la de otros sistemas definidos por software, pero los objetos eran nativos de nube y tenían en cuenta las aplicaciones. El controlador necesitaba acceder a las cuentas y a las API de la nube, mientras que el borde necesitaba conectarse a los servicios de tránsito nativos, a las redes de las cargas de trabajo y a las rutas privadas o externas. La autoridad de la plataforma procedía de combinar dos perspectivas: una intención global por encima de las nubes y una ejecución local cercana al tráfico relevante.

La arquitectura también creaba un límite práctico para el despliegue. Cada borde consumía recursos de nube, requería un diseño de alta disponibilidad y debía actualizarse, supervisarse y protegerse. La capa de control necesitaba credenciales con privilegios suficientes para descubrir activos y modificar el estado de la red. La empresa obtenía un flujo de trabajo compartido, pero añadía un nuevo sistema de gestión cuya disponibilidad y salud afectaban al acceso en producción.

Prosimo utilizó en ocasiones el lenguaje del “networking autónomo en la nube”. Las evidencias respaldan la automatización, las recomendaciones y la orquestación basada en API, pero no una red que funcione de forma independiente respecto de la política humana, los servicios del proveedor de nube o el transporte subyacente. Los operadores seguían definiendo la intención, aprobando el acceso, gestionando las excepciones y asumiendo la responsabilidad del resultado.

AXI Edge era una decisión de ubicación, no una máquina virtual genérica

Un AXI Edge se podía desplegar en una VPC o VNet de nube, en un entorno de colocation o en una infraestructura adyacente. La explicación técnica de AWS mostraba una VPC de borde conectada a las VPC de las cargas de trabajo mediante Transit Gateway, con la posibilidad de encadenar un cortafuegos y de acceder desde usuarios remotos o ubicaciones locales. El diseño situaba el punto de ejecución de Prosimo dentro de la topología de la nube, no en un perímetro empresarial distante.

La ubicación no solo influía en la latencia: determinaba dónde entraba el tráfico en el dominio de la política, qué red troncal de nube o ruta de Internet utilizaba, dónde se producían el cifrado y la inspección, y qué métricas podía recoger la plataforma. Un borde mal ubicado podía provocar desvíos o costes innecesarios, mientras que uno bien colocado acortaba la ruta o mantenía el tráfico próximo a la carga de trabajo.

El despliegue distribuido multiplicaba los dominios de fallo que era necesario gestionar. La capacidad, las versiones de software, el diseño de la región de nube, las distancias entre rutas y los permisos de acceso podían variar según la región. La alta disponibilidad exigía algo más que ejecutar dos copias: el controlador, las tablas de rutas, los servicios de seguridad y las rutas de retorno debían ponerse de acuerdo sobre el estado de la conmutación por error.

El borde formaba parte, por tanto, de un sistema operativo más amplio. Su valor dependía de que el descubrimiento de activos, la topología, la política y la analítica se mantuvieran coherentes con el entorno de nube circundante. Tratarlo como un dispositivo virtual aislado supone ignorar la arquitectura que Prosimo intentaba vender.

La infraestructura siempre fue propiedad de otro

Prosimo orquestaba el transporte, pero no poseía la ruta física. La trayectoria de la aplicación podía utilizar la red troncal de AWS o de otro proveedor de nube, una conexión a Internet pública, Direct Connect o ExpressRoute, un servicio de colocation, un circuito de un operador o una red empresarial. La plataforma podía elegir y coordinar entre las opciones disponibles, pero no podía eliminar la latencia, la pérdida de paquetes, los dominios de fallo ni las reglas de tarificación que imponen esas entidades.

Este límite es importante a la hora de evaluar las afirmaciones de rendimiento. El controlador podía seleccionar una ruta observada como mejor o acercar el punto de entrada al usuario, pero no podía garantizar que un operador no fallara, que una región de nube siguiera disponible o que una dependencia externa respondiera con rapidez. La experiencia de la aplicación también incluye DNS, procesamiento del servidor, almacenamiento, comportamiento del navegador y servicios de terceros que escapan al control total de la plataforma.

La ausencia de una red troncal propia no era solo una debilidad. Permitía a Prosimo utilizar infraestructura que las empresas ya habían adquirido y aprovechar la inversión de los proveedores de nube. Podía acceder a regiones sin tender fibra y orquestar sistemas nativos como AWS Cloud WAN. La contrapartida era la dependencia de la estabilidad de las API, las cuotas de servicio, las condiciones comerciales y la semántica de cada proveedor.

Por ello, la afirmación de la plataforma se refería al control operativo, no a la propiedad física. Intentaba hacer que infraestructuras heterogéneas funcionaran como un único sistema gestionado, al tiempo que conservaba sus ventajas nativas. Si esta abstracción reducía la dependencia del proveedor o simplemente la desplazaba dependía de la portabilidad de la política, la topología y el despliegue de los bordes.

Network Transit gestionaba la alcanzabilidad entre objetos de red

Network Transit se centraba en las VPC, VNet, subredes, regiones, ubicaciones y segmentos. Orquestaba los servicios de tránsito y las rutas nativas de la nube para que los equipos construyeran la conectividad mediante un flujo de trabajo compartido, en lugar de configurar cada proveedor por separado. Resolvía así el requisito tradicional de red: un prefijo o segmento de origen debe alcanzar un destino a través de una ruta permitida.

Esto no implica que las diferencias entre nubes desaparecieran. AWS, Azure y Google Cloud ofrecen objetos, cuotas y comportamientos de enrutamiento diferentes. Los espacios de direcciones solapados, las rutas asimétricas, los puntos privados y los límites de los servicios propietarios de cada proveedor seguían exigiendo ingeniería. Prosimo podía unificar las operaciones comunes y mostrar relaciones, pero los sistemas subyacentes conservaban sus restricciones.

Network Transit también incorporaba la segmentación. Los dominios de enrutamiento y las políticas podían separar entornos o restringir el acceso. El controlador debía entender dónde existía un segmento a través de las nubes y cómo lo aplicaban los objetos nativos. Una política declarada una sola vez podía traducirse en varios cambios específicos de cada proveedor.

La ventaja era una superficie de intención unificada. El riesgo residía en la traducción. Si la política compartida se desvinculaba de la configuración de la nube, la empresa podía creer que un segmento estaba protegido mientras que el estado del proveedor decía lo contrario. Por eso eran tan importantes la conciliación, la auditoría y la notificación explícita de fallos como el propio flujo de aprovisionamiento.

App Transit convirtió la aplicación en un objeto de enrutamiento

App Transit amplió el modelo más allá de las subredes. 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 para decidir cómo un usuario o una carga de trabajo alcanza un servicio. Este fue el intento más claro de Prosimo de diferenciar su plataforma de un enrutador de nube tradicional.

La visibilidad de la aplicación era útil porque los servicios modernos no siempre se representan limpiamente con direcciones fijas. Las plataformas gestionadas, los puntos SaaS y los componentes distribuidos pueden cambiar mientras la identidad de la aplicación sigue siendo significativa. Una política que haga referencia al servicio o al usuario puede durar más que una regla escrita únicamente con direcciones y puertos.

El modelo requería un descubrimiento preciso. El controlador necesitaba saber qué dominios y puntos pertenecían a una aplicación, qué dependencias eran necesarias y en qué afirmaciones del proveedor de identidad confiar. Un mapa desactualizado podía enviar una solicitud por una ruta incorrecta o aplicar una regla de seguridad equivocada. La abstracción de la aplicación no eliminaba la necesidad de comprender el estado de la red; simplemente añadía otra capa semántica por encima.

Reunir Network Transit y App Transit reconocía que dentro de las empresas existen dos mundos. Los sistemas heredados, las redes privadas y los controles basados en IP permanecen, mientras que las aplicaciones más nuevas dependen de dominios, identidades y servicios gestionados. Full-Stack Cloud Transit era el nombre del producto que operaba ambos modelos juntos, en lugar de forzar a uno a sustituir al otro.

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

El acceso sensible a la aplicación necesitaba la integración de identidad. La plataforma podía utilizar el contexto del usuario o de la carga de trabajo para decidir si se establecía la conexión y cómo. Esto permitía una política de tipo confianza cero, en la que la ubicación por sí sola no bastaba como prueba de autorización.

La identidad mejoraba la precisión, pero añadía otra dependencia. La política de la ruta o de la aplicación pasaba a depender del proveedor de identidad, sus afirmaciones, el estado de la sesión y los datos de los grupos. Una ruta podía fallar porque la autenticación no estuviera disponible o porque un atributo hubiera cambiado, incluso cuando los enrutadores y los bordes estuvieran en buen estado. La resolución de problemas cruzaba la frontera 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 almacenar topología, relaciones de aplicaciones, atributos de usuario, señales de riesgo y resultados de políticas. Esto mejoraba el diagnóstico y la optimización, pero agravaba las consecuencias del acceso no autorizado. Por eso, los privilegios mínimos, la retención de datos, la auditoría y la separación de funciones eran requisitos arquitectónicos, no complementos de gestión añadidos a posteriori.

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 la plataforma, más útiles son sus decisiones y más precisa debe ser la gobernanza de su autoridad.

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

Un controlador multinube no puede gestionar lo que no ve. Prosimo desarrolló un descubrimiento de activos en la nube y mapas que representaban VPC, VNet, 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.

El descubrimiento era estratégicamente importante porque los entornos en la nube cambian al margen de los flujos de trabajo de la red central. Los equipos de aplicaciones pueden crear cuentas, redes, puntos finales y servicios gestionados con su propia automatización. Los diagramas manuales se vuelven obsoletos. Un inventario basado en API podía ofrecer un plano más actual, pero su completitud dependía de la cobertura 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 sobre la que se calculaban las decisiones de enrutamiento, segmentación, inserción de servicios y optimización. Si faltaba un activo o una dependencia, todos los resultados basados en él podían ser erróneos. Por eso, la topología necesitaba una procedencia clara: cuándo se recopiló, qué cuenta la suministró, qué regiones cubría y si alguna solicitud había fallado.

Este grafo también ayuda a explicar la adquisición. Palo Alto Networks puede crear valor de seguridad cuando sabe dónde están las cargas de trabajo y las rutas del tráfico. Un sistema que descubre activos y modifica rutas reduce la distancia entre comprar un cortafuegos virtual y colocarlo en el lugar correcto. La declaración posterior de Bhau se centró precisamente en el descubrimiento de activos y en la aceleración del despliegue de cortafuegos virtuales.

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

Application-driven Intelligent Results, o AIR, analizaba la telemetría recogida por los bordes AXI. La documentación de AWS explicaba la visibilidad 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 las observaciones del usuario, la red y la aplicación, en lugar de mostrar contadores de dispositivos aislados.

Esta correlación abordaba un problema operativo habitual. Una transacción lenta podía deberse a la ruta del usuario, al borde, a la red troncal de la nube, a un servicio de seguridad o a la propia aplicación. Una visibilidad entre capas podía acotar la búsqueda más rápido que los paneles separados y apoyar recomendaciones sobre ruta, ubicación, riesgo y coste.

La calidad de la recomendación dependía de la cobertura de la telemetría y del modelo utilizado para interpretarla. El borde solo veía el tráfico que pasaba por él. Las dependencias externas de la aplicación y los estados internos del proveedor podían permanecer invisibles. Una recomendación podía ser útil en una dirección sin llegar a demostrar la causa raíz.

La telemetría también tenía valor de gobernanza. Las observaciones históricas podían ayudar a la empresa a explicar por qué cambió una ruta o una política. También podían revelar el uso sensible de una aplicación y el comportamiento del usuario. El contenido público no ofrece una descripción completa de la retención o la gobernanza de los datos después de la adquisición, por lo que estas cuestiones siguen siendo parte de la diligencia debida de los clientes.

AWS proporcionó la demostración mejor documentada

El trabajo de Prosimo con AWS produjo la prueba técnica pública más sólida. La empresa se integró con AWS Transit Gateway, Cloud WAN, PrivateLink y la ruta de despliegue del Marketplace for Containers Anywhere. AWS publicó una explicación de la ubicación de AXI Edge, la incorporación de aplicaciones, la identidad, la seguridad y la optimización.

AWS Cloud WAN fue especialmente importante. Proporcionaba un servicio de red troncal nativo en la nube y de segmentación que Prosimo podía orquestar en lugar de sustituir. El acuerdo mostraba el modelo de producto colaborativo: AWS poseía la red nativa y la infraestructura global; Prosimo aportaba la intención multinube, el contexto de la aplicación, el software de borde y la analítica.

La ruta del Marketplace simplificaba el primer paso del despliegue al empaquetar AXI Edge en un canal autorizado, pero no eliminaba el trabajo posterior sobre permisos de cuentas, diseño de rutas, alta disponibilidad, capacidad y operaciones. La automatización del día cero podía reducir la fricción de la instalación, pero el problema del control a largo plazo permanecía.

Una referencia nominal a Flexport respaldaba el caso de uso de AWS Cloud WAN en el contenido de la empresa. Esto demuestra que un cliente empresarial estaba dispuesto a avalar la arquitectura, no una auditoría independiente de la escala del despliegue, los ahorros o la disponibilidad. Por tanto, las declaraciones de los clientes deben utilizarse como ejemplos de adopción, no como pruebas de rendimiento generalizadas.

Azure y Google Cloud completaban la afirmación multinube

Prosimo también era compatible con los entornos de Microsoft Azure y Google Cloud. Sus materiales describían la orquestación en torno a Azure Virtual WAN, las redes de Google Cloud y los objetos de servicio privado. El objetivo era ofrecer un modelo operativo único, manteniendo al mismo tiempo la red nativa de cada proveedor en su lugar.

La existencia de compatibilidad no demuestra una equivalencia de capacidades entre proveedores. Las API de las nubes maduran a ritmos diferentes, y nombres de producto similares pueden ocultar semánticas distintas. Una ruta, un segmento, un punto privado o una inserción de servicio pueden requerir un tratamiento específico del proveedor. Las evidencias presentadas no reconstruyen una matriz de equivalencia para cada función en cada región y versión.

Por lo tanto, la abstracción multinube se entiende mejor como un sistema de traducción. Puede unificar la intención y el flujo de trabajo compartido, pero debe preservar los detalles que afectan a la seguridad, el coste y el fallo. La plataforma se vuelve peligrosa cuando la interfaz parece uniforme mientras las diferencias de implementación se ocultan a los operadores.

Lo mismo se aplica tras la adquisición. Palo Alto Networks puede utilizar el grafo compartido para posicionar la seguridad en todas las nubes, pero los proveedores de nube siguen controlando los objetos nativos que ejecutan la ruta. Ser propietario de la capa de orquestación no otorga la propiedad de la infraestructura de nube subyacente.

El producto se expandió desde la conectividad hasta el ciclo de vida

En 2023, Prosimo describió flujos de trabajo para diseñar, construir, investigar y gestionar redes multinube. El producto fue más allá de crear un túnel o una pasarela. El descubrimiento de activos apoyaba el diseño; la orquestación construía la conectividad; los mapas y la telemetría ayudaban a resolver problemas; y la política y el estado histórico respaldaban la gestión continua.

El marco del ciclo de vida ampliaba el comprador comercial. Un ingeniero de redes podía utilizar la topología y el análisis de rutas; el equipo de plataforma en la nube podía incorporar cuentas y servicios; el equipo de seguridad podía revisar la segmentación y la inspección; el equipo de migración podía planificar los cambios; el equipo de FinOps podía examinar las implicaciones de las rutas y el tráfico de salida. La plataforma ganaba valor cuando varios grupos utilizaban el mismo plano compartido.

Sin embargo, un plano compartido también podía generar conflictos de gobernanza. Una plataforma centralizada podía revelar que la configuración del equipo de nube difería de la política corporativa. La empresa debía decidir qué sistema era la referencia y quién aprobaba la corrección. El software por sí solo no podía resolver esta cuestión organizativa.

El enfoque del ciclo de vida también reforzaba el coste de la transición. Cuando el controlador conserva el grafo de activos, las políticas, la telemetría, las ubicaciones de los bordes y las integraciones de automatización, sustituirlo exige más que cambiar un circuito. El cliente debe exportar o reconstruir el modelo operativo. Prosimo vendía la reducción de la fragmentación de la nube, pero al mismo tiempo creaba la posibilidad de una dependencia del controlador.

La segmentación se extendía desde el acceso de red hasta la política de aplicación

Prosimo ofrecía segmentación de capa 3 a capa 7. A nivel de red, los dominios de enrutamiento y los segmentos determinaban qué redes o ubicaciones 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 afinaban la regla.

El modelo multicapa podía reducir la brecha entre una zona de red y una política de aplicación. Un servicio de negocio podía estar permitido mientras se bloqueaba el acceso amplio entre redes. A la inversa, se podía denegar una ruta alcanzable porque la identidad o el contexto de la aplicación no fueran válidos.

Esto no convertía a Prosimo en un cortafuegos de nueva generación completo. La integración de 2024 separaba las responsabilidades: Prosimo orquestaba rutas, segmentación e inserción de servicios; los VM-Series realizaban la inspección profunda. La distinción es importante porque la política de enrutamiento y la imposición de la seguridad fallan de maneras diferentes.

Un segmento solo es eficaz cuando 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 ello, la verificación exige comparar la política declarada con el estado del proveedor y el tráfico observado, no solo confiar en la pantalla de configuración del controlador.

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

El diseño de la seguridad en la nube debe decidir dónde se produce la inspección. Los cortafuegos centralizados pueden simplificar la política y reducir el número de dispositivos, pero pueden provocar desvíos, concentración y presión sobre la capacidad. Los cortafuegos distribuidos permanecen más cerca de las cargas de trabajo y mitigan algunas distorsiones de la ruta, pero multiplican el despliegue, las licencias, las actualizaciones y la gestión de políticas.

Prosimo era compatible con ambos modelos en la integración con VM-Series. La política podía dirigir el tráfico seleccionado a través de un punto de inspección centralizado o a través de cortafuegos distribuidos dentro de las VPC de las aplicaciones. El controlador actualizaba las rutas circundantes, mientras que Palo Alto Networks proporcionaba la función de inspección.

Esta arquitectura convertía la orquestación de rutas en un bien comercial para un proveedor de seguridad. Un cortafuegos virtual no protege el tráfico que no llega a él. El descubrimiento, la ubicación y la actualización de rutas reducen la fricción entre la adquisición de capacidad de seguridad y su inserción en una ruta viva. Esa es una razón estratégica plausible para que Palo Alto Networks absorbiera la tecnología de Prosimo.

También ampliaba el ámbito de influencia del controlador. Una política errónea podía eludir la inspección, crear un bucle, generar un enrutamiento asimétrico o detener una aplicación. Las comprobaciones de salud, el despliegue gradual, la simulación, la auditoría y la reversión se vuelven necesarias porque un fallo de inserción de servicio es a la vez un incidente de red y un incidente de seguridad.

La asociación de 2024 no debe atribuirse retroactivamente a la fecha de 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, no afirmaba que Palo Alto Networks hubiera adquirido Prosimo. Tratar el anuncio como prueba de propiedad fusionaría dos acontecimientos distintos.

No obstante, la asociación tendió un puente. Prosimo pudo mostrar cómo su sistema de rutas y políticas facilitaba el despliegue de VM-Series en todas las nubes. Palo Alto Networks pudo evaluar la tecnología en una integración real antes del posterior movimiento corporativo. Las evidencias públicas no describen el proceso de adquisición, por lo que afirmar que la asociación se diseñó como un paso formal previo a la compra sigue siendo una conjetura.

A principios de 2025, los perfiles de los fundadores y empleados cambiaron. La página de la empresa adoptó posteriormente la etiqueta de adquisición. A finales de 2025, Bhau afirmó que la tecnología se había integrado completamente en los productos de Palo Alto Networks. Estos registros, en conjunto, respaldan el resultado de la adquisición, pero dejan sin resolver el mecanismo legal.

Esta secuencia es importante para la exactitud editorial y para los clientes. Una asociación implica dos proveedores, dos estructuras de soporte y un punto de integración conocido. Una adquisición puede transferir la hoja de ruta, los datos, los contratos y la autoridad a una sola empresa. El tránsito modifica más que el nombre, incluso cuando la ruta técnica parece inicialmente similar.

Nebula convirtió el grafo topológico en una interfaz conversacional

Prosimo presentó Nebula en febrero de 2024 como parte de la AI Suite para redes multinube. El asistente se diseñó para responder en lenguaje natural a preguntas sobre redes superpuestas, costes, salud de las rutas, violaciones de políticas de seguridad y otros estados representados en el grafo y la telemetría de la plataforma.

El activo valioso no era solo la interfaz de lenguaje, sino el contexto estructurado multinube subyacente. Un modelo genérico no puede diagnosticar una ruta o un segmento privado que no ve. Nebula podía apoyarse en el inventario de activos, la topología, las políticas y la observabilidad que Prosimo ya recopilaba. Esto convertía la inversión previa en un grafo compartido en algo relevante para las operaciones de AIOps.

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

Prosimo mencionó beneficios potenciales, como una reducción del tiempo medio de resolución del 60-80 % y una disminución del coste de la red en la nube superior al 60 %. Se trataba de cifras afirmadas por la empresa en un anuncio de producto. Las evidencias no aportan una metodología independiente ni una línea de base de clientes que demuestre su aplicabilidad general. Pueden citarse como beneficios propuestos por Prosimo, no como hechos de mercado medidos.

Las cargas de trabajo de IA fueron un nuevo caso de uso, no la prueba de un nuevo mercado

El mismo anuncio de 2024 situaba la arquitectura de Prosimo en el contexto de las cargas de trabajo de IA. Los sistemas distribuidos pueden necesitar acceso privado a datos, conectividad entre nubes y centros de datos, controles de cumplimiento y un enrutamiento que refleje el comportamiento de la aplicación. Estos requisitos eran compatibles con el modelo de activos, políticas y rutas existente.

El nombre no cambiaba la infraestructura subyacente. Prosimo seguía dependiendo de las redes de las nubes, los operadores y la infraestructura del cliente, y no ofrecía computación GPU ni marcos de desarrollo de modelos. Su posible función era la capa de conectividad y seguridad alrededor de los datos y servicios distribuidos.

Posicionarse en el ámbito de la IA era estratégicamente lógico, porque el valor de la topología multinube aumenta cuanto más distribuidos están los datos y los servicios. Pero también era una categoría de marketing introducida poco antes del fin de la operación independiente de la empresa. Las evidencias no muestran ingresos separados por un producto de IA, ni despliegues en producción con nombre, ni resultados de cargas de trabajo auditados.

La idea duradera es que la telemetría multinube puede convertirse en un insumo para operaciones asistidas por máquinas. La pregunta actual es si Palo Alto Networks retuvo ese contexto y cómo presenta la capacidad. Las evidencias públicas en la fecha de corte no ofrecen una respuesta completa.

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

El negocio independiente de Prosimo consistía en suscripciones de software y servicios, no en un modelo de transporte. Los clientes desplegaban los bordes AXI en sus entornos y conectaban las cuentas de nube a la capa de control. Es razonable suponer que los ingresos se basaban en licencias o suscripciones, soporte, servicios profesionales y canales, pero los precios exactos y las métricas de los contratos no se publicaron en las evidencias presentadas.

El modelo podía escalar sin poseer fibra. Una sola plataforma de software orquestaba muchas regiones y múltiples entornos de cliente. Sin embargo, no se puede inferir la economía agregada solo a partir de la arquitectura: mantener las API de los proveedores, el ciclo de vida de los bordes, las integraciones de seguridad y los despliegues empresariales podía ser costoso, mientras que el cliente pagaba los recursos de nube que consumían los bordes, en lugar del proveedor.

Prosimo utilizó los mercados de nube, los socios de integración, los canales de venta y los clientes de referencia para llegar a las empresas. Estas relaciones no son equivalentes. Una lista en un mercado demuestra una ruta de compra y despliegue. Una integración técnica muestra que dos sistemas pueden combinarse en condiciones determinadas. El testimonio de un cliente proporciona una referencia. Ninguno de estos elementos por sí solo demuestra el número de clientes de pago o los ingresos recurrentes.

Es probable que la amplitud de la empresa complicara las ventas. Los equipos de redes, seguridad, nube y aplicaciones podían beneficiarse, mientras la propiedad del presupuesto seguía sin estar clara. El producto necesitaba un comprador dispuesto a financiar una capa de control compartida, en lugar de dejar que cada nube y cada equipo operaran por separado.

Socios, clientes e inversores ocupaban posiciones distintas

Amazon Web Services era a la vez proveedor de infraestructura, socio de integración y aliado para la llegada al mercado. Azure y Google Cloud eran entornos compatibles. Los proveedores de identidad suministraban el contexto de autenticación, los proveedores de cortafuegos la inspección, las empresas de colocation y los operadores podían alojar o conectar los bordes, y los socios de canal podían diseñar y operar los despliegues.

Flexport apareció como cliente de referencia nominal en el material de AWS Cloud WAN. La referencia demuestra el interés de una empresa en la arquitectura, pero no revela el alcance completo, la duración ni el valor comercial del despliegue. No debe convertirse en un sustituto del conocimiento de toda la base de clientes.

General Catalyst lideró la ronda de serie A y participó en la gobernanza desde la posición de inversor. Inversores vinculados a WRVI o Celesta aparecen en los materiales de la empresa, y comunicaciones posteriores aludían a la participación de otros nombres destacados, entre ellos uno asociado a BlackRock, sin que se haya identificado con certeza la entidad inversora concreta. Los registros respaldan una base de financiación con relaciones sólidas, no un cuadro de propiedad completo.

Palo Alto Networks ocupaba la relación más importante. Pasó de ser un socio de seguridad en 2024 a ser el adquirente a principios de 2025. La secuencia muestra cómo una dependencia del ecosistema se transforma en una relación de control cuando una de las partes compra la capa de software que orquesta la ruta hacia su propio producto.

Se recaudaron al menos 55 millones de dólares, y la economía de la salida es desconocida

El historial de financiación documentado se compone de 25 millones en la ronda A de abril de 2021 y 30 millones en la ronda B de 2022. El total asciende a al menos 55 millones de dólares. Las evidencias no incluyen un cuadro de propiedad auditado, una valoración, un cuadro de deuda ni una ronda posterior.

El contravalor de la adquisición no se anunció ni se verificó de forma independiente. Sin precio, el resultado no puede calificarse responsablemente como una prima estratégica, una compra técnica limitada, una adquisición de equipo o una venta forzosa. La persistencia de la integración respalda la existencia de valor en la tecnología, pero no revela el retorno para los inversores o los fundadores.

No se deben atribuir a Prosimo los ingresos ni la capitalización bursátil de Palo Alto Networks después de la adquisición. Cuando la startup dejó de aparecer como unidad independiente, ya no había ingresos, beneficios ni segmento de clientes separados que analizar. El propietario mayor puede hacer que la tecnología sea más omnipresente, al tiempo que reduce la visibilidad de su propia economía.

La ausencia de un anuncio oficial de la adquisición es significativa en sí misma. Clientes, empleados e investigadores suelen utilizar esos anuncios para fijar el momento, el soporte y la lógica estratégica. En este caso, el estatus debe reconstruirse a partir de trayectorias profesionales, la etiqueta de la página de la empresa y una declaración posterior del fundador. Esto basta para corregir el estatus de la empresa, pero no para inventar detalles del acuerdo.

La competencia provenía de plataformas, nubes e ingeniería interna

Prosimo competía con plataformas especializadas en redes multinube 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 el modelo de “hágalo usted mismo”, en el que la empresa utiliza infraestructura como código, servicios de tránsito, tablas de rutas y cortafuegos directamente. Las alternativas abordaban porciones distintas del mismo problema.

Un controlador especializado podía ofrecer una topología y un modelo de política únicos a través de los proveedores. Un diseño nativo dentro de una sola nube podía reducir la dependencia de terceros y adaptarse mejor a un proveedor concreto. Un servicio respaldado por un operador podía proporcionar el transporte físico. Una plataforma SASE o de seguridad podía fusionar la conectividad y la imposición de políticas. La ingeniería interna podía mantener el control a cambio de una carga de personal e integración.

La diferenciación de Prosimo residía en combinar el tránsito de aplicaciones y de red, los bordes distribuidos, la orquestación nativa de nube, la topología, la telemetría y la inserción de servicios. La misma amplitud dificultaba la comparación. Los compradores tenían que probar los servicios de nube, las rutas, los sistemas de identidad y el modelo de seguridad que pretendían utilizar, en lugar de comparar los nombres de las categorías.

La adquisición modifica el marco competitivo. Prosimo ya no tiene que ganar como empresa independiente, pero su tecnología debe demostrar su valor dentro de Palo Alto Networks. La comparación relevante pasa a ser: ¿mejoran el descubrimiento integrado y la orquestación de rutas el despliegue de los productos de seguridad de Palo Alto, y aceptan los clientes la dependencia de la plataforma resultante?

Los servicios nativos de nube eran a la vez cimiento y alternativa

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

Esta relación creaba un límite móvil. Cada vez que un proveedor de nube añadía un enrutamiento global, una segmentación, un acceso privado o una política centralizada, facilitaba que se reprodujeran localmente algunas de las funciones de terceros. Al mismo tiempo, cada nuevo servicio nativo añadía otro objeto que el controlador multinube podía descubrir y orquestar. El avance de la nube podía reducir una parte del valor de Prosimo, al tiempo que ampliaba la necesidad de traducción entre proveedores.

El factor decisivo era tanto organizativo como técnico. Una empresa que adopta una sola nube y posee una sólida ingeniería interna puede preferir las herramientas nativas. Una empresa multinube con equipos fragmentados puede valorar un plano de control único. Una empresa regulada puede querer una capa de inteligencia de terceros, pero preocuparse por las credenciales con privilegios y la concentración de datos.

Ninguna arquitectura eliminaba la dependencia. Las herramientas nativas aumentaban la dependencia de las API y la semántica de un único proveedor. El controlador multinube aumentaba la dependencia de su grafo, sus políticas y su software de borde. La pregunta útil era si la dependencia resultaba visible, portátil y compatible con el modelo operativo de la empresa.

El fallo podía producirse en el controlador, el borde, la API de la nube, la identidad o la infraestructura

La arquitectura distribuida reducía la dependencia de un único hub de tráfico, pero creaba dominios de fallo que interactúan entre sí. El sistema central podía caerse o cargar una intención obsoleta. Un borde podía fallar o quedar aislado. Una API de nube podía rechazar parte de un cambio. El proveedor de identidad podía fallar. La infraestructura subyacente podía perder capacidad o tomar una ruta inesperada. Un cortafuegos insertado podía agotar sus recursos.

Los fallos parciales eran especialmente difíciles. Un proveedor podía aceptar una actualización de ruta y otro rechazarla. En ese caso, el estado pretendido por el controlador difería del estado real en la nube. El tráfico podía tomar una ruta asimétrica o eludir la inspección. Un sistema fiable necesitaba conciliación, operaciones repetibles de forma segura, despliegue gradual, un estado de error explícito y una reversión que respetara el comportamiento de cada proveedor.

Las evidencias 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 un resultado de servicio público. Por lo tanto, las afirmaciones de resiliencia deben vincularse a la arquitectura documentada o a pruebas de clientes nominales.

La adquisición añade otro dominio de fallo: la continuidad del producto. Los clientes necesitan saber qué panel, interfaz, imagen de borde, modelo de política y punto de soporte reemplazan al sistema histórico de Prosimo. Una integración de código exitosa desde el punto de vista técnico puede seguir presentando un riesgo de migración si los límites comerciales y operativos no están claros.

Las credenciales de nube convirtieron 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. El inventario de solo lectura podía funcionar con permisos limitados, mientras que cambiar rutas, segmentos e inserciones de servicios exigía una autoridad más fuerte. Por lo tanto, el controlador se sentaba dentro del plano de gestión con privilegios, aunque no poseía las cargas de trabajo.

Un compromiso de las credenciales podía exponer la topología o permitir cambios generalizados. Un defecto de software o un error del operador podía propagar una política a través de múltiples nubes. El riesgo crecía con la utilidad de la plataforma: cuantas más cuentas y servicios gestionaba, mayor era el ámbito del impacto potencial.

Las empresas necesitaban roles de privilegio mínimo, credenciales separadas para el descubrimiento y la modificación, aprobación por múltiples partes, auditoría completa, rotación, revocación de emergencia y una ruta de recuperación que no dependiera únicamente del propio controlador. Los materiales públicos no ofrecen una evaluación de seguridad independiente completa, por lo que estos siguen siendo controles de despliegue necesarios, no garantías probadas del producto.

La telemetría también era sensible. Podía revelar nombres de aplicaciones, arquitectura de red, políticas, relaciones de usuarios, salud de las rutas y patrones de costes. La gobernanza tras la adquisición debería aclarar dónde se almacenan estos datos, qué productos de Palo Alto pueden utilizarlos y cómo se han transferido los derechos de los clientes existentes. Las evidencias públicas en la fecha de corte no responden a estas preguntas.

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

La posición independiente de Prosimo le permitía presentarse como una capa compartida entre las nubes y los servicios de seguridad. Cuando Palo Alto Networks se convirtió en propietaria, los incentivos cambiaron. La tecnología adquirida podía facilitar el despliegue de VM-Series y de otros productos de Palo Alto. El resultado podía ser una mejor integración, con preguntas sobre el soporte a los servicios de inspección de terceros.

La propiedad no implica la desaparición de la neutralidad. Las evidencias no ofrecen una matriz de socios actual ni una arquitectura de producto contemporánea. Pero cambian lo que el cliente debe preguntar: ¿sigue abierto el controlador de rutas a múltiples proveedores de seguridad?, ¿se pueden exportar las políticas y la telemetría?, ¿favorece la optimización la cartera del propietario?

La declaración de integración se centraba en la inspección de entrada, salida y este-oeste. Esto sugiere que la topología y la orquestación de Prosimo entraron en un sistema de despliegue de seguridad. Pero no demuestra que el histórico App Transit, el acceso de usuarios, la optimización de costes o todos los flujos de trabajo de redes en la nube sigan existiendo como capacidad separada.

Se trata de un patrón familiar en la infraestructura. Una startup abstrae un difícil problema de coordinación y, a continuación, una plataforma mayor compra esa abstracción porque aumenta el consumo y el control de su producto principal. El comprador obtiene una vía de despliegue. El cliente puede obtener integración y perder parte de su independencia respecto al proveedor.

El mapa actual de productos es el mayor hecho ausente

El registro público confirma la adquisición y la integración, pero no especifica un mapa completo desde AXI, Network Transit, App Transit, AIR y Nebula hasta los productos actuales o las unidades de venta de Palo Alto Networks. Tampoco publica fechas de fin de soporte heredado, procedimientos de migración ni una hoja de continuidad función por función.

Esta laguna impide reseñar el producto en presente. Las descripciones históricas pueden explicar lo que Prosimo construyó y por qué fue importante, pero no dicen al comprador qué capacidades están disponibles, bajo qué licencia o con qué soporte hoy. Cualquier consejo de despliegue contemporáneo debe basarse en la documentación actual de Palo Alto Networks, no en los datos archivados de Prosimo.

La ausencia del mapa también limita el análisis estratégico. Absorber completamente el grafo y la capa de orquestación es distinto de utilizar selectivamente el descubrimiento de activos y la ubicación de cortafuegos. Lo primero crea un servicio de control amplio; lo segundo emplea Prosimo principalmente como acelerador del despliegue de seguridad. La declaración del fundador respalda la continuidad de la tecnología, pero deja este límite arquitectónico sin resolver.

Un documento de producto, una guía de migración o un estudio de caso de un cliente publicado con posterioridad pueden resolver gran parte de la incertidumbre. Hasta entonces, la formulación precisa es que la tecnología de Prosimo se ha integrado en los productos de Palo Alto Networks, según un cofundador, mientras que el alcance y el empaquetado no están verificados.

¿Quién controla el enrutamiento multinube?

Ninguna entidad controla toda la ruta. La empresa controla la propiedad de las cuentas, la intención de negocio, el diseño de las aplicaciones y las credenciales que otorga. Un controlador multinube puede descubrir la topología, traducir la política, elegir rutas y modificar el estado de enrutamiento nativo. Los proveedores de nube controlan las API, los servicios de tránsito, los puntos privados, la red troncal y muchos dominios de fallo. Los operadores y las empresas 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 ventajosa. No poseía la infraestructura, pero intentaba poseer 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 bordes, qué servicio inspecciona el tráfico y qué telemetría se considera la referencia. Esto supone un poder operativo sobre el enrutamiento incluso cuando la fibra es propiedad de otro.

Tras la adquisición, Palo Alto Networks posee la tecnología restante y decide cómo integrarla, empaquetarla y hacerla evolucionar. Los proveedores de nube siguen siendo soberanos dentro de sus entornos, y la empresa puede revocar credenciales o elegir otra arquitectura. Pero la salida puede ser costosa si la topología, las políticas y los flujos de trabajo han quedado ligados al controlador.

La respuesta es de múltiples capas, no absoluta: la empresa delega, el controlador orquesta, las capas de nube y de operador transportan, y la plataforma de seguridad impone. La historia de Prosimo es relevante porque muestra que la propiedad de la capa de orquestación puede cambiar sin que lo hagan la propiedad de una cuenta de nube ni la de una ruta física.

Registro de fuentes principales

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

Prosimo captó un cambio real en la infraestructura. La unidad operativa de la red está pasando del dispositivo y el prefijo hacia la aplicación, la identidad, la dependencia del servicio y el grafo de políticas. Las API de la nube hacen programable el estado de la red, y los bordes distribuidos hacen móvil el punto de imposición. Un controlador que ve múltiples nubes puede coordinar acciones que ningún panel de una sola nube puede completar por sí solo.

La empresa también reveló el coste de esa coordinación. La capa compartida necesita credenciales con privilegios, mantenimiento continuo de las API, un descubrimiento preciso, traducción semántica, telemetría y disciplina operativa. Puede reducir el trabajo fragmentado, al tiempo que crea un nuevo punto de concentración. El mismo sistema puede simplificar el enrutamiento y ampliar el alcance de una decisión equivocada.

La adquisición por parte de Palo Alto Networks hace más evidente la cuestión del control. Las redes y la seguridad convergen 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 modifica las rutas no se limita a inspeccionar el tráfico que le llega; puede ayudar a decidir qué tráfico llega a la inspección y dónde.

Por todo ello, Prosimo no debe recordarse como una marca independiente que fracasó, ni como prueba de que una sola plataforma resolvió el multinube. Su contribución duradera fue definir el grafo multinube como infraestructura. La pregunta pendiente es si ese grafo, ahora dentro de una empresa de seguridad más grande, sigue siendo lo bastante transparente, portátil y gobernable para merecer la confianza de los clientes.