Resumen

  • Prosimo se fundó en 2019 y recaudó al menos 55 millones de dólares en las rondas de serie A (2021) y serie B (2022); los ingresos auditados, la valoración y el precio de adquisición no se han revelado
  • AXI combinaba intención, topología y análisis centralizados con nodos de borde distribuidos, que descubrían activos en la 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ó a la incorporación de Prosimo a Palo Alto Networks alrededor de febrero de 2025; la fecha exacta, el precio y el mapa de productos actual no se han hecho públicos
  • El control sigue distribuido 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 subsiste

En 2026 ya no es correcto describir a Prosimo como un proveedor independiente en activo. Los historiales profesionales públicos muestran que sus fundadores y varios empleados se incorporaron a Palo Alto Networks en torno a febrero de 2025. La página corporativa de Prosimo aparece etiquetada como empresa adquirida, y el exdirector de tecnología Nehal Bhau escribió posteriormente que la tecnología se había integrado en los productos de Palo Alto Networks. Las evidencias muestran un cambio de control y la continuidad del valor tecnológico, pero no aclaran la fecha exacta de firma o cierre, la forma jurídica ni el precio de la transacción.

Esa precisión debe aparecer al principio porque altera el tiempo verbal de todas las afirmaciones sobre los productos. AXI, Network Transit, App Transit, Application-driven Intelligent Results y Nebula fueron capacidades documentadas de Prosimo durante el período independiente. No deben presentarse como productos actuales que se venden por separado hasta que Palo Alto Networks publique un mapa actualizado de productos y soporte. Una arquitectura histórica puede sobrevivir a una adquisición como código incorporado, servicio compartido, módulo o activo interno de ingeniería; esas formas no son equivalentes.

La marca desapareció, pero el problema subyacente permaneció. Las empresas siguen distribuyendo cargas de trabajo entre Amazon Web Services, Microsoft Azure, Google Cloud, centros de datos privados, instalaciones de coubicación, plataformas de software como servicio y usuarios remotos. Cada entorno posee rutas, gateways, puntos finales privados, controles de identidad, servicios de seguridad, cuotas y reglas propias de facturación. Una organización puede ser propietaria de todas las cuentas y, aún así, no disponer de una visión única de cómo una solicitud recorre esos entornos.

La importancia de Prosimo radica en su intento de reunir y controlar esa visión operativa.

Por eso, la adquisición es el eje de la narrativa, y no un simple epílogo. Prosimo construyó una capa de control multicloud capaz de descubrir activos, interpretar el contexto de las aplicaciones y enrutar el tráfico a través de 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. La frontera entre la orquestación de rutas y la inspección profunda se trasladó así al interior de una única plataforma de ciberseguridad.

El enrutamiento multicloud es una disputa por el contexto

Una tabla de rutas puede indicar si un prefijo es alcanzable a través de un determinado siguiente salto. Por sí sola, sin embargo, no explica qué aplicación pretendía acceder el usuario, si el solicitante es fiable, si un servicio de inspección debe ver el tráfico, si existe un punto final privado, si una ruta en la nube cuesta más que otra o si la transacción está fallando después de que el paquete llegue. Las operaciones multicloud convierten estas preguntas en un problema compartido de control.

La tesis de Prosimo era que las decisiones de enrutamiento debían considerar más que la alcanzabilidad de Capa 3. Su software intentaba combinar el inventario de la nube, el estado de la red, la identidad de la aplicación, la identidad del usuario, el riesgo, el rendimiento y la telemetría de las transacciones. Ese contexto más amplio permitía expresar políticas como conectar una aplicación específica, separar un segmento, elegir un punto de entrada o encaminar tráfico seleccionado a través de un firewall.

El valor no procedía de la invención de una nueva ruta de fibra, sino de la decisión sobre cómo debían combinarse los caminos y servicios existentes.

Esta distinción explica el uso de la expresión “infraestructura de experiencia de aplicación”. El término situaba la solicitud de la aplicación por encima del componente individual de red. Una VPC, una VNet, una subred, un hub de tránsito o una conexión privada pasaban a ser un elemento de un camino extremo a extremo, y no el objeto final de la gestión. El enfoque también llevó el producto a varios mercados a la vez: redes en la nube, entrega de aplicaciones, acceso de confianza cero, verificación de red, optimización de costes e inserción de servicios de seguridad.

La amplitud creó oportunidad y ambigüedad. Un producto que abarca varios equipos puede resolver fallos de coordinación que ninguno de ellos controla por separado. También puede ser difícil de evaluar, porque las áreas de red, seguridad, nube, aplicaciones y finanzas utilizan definiciones distintas de éxito. Prosimo necesitaba demostrar que un único modelo entre nubes mejoraba las operaciones sin convertirse en otra capa privilegiada cuyos errores afectaran a todos los entornos.

Qué era Prosimo — y qué permanece

Prosimo era una empresa privada de software de redes en la nube, fundada en 2019 y con sede en el Área de la Bahía de San Francisco. Ramesh Prabagaran ejerció como cofundador y director ejecutivo, mientras que Nehal Bhau fue cofundador y director de tecnología durante el período independiente. Los historiales públicos también identifican a Linus Aranha y Pradeep Aragonda en funciones de fundación o liderazgo de ingeniería, aunque sus títulos exactos deben permanecer vinculados a biografías fechadas.

Su principal plataforma era la Application eXperience Infrastructure, abreviada como AXI. Utilizaba una capa central de software para la intención, la topología, el análisis y la orquestación, combinada con AXI Edges distribuidos en regiones de nube, entornos de coubicación o infraestructura local adyacente. Más adelante, la empresa organizó la oferta como Full-Stack Cloud Transit, con Network Transit y App Transit atendiendo a diferentes clases de conectividad. AIR analizaba la telemetría y generaba información operativa; en 2024, Nebula añadió una interfaz conversacional.

Prosimo no era un operador de nube. No poseía un backbone mundial de fibra que conectara todas las regiones. Los caminos podían atravesar backbones de los proveedores, internet pública, circuitos dedicados, enlaces de coubicación y redes empresariales. Tampoco era un proveedor de firewall en el mismo sentido que Palo Alto Networks. En la integración de 2024, su papel era descubrir, segmentar y dirigir; el VM-Series proporcionaba la inspección profunda de seguridad.

