Resumen

  • Fundada en 2019, Prosimo recaudó al menos 55 millones de dólares en su serie A de 2021 y serie B de 2022; los ingresos auditados, la valoración y el precio de adquisición siguen sin conocerse.
  • AXI combinaba intención, topología y analítica central con nodos distribuidos que descubrían los activos cloud, conectaban aplicaciones e insertaban seguridad sin poseer la red física.
  • La integración de VM-Series anunciada en junio de 2024 precedió al traspaso de Prosimo a Palo Alto Networks hacia febrero de 2025; ninguna fuente precisa la fecha, el precio ni la cartografía actual de productos.
  • El control sigue repartido entre empresas, software de orquestación, proveedores cloud y Palo Alto Networks; la portabilidad de la topología, las credenciales, las políticas y las rutas se convierte así en la prueba decisiva.

La empresa desapareció antes del problema

Sería inexacto presentar a Prosimo como un proveedor independiente activo en 2026. Los recorridos profesionales públicos muestran a sus fundadores y a varios empleados uniéndose a Palo Alto Networks hacia febrero de 2025. La página de la empresa Prosimo está marcada como adquirida, y el exdirector técnico Nehal Bhau escribió posteriormente que su tecnología se había integrado en los productos de Palo Alto Networks. Estos elementos establecen un cambio de control y la continuidad de su valor técnico. No permiten determinar la fecha exacta de la firma o finalización, la forma jurídica ni el precio de la transacción.

Esta corrección debe abrir el relato, pues modifica el tiempo gramatical de cada afirmación sobre los productos. AXI, Network Transit, App Transit, Application-driven Intelligent Results y Nebula eran capacidades de Prosimo documentadas durante el período de independencia. No deben presentarse como productos actuales vendidos por separado mientras Palo Alto Networks no haya publicado una cartografía actual de productos y soporte. Tras una adquisición, una arquitectura histórica puede subsistir como código integrado, servicio compartido, módulo o activo de ingeniería interna; estas situaciones no son equivalentes.

La desaparición de la marca no hace obsoleto el problema. Las empresas reparten sus cargas entre Amazon Web Services, Microsoft Azure, Google Cloud, centros de datos privados, sitios de coubicación, plataformas SaaS y usuarios remotos. Cada entorno posee sus propias rutas, puertas de enlace, puntos de conexión privados, controles de identidad, servicios de seguridad, cuotas y reglas de facturación. Una empresa puede ser dueña de todas sus cuentas sin disponer de una visión única del recorrido de una solicitud. La importancia de Prosimo reside en su intento de controlar esa visión de conjunto.

La adquisición constituye, por tanto, el eje narrativo, y no una simple nota final. Prosimo había construido una capa de control transversal capaz de descubrir activos, interpretar el contexto aplicativo y dirigir el tráfico hacia servicios de seguridad. Palo Alto Networks apareció primero como socio técnico cuyos firewalls VM-Series podían insertarse en esos recorridos, antes de convertirse en propietario de la tecnología. La frontera que separaba la orquestación del enrutamiento de la inspección profunda se trasladó al interior de una misma plataforma de ciberseguridad.

El enrutamiento multicloud es una batalla por el contexto

Una tabla de enrutamiento puede indicar si un prefijo es accesible a través de un próximo salto. Por sí sola, no puede explicar qué aplicación intentaba alcanzar el usuario, si el solicitante es de confianza, si un servicio de inspección debe ver el tráfico, si hay un punto de conexión privado disponible, si una ruta cloud cuesta más que otra o si la transacción falla tras la llegada del paquete. Las operaciones multicloud convierten estas cuestiones en un problema de control compartido.

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

Esta distinción explica la expresión «infraestructura de experiencia de aplicación». Situaba la solicitud aplicativa por encima de cada objeto de red. Un VPC, un VNet, una subred, un hub de tránsito o un enlace privado se convertía en un componente de una ruta de extremo a extremo, en lugar del objeto final de gestión. El enfoque también situaba el producto en la intersección de varios mercados: red cloud, entrega de aplicaciones, acceso de confianza cero, aseguramiento de red, optimización de costes e inserción de servicios de seguridad.

Esta amplitud funcional creaba tanto una oportunidad como una ambigüedad. Un producto utilizado por varios equipos puede resolver fallos de coordinación de los que ningún equipo es responsable por sí solo. También puede ser difícil de evaluar, porque los equipos de red, seguridad, cloud, aplicaciones y finanzas no emplean los mismos criterios de éxito. Prosimo debía demostrar que un modelo transversal mejoraba las operaciones sin convertirse en una nueva capa privilegiada cuyos errores afectarían a todos los entornos.

Lo que era Prosimo — y lo que queda

Prosimo era una empresa privada de software de red cloud fundada en 2019 en el área de San Francisco. Ramesh Prabagaran era cofundador y director general, mientras que Nehal Bhau ocupaba el cargo de cofundador y director técnico durante el período de independencia. Los historiales públicos también identifican a Linus Aranha y Pradeep Aragonda en funciones fundadoras o de dirección de ingeniería, pero sus títulos exactos deben estar vinculados a biografías fechadas.

Su plataforma principal se llamaba Application eXperience Infrastructure, abreviada generalmente AXI. AXI combinaba una capa de software central para la intención, la topología, el análisis y la orquestación con AXI Edges distribuidos en las regiones cloud, los entornos de coubicación o las infraestructuras locales adyacentes. La oferta se organizó posteriormente bajo los nombres Full-Stack Cloud Transit, Network Transit y App Transit, que cubrían diferentes clases de conectividad. AIR analizaba la telemetría y generaba indicaciones operativas; Nebula añadió una interfaz conversacional en 2024.

Prosimo no era un operador cloud. La empresa no poseía un backbone global de fibra que conectara todas las regiones. Las rutas podían utilizar los backbones de los proveedores cloud, Internet, circuitos directos, conexiones de coubicación y las redes de la empresa. Tampoco era un proveedor de firewall en el mismo sentido que Palo Alto Networks. En la integración de 2024, su papel consistía en descubrir, segmentar y dirigir; VM-Series proporcionaba la inspección de seguridad profunda.

