Resumen

  • Prosimo se fundó en 2019 y recaudó al menos 55 millones de dólares en sus rondas A de 2021 y B de 2022; no publicó ingresos auditados, valoración ni precio de adquisición
  • AXI combinaba intención, topología y análisis centrales con nodos distribuidos que descubrían activos de nube, conectaban aplicaciones e insertaban servicios de seguridad sin poseer la infraestructura física
  • La integración con VM-Series anunciada en junio de 2024 precedió la incorporación de Prosimo a Palo Alto Networks hacia febrero de 2025; no se han publicado la fecha exacta, el precio ni el mapa actual de productos
  • El control sigue repartido entre las empresas, el software de orquestación, los proveedores de nube y Palo Alto Networks; la portabilidad de la topología, las credenciales, las políticas y la autoridad sobre las rutas es la prueba decisiva para los clientes

La marca desapareció, pero el problema permaneció

En 2026, ya no es correcto describir a Prosimo como un proveedor independiente activo. Los historiales profesionales públicos muestran a sus fundadores y a varios empleados incorporándose a Palo Alto Networks alrededor de febrero de 2025. La identidad corporativa de Prosimo aparece marcada 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 establecen un cambio de control y la continuidad de valor técnico. No establecen la fecha exacta de firma o cierre, la forma jurídica ni el precio de la operación.

Esta precisión debe aparecer al principio porque cambia el tiempo verbal de todas las afirmaciones sobre los productos. AXI, Network Transit, App Transit, Application-driven Intelligent Results y Nebula fueron capacidades documentadas durante la etapa independiente. No deben presentarse como productos actuales vendidos por separado hasta que Palo Alto Networks publique una correspondencia contemporánea de producto y soporte. Tras una adquisición, una arquitectura puede sobrevivir como código integrado, servicio compartido, módulo o activo interno de ingeniería; esos resultados no son equivalentes.

La desaparición de la marca no eliminó el problema subyacente. Las empresas siguen distribuyendo cargas entre Amazon Web Services, Microsoft Azure, Google Cloud, centros de datos privados, instalaciones de colocación, plataformas SaaS y usuarios remotos. Cada entorno tiene sus propias rutas, pasarelas, endpoints privados, controles de identidad, servicios de seguridad, cuotas y reglas de facturación. Una empresa puede ser propietaria de todas las cuentas y aun así carecer de una visión coherente del recorrido de una solicitud. La importancia de Prosimo radica en su intento de reunir esa visión en una capa de control común.

Por eso, la adquisición constituye el eje narrativo y no un simple epílogo. Prosimo construyó una capa de control transversal capaz de descubrir activos, interpretar el contexto de las aplicaciones y dirigir tráfico a servicios de seguridad. Palo Alto Networks apareció primero como socio técnico cuyos firewalls VM-Series podían insertarse en esas rutas; después se convirtió en propietaria de la tecnología. El límite que separaba la orquestación del enrutamiento de la inspección profunda quedó dentro de una única plataforma de ciberseguridad.

En el enrutamiento multinube, el contexto decide

Una tabla de rutas puede indicar si un prefijo es alcanzable a través de un siguiente salto. Por sí sola no explica qué aplicación quería alcanzar el usuario, si el usuario o la carga son de confianza, si un servicio de inspección debe ver el tráfico, si existe un endpoint privado, si una ruta en la nube cuesta más que otra o si la transacción falla después de llegar el paquete. Las operaciones multinube convierten esas preguntas en un problema de control compartido.

La tesis de Prosimo era que la autoridad de enrutamiento debía basarse en algo más que la conectividad de capa 3. Su software intentaba combinar inventario de nube, estado de red, identidad de aplicación, identidad de usuario, riesgo, rendimiento y telemetría transaccional. Ese contexto permitía expresar políticas como conectar una aplicación concreta, separar un segmento, elegir un punto de entrada o dirigir tráfico seleccionado a un firewall. El valor no procedía de inventar una nueva ruta de fibra, sino de decidir cómo ensamblar rutas y servicios existentes.

Esa diferencia explica la expresión «application experience infrastructure». La solicitud de la aplicación quedaba por encima del objeto de red individual. Un VPC, VNet, subred, hub de tránsito o enlace privado pasaba a ser un componente del recorrido de extremo a extremo, no el objeto final de gestión. La propuesta también colocaba el producto en varios mercados a la vez: redes en la nube, entrega de aplicaciones, acceso zero trust, verificación operativa de la red, optimización de costes e inserción de servicios de seguridad.

Esa amplitud generaba oportunidades y ambigüedad. Un producto que cruza varios equipos puede resolver fallos de coordinación que no pertenecen a un único responsable. También puede ser difícil de evaluar porque los equipos de red, seguridad, nube, aplicaciones y finanzas utilizan definiciones distintas de éxito. Prosimo tenía que demostrar que un modelo transversal mejoraba la operación sin convertirse en otra capa privilegiada cuyas equivocaciones afectaran a todos los entornos.

Qué era Prosimo y qué quedó de su tecnología

Prosimo fue 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; Nehal Bhau fue cofundador y director de tecnología durante la etapa independiente. Los historiales públicos también sitúan a Linus Aranha y Pradeep Aragonda en funciones fundacionales o de ingeniería sénior, aunque sus cargos exactos deben vincularse a biografías fechadas.

Su plataforma principal era Application eXperience Infrastructure, normalmente abreviada AXI. AXI utilizaba una capa central de software para intención, topología, análisis y orquestación, junto con nodos AXI Edge distribuidos en regiones de nube, entornos de colocación o infraestructura local cercana. Más tarde, la oferta se organizó como Full-Stack Cloud Transit, con Network Transit y App Transit para distintas clases de conectividad. AIR analizaba telemetría y producía información operativa; Nebula añadió una interfaz conversacional en 2024.