Tras la adquisición, la descripción más segura es “linaje tecnológico”. La declaración posterior de integración destaca el descubrimiento de activos multicloud y la implantación más rápida de firewalls de software para la inspección de entrada, salida y tráfico este-oeste. Esto demuestra que componentes importantes de Prosimo sobrevivieron. No demuestra que todo el catálogo histórico de AXI, el empaquetado comercial o el modelo de soporte al cliente continuaran sin cambios.

El problema que vino después de SD-WAN

El equipo fundador tenía experiencia en redes a gran escala, entrega de aplicaciones e infraestructura en la nube. Prosimo surgió también del ecosistema más amplio de fundadores e ingenieros ligado a Viptela, empresa que ayudó a establecer la red de área extensa definida por software como categoría empresarial. El problema siguiente era diferente. SD-WAN podía simplificar cómo las sucursales accedían a las redes y aplicaciones, pero no creaba un único modelo operativo 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 servicio gestionado en otro, de un proveedor de identidad externo a ambos, de conectividad privada con un centro de datos y de inspección de seguridad en perímetros seleccionados. Cada dependencia puede aparecer como un componente nativo distinto. El equipo de red puede ver prefijos y hubs de tránsito; el equipo de nube, cuentas y objetos de recurso; el responsable de la aplicación, dominios y transacciones; y el área de seguridad, zonas y políticas de inspección.

Prosimo partía de la solicitud, no de la sucursal. La cuestión relevante era cómo un usuario o una carga de trabajo debía alcanzar una aplicación con niveles aceptables de seguridad, rendimiento, disponibilidad y coste. Esta formulación cambió el objeto del enrutamiento: de solo un prefijo de destino a una transacción con contexto de identidad y de aplicación. También exigió que la plataforma recopilara y mantuviera mucha más información que un enrutador convencional.

El momento era favorable. AWS, Azure y Google Cloud ampliaban sus servicios nativos de tránsito y conectividad privada. Las empresas podían construir redes sofisticadas dentro de cada proveedor, pero las API, los objetos y los modelos de política seguían siendo específicos de cada uno. La oportunidad de Prosimo era coordinar esos servicios, en lugar de obligar a todos los clientes a sustituirlos por un backbone propietario separado.

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

Prosimo se fundó en 2019, pero no anunció su lanzamiento público hasta el 6 de abril de 2021. General Catalyst lideró una Serie A de 25 millones de dólares en aquel momento. El inversor describió la oportunidad como la entrega de experiencia de aplicación entre nubes, alineándose con el esfuerzo de los fundadores por definir una categoría más allá de la conectividad convencional de sucursales.

El lanzamiento colocó a la empresa en un mercado lleno y aún indefinido. Los proveedores de nube facilitaban el consumo de sus propios servicios de red. Los proveedores de SD-WAN y SASE extendían políticas a los entornos en la nube. Las empresas de entrega de aplicaciones podían optimizar solicitudes, mientras que las compañías de seguridad de red podían inspeccionarlas. La propuesta de Prosimo dependía de reunir esas funciones en una arquitectura orientada a la nube sin afirmar que reemplazaría todos los sistemas circundantes.

La financiación dio margen para crear integraciones, edges de software, análisis, una organización comercial y relaciones con socios. No demostró el ajuste del producto al mercado, la escala de ingresos o una diferenciación duradera. Las evidencias aportadas no incluyen ingresos auditados, ingresos recurrentes anuales, número de clientes ni valoración. El historial de financiación muestra el compromiso de los inversores con una tesis, no un retrato completo del rendimiento operativo.

En 2022, Prosimo cerró una Serie B de 30 millones de dólares, descrita como una ronda con sobredemanda. La suma de las dos rondas claramente identificadas produce un total verificado de al menos 55 millones de dólares. Algunas bases de datos pueden mostrar una cifra mayor al duplicar anuncios o registros relacionados; esos totales no deben utilizarse sin reconciliar los eventos subyacentes.

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

La arquitectura AXI dividía el trabajo entre una capa central de control y análisis y edges distribuidos en software. La capa central mantenía la intención de aplicaciones y redes, descubría activos, ensamblaba la topología, integraba identidad, analizaba telemetría y orquestaba cambios. Los AXI Edges se implantaban cerca de las cargas de trabajo o de los usuarios, para aplicar políticas sin obligar a que todo el tráfico pasara por un hub físico distante.

La separación se asemejaba a la de otros sistemas definidos por software, pero los objetos eran específicos de la nube e incorporaban contexto de aplicación. El controlador necesitaba acceso a cuentas y API de nube, mientras que el edge requería conectividad con servicios nativos de tránsito, redes de cargas de trabajo, endpoints privados o caminos externos. La autoridad de la plataforma procedía de la combinación de estas dos visiones: intención global por encima de las nubes y ejecución local cerca del tráfico relevante.

La arquitectura también creaba una frontera práctica de implantación. Cada edge consumía recursos de nube, exigía un diseño de alta disponibilidad y necesitaba ser actualizado, monitorizado y protegido. La capa de control necesitaba credenciales con privilegios suficientes para descubrir activos y modificar el estado de la red. La empresa ganaba un flujo de trabajo común, pero añadía un nuevo sistema de gestión cuya disponibilidad y corrección eran importantes para la conectividad de producción.

Prosimo utilizó a veces el lenguaje de red autónoma en la nube. Las evidencias sustentan automatización, recomendaciones y orquestación basada en API. No sustentan una red capaz de funcionar independientemente de políticas humanas, servicios de los proveedores o transporte subyacente. Los operadores seguían definiendo la intención, aprobando el acceso, resolviendo excepciones y respondiendo del resultado.

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

Un AXI Edge podía implantarse en una VPC o VNet de nube, en un entorno de coubicación o en infraestructura adyacente. La guía técnica de AWS mostraba una VPC de edge conectada a VPCs de workloads a través del Transit Gateway, con encadenamiento opcional de firewall y acceso desde usuarios remotos o sitios locales. El diseño situaba el punto de ejecución de Prosimo dentro de la topología de la nube, y no en un perímetro corporativo distante.