Tras la adquisición, la descripción más prudente es la de un «legado tecnológico». La declaración posterior sobre la integración destaca el descubrimiento de activos multicloud y el despliegue más rápido de firewalls de software para los flujos entrantes, salientes y este-oeste. Demuestra que componentes importantes de Prosimo han sobrevivido. No demuestra que todo el catálogo histórico de AXI, su modelo de comercialización o su modelo de soporte hayan continuado sin cambios.

El problema aparecido después del SD-WAN

El equipo fundador tenía experiencia en redes a gran escala, entrega de aplicaciones e infraestructura cloud. Prosimo también provenía del ecosistema más amplio de fundadores e ingenieros asociados con Viptela, empresa que había contribuido a establecer el SD-WAN como categoría empresarial. El siguiente problema era diferente. El SD-WAN podía simplificar la relación entre las sucursales y las redes o aplicaciones, pero no creaba un modelo operativo único dentro y entre múltiples nubes públicas.

Una aplicación multicloud puede depender de un endpoint web en un entorno, de una base de datos o un servicio gestionado en otro, de un proveedor de identidad externo a ambos, de conectividad privada hacia un centro de datos y de una inspección de seguridad situada en ciertas fronteras. Cada dependencia puede estar representada por un objeto nativo diferente. El equipo de red ve prefijos y hubs de tránsito; el equipo cloud ve cuentas y recursos; el propietario de la aplicación ve dominios y transacciones; el equipo de seguridad ve zonas y políticas de inspección.

Prosimo partía de la solicitud, en lugar de la sucursal. La pregunta útil era cómo un usuario o una carga de trabajo debía alcanzar una aplicación con un nivel aceptable de seguridad, rendimiento, disponibilidad y coste. Este planteamiento transformaba el objeto del enrutamiento: del mero prefijo de destino a una transacción portadora de identidad y contexto aplicativo. También obligaba a la plataforma a recopilar y mantener mucha más información que un router convencional.

El momento era favorable. AWS, Azure y Google Cloud estaban enriqueciendo sus servicios nativos de tránsito y conectividad privada. Las empresas podían construir redes sofisticadas en 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 estos servicios sin obligar a cada cliente a sustituirlos por un backbone propietario separado.

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

Prosimo se fundó en 2019, pero su lanzamiento público no se anunció hasta el 6 de abril de 2021. General Catalyst lideró una serie A de 25 millones de dólares en el momento del lanzamiento. El inversor presentaba la oportunidad como la oferta de una experiencia de aplicación a través de múltiples nubes, en consonancia con la voluntad de los fundadores de definir una categoría que fuera más allá de la conectividad clásica de sucursales.

El lanzamiento situaba a la empresa en un mercado denso y aún mal definido. Los proveedores cloud facilitaban el consumo de sus propios servicios de red. Los vendedores de SD-WAN y SASE extendían sus políticas a los entornos cloud. Los proveedores de entrega de aplicaciones podían optimizar las solicitudes, mientras que las empresas de ciberseguridad podían inspeccionarlas. La propuesta de Prosimo se basaba en reunir estas funciones en una arquitectura orientada a la nube, sin pretender sustituir todo el sistema circundante.

La financiación permitió desarrollar integraciones, edges de software, análisis, una organización comercial y relaciones de asociación. No demostraba ni la adecuación al mercado, ni la escala de ingresos, ni una diferenciación duradera. En los elementos proporcionados no se publican ingresos auditados, ingresos recurrentes anuales, número de clientes o valoración. La financiación muestra el compromiso de los inversores con una tesis, no un relato completo del rendimiento operativo.

En 2022, Prosimo realizó una serie B de 30 millones de dólares, presentada como sobresuscrita. La suma de las dos rondas claramente identificadas da un total verificado de al menos 55 millones de dólares. Algunas bases de datos pueden mostrar más cuando duplican anuncios o registros relacionados; esos totales no deben utilizarse sin resolver los eventos subyacentes.

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

La arquitectura AXI repartía el trabajo entre una capa central de control y análisis, y edges de software distribuidos. La capa central contenía la intención de aplicación y red, descubría los activos, ensamblaba la topología, integraba la identidad, analizaba la telemetría y orquestaba los cambios. Los AXI Edges se desplegaban cerca de las cargas de trabajo o los usuarios para aplicar las políticas sin obligar a cada ruta a pasar por un hub físico lejano.

Esta separación recuerda a otros sistemas definidos por software, pero los objetos eran propios de la nube y conscientes de las aplicaciones. El controlador necesitaba acceso a las cuentas cloud y a sus API, mientras que el edge debía conectarse a los servicios nativos de tránsito, a las redes de cargas de trabajo, a los puntos de conexión privados o a las rutas externas. La autoridad de la plataforma surgía de la combinación de estas vistas: intención global por encima de las nubes y ejecución local cerca del tráfico afectado.

La arquitectura también creaba una frontera de despliegue concreta. Cada edge consumía recursos cloud, requería un diseño de alta disponibilidad y debía actualizarse, supervisarse y protegerse. La capa de control exigía credenciales con privilegios suficientes para descubrir los activos y modificar el estado de la red. La empresa ganaba un flujo de trabajo común, pero añadía un sistema de gestión cuya disponibilidad y fiabilidad se volvían esenciales para la accesibilidad de producción.

Prosimo empleaba a veces el vocabulario de la «red cloud autónoma». Las pruebas avalan la automatización, las recomendaciones y la orquestación mediante API. No describen una red independiente de las políticas humanas, de los servicios de los proveedores cloud o del transporte subyacente. Los operadores seguían definiendo la intención, aprobando los accesos, tratando las excepciones y siendo responsables del resultado.

AXI Edge era una decisión de colocación, no un appliance genérico

Un AXI Edge podía desplegarse en un VPC o VNet cloud, un entorno de coubicación o una infraestructura adyacente. La guía técnica de AWS mostraba un VPC de edge conectado a los VPC de cargas de trabajo mediante Transit Gateway, con encadenamiento opcional de un firewall y acceso desde usuarios remotos o sitios locales. La ejecución de Prosimo se situaba así en la topología cloud, en lugar de en un perímetro empresarial lejano.

La colocación influía en algo más que la latencia. Determinaba el punto de entrada del tráfico en el dominio de política, el backbone cloud o la ruta de Internet utilizada, el lugar del cifrado y la inspección, así como la telemetría accesible. Un edge mal colocado podía crear un desvío o un coste; una colocación adecuada podía acortar la ruta o mantener el tráfico cerca de la carga de trabajo.

