Resumen

  • Prosimo se fundó en 2019 y recaudó al menos 55 millones de dólares mediante una ronda Serie A en 2021 y una Serie B en 2022; no se han revelado ingresos auditados, valoración ni precio de adquisición.
  • AXI utiliza una capa central de intención, topología y análisis junto con bordes distribuidos para descubrir activos en la nube, conectar aplicaciones, insertar servicios de seguridad y recopilar telemetría, pero no posee una red troncal física.
  • La integración de VM-Series anunciada en junio de 2024 precedió a la incorporación de Prosimo a Palo Alto Networks alrededor de febrero de 2025; la información pública no ofrece fechas exactas, precio ni el mapeo actual de productos.
  • El control sigue repartido entre las empresas, el software de orquestación, los proveedores de nube y Palo Alto Networks; la posibilidad de migrar la topología, las credenciales, las políticas y los permisos de enrutamiento es la prueba más importante para los clientes.

La empresa desapareció, pero no las preguntas

Describir a Prosimo como un proveedor que sigue operando de forma independiente en 2026 no es exacto. Los historiales profesionales públicos muestran que su fundador y varios empleados pasaron a Palo Alto Networks en torno a febrero de 2025. La página corporativa de Prosimo aparece como adquirida y el ex director de tecnología, Nehal Bhau, declaró posteriormente que la tecnología se había integrado en los productos de Palo Alto Networks. Estas pruebas confirman un cambio de control y que la tecnología conserva valor; sin embargo, no permiten determinar la fecha del acuerdo, la de cierre, la forma jurídica ni el precio de la transacción.

Este hecho debe señalarse al principio, porque determina el tiempo verbal de todas las descripciones de producto. AXI, Network Transit, App Transit, Application-driven Intelligent Results y Nebula son capacidades bien documentadas de la etapa independiente de Prosimo. No se debe escribir sobre ellas como productos actuales que se venden por separado bajo la marca Prosimo hasta que Palo Alto Networks publique el mapeo de productos y el soporte actuales. Tras la adquisición, la arquitectura histórica puede perdurar como código embebido, servicios compartidos, módulos de producto o activos internos de ingeniería, formas que no son equivalentes.

La desaparición de la marca no significa que los problemas subyacentes hayan caducado. Las empresas siguen distribuyendo cargas de trabajo entre Amazon Web Services, Microsoft Azure, Google Cloud, centros de datos privados, instalaciones de co-ubicación, plataformas SaaS y usuarios remotos. Cada entorno tiene sus propias reglas de enrutamiento, puertas de enlace, puntos de conexión privados, controles de identidad, servicios de seguridad, cuotas y modelos de facturación. Incluso cuando la empresa es titular de todas las cuentas, no siempre dispone de una visión unificada de cómo fluyen las solicitudes entre esos entornos.

La importancia de Prosimo radica precisamente en que intentó proporcionar esa visión.

Por lo tanto, la adquisición no es una nota al pie, sino el hilo conductor de todo el artículo. Prosimo construyó una capa de control multicloud capaz de descubrir activos, interpretar el contexto de las aplicaciones y dirigir el tráfico hacia servicios de seguridad. Palo Alto Networks apareció primero como socio tecnológico, con sus firewalls VM-Series insertables en esas rutas; después se convirtió en el propietario de la tecnología. La frontera que antes separaba la orquestación del enrutamiento de la inspección profunda se desplazó al interior de una única plataforma de ciberseguridad.

Lo que está en juego en el enrutamiento multicloud es el contexto

Una tabla de enrutamiento puede indicar si un prefijo es accesible a través de un siguiente salto, pero no puede decir por sí sola a qué aplicación quiere acceder el usuario, si el solicitante es de confianza, si el tráfico debe ser inspeccionado, si hay un punto de conexión privado disponible, si una ruta en la nube es más costosa, o por qué una transacción falla después de que el paquete haya llegado. La operación multicloud convierte estas cuestiones en un problema de control compartido.

El planteamiento de Prosimo fue que el control del enrutamiento no puede basarse únicamente en la accesibilidad de capa 3. Trató de combinar el inventario de activos en la nube, el estado de la red, la identidad de las aplicaciones, la identidad de los usuarios, el riesgo, el rendimiento y la telemetría de las transacciones. Ese contexto permite aplicar políticas más específicas: conectar una aplicación, aislar un segmento, elegir un punto de entrada o hacer que un tráfico determinado pase por un firewall. El valor no residía en crear una nueva ruta de fibra, sino en decidir cómo combinar las rutas y los servicios existentes.

Esto explica también por qué Prosimo utilizaba la expresión “infraestructura de experiencia de aplicación” (application experience infrastructure). La solicitud de aplicación se sitúa por encima de los objetos de red individuales; la VPC, la VNet, la subred, el concentrador de tránsito o el enlace privado son solo componentes de una ruta de extremo a extremo, no el objetivo final de la gestión. Este enfoque sitúa el producto simultáneamente en varios mercados: redes en la nube, entrega de aplicaciones, acceso de confianza cero, aseguramiento de la red, optimización de costes e inserción de servicios de seguridad.

Esta amplitud funcional genera oportunidades, pero también ambigüedad. Una plataforma que abarque varios equipos puede resolver fallos de coordinación de los que ningún equipo se responsabiliza en solitario, pero también es más difícil de evaluar, porque los equipos de redes, seguridad, nube, aplicaciones y finanzas utilizan criterios de éxito diferentes. Prosimo tenía que demostrar que un modelo unificado mejora las operaciones, sin convertirse en una capa centralizada más que, con altos privilegios, pueda afectar a todos los entornos si comete un único error.

Qué era Prosimo y qué queda hoy

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. Durante su etapa independiente, Ramesh Prabagaran fue cofundador y consejero delegado, y Nehal Bhau, cofundador y director de tecnología. Los historiales públicos también vinculan a Linus Aranha y Pradeep Aragonda con las labores fundacionales o de ingeniería sénior, pero sus cargos exactos deben verificarse en los perfiles correspondientes a cada fecha.

La plataforma principal de la empresa era Application eXperience Infrastructure, abreviada como AXI. AXI gestionaba la intención, la topología, el análisis y la orquestación a través de una capa de software central, y desplegaba bordes AXI distribuidos en las regiones de nube, en las instalaciones de co-ubicación o en infraestructuras locales cercanas. Posteriormente, la empresa reorganizó su oferta bajo el nombre Full-Stack Cloud Transit, con Network Transit y App Transit para distintas categorías de conectividad. AIR analizaba la telemetría y generaba información operativa; Nebula añadió interacción en lenguaje natural en 2024.