El posicionamiento afectaba a algo más que la latencia. Determinaba dónde entraba el tráfico en el dominio de política, qué backbone de nube o camino de internet utilizaba, dónde se producía el cifrado y la inspección y qué telemetría podía recopilar la plataforma. Un edge mal posicionado podía crear desvíos y costes adicionales; uno bien posicionado podía acortar el camino o mantener el tráfico cerca de la carga de trabajo.

La implantación distribuida aumentaba el número de dominios de fallo a gestionar. La capacidad, las versiones de software, el diseño de zonas de nube, la convergencia de rutas y los permisos de acceso podían variar por región. La alta disponibilidad exigía más que ejecutar dos instancias: el controlador, las tablas de rutas, los servicios de seguridad y los caminos de retorno también debían coincidir en el estado de failover.

El edge, por tanto, formaba parte de un sistema operativo más amplio. Su valor dependía de que el descubrimiento de activos, la topología, la política y el análisis se mantuvieran coherentes con el entorno de nube circundante. Tratarlo como un appliance virtual autónomo obviaría la arquitectura que Prosimo intentaba vender.

El underlay siempre perteneció a otra organización

Prosimo coordinaba el transporte, pero no poseía el camino físico. Una ruta de aplicación podía utilizar el backbone de AWS o de otro proveedor, una conexión de internet pública, Direct Connect o ExpressRoute, un servicio de coubicación, un circuito de operadora o una red empresarial. La plataforma podía seleccionar y orquestar entre las opciones disponibles; no podía eliminar la latencia, la pérdida de paquetes, los dominios de fallo ni las reglas de precio definidas por esos proveedores.

Esta frontera importa al evaluar las afirmaciones de rendimiento. Un controlador puede elegir un camino observado como mejor o acercar la entrada del usuario. No puede garantizar que una operadora no falle, que una región de nube permanezca disponible o que una dependencia externa responda rápidamente. La experiencia de la aplicación también incluye DNS, procesamiento en el servidor, almacenamiento, comportamiento del navegador y servicios de terceros fuera de la autoridad total del controlador de red.

La ausencia de un backbone propietario no era solo una debilidad. Permitía a Prosimo utilizar infraestructura que las empresas ya habían contratado y beneficiarse de las inversiones de los proveedores. La empresa podía alcanzar regiones sin construir fibra y coordinar sistemas nativos como AWS Cloud WAN. La contrapartida era la dependencia de la estabilidad de las API, los límites de servicio, las condiciones comerciales y la semántica específica de los proveedores.

La reivindicación de la plataforma, por tanto, versaba sobre el control operativo, no sobre la propiedad física. Intentaba hacer que underlays heterogéneos funcionaran como un sistema gestionado, preservando sus ventajas nativas. Si esta abstracción reducía el vendor lock-in o simplemente lo desplazaba, dependía de la portabilidad de la política, la topología y la implantación de los edges.

Network Transit trataba la alcanzabilidad entre objetos de red

Network Transit se centraba en VPCs, VNets, subredes, regiones, sitios y segmentos. Coordinaba el tránsito nativo y los componentes de enrutamiento de las nubes para permitir que los equipos crearan conectividad mediante un flujo común, en lugar de configurar cada proveedor por separado. El producto atendía al requisito convencional de red: un prefijo o segmento de origen debe alcanzar un destino a través de un camino permitido.

Esto no significaba que las diferencias entre nubes desaparecieran. AWS, Azure y Google Cloud exponen objetos, límites y comportamientos de ruta diferentes. Espacios de direcciones superpuestos, caminos asimétricos, endpoints privados y límites de servicio específicos seguían exigiendo ingeniería. Prosimo podía normalizar operaciones comunes y mostrar relaciones, pero los sistemas subyacentes mantenían sus restricciones.

Network Transit también incorporaba la segmentación. Los dominios de ruta y las políticas podían separar entornos o limitar la alcanzabilidad. El controlador necesitaba entender dónde existía un segmento entre nubes y cómo los componentes nativos implementaban esa frontera. Una política expresada una sola vez podía generar múltiples cambios específicos del proveedor.

El beneficio era una superficie unificada de intención. El riesgo residía en la traducción. Si la política común y la configuración de la nube divergían, la empresa podía creer que un segmento estaba protegido cuando el estado del proveedor decía lo contrario. La reconciliación, la auditoría y el informe explícito de fallos eran, por ello, tan importantes como el flujo inicial de aprovisionamiento.

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

App Transit ampliaba el modelo más allá de las subredes. Podía usar el dominio de la aplicación, la identidad, el tipo de solicitud, la salud de la transacción, el riesgo y el rendimiento para decidir cómo un usuario o una carga de trabajo alcanzaría un servicio. Este fue el intento más claro de Prosimo de distinguir su plataforma de un enrutador de nube convencional.

La visión de la aplicación era útil porque los servicios modernos no siempre se representan de forma estable mediante direcciones fijas. Las plataformas gestionadas, los endpoints SaaS y los componentes distribuidos pueden cambiar mientras la identidad de la aplicación sigue siendo significativa. Una política que se refiere al servicio o al usuario puede ser más duradera que una regla escrita únicamente en torno a direcciones y puertos.

El modelo exigía un descubrimiento preciso. El controlador necesitaba saber qué dominios y endpoints pertenecían a una aplicación, qué dependencias eran necesarias y qué afirmaciones del proveedor de identidad eran fiables. Un mapeo desactualizado podía enviar la solicitud por el camino equivocado o aplicar la regla de seguridad incorrecta. La abstracción de la aplicación no eliminaba la necesidad de entender el estado de la red; añadía otra capa semántica por encima.

La combinación de Network Transit y App Transit reconocía que las empresas contienen ambos mundos. Los sistemas legacy, las subredes privadas y los controles basados en IP permanecen, mientras que las aplicaciones más nuevas dependen de dominios, identidad y servicios gestionados. Full-Stack Cloud Transit era el nombre del producto para operar esos modelos de forma conjunta, en lugar de forzar a uno a sustituir al otro.

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