La distribución multiplicaba los dominios de fallo. La capacidad, las versiones de software, el diseño de las zonas cloud, la convergencia de rutas y los permisos podían variar de una región a otra. La alta disponibilidad no se limitaba a dos instancias: el controlador, las tablas de enrutamiento cloud, los servicios de seguridad y las rutas de retorno también debían acordar el estado de conmutación por error.

El edge formaba, por tanto, parte de un sistema operativo más amplio. Su valor dependía de la coherencia entre el descubrimiento de activos, la topología, las políticas, el análisis y el entorno cloud. Tratarlo como un appliance virtual autónomo haría perder de vista la arquitectura que Prosimo pretendía vender.

El transporte subyacente siempre pertenecía a otro

Prosimo coordinaba el transporte sin poseer el camino físico. Una conexión de aplicación podía utilizar el backbone de AWS o de otra nube, Internet público, Direct Connect o ExpressRoute, un servicio de coubicación, un circuito de operador o la red de la empresa. La plataforma podía seleccionar y orquestar las opciones disponibles; no podía eliminar la latencia, la pérdida de paquetes, los dominios de fallo o las reglas tarifarias creadas por esos proveedores.

Esta frontera es esencial para evaluar las promesas de rendimiento. Un controlador puede elegir un mejor camino observado o acercar el punto de entrada al usuario. No puede garantizar que un operador no sufra una avería, que una región cloud permanezca disponible o que una dependencia externa responda con rapidez. La experiencia de aplicación también incluye el DNS, el procesamiento del servidor, el almacenamiento, el comportamiento del navegador y los servicios de terceros, fuera de la autoridad total del controlador de red.

La ausencia de backbone propietario no era solo una debilidad. Permitía a Prosimo utilizar la infraestructura ya adquirida por las empresas y aprovechar las inversiones de los proveedores cloud. La empresa podía alcanzar nuevas 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 las semánticas propias de cada proveedor.

La propuesta tenía que ver, por tanto, con el control operativo, y no con la propiedad física. Prosimo pretendía hacer funcionar underlays heterogéneos como un único sistema gestionado, conservando sus ventajas nativas. Si esta abstracción reducía la dependencia del proveedor o la trasladaba, dependía de la portabilidad de las políticas, la topología y el despliegue de los edges.

Network Transit gestionaba la accesibilidad de los objetos de red

Network Transit se centraba en los VPC, VNet, subredes, regiones, sitios y segmentos. Coordinaba los servicios nativos de tránsito y los objetos de enrutamiento para que los equipos pudieran construir la conectividad mediante un flujo de trabajo común, en lugar de configurar cada proveedor por separado. El producto respondía a la necesidad de red clásica: un origen o un segmento debe alcanzar un destino por una ruta autorizada.

No pretendía que las diferencias entre nubes hubieran desaparecido. AWS, Azure y Google Cloud exponen objetos, cuotas y comportamientos de enrutamiento diferentes. Los espacios de direcciones que se solapan, las rutas asimétricas, los puntos de conexión privados y los límites de servicio seguían requiriendo ingeniería. Prosimo podía normalizar las operaciones comunes y mostrar las 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 limitar la accesibilidad. El controlador debía comprender dónde existía un segmento a través de las nubes y cómo los objetos nativos materializaban esa frontera. Una política escrita una sola vez podía generar aún múltiples cambios específicos del proveedor.

El beneficio era una superficie de intención unificada. El riesgo residía en la traducción. Si la política común y la configuración cloud divergían, la empresa podía creer que un segmento estaba protegido mientras que el estado real decía lo contrario. La conciliación, la auditoría y la notificación explícita de fallos eran, por tanto, tan importantes como el aprovisionamiento inicial.

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

App Transit ampliaba el modelo más allá de las subredes. Podía tener en cuenta el dominio de aplicación, la identidad, el tipo de solicitud, la salud transaccional, el riesgo y el rendimiento para decidir cómo un usuario o una carga de trabajo alcanzaba un servicio. Era el intento más claro de Prosimo de distinguirse de un router cloud clásico.

La vista de aplicación era útil porque los servicios modernos no siempre están representados por direcciones fijas. Las plataformas gestionadas, los endpoints SaaS y los componentes distribuidos pueden cambiar mientras la identidad del servicio permanece estable. Una política que haga referencia a la aplicación o al usuario puede durar más que una regla construida solo en torno a direcciones y puertos.

El modelo exigía un descubrimiento preciso. El controlador debía saber qué dominios y endpoints pertenecían a una aplicación, qué dependencias eran necesarias y qué afirmaciones del proveedor de identidad eran fiables. Una cartografía obsoleta podía dirigir la solicitud por la ruta equivocada o aplicar una regla de seguridad incorrecta. La abstracción de aplicación no eliminaba la necesidad de comprender el estado de la red; añadía una capa semántica por encima.

La unión de Network Transit y App Transit reconocía la coexistencia de ambos mundos en la empresa. Los sistemas heredados, las subredes privadas y los controles IP siguen presentes, mientras que las aplicaciones modernas se basan en los dominios, la identidad y los servicios gestionados. Full-Stack Cloud Transit era el nombre dado a la explotación conjunta de estos modelos, sin obligar a uno a sustituir al otro.

La identidad ampliaba la decisión de enrutamiento y el perímetro de confianza

El acceso consciente de las aplicaciones requería una integración de la identidad. La plataforma podía utilizar el contexto de un usuario o una carga de trabajo para decidir si una conexión debía establecerse y por qué ruta. Esto respaldaba una política de confianza cero en la que la ubicación no bastaba para demostrar la autorización.

La identidad mejoraba la precisión, pero añadía una dependencia. La política de ruta o de aplicación dependía ahora del proveedor de identidad, sus afirmaciones, el estado de sesión y los datos de grupo. Una ruta podía fallar porque la autenticación no estaba disponible o porque un atributo había cambiado, mientras que los routers y los edges seguían funcionando. El diagnóstico debía cruzar la frontera entre la red y la gestión de identidades.

