Introducción
El software Quantum abarca lenguajes de programación, compiladores, optimización de circuitos, mitigación de errores, sistemas de control, simuladores, orquestación de flujo de trabajo, bibliotecas de aplicaciones, estimación de recursos y soluciones de dominio. Algunos productos se ubican cerca de un procesador cuántico. Otros coordinan la computación cuántica y clásica, gestionan experimentos o empaquetan métodos científicos para la química, las finanzas, la optimización y el aprendizaje automático. Por lo tanto, el perímetro de transacción puede contener código, datos, patentes, secretos comerciales, empleados, contratos con clientes, relaciones en la nube y acceso futuro al hardware.
La pregunta central del comprador es si el objetivo posee una capacidad duradera o una implementación temporal adaptada a un dispositivo en particular. Un circuito que se ejecuta en dos plataformas puede producir diferente precisión, profundidad, costo y latencia. Un compilador puede reducir las puertas en una topología y al mismo tiempo aumentar la sobrecarga de enrutamiento en otra. Una aplicación puede depender del acceso por pulsos, del servicio de mitigación de errores o de la prioridad de cola de propiedad de un proveedor. Un contrato con un cliente puede financiar investigaciones en lugar de un producto repetible.
La valoración se vuelve difícil cuando la portabilidad se trata como un atributo de sí o no. El software puede ser portátil a nivel de origen y dependiente a nivel de rendimiento. Puede compilarse en una representación común y aún requerir una reducción específica del objetivo. Puede reproducir un resultado matemático perdiendo la velocidad, el costo o la precisión que respaldaron la afirmación comercial. Puede ejecutarse en hardware alternativo mientras la relación con el cliente permanece vinculada a un proveedor preferido.
Este artículo reemplaza la afirmación amplia de independencia del hardware con una jerarquía de evidencia. Se pregunta qué se mueve, qué se debe reconstruir, qué se realiza, quién paga y qué derechos se transfieren. El resultado es un marco de transacciones para equipos de desarrollo corporativo, inversores, fundadores y asesores que evalúan adquisiciones, combinaciones e inversiones estratégicas de software cuántico.
1 Definir la tesis de adquisición
El comité de transacciones debe indicar por qué se requiere la propiedad. Un comprador puede buscar una cartera de algoritmos, un compilador o una capa de control, un equipo de aplicaciones, acceso de clientes, datos de propiedad, patentes, una comunidad de desarrolladores o una ruta para integrar hardware y software. Cada tesis requiere una diligencia diferente y produce un puente de valoración diferente.
Un comprador de hardware puede valorar el software porque mejora la utilización, expone las capacidades del dispositivo y atrae cargas de trabajo. Un comprador de nube o plataforma puede valorar la abstracción, la orquestación y la distribución. Un comprador industrial puede valorar el flujo de trabajo de un dominio y a los científicos que lo entienden. Un inversor financiero puede valorar la opcionalidad entre varios proveedores de hardware. El comité debe identificar los ingresos, costos, tiempos o dependencia estratégica en que cambia la adquisición.
La tesis también debe exponer el contrafactual. Las alternativas pueden incluir licencias, asociaciones, desarrollo interno, adopción de código abierto, adquisición o espera. El tiempo de reemplazo y el riesgo de ejecución a menudo importan más que el gasto histórico en desarrollo. Es difícil justificar una prima de adquisición cuando una alternativa creíble logra el mismo resultado para el cliente antes de que el hardware cuántico se vuelva comercialmente relevante.
El documento de la junta directiva debe especificar la fecha de valoración, la garantía, la contraprestación, la financiación prevista y el presupuesto de integración. Debe identificar qué valor está presente en el cierre y cuál depende de hitos técnicos, del cliente o del hardware. Esa separación permite que el precio y la protección sigan a la evidencia.
2 Descomponer la independencia del hardware
La portabilidad del código fuente significa que el código o un algoritmo de alto nivel se puede mover o traducir. La portabilidad semántica significa que la operación matemática prevista sigue siendo equivalente. La portabilidad de la compilación significa que el programa se puede reducir a una representación intermedia aceptada y a un conjunto de instrucciones de destino. La portabilidad ejecutable significa que el flujo de trabajo completo se ejecuta en un destino en condiciones compatibles.
La portabilidad del rendimiento añade calidad a la solución, uso de recursos, latencia, rendimiento y costo. La portabilidad comercial pregunta si el cliente acepta el resultado, si el modelo de soporte sigue siendo viable y si la economía sobrevive. Estas capas deben probarse por separado. Pasar una capa anterior no establece la siguiente.
Una representación intermedia puede reducir el acoplamiento del lenguaje y el compilador. Microsoft describe Quantum Intermediate Representation como independiente del lenguaje y del hardware, y utiliza la infraestructura LLVM como interfaz común. El entorno de destino aún determina las puertas disponibles, el flujo de control, la medición, la sincronización y los servicios de tiempo de ejecución. Los perfiles de destino de Azure Quantum documentan diferentes capacidades para bifurcaciones, aritméticas y bucles condicionales. El comprador debe probar el perfil requerido por cada flujo de trabajo valioso.
OpenQASM 3 también proporciona un lenguaje amplio para programas cuánticos y control clásico en tiempo real. Su especificación permite que las implementaciones restrinjan el procesamiento en tiempo de ejecución a operaciones que el hardware puede realizar de manera eficiente. Los documentos de Amazon Braket admiten declaraciones, operaciones y capacidades del dispositivo. Por lo tanto, la existencia de una norma mejora la interoperabilidad y deja diferencias sustanciales en la implementación.
3 Construya la escalera de evidencia del algoritmo
El primer nivel es una especificación matemática con un problema definido, entradas, salidas y criterios de corrección. El segundo es una simulación clásica reproducible. El tercero es la compilación para un objetivo con nombre. El cuarto es la ejecución en hardware con registros completos de recursos y errores. El quinto es el rendimiento repetido en todas las fechas, dispositivos e instancias de problemas. El sexto es un resultado aceptado por el cliente.
Cada nivel debe tener un paquete de evidencia congelada. Debe contener código fuente, dependencias, archivos de entorno, casos de prueba, datos, semillas, configuraciones del compilador, identificadores de destino, registros de calibración, tiempo de cola, tiempo de ejecución, tomas, posprocesamiento, costos y medidas de calidad de resultados. El adquirente debería poder reproducir el resultado reclamado en un entorno limpio.
La novedad algorítmica no crea automáticamente valor comercial. Un método puede ser científicamente interesante mientras que las alternativas clásicas siguen siendo más rápidas, más baratas o más precisas. Una aplicación valiosa debería definir la decisión mejorada, la línea de base relevante y las condiciones bajo las cuales la computación cuántica o de inspiración cuántica cambia la economía.
La escalera debe identificar el nivel de evidencia más alto alcanzado para cada producto. Un portafolio puede contener software maduro de diagnóstico de errores, rutinas de optimización experimentales e investigaciones no financiadas. Aplicar un múltiplo de ingresos a los tres oculta la diferencia. La valoración debe asignar el valor alcanzado y el valor de la opción condicional por separado.
4 Medir la calidad de referencia
Los puntos de referencia deberían responder a una pregunta sobre transacciones. Los puntos de referencia QED-C orientados a aplicaciones evalúan la fidelidad de los resultados, el tiempo de ejecución y el consumo de recursos en todos los algoritmos y tamaños de problemas. Son útiles porque van más allá de una única métrica de hardware. El comprador aún debe verificar si el punto de referencia representa las cargas de trabajo del cliente objetivo y si las opciones de implementación favorecen a una plataforma.
El plan de referencia debe incluir instancias reservadas, líneas de base clásicas y configuraciones de objetivos múltiples. Debe registrar el tiempo de compilación, el ancho y la profundidad del circuito, las operaciones de dos qubits, los disparos, el tiempo de cola, el tiempo de ejecución, el posprocesamiento clásico, los reintentos y el costo total. La calidad de la solución debe definirse antes de conocer los resultados.
Las versiones de hardware y compilador son importantes. Un resultado puede mejorar debido a la calibración, la transpilación o la mitigación de errores en lugar del algoritmo propietario del objetivo. El comprador debe volver a ejecutar una implementación de referencia a través de la misma pila y probar la contribución del objetivo mediante ablación. El valor de propiedad se admite cuando la mejora persiste después de controlar el acceso y la configuración.
La gobernanza de referencia debería evitar la presentación de informes selectivos. Se deben conservar todos los intentos de instancias, exclusiones y ejecuciones fallidas. El equipo de diligencia debe comprender el ajuste de parámetros y si las implementaciones de los clientes requieren una intervención especializada similar. Un resultado que depende del ajuste manual dirigido por el fundador puede representar valor de servicios o talento en lugar de un producto de software escalable.
5 Compilador de mapas y dependencia de representación intermedia
La compilación cuántica incluye descomposición, mapeo, enrutamiento, programación, optimización, reducción de pulsos e integración del tiempo de ejecución. Una aplicación puede llamar a una biblioteca de alto nivel mientras que el rendimiento de valor se encuentra en pases de terceros o servicios de proveedores. El comprador debe rastrear cada transformación desde el origen hasta el trabajo ejecutado.
El gráfico de dependencia debe identificar lenguajes, bibliotecas, representaciones intermedias, compiladores, complementos, backends de destino, simuladores, API en la nube y servicios clásicos. Para cada componente, la diligencia debe registrar la propiedad, la licencia, la versión, el mantenimiento, el esfuerzo de reemplazo y la importancia operativa. La disponibilidad de código abierto reduce parte del riesgo de adquisición al tiempo que crea obligaciones de gobernanza y compatibilidad.
El rendimiento del compilador debe probarse según el objetivo. Un pase que reduzca la profundidad en un gráfico de conectividad puede proporcionar un beneficio limitado en otros lugares. Los circuitos dinámicos, la medición de mitad del circuito, el restablecimiento, el acceso a pulsos y las funciones de mitigación de errores pueden cambiar el algoritmo disponible. Los perfiles de destino QIR y la documentación del proveedor deben conciliarse con los requisitos reales del objetivo.
El adquirente debe reproducir una compilación limpia sin credenciales de fundador, archivos locales o servicios no divulgados. Debería regenerar artefactos intermedios y ejecutar un punto de referencia acordado. La reproducibilidad de la construcción respalda la transferibilidad. No establece por sí solo libertad de operación, escala o valor para el cliente.
6 Pruebe la portabilidad entre modalidades de hardware
Las modalidades de hardware difieren en conectividad, operaciones nativas, medición, reinicio, coherencia, duración de puerta, control y economía de colas. Los sistemas superconductores, de iones atrapados, de átomos neutros, fotónicos y de recocido pueden requerir diferentes formulaciones u opciones de compilación. Una afirmación de portabilidad debe especificar la clase de problema y el objetivo admitidos.
La matriz de prueba debe incluir al menos un objetivo principal, una alternativa creíble y un simulador o emulador. La misma carga de trabajo debe utilizar datos de entrada y criterios de aceptación definidos. Se deben medir las diferencias en la calidad, la profundidad, el tiempo de ejecución, los reintentos y el costo de la solución. Cuando el algoritmo cambia materialmente según el objetivo, el comprador debe tratar cada implementación como un producto mantenido por separado.
El acceso de los proveedores puede ser un activo oculto. Las colas de prioridad, la capacidad reservada, la información de calibración, el soporte de ingeniería y las funciones no públicas pueden respaldar resultados que los clientes comunes no pueden reproducir. Los contratos deben revisarse para determinar su asignación, cambio de control, fijación de precios, datos y continuidad. La valoración debe separar el software del acceso privilegiado.
La portabilidad también puede debilitar la diferenciación. Si una representación estándar permite a los competidores mover algoritmos equivalentes fácilmente, el foso puede estar en los datos, la optimización, la integración del flujo de trabajo o las relaciones con los clientes. El informe de diligencia debe indicar qué capa sigue siendo propietaria después de que el programa se expresa a través de interfaces abiertas.
7 Diligencia en propiedad intelectual y código abierto
El comprador debe asignar patentes, derechos de autor, secretos comerciales, derechos de datos, licencias y acuerdos de contribución a cada producto. Los repositorios de origen deben mostrar la autoría, el historial de confirmaciones, los componentes y las versiones de terceros. Las asignaciones de empleados y contratistas deben estar completas. El trabajo universitario o financiado por el gobierno puede conllevar derechos y obligaciones adicionales.
El software de código abierto puede acelerar la adopción y crear una comunidad de desarrolladores. También puede permitir a los competidores utilizar la capacidad central. El comprador debe comprender qué repositorios están abiertos, qué componentes siguen siendo propietarios y si un cambio en la licencia es legal y comercialmente práctico. Las obligaciones de copyleft, atribución, notificación, patentes y redistribución deben ser revisadas por un abogado calificado.
Los datos de capacitación, los datos moleculares, los conjuntos de datos de clientes y los corpus de referencia pueden ser materiales. El objetivo debe demostrar procedencia, consentimiento, derechos de uso contractuales, derechos de retención y transferencia. Los datos obtenidos para un proyecto específico pueden no ser reutilizables después de una adquisición. Los datos sintéticos o públicos pueden ser reemplazables y no deberían recibir un valor de escasez no respaldado.
Los secretos comerciales requieren controles operativos. El comprador debe examinar el acceso, la documentación, el cifrado, la salida y la concentración de conocimientos. Un método conocido sólo por un investigador debe valorarse con riesgo de retención y transferencia. Las patentes deberían relacionarse con el producto real en lugar de contarse.
8 Separar los ingresos por productos de la financiación de la investigación
Los ingresos del software cuántico pueden incluir suscripciones, licencias, servicios profesionales, premios gubernamentales, colaboraciones de investigación, pagos por hitos y uso de la nube. Estas categorías tienen diferente repetibilidad y márgenes brutos. El comprador deberá conciliar contratos, facturas, aceptaciones y efectivo por cliente y producto.
Los ingresos recurrentes deberían requerir una obligación continua y una base de renovación creíble. Un acuerdo de investigación de varios años puede proporcionar efectivo contratado y al mismo tiempo financiar trabajos personalizados. Un piloto puede demostrar presupuesto y compromiso sin demostrar la adecuación del producto al mercado. Las subvenciones pueden financiar un desarrollo valioso al tiempo que conllevan restricciones y una recurrencia comercial limitada.
La cohorte de clientes debe mostrar ingresos iniciales, renovaciones, expansión, contracción, abandono, servicios, ingresos diferidos y cobranza de efectivo. Debe identificar el proveedor de hardware, la carga de trabajo, la versión del producto y el soporte especializado. La concentración puede ser alta porque los primeros clientes son socios estratégicos. El comprador debe probar si esas relaciones sobreviven a un cambio de control o de estrategia de hardware.
Las previsiones de ingresos no deben suponer que una mayor disponibilidad de hardware genera demanda automáticamente. El modelo debe vincular cada segmento de clientes con una capacidad definida, un evento de adopción y un costo de venta. Los pronósticos de mercado no respaldados deberían permanecer fuera del puente del valor alcanzado.
9 Resultados de diligencia para el cliente
Las referencias de los clientes deben centrarse en las decisiones y los resultados aceptados. El comprador debe preguntar qué problema se abordó, qué línea de base clásica existía, qué objetivo se utilizó, cómo se validaron los resultados, qué recursos se consumieron y si el cliente cambió una decisión operativa. Una colaboración publicada puede ser estratégicamente significativa sin establecer un valor económico recurrente.
Los criterios de aceptación deben ser contractuales siempre que sea posible. El software de química puede juzgarse por su precisión predictiva y su validación experimental. La optimización puede juzgarse por el valor objetivo, la viabilidad, el tiempo de ejecución y la repetibilidad. El diagnóstico de errores puede juzgarse por la reducción medida o la calidad de la validación. La métrica debe coincidir con el uso del cliente.
La portabilidad debería probarse comercialmente. Si el proveedor original no está disponible o el objetivo es adquirido por una empresa de hardware competidora, ¿puede el cliente continuar? El comprador debe examinar las obligaciones de rescisión, exclusividad, datos, propiedad de la producción, auditoría y soporte.
La evidencia más sólida es el uso pago repetido con una economía de entrega estable. El más débil es una expresión de interés sin firmar. La valoración debe utilizar una escalera de evidencia del cliente en lugar de colocar todos los logotipos en el valor del canal.
10 Valorar el talento y el conocimiento científico
Los equipos de software cuántico pueden combinar físicos teóricos, matemáticos aplicados, ingenieros compiladores, científicos de dominio, ingenieros de software, líderes de productos y científicos de clientes. El comprador debe asignar cada capacidad crítica a productos e hitos. Los títulos organizacionales por sí solos no revelan dependencia técnica.
El objetivo puede confiar en los fundadores para el diseño de algoritmos, la credibilidad del cliente y el ajuste manual. Los ingenieros clave pueden ser propietarios del compilador o del sistema de implementación. Los científicos del campo pueden traducir los problemas de los clientes en formulaciones con solución. El equipo de diligencia debe identificar el conocimiento no documentado y el tiempo de reemplazo realista.
La retención debe reflejar el trabajo posterior al cierre. Los premios basados en servicios pueden respaldar la continuidad. Los premios Milestone deben utilizar resultados reproducibles y resultados aceptados por los clientes. La compensación debe evitar premiar la selección de índices de referencia o afirmaciones de desempeño no fundamentadas.
La integración debe preservar el desafío científico y la disciplina de entrega de software. El comprador debe definir el acceso al repositorio, la gobernanza de la versión, la seguridad, la autoridad de la arquitectura y la propiedad del producto. Un comprador de hardware debe evitar forzar que cada aplicación se instale en su propia plataforma antes de probar la portabilidad y el valor para el cliente.
11 Evaluar el riesgo de la cadena de suministro de software y ciberseguridad
Los productos de software cuántico heredan el riesgo del software clásico. El comprador debe revisar la identidad, el acceso privilegiado, los secretos, las dependencias, la creación de canalizaciones, la firma de paquetes, la gestión de vulnerabilidades, el registro, la respuesta y recuperación ante incidentes. Los tokens de nube y las credenciales de hardware requieren un control particular.
Las listas de materiales del software deben identificar paquetes, versiones, licencias y vulnerabilidades conocidas. Las compilaciones reproducibles y los canales de lanzamiento protegidos reducen el riesgo de que no se pueda reconstruir ni confiar en el producto adquirido. El comprador debe probar la restauración de la copia de seguridad y la capacidad de rotar todas las credenciales al momento del cierre.
Los datos experimentales y de clientes pueden ser confidenciales. Los contratos y la arquitectura deben mostrar dónde se almacenan las entradas, los circuitos, los datos de calibración y las salidas. El procesamiento transfronterizo, los controles de exportación y los requisitos sectoriales pueden afectar la integración. Las representaciones de seguridad deben probarse con registros e incidentes.
El costo de remediación pertenece al plan de valoración e integración. Un algoritmo valioso con controles de software débiles puede requerir trabajo en el repositorio, la nube y la identidad antes de poder implementarse en clientes regulados. Ese gasto no debería ocultarse en una sinergia general.
12 Costo de reposición del modelo y tiempo evitado
El costo de reemplazo debe estimar el equipo, los datos, la experimentación, el software y el tiempo transcurrido necesarios para reproducir la capacidad transferible. El gasto histórico es evidencia, pero incluye caminos fallidos y costos hundidos. El comprador debe valorar el sistema actual, la documentación y el aprendizaje que acortan una alternativa creíble.
El modelo debe separar el volumen del código de la dificultad. Un pequeño paso del compilador puede codificar conocimientos poco comunes. Un repositorio de aplicaciones grande puede contener código de integración reemplazable. Las entrevistas con expertos, el historial del repositorio y la reproducción de puntos de referencia ayudan a identificar el cuello de botella.
El tiempo ahorrado puede ser valioso cuando una hoja de ruta industrial o de hardware tiene una ventana fija. El adquirente debe comparar el tiempo de compra e integración con una construcción interna. El beneficio debe reducirse cuando los derechos clave, los clientes o el personal no puedan transferirse.
Los estándares abiertos y los marcos de código abierto pueden reducir el costo de reemplazo. También pueden ampliar el mercado y aumentar el valor de las capas propietarias complementarias. La valoración debe identificar si el foso del objetivo se fortalece o se debilita a medida que mejora la interoperabilidad.
13 Construir el modelo de ingresos
Un modelo de ingresos debería utilizar evidencia de los clientes en lugar de un pronóstico cuántico distante del mercado. Los ingresos deben segmentarse por productos, servicios, subvenciones y otras fuentes. El margen bruto debe incluir la ejecución en la nube, el acceso al hardware, la entrega especializada, el soporte y las licencias de terceros. La nómina de investigación y el desarrollo de productos deberían seguir siendo visibles.
El pronóstico debe modelar los eventos de conversión. Un piloto se convierte cuando se cumplen la aceptación, la adquisición y el presupuesto. Una suscripción se renueva cuando el producto sigue siendo útil en todo el hardware y las versiones. Un proyecto de servicios se convierte en ingreso de producto sólo cuando la entrega es repetible con menos esfuerzo personalizado.
El modelo debe incluir dependencias de hardware. Si un flujo de trabajo valioso requiere una capacidad de proveedor esperada en dos años, los ingresos deben ponderarse en probabilidad y capitalizarse con cautela. Si el objetivo obtiene ingresos hoy gracias al diagnóstico o la simulación, ese flujo de caja logrado puede respaldar el análisis convencional.
El valor terminal debe reflejar el cambio tecnológico y la competencia. Un largo período de crecimiento sin el respaldo de cohortes de clientes crea una precisión falsa. El comité de transacciones debe comparar el enfoque de ingresos con el costo de reposición y el valor del escenario.
14 Utilice un cuadro de mando ajustado a la portabilidad
El cuadro de mando debe cubrir la evidencia del algoritmo, la portabilidad, la calidad de referencia, la propiedad intelectual, los datos, los resultados de los clientes, la calidad de los ingresos, el equipo, la seguridad y la pista. Cada puntuación debe vincularse a la evidencia y a una implicación de valoración. Una puntuación científica alta no puede reparar la falta de propiedad o la débil aceptación del cliente.
La portabilidad debe recibir subpuntuaciones separadas para fuente, semántica, compilación, ejecución, rendimiento y continuidad comercial. El comprador deberá identificar el nivel mínimo exigido por la tesis de adquisición. Un comprador de hardware puede aceptar una dependencia que fortalezca su plataforma. Un comprador neutral de nube puede requerir una amplia portabilidad del rendimiento.
El cuadro de mando debe mostrar concentración. Un objetivo puede recibir altas calificaciones promedio dependiendo de un proveedor, científico o cliente. Por lo tanto, los fallos de activación deben informarse por separado de las puntuaciones ponderadas. El tribunal debe saber qué cuestión puede invalidar la tesis.
Las puntuaciones deberían cambiar después de las pruebas confirmatorias. El modelo debe preservar la evidencia y la justificación de cada actualización. Esto respalda la negociación de precios y la responsabilidad posterior al cierre.
15 Aprenda de las combinaciones reveladas
La formación de Quantinuum combinó Honeywell Quantum Solutions con Cambridge Quantum. Los anuncios públicos describían una empresa integrada de hardware y software y soporte de fabricación a largo plazo. La combinación ilustra una tesis de integración vertical, incluida la capacidad de desarrollar software a través de plataformas mientras se controla una hoja de ruta de hardware.
La adquisición de Quantum Benchmark por parte de Keysight agregó software de diagnóstico de errores, supresión de errores y validación de rendimiento a una cartera cuántica más amplia. La justificación revelada ilustra el valor del software que mide y mejora el hardware. No revela una valoración de algoritmo independiente.
Quantum Machines adquirió QDevil para ampliar la capacidad de control cuántico desde el nivel de puerta hasta el qubit. SandboxAQ adquirió Good Chemistry para agregar tecnología, clientes y talento de química computacional. Estas transacciones ilustran las tesis de la pila de control y de la aplicación de dominio.
Los ejemplos no deben tratarse como comparables directos sin alineación de precios, ingresos, derechos y pruebas. Son útiles para identificar rutas estratégicas de valor: integración vertical, validación, control, flujo de trabajo de dominio, talento y acceso de clientes. El objetivo debe asignarse a la ruta respaldada por su evidencia.
16 Construya la valoración hipotética
El ejemplo trabajado utiliza un objetivo de software cuántico totalmente hipotético. Informa USD 18 million de ingresos anuales: USD 11 million ingresos recurrentes por productos, USD 4 million servicios y USD 3 million subvenciones y otros ingresos. Tiene USD 96 million de efectivo sin restricciones y USD 38 million de uso de efectivo anual. Estos montos no representan una empresa observada.
El valor empresarial central es USD 420 million. Asigna USD 105 million a algoritmos y aplicaciones validados, USD 90 million a activos de compilación y orquestación, USD 60 million a relaciones y contratos con clientes, USD 45 million a datos y flujos de trabajo propietarios, USD 70 million a equipos y conocimientos, y USD 50 million a opciones de hoja de ruta. Cada valor es un supuesto de gestión.
Cuatro escenarios prueban la portabilidad. Un caso restringido en el que el algoritmo principal permanece vinculado a un proveedor tiene un valor de USD 140 million y una probabilidad del 25 por ciento. Un caso de origen portátil pero de rendimiento variable tiene un valor de USD 360 million y una probabilidad del 40 por ciento. Un producto portátil de alto rendimiento con clientes habituales tiene un valor de USD 820 million y una probabilidad del 27 por ciento. Una plataforma de categoría con amplio acceso a hardware tiene un valor de USD 1.80 billion y una probabilidad del 8 por ciento. El valor ilustrativo ponderado por probabilidad es USD 508.4 million antes de integración, financiación y dilución.
La diferencia entre el valor central asignado y el valor del escenario ponderado por probabilidad expone supuestos. Un comprador debe ajustarse al costo de integración, la retención, el consentimiento del cliente, los contratos de hardware y la financiación. La consideración contingente puede alinear el pago con las pruebas de portabilidad y la retención de clientes.
17 Estructurar la consideración en torno a la evidencia
La contraprestación inicial puede pagar por el código controlado, los derechos, el flujo de caja y la capacidad transferible. Los pagos diferidos pueden depender de una construcción limpia, un punto de referencia de múltiples objetivos retenido, la retención de clientes o el lanzamiento de un producto aceptado. Los premios de retención deberían recompensar el servicio y la transferencia de conocimientos.
Los hitos deben especificar objetivos, versiones, cargas de trabajo, líneas de base, métricas y revisión independiente. El requisito general de que el software sea independiente del hardware genera controversia. Un mejor hito establece que las cargas de trabajo definidas se compilan y ejecutan según los objetivos acordados y al mismo tiempo cumplen con los umbrales de calidad, tiempo y costo de la solución.
El acuerdo debe dar cabida a los cambios técnicos. El nuevo hardware puede reemplazar un objetivo original. Las reglas de sustitución deben preservar la equivalencia económica e impedir que cualquiera de las partes elija una prueba artificialmente fácil o imposible. Los asesores calificados deben abordar las consecuencias contables, fiscales, laborales y de valores.
El comprador también debe proteger los datos y la continuidad del cliente. Los consentimientos, los servicios de transición, el acceso a la nube y la corrección de la seguridad pueden ser condiciones o convenios de cierre. Un depósito en garantía puede abordar las brechas de derechos identificadas. Cada protección debe corresponderse con un riesgo de movimiento de valor.
18 Planifica los primeros cien días
Los primeros treinta días deberían proteger los repositorios, las credenciales, las cuentas en la nube, los datos de los clientes y los canales de lanzamiento. El comprador debe confirmar el personal crítico, congelar las bases de evidencia y preservar el acceso de los proveedores. Las comunicaciones con los clientes deben explicar la continuidad sin hacer promesas de desempeño no respaldadas.
Los días treinta a sesenta deberían reproducir compilaciones, volver a ejecutar puntos de referencia clave, mapear la arquitectura del producto y validar las obligaciones del cliente. El equipo de integración debería separar los servicios compartidos del trabajo científico protegido. Una hoja de ruta combinada debería identificar qué plataformas siguen siendo compatibles y por qué.
Los días sesenta a cien deberían racionalizar las herramientas superpuestas, aprobar la matriz de productos y hardware, remediar la seguridad y probar la transferencia de conocimientos. Los líderes comerciales deben revisar los planes de precios, soporte y renovación. Las finanzas deben conciliar el gasto en integración y el progreso de los hitos con el caso de inversión.
La junta directiva debería recibir un informe sobre la realización del valor. Debe mostrar las sinergias logradas, los clientes preservados, la evidencia de portabilidad, el uso del efectivo, los riesgos y las próximas decisiones. El aprendizaje técnico debería actualizar los supuestos de valoración en lugar de informarse únicamente como actividad.
Conclusión
El valor del software Quantum no lo establece una etiqueta independiente del hardware. Depende de hasta qué punto los algoritmos, los compiladores, los flujos de trabajo y los resultados de los clientes sobreviven a un cambio en el entorno de ejecución. La traducción del código fuente, la compilación exitosa y el desempeño comercial equivalente son estados de evidencia diferentes.
Un adquirente debe crear una escalera de evidencia algorítmica, un gráfico de dependencia, una matriz de portabilidad, un plan de referencia y una cohorte de clientes. Debe reproducir compilaciones, controlar las funciones del proveedor, medir la calidad y el tiempo de solución, confirmar los derechos y conciliar el efectivo del cliente. Los activos obtenidos deben separarse del valor de la hoja de ruta condicional.
Las representaciones y estándares abiertos pueden reducir el costo de cambio y al mismo tiempo exponer los límites de capacidad específicos del objetivo. Las combinaciones estratégicas muestran que el software puede crear valor a través de la integración vertical, el diagnóstico, el control y las aplicaciones de dominio. El valor de un objetivo específico aún requiere evidencia específica de la transacción.
Las juntas pueden utilizar este marco para decidir si adquirir, invertir, otorgar licencias, asociarse o construir. Cada componente de valor material debe apuntar a derechos controlados, desempeño reproducible, resultados aceptados por el cliente o un supuesto de gestión establecido explícitamente. La consideración debe moverse cuando esa evidencia cambie.
Apéndice A Protocolo de prueba de portabilidad
El protocolo debe congelar la fuente, las dependencias, las versiones del compilador, los perfiles de destino, los datos, las semillas y los criterios de aceptación. Debe incluir un objetivo principal, una alternativa creíble y un simulador o emulador. El objetivo debe construir desde un entorno limpio utilizando infraestructura y credenciales documentadas.
Cada ejecución debe registrar el tiempo de compilación, el ancho y la profundidad del circuito, las operaciones nativas, los disparos, el tiempo de cola y de ejecución, el posprocesamiento clásico, los reintentos, el costo total y la calidad de la solución. Las exclusiones y ejecuciones fallidas deben permanecer en el registro. Una implementación básica debe utilizar el mismo acceso y configuración.
El informe debe clasificar fuente, semántica, compilación, ejecución, rendimiento y portabilidad comercial. Debe indicar qué cambios fueron necesarios y si forman ramas de productos mantenidas. Los revisores independientes deberían tener suficiente acceso para reproducir la conclusión.
Apéndice B Pruebas de clientes e ingresos
El cronograma del cliente debe identificar la contraparte legal, el producto, la carga de trabajo, el proveedor de hardware, el plazo, el valor comprometido, los servicios, la aceptación, la facturación, el efectivo, la renovación y el cambio de control. La financiación y las subvenciones para la investigación deben separarse de los ingresos recurrentes por productos.
El análisis de cohorte debe mostrar los ingresos recurrentes de apertura, los nuevos clientes, la expansión, la contracción, la deserción y el cierre de los ingresos recurrentes. Debe conciliarse con los registros contables. La cartera de proyectos debe permanecer fuera de los ingresos contratados y debe identificar las puertas de adquisiciones, técnicas y presupuestarias.
Las referencias de los clientes deben confirmar la decisión respaldada, la línea de base, el resultado aceptado, el esfuerzo del especialista y la intención futura. El comprador debe comprobar si la relación sobrevive a un cambio de hardware o de propiedad.
Apéndice C Sala de datos de valoración
La sala de datos técnicos debe contener repositorios, instrucciones de construcción, bloqueos de dependencia, listas de materiales de software, licencias, acuerdos de colaborador, patentes, derechos de datos, puntos de referencia, registros de ejecución sin procesar, configuraciones de objetivos, registros de seguridad e historial de incidentes. Debe incluir experimentos negativos y fallidos.
Los registros comerciales deben incluir contratos, declaraciones de trabajo, subvenciones, facturas, recibos de efectivo, registros de soporte y uso. Los registros financieros deben conciliar las categorías de ingresos, el margen bruto, el gasto en investigación, el efectivo, los compromisos y el uso mensual de efectivo.
El informe de diligencia debe identificar lo que se reprodujo, lo que se tomó como muestra, lo que no estuvo disponible o lo que se discutió. Cada brecha no resuelta debería aparecer en el precio, la estructura, el presupuesto de integración o las condiciones de aprobación.
Apéndice D Libro mayor de valores de integración
El libro de valores de integración debe distinguir ingresos, costos, capital y efectos estratégicos. Los efectos en los ingresos pueden incluir retención de clientes, ventas cruzadas, acceso a nuevas plataformas y una conversión más rápida de las pruebas piloto. Los efectos en los costos pueden incluir la eliminación de infraestructura duplicada, el apalancamiento en adquisiciones y un menor gasto en licencias externas. Los efectos capitales incluyen evitar el desarrollo interno y reducir el tiempo hasta el próximo lanzamiento del producto. Los efectos estratégicos incluyen el control de un compilador, un flujo de trabajo, un activo de datos o una interfaz de cliente críticos.
Cada elemento debe tener una línea de base, un propietario responsable, un calendario, un gasto requerido y una fuente de evidencia. Se debe reducir una estimación de sinergia bruta por desgaste de clientes, interrupción de productos, premios de retención, migración a la nube, corrección de seguridad, soporte de plataforma duplicada e impuestos. Los beneficios que dependen del hardware futuro deben ponderarse en probabilidad y mostrarse por separado de las acciones a corto plazo.
El libro mayor debe evitar la doble contabilización. La portabilidad del algoritmo puede respaldar la retención de clientes y reducir el costo de reconstrucción, pero el mismo beneficio no debería aparecer en ambas líneas sin una conciliación. El comprador también debe distinguir el valor transferido desde otra unidad de negocio del valor creado para el grupo combinado. Trasladar los costos de la nube o de ingeniería a un presupuesto central no crea en sí mismo valor empresarial.
Los informes posteriores al cierre deben comparar el valor realizado con el caso aprobado. Las métricas técnicas deben conectarse con los resultados comerciales. Un punto de referencia exitoso para múltiples objetivos tiene un valor de transacción limitado hasta que reduce el costo de soporte, retiene a un cliente, expande la distribución o desbloquea un producto. La renovación de un cliente debe atribuirse con cuidado cuando también depende de las ventas, el progreso del hardware o los precios.
La junta debe revisar el libro mayor a intervalos definidos y revisar el caso de inversión cuando cambie la evidencia. El valor no alcanzado debería desencadenar una decisión sobre producto, capital o integración. El objetivo es preservar una conexión rastreable entre la tesis de adquisición, la evidencia técnica, el efectivo y la ejecución responsable.
Apéndice E Cifras y tablas de decisión
Secuencia propuesta; Cada etapa requiere un registro reproducible y una prueba de aceptación definida.
Supuestos de gestión totalmente hipotéticos; Score combina calidad, tiempo y costo de la solución normalizada.
Supuestos de gestión totalmente hipotéticos; USD millones.
Supuestos de gestión totalmente hipotéticos; USD millones.
Supuestos de gestión totalmente hipotéticos; USD millones.
| Capa | Prueba | Fallo común | Uso de valoración |
|---|---|---|---|
| Fuente | El código se traduce o se expresa a través de un lenguaje compartido. | La sintaxis se mueve mientras las dependencias permanecen | Evidencia de transferibilidad limitada |
| Semántico | La intención matemática sigue siendo equivalente | Las restricciones de destino cambian el método. | Ajuste de evidencia algorítmica |
| Compilación | El programa desciende a la pila de destino. | Funciones de control, puertas o tiempo de ejecución no compatibles | Costo de reorientación |
| Ejecución | El flujo de trabajo completo se ejecuta en condiciones compatibles | Servicio de proveedor oculto o intervención manual. | Prueba de capacidad lograda |
| Actuación | La calidad, el tiempo y el coste se mantienen dentro del umbral | La producción equivalente se vuelve antieconómica | Valor del producto y de la opción |
| Comercial | El cliente acepta, paga y renueva | El cambio de hardware o de propietario interrumpe la adopción | Relación y valor de los ingresos. |
Jerarquía propuesta; cada capa requiere su propia evidencia.
| Escenario | Registro requerido | cheque independiente | Tratamiento de valoración |
|---|---|---|---|
| Reclamación matemática | Problema, supuestos y criterio de corrección. | Revisión de expertos | Sólo opción de investigación |
| Simulación reproducible | Código, datos, semillas y línea base clásica. | Repetición en un entorno limpio | Conocimiento y valor del código |
| Compilación de objetivos | Registros del compilador, perfil, circuito y recursos. | Repetir compilación | Valor de implementación condicional |
| Ejecución de hardware | Trabajos, calibración, disparos, tiempo, costo y producción. | Carrera retenida | Evidencia técnica conseguida |
| Rendimiento multiobjetivo | Objetivos comparables y umbrales de aceptación | Punto de referencia independiente | Aumento de la portabilidad |
| Aceptación del cliente | Contrato, entrega, factura y efectivo. | Conciliación de clientes y contabilidad. | Valor comercial |
Secuencia propuesta de diligencia de transacción.
| Capa | Evidencia | Riesgo de dependencia | Implicación de valor |
|---|---|---|---|
| Idiomas y bibliotecas | Repositorios, versiones, licencias y pruebas | Cambios importantes y componentes sin propietario. | Costo de mantenimiento y remediación |
| Representación intermedia | Perfiles, transformaciones y validación. | Semántica o características de destino no admitidas | Ajuste de portabilidad |
| Compilador y pases. | Construcción, puntos de referencia, propiedad y documentación. | Optimización específica del objetivo | Activo logrado o costo de retargeting |
| Hardware y nube | Contratos, acceso, colas, precios y características | Concentración de proveedores y cambio de control | Rendimiento y ajuste del cliente. |
| Flujo de trabajo clásico | Datos, HPC, AI, posprocesamiento y orquestación | La afirmación cuántica depende de los activos clásicos | Asignar valor al sistema completo |
Propuesta de revisión mínima de la cadena de ejecución del software.
| Componente de valor | Monto ilustrativo | Puerta de evidencia | Tratamiento de desventajas |
|---|---|---|---|
| Algoritmos y aplicaciones validados | USD 105 million | Puntos de referencia y derechos reproducibles | Retención de portabilidad |
| Compilador y orquestación | USD 90 million | Construcción limpia, evidencia objetivo y propiedad | Reserva de remediación |
| Relaciones y contratos con los clientes. | USD 60 million | Aceptación, renovación, efectivo y consentimiento | Ajuste de retención |
| Datos y flujos de trabajo propietarios | USD 45 million | Procedencia, derechos de transferencia y aportación | Deducción de derechos |
| Equipo y know-how | USD 70 million | Retención de roles críticos y transferencia de conocimientos | Retención basada en servicios |
| Opciones de hoja de ruta | USD 50 million | Portabilidad financiada e hitos del cliente | Consideración contingente |
Supuestos de gestión totalmente hipotéticos; datos no observados de la empresa o de la transacción.
| Evidencia | lo que soporta | Limitación | Uso de valoración |
|---|---|---|---|
| Colaboración en investigación | Acceso y compromiso técnico | Puede carecer de presupuesto recurrente o aceptación. | evidencia de relación |
| Beca o premio | Alcance financiado y apoyo a las políticas | Uso restringido y recurrencia limitada | Efectivo contratado con condiciones |
| piloto pagado | Presupuesto del cliente y experimento definido. | El trabajo personalizado puede no escalar | Conversión ajustada por probabilidad |
| Entrega de producto aceptado | Desempeño frente a criterios acordados | No establece renovación | Valor del contrato y entrega |
| Repetir uso pago | Presupuesto continuo y relevancia operativa | Puede seguir dependiendo del proveedor | Pruebas de ingresos más sólidas |
Clasificación propuesta para la diligencia tributaria.
| Medida | Monto ilustrativo | Pregunta de diligencia | Consecuencia de valoración |
|---|---|---|---|
| Ingresos recurrentes por productos | USD 11 million | Renovación, margen y portabilidad | Apoyo a los ingresos |
| Ingresos por servicios | USD 4 million | Esfuerzo del fundador y repetibilidad. | Ajuste de servicios |
| Subvenciones y otros ingresos | USD 3 million | Restricciones y recurrencia | Separado del producto múltiple |
| Efectivo sin restricciones | USD 96 million | Disponibilidad y compromisos | Conciliación del valor del capital |
| Uso anual de efectivo | USD 38 million | Próxima puerta de pruebas y plazo de financiación | Ajuste de pista y dilución. |
Supuestos de gestión totalmente hipotéticos; USD millones.
| Área de decisión | Evidencia verde | Condición ámbar | Condición roja |
|---|---|---|---|
| Portabilidad | Las cargas de trabajo retenidas cumplen con los umbrales de calidad, tiempo y costo en los objetivos acordados. | Portabilidad de origen y ejecución con variación de rendimiento. | Afirmación de marketing sin evidencia objetivo reproducible |
| Derechos | Código, datos, licencias y derechos de colaborador confirmados | Remediación acotada con costo y fecha | Capacidad crítica sin dueño o intransferible |
| Clientes | Aceptación pagada, renovación y conciliación de efectivo. | Investigación piloto o financiada con plan de conversión. | Logotipos o canalizaciones tratados como ingresos recurrentes |
| Equipo y seguridad | Se mantienen roles críticos; construcción limpia y transferencia de acceso aprobada | Plan documentado de remediación y retención. | Se requieren credenciales de fundador o cadena de suministro insegura |
| Valuación | Activos obtenidos y opciones condicionales separadas | Rango de escenarios amplio pero explícito | Las previsiones de mercado sustituyen a la evidencia |
Marco de decisión propuesto.
Fuentes
- Consorcio de Desarrollo Económico Cuántico, Puntos de referencia de rendimiento orientados a aplicaciones para la computación cuántica. Lea la fuente principal
- Consorcio de Desarrollo Económico Cuántico, Exploración de algoritmos cuánticos utilizando puntos de referencia de rendimiento orientados a aplicaciones, 2024. Lea la fuente principal
- Consorcio de Desarrollo Económico Cuántico, Comité Asesor Técnico de Estándares y Métricas de Desempeño. Lea la fuente principal
- Microsoft Azure Quantum, Representación Intermedia Cuántica. Lea la fuente principal
- Microsoft Azure Quantum, perfiles de destino QIR en el kit de desarrollo Quantum, 2026. Lea la fuente principal
- Microsoft Azure Quantum, Simuladores cuánticos backend de proveedores cuánticos, 2026. Lea la fuente principal
- OpenQASM, especificación en vivo OpenQASM 3. Lea la fuente principal
- Cross y colaboradores, OpenQASM 3: un lenguaje ensamblador cuántico más amplio y profundo, ACM Transactions on Quantum Computing, 2022. Lea la fuente principal
- Amazon Web Services, soporte para OpenQASM en diferentes dispositivos Amazon Braket. Lea la fuente principal
- Amazon Web Services, funciones OpenQASM compatibles con Amazon Braket. Lea la fuente principal
- IBM Quantum, documentación del transpilador Qiskit. Lea la fuente principal
- IBM Quantum, Backend y documentación de destino. Lea la fuente principal
- Google Quantum AI, documentación de Cirq. Lea la fuente principal
- NVIDIA, documentación CUDA-Q. Lea la fuente principal
- NVIDIA, documentación del SDK cuQuantum, 2026. Lea la fuente principal
- Xanadú, documentación de PennyLane. Lea la fuente principal
- Fundación Linux, Alianza QIR. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, Ciencia de la información cuántica. Lea la fuente principal
- ISO, ISO/IEC 4879:2024 Tecnologías cuánticas; Vocabulario. Lea la fuente principal
- Honeywell, Honeywell Quantum Solutions y Cambridge Quantum completan la combinación de negocios, 2021. Lea la fuente principal
- Quantinuum, Presentación de Quantinuum, 2021. Lea la fuente principal
- Quantinuum, Declaración de registro presentada ante la Comisión de Bolsa y Valores de Estados Unidos, 2026. Lea la fuente principal
- Keysight Technologies, Keysight Technologies adquiere Quantum Benchmark, 2021. Lea la fuente principal
- Quantum Machines, Quantum Machines adquiere QDevil, 2022. Lea la fuente principal
- SandboxAQ, SandboxAQ adquiere Good Chemistry, 2024. Lea la fuente principal
- Fundación NIIF, NIIF 3 Combinaciones de Negocios. Lea la fuente principal
- Fundación NIIF, NIIF 13 Medición del Valor Razonable. Lea la fuente principal
- Fundación IFRS, NIC 38 Activos Intangibles. Lea la fuente principal
- Consejo de Normas Internacionales de Valoración, Normas Internacionales de Valoración. Lea la fuente principal
- Comisión de Bolsa y Valores de Estados Unidos, Manual de informes financieros. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, Marco de desarrollo de software seguro SP 800-218. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, Marco de Ciberseguridad 2.0. Lea la fuente principal