Prosimo no era un operador de nube. No poseía una red mundial de fibra que conectara todas las regiones. Las rutas podían atravesar redes troncales de los proveedores, internet público, circuitos directos, enlaces de colocación y redes empresariales. Tampoco era un proveedor de firewall en el mismo sentido que Palo Alto Networks. En la integración de 2024, Prosimo descubría, segmentaba y dirigía; VM-Series realizaba la inspección profunda.

Después de la adquisición, la descripción más prudente es «linaje tecnológico». La declaración posterior de integración destaca el descubrimiento de activos multinube y el despliegue más rápido de firewalls de software para tráfico de entrada, salida y este-oeste. Es una prueba de que componentes importantes sobrevivieron. No demuestra que el catálogo histórico completo de AXI, su empaquetado comercial o su modelo de soporte continuaran sin cambios.

El problema después de SD-WAN

El equipo fundador tenía experiencia en redes a gran escala, entrega de aplicaciones e infraestructura de nube. Prosimo también surgió del ecosistema más amplio de fundadores e ingenieros asociado a Viptela, compañía que ayudó a consolidar SD-WAN como categoría empresarial. El problema siguiente era distinto. SD-WAN podía simplificar la relación entre una sucursal y la red, pero no creaba un modelo operativo único dentro y a través de varias nubes públicas.

Una aplicación multinube puede depender de un endpoint web en un entorno, una base de datos o servicio gestionado en otro, un proveedor de identidad fuera de ambos, conectividad privada hacia un centro de datos e inspección de seguridad situada en límites concretos. Cada dependencia puede representarse con un objeto nativo distinto. El equipo de red ve prefijos y hubs de tránsito; el equipo de nube ve cuentas y recursos; el propietario de la aplicación ve dominios y transacciones; seguridad ve zonas y políticas de inspección.

Prosimo partía de la solicitud, no de la sucursal. La pregunta era cómo debía un usuario o una carga llegar a una aplicación con seguridad, rendimiento, disponibilidad y coste aceptables. Ese enfoque ampliaba el objeto del enrutamiento desde el prefijo de destino a una transacción con identidad y contexto de aplicación. También obligaba a recoger y mantener mucha más información que un router convencional.

El momento era favorable. AWS, Azure y Google Cloud estaban ampliando sus sistemas 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 específicos. La oportunidad de Prosimo consistía en coordinar esos servicios, no en obligar a cada cliente a sustituirlos por una red troncal propietaria.

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

Prosimo se fundó en 2019, pero no anunció su lanzamiento público hasta el 6 de abril de 2021. General Catalyst lideró una Serie A de 25 millones de dólares en el lanzamiento. El inversor describió la oportunidad en términos de entrega de experiencia de aplicación entre nubes, en línea con la intención de definir una categoría más amplia que la conectividad tradicional de sucursales.

El lanzamiento situó a la empresa en un mercado concurrido y todavía inestable. Los proveedores de nube facilitaban el consumo de sus servicios de red. Los vendedores de SD-WAN y SASE extendían la política hacia la nube. Los proveedores de entrega de aplicaciones podían optimizar solicitudes y las empresas de seguridad podían inspeccionarlas. El caso de Prosimo dependía de unir esas funciones en una arquitectura orientada a la nube sin afirmar que sustituía todo lo que la rodeaba.

La financiación permitió construir integraciones, nodos de borde de software, análisis, una organización comercial y relaciones con socios. No probaba encaje de producto, escala de ingresos ni diferenciación duradera. Las pruebas suministradas no contienen ingresos auditados, ARR, número de clientes o valoración. El registro de financiación muestra apoyo inversor a una tesis, no un informe completo de rendimiento operativo.

En 2022, Prosimo completó una Serie B de 30 millones de dólares descrita como sobresuscrita. Sumando las dos rondas claramente identificadas se obtiene un total verificado de al menos 55 millones. Algunas bases de datos pueden mostrar más si duplican anuncios o registros relacionados; no deben usarse sin resolver 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 dividía el trabajo entre una capa central de control y análisis y nodos de borde distribuidos. La capa central mantenía la intención de red y aplicación, descubría activos, ensamblaba la topología, integraba identidad, analizaba telemetría y orquestaba cambios. Los nodos AXI Edge se desplegaban cerca de las cargas de trabajo o los usuarios para aplicar política sin obligar a que todas las rutas pasaran por un hub físico distante.

La separación se parece a otros sistemas definidos por software, pero los objetos eran específicos de la nube y conscientes de la aplicación. El controlador necesitaba acceso a cuentas y API, mientras que el nodo de borde necesitaba conectividad con tránsito nativo, redes de trabajo, endpoints privados o rutas externas. La autoridad nacía de combinar ambas vistas: intención global por encima de las nubes y ejecución local cerca del tráfico.

La arquitectura también creaba un límite operativo. Cada nodo de borde consumía recursos de nube, necesitaba alta disponibilidad y debía actualizarse, supervisarse y protegerse. La capa central requería credenciales con suficiente privilegio para descubrir activos y alterar el estado de red. La empresa ganaba un flujo común, pero añadía un sistema de gestión cuya disponibilidad y corrección afectaban a la conectividad de producción.

Prosimo utilizó a veces el lenguaje de red autónoma en la nube. Las pruebas respaldan automatización, recomendaciones y orquestación por API. No describen una red que opere sin política humana, servicios de nube o transporte subyacente. Los operadores seguían definiendo intención, aprobando acceso, resolviendo excepciones y respondiendo del resultado.