Prosimo no era un operador de nube ni poseía una red troncal global de fibra que conectara todas las regiones. Las rutas podían atravesar las redes troncales de los proveedores de nube, la Internet pública, Direct Connect o ExpressRoute, enlaces de co-ubicación, circuitos de operadores y redes empresariales. Tampoco era un fabricante de firewalls equiparable a Palo Alto Networks. En la integración de 2024, Prosimo se encargaba del descubrimiento, la segmentación y la conducción del tráfico, mientras que VM-Series realizaba la inspección de seguridad profunda.

Tras la adquisición, la denominación más prudente es “herencia tecnológica”. Las declaraciones posteriores sobre la integración destacan el descubrimiento de activos multicloud y la agilización del despliegue de firewalls de software para el tráfico de entrada, salida y este-oeste. Esto demuestra que componentes importantes de Prosimo sobreviven, pero no que el catálogo completo de productos AXI, el empaquetado comercial y el modelo de soporte hayan continuado tal cual.

El nuevo rompecabezas posterior a SD-WAN

El equipo fundador poseía una amplia experiencia en redes a gran escala, entrega de aplicaciones e infraestructura en la nube. Prosimo también procedía del ecosistema más amplio de fundadores e ingenieros vinculados a Viptela, empresa que contribuyó a consolidar SD-WAN como una categoría definida en el mercado empresarial. Pero el siguiente desafío era diferente. SD-WAN puede simplificar la relación entre las sucursales y la red o las aplicaciones, pero no crea automáticamente un modelo operativo unificado que abarque varias nubes públicas.

Una aplicación multicloud puede depender de un punto de conexión web en un entorno, de una base de datos o un servicio gestionado en otro, de un proveedor de identidad externo a ambos, de enlaces privados hacia los centros de datos y de inspecciones de seguridad desplegadas en perímetros concretos. Cada dependencia puede materializarse en objetos nativos de nube diferentes. El equipo de redes ve prefijos y concentradores de tránsito; el de nube, cuentas y recursos; el responsable de aplicaciones, nombres de dominio y transacciones; el de seguridad, zonas y políticas de inspección.

Prosimo partía de las solicitudes, no de las sucursales. La cuestión real era: ¿cómo deben acceder los usuarios o las cargas de trabajo a las aplicaciones con niveles aceptables de seguridad, rendimiento, disponibilidad y coste? Así, el objeto de enrutamiento dejaba de ser simplemente un prefijo de destino para convertirse en una transacción que incorpora identidad y contexto de aplicación. La plataforma también debía recopilar y mantener mucha más información que un enrutador tradicional.

El momento del mercado también era favorable. AWS, Azure y Google Cloud estaban ampliando sus servicios nativos de tránsito y conectividad privada. Las empresas podían construir redes complejas dentro de una sola nube, pero las API, los objetos y los modelos de políticas seguían siendo diferentes. La oportunidad de Prosimo no era sustituir esas capacidades con una red troncal privada, sino orquestar los servicios nativos de cada nube.

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

Prosimo se fundó en 2019, pero no se presentó oficialmente hasta el 6 de abril de 2021. General Catalyst lideró en ese momento una ronda Serie A de 25 millones de dólares. El inversor describió la oportunidad como la entrega de experiencia de aplicación a través de múltiples nubes, en línea con el objetivo del equipo fundador de superar la conectividad de sucursales tradicional y crear una nueva categoría.

El mercado en el momento del lanzamiento era a la vez saturado y aún no definido. Los proveedores de nube estaban facilitando el uso de sus servicios de red; los proveedores de SD-WAN y SASE extendían sus políticas hacia la nube; los de entrega de aplicaciones podían optimizar las solicitudes; los de seguridad podían inspeccionar el tráfico. Prosimo tenía que demostrar que esas capacidades podían funcionar juntas dentro de una arquitectura orientada a la nube, sin pretender sustituir todos los sistemas existentes.

La financiación permitió a la empresa desarrollar integraciones, bordes de software, sistemas de análisis, equipos comerciales y canales de colaboración. Pero la financiación por sí sola no demuestra el encaje producto-mercado, la escala de ingresos ni una diferenciación duradera. Los materiales disponibles no ofrecen ingresos auditados, ingresos recurrentes anuales, número total de clientes ni valoración. Los registros de financiación acreditan el compromiso de los inversores con una tesis de mercado, no un historial operativo completo.

En 2022, Prosimo cerró una ronda Serie B de 30 millones de dólares que se calificó como sobresuscrita. Sumando las dos rondas claramente identificadas, el total verificado asciende al menos a 55 millones de dólares. Algunas bases de datos pueden mostrar cifras más altas debido a registros duplicados de anuncios o entradas relacionadas; esos datos no deben utilizarse sin depurar los eventos subyacentes.

AXI colocaba las políticas por encima de la nube 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 bordes de software distribuidos. La capa central albergaba la intención de aplicación y de red, descubría activos, ensamblaba la topología, integraba la identidad, analizaba la telemetría y orquestaba los cambios. Los bordes AXI se desplegaban cerca de las cargas de trabajo o de los usuarios, para que la política no dependiera de un centro físico distante para su aplicación.

Esta separación se asemeja a la de otros sistemas definidos por software, pero maneja objetos nativos de la nube y con semántica de aplicación. El controlador necesita acceso a las cuentas y API de la nube; los bordes necesitan acceso a los servicios de tránsito nativos, a las redes de cargas de trabajo, a los puntos de conexión privados o a las rutas externas. La potencia de la plataforma deriva de la combinación de dos vistas: la intención global por encima de la nube y la ejecución local cerca del tráfico.

La arquitectura también impone limitaciones de despliegue concretas. Cada borde consume recursos de nube, requiere un diseño de alta disponibilidad y debe ser actualizado, supervisado y protegido. La capa de control necesita privilegios suficientes para descubrir activos y modificar el estado de la red. La empresa obtiene flujos de trabajo unificados, pero añade un sistema de gestión cuya disponibilidad y corrección afectan a la accesibilidad en producción.

Prosimo utilizó a veces la expresión “red autónoma en la nube” (autonomous cloud network). Las pruebas respaldan la automatización, las recomendaciones y la orquestación basada en API, pero no una red que funcione de forma independiente sin intervención humana, servicios de nube ni transporte subyacente. Los operadores siguen teniendo que definir la intención, aprobar el acceso, gestionar las excepciones y asumir la responsabilidad de los resultados.

El borde AXI es una elección de ubicación, no un dispositivo virtual genérico