El acceso consciente de las aplicaciones exigía la integración de la identidad. La plataforma podía utilizar el contexto de un usuario o una carga de trabajo para decidir si se establecía una conexión y cómo. Esto respaldaba una política de estilo de confianza cero, en la que la ubicación, por sí sola, no era prueba suficiente de autorización.

La identidad aumentaba la precisión, pero introducía otra dependencia. La política de ruta o de aplicación pasaba a depender del proveedor de identidad, de sus afirmaciones, del estado de la sesión y de los datos de grupo. Un camino de red podía fallar porque la autenticación no estuviera disponible o un atributo hubiera cambiado, incluso con enrutadores y edges en buen estado. La investigación debía atravesar la frontera entre las operaciones de red y de identidad.

El controlador también se convertía en un punto de concentración de contexto sensible. Podía mantener la topología, las relaciones entre aplicaciones, los atributos de usuario, las señales de riesgo y los resultados de política. Este conjunto de datos mejoraba el diagnóstico y la optimización, pero ampliaba las consecuencias de un acceso no autorizado. El privilegio mínimo, la retención, la auditoría y la separación de funciones eran requisitos arquitectónicos, no medidas administrativas posteriores.

El enfoque de Prosimo ilustra un cambio más amplio en la infraestructura. Las políticas de enrutamiento y acceso dependen cada vez más de la identidad y 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 creó el grafo del que dependían todas las decisiones posteriores

Un controlador entre nubes no puede gobernar lo que no ve. Prosimo desarrolló un descubrimiento y mapas de activos que representaban VPCs, VNets, subredes, aplicaciones, conectividad y relaciones de seguridad. Estas vistas respaldaban la incorporación, el diseño, la investigación de fallos y la política.

El descubrimiento era estratégicamente importante porque los entornos de nube cambian fuera de los flujos centrales de red. Los equipos de aplicaciones pueden crear cuentas, redes, endpoints y servicios gestionados mediante su propia automatización. Un diagrama mantenido manualmente se vuelve obsoleto. Un inventario basado en API puede proporcionar un grafo más actual, aunque su exhaustividad aún depende de las cuentas cubiertas, los permisos, la lógica de interpretación y las API de los proveedores.

El grafo no era solo documentación. Era la estructura de datos 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 sobre él podían ser erróneas. Por tanto, la topología necesitaba procedencia: cuándo se recopiló, qué cuenta la proporcionó, qué regiones estaban cubiertas y si alguna solicitud falló.

Este grafo también ayuda a explicar la adquisición. Palo Alto Networks puede crear valor de seguridad cuando sabe dónde están las cargas de trabajo y los caminos de tráfico. Un sistema que descubre activos en la nube y modifica rutas reduce la distancia entre comprar un firewall de software y posicionarlo correctamente. La declaración posterior de Bhau sobre la integración destacó específicamente el descubrimiento de activos y la implantación acelerada de firewalls de software.

AIR convirtió la telemetría de edge en recomendaciones operativas

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

Esta correlación atacaba un problema operativo conocido. Una transacción lenta puede deberse al camino del usuario, al edge, al backbone de la nube, a un servicio de seguridad o a la propia aplicación. Una visión entre capas puede reducir el campo de investigación más rápidamente que consolas separadas, y también respaldar recomendaciones sobre camino, posicionamiento, riesgo o coste.

La calidad de una recomendación dependía de la cobertura de la telemetría y del modelo utilizado para interpretarla. Un edge solo podía observar el tráfico que lo atravesaba. Las dependencias externas de la aplicación y las condiciones internas del proveedor podían permanecer invisibles. Una recomendación podía orientar el análisis sin demostrar por sí misma la causa raíz.

La telemetría también tenía valor de gobernanza. Las observaciones históricas podían ayudar a la empresa a explicar por qué cambió una ruta o una política. También podían exponer un uso sensible de las aplicaciones y el comportamiento de los usuarios. El material público no proporciona una descripción completa de la retención o la gobernanza de datos después de la adquisición, por lo que estos puntos siguen formando parte de la diligencia debida de los clientes.

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

El trabajo de Prosimo con AWS produjo las evidencias técnicas públicas más sólidas. La empresa se integró con AWS Transit Gateway, Cloud WAN, PrivateLink y el flujo de implantación del Marketplace for Containers Anywhere. AWS publicó una guía sobre el posicionamiento del AXI Edge, la incorporación de aplicaciones, la identidad, la seguridad y la optimización.

AWS Cloud WAN fue especialmente significativo. Proporcionaba un backbone y un servicio de segmentación nativos de la nube que Prosimo podía orquestar, no reemplazar. El acuerdo mostraba el modelo cooperativo del producto: AWS poseía la red nativa y la infraestructura global; Prosimo proporcionaba intención entre nubes, contexto de aplicación, software de edge y análisis.

El flujo del Marketplace simplificaba el primer paso de la implantación al empaquetar el AXI Edge a través de un canal aprobado. No eliminaba el trabajo posterior de permisos de cuenta, diseño de rutas, alta disponibilidad, capacidad y operaciones. La automatización del día cero puede reducir la fricción de instalación sin resolver el problema de control a largo plazo.

Una referencia nominal a Flexport respaldaba el caso de uso de AWS Cloud WAN en los materiales de la empresa. Demuestra que un cliente empresarial estaba dispuesto a respaldar la arquitectura, no una auditoría independiente de escala, economía o disponibilidad. Los testimonios de clientes deben utilizarse, por tanto, como ejemplos de adopción, no como evidencia universal de rendimiento.

Azure y Google Cloud completaban la afirmación multicloud

Prosimo también ofrecía soporte para entornos Microsoft Azure y Google Cloud. Sus materiales describían la orquestación en torno a Azure Virtual WAN y los componentes de red y servicios privados de Google Cloud. El objetivo era presentar un único modelo operativo, manteniendo la red nativa de cada proveedor.