AXI Edge era una decisión de ubicación, no un dispositivo genérico

Un AXI Edge podía desplegarse en un VPC o VNet, en una instalación de colocación o en infraestructura adyacente. El recorrido técnico de AWS mostraba un VPC de borde conectado a VPC de carga mediante Transit Gateway, con encadenamiento opcional de firewall y acceso desde sedes o usuarios remotos. El punto de ejecución quedaba dentro de la topología de nube, no en un perímetro corporativo lejano.

La ubicación determinaba más que la latencia. Definía dónde entraba el tráfico en el dominio de política, qué red troncal de nube o ruta de internet utilizaba, dónde se cifraba o inspeccionaba y qué telemetría estaba disponible. Un nodo de borde mal situado podía generar desvíos o costes; uno bien ubicado podía acortar la ruta o mantener el tráfico cerca de la carga.

La distribución aumentaba los dominios de fallo. La capacidad, las versiones, el diseño de zonas, la convergencia de rutas y los permisos podían variar entre regiones. La alta disponibilidad requería más que dos instancias: el controlador, las tablas de rutas de nube, los servicios de seguridad y las rutas de retorno tenían que coincidir en el estado de conmutación.

Por tanto, el nodo de borde formaba parte de un sistema operativo más amplio. Su valor dependía de que descubrimiento, topología, política y análisis siguieran siendo coherentes con el entorno. Tratarlo como un dispositivo virtual autónomo perdería la arquitectura que Prosimo intentaba vender.

La infraestructura subyacente siguió en manos de terceros

Prosimo coordinaba el transporte, pero no era dueña de la ruta física. Una conexión podía utilizar la red troncal de AWS u otro proveedor, internet público, Direct Connect o ExpressRoute, un servicio de colocación, un circuito de operador o una red empresarial. La plataforma podía seleccionar y orquestar opciones disponibles; no podía eliminar la latencia, la pérdida de paquetes, los dominios de fallo o las reglas de precios creadas por esos proveedores.

Ese límite importa al evaluar promesas de rendimiento. Un controlador puede elegir una ruta observada mejor o acercar el ingreso al usuario. 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 también incluye DNS, procesamiento del servidor, almacenamiento, navegador y servicios externos fuera de la autoridad total del controlador.

No disponer de una red troncal propia no era solo una desventaja. Permitía utilizar infraestructura que las empresas ya habían comprado y beneficiarse de la inversión de los proveedores de nube. Prosimo podía llegar a regiones sin construir fibra y coordinar sistemas nativos como AWS Cloud WAN. A cambio, dependía de la estabilidad de las API, las cuotas, las condiciones comerciales y la semántica de cada proveedor.

La propuesta trataba de control operativo, no de propiedad física. La plataforma intentaba hacer que infraestructuras heterogéneas funcionaran como un único sistema gestionado, conservando sus ventajas nativas. Que esa abstracción redujera el lock-in o simplemente lo trasladara dependía de la portabilidad de las políticas, la topología y los nodos de borde.

Network Transit gestionaba la conectividad entre objetos de red

Network Transit se centraba en VPC, VNet, subredes, regiones, sedes y segmentos. Coordinaba servicios nativos de tránsito y objetos de ruta para que los equipos construyeran conectividad mediante un flujo común en vez de configurar cada proveedor por separado. Respondía a la necesidad clásica: una fuente o un segmento debe alcanzar un destino por una ruta permitida.

No pretendía que las diferencias entre nubes hubieran desaparecido. AWS, Azure y Google Cloud exponen objetos, cuotas y comportamientos distintos. Los solapamientos de direcciones, las rutas asimétricas, los endpoints privados y los límites de servicio seguían necesitando ingeniería. Prosimo podía normalizar operaciones comunes y mostrar relaciones, pero los sistemas subyacentes conservaban sus restricciones.

Network Transit también aportaba segmentación. Los dominios de ruta y las políticas podían separar entornos o limitar conectividad. El controlador tenía que entender dónde existía un segmento entre nubes y cómo se materializaba con objetos nativos. Una política expresada una sola vez podía generar varios cambios específicos de cada proveedor.

La ventaja era una superficie unificada de intención. El riesgo era la traducción. Si la política común y la configuración real divergían, la empresa podía creer que un segmento estaba protegido cuando el estado del proveedor indicaba lo contrario. La reconciliación, la auditoría y los errores explícitos eran tan importantes como el aprovisionamiento inicial.

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

App Transit ampliaba el modelo más allá de las subredes. Podía utilizar el dominio de la aplicación, identidad, tipo de solicitud, estado de transacción, riesgo y rendimiento para decidir cómo un usuario o una carga de trabajo alcanzaban un servicio. Era el intento más claro de diferenciarse de un router de nube convencional.

La vista de aplicación era útil porque los servicios modernos no siempre tienen direcciones fijas. Las plataformas gestionadas, endpoints SaaS y componentes distribuidos pueden cambiar mientras la identidad del servicio sigue siendo significativa. Una política que se refiere a la aplicación o al usuario puede durar más que otra basada solo en direcciones y puertos.

El modelo exigía descubrimiento correcto. El controlador debía saber qué dominios y endpoints pertenecían a una aplicación, qué dependencias eran necesarias y qué afirmaciones de identidad eran fiables. Un mapa obsoleto podía dirigir una solicitud por la ruta equivocada o aplicar una política incorrecta. La abstracción de aplicación no eliminaba la necesidad de conocer el estado de red; añadía una capa semántica.