El borde AXI podía desplegarse en una VPC o VNet de nube, en un entorno de co-ubicación o en infraestructuras cercanas. La documentación técnica de AWS mostraba una VPC de borde conectada a las VPC de cargas de trabajo a través de Transit Gateway, con la opción de encadenar un firewall y, al mismo tiempo, dar acceso a sitios locales o usuarios remotos. El punto de aplicación se situaba dentro de la topología de nube, no en un perímetro empresarial distante.

La ubicación no solo afecta a la latencia: determina dónde entra el tráfico en el dominio de la política, qué segmento de la red troncal de la nube o de Internet se utiliza, dónde se producen el cifrado y la inspección, y qué telemetría puede ver la plataforma. Una ubicación incorrecta puede provocar desvíos o costes adicionales; una ubicación acertada puede acortar las rutas y mantener el tráfico cerca de las cargas de trabajo.

El despliegue distribuido aumenta los dominios de fallo. La capacidad, la versión del software, el diseño de zonas de disponibilidad, la convergencia del enrutamiento y los permisos de acceso pueden variar entre regiones. La alta disponibilidad no consiste solo en ejecutar dos instancias: el controlador, las tablas de enrutamiento de la nube, los servicios de seguridad y las rutas de retorno también deben tener una visión coherente del estado de la conmutación por error.

Por consiguiente, el borde forma parte de un sistema operativo mayor. Su valor depende de que el descubrimiento de activos, la topología, las políticas y el análisis estén alineados con el entorno de nube circundante. Verlo como un dispositivo virtual aislado supone ignorar la arquitectura que realmente vendía Prosimo.

El transporte subyacente siempre perteneció a otros actores

Prosimo orquestaba el transporte, pero no poseía las rutas físicas. El tráfico de las aplicaciones podía utilizar las redes troncales de AWS u otros proveedores de nube, la Internet pública, Direct Connect, ExpressRoute, conexiones de co-ubicación, circuitos de operadores o la propia red de la empresa. La plataforma podía elegir y orquestar entre las opciones disponibles, pero no podía eliminar la latencia, la pérdida de paquetes, los dominios de fallo ni las reglas de facturación que imponen esos proveedores.

Este límite es fundamental para entender las promesas de rendimiento. El controlador puede seleccionar la ruta que observa como mejor o colocar el punto de entrada más cerca del usuario, pero no puede garantizar que un operador no falle, que una región de nube no sufra una interrupción o que las dependencias externas respondan siempre con rapidez. La experiencia de la aplicación también se ve afectada por el DNS, el procesamiento del servidor, el almacenamiento, el comportamiento del navegador y los servicios de terceros, factores que escapan al control total de un controlador de red.

No poseer una red troncal privada no es solo una debilidad. Prosimo podía aprovechar la infraestructura que la empresa ya había adquirido y beneficiarse de las inversiones de los proveedores de nube; podía llegar a más regiones sin tender fibra y podía orquestar sistemas nativos como AWS Cloud WAN. El coste era la dependencia de la estabilidad de las API, las cuotas de servicio, las condiciones comerciales y la semántica específica de cada proveedor.

Por lo tanto, la propuesta de Prosimo era el control operativo, no la propiedad física. Trataba de hacer funcionar una infraestructura de transporte heterogénea bajo un modelo de gestión unificado, respetando las ventajas nativas de cada una. Que esta abstracción reduzca la dependencia de un proveedor o la traslade al controlador depende de que las políticas, la topología y los despliegues de borde sean portables.

Network Transit gestionaba la accesibilidad entre objetos de red

Network Transit se dirigía a VPC, VNet, subredes, regiones, sitios y segmentos. Orquestaba los concentradores de tránsito nativos de la nube y los objetos de enrutamiento, para que los equipos pudieran establecer conectividad mediante flujos de trabajo unificados en lugar de operar nube por nube. Resolvía la necesidad clásica de redes: que un origen o segmento determinado pueda alcanzar su destino a través de una ruta permitida.

Esto no significa que desaparezcan las diferencias entre nubes. AWS, Azure y Google Cloud exponen objetos, cuotas y comportamientos de enrutamiento distintos. Los solapamientos de direcciones, las rutas asimétricas, los puntos de conexión privados y las limitaciones de los servicios de los proveedores siguen requiriendo trabajo de ingeniería. Prosimo podía normalizar las operaciones más comunes y mostrar las relaciones, pero los sistemas subyacentes conservaban sus propias restricciones.

Network Transit también se encargaba de la segmentación. Los dominios de enrutamiento y las políticas podían aislar entornos o restringir la accesibilidad. El controlador necesitaba entender cómo existe un segmento en varias nubes y cómo los objetos nativos aplican esa frontera. Una política unificada podía traducirse en múltiples conjuntos de cambios específicos de cada proveedor.

La interfaz de intención unificada es una ventaja; la traducción, un riesgo. Si la política común diverge del estado real de la nube, la empresa puede creer que un segmento está protegido cuando en realidad no lo está. La reconciliación, la auditoría y la definición clara de los estados de fallo son tan importantes como la configuración inicial.

App Transit convierte la propia aplicación en objeto de enrutamiento

App Transit ampliaba el modelo de las subredes a las aplicaciones. Podía decidir cómo debían acceder los usuarios o las cargas de trabajo a un servicio en función del nombre de dominio de la aplicación, la identidad, el tipo de solicitud, el estado de la transacción, el riesgo y el rendimiento. Esta es una de las diferencias más claras entre Prosimo y un enrutador de nube tradicional.

La perspectiva de aplicación es valiosa porque los servicios modernos no siempre corresponden a direcciones estables. Las plataformas gestionadas, los puntos de conexión SaaS y los componentes distribuidos cambian, pero la identidad de la aplicación sigue teniendo sentido. Una política orientada al servicio o al usuario puede ser más duradera que una regla basada únicamente en direcciones y puertos.

Este modelo depende de un descubrimiento preciso. El controlador debe saber qué nombres de dominio y puntos de conexión pertenecen a una aplicación, qué dependencias son imprescindibles y qué afirmaciones del proveedor de identidad son fiables. Un mapeo desactualizado puede hacer que las solicitudes sigan rutas incorrectas o reciban políticas equivocadas. La abstracción de aplicación no elimina la necesidad de entender el estado de la red, solo añade una capa semántica por encima.

La combinación de Network Transit y App Transit reconocía que en las empresas conviven dos tipos de sistemas: las cargas de trabajo IP tradicionales y las subredes privadas siguen existiendo, mientras que las nuevas aplicaciones dependen de nombres de dominio, identidades y servicios gestionados. El sentido de Full-Stack Cloud Transit era situar ambos modelos en un mismo marco operativo, sin obligar a que uno sustituyera al otro.

La identidad amplía la decisión de enrutamiento y también el perímetro de confianza