La existencia de soporte no demuestra capacidades idénticas entre proveedores. Las API de nube maduran a ritmos diferentes, y nombres de productos comparables pueden ocultar semánticas distintas. Una ruta, un segmento, un endpoint privado o la inserción de un servicio pueden requerir un tratamiento específico. Las evidencias proporcionadas no reconstruyen una matriz de equivalencia función por función para cada región y versión.

Por tanto, la abstracción multicloud se entiende mejor como un sistema de traducción. Puede estandarizar la intención y los flujos de trabajo comunes, pero necesita preservar los detalles que afectan a la seguridad, el coste y los fallos. Una plataforma se vuelve peligrosa cuando la interfaz parece uniforme mientras las diferencias de implementación quedan ocultas para los operadores.

Lo mismo se aplica después de la adquisición. Palo Alto Networks puede utilizar el grafo común para posicionar la seguridad entre nubes, pero los proveedores siguen controlando los objetos nativos que implementan el camino. Poseer la capa de orquestación no significa poseer el underlay de la nube.

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

En 2023, Prosimo describía flujos para diseñar, construir, investigar y administrar redes multicloud. El producto había ido más allá del establecimiento de un túnel o un gateway. El descubrimiento de activos respaldaba el diseño; la orquestación creaba conectividad; los mapas y la telemetría ayudaban en la investigación; la política y el estado histórico sostenían la gestión continua.

Este marco de ciclo de vida ampliaba el grupo de compradores potenciales. Un ingeniero de red podía utilizar la topología y el análisis de caminos; un equipo de plataforma en la nube, integrar cuentas y servicios; un equipo de seguridad, revisar la segmentación y la inspección; un equipo de migración, planificar cambios; y el área de FinOps, examinar las implicaciones de ruta y de salida. El valor aumentaba cuando varios grupos utilizaban las mismas evidencias.

La evidencia compartida también puede crear conflictos de gobernanza. Una plataforma central puede revelar que la configuración nativa de un equipo de nube diverge de la política empresarial. La organización debe decidir qué sistema tiene autoridad y quién puede aprobar la corrección. El software, por sí solo, no resuelve esa cuestión institucional.

La narrativa del ciclo de vida también elevaba el coste de cambio. Cuando un controlador guarda el grafo de activos, las políticas, la telemetría, el posicionamiento de los edges y las integraciones de automatización, sustituirlo exige más que mover un circuito. El cliente necesita exportar o reconstruir el modelo operativo. Prosimo vendía una menor fragmentación de la nube, al mismo tiempo que creaba la posibilidad de dependencia del controlador.

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

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

El modelo en capas podía reducir la distancia entre una zona de red y una política de aplicación. Un servicio empresarial podría permitirse incluso cuando la alcanzabilidad amplia entre subredes permaneciera bloqueada. A la inversa, un camino de red alcanzable aún podría denegarse porque la identidad o el contexto de la aplicación fallaron.

Esto no convertía a Prosimo en un firewall de próxima generación completo. La integración de 2024 con Palo Alto Networks separaba responsabilidades: Prosimo orquestaba rutas, segmentación e inserción de servicios; el VM-Series realizaba la inspección profunda. La distinción importa porque el reenvío basado en políticas y la inspección de seguridad fallan de formas diferentes.

Un segmento solo es efectivo si todos los caminos relevantes están representados. Una ruta desconocida, una excepción nativa de la nube o una inserción de servicio fallida pueden eludir el control previsto. La validación exige comparar la política declarada con el estado del proveedor y el tráfico observado, en lugar de confiar únicamente en la pantalla de configuración del controlador.

La inserción de servicios vinculó el control de rutas a la economía de los firewalls

El diseño de seguridad en la nube necesita decidir dónde se producirá la inspección. Los firewalls centralizados pueden simplificar la política y reducir el número de appliances, pero pueden crear backhaul, concentración y presión de escala. Los firewalls distribuidos se sitúan cerca de las cargas de trabajo y reducen algunas distorsiones de camino, pero multiplican la implantación, el licenciamiento, la actualización y la operación de políticas.

Prosimo ofrecía ambos patrones en su integración con el VM-Series. La política podía encaminar tráfico seleccionado a través de un punto central de inspección o mediante firewalls distribuidos en las VPCs de las aplicaciones. El controlador actualizaba las rutas alrededor, mientras que Palo Alto Networks proporcionaba la función de inspección.

La arquitectura hizo que la orquestación de rutas fuera comercialmente valiosa para un proveedor de seguridad. Un firewall de software no protege el tráfico que nunca lo alcanza. El descubrimiento, el posicionamiento y la actualización de rutas reducen la fricción operativa entre comprar capacidad de seguridad e insertarla en un camino activo. Esta es una razón estratégica plausible para que Palo Alto Networks absorbiera la tecnología de Prosimo.

También amplía el radio de impacto del controlador. Una política incorrecta puede eludir la inspección, crear un bucle, producir enrutamiento asimétrico o tumbar una aplicación. Las comprobaciones de salud, los cambios por etapas, la simulación, la auditoría y el rollback son necesarios porque un fallo en la inserción de servicios es simultáneamente un evento de red y de seguridad.

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

Prosimo y Palo Alto Networks anunciaron la integración con el VM-Series el 12 de junio de 2024. El comunicado describía una solución técnica y comercial conjunta. No afirmaba que Palo Alto Networks hubiera adquirido Prosimo. Tratar el anuncio como prueba de propiedad haría que dos eventos distintos parecieran uno solo.

Aun así, la asociación creó un puente. Prosimo podía demostrar cómo su sistema de rutas y políticas facilitaba la implantación del VM-Series entre nubes. Palo Alto Networks podía evaluar la tecnología dentro de una integración real antes de la transición corporativa posterior. Las evidencias públicas no describen el proceso de adquisición, por lo que cualquier afirmación de que la asociación se diseñó como paso formal previo a la adquisición sería especulativa.

A principios de 2025, los historiales de fundadores y empleados habían cambiado. La página de la empresa pasó después a indicar adquisición. A finales de 2025, Bhau afirmó que la tecnología estaba totalmente integrada en los productos de Palo Alto Networks. En conjunto, estos registros respaldan la conclusión de la adquisición, manteniendo sin respuesta su mecánica jurídica.