La combinación de Network Transit y App Transit reconocía que las empresas contienen ambos mundos. Persisten sistemas heredados, subredes privadas y controles IP, mientras que aplicaciones nuevas dependen de dominios, identidad y servicios gestionados. Full-Stack Cloud Transit era el nombre para operar ambos modelos juntos sin obligar a que uno sustituyera al otro.

La identidad ampliaba la decisión de ruta y el límite de confianza

El acceso consciente de la aplicación necesitaba integración de identidad. La plataforma podía usar el contexto de un usuario o carga para decidir si debía establecer una conexión y por qué camino. Esto respaldaba un enfoque zero trust en el que la ubicación no bastaba como prueba de autoridad.

La identidad mejoraba la precisión, pero añadía dependencia. La política pasaba a confiar en el proveedor de identidad, sus atributos, la sesión y los grupos. Una ruta podía fallar porque la autenticación no estuviera disponible o porque cambiara un atributo, aunque los routers y los nodos de borde funcionaran. El diagnóstico tenía que cruzar la frontera entre redes e identidad.

El controlador se convertía además en punto de concentración de contexto sensible. Podía reunir topología, relaciones de aplicación, atributos de usuario, señales de riesgo y resultados de política. Ese conjunto mejoraba diagnóstico y optimización, al tiempo que aumentaba el impacto de un acceso no autorizado. Mínimo privilegio, retención, auditoría y separación de funciones eran requisitos arquitectónicos.

El enfoque de Prosimo muestra una tendencia amplia: el enrutamiento y el acceso dependen cada vez más de identidad y semántica de aplicación. Cuanto más contexto ve una plataforma, más útiles pueden ser sus decisiones y más rigurosa debe ser la gobernanza de su autoridad.

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

Un controlador transversal no puede gobernar lo que no ve. Prosimo desarrolló funciones de descubrimiento de activos y mapas de VPC, VNet, subredes, aplicaciones, conectividad y relaciones de seguridad. Esas vistas apoyaban la incorporación de entornos, el diseño, la resolución de problemas y la aplicación de políticas.

El descubrimiento era estratégico porque los entornos cambian fuera de los flujos centrales de red. Los equipos de aplicaciones pueden crear cuentas, redes, endpoints y servicios con su propia automatización. Un diagrama manual queda obsoleto. Un inventario por API puede ser más reciente, aunque su integridad dependa de la cobertura de cuentas, los permisos, la lógica de los analizadores y las API.

El grafo no era solo documentación. Era la estructura a partir de la cual se calculaban rutas, segmentación, inserción de servicios y optimización. Si faltaba un activo o una dependencia, las conclusiones construidas sobre ese modelo podían ser erróneas. La topología necesitaba trazabilidad: fecha de recogida, cuenta de origen, regiones cubiertas y cualquier fallo de recopilación.

El grafo ayuda a explicar la adquisición. Palo Alto Networks obtiene valor cuando sabe dónde están las cargas y las rutas. Un sistema que descubre activos y cambia rutas acorta la distancia entre comprar un firewall de software y colocarlo correctamente. La declaración posterior de Bhau destacó precisamente descubrimiento de activos y despliegue acelerado de firewalls.

AIR convertía la telemetría de los nodos AXI Edge en recomendaciones

Application-driven Intelligent Results, o AIR, analizaba telemetría recogida por los nodos AXI Edge. El recorrido de AWS describía visibilidad de tiempo de ida y vuelta, procesamiento, respuesta de aplicación, tipo de transacción, riesgo y resultados de política. La plataforma podía correlacionar usuario, red y aplicación en vez de mostrar contadores aislados.

Esa correlación abordaba un problema común. Una transacción lenta puede originarse en el camino del usuario, el nodo de borde, la red troncal de nube, un servicio de seguridad o la aplicación. Una vista transversal puede acotar la búsqueda más rápido que varias consolas. También puede apoyar recomendaciones de ruta, ubicación, riesgo o coste.

La calidad dependía de la cobertura de telemetría y del modelo utilizado para interpretarla. Un nodo de borde solo observaba el tráfico que lo atravesaba, mientras que las dependencias externas y ciertas condiciones internas del proveedor podían quedar fuera. Por ello, una recomendación podía ser útil para orientar la investigación sin demostrar por sí sola la causa raíz.

La telemetría también tenía valor de gobernanza. Los registros históricos podían explicar por qué cambió una política, pero también podían exponer el uso de aplicaciones y el comportamiento de los usuarios. Los materiales públicos no ofrecen una explicación completa sobre retención y gobernanza de datos después de la adquisición, por lo que estas cuestiones siguen formando parte de la diligencia debida del cliente.

AWS ofreció la implementación pública mejor documentada

El trabajo con AWS produjo las pruebas técnicas públicas más sólidas. Prosimo se integró con Transit Gateway, Cloud WAN, PrivateLink y Marketplace for Containers Anywhere. AWS publicó un recorrido sobre ubicación de AXI Edge, incorporación de aplicaciones, identidad, seguridad y optimización.

AWS Cloud WAN era especialmente importante. Suministraba una red troncal nativa y segmentación que Prosimo podía orquestar sin sustituir. El acuerdo mostraba el modelo cooperativo: AWS poseía red e infraestructura mundial; Prosimo aportaba intención multinube, contexto de aplicación, nodos de borde y análisis.

Marketplace simplificaba el despliegue inicial mediante un canal aprobado, pero no eliminaba el trabajo posterior sobre permisos, diseño de rutas, alta disponibilidad, capacidad y operación. La automatización de la fase inicial reducía la fricción sin resolver el problema de control a largo plazo.