El acceso consciente de la aplicación exige integración con la identidad. La plataforma podía decidir si establecer una conexión y qué ruta utilizar en función del contexto del usuario o de la carga de trabajo. Esto permite aplicar una política de tipo confianza cero: la ubicación por sí sola no basta para conceder el acceso.

La identidad mejora la precisión de las políticas, pero introduce nuevas dependencias. Las políticas de enrutamiento o de aplicación pasan a depender del proveedor de identidad, de sus afirmaciones, del estado de la sesión y de los datos de grupo. Incluso si los enrutadores y los bordes funcionan correctamente, la indisponibilidad del servicio de autenticación o un cambio de atributos puede provocar fallos en la ruta. La resolución de problemas debe abarcar tanto las operaciones de red como las de identidad.

El controlador también centraliza un contexto sensible: puede almacenar topología, relaciones de aplicaciones, atributos de usuario, señales de riesgo y resultados de políticas. Estos datos facilitan el diagnóstico y la optimización, pero también agravan las consecuencias de un acceso no autorizado. El principio de privilegio mínimo, los plazos de conservación, la auditoría y la separación de funciones no son complementos administrativos, sino requisitos arquitectónicos.

Prosimo reflejaba un cambio más amplio en la infraestructura: las decisiones de enrutamiento y de acceso dependen cada vez más de la identidad y de la semántica de las aplicaciones. Cuanto más contexto ve el controlador, más valiosas pueden ser sus decisiones, pero también más rigurosa debe ser su gobernanza.

El descubrimiento de activos construye el mapa del que dependen todas las decisiones posteriores

Un controlador multicloud no puede gobernar lo que no ve. Prosimo desarrolló un descubrimiento y un mapa de activos en la nube que representaba VPC, VNet, subredes, aplicaciones, conexiones y relaciones de seguridad. Estas vistas se utilizaban para la incorporación, el diseño, la resolución de problemas y las políticas.

La capacidad de descubrimiento es importante porque los entornos de nube cambian a menudo al margen de los procesos centrales de red. Los equipos de aplicaciones pueden crear cuentas, redes, puntos de conexión y servicios gestionados con su propia automatización. Los diagramas mantenidos manualmente quedan obsoletos con rapidez. Un inventario basado en API suele estar más actualizado, pero su integridad depende de la cobertura de cuentas, los permisos, la lógica de análisis y las API de la nube.

Este mapa no solo sirve para la documentación: el enrutamiento, la segmentación, la inserción de servicios y la optimización pueden calcularse a partir de él. La omisión de un solo activo o dependencia puede distorsionar las conclusiones. Por eso, la topología debe conservar la información de origen: cuándo se recopiló, desde qué cuenta, qué regiones cubre y si hubo solicitudes fallidas.

Esto también ayuda a explicar la adquisición. Palo Alto Networks solo puede desplegar capacidades de seguridad de forma más eficaz si sabe dónde están las cargas de trabajo y las rutas de tráfico. Un sistema que descubre activos en la nube y modifica el enrutamiento puede acortar la distancia entre la compra de un firewall de software y su colocación en el lugar correcto. Las declaraciones posteriores de Bhau precisamente subrayan el descubrimiento de activos y la aceleración del despliegue de firewalls de software.

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

Application-driven Intelligent Results (AIR) analizaba la telemetría recopilada por los bordes AXI. La documentación técnica de AWS mencionaba 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 de usuario, red y aplicación, en lugar de mostrar contadores aislados de dispositivos.

Esta correlación aborda problemas operativos habituales: una transacción puede ralentizarse por la ruta del usuario, el borde, la red troncal de la nube, un servicio de seguridad o la propia aplicación. Una vista transversal puede acotar la causa más rápidamente que varias consolas independientes, y también puede ofrecer recomendaciones sobre rutas, ubicación, riesgo y coste.

La calidad de las recomendaciones depende de la cobertura de la telemetría y del modelo de interpretación. Los bordes solo ven el tráfico que los atraviesa; las dependencias externas de las aplicaciones y el estado interno de los proveedores de nube pueden permanecer invisibles. Por tanto, una recomendación puede tener valor orientativo sin demostrar la causa raíz.

La telemetría también tiene valor de gobernanza: los datos históricos pueden explicar por qué cambió una ruta o una política, pero también pueden exponer patrones de uso de aplicaciones sensibles y comportamientos de usuario. La información pública no detalla la conservación de datos ni la gobernanza posterior a la adquisición, por lo que estas cuestiones siguen siendo competencia de la diligencia debida del cliente.

AWS ofrecía el ejemplo de implantación más claro de la documentación pública

La colaboración de Prosimo con AWS generó las pruebas técnicas públicas más sólidas. La empresa se integró con AWS Transit Gateway, Cloud WAN, PrivateLink y Marketplace for Containers Anywhere. AWS publicó flujos para la ubicación del borde AXI, el acceso a aplicaciones, la identidad, la seguridad y la optimización.

AWS Cloud WAN es especialmente relevante: proporciona una red troncal nativa y capacidades de segmentación, y Prosimo las orquestaba en lugar de sustituirlas. La división del trabajo era clara: AWS posee la red nativa y la infraestructura global; Prosimo aportaba la intención multicloud, el contexto de aplicación, el software de borde y el análisis.

El flujo de trabajo del Marketplace simplificaba el despliegue inicial, pero no eliminaba las cuestiones de permisos de cuenta, diseño de enrutamiento, alta disponibilidad, capacidad y operación a largo plazo. La automatización del día 0 reduce la fricción de instalación, pero no sustituye la gobernanza continua.

Los materiales de Prosimo también citaban el testimonio de Flexport, que respaldaba el caso de uso de AWS Cloud WAN. Esto demuestra que una empresa cliente estaba dispuesta a avalar la arquitectura, pero no constituye una auditoría independiente de la escala de despliegue, el ahorro o la disponibilidad. Los testimonios de clientes deben considerarse ejemplos de adopción, no pruebas de rendimiento generalizables.

Azure y Google Cloud completaban la propuesta multicloud

Prosimo también era compatible con Microsoft Azure y Google Cloud. Los materiales de producto describían la orquestación en torno a Azure Virtual WAN y a los objetos de red y servicios privados de Google Cloud. El objetivo era ofrecer un modelo operativo unificado respetando las redes nativas de cada nube.

La compatibilidad no equivale a una paridad funcional completa. Las API de las nubes evolucionan a ritmos distintos, y nombres de producto similares pueden ocultar semánticas diferentes. El enrutamiento, la segmentación, los puntos de conexión privados o la inserción de servicios pueden requerir un tratamiento específico del proveedor. Las pruebas disponibles no reconstruyen una tabla comparativa función por función que cubra todas las regiones y versiones.