Esta secuencia es importante para la precisión editorial y para los clientes. Una asociación significa dos proveedores, dos estructuras de soporte y una frontera de integración definida. Una adquisición puede transferir hojas de ruta, datos, contratos y autoridad a una sola empresa. La transición cambia más que la marca, incluso cuando el camino técnico parece inicialmente similar.

Nebula transformó el grafo de topología en una interfaz conversacional

Prosimo presentó Nebula en febrero de 2024 como parte de una AI Suite para redes multicloud. El asistente estaba diseñado para responder, en lenguaje natural, a preguntas sobre redes superpuestas, costes, salud de rutas, violaciones de políticas de seguridad y otras condiciones representadas en el grafo y la telemetría de la plataforma.

El activo útil no era la interfaz de lenguaje por sí misma, sino el contexto estructurado entre nubes que existía debajo. Un modelo general no puede diagnosticar una ruta privada o un segmento que no ve. Nebula podía recurrir al inventario de activos, la topología, las políticas y las observaciones que Prosimo ya recopilaba. Esto hizo que la inversión anterior en un grafo común fuera relevante para AIOps.

El acceso conversacional podía poner datos complejos a disposición de más operadores. También podía generar una confianza indebida si la respuesta omitía un activo no soportado, malinterpretaba 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 permiso y revisión humana.

Prosimo informó de posibles ganancias, como una reducción del 60% al 80% en el tiempo medio de resolución y una disminución superior al 60% en los costes de red en la nube. Estas cifras eran afirmaciones de la empresa en un anuncio de producto. Ninguna metodología independiente ni línea de base de clientes en las evidencias proporcionadas demuestra su aplicación general. Pueden citarse como un beneficio propuesto por Prosimo, no como un hecho de mercado medido.

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

El mismo anuncio de 2024 presentaba la arquitectura de Prosimo como útil para las cargas de trabajo de IA. Los sistemas distribuidos de IA pueden necesitar acceso privado a datos, conexiones entre nubes y centros de datos, controles de conformidad y un enrutamiento que refleje el comportamiento de la aplicación. Estos requisitos eran compatibles con el modelo ya existente de activos, políticas y caminos.

La etiqueta no cambiaba el underlay. Prosimo seguía dependiendo de redes en la nube, operadoras e infraestructura de los clientes. Tampoco proporcionaba computación GPU o software de desarrollo de modelos. Su papel potencial era la capa de conectividad y seguridad alrededor de los datos y servicios distribuidos.

El posicionamiento en IA era estratégicamente coherente, porque el valor de la topología entre nubes crece a medida que los datos y los servicios se distribuyen más. También era una categoría de marketing introducida poco antes de que la empresa dejara de operar de forma independiente. Las evidencias no establecen ingresos separados de productos de IA, implantaciones de producción identificadas o resultados auditados de cargas de trabajo.

El punto duradero es que la telemetría multicloud puede convertirse en entrada para operaciones asistidas por máquinas. La cuestión actual del producto es si Palo Alto Networks preservó ese contexto y cómo expone la capacidad. Las evidencias públicas disponibles en el corte de la investigación no proporcionan una respuesta completa.

El modelo comercial dependía de infraestructura de terceros

El negocio independiente de Prosimo seguía un modelo de software por suscripción y servicios, no un modelo de operadora. Los clientes implantaban AXI Edges en sus entornos y conectaban cuentas de nube a la capa de control. Los ingresos probablemente procedían de licencias o suscripciones, soporte, servicios profesionales y canales, aunque los precios exactos y las métricas contractuales no aparecen en las evidencias proporcionadas.

El modelo podía crecer sin poseer fibra. Una plataforma de software podía coordinar muchas regiones y entornos de clientes. Sin embargo, la economía bruta no puede inferirse de esta arquitectura. El soporte de ingeniería a las API de los proveedores, el ciclo de vida de los edges, las integraciones de seguridad y las implantaciones empresariales pueden ser costosos, mientras que los recursos de nube consumidos por los edges pueden ser pagados por el cliente, no por el proveedor.

Prosimo utilizaba marketplaces de nube, socios de integración, organizaciones de canal y referencias nominales de clientes para llegar a las empresas. Estas relaciones no son equivalentes. Una inclusión en el marketplace demuestra un camino de adquisición e implantación. Una integración técnica demuestra que dos sistemas pueden combinarse en condiciones definidas. Un testimonio de cliente ofrece una referencia. Ninguno de estos elementos, por sí solo, establece el número de clientes de pago o los ingresos recurrentes.

La amplitud de la empresa pudo haber aumentado la complejidad de ventas. Los equipos de red, seguridad, nube y aplicaciones podían beneficiarse, pero la responsabilidad presupuestaria podía ser incierta. El producto necesitaba un comprador dispuesto a financiar una capa común de control en lugar de permitir que cada nube y cada equipo operaran por separado.

Socios, clientes e inversores ocupaban posiciones diferentes

Amazon Web Services era simultáneamente proveedor de underlay y socio de integración comercial. Azure y Google Cloud eran entornos soportados. Los proveedores de identidad proporcionaban contexto de autenticación. Los proveedores de firewall entregaban inspección. Los servicios de coubicación y las operadoras podían alojar o conectar edges. Los socios de canal podían diseñar y operar implantaciones.

Flexport apareció como referencia nominal de cliente en el material de AWS Cloud WAN. La referencia demuestra interés empresarial en la arquitectura, pero no revela el alcance completo, la duración o el valor comercial de la implantación. No debe convertirse en representante de toda la base de clientes.

General Catalyst lideró la Serie A y participó en la gobernanza a través de su implicación como inversor. Inversores vinculados a WRVI o a Celesta aparecieron en materiales de la empresa, y comunicaciones posteriores de Prosimo citaron a otros participantes destacados, incluido un nombre asociado a BlackRock cuyo vehículo exacto no fue aclarado por la investigación. Estos registros respaldan una base financiera bien conectada, no un cuadro completo de capitalización.

Palo Alto Networks ocupaba la relación más importante. Pasó de 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 el camino hacia su producto.

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