Una referencia de Flexport apoyaba el caso de uso en materiales corporativos. Mostraba que un cliente empresarial estaba dispuesto a respaldar la arquitectura, pero no constituía una auditoría independiente sobre escala, ahorro o disponibilidad. Las referencias de clientes deben tratarse como ejemplos de adopción, no como prueba universal de rendimiento.

Azure y Google Cloud completaban la afirmación multinube

Prosimo también admitía Microsoft Azure y Google Cloud. Sus materiales describían orquestación alrededor de Azure Virtual WAN y objetos de red y servicio privado de Google Cloud. La meta era un modelo único conservando las redes nativas.

La existencia de soporte no demuestra paridad. Las API evolucionan a ritmos diferentes y nombres similares esconden semánticas distintas. Una ruta, segmento, endpoint privado o inserción puede requerir tratamiento específico. Las pruebas no permiten reconstruir una matriz completa por región y versión.

La abstracción debe entenderse como un sistema de traducción. Puede normalizar la intención y el flujo de trabajo, pero debe conservar los detalles que afectan a la seguridad, el coste y los modos de fallo. Una interfaz uniforme se vuelve peligrosa cuando oculta diferencias relevantes de implementación.

Lo mismo ocurre después de la adquisición. Palo Alto Networks puede usar el grafo común para colocar seguridad, pero los proveedores siguen controlando los objetos nativos. Ser dueño de la orquestación no significa ser dueño de la infraestructura de 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, diagnosticar y gestionar redes multinube. La plataforma ya no se presentaba como un simple túnel o gateway: el descubrimiento apoyaba el diseño, la orquestación creaba conectividad, los mapas y la telemetría ayudaban al diagnóstico, y las políticas y el historial respaldaban la gestión continua.

Este encuadre ampliaba el número de compradores potenciales. El equipo de red podía utilizar la topología y el análisis; el equipo de nube, incorporar cuentas y servicios; seguridad, revisar la segmentación; migración, planificar cambios; y FinOps, estudiar los costes de salida de datos y las rutas. El valor de la plataforma aumentaba cuando varios grupos trabajaban sobre la misma evidencia.

La evidencia compartida también puede generar conflictos de gobernanza. Una plataforma central puede revelar que la configuración nativa difiere de la política empresarial, pero la organización debe decidir qué sistema es autoritativo y quién puede aprobar la corrección. El software puede exponer la divergencia; no puede resolver por sí solo esa cuestión institucional.

El enfoque de ciclo de vida también aumentaba los costes de cambio. Cuando un controlador conserva el grafo, las políticas, la telemetría, los nodos de borde y las integraciones, sustituirlo exige reconstruir gran parte del modelo operativo. Prosimo vendía una reducción de la fragmentación entre nubes, pero podía crear una nueva dependencia respecto del controlador.

La segmentación iba de la conectividad de red a la política de aplicación

Prosimo presentaba una segmentación que abarcaba de la capa 3 a la capa 7. En la red, los dominios y segmentos controlaban la conectividad; en las capas superiores, la identidad de la aplicación, el usuario y las propiedades de la transacción podían precisar la regla.

El modelo podía reducir la distancia entre zona de red y política de aplicación. Un servicio podía permitirse mientras la conectividad general entre subredes permanecía bloqueada. A la inversa, una ruta alcanzable podía denegarse por identidad o contexto.

Prosimo no se convertía por ello en un firewall completo. La integración separaba responsabilidades: Prosimo orquestaba rutas, segmentación e inserción de servicios, mientras VM-Series realizaba la inspección profunda. La distinción importa porque la dirección del tráfico y la aplicación de controles pueden fallar de formas diferentes.

Un segmento solo es eficaz si se representan todas las rutas relevantes. Una ruta desconocida, una excepción nativa o una inserción fallida puede eludirlo. La verificación operativa requiere comparar política declarada, estado de proveedor y tráfico observado.

La inserción de servicios vinculaba rutas y economía de firewall

El diseño de seguridad en la nube debe decidir dónde se realiza la inspección. Los firewalls centralizados pueden simplificar las políticas y reducir el número de instancias, pero también crear tráfico de retorno, concentración y presión de escala. Los firewalls distribuidos permanecen más cerca de las cargas de trabajo, aunque multiplican el despliegue, las licencias, las actualizaciones y las operaciones.

Prosimo permitía ambos patrones con VM-Series. La política podía dirigir tráfico a un punto central o a firewalls distribuidos en VPC de aplicación. El controlador actualizaba rutas y Palo Alto aportaba inspección.

Esto hacía valiosa la orquestación para un proveedor de seguridad. Un firewall no puede proteger tráfico que nunca lo alcanza; por eso, el descubrimiento, la colocación y la actualización de rutas reducen la fricción entre comprar capacidad de seguridad e insertarla en una ruta de producción. Esa es una razón estratégica plausible para la adquisición.

También ampliaba el radio de impacto de los errores. Una política equivocada podía eludir la inspección, crear bucles, provocar rutas asimétricas o dejar una aplicación fuera de servicio. Por ello eran necesarias comprobaciones previas, despliegues graduales, simulación, auditoría y mecanismos de reversión, ya que el fallo afectaba al mismo tiempo a la red y a la seguridad.

La asociación de 2024 no debe reinterpretarse retrospectivamente como una adquisición

Prosimo y Palo Alto Networks anunciaron la integración el 12 de junio de 2024. El comunicado describía una solución conjunta y no afirmaba que Palo Alto Networks hubiera adquirido Prosimo. Utilizarlo como prueba de propiedad confundiría dos acontecimientos distintos.