Por tanto, la abstracción multicloud se asemeja más a un sistema de traducción: puede normalizar la intención y los flujos de trabajo comunes, pero debe conservar las diferencias que afectan a la seguridad, el coste y los fallos. La abstracción se vuelve peligrosa cuando la interfaz parece uniforme pero las diferencias de implementación no son visibles para el operador.

Lo mismo se aplica después de la adquisición. Palo Alto Networks puede utilizar un mapa unificado para colocar la seguridad en todas las nubes, pero los proveedores de nube siguen controlando los objetos nativos que materializan la ruta. Poseer la capa de orquestación no equivale a poseer la infraestructura de transporte subyacente.

El producto pasó de la conectividad a todo el ciclo de vida operativo

En 2023, Prosimo ya describía su producto como un flujo de trabajo completo para diseñar, construir, diagnosticar y gestionar redes multicloud, no solo como túneles o puertas de enlace. El descubrimiento de activos ayudaba a diseñar, la orquestación creaba la conectividad, el mapa y la telemetría facilitaban el diagnóstico, y las políticas junto con el estado histórico permitían la gestión continua.

Este posicionamiento ampliaba los compradores potenciales. El equipo de redes utilizaba la topología y el análisis de rutas; el de plataforma de nube accedía a las cuentas y los servicios; el de seguridad examinaba la segmentación y las rutas de inspección; el de migración planificaba los cambios; el de FinOps evaluaba los costes de salida y las rutas. La plataforma gana valor cuando varios equipos comparten las mismas evidencias.

Compartir evidencias también provoca conflictos de gobernanza: una plataforma central puede descubrir que la configuración nativa de un equipo de nube no coincide con la política corporativa. La organización debe decidir qué sistema tiene autoridad y quién puede aprobar la corrección. El software por sí solo no resuelve este problema institucional.

La narrativa del ciclo de vida también eleva los costes de cambio. Una vez que el controlador almacena el mapa de activos, las políticas, la telemetría, las ubicaciones de los bordes y las integraciones de automatización, sustituirlo no es solo mover líneas, sino exportar o reconstruir el modelo operativo. Prosimo solucionaba la fragmentación de la nube, pero también podía crear una dependencia del controlador.

La segmentación pasó de la accesibilidad de capa 3 a las políticas de aplicación de capa 7

Prosimo describía la segmentación como una capacidad que abarcaba de la capa 3 a la capa 7. En la capa de red, los dominios de enrutamiento 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 los atributos de la transacción podían refinar aún más las reglas.

Este modelo puede acortar la distancia entre las zonas de red y las políticas de aplicación. Un servicio de negocio concreto puede estar permitido aunque la comunicación amplia entre subredes esté bloqueada; a la inversa, una ruta de red puede ser accesible, pero denegarse porque el contexto de identidad o de aplicación no coincide.

Esto no convertía a Prosimo en un firewall de última generación completo. La integración con Palo Alto de 2024 establecía una división clara: Prosimo se encargaba de la conducción del tráfico, la segmentación y la inserción de servicios; VM-Series, de la inspección profunda. La conducción de políticas y la ejecución de la seguridad tienen modos de fallo distintos y no deben confundirse.

La segmentación solo es efectiva si todas las rutas relevantes están representadas. Una ruta desconocida, una excepción nativa de la nube o una inserción de servicio fallida pueden eludir el control. Para garantizarla, hay que contrastar las políticas declaradas, el estado real de la nube y el tráfico observado, sin fiarse únicamente de lo que muestra la consola de configuración.

La inserción de servicios conecta el control de enrutamiento con la economía del firewall

El diseño de la seguridad en la nube obliga a decidir dónde se realiza la inspección. Un firewall centralizado simplifica las políticas y reduce el número de instancias, pero puede provocar retornos de tráfico, riesgos de concentración y presión sobre la capacidad. Un firewall distribuido cerca de las cargas de trabajo reduce esos problemas, pero multiplica los despliegues, las licencias, las actualizaciones y la gestión de políticas.

La integración de Prosimo con VM-Series admitía ambos modelos. Las políticas podían dirigir tráfico específico hacia un punto de inspección central o hacia firewalls distribuidos en las VPC de aplicación. Prosimo modificaba el enrutamiento circundante; Palo Alto Networks proporcionaba la inspección.

Esta arquitectura convierte la orquestación del enrutamiento en un activo comercial para el fabricante de seguridad. Un firewall de software no puede proteger el tráfico que nunca lo atraviesa. El descubrimiento, la elección de la ubicación y las actualizaciones de enrutamiento pueden acortar la distancia entre la compra de una capacidad de seguridad y su inserción real en la ruta de producción. Este es uno de los motivos estratégicos razonables por los que Palo Alto Networks adquirió la tecnología de Prosimo.

Al mismo tiempo, el radio de fallo del controlador también se amplía. Una política errónea puede eludir la inspección, crear bucles, provocar enrutamiento asimétrico o interrumpir aplicaciones. Las comprobaciones de estado, los cambios por fases, la simulación, la auditoría y la reversión son imprescindibles, porque un error en la inserción de servicios es tanto un incidente de red como de seguridad.

La colaboración de 2024 no puede interpretarse como una adquisición consumada

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, sin afirmar que Palo Alto Networks hubiera adquirido Prosimo. Utilizar ese anuncio como prueba de propiedad confunde dos acontecimientos distintos.

La colaboración sí tendió un puente: Prosimo podía demostrar cómo su sistema de enrutamiento y políticas simplificaba el despliegue de VM-Series en varias nubes; Palo Alto Networks podía evaluar la tecnología en una integración real. Los documentos públicos no describen el proceso de adquisición, por lo que no se puede deducir que esa colaboración fuera un paso formal previo a la compra.

A principios de 2025, los perfiles profesionales de los fundadores y los empleados cambiaron; más tarde, la página corporativa mostró el estado de adquirida; a finales de 2025, Bhau afirmó que la tecnología estaba plenamente integrada. El conjunto de estos tres tipos de pruebas respalda la conclusión de la adquisición, pero sigue sin aportar los detalles jurídicos de la transacción.

Esta secuencia temporal también es importante para los clientes. Una colaboración implica dos proveedores, dos sistemas de soporte y un límite de integración definido. Una adquisición puede transferir la hoja de ruta, los datos, los contratos y los permisos a una sola empresa. Aunque la ruta técnica parezca similar, las implicaciones de gobernanza han cambiado.

Nebula convierte el mapa topológico en una interfaz conversacional