El historial de financiación verificado consiste en una Serie A de 25 millones de dólares en abril de 2021 y una Serie B de 30 millones de dólares en 2022. El total es de al menos 55 millones de dólares. Las evidencias proporcionadas no incluyen una tabla de capitalización auditada, valoración, estructura de deuda ni una ronda posterior.

El precio pagado en la adquisición no fue divulgado ni verificado de forma independiente. Sin precio, no es responsable clasificar el resultado como prima estratégica, compra modesta de tecnología, acqui-hire o venta en dificultades. La continuidad de la integración demuestra valor tecnológico; no revela el retorno obtenido por inversores o fundadores.

Los ingresos y la escala de mercado de Palo Alto Networks no deben atribuirse a Prosimo después de la adquisición. Cuando la startup dejó de ser observable por separado, no había ingresos, beneficios ni segmento de clientes autónomo que analizar. Un propietario mayor puede hacer que la tecnología esté más ampliamente disponible y, al mismo tiempo, hacer que su economía individual sea menos visible.

La ausencia de un anuncio formal de la adquisición es relevante por sí misma. Los clientes, empleados e investigadores suelen utilizar estos comunicados para determinar la cronología, 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 de la empresa y una declaración posterior del fundador. Es suficiente para corregir la condición de la empresa, pero insuficiente para inventar detalles de la transacción.

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

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

Un controlador especializado podía ofrecer una topología y un modelo de políticas entre proveedores. Un diseño nativo de nube podía reducir la dependencia de terceros y ajustarse estrechamente a un proveedor. Un servicio respaldado por una operadora podía proporcionar transporte físico. Una plataforma SASE o de seguridad podía combinar conectividad y ejecución de políticas. La ingeniería interna podía preservar el control a costa de personal e integración.

La diferenciación de Prosimo era la combinación de tránsito de aplicaciones y redes, edges distribuidos, orquestación nativa de nube, topología, telemetría e inserción de servicios. La misma amplitud dificultaba la comparación. Los compradores necesitaban probar los servicios de nube, las rutas, los sistemas de identidad y los patrones de seguridad que realmente pretendían utilizar, en lugar de comparar etiquetas de categoría.

La adquisición cambia el panorama competitivo. Prosimo ya no necesita ganar como empresa autónoma, pero su tecnología debe justificarse dentro de Palo Alto Networks. La comparación relevante pasa a ser si el descubrimiento y la orquestación integrados mejoran la implantación de los productos de seguridad de Palo Alto y si los clientes aceptan la dependencia resultante de la plataforma.

Los servicios nativos de nube eran fundamento y sustituto

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN y los servicios de red de Google Cloud daban a las empresas opciones nativas poderosas. Prosimo dependía de estos servicios y competía con la posibilidad de que los clientes los operaran directamente.

Esta relación creaba una frontera móvil. A medida que un proveedor añadía enrutamiento global, segmentación, acceso privado a servicios o política central, algunas funciones de terceros se volvían más fáciles de reproducir de forma nativa. Al mismo tiempo, cada nuevo servicio nativo añadía otro objeto que un controlador multicloud podía descubrir y coordinar. El progreso de la nube podía reducir una parte del valor de Prosimo y ampliar la necesidad de traducción entre proveedores.

El factor decisivo era tanto organizativo como técnico. Una empresa concentrada en una única nube y con una gran capacidad de ingeniería interna podía preferir herramientas nativas. Una organización multicloud con equipos fragmentados podía valorar un único plano de control. Una institución regulada podía preferir una capa de evidencia independiente, pero preocuparse por las credenciales privilegiadas y la concentración de datos.

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

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

La arquitectura distribuida de Prosimo reducía la dependencia de un único hub de tráfico, pero creaba varios dominios de fallo interconectados. El servicio central podía no estar disponible o mantener una intención obsoleta. Un edge podía fallar o quedar aislado. Una API de nube podía rechazar parte de un cambio. El proveedor de identidad podía detenerse. El underlay podía perder capacidad o seguir una ruta inesperada. Un firewall insertado podía agotar los recursos.

El fallo parcial es especialmente difícil. Un proveedor puede aceptar una actualización de ruta mientras que otro la rechaza. El estado pretendido por el controlador puede entonces divergir del estado real de la nube. El tráfico puede seguir un camino asimétrico o eludir la inspección. Un sistema fiable necesita reconciliación, operaciones idempotentes, cambios graduales, un estado de error explícito y un rollback que considere el comportamiento de cada proveedor.

Las evidencias públicas describen disponibilidad y optimización a alto nivel, pero no incluyen un estudio independiente de inyección de fallos, un historial completo de incidentes o resultados universales de nivel de servicio. Las afirmaciones de resiliencia deben permanecer vinculadas a la arquitectura documentada o a evidencias de clientes identificados.

La adquisición introduce otro dominio de fallo: la continuidad del producto. Los clientes necesitan saber qué consola, API, imagen de edge, modelo de política y organización de soporte sustituye al sistema histórico de Prosimo. Una integración de código técnicamente exitosa aún puede crear riesgo de migración cuando las fronteras comerciales y operativas permanecen oscuras.

Las credenciales de nube situaron al controlador en el plano crítico de gestión

El descubrimiento de activos y la orquestación exigían acceso a las cuentas de nube. El inventario de solo lectura podía utilizar privilegios limitados, mientras que los cambios de rutas, segmentos e inserciones de servicio necesitaban una autoridad mayor. Por tanto, el controlador se situaba dentro del plano de gestión privilegiado, incluso sin poseer las cargas de trabajo.

El compromiso de las credenciales podía exponer la topología o permitir cambios amplios. Un defecto de software o un error operativo podía propagar políticas entre múltiples nubes. El riesgo crecía con la utilidad de la plataforma: cuantas más cuentas y servicios gobernara, mayor era el radio de impacto potencial.

Las empresas necesitaban roles de privilegio mínimo, credenciales separadas para el descubrimiento y el cambio, aprobación por varias partes, auditoría completa, rotación, revocación de emergencia y una ruta de recuperación que no dependiera únicamente del mismo controlador. El material público proporcionado no presenta una evaluación de seguridad independiente completa, por lo que estos elementos siguen siendo controles de implantación necesarios, no garantías verificadas del producto.