La asociación sí creó un puente. Prosimo podía demostrar que su capa de control facilitaba el despliegue de VM-Series, mientras Palo Alto Networks evaluaba la tecnología dentro de una integración real antes de la transición corporativa. Las fuentes no describen el proceso de compra, por lo que afirmar que la asociación fue una fase formal previa a la adquisición sería especulativo.

A comienzos de 2025 cambiaron los historiales profesionales de fundadores y empleados, y la página corporativa apareció posteriormente marcada como adquirida. A finales de ese año, Bhau afirmó que la tecnología estaba plenamente integrada en productos de Palo Alto Networks. En conjunto, estas señales respaldan la conclusión de que hubo una adquisición, aunque dejan sin resolver sus mecanismos jurídicos.

La secuencia importa a los clientes. Una asociación implica dos proveedores, dos estructuras de soporte y una frontera de integración definida; una adquisición puede trasladar hojas de ruta, datos, contratos y autoridad a una sola empresa. El cambio va más allá de la marca, aunque el recorrido técnico parezca inicialmente similar.

Nebula hizo accesible el grafo topológico mediante una interfaz conversacional

Prosimo presentó Nebula en febrero de 2024 dentro de una AI Suite. El asistente debía responder preguntas en lenguaje natural sobre solapamientos, costes, salud de rutas, violaciones de seguridad y otras condiciones representadas en grafo y telemetría.

El activo importante no era solo la interfaz, sino el contexto estructurado. Un modelo general no diagnostica una ruta privada que no ve. Nebula se apoyaba en inventario, topología, política y observaciones ya recogidas. La inversión previa en un grafo común se convertía en base para AIOps.

El acceso conversacional podía abrir datos complejos a más operadores. También podía crear confianza falsa si omitía activos, entendía mal la consulta o trataba una recomendación como acción autorizada. Los cambios de alto riesgo seguían necesitando controles deterministas, permisos y revisión humana.

Prosimo afirmó reducciones potenciales de 60–80 % del MTTR y más de 60 % del coste de las redes en la nube. Eran cifras del proveedor en una nota de producto. No existe metodología independiente ni base de clientes que demuestre aplicación general. Pueden citarse como beneficios propuestos, no como hechos medidos.

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

La misma nota presentó la arquitectura para IA. Los sistemas distribuidos pueden necesitar acceso privado a datos, enlaces entre nubes y centros, cumplimiento y rutas conscientes de la aplicación. Esos requisitos encajaban con el modelo existente de activos, política y rutas.

La etiqueta no cambiaba la infraestructura subyacente. Prosimo seguía dependiendo de redes en la nube, operadores e infraestructura del cliente. Tampoco suministraba GPU ni herramientas de desarrollo de modelos. Su posible función era la conectividad y seguridad alrededor de datos y servicios distribuidos.

La posición era estratégicamente lógica porque el valor de la topología aumenta con la distribución. También era una categoría de marketing introducida poco antes del final independiente. Las pruebas no establecen ingresos de IA, despliegues nombrados o resultados auditados.

La conclusión duradera es que la telemetría multinube puede alimentar operaciones asistidas por sistemas automatizados. La pregunta actual es si Palo Alto conservó ese contexto y cómo lo expone. Las fuentes no ofrecen una respuesta completa.

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

Prosimo era una propuesta de software por suscripción y servicios, no un operador. Los clientes desplegaban nodos AXI Edge y conectaban cuentas a la capa central. Los ingresos habrían dependido de licencias, soporte, servicios profesionales y canal, aunque precios y métricas no se publicaron en las pruebas.

Podía escalar sin fibra propia. Una plataforma podía coordinar muchas regiones. Sin embargo, la arquitectura no permite inferir márgenes. Mantener API, nodos de borde, integraciones y despliegue empresarial puede ser costoso; los recursos de nube consumidos por cada nodo de borde pueden pagarlos los clientes.

Prosimo utilizó marketplaces, integradores, canales y referencias de clientes para llegar al mercado empresarial. Estas relaciones no son equivalentes: una presencia en marketplace demuestra un canal de compra y despliegue; una integración técnica demuestra compatibilidad bajo determinadas condiciones; y un testimonio aporta una referencia comercial. Ninguno de estos elementos revela por sí solo el número de clientes de pago ni los ingresos recurrentes.

La amplitud podía complicar la venta. Los equipos de red, seguridad, nube y aplicaciones se beneficiaban, pero el presupuesto podía no tener dueño. El producto necesitaba un comprador dispuesto a financiar una capa común de control.

Socios, clientes e inversores ocupaban posiciones diferentes

AWS era a la vez proveedor de infraestructura y socio de integración, mientras Azure y Google Cloud figuraban como entornos compatibles. Los proveedores de identidad aportaban contexto de autenticación; los firewalls, capacidad de inspección; y los servicios de colocación y los operadores podían alojar o conectar nodos de borde. Los socios de canal podían diseñar, desplegar y gestionar las soluciones.

Flexport aparecía como referencia en material de AWS Cloud WAN. Demuestra interés empresarial, pero no revela alcance, duración o valor. No debe convertirse en sustituto del número de clientes.

General Catalyst lideró la Serie A y participó como inversor. Los materiales también citaban a WRVI o Celesta y, más adelante, una participación vinculada a BlackRock cuyo vehículo exacto no quedó resuelto. Esto demuestra una base de financiación bien conectada, no una tabla de capitalización completa.

Palo Alto Networks fue la relación decisiva: de socio en 2024 a comprador en 2025. La secuencia muestra cómo una dependencia de ecosistema se convierte en control cuando un participante compra la capa que coordina la ruta hacia su producto.

Se verificaron al menos 55 millones; los términos económicos de la salida siguen sin conocerse