El controlador también se convertía en un punto de concentración de información sensible. Podía contener topología, relaciones de aplicación, atributos de usuario, señales de riesgo y resultados de políticas. Este conjunto de datos mejoraba el diagnóstico y la optimización, pero agravaba las consecuencias de un acceso no autorizado. El principio de mínimo privilegio, la conservación, la auditoría y la separación de tareas formaban, por tanto, parte de la arquitectura, no de la simple administración.

El enfoque de Prosimo ilustra una evolución más general: el enrutamiento y el acceso dependen cada vez más de la identidad y la semántica de la aplicación. Cuanto más contexto ve una plataforma, más útiles pueden ser sus decisiones... y con más cuidado debe gobernarse su autoridad.

El descubrimiento de activos creaba el grafo del que dependían las decisiones

Un controlador transversal no puede gobernar lo que no ve. Prosimo desarrollaba un descubrimiento de activos cloud y mapas que representaban VPC, VNet, subredes, aplicaciones, conectividad y relaciones de seguridad. Estas vistas servían para la integración, el diseño, el diagnóstico y la política.

El descubrimiento era estratégico, porque los entornos cloud evolucionan al margen de los procesos centrales de la red. Los equipos de aplicaciones pueden crear cuentas, redes, endpoints y servicios gestionados mediante su propia automatización. Un diagrama dibujado a mano queda obsoleto. Un inventario basado en API puede proporcionar un grafo más reciente, pero su exhaustividad depende siempre de las cuentas cubiertas, los permisos, los analizadores y las API de los proveedores.

El grafo no era meramente documental. Constituía la estructura a partir de la cual se podían calcular el enrutamiento, la segmentación, la inserción de servicios y la optimización. Si faltaba un activo o una dependencia, todas las conclusiones construidas encima podían ser falsas. La topología necesitaba, por tanto, una procedencia: fecha de recogida, cuenta de origen, regiones cubiertas y posibles fallos de consulta.

Este grafo también contribuye a explicar la adquisición. Palo Alto Networks crea valor de seguridad cuando sabe dónde se encuentran las cargas de trabajo y las rutas de tráfico. Un sistema capaz de descubrir los activos y modificar las rutas reduce la distancia entre la compra de un firewall de software y su colocación adecuada. La declaración posterior de Nehal Bhau sobre la integración insistía precisamente en el descubrimiento de activos y la aceleración del despliegue de firewalls de software.

AIR transformaba la telemetría de los edges en recomendaciones

Application-driven Intelligent Results, o AIR, analizaba la telemetría recopilada por los AXI Edges. La guía de AWS describía una visibilidad sobre el tiempo de ida y vuelta, el tiempo de procesamiento, el tiempo de respuesta de la aplicación, el tipo de transacción, el riesgo y los resultados de las políticas. La plataforma podía correlacionar las observaciones del usuario, la red y la aplicación, en lugar de presentar contadores aislados.

Esta correlación respondía a un problema operativo frecuente. Una transacción lenta puede deberse a la ruta del usuario, al edge, al backbone cloud, a un servicio de seguridad o a la aplicación. Una vista transversal puede reducir el tiempo de búsqueda en comparación con varias consolas separadas. También puede fundamentar recomendaciones sobre la ruta, la colocación, el riesgo o el coste.

La calidad de una recomendación dependía de la cobertura de la telemetría y del modelo de interpretación. Un edge solo veía el tráfico que lo atravesaba. Las dependencias externas de la aplicación y ciertas condiciones internas del proveedor podían permanecer invisibles. Una recomendación podía ser útil sin demostrar la causa raíz.

La telemetría también tenía un valor de gobernanza. Las observaciones históricas podían explicar por qué una ruta o una política había cambiado. También podían exponer usos de aplicaciones y comportamientos de usuarios sensibles. La información pública no ofrece una descripción completa de la conservación o la gobernanza de los datos tras la adquisición; estas cuestiones permanecen, por tanto, en el ámbito de la diligencia del cliente.

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

Los trabajos de Prosimo con AWS constituyen las pruebas técnicas públicas más sólidas. La empresa se integró con AWS Transit Gateway, Cloud WAN, PrivateLink y el flujo de trabajo de Marketplace for Containers Anywhere. AWS publicó una guía sobre la colocación de los AXI Edges, la integración de las aplicaciones, la identidad, la seguridad y la optimización.

AWS Cloud WAN era especialmente importante. Proporcionaba un backbone nativo y un servicio de segmentación que Prosimo podía orquestar en lugar de sustituir. La arquitectura mostraba el modelo cooperativo: AWS poseía la red nativa y la infraestructura mundial; Prosimo aportaba la intención multicloud, el contexto de aplicación, el software de edge y los análisis.

El flujo de trabajo de Marketplace simplificaba el primer paso al proporcionar AXI Edge a través de un canal autorizado. No eliminaba el trabajo posterior sobre los permisos de las cuentas, el diseño de rutas, la alta disponibilidad, la capacidad y las operaciones. La automatización del día cero puede reducir la fricción de instalación, dejando intacto el problema del control a largo plazo.

Una referencia con nombre a Flexport respaldaba el caso de AWS Cloud WAN en los documentos de la empresa. Muestra que un cliente empresarial aceptaba recomendar la arquitectura, pero no constituye una auditoría independiente de la escala, los ahorros o la disponibilidad. Las citas de clientes deben servir como ejemplos de adopción, no como prueba universal del rendimiento.

Azure y Google Cloud completaban la promesa multicloud

Prosimo también era compatible con Microsoft Azure y Google Cloud. Sus documentos mencionaban la orquestación en torno a Azure Virtual WAN y a los objetos de red y servicio privado de Google Cloud. El objetivo era presentar un modelo operativo único, dejando en su sitio la red nativa de cada proveedor.

La compatibilidad no demuestra una paridad de funciones. 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 de conexión privado o una inserción de servicio pueden requerir un tratamiento propio del proveedor. Las fuentes proporcionadas no reconstruyen una matriz de paridad función por función para cada región y versión.

La abstracción multicloud es, por tanto, un sistema de traducción. Puede normalizar la intención común y los flujos de trabajo, pero debe preservar los detalles que afectan a la seguridad, el coste y las averías. Una plataforma se vuelve peligrosa cuando la interfaz parece uniforme mientras las diferencias de implementación quedan ocultas a los operadores.