Prosimo presentó Nebula en febrero de 2024 como parte de AI Suite para redes multicloud. Estaba diseñado para responder en lenguaje natural a preguntas sobre solapamiento de direcciones, costes, estado del enrutamiento, infracciones de políticas de seguridad y otras cuestiones, todas ellas basadas en el mapa y la telemetría de la plataforma.

El activo realmente valioso no era la interfaz de lenguaje en sí, sino el contexto estructurado subyacente. Un modelo genérico no puede diagnosticar rutas privadas que no ve. Nebula podía acceder a los activos, la topología, las políticas y los datos de observación que Prosimo ya había recopilado, de modo que la inversión previa en un mapa unificado se convertía en la base para las operaciones asistidas por IA.

El acceso conversacional puede facilitar que más personal de operaciones utilice datos complejos, pero también puede generar una falsa confianza: la respuesta podría omitir activos no soportados, malinterpretar la pregunta o convertir una sugerencia en una acción aprobada. Los cambios de alto riesgo siguen necesitando control determinista, límites de autoridad y revisión humana.

Prosimo llegó a afirmar que el tiempo medio de reparación podía reducirse entre un 60% y un 80%, y que los costes de red en la nube podían bajar más de un 60%. Estas cifras proceden de los anuncios de producto del fabricante, sin una metodología independiente ni líneas de base de clientes que demuestren su aplicabilidad general. Pueden citarse como objetivos planteados por Prosimo, pero no como hechos sectoriales contrastados.

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

El mismo anuncio de 2024 también describía la arquitectura de Prosimo como adecuada para cargas de trabajo de IA. Los sistemas de IA distribuidos pueden requerir acceso a datos privados, conectividad entre nubes y centros de datos, controles de cumplimiento y enrutamiento consciente de la aplicación. Estos requisitos encajan con los modelos existentes de activos, políticas y rutas.

La etiqueta “IA” no modificaba la infraestructura de transporte subyacente. Prosimo seguía dependiendo de las redes de los proveedores de nube, de los operadores y de la infraestructura del cliente, y no ofrecía computación GPU ni software de desarrollo de modelos. Su posible función era proporcionar conectividad y seguridad alrededor de los datos y servicios distribuidos.

Este posicionamiento tiene lógica estratégica, porque cuanto más dispersos estén los datos y los servicios, más valiosa resulta una topología multicloud. Sin embargo, se trata de una categoría de marketing introducida poco antes de que la empresa dejara de operar de forma independiente. Las pruebas disponibles no incluyen ingresos separados de IA, despliegues de producción identificados ni resultados auditados.

La conclusión sostenible es que la telemetría multicloud puede servir como entrada para operaciones asistidas por máquinas. La pregunta hoy es si Palo Alto Networks ha conservado ese contexto y cómo expone las capacidades a los clientes. La información pública no lo responde por completo.

El modelo de negocio era vender software sobre infraestructura ajena

El negocio independiente de Prosimo se basaba en suscripciones de software y servicios, no en un modelo de operador. Los clientes desplegaban los bordes AXI en sus propios entornos y conectaban las cuentas de nube a la capa de control. Los ingresos probablemente procedían de licencias o suscripciones, soporte, servicios profesionales y canal, pero los materiales disponibles no ofrecen precios concretos ni indicadores contractuales.

Este modelo permitía crecer sin poseer fibra: una sola plataforma podía orquestar un gran número de regiones y entornos de cliente. Sin embargo, no se puede deducir el margen bruto a partir de la arquitectura; el mantenimiento continuo de las API de los proveedores, el ciclo de vida de los bordes, las integraciones de seguridad y los despliegues empresariales pueden ser costosos, y los recursos de nube que consumen los bordes pueden ser facturados directamente al cliente.

Prosimo accedía a las empresas a través de los mercados de nube, los socios de integración, el canal y los casos de clientes. Estas relaciones no son equivalentes: la presencia en un mercado demuestra que existe un canal de compra y despliegue; la integración técnica demuestra que dos sistemas pueden funcionar juntos en condiciones determinadas; los testimonios de clientes ofrecen referencias. Ninguno de ellos, por sí solo, acredita el número de clientes de pago o los ingresos recurrentes.

La amplitud del producto también podía dificultar la venta. Los equipos de redes, seguridad, nube y aplicaciones podían beneficiarse, pero la titularidad del presupuesto era difusa. Prosimo necesitaba un comprador dispuesto a pagar por una capa de control común, en lugar de permitir que cada equipo siguiera operando de forma aislada.

Socios, clientes e inversores desempeñan papeles distintos

AWS era a la vez el proveedor de la infraestructura subyacente y un socio de integración en el mercado; Azure y Google Cloud eran entornos compatibles; los proveedores de identidad aportaban el contexto de autenticación; los fabricantes de firewalls proporcionaban la inspección; los servicios gestionados y de co-ubicación podían alojar o conectar los bordes; los socios de canal podían diseñar y operar los despliegues.

Flexport era la referencia de cliente más visible en los materiales de AWS Cloud WAN, lo que demuestra el interés de una empresa por la arquitectura, pero no revela el alcance completo del despliegue, su duración ni su valor comercial, y no sustituye el dato del número total de clientes.

General Catalyst lideró la Serie A y participó en la gobernanza de la inversión. Los materiales de la empresa también mencionan a inversores relacionados con WRVI/Celesta, e informaciones posteriores aluden a una participación conocida vinculada a BlackRock, aunque la investigación no pudo precisar el vehículo de inversión concreto. Estos datos indican una red de financiación sólida, pero no constituyen una tabla de capitalización completa.

Palo Alto Networks es la relación más importante: pasó de ser un socio de seguridad en 2024 a ser el adquirente a principios de 2025. Este proceso ilustra cómo la dependencia tecnológica se transforma en una relación de control cuando un socio del ecosistema compra la capa de software que coordina el acceso a sus propios productos.

Financiación verificada de al menos 55 millones de dólares; la economía de la salida sigue siendo desconocida

La financiación confirmada incluye 25 millones de dólares en la Serie A de abril de 2021 y 30 millones en la Serie B de 2022. Los materiales disponibles no contienen una tabla de capitalización auditada, valoración, acuerdos de deuda ni financiación posterior.

El precio de la adquisición no se ha revelado ni verificado de forma independiente. Sin él, no se puede clasificar de forma responsable el resultado como una prima estratégica, una adquisición tecnológica ordinaria, una compra de talento o una operación en situación de dificultad. El hecho de que la tecnología se siga integrando indica que tiene valor, pero no dice nada sobre el rendimiento real para los inversores y los fundadores.