El registro verificado incluye una Serie A de 25 millones de dólares en abril de 2021 y una Serie B de 30 millones en 2022. No hay una tabla de capitalización auditada ni datos públicos sobre valoración, deuda o rondas posteriores.

El precio de adquisición no se divulgó ni se verificó de forma independiente. Sin esa cifra, no es posible clasificar responsablemente la operación como una compra con prima estratégica, una adquisición tecnológica modesta, un acqui-hire o una venta bajo presión. La continuidad de la integración demuestra valor tecnológico, pero no revela el retorno obtenido por inversores o fundadores.

No debe atribuirse a Prosimo la escala financiera de Palo Alto Networks. Al dejar de ser observable, no existe un segmento autónomo de ingresos, beneficio o clientes. Un propietario mayor puede ampliar el alcance y hacer menos visibles las cifras individuales.

La ausencia de un anuncio formal de adquisición también es relevante. Este tipo de documentos suele aclarar el calendario, el soporte y la lógica estratégica; en este caso, el estado debe reconstruirse a partir de historiales profesionales, la etiqueta de la página corporativa y una declaración posterior del cofundador. Esa evidencia basta para corregir la condición corporativa, pero no para inventar términos de la transacción.

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

Prosimo competía con plataformas especializadas como Aviatrix y Alkira, con proveedores de redes empresariales y SASE, con los servicios nativos de AWS, Azure y Google Cloud, y con enfoques internos basados en infraestructura como código, servicios de tránsito, tablas de rutas y firewalls. Cada alternativa resolvía una parte diferente del mismo problema.

Un controlador especializado podía ofrecer una topología y unas políticas comunes entre proveedores. Una solución nativa reducía la dependencia externa dentro de una sola nube; un operador aportaba transporte físico; una plataforma de seguridad combinaba conectividad e inspección; y el desarrollo interno preservaba el control a cambio de más personal e integración.

La diferenciación de Prosimo era la combinación de tránsito de red y aplicación, nodos de borde, orquestación nativa, grafo, telemetría e inserción de servicios. Esa amplitud dificultaba las comparaciones. Los compradores debían probar servicios, rutas, identidades y seguridad concretos.

La adquisición cambia el marco competitivo. Prosimo ya no compite como empresa independiente; su tecnología debe justificar su lugar dentro de Palo Alto Networks. La cuestión pasa a ser cuánto mejora el despliegue de seguridad y cuánta dependencia adicional están dispuestos a aceptar los clientes.

Los servicios nativos eran fundamento y sustituto

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN y Google Cloud daban opciones potentes. Prosimo dependía de ellos y competía con la operación directa por parte del cliente.

La frontera era móvil. Las nuevas funciones nativas podían reproducir partes de la propuesta de Prosimo y, al mismo tiempo, añadir más objetos que un controlador transversal debía coordinar. La evolución de los servicios de nube podía reducir el valor de algunas funciones y aumentar la necesidad de traducción entre proveedores.

La decisión era organizativa además de técnica. Una empresa de una sola nube y fuerte ingeniería podía preferir nativo. Una multinube fragmentada podía valorar un plano común. Una organización regulada podía apreciar evidencia independiente y temer concentración de credenciales.

Ningún enfoque eliminaba la dependencia tecnológica. Las herramientas nativas vinculaban al cliente con API y semánticas específicas de un proveedor; el controlador transversal lo vinculaba con su grafo, sus políticas y sus nodos de borde. La cuestión relevante era si esa dependencia era visible, portable y adecuada al modelo operativo de la organización.

Los fallos podían originarse en el controlador, los nodos de borde, las API de nube, el sistema de identidad o la infraestructura subyacente

La arquitectura distribuida reducía la dependencia de un único concentrador, pero creaba varios dominios de fallo. El servicio central podía quedar desactualizado; un nodo de borde, aislado; una API, rechazar una parte del cambio; el sistema de identidad, dejar de responder; la infraestructura subyacente, degradarse; o un firewall, agotar sus recursos.

Los fallos parciales son especialmente difíciles de gestionar. Un proveedor puede aceptar una actualización mientras otro la rechaza, de modo que el estado deseado se separa del estado real y pueden aparecer rutas asimétricas o vías que eluden la inspección. El sistema necesita reconciliación, operaciones idempotentes, despliegues graduales, estados de error explícitos y mecanismos de reversión adaptados a cada proveedor.

La evidencia pública no contiene pruebas independientes de inyección de fallos, un registro completo de incidentes ni resultados universales de nivel de servicio. Por ello, cualquier afirmación sobre resiliencia debe vincularse a la arquitectura documentada o a evidencia concreta de clientes.

La adquisición añade otro riesgo: la continuidad del producto. Los clientes necesitan saber qué consola, API, imagen de nodo, modelo de políticas y organización de soporte reemplazan al sistema histórico. Una integración técnica satisfactoria puede aun así producir una migración deficiente si las fronteras comerciales y operativas quedan opacas.

Las credenciales de nube convertían al controlador en infraestructura crítica

El descubrimiento y la orquestación exigían acceso a las cuentas de nube. El inventario podía utilizar permisos de solo lectura, mientras que los cambios en rutas, segmentos e inserción de servicios requerían una autoridad mayor. El controlador formaba parte del plano de gestión privilegiado aunque no fuera propietario de las cargas de trabajo.

Una credencial comprometida podía exponer topología o permitir cambios amplios. Un defecto o error podía propagarse por varias nubes. El radio de impacto aumentaba con la utilidad de la plataforma.