El mismo principio se aplica tras la adquisición. Palo Alto Networks puede utilizar el grafo común para colocar la seguridad entre varias nubes, pero los proveedores conservan el control de los objetos nativos que materializan la ruta. Poseer la orquestación no significa poseer el underlay cloud.

El producto se amplió de la conexión al ciclo de vida

En 2023, Prosimo describía flujos de trabajo de diseño, construcción, resolución de problemas y gestión de redes multicloud. El producto iba más allá de un túnel o una puerta de enlace. El descubrimiento de activos respaldaba el diseño; la orquestación creaba la conectividad; los mapas y la telemetría ayudaban al diagnóstico; las políticas y el historial respaldaban la gestión continua.

Este enfoque ampliaba el comprador potencial. Un ingeniero de red podía explotar la topología y el análisis de rutas; un equipo de plataforma cloud, integrar cuentas y servicios; un equipo de seguridad, revisar la segmentación y la inspección; un equipo de migración, planificar los cambios; un equipo de FinOps, examinar las consecuencias de la ruta y el tráfico de salida. El valor aumentaba cuando varios grupos utilizaban las mismas pruebas.

Las pruebas comunes también pueden provocar conflictos de gobernanza. Una plataforma central puede revelar que la configuración nativa de un equipo cloud difiere de la política de la empresa. La organización debe decidir qué sistema tiene autoridad y quién puede aprobar la corrección. El software no resuelve por sí solo esta cuestión institucional.

La narrativa del ciclo de vida también reforzaba los costes de cambio. Cuando un controlador posee el grafo de activos, las políticas, la telemetría, las ubicaciones de los edges y las integraciones de automatización, sustituirlo exige algo más que mover un circuito. El cliente debe exportar o reconstruir su modelo operativo. Prosimo vendía una reducción de la fragmentación cloud, al tiempo que creaba la posibilidad de una dependencia del controlador.

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

Prosimo presentaba una segmentación de las capas 3 a 7. A nivel de red, los dominios de enrutamiento y los segmentos determinaban qué subredes o sitios podían comunicarse. En los niveles superiores, la identidad de la aplicación, el contexto del usuario y las propiedades de la transacción podían precisar la regla.

Este modelo podía reducir la brecha entre la zona de red y la política de aplicación. Un servicio de negocio podía estar autorizado mientras que una accesibilidad amplia entre subredes permanecía bloqueada. A la inversa, una ruta de red válida podía ser rechazada porque la identidad o el contexto de aplicación fallaba.

Esto no convertía a Prosimo en un firewall de nueva generación completo. La integración con Palo Alto Networks separaba las responsabilidades: Prosimo orquestaba las rutas, la segmentación y la inserción de servicios; VM-Series realizaba la inspección profunda. La distinción es importante, porque la orientación de las políticas y la aplicación de la seguridad fallan de maneras diferentes.

Un segmento solo es eficaz si todas las rutas pertinentes están representadas. Una ruta desconocida, una excepción nativa o una inserción fallida pueden eludir el control. La verificación exige, por tanto, comparar la política declarada, el estado del proveedor y el tráfico observado, y no confiar únicamente en la pantalla del controlador.

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

La seguridad cloud debe decidir dónde se realiza la inspección. Los firewalls centralizados simplifican a veces la política y reducen el número de instancias, pero pueden crear desvíos, concentración y presiones de capacidad. Los firewalls distribuidos permanecen cerca de las cargas de trabajo y reducen ciertas distorsiones, pero multiplican el despliegue, las licencias, las actualizaciones y las operaciones de política.

Prosimo soportaba ambos modelos en la integración de VM-Series. La política podía dirigir el tráfico seleccionado hacia un punto central o hacia firewalls distribuidos en los VPC de aplicación. El controlador actualizaba las rutas circundantes mientras Palo Alto Networks proporcionaba la inspección.

La arquitectura hacía valiosa la orquestación del enrutamiento para un proveedor de seguridad. Un firewall de software no protege el tráfico que nunca lo atraviesa. El descubrimiento, la colocación y los cambios de rutas reducen la fricción entre la compra de capacidad de seguridad y su inserción en una ruta activa. Esta es una razón estratégica plausible para la absorción de la tecnología de Prosimo por parte de Palo Alto Networks.

También ampliaba el radio de impacto del controlador. Una política errónea puede eludir la inspección, crear un bucle, producir un enrutamiento asimétrico o interrumpir la aplicación. Los controles de salud, los cambios por etapas, la simulación, la auditoría y la marcha atrás son necesarios, porque un error de inserción es a la vez un incidente de red y un incidente de seguridad.

La asociación de 2024 no debe convertirse retroactivamente en una adquisición

Prosimo y Palo Alto Networks anunciaron la integración de VM-Series el 12 de junio de 2024. El comunicado describía una solución técnica y comercial conjunta. No decía que Palo Alto Networks hubiera adquirido Prosimo. Utilizar ese anuncio como prueba de propiedad confundiría dos eventos distintos.

La asociación creó, sin embargo, un puente. Prosimo podía mostrar cómo su sistema de rutas y políticas facilitaba el despliegue de VM-Series en varias nubes. Palo Alto Networks podía evaluar la tecnología en una integración real antes de la transición posterior. Las fuentes públicas no describen el proceso de adquisición; afirmar que la asociación constituía formalmente una etapa preparatoria sería especulativo.

A principios de 2025, los historiales de los fundadores y empleados habían cambiado. La página de la empresa mostró posteriormente un estado de adquirida. A finales de 2025, Bhau declaró que la tecnología estaba totalmente integrada en los productos de Palo Alto Networks. Estos elementos apoyan conjuntamente la conclusión de una adquisición, aunque dejan sin resolver los mecanismos jurídicos.

Esta secuencia es importante para la precisión editorial y para los clientes. Una asociación implica dos proveedores, dos estructuras de soporte y una frontera de integración definida. Una adquisición puede trasladar las hojas de ruta, los datos, los contratos y la autoridad a una sola empresa. La transición cambia algo más que la marca, aunque la ruta técnica parezca similar al principio.

Nebula transformaba el grafo topológico en una interfaz conversacional