Tampoco se pueden atribuir a Prosimo los ingresos y el tamaño de mercado de Palo Alto Networks. Tras la adquisición, Prosimo dejó de ser una unidad económica observable por separado; no existen ingresos, beneficios ni segmentos de cliente independientes que analizar. Un propietario más grande puede ampliar el uso de la tecnología y, al mismo tiempo, hacer que su economía individual sea más opaca.

La ausencia de un comunicado oficial de adquisición es en sí misma un hecho relevante. Normalmente, los clientes, los empleados y los investigadores utilizan ese comunicado para conocer el calendario, el soporte y la lógica estratégica. Aquí, el estado ha tenido que reconstruirse a partir de los historiales profesionales, la etiqueta de estado de la empresa y las declaraciones posteriores del fundador. Esto basta para corregir la identidad corporativa, pero no para inventar las condiciones de la transacción.

La competencia procede de plataformas especializadas, servicios nativos de nube e ingeniería interna

Prosimo competía con plataformas especializadas de redes multicloud como Aviatrix y Alkira, con fabricantes de redes empresariales y SASE, y con los servicios nativos de AWS, Azure y Google Cloud. También competía con el modelo de construcción propia: utilizar directamente infraestructura como código, servicios de tránsito en la nube, tablas de enrutamiento y firewalls. Cada alternativa resuelve una parte diferente del mismo problema.

Los controladores especializados ofrecen topología y políticas unificadas en varias nubes; los diseños nativos de nube reducen la dependencia de terceros y se ajustan a un único proveedor; los servicios de operador proporcionan transporte físico; las plataformas SASE o de seguridad combinan conectividad y ejecución; la ingeniería interna intercambia costes de personal e integración por control.

El elemento diferenciador de Prosimo era la combinación de tránsito de aplicaciones y de red, bordes distribuidos, orquestación nativa de nube, topología, telemetría e inserción de servicios. Esa misma amplitud dificulta la comparación. Los compradores deben probar los servicios de nube, el enrutamiento, la identidad y los modelos de seguridad que realmente utilizan, en lugar de limitarse a comparar nombres de categorías.

La adquisición modifica el marco competitivo. Prosimo ya no necesita ganar como empresa independiente; su tecnología debe demostrar su valor dentro de Palo Alto Networks. La comparación clave pasa a ser: ¿mejora la integración del descubrimiento y la orquestación del enrutamiento el despliegue de los productos de seguridad de Palo Alto, y aceptan los clientes la mayor dependencia de la plataforma que ello conlleva?

Los servicios nativos de nube son a la vez la base y la alternativa

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN y las capacidades de red de Google Cloud ofrecen a las empresas sólidas opciones nativas. Prosimo dependía de ellas y, al mismo tiempo, competía con la opción de que los clientes las manejaran directamente.

Esta frontera está en constante movimiento. Cuando los proveedores de nube añaden enrutamiento global, segmentación, servicios privados o políticas centralizadas, algunas funciones de terceros se vuelven más fáciles de replicar de forma nativa; al mismo tiempo, cada nuevo servicio nativo genera nuevos objetos que necesitan ser descubiertos y coordinados por un controlador multicloud. Los avances de la nube pueden reducir una parte del valor de Prosimo, pero también pueden aumentar la necesidad de traducción entre proveedores.

El factor determinante vuelve a ser la capacidad organizativa. Una empresa que opera en una sola nube y cuenta con un sólido equipo de ingeniería interna puede preferir las herramientas nativas; una empresa multicloud con equipos fragmentados puede necesitar una capa de control unificada; una organización regulada puede valorar las pruebas proporcionadas por un tercero, pero temer la concentración de credenciales y datos.

Ninguna arquitectura elimina por completo la dependencia de un proveedor. Las herramientas nativas dependen de las API y la semántica de una nube concreta; un controlador multicloud depende de su mapa, sus políticas y sus bordes. La verdadera pregunta es si esa dependencia es transparente, portable y compatible con el modelo operativo de la organización.

Los fallos pueden producirse en el controlador, los bordes, las API de nube, los sistemas de identidad o la red subyacente

Una arquitectura distribuida reduce la dependencia de un único centro de tráfico, pero crea múltiples dominios de fallo que interactúan entre sí. El servicio central puede no estar disponible o conservar una intención desactualizada; un borde puede fallar o quedar aislado; una API de nube puede rechazar un cambio parcial; un sistema de identidad puede interrumpirse; la red subyacente puede degradarse o desviar el tráfico; un firewall insertado puede agotar sus recursos.

Los fallos parciales son especialmente difíciles: una nube acepta la actualización de enrutamiento y otra la rechaza, lo que provoca una divergencia entre el estado esperado por el controlador y el estado real; el tráfico puede seguir rutas asimétricas o eludir la inspección. Un sistema fiable necesita reconciliación, operaciones idempotentes, cambios por fases, errores explícitos y reversiones adaptadas a cada proveedor.

Las pruebas públicas describen una arquitectura de alta disponibilidad y optimización, pero no incluyen estudios independientes de inyección de fallos, registros completos de incidencias ni resultados de servicio generalizables. Por tanto, las conclusiones sobre la resiliencia deben limitarse al ámbito de la arquitectura documentada o de las pruebas de clientes identificados.

La adquisición añade un nuevo dominio de fallo: la continuidad del producto. Los clientes necesitan saber qué consola, API, imágenes de borde, modelo de políticas y organización de soporte sustituyen al sistema histórico de Prosimo. Incluso si la integración del código es técnicamente exitosa, la falta de claridad en los límites comerciales y operativos crea riesgos de migración.

Las credenciales de nube sitúan al controlador dentro de un plano de gestión crítico

El descubrimiento de activos y la orquestación requieren acceso a las cuentas de nube. Un inventario de solo lectura puede utilizar permisos limitados, pero los cambios de enrutamiento, segmentación e inserción de servicios necesitan permisos más amplios. En consecuencia, el controlador, sin ser propietario de las cargas de trabajo, se sitúa dentro de un plano de gestión con altos privilegios.

La filtración de credenciales podría exponer la topología o permitir cambios generalizados; un defecto de software o un error operativo podría propagar políticas a través de varias nubes. Cuantas más cuentas y servicios gobierne la plataforma, mayor será el radio de fallo potencial.

Las empresas necesitan roles con privilegio mínimo, credenciales separadas para descubrimiento y escritura, aprobación por varias personas, auditoría completa, rotación, revocación de emergencia y una ruta de recuperación que no dependa del mismo controlador. Los materiales públicos no contienen una evaluación de seguridad independiente completa, por lo que estos son controles de despliegue necesarios, no garantías verificadas.

El mapa de telemetría es igualmente sensible: puede exponer nombres de aplicaciones, estructuras de red, políticas, relaciones de usuario, estado del enrutamiento 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 transfieren los permisos históricos de los clientes. La información pública aún no responde a estas cuestiones.