El grafo de telemetría era igualmente sensible. Podía revelar nombres de aplicaciones, estructura de red, políticas, relaciones de usuarios, salud de rutas y patrones de coste. La gobernanza posterior a la adquisición debería aclarar dónde se almacenan estos datos, qué productos de Palo Alto Networks pueden utilizarlos y cómo se migraron los permisos de los antiguos clientes. Las evidencias públicas en el corte de la investigación no responden a estas preguntas.

La adquisición llevó una capa de control antes neutral a una plataforma de seguridad

La posición independiente permitía a Prosimo presentarse como una capa común entre nubes y servicios de seguridad. Cuando Palo Alto Networks se convirtió en propietaria, los incentivos cambiaron. La tecnología adquirida podía facilitar la implantación del VM-Series y de otros productos de Palo Alto. Esto puede ofrecer una mejor integración, al mismo tiempo que suscita dudas sobre el soporte a servicios de inspección de terceros.

La propiedad no demuestra que la neutralidad haya desaparecido. Las evidencias no aportan una matriz actual de socios ni la arquitectura contemporánea del producto. Sin embargo, la pregunta del cliente cambia. Es necesario saber si el controlador de enrutamiento sigue abierto a varios proveedores de seguridad, si las políticas y la telemetría pueden exportarse y si la optimización favorece la cartera del propietario.

La declaración de integración enfatizó la inspección de entrada, salida y este-oeste. Este enfoque sugiere que la topología y la orquestación de Prosimo pasaron a formar parte de un sistema de implantación de seguridad. No demuestra que App Transit, el acceso de usuarios, la optimización de costes o todo el flujo histórico de redes en la nube sobrevivieran como capacidades separadas.

Este es un patrón común en infraestructura. Una startup abstrae un problema difícil de coordinación; una plataforma mayor compra la abstracción porque aumenta el consumo y el control de su producto principal. El comprador gana una ruta hacia la implantación. El cliente puede ganar integración y perder algo de independencia de proveedor.

El mapa actual de productos es la principal laguna de información

Los registros públicos confirman la adquisición y la integración, pero no identifican un mapeo completo de AXI, Network Transit, App Transit, AIR y Nebula a los productos o SKU actuales de Palo Alto Networks. Tampoco publican plazos de soporte heredado, procedimientos de migración ni una tabla de continuidad funcional.

Esta laguna impide una evaluación actual del producto. Las descripciones históricas explican lo que Prosimo construyó y por qué importaba. No informan sobre qué capacidades están disponibles, licenciadas o soportadas hoy. Las recomendaciones contemporáneas de implantación deben basarse en la documentación actual de Palo Alto Networks, no en los comunicados archivados de Prosimo.

La ausencia del mapa también limita el análisis estratégico. La absorción completa del grafo y la capa de orquestación sería diferente del uso selectivo del descubrimiento de activos y el posicionamiento de firewalls. Un resultado crearía un amplio servicio de control multicloud; el otro utilizaría Prosimo principalmente para acelerar la implantación de seguridad. La declaración del cofundador respalda la continuidad tecnológica, pero deja sin respuesta esta frontera arquitectónica.

Un futuro documento de producto, una guía de migración o un estudio de caso de cliente podría resolver buena parte de la incertidumbre. Hasta entonces, la formulación precisa es que, según un cofundador, la tecnología de Prosimo se integró en los productos de Palo Alto Networks, mientras que el alcance y el empaquetado no han sido verificados.

¿Quién controla el enrutamiento multicloud?

Ninguna parte controla el camino entero. La empresa controla la propiedad de las cuentas, la intención de negocio, el diseño de la aplicación y las credenciales que otorga. Un controlador entre nubes puede descubrir la topología, traducir políticas, elegir caminos y modificar el estado de las rutas nativas. Los proveedores controlan sus API, servicios de tránsito, endpoints privados, backbone y muchos dominios de fallo. Las operadoras y las empresas de coubicación controlan otras partes del transporte. Los servicios de seguridad controlan si se permite el tráfico inspeccionado.

Prosimo aspiraba a la posición intermedia más útil estratégicamente. No poseía el underlay, pero intentaba poseer el grafo y la traducción de políticas por encima de él. Quien controla esa capa puede decidir qué activos son visibles, cómo se representan los segmentos, dónde se colocan los edges, qué servicio inspecciona el tráfico y qué telemetría se considera autoritativa. Esto supone un poder práctico sobre el enrutamiento, incluso cuando la fibra pertenece a otra organización.

Después de la adquisición, Palo Alto Networks es propietaria de la tecnología remanente de Prosimo y determina cómo se integra, empaqueta y desarrolla. Los proveedores siguen siendo soberanos dentro de sus entornos, y la empresa puede revocar credenciales o elegir otra arquitectura. Sin embargo, la salida puede ser costosa si la topología, las políticas y los flujos operativos se han vuelto dependientes del controlador.

La respuesta, por tanto, está distribuida por capas, no es absoluta: la empresa autoriza; el controlador coordina; los underlays de nube y de operadora transportan; la plataforma de seguridad aplica. La historia de Prosimo importa porque muestra que la propiedad de la capa de coordinación puede cambiar sin que una cuenta de nube o una ruta física cambien de manos.

Registro principal de fuentes

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

Prosimo captó un cambio real en la infraestructura. La unidad de gestión de red está migrando del dispositivo y el 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 distribuidos hacen móvil el punto de aplicación. Un controlador que ve múltiples nubes puede coordinar acciones que ninguna consola individual puede completar por sí sola.

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

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

Prosimo no debe ser recordada ni como una marca autónoma fracasada ni como la prueba de que una plataforma resolvió el multicloud. Su contribución duradera fue definir el grafo entre nubes como infraestructura. La pregunta pendiente es si ese grafo, ahora dentro de una compañía de seguridad mayor, sigue siendo transparente, portable y gobernable en la medida suficiente para merecer la confianza de los clientes.