Prosimo introdujo Nebula en febrero de 2024 dentro de una AI Suite para la red multicloud. El asistente debía responder en lenguaje natural a preguntas sobre redes que se solapan, costes, salud de las rutas, violaciones de la política de seguridad y otras condiciones representadas en el grafo y la telemetría.

El activo útil no era la interfaz lingüística en sí, sino el contexto multicloud estructurado subyacente. Un modelo general no puede diagnosticar una ruta privada o un segmento que no ve. Nebula podía apoyarse en el inventario, la topología, las políticas y las observaciones ya recogidas. La inversión previa en un grafo común se volvía así pertinente para la AIOps.

El acceso conversacional podía hacer accesibles datos complejos a más operadores. También podía generar una falsa confianza si la respuesta omitía un activo no soportado, entendía mal la pregunta o trataba una recomendación como una acción aprobada. Los cambios de alto riesgo seguían exigiendo controles deterministas, límites de autorización y revisión humana.

Prosimo avanzaba posibles mejoras, como una reducción del 60 al 80 % del tiempo medio de resolución y de más del 60 % del coste de la red cloud. Estas cifras eran afirmaciones de la empresa en un anuncio de producto. Ninguna metodología independiente ni base de clientes proporcionada demuestra que se apliquen en general. Pueden citarse como beneficios propuestos por Prosimo, no como hechos medidos del mercado.

Las cargas de IA constituían un caso de uso, no la prueba de un nuevo mercado

El mismo anuncio de 2024 presentaba la arquitectura como útil para las cargas de trabajo de inteligencia artificial. Los sistemas de IA distribuidos pueden necesitar acceso privado a los datos, conexiones entre nubes y centros de datos, controles de cumplimiento y un enrutamiento que tenga en cuenta el comportamiento de la aplicación. Estas necesidades coincidían con el modelo de activos, políticas y rutas ya desarrollado.

La etiqueta no cambiaba el underlay. Prosimo seguía dependiendo de las redes cloud, los operadores y la infraestructura de los clientes. La empresa no proporcionaba cálculo en GPU ni software de desarrollo de modelos. Su papel potencial era la conectividad y la seguridad en torno a datos y servicios distribuidos.

El posicionamiento de IA era lógico, porque el valor de una topología transversal aumenta con la distribución de datos y servicios. También constituía una categoría de marketing introducida poco antes del fin de la independencia. Los elementos proporcionados no establecen ni ingresos separados vinculados a la IA, ni despliegues de producción nombrados, ni resultados auditados.

El punto duradero es que la telemetría multicloud puede alimentar operaciones asistidas por máquina. La cuestión actual es si Palo Alto Networks ha conservado ese contexto y cómo expone la capacidad. Las fuentes públicas disponibles en la fecha de corte no dan la respuesta completa.

El modelo de negocio vendía software sobre infraestructura de terceros

Prosimo funcionaba como una empresa de software por suscripción y servicios, no como un operador. Los clientes desplegaban AXI Edges en sus entornos y conectaban sus cuentas cloud a la capa de control. Los ingresos habrían dependido de licencias o suscripciones, soporte, servicios profesionales y canales, pero los precios y las métricas contractuales exactas no se publican en los elementos proporcionados.

El modelo podía crecer sin poseer fibra. Una plataforma de software podía coordinar muchas regiones y muchos entornos. Sin embargo, no es posible deducir la economía bruta. El soporte de las API de los proveedores, el ciclo de vida de los edges, las integraciones de seguridad y el despliegue empresarial pueden ser costosos, mientras que los recursos cloud consumidos por los edges pueden ser pagados directamente por el cliente.

Prosimo utilizaba los marketplaces, los socios de integración, los canales y las referencias de clientes para llegar a las empresas. Estas relaciones no son equivalentes. Una presencia en un marketplace demuestra un canal de compra y despliegue. Una integración técnica demuestra que dos sistemas pueden funcionar juntos en condiciones definidas. Una cita de un cliente proporciona una referencia. Ninguna revela por sí sola el número de clientes de pago o los ingresos recurrentes.

La amplitud de la oferta podía complicar la venta. Los equipos de red, seguridad, cloud y aplicaciones podían beneficiarse todos, pero la propiedad presupuestaria podía seguir siendo difusa. El producto necesitaba un comprador dispuesto a financiar una capa de control común, en lugar de dejar que cada nube y cada equipo funcionaran por separado.

Socios, clientes e inversores ocupaban posiciones distintas

Amazon Web Services era a la vez un proveedor de la infraestructura subyacente y un socio de integración comercial. Azure y Google Cloud eran entornos soportados. Los proveedores de identidad aportaban el contexto de autenticación. Los firewalls proporcionaban la inspección. Los servicios de coubicación y los operadores podían alojar o conectar los edges. Los socios de canal podían diseñar y operar los despliegues.

Flexport figuraba como referencia de cliente en los documentos de AWS Cloud WAN. La referencia muestra un interés empresarial por la arquitectura, pero los elementos no proporcionan la amplitud, la duración o el valor comercial completo del despliegue. No debe servir como sustituto del número total de clientes.

General Catalyst lideró la serie A y participó en la gobernanza como inversor. Inversores vinculados a WRVI o Celesta aparecían en los documentos, mientras que mensajes posteriores mencionaban otras participaciones conocidas, incluido un nombre vinculado a BlackRock cuyo vehículo exacto no se ha resuelto. Estos elementos indican una base de financiación bien conectada, no una tabla de capitalización completa.

Palo Alto Networks ocupaba la relación más importante. La empresa pasó de ser socio de seguridad en 2024 a adquirente a principios de 2025. La secuencia muestra cómo una dependencia del ecosistema puede convertirse en una relación de control cuando un participante compra la capa de software que coordina la ruta hacia su producto.

Se recaudaron al menos 55 millones de dólares; la economía de la salida sigue siendo desconocida

La financiación verificada incluye una serie A de 25 millones de dólares en abril de 2021 y una serie B de 30 millones de dólares en 2022, es decir, al menos 55 millones. No se dispone de ninguna tabla de capitalización auditada, valoración, deuda o ronda posterior en los elementos proporcionados.

La contrapartida de la adquisición no se ha revelado ni verificado de forma independiente. Sin el precio, es imposible calificar adecuadamente la operación como prima estratégica, compra tecnológica modesta, «acqui-hire» o venta en dificultades. La continuación de la integración respalda la idea de un valor tecnológico, pero no revela el rendimiento de los inversores o fundadores.