La adquisición sitúa una capa de control que se consideraba neutral dentro de una plataforma de seguridad

Cuando Prosimo era independiente, podía presentarse como una capa de control común para todas las nubes y servicios de seguridad. Al convertirse Palo Alto Networks en propietario, la estructura de incentivos cambió. La tecnología adquirida puede facilitar el despliegue de VM-Series y otros productos de Palo Alto, lo que puede traducirse en una integración más estrecha, pero también plantea si los servicios de inspección de terceros seguirán recibiendo un soporte equitativo.

El cambio de propiedad no demuestra que la neutralidad haya desaparecido; los materiales actuales no ofrecen una matriz de socios ni una arquitectura completa. Pero las preguntas que deben hacerse los clientes han cambiado: ¿sigue el controlador soportando múltiples fabricantes de seguridad? ¿Se pueden exportar las políticas y la telemetría? ¿La lógica de optimización privilegia la cartera de productos del propietario?

Las declaraciones de integración destacan la inspección del tráfico de entrada, salida y este-oeste, lo que sugiere que la topología y la orquestación de Prosimo pueden formar parte de un sistema de despliegue de seguridad. Sin embargo, no demuestran que los flujos de trabajo históricos de App Transit, acceso de usuarios, optimización de costes y todas las capacidades de red en la nube sigan existiendo como funciones independientes.

Este es un patrón habitual en infraestructura: una startup abstrae un problema de coordinación complejo; un gran proveedor de plataforma compra esa capa de abstracción para aumentar el despliegue y el control de sus productos principales. Los clientes pueden obtener una mejor integración, pero pierden parte de su independencia frente al proveedor.

El mapeo actual de productos es el dato más relevante que falta

El registro público confirma la adquisición y la integración, pero no especifica qué productos o SKU actuales de Palo Alto Networks corresponden a AXI, Network Transit, App Transit, AIR y Nebula respectivamente. Tampoco se ha hecho público el plazo de soporte de los sistemas antiguos, el proceso de migración ni una tabla de continuidad funcional elemento por elemento.

Por tanto, no es posible realizar una evaluación de producto en tiempo presente. La documentación histórica puede explicar qué construyó Prosimo y por qué era importante, pero no puede afirmar qué capacidades están disponibles hoy, cómo se licencian o quién las soporta. Cualquier recomendación de despliegue actual debe basarse en la documentación vigente de Palo Alto Networks, no en anuncios archivados.

La ausencia de este mapeo también limita el análisis estratégico. Absorber por completo el mapa topológico y la capa de orquestación es un resultado muy distinto al de utilizar únicamente el descubrimiento de activos y la colocación de firewalls. El primero podría dar lugar a un amplio servicio de control multicloud; el segundo se centraría sobre todo en acelerar el despliegue de seguridad. Las declaraciones del cofundador confirman la continuidad tecnológica, pero no resuelven esta frontera arquitectónica.

Es probable que la futura documentación de producto, las guías de migración o los casos de clientes aclaren la mayoría de estas cuestiones. Hasta entonces, la formulación precisa es: según uno de los cofundadores, la tecnología de Prosimo se ha integrado en los productos de Palo Alto Networks, pero el alcance y el empaquetado siguen sin estar verificados públicamente.

¿Quién controla el enrutamiento multicloud?

Ninguna parte controla por sí sola la ruta completa. La empresa controla la titularidad de las cuentas, la intención de negocio, el diseño de las aplicaciones y las credenciales otorgadas. El controlador multicloud puede descubrir la topología, traducir las políticas, elegir las rutas y modificar el estado del enrutamiento nativo.

Los proveedores de nube controlan las API, los servicios de tránsito, los puntos de conexión privados, la red troncal y una parte importante de los dominios de fallo; los operadores y los servicios gestionados controlan otras partes del transporte; los servicios de seguridad deciden si el tráfico inspeccionado está permitido.

Prosimo buscó la posición intermedia de mayor valor estratégico: no poseía la infraestructura subyacente, pero aspiraba a controlar el mapa y la traducción de políticas que se situaban por encima de ella. Quien controla esa capa puede decidir qué activos son visibles, cómo se representan los segmentos, dónde se colocan los bordes, qué servicio inspecciona el tráfico y qué conjunto de telemetría se considera autorizado. Incluso si la fibra pertenece a otros, eso equivale a un poder real de enrutamiento.

Tras la adquisición, Palo Alto Networks es propietario de la tecnología remanente de Prosimo y decide su integración, su empaquetado comercial y su dirección de desarrollo. Los proveedores de nube siguen siendo dominantes dentro de sus respectivos entornos, y las empresas pueden revocar credenciales o elegir otra arquitectura; pero si la topología, las políticas y los flujos de trabajo operativos dependen del controlador, el coste de salida puede ser muy alto.

Por tanto, la respuesta es escalonada: la empresa autoriza, el controlador coordina, la infraestructura subyacente de los proveedores de nube y los operadores transporta, y la plataforma de seguridad ejecuta. La historia de Prosimo demuestra que la propiedad de la capa de coordinación puede cambiar sin que lo hagan las cuentas de nube ni las rutas físicas.

Registro de fuentes principales

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

Prosimo captó un cambio real: las unidades operativas de red están pasando de los dispositivos y los prefijos a las aplicaciones, la identidad, las dependencias de servicio y los mapas de políticas. Las API nativas de nube hacen que el estado de la red sea programable, y los bordes de software distribuidos permiten mover la ubicación de ejecución. Un controlador que ve múltiples nubes puede coordinar acciones que una sola consola de nube no puede realizar.

La empresa también puso de manifiesto el coste de la coordinación: una capa de control común requiere credenciales de alto privilegio, mantenimiento continuo de 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 amplificar el impacto de un error.

La adquisición por parte de Palo Alto Networks hace más evidente el problema del control. Las redes y la seguridad están convergiendo en torno a la inserción de servicios, el descubrimiento de cargas de trabajo y las políticas. Un fabricante de seguridad que conoce la topología y puede modificar el enrutamiento no se limita a inspeccionar el tráfico que le llega: también puede ayudar a decidir qué tráfico llega al punto de inspección y dónde se inspecciona.

Por lo tanto, Prosimo no debe recordarse solo como una marca independiente desaparecida, ni como la prueba de que una plataforma ha resuelto el problema multicloud. Su contribución duradera fue definir el mapa multicloud como infraestructura. La pregunta pendiente es si ese mapa, ahora integrado en una gran empresa de seguridad, sigue siendo lo bastante transparente, portable y gobernable para merecer la confianza de los clientes.