Las empresas necesitaban aplicar mínimo privilegio, credenciales separadas, aprobaciones múltiples, auditoría, rotación, revocación de emergencia y una vía de recuperación independiente del mismo controlador. Los materiales públicos no incluyen una evaluación de seguridad independiente y completa, por lo que estos elementos deben tratarse como controles necesarios, no como garantías verificadas.

El grafo de telemetría era igualmente sensible. Podía revelar aplicaciones, estructura de red, políticas, relaciones de usuarios, estado de las rutas y patrones de costes. La gobernanza posterior a la adquisición debe aclarar dónde se almacenan esos datos, qué productos pueden utilizarlos y cómo se migraron los permisos; las fuentes públicas no resuelven estas cuestiones.

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

Como empresa independiente, Prosimo podía presentarse como una capa común entre nubes y servicios de seguridad. Con Palo Alto Networks como propietario, los incentivos cambiaron: la tecnología podía facilitar el despliegue de VM-Series y otros productos del grupo, mejorando la integración y planteando dudas sobre el tratamiento de servicios de terceros.

La propiedad no demuestra por sí sola que desapareciera la neutralidad, pero tampoco se ha publicado una matriz actual de compatibilidad. La pregunta para los clientes pasa a ser si se mantiene el soporte para terceros, si las políticas y la telemetría pueden exportarse y si la optimización favorece la cartera del propietario.

La declaración destacó la inspección de entrada, salida y este-oeste. Esto sugiere que la topología y la orquestación pasaron a formar parte de un sistema de despliegue de seguridad, pero no demuestra que App Transit, el acceso de usuarios, la optimización de costes o todos los flujos históricos continuaran como capacidades separadas.

Es un patrón habitual de infraestructura: una startup abstrae un problema complejo de coordinación y una plataforma mayor compra esa abstracción para aumentar el uso de sus productos principales. El cliente puede ganar integración y, al mismo tiempo, perder parte de su independencia frente a proveedores.

El mapa del producto actual es el mayor dato ausente

La evidencia confirma la adquisición y la integración, pero no ofrece un mapa completo que relacione AXI, Network Transit, App Transit, AIR y Nebula con productos o SKU actuales. Tampoco se han publicado fechas de soporte, procedimientos de migración ni una tabla de continuidad funcional.

Esa ausencia impide una evaluación del producto en tiempo presente. La historia explica qué se construyó, pero no qué se vende o se mantiene hoy. Cualquier recomendación actual de despliegue debe basarse en documentación vigente de Palo Alto Networks.

También limita la estrategia. Una absorción completa del grafo sería distinta de utilizar solo el descubrimiento de activos y la colocación de firewalls. La declaración confirma continuidad técnica y deja el límite sin resolver.

Un documento de producto, guía o caso futuro podría aclararlo. Hasta entonces, la formulación precisa es que, según un cofundador, la tecnología se integró en productos de Palo Alto Networks, aunque el alcance y el empaquetado no están verificados.

¿Quién controla el enrutamiento multinube?

Ningún actor 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 concede. El controlador descubre la topología, traduce las políticas y modifica el estado de las rutas; los proveedores de nube controlan sus API, servicios de tránsito, endpoints privados, redes troncales y muchos dominios de fallo; y los operadores y proveedores de colocación controlan otros tramos del transporte. Los servicios de seguridad, por su parte, deciden si el tráfico inspeccionado se permite o se bloquea.

Prosimo buscaba la posición intermedia. Sin poseer la infraestructura subyacente, quería poseer el grafo y la traducción. Quien controla esa capa decide qué se ve, cómo se representan segmentos, dónde se colocan los nodos de borde, qué servicio inspecciona y qué telemetría manda. Eso constituye poder práctico sobre el enrutamiento.

Después de la adquisición, Palo Alto Networks controla la tecnología y su desarrollo. Los proveedores de nube conservan la autoridad dentro de sus propios entornos, y la empresa puede revocar credenciales o elegir otra arquitectura; aun así, la salida puede ser costosa si la topología, las políticas y los flujos operativos dependen del controlador.

La respuesta es, por tanto, estratificada: la empresa autoriza; el controlador coordina; los proveedores de nube y los operadores transportan; y la plataforma de seguridad aplica los controles. La historia de Prosimo muestra que el propietario de la capa de coordinación puede cambiar sin que cambien de manos las cuentas de nube o la fibra física.

Registro principal de fuentes

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

Prosimo identificó un cambio real en la infraestructura. La unidad de operación se desplaza del dispositivo y el prefijo hacia la aplicación, la identidad, las dependencias de servicio y el grafo de políticas. Las API hacen programable el estado de la red, mientras los nodos de borde permiten mover los puntos de aplicación de controles. Un controlador con visibilidad sobre varias nubes puede coordinar acciones que ninguna consola individual completa por sí sola.

También mostró el coste de esa coordinación: credenciales privilegiadas, mantenimiento continuo de API, descubrimiento preciso, traducción semántica, telemetría y disciplina operativa. Una capa común puede reducir el trabajo fragmentado y, al mismo tiempo, crear un nuevo punto de concentración. El mismo sistema que simplifica las rutas puede ampliar el impacto de una mala decisión.

La adquisición hace más visible la convergencia entre redes y seguridad. Una empresa de seguridad que conoce la topología y puede cambiar rutas no se limita a inspeccionar el tráfico que recibe; también ayuda a decidir qué tráfico llega a la inspección y dónde se produce.

Prosimo no debe recordarse únicamente como una marca desaparecida ni como prueba de que una plataforma resolvió el problema multinube. Su contribución duradera fue convertir el grafo transversal en una forma de infraestructura. La pregunta pendiente es si ese grafo, ahora dentro de una empresa mayor, seguirá siendo transparente, portable y gobernable.