Los ingresos y la escala de Palo Alto Networks no deben atribuirse a Prosimo tras la adquisición. Al dejar la startup de ser observable por separado, ya no existen ingresos, beneficios o segmentos de clientes autónomos que analizar. Un propietario más grande puede difundir más la tecnología, al tiempo que hace menos visible su economía individual.

La ausencia de un anuncio formal de adquisición es en sí misma pertinente. Los clientes, los empleados y los investigadores utilizan normalmente estos comunicados para determinar el calendario, el soporte y la lógica estratégica. Aquí, el estatus debe reconstruirse a partir de los recorridos profesionales, una etiqueta en la página de la empresa y una declaración posterior del fundador. Es suficiente para corregir el estatus, pero insuficiente para inventar los detalles de la transacción.

La competencia procedía de las plataformas, las nubes y la ingeniería interna

Prosimo competía con plataformas especializadas como Aviatrix y Alkira, con proveedores de redes empresariales y SASE, así como con los servicios nativos de AWS, Azure y Google Cloud. También se enfrentaba a un modelo interno en el que la empresa utiliza directamente la infraestructura como código, los servicios de tránsito, las tablas de enrutamiento y los firewalls de los proveedores. Estas alternativas resolvían porciones diferentes del mismo problema.

Un controlador especializado podía proporcionar una sola topología y un solo modelo de política. Un diseño nativo de la nube podía reducir la dependencia de un tercero y alinearse estrechamente con un proveedor. Un servicio soportado por un operador podía proporcionar el transporte físico. Una plataforma SASE o de seguridad podía combinar conectividad y aplicación. La ingeniería interna podía preservar el control a costa de un esfuerzo de personal e integración.

La diferenciación de Prosimo reunía el tránsito de aplicación y de red, los edges distribuidos, la orquestación nativa, la topología, la telemetría y la inserción de servicios. Esta amplitud también hacía difíciles las comparaciones. Los compradores debían probar las nubes, las rutas, las identidades y los modelos de seguridad que pensaban utilizar realmente, en lugar de comparar etiquetas de categoría.

La adquisición modifica el marco competitivo. Prosimo ya no tiene que ganar como empresa autónoma; su tecnología debe demostrar su valor dentro de Palo Alto Networks. La comparación pertinente se convierte en la capacidad del descubrimiento y la orquestación integrados para mejorar el despliegue de los productos de seguridad de Palo Alto, y en la aceptación por parte de los clientes de la dependencia resultante.

Los servicios nativos de las nubes eran a la vez fundamento y sustituto

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN y los servicios de red de Google Cloud ofrecían a las empresas potentes opciones nativas. Prosimo dependía de estos servicios y se enfrentaba a la posibilidad de que los clientes los explotaran directamente.

Esta relación creaba una frontera móvil. Cuando un proveedor añadía enrutamiento global, segmentación, servicios privados o una política central, algunas funciones de terceros se volvían más fáciles de reproducir. Al mismo tiempo, cada nuevo servicio nativo añadía un objeto que el controlador transversal podía descubrir y coordinar. Los avances de las nubes podían reducir una parte del valor de Prosimo, al tiempo que aumentaban la necesidad de traducción entre proveedores.

El factor decisivo era tanto organizativo como técnico. Una empresa centrada en una nube y con una sólida ingeniería interna podía preferir las herramientas nativas. Una empresa multicloud con equipos fragmentados podía valorar un plano de control único. Una organización regulada podía apreciar una capa de evidencia independiente, al tiempo que temía la concentración de credenciales y datos.

Ninguna arquitectura eliminaba la dependencia del proveedor. Las herramientas nativas aumentaban la dependencia de las API y las semánticas de una nube. Un controlador transversal aumentaba la dependencia de su grafo, sus políticas y sus edges. La cuestión útil era si la dependencia seguía siendo visible, portable y adaptada al modelo operativo.

El fallo podía residir en el controlador, el edge, la API cloud, la identidad o el underlay

La arquitectura distribuida reducía la dependencia de un solo hub de tráfico, pero creaba varios dominios de fallo que interactuaban. El servicio central podía no estar disponible o conservar una intención obsoleta. Un edge podía caerse o aislarse. Una API cloud podía rechazar una parte del cambio. El proveedor de identidad podía no estar disponible. El underlay podía perder capacidad o tomar una ruta inesperada. Un firewall insertado podía agotar sus recursos.

Los fallos parciales son especialmente difíciles. Un proveedor puede aceptar una modificación de ruta mientras que otro la rechaza. El estado deseado por el controlador diverge entonces del estado real. El tráfico puede volverse asimétrico o eludir la inspección. Un sistema fiable necesita conciliación, operaciones idempotentes, cambios por etapas, estados de error explícitos y una marcha atrás adaptada a cada proveedor.

Las fuentes públicas describen la arquitectura de disponibilidad y optimización, pero no incluyen ningún estudio independiente de inyección de fallos, ni un registro completo de incidentes, ni un resultado universal de nivel de servicio. Las afirmaciones de resiliencia deben permanecer vinculadas a una arquitectura documentada o a un ejemplo de cliente con nombre.

La adquisición añade otro dominio de fallo: la continuidad del producto. Los clientes deben saber qué consola, API, imagen de edge, política y organización de soporte sustituye al sistema histórico. Una integración de código técnicamente exitosa puede crear un riesgo de migración cuando las fronteras comerciales y operativas siguen siendo difusas.

Las credenciales cloud convertían al controlador en una infraestructura de gestión crítica

El descubrimiento y la orquestación requerían acceso a las cuentas cloud. Un inventario de solo lectura podía utilizar derechos limitados, mientras que los cambios de rutas, segmentos y servicios exigían una autoridad mayor. El controlador se situaba, por tanto, en el plano de gestión privilegiado aunque no poseyera las cargas de trabajo.

La puesta en peligro de una credencial 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 en varias nubes. El riesgo aumentaba con la utilidad: cuantas más cuentas y servicios gobernara la plataforma, mayor era el radio de impacto potencial.

Las empresas necesitaban roles de mínimo privilegio, credenciales distintas para el descubrimiento y la escritura, aprobación multiparte, auditoría completa, rotación, revocación de emergencia y una vía de recuperación independiente del controlador. Los documentos públicos no proporcionan una evaluación de seguridad independiente completa; estos requisitos siguen siendo, por tanto, controles de despliegue necesarios, no garantías verificadas.

El grafo de telemetría era igualmente sensible. Podía revelar nombres de aplicaciones, estructura de la red, políticas, relaciones de usuarios, salud de las rutas y costes. La gobernanza tras la adquisición debería precisar dónde se almacenan estos datos, qué productos de Palo Alto Networks pueden utilizarlos y cómo se han migrado los permisos de los clientes históricos. Las fuentes públicas no responden a estas preguntas.

La adquisición trasladó una capa considerada neutra a una plataforma de seguridad

La posición independiente de Prosimo le permitía presentarse como una capa común entre nubes y servicios de seguridad. Cuando Palo Alto Networks se convirtió en propietario, los incentivos cambiaron. La tecnología adquirida podía facilitar el despliegue de VM-Series y otros productos de Palo Alto. Esto puede producir una mejor integración, al tiempo que plantea preguntas sobre el soporte de inspecciones de terceros.

La propiedad no demuestra que la neutralidad haya desaparecido. Los elementos proporcionados no contienen una matriz actual de socios o de arquitectura. Sin embargo, cambian la pregunta que hay que hacer. Los clientes deben saber si el controlador permanece abierto a varios proveedores, si las políticas y la telemetría son exportables y si la optimización favorece la cartera del propietario.

La declaración de integración ponía el acento en la inspección de los flujos entrantes, salientes y este-oeste. Esto sugiere que la topología y la orquestación se han convertido en parte de un sistema de despliegue de seguridad. No demuestra que las funciones históricas de App Transit, acceso de usuario, optimización de costes o cada flujo de trabajo de red hayan sobrevivido por separado.

Se trata de un patrón frecuente en la infraestructura. Una startup abstrae un problema de coordinación difícil; un gran proveedor compra la abstracción porque aumenta el uso y el control de su producto principal. El adquirente obtiene un camino hacia el despliegue. El cliente puede ganar en integración y perder en independencia del proveedor.

La cartografía del producto actual es el principal hecho que falta

El expediente público confirma la adquisición y la integración, pero no proporciona una correspondencia completa entre AXI, Network Transit, App Transit, AIR y Nebula y los productos u ofertas actuales de Palo Alto Networks. No publica ni fechas de fin de soporte, ni procedimientos de migración, ni una tabla de continuidad funcional.

Esta laguna impide una revisión del producto en presente. Las descripciones históricas explican lo que Prosimo había construido y por qué era importante. No dicen qué capacidades están hoy disponibles, bajo licencia o soportadas. Cualquier consejo de despliegue contemporáneo debe basarse en la documentación actual de Palo Alto Networks, no en los antiguos anuncios de Prosimo.

La ausencia de cartografía también limita el análisis estratégico. La absorción completa del grafo y la orquestación sería diferente de un uso selectivo del descubrimiento de activos y la colocación de firewalls. El primer caso crearía un amplio servicio de control multicloud; el segundo utilizaría Prosimo sobre todo para acelerar el despliegue de la seguridad. La declaración del cofundador confirma la continuidad tecnológica sin resolver esta frontera.

Un futuro documento de producto, una guía de migración o un caso de cliente podría levantar gran parte de la incertidumbre. Mientras tanto, 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 su alcance y su modelo de comercialización siguen sin verificarse.

¿Quién controla el enrutamiento multicloud?

Ningún actor controla por sí solo la ruta completa. La empresa controla la propiedad de las cuentas, la intención de negocio, el diseño de la aplicación y los derechos que concede. Un controlador transversal puede descubrir la topología, traducir las políticas, elegir las rutas y modificar el estado nativo de las rutas. Las nubes controlan sus API, servicios de tránsito, puntos privados, backbones y numerosos dominios de fallo. Los operadores y los sitios de coubicación controlan otras porciones. Los servicios de seguridad deciden si se autoriza el tráfico inspeccionado.

Prosimo buscaba la posición intermedia más estratégica. Sin poseer el underlay, quería poseer el grafo y la traducción de las políticas por encima. Quien controla esa capa decide qué activos son visibles, cómo se representan los segmentos, dónde se colocan los edges, qué servicio inspecciona el tráfico y qué telemetría es la autorizada. Es un poder de enrutamiento práctico incluso cuando la fibra pertenece a un tercero.

Tras la adquisición, Palo Alto Networks posee la tecnología superviviente y determina su integración, su modelo de comercialización y su desarrollo. Las nubes siguen siendo soberanas en sus entornos, y la empresa puede revocar las credenciales o elegir otra arquitectura. Sin embargo, la salida puede ser costosa si la topología, las políticas y los flujos de trabajo se han vuelto dependientes del controlador.

La respuesta es, por tanto, distribuida: la empresa autoriza; el controlador coordina; las infraestructuras subyacentes de las nubes y los operadores transportan; la plataforma de seguridad aplica. La historia de Prosimo muestra que la propiedad de la capa de coordinación puede cambiar sin que ninguna cuenta cloud o ruta física cambie de manos.

Registro principal de fuentes

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

Prosimo captó una evolución real de la infraestructura. La unidad de las operaciones de red se desplaza del dispositivo y del prefijo hacia la aplicación, la identidad, la dependencia del servicio y el grafo de políticas. Las API nativas hacen que el estado de la red sea programable, mientras que los edges de software distribuidos permiten desplazar los puntos de aplicación de las políticas. Un controlador que ve varias nubes puede coordinar acciones que ninguna consola individual puede realizar por sí sola.

La empresa también reveló el coste de esta coordinación. Una capa común exige credenciales privilegiadas, mantenimiento continuo de las API, 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 que simplifica el enrutamiento puede ampliar el radio de impacto de una mala decisión.

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

Por tanto, Prosimo no debe ser recordado ni como una marca autónoma que simplemente fracasó, ni como la prueba de que una plataforma ha resuelto el multicloud. Su contribución duradera fue definir el grafo transversal como infraestructura. La cuestión pendiente es si ese grafo, ahora dentro de una gran empresa de seguridad, sigue siendo lo suficientemente transparente, portable y gobernable como para inspirar confianza.