Diligencia debida de capital de crecimiento nativa de AI: velocidad de funcionalidades, retención y dependencia del modelo

1. Definir la decisión de inversión

La diligencia debida de capital de crecimiento debería comenzar por la decisión que debe tomar el comité de inversiones. El mandato debería especificar el instrumento propuesto, los fondos obtenidos, la participación, los derechos de gobernanza, el período de tenencia previsto, el marco de rentabilidad y las condiciones materiales. Una instrucción amplia para evaluar una empresa AI puede generar una actividad extensa sin resolver las cuestiones de precio, estructura y riesgo que rigen el despliegue de capital.

El marco de decisión debería identificar la tesis operativa. La dirección puede argumentar que los lanzamientos rápidos de productos aumentan la adopción, que la adopción genera resultados recurrentes para los clientes, que esos resultados respaldan la retención y la expansión, y que la escala mejora el margen de contribución. Cada eslabón requiere una definición, una fuente y un período de observación. Un resultado sólido en un eslabón no demuestra el resto de la cadena.

El comité debería aprobar el estándar de evidencia antes de que se acelere la diligencia debida. El estándar debería distinguir entre registros verificados, manifestaciones de la dirección, cálculos contrastados, evidencia de terceros y escenarios hipotéticos. La información material faltante debería permanecer visible. El inversor también debería decidir qué hallazgos pueden cambiar la valoración, los términos del instrumento, la gobernanza, la financiación por etapas, las condiciones o la decisión de detenerse.

2. Construir la arquitectura integrada de diligencia debida

Los flujos de trabajo comerciales, de producto, técnicos, financieros y de gobernanza deberían utilizar un único registro de afirmaciones. Los informes separados pueden describir el mismo hecho de forma diferente, aplicar períodos incoherentes o pasar por alto una dependencia que atraviesa funciones. La arquitectura integrada asigna cada afirmación material a un responsable, una fuente, una prueba, un revisor y una consecuencia de inversión.

La arquitectura debería abarcar el propósito del producto, los segmentos de clientes, el historial de lanzamientos, el éxito en tareas, la adopción, la retención, el precio, el reconocimiento de ingresos, la asignación de costes, las dependencias de modelos y de la nube, los derechos sobre los datos, la seguridad, la regulación, la organización, la previsión, la necesidad de capital y la tabla de capitalización. También debería preservar la relación entre estos elementos. Una nueva funcionalidad puede mejorar la adopción al tiempo que aumenta el coste de inferencia, el trabajo de implementación o la concentración de modelos.

El Marco de Gestión de Riesgos AI de NIST conecta las prácticas organizativas con el mapeo, la medición, la gestión y la gobernanza a lo largo del ciclo de vida de AI [1]. Su núcleo exige pruebas, evaluación, verificación y validación documentadas, así como monitorización en producción en condiciones similares al despliegue [2]. Esos principios respaldan un sistema de evidencia para la inversión, aunque el inversor debe adaptarlos a la operación y a la empresa.

Cada etapa requiere una población, una fuente, un periodo y una revisión definidos antes de respaldar la siguiente conclusión.

3. Crear el registro de evidencia

El registro de evidencia es el registro de la operación para las afirmaciones materiales. Cada entrada debe indicar la afirmación, la definición de la métrica, la población, el periodo, el sistema de origen, el método de extracción, el cálculo, el responsable, el revisor, la versión, la limitación y la posible respuesta de inversión. El registro debe enlazar con los archivos de origen manteniendo los controles de acceso y confidencialidad.

Los cuadros de mando de la dirección son puntos de partida útiles. Pueden cambiar definiciones, excluir actividad fallida, combinar tráfico de producción y de pruebas, o presentar una instantánea actual junto a una previsión histórica. El equipo de diligencia debida debe conciliar las métricas seleccionadas con los sistemas de origen, los contratos y los registros contables. La reejecución debería centrarse en las afirmaciones que impulsan la valoración, la protección a la baja o la necesidad de capital.

El registro de evidencia debe conservar la evidencia adversa. Las evaluaciones fallidas, las cohortes con abandono, los sobrecostes, las quejas de clientes y los derechos no resueltos pueden explicar el abanico de resultados con mayor eficacia que una sala de datos impecable. Una excepción debe tener un responsable, relevancia financiera, acción propuesta y fecha de decisión. Eliminarla tras una solución provisional suprime la pista de auditoría.

Tabla 1. Campos principales del registro de evidencia

Un campo completado requiere evidencia de la fuente y una revisión proporcional a su importancia para la inversión.

4. Definir el alcance del producto nativo de AI

El equipo de diligencia debida debe determinar qué hace que la empresa sea nativa de AI en términos operativos. El producto puede entrenar modelos propietarios, ajustar modelos de terceros, orquestar múltiples modelos, aplicar lógica de recuperación y de flujo de trabajo, proporcionar infraestructura o integrar servicios externos de AI dentro de una aplicación más amplia. Estas arquitecturas generan distintas exposiciones en materia de propiedad intelectual, costes, fiabilidad y cambio de proveedor.

El mapa de producto debe identificar cada flujo de trabajo de cara al cliente, la ruta del modelo y de los datos, la intervención humana, el entorno de producción y la promesa comercial. Una sola empresa puede contener varias arquitecturas. Un flujo de trabajo puede usar un clasificador propietario, otro puede enrutar hacia un proveedor de modelos fundacionales y un tercero puede requerir revisión de expertos. El margen y la fiabilidad agregados pueden ocultar esas diferencias.

El alcance también afecta a la comparabilidad. Una empresa cuya economía depende de la inferencia de terceros no debería evaluarse únicamente como software tradicional. Un despliegue con un fuerte componente de servicios no debería presentarse como ingresos recurrentes de autoservicio sin evidencia. El inversor debería usar el modelo operativo real, los derechos contractuales y los factores de coste en lugar de una etiqueta.

5. Definir un lanzamiento controlado

La velocidad de las funcionalidades requiere una unidad de análisis estable. Un lanzamiento debería representar un cambio en producción que llegue a una población de clientes elegible y pueda asociarse con un comportamiento o unos resultados definidos. Los commits de código, los experimentos, las demostraciones internas y los anuncios de marketing son eventos separados. Contarlos juntos recompensa la actividad sin poner a prueba el valor para el cliente.

El registro de lanzamiento debería incluir el usuario previsto, el problema, el responsable, la aprobación, la fecha de despliegue, la población elegible, la lógica de exposición, el plan de reversión, el resultado de la evaluación, el historial de incidentes y la hipótesis comercial. Los cambios sustanciales en modelo, prompt, recuperación, datos y políticas deberían incluirse porque pueden alterar el comportamiento del producto sin un cambio visible en la interfaz.

La velocidad debería evaluarse junto con la calidad y la reversibilidad. Los lanzamientos frecuentes pueden demostrar capacidad de aprendizaje cuando la telemetría, las pruebas y la reversión son sólidas. También pueden crear fragmentación, carga de soporte y riesgo de fiabilidad. El inversor debería medir la proporción de lanzamientos que llegan a producción estable, alcanzan su umbral de aceptación y siguen recibiendo soporte después de la ventana de observación.

6. Medir la velocidad de las funcionalidades

Las medidas útiles de velocidad incluyen el tiempo desde la aprobación del problema hasta producción, la frecuencia de despliegue, la aceptación de lanzamientos, la tasa de reversión, el escape de defectos, la cobertura de evaluación y el tiempo de remediación. El denominador debería ser explícito. La mediana del tiempo hasta producción de los lanzamientos aceptados puede comunicar más que un promedio distorsionado por unas pocas iniciativas abandonadas.

El equipo debería segmentar la velocidad por área de producto, tipo de cliente y clase de cambio. Un ajuste de interfaz de usuario, una migración de modelo y un flujo de trabajo regulado requieren pruebas y tolerancias al riesgo distintas. Las comparaciones entre periodos deberían explicar los cambios en tamaño del equipo, arquitectura, mezcla de clientes y política de lanzamientos.

La velocidad puede compararse con el plan de inversión. Si el crecimiento exige una secuencia definida de controles empresariales, integraciones o capacidades de flujo de trabajo, la diligencia debida debería comprobar si el rendimiento histórico respalda esa secuencia. La previsión debería incluir descubrimiento, revisión de seguridad, aceptación del cliente y esfuerzo de despliegue. Las estimaciones de ingeniería por sí solas no establecen la disponibilidad comercial.

7. Conectar los lanzamientos con las cohortes de adopción

Cada lanzamiento relevante debería tener una cohorte elegible y una cohorte expuesta. La elegibilidad responde a quién podría usar la funcionalidad; la exposición responde a quién la recibió o descubrió realmente. La adopción debería distinguir entonces entre primer uso, uso significativo, uso repetido y uso exitoso. Una población elegible grande con exposición limitada puede indicar fricción en la distribución más que rechazo del producto.

Las cohortes deberían conservar la fecha de inicio, las características de la cuenta, el contrato, el segmento, la geografía y la línea base relevante. El equipo debería comparar a los usuarios expuestos con una línea base previa al lanzamiento adecuada o un control cuando sea factible. La analítica de producto puede mostrar asociación; las afirmaciones causales requieren un diseño más sólido y limitaciones declaradas.

Las curvas de adopción deberían seguirse durante el tiempo suficiente para distinguir la novedad de un flujo de trabajo recurrente. Una funcionalidad usada una sola vez durante la incorporación puede reducir el tiempo de implementación sin convertirse en un flujo de trabajo diario. Ese resultado aún puede crear valor, pero debería entrar en la tesis de ingresos y retención mediante el mecanismo correcto.

8. Definir el éxito de la tarea y la aceptación del cliente

Los productos AI requieren definiciones de éxito específicas del flujo de trabajo. Una respuesta puede entregarse dentro del objetivo de latencia y aun así ser inexacta, insegura o inutilizable. La definición puede combinar finalización, calidad, fiabilidad, latencia, escalado, esfuerzo de revisión y aceptación del cliente. El inversor debería entender quién fija el umbral y cómo se relaciona con la promesa contractual.

La evidencia de evaluación debería abarcar condiciones similares a las de producción, en consonancia con el énfasis de NIST en las pruebas documentadas y la monitorización de producción [2]. Las muestras deberían representar poblaciones de clientes relevantes y modos de fallo. Los resultados de demostraciones curadas deberían separarse del rendimiento en vivo. La evaluación humana debería documentar instrucciones, revisores, desacuerdos y escalado.

El equipo debería rastrear los fallos hasta sus consecuencias para el cliente y económicas. Un error de baja gravedad puede generar un coste limitado; un fallo poco frecuente en un flujo de trabajo de alto riesgo puede limitar el acceso al mercado o exigir una revisión costosa. La precisión agregada puede ocultar esa distribución. El modelo de inversión debería reflejar el caso de uso real y los controles residuales.

9. Construya el puente de resultados del cliente

El puente de resultados del cliente conecta la actividad del producto con el resultado que el comprador valora. Comienza con el flujo de trabajo contratado o previsto, sigue a los usuarios elegibles a través de la exposición y el uso exitoso, y después evalúa resultados de tiempo, coste, ingresos, riesgo o calidad. El puente debe identificar cambios de confusión, como nuevos precios, apoyo a la implementación o dotación de personal del cliente.

La evidencia puede incluir datos de los sistemas del cliente, entregables aceptados, niveles de servicio, decisiones de renovación y casos prácticos documentados. Los testimonios sin una línea base aportan contexto, pero dejan la magnitud sin resolver. El inversor debe distinguir entre cálculos de la empresa, resultados confirmados por el cliente y evidencia reproducida de forma independiente.

La durabilidad de los resultados importa. Un ahorro logrado mediante un apoyo intensivo del proveedor puede no persistir a escala. El puente debe mostrar horas de soporte, esfuerzo de implementación y excepciones. Un cliente puede renovar por un paquete más amplio aunque la función AI tenga una baja adopción directa. La atribución debe mantenerse proporcionada a la evidencia.

El valor para el cliente debe estar respaldado por una línea base, una cohorte, evidencia de aceptación, esfuerzo de entrega y una limitación declarada.

10. Analice la retención por cohorte

La retención debe calcularse a partir de una población definida y una base económica. La retención de logos, la retención de ingresos brutos, la retención de ingresos netos, la retención de producto y la retención de carga de trabajo responden a preguntas diferentes. El equipo debe conciliar la medida seleccionada con los contratos y los ingresos reconocidos o facturados, según corresponda.

El análisis de lanzamiento a retención sigue cohortes expuestas a funcionalidades relevantes y compara renovación, contracción, expansión y abandono. La ventana de observación debe coincidir con los ciclos de contrato y uso. Las cohortes recientes pueden parecer saludables porque aún no han llegado a la renovación. Las cohortes maduras pueden reflejar un perfil de producto y de cliente más antiguo. Deben mostrarse ambas.

Los documentos públicos demuestran que las empresas definen y analizan la retención con cuidado. DigitalOcean informó de la retención neta en dólares junto con lanzamientos de productos nativos de AI en sus resultados de 2025 [15]. Atlassian identifica la satisfacción, los lanzamientos, el soporte, los precios, el empaquetado y las ofertas de AI entre los factores que pueden afectar la retención y la expansión [16]. Estas divulgaciones ilustran variables relevantes; no establecen un punto de referencia para otra empresa.

Tabla 2. Estructura de cohortes de lanzamiento a retención

Los valores son hipotéticos y solo ilustran la estructura del cálculo de diligencia debida.

11. Diagnosticar el abandono y la contracción

La revisión del abandono debe utilizar motivos a nivel de cuenta respaldados por evidencia. Las categorías pueden incluir encaje del producto, calidad, fiabilidad, seguridad, compras, integración, soporte, precios, presupuesto, competencia, fallo del cliente o cambio estratégico. Un único motivo principal puede resultar cómodo mientras oculta causas que interactúan.

El equipo debe comparar el motivo declarado, el historial de uso, el historial de soporte, la exposición al producto, los cambios de precio y las notas de la cuenta. Las cuentas perdidas deben segmentarse por ingresos, margen, sector, producto y dependencia. Un número reducido de pérdidas concentradas puede afectar a la previsión más que un conjunto amplio de experimentos de bajo valor.

La contracción merece un análisis separado. Los clientes pueden mantener el contrato mientras reducen puestos, cargas de trabajo o funcionalidades premium. Una funcionalidad de AI puede aumentar la interacción sin impedir una reducción presupuestaria en otra área. El puente de ingresos debe mostrar el valor inicial, el abandono, la contracción, la expansión, el precio y los efectos de tipo de cambio utilizando períodos coherentes.

12. Evaluar la calidad de la expansión

La expansión debe vincularse a un impulsor repetible. Puede provenir de más usuarios, mayor carga de trabajo, nuevos productos, precio, implementación, entidades adquiridas o consumo temporal. El inversor debe separar los compromisos contractuales del uso variable e identificar si las mismas versiones que favorecen la adopción también favorecen la expansión de pago.

Los negocios basados en consumo requieren especial atención. La optimización del producto puede reducir el consumo del cliente al tiempo que mejora el valor. Un descenso del uso no es automáticamente adverso, y el crecimiento impulsado por un uso ineficiente de tokens o de capacidad de cómputo no es automáticamente favorable. El análisis debe conectar las unidades de uso con los resultados para el cliente, el precio y el coste directo.

Debe evaluarse la concentración de la expansión. Un número reducido de grandes clientes puede generar una retención neta atractiva al tiempo que aumenta el poder de negociación y la volatilidad de las previsiones. El modelo debe mostrar la expansión por cohorte, segmento y cliente, junto con los supuestos de pipeline y la evidencia contractual. Los supuestos de venta cruzada no respaldados siguen siendo variables de escenario.

13. Conciliar la calidad de los ingresos

El análisis de la calidad de los ingresos debe conciliar los contratos, la facturación, los ingresos reconocidos, los cobros y la evidencia del producto. La NIIF 15 establece los principios para reconocer los ingresos procedentes de contratos con clientes [5]. El equipo de diligencia debida debe obtener asesoramiento contable específico de la operación y comprender las obligaciones de desempeño, la contraprestación variable, las modificaciones de contratos, las cuestiones de principal-agente y los componentes de financiación significativos cuando corresponda.

Las etiquetas de ingresos recurrentes requieren examen. Los ingresos pueden incluir implementación, desarrollo personalizado, revisión experta, formación, soporte, intermediación de marketplace o reventa en la nube. Esos flujos pueden ser comercialmente valiosos aunque presenten características diferentes de margen, capital circulante y escalabilidad. El modelo debe preservar la combinación.

El equipo debe contrastar los pedidos, los valores anualizados y las afirmaciones sobre el pipeline con los términos ejecutados y las fechas de inicio. El backlog contratado puede contener derechos de rescisión, variabilidad del consumo, condiciones de aceptación o despliegue retrasado. Los cobros deben analizarse junto a los ingresos reconocidos. Un resultado para el cliente puede ser sólido mientras los retrasos en compras o aceptación generan presión de liquidez.

14. Asignar el coste recurrente de prestación

El análisis de margen nativo de AI debe incluir los recursos necesarios para entregar el resultado contratado. El coste directo puede incluir inferencia de modelos, cómputo en la nube, almacenamiento, adquisición de datos, observabilidad, orquestación, revisión humana, implementación, soporte, créditos de servicio y licencias de terceros. La clasificación debe conciliar con el registro contable al tiempo que respalda una visión económica.

Los créditos promocionales, los compromisos mínimos y la capacidad reservada deben ser visibles. El coste declarado durante un periodo de créditos puede no representar una economía sostenible. Un compromiso puede reducir el precio unitario al tiempo que genera exposición a take-or-pay o a infrautilización. El modelo de diligencia debida debe mostrar el coste contractual y económico en los escenarios de utilización pertinentes.

El informe de Microsoft de 2025 señala costes significativos de desarrollo y operativos asociados a los modelos, servicios, plataformas e infraestructura de AI [17]. El informe de Alphabet de 2025 describe el aumento de la inversión en infraestructura técnica y de los costes operativos de las ofertas de AI [18]. Estas revelaciones específicas del emisor respaldan la necesidad de evaluar la arquitectura de costes; no son evidencia directa sobre la sociedad objetivo.

15. Calcular el margen de contribución recurrente

El margen de contribución recurrente debe utilizar una base de ingresos definida y un perímetro completo de costes directos. El equipo debería calcular vistas por cuenta, flujo de trabajo y cohorte cuando los datos lo permitan. El margen bruto declarado para la compañía puede ocultar un flujo de trabajo de AI no rentable respaldado por una línea de productos o servicios heredada rentable.

El puente debe separar precio, volumen, mezcla, tarifa del proveedor, elección de modelo, intensidad de tokens o de carga de trabajo, almacenamiento en caché, intervención humana, soporte y créditos de servicio. Las mejoras deben vincularse a cambios implementados y a una observación sostenida. Una previsión que asuma simultáneamente un menor coste del modelo y un menor esfuerzo de soporte debe explicar la evidencia operativa para ambos.

La calidad del margen también depende del valor para el cliente. Reducir la calidad del modelo, el contexto o la revisión puede disminuir el coste a la vez que perjudica los resultados y la retención. El inversor debería evaluar la frontera eficiente entre resultado, latencia, fiabilidad y coste directo. Una única métrica de optimización no puede representar las cuatro.

16. Mapear la arquitectura de dependencias

La arquitectura de dependencias identifica los sistemas, derechos y contrapartes necesarios para entregar cada flujo de trabajo material. Debe cubrir modelos fundacionales, modelos propietarios, servicios en la nube, aceleradores, datos, recuperación, almacenes vectoriales, observabilidad, seguridad, herramientas de evaluación, integraciones, especialistas y contenido con licencia. Cada dependencia debe conectarse con la promesa al cliente y el coste.

Para cada dependencia, la diligencia debida debe registrar proveedor, contrato, plazo, renovación, mecánica de precios, compromiso de volumen, nivel de servicio, uso de datos, asignación de propiedad intelectual, responsabilidad, terminación, portabilidad, alternativa, esfuerzo de cambio y limitación residual. La sustituibilidad técnica y la portabilidad contractual son cuestiones distintas.

El perfil de AI generativa del NIST destaca riesgos a lo largo del ciclo de vida de la AI generativa y fomenta acciones alineadas con los objetivos de la organización y las tolerancias al riesgo [3]. El mapa de dependencias convierte esas preocupaciones en evidencia de inversión. Debe mantenerse a nivel de flujo de trabajo porque una compañía puede tener una fuerte portabilidad en un producto y una concentración significativa en otro.

Cada capa debe evaluarse en cuanto a derechos, concentración, sustituibilidad, tiempo de cambio y exposición económica.

17. Evaluar la dependencia de modelos fundacionales

La dependencia de modelos fundacionales debe evaluarse por flujo de trabajo, no solo por el número de proveedores. Un producto puede invocar varios modelos mientras depende de un proveedor para la calidad, la latencia, las condiciones empresariales o una capacidad crítica. El equipo debe identificar el enrutamiento predeterminado, el comportamiento de respaldo, el ajuste fino, los activos de prompts y evaluación, las características específicas del proveedor y los modos de fallo.

La revisión del contrato debe cubrir acceso, precios, límites de tasa, compromisos de servicio, tratamiento de datos, derechos de entrenamiento, condiciones de los resultados, indemnizaciones, restricciones territoriales, derechos de cambio y terminación. Las pruebas técnicas deben medir el resultado y el coste con alternativas viables. Un respaldo nominal que no supere los umbrales de aceptación no proporciona una resiliencia equivalente.

La presentación regulatoria de Atlassian declara que depende de determinados modelos de AI, productos y proveedores de integración de terceros, e identifica la disponibilidad, la jurisdicción y el precio como posibles exposiciones [16]. Esta divulgación pública ilustra cuestiones relevantes para la diligencia debida de dependencias. El riesgo de la sociedad objetivo debe establecerse a partir de su propia arquitectura, contratos y pruebas.

18. Probar la sustituibilidad de los modelos

Las pruebas de sustituibilidad deberían utilizar flujos de trabajo de producción representativos y criterios de aceptación aprobados. El equipo debería comparar la calidad de los resultados, la latencia, la fiabilidad, la seguridad, la gestión del contexto, el uso de herramientas, el coste, el esfuerzo de integración y los controles operativos. Una puntuación de referencia puede respaldar el análisis, aunque deja sin resolver el rendimiento de los flujos de trabajo.

El tiempo de cambio debería incluir la contratación, la revisión de seguridad, los términos de tratamiento de datos, la implementación, la evaluación, la aprobación del cliente, el despliegue y el seguimiento. También debería incluir el tiempo necesario para reconstruir los elementos específicos del proveedor, como prompts, ajuste fino, recuperación o salvaguardas. La empresa debería identificar qué activos siguen siendo utilizables después de un cambio.

El modelo de inversión puede utilizar escenarios discretos de dependencia. Un caso base puede asumir los términos comerciales actuales; un escenario adverso puede aplicar un aumento de precio, un límite de capacidad o una degradación de la calidad; un caso de migración puede incluir costes operativos duplicados y lanzamientos retrasados. Los supuestos deberían ser trazables y evitar sugerir que todas las dependencias fallan simultáneamente sin una causa coherente.

Tabla 3. Cuadro de evaluación de dependencia y portabilidad

Las puntuaciones deben basarse en evidencia documentada y umbrales específicos de cada flujo de trabajo.

19. Revisión de las afirmaciones sobre modelos propietarios

Las afirmaciones de ventaja por modelos propietarios deben descomponerse. La empresa puede ser propietaria del código de entrenamiento, los pesos, los ajustes finos, los datos sintéticos, los conjuntos de evaluación, el enrutamiento, la recuperación, las ontologías de dominio o la retroalimentación de los flujos de trabajo. Cada activo tiene derechos, reproducibilidad y relevancia comercial diferentes. Una afirmación general de propiedad no es suficiente.

El equipo debe revisar los registros de desarrollo, las licencias, las cesiones de empleados y contratistas, la procedencia de los datos, los permisos de entrenamiento, la seguridad y la documentación del modelo. El rendimiento debe probarse frente a una referencia relevante en condiciones de producción. El análisis debe incluir el coste y el tiempo necesarios para reproducir la ventaja declarada.

La durabilidad depende del valor para el cliente y de la respuesta competitiva. Una ventaja de rendimiento medible puede erosionarse si los proveedores mejoran o si los clientes aceptan una alternativa más barata. Los activos propietarios también pueden reducir la dependencia a la vez que aumentan los requisitos de entrenamiento, talento y cómputo. El modelo de valoración debe incorporar tanto el beneficio como la obligación.

20. Revisión de los derechos y la procedencia de los datos

La diligencia debida de datos debe mapear la fuente, la propiedad, la licencia, el consentimiento, la finalidad permitida, la geografía, la retención, la transformación, el intercambio y la eliminación. El mapa debe abarcar el entrenamiento, el ajuste fino, la recuperación, la evaluación, la monitorización y la retroalimentación generada por el cliente. Los derechos que respaldan una finalidad pueden no respaldar otra.

El equipo debe comprobar si la empresa puede reproducir conjuntos de datos críticos y si el linaje sobrevive a la transformación. Los datos sintéticos deben conservar el método de generación y los controles de calidad. Los datos de los clientes deben separarse de acuerdo con el contrato y la política. La disponibilidad pública no establece por sí sola un derecho comercial sin restricciones.

El marco regulatorio AI de la Comisión Europea describe obligaciones que varían según el riesgo y el rol del sistema AI [6]. Los Principios AI de la OCDE proporcionan una referencia internacional para una gestión responsable [7]. La legislación y el contrato aplicables exigen asesoramiento cualificado; el expediente de inversión debe indicar qué asuntos se revisaron, por quién y con qué limitaciones.

21. Gobernanza de la evaluación de pruebas

La gobernanza de la evaluación debe definir quién aprueba las métricas, los conjuntos de datos, los umbrales, las versiones y las excepciones. Los equipos de desarrollo pueden preparar la evidencia, mientras que las afirmaciones materiales sobre el producto se benefician de una revisión independiente proporcional al riesgo. El registro debe conservar las pruebas fallidas y explicar cualquier cambio de umbral.

El equipo debe revisar la evaluación offline, las pruebas de red team, la revisión humana, la monitorización en producción y la aceptación del cliente. Los conjuntos de prueba deben representar poblaciones relevantes y modos de fallo conocidos. Debe evaluarse la fuga de información entre el entrenamiento y la evaluación. El versionado debe conectar el modelo, el prompt, los datos, el código y el resultado.

El RMF Core AI del NIST establece que deben documentarse los conjuntos de prueba, las métricas y las herramientas utilizados durante la evaluación, y que debe monitorizarse la funcionalidad y el comportamiento en producción [2]. El inversor debe comprobar si la evidencia de la empresa respalda sus promesas comerciales reales en lugar de una lista de verificación genérica de cumplimiento.

22. Revisión de seguridad y resiliencia

La diligencia debida en materia de seguridad debe abarcar el producto, el modelo, los datos, la infraestructura, la identidad, el acceso, los secretos, la cadena de suministro de software, la integración con el cliente, la monitorización, la respuesta a incidentes y la continuidad del negocio. El equipo debe identificar qué controles gestiona la empresa y cuáles dependen de proveedores. Las certificaciones pueden respaldar la evidencia, aunque el alcance y la eficacia operativa quedan por probar.

Los escenarios específicos de AI pueden incluir inyección de prompt, fuga de datos, uso inseguro de herramientas, extracción de modelos, fuentes de conocimiento envenenadas, automatización insegura y abuso. El análisis debe centrarse en la arquitectura del producto y en el modelo de amenazas. Un catálogo de posibles riesgos no es evidencia de exposición ni de control.

Los incidentes, los cuasiincidentes, las vulnerabilidades y las excepciones deben vincularse con la remediación, el impacto en el cliente, la notificación contractual y el coste. Las pruebas de resiliencia deben incluir la caída de dependencias y el rendimiento degradado del modelo. Los hallazgos materiales pueden afectar a las condiciones, las indemnizaciones, las reservas, el calendario de inversión o la decisión de detenerse.

23. Evaluación de la concentración en nube y cómputo

La concentración de cómputo debe evaluarse por proveedor, región, acelerador, compromiso de capacidad y carga de trabajo. Una empresa puede utilizar varios servicios en la nube y, al mismo tiempo, depender de una sola región o clase de hardware para un producto crítico. El mapa debe incluir las cargas de trabajo de despliegue, evaluación, entrenamiento, datos y continuidad del negocio.

La revisión contractual debe abarcar el precio, los descuentos, los créditos, los compromisos, la capacidad, los niveles de servicio, la ubicación de los datos, la seguridad, la terminación y el soporte a la migración. La revisión técnica debe probar la observabilidad, la portabilidad de las cargas de trabajo y la recuperación. El modelo financiero debe mostrar por separado el coste utilizado y el coste comprometido.

La presentación de CoreWeave de 2025 analiza la adopción por parte de clientes, el rendimiento, la eficiencia, las obligaciones de rendimiento pendientes y la financiación de la infraestructura AI [19]. La presentación de Oracle de 2026 describe la energía, la capacidad y las dependencias de centros de datos de terceros [20]. Estas divulgaciones sobre infraestructura ilustran condiciones aguas arriba que pueden llegar a una empresa de aplicaciones a través del precio, la disponibilidad o las condiciones de los proveedores.

24. Elaborar la sensibilidad al cómputo

La sensibilidad al cómputo debe conectar el volumen de carga de trabajo, el éxito de las tareas, la combinación de modelos, la intensidad de entrada y salida, el almacenamiento en caché, el tratamiento por lotes, el nivel de latencia, la tarifa del proveedor, los créditos y los compromisos mínimos. El modelo debe conciliar con las facturas y la telemetría de un periodo seleccionado. Después debe enlazar con el margen de contribución recurrente y la caja.

El equipo debería evitar una única medida de coste por consulta cuando las consultas varían de forma material. El coste por flujo de trabajo exitoso aceptado puede ofrecer una unidad económica más sólida, siempre que el éxito esté bien definido. El modelo también debería mostrar intentos fallidos, reintentos, revisión humana y capacidad ociosa.

El diseño de escenarios puede probar mayor volumen, tarifas de proveedor más bajas, migración de modelos, umbrales de calidad, mix de clientes y utilización de compromisos. Cada escenario debería preservar la viabilidad operativa. Un coste menor puede exigir una contrapartida en calidad; un compromiso mayor puede mejorar el precio unitario mientras aumenta el riesgo de caja.

Los valores son hipotéticos e ilustran la estructura del modelo; no constituyen una previsión ni una conclusión de valoración.

25. Evaluar la fiabilidad del producto

La fiabilidad debería definirse mediante la promesa al cliente. Las medidas pueden incluir disponibilidad, latencia, tasa de errores, finalización exitosa, escalado, recuperación, frescura de los datos y créditos de servicio. El tiempo de actividad agregado puede ocultar un flujo de trabajo AI con fallos dentro de una aplicación disponible.

El equipo debería revisar los objetivos de servicio, el rendimiento real, los incidentes, las causas raíz, la remediación y la comunicación con el cliente. El análisis a nivel de versión puede mostrar si la velocidad aumenta la frecuencia de incidentes o reduce el tiempo de recuperación. Deberían ser visibles los segmentos de clientes relevantes y los periodos punta.

La economía de la fiabilidad incluye ingresos perdidos, créditos, soporte, retrabajo, capacidad duplicada y abandono de clientes. La previsión debería incluir la inversión necesaria para sostener el crecimiento. Un historial sólido a escala limitada no demuestra el rendimiento con el volumen proyectado; el plan de capacidad y resiliencia debería explicar la transición.

26. Evaluar la organización de producto

La diligencia debida de la organización debería mapear los derechos de decisión, el liderazgo, la gestión de producto, la ingeniería, el aprendizaje automático, los datos, la seguridad, la fiabilidad, el éxito del cliente y las finanzas. El equipo debería comprobar si los responsables pueden definir resultados, instrumentar el producto, revisar la evidencia y responder a incidentes. La plantilla por sí sola no establece la capacidad.

El rendimiento de las versiones debería normalizarse por tamaño del equipo, arquitectura y clase de cambio. La dependencia de personas clave debería incluir conocimiento técnico, relaciones con clientes y derechos de aprobación. El inversor debería revisar la sucesión, la retención, los incentivos, el plan de contratación y la exposición a contratistas, respetando los requisitos laborales y de privacidad aplicables.

El plan operativo debería vincular las contrataciones con restricciones específicas. Añadir desarrolladores puede no resolver un mal descubrimiento de producto, los derechos sobre los datos o una aprobación empresarial lenta. Un rol especializado previsto debería incluir plazo, coste y control provisional. El caso de inversión debería reflejar la capacidad de ejecución disponible tras el cierre.

27. Revisar la concentración de clientes y la capacidad de referencia

La concentración de clientes debería medirse en ingresos, beneficio bruto, cobro de efectivo, carga de trabajo y evidencia de producto. Un cliente puede representar una cuota moderada de los ingresos y, al mismo tiempo, aportar una gran parte de los datos de uso exitoso o de la dirección del producto. El inversor debería comprender la concentración comercial y técnica en conjunto.

Los contratos deben revisarse en cuanto a plazo, terminación, renovación, precios, mínimos, aceptación, nivel de servicio, responsabilidad, derechos sobre datos, publicidad y cambio de control. Las llamadas de referencia requieren el consentimiento del cliente y un conjunto controlado de preguntas. El registro debe distinguir a los defensores seleccionados por la dirección de una muestra representativa.

La evidencia de referencias debe evaluar la importancia del problema, la implementación, el resultado, la fiabilidad, el soporte, las alternativas, la intención de renovación y la expansión. También debe recoger limitaciones y factores específicos del cliente. Una referencia entusiasta no puede demostrar la retención de toda la cartera. Los hallazgos deben conciliarse con los registros de uso, soporte y comerciales cuando esté permitido.

28. Analizar el mercado y la posición competitiva

La diligencia de mercado debe definir el problema del cliente, el comprador económico, el usuario, el presupuesto, el proceso de compra y las alternativas creíbles. Las empresas nativas de AI pueden competir con proveedores de software, desarrollo interno, servicios externalizados, proveedores de modelos o trabajo manual continuado. El tamaño del mercado debe basarse en flujos de trabajo direccionables y la disposición a pagar.

La evidencia competitiva debe comparar el resultado para el cliente, la calidad, la integración, la seguridad, el despliegue, el precio, el coste directo y el cambio de proveedor. El recuento de funciones puede inducir a error porque las capacidades difieren en preparación para producción y aceptación por el cliente. El equipo debe revisar los registros de victorias y derrotas, las referencias de competidores y las decisiones de renovación, preservando las limitaciones de la muestra.

La tesis de inversión debe indicar dónde reside la ventaja y cómo puede cambiar. Las mejoras de los proveedores pueden reforzar el producto o comprimir la diferenciación. Los modelos abiertos pueden reducir costes o aumentar la competencia. La regulación puede elevar las barreras y el coste de cumplimiento. Los escenarios deben conectar estas fuerzas con los resultados para el cliente, la retención y el margen.

29. Probar la fijación de precios y el empaquetado

La diligencia de precios debe vincular la unidad de cobro con el valor para el cliente y el coste de la empresa. Las estructuras por usuario, por flujo de trabajo, por resultado, por suscripción, por consumo e híbridas distribuyen el riesgo de manera diferente. El equipo debe examinar el precio de lista, el precio efectivo, los descuentos, los créditos, los mínimos, los excesos, los servicios y la mecánica de renovación por cohorte.

El empaquetado debe mostrar qué funciones impulsan la adquisición, la adopción, la expansión y la retención. Las funciones de AI ofrecidas a un precio bajo o sin precio incremental pueden respaldar una plataforma más amplia mientras aumentan el coste de alojamiento, como Atlassian describe como un riesgo en su presentación [16]. Esa declaración específica del emisor ilustra la necesidad de evaluar la economía del empaquetado del objetivo.

Los experimentos de precios deben separarse de los resultados contractuales. El inversor debe evaluar la disposición a pagar, la respuesta de compras, la elasticidad de uso y el abandono. Una previsión que asume un precio más alto y una mayor adopción debe explicar el valor para el cliente y el plan de transición. Los cambios de precios también pueden alterar los requisitos de soporte, canal y reconocimiento de ingresos.

30. Evaluar la repetibilidad de la comercialización

El análisis de comercialización debe seguir la cuenta objetivo, la oportunidad cualificada, la validación técnica, la revisión de seguridad, la aprobación comercial, la implementación, la adopción y la renovación. El tiempo de ciclo debe segmentarse por cliente y caso de uso. Los productos de AI pueden enfrentarse a largas etapas de evaluación y gobernanza incluso cuando las demostraciones son rápidas.

El equipo debe conciliar los registros de relaciones con clientes, los contratos, la telemetría del producto, los registros de implementación y los ingresos. Las etapas del pipeline deben tener criterios de salida basados en evidencia. Las vías originadas por socios, lideradas por fundadores y de autoservicio deben mostrarse por separado porque la capacidad y la conversión pueden diferir.

La repetibilidad requiere más que el crecimiento histórico. La empresa debe mostrar un problema definido, un resultado referenciable, un despliegue viable, capacidad de soporte y economía unitaria en cohortes sucesivas. La previsión debe incluir los recursos de ventas, ingeniería de soluciones, seguridad, implementación y éxito del cliente necesarios para reproducir la dinámica comercial.

31. Construir la previsión a partir de impulsores operativos

La previsión debe comenzar con cohortes de clientes e impulsores operativos. Los clientes iniciales, la captación de nuevos clientes, la activación, el uso recurrente exitoso, la renovación, la contracción, la expansión, y el calendario de precios e ingresos forman el puente comercial. La carga de trabajo, la mezcla de modelos, las tarifas de proveedores, el soporte y la implementación forman el puente de costes.

Cada supuesto debe tener una fuente, un periodo base y un responsable. La evidencia histórica puede respaldar un rango en lugar de un punto. Los cambios recientes de producto pueden carecer de datos maduros de renovación. El modelo debe indicar dónde el juicio de la dirección va más allá de la evidencia observada y debe conservar los casos alternativos.

El balance y el estado de flujos de efectivo deben seguir el modelo operativo. Los ingresos diferidos, las cuentas por cobrar, los compromisos con proveedores, el desarrollo capitalizado, los arrendamientos, la deuda, los impuestos y los costes de transacción pueden afectar a la liquidez. La previsión debe conciliarse con las políticas contables y recibir una revisión cualificada cuando proceda.

Tabla 4. Mapa de evidencia de los supuestos de la previsión

Cada supuesto debe conservar una fuente, un periodo de observación y un rango de escenarios aprobado.

32. Construir escenarios coherentes

Los escenarios deben describir estados operativos internamente coherentes. Un caso base puede asumir la aceptación actual del producto, una retención cuantificada y la contratación prevista. Un escenario favorable puede combinar una adopción más fuerte con un apalancamiento de soporte comprobado. Un escenario desfavorable puede combinar un despliegue empresarial más lento, una renovación más débil y un mayor coste del modelo. Cada caso debe especificar el mecanismo.

El equipo debe evitar combinar todos los supuestos favorables en un solo caso sin dependencias operativas. Lanzamientos más rápidos pueden requerir más capacidad de evaluación y de fiabilidad. Un mayor volumen de clientes puede aumentar el soporte y el capital circulante antes de que aparezca la eficiencia. Precios más bajos de los proveedores pueden atraer competidores además de mejorar el margen.

Las probabilidades de los escenarios deben utilizarse con cautela. Cuando la evidencia sea limitada, los rangos y umbrales de decisión pueden ser más transparentes. El comité de inversiones debe ver qué supuestos impulsan el valor del título, la necesidad de capital y el retorno. El análisis de sensibilidad no debe sustituir una narrativa coherente sobre cómo opera el negocio.

33. Determinar la necesidad de capital y el runway

La necesidad de capital debe extenderse desde la firma hasta una próxima financiación creíble, un punto de autofinanciación o una decisión estratégica. Debe incluir efectivo operativo, compromisos con proveedores, capital circulante, costes de transacción, servicio de la deuda, pagos contingentes y una reserva de liquidez. El modelo debe utilizar las condiciones reales del título y las condiciones de cierre.

El plan de diligencia debida debe identificar hitos de evidencia que requieren tiempo y efectivo. Las renovaciones de clientes empresariales, las migraciones de modelos, las certificaciones y la expansión de mercado pueden extenderse más allá del runway propuesto. Un título por tramos puede alinear la financiación con la evidencia, a la vez que introduce consideraciones de ejecución y control que requieren asesoramiento legal y fiscal.

El runway debe probarse bajo escenarios de ingresos retrasados, mayores costes y riesgo de cierre. Un term sheet firmado no proporciona efectivo. La empresa puede necesitar capacidad para operar durante la documentación, las aprobaciones y la recepción de fondos. El inversor también debe comprender si la confianza de clientes o proveedores depende de la fortaleza del balance.

34. Trasladar los hallazgos a la valoración

La valoración debe seguir el propósito, la base, los métodos, la evidencia y los derechos del título. La NIIF 13 define el valor razonable como una medición basada en el mercado y establece un marco para la medición y la revelación [4]. Las Normas Internacionales de Valoración proporcionan estándares relevantes para los encargos de valoración [8]. Puede ser necesario un asesoramiento cualificado específico de la transacción.

Los enfoques de mercado pueden utilizar empresas y transacciones comparables, con ajustes respaldados por diferencias en crecimiento, retención, margen, concentración, intensidad de capital, derechos y riesgo. Los enfoques de ingresos pueden traducir la evidencia de cohortes y costes en flujos de caja. Una financiación reciente puede aportar contexto, si bien requiere revisar los derechos y las condiciones de mercado.

Los hallazgos de la diligencia debida deben incorporarse al modelo mediante factores impulsores explícitos. Una cohorte retenida madura puede afectar la durabilidad de los ingresos; la concentración del modelo puede afectar el margen, la necesidad de capital o el rango de escenarios; los hallazgos sobre el título pueden afectar las condiciones de cierre y la inversión. Los descuentos arbitrarios pueden duplicar efectos ya recogidos en la previsión.

35. Modelar el waterfall del título

El valor de empresa no determina el valor actual para los accionistas sin la estructura de capital. El modelo debe incluir efectivo, deuda, convertibles, preferencias, participación, antidilución, warrants, opciones, cambios en el pool de opciones, tramos y costes de transacción. Las definiciones deben seguir los documentos reales y una revisión legal cualificada.

El waterfall debe mostrar los importes de salida en los distintos escenarios de valor de empresa y convertirlos en participación del inversor, retorno y potencial a la baja. La nueva financiación puede mejorar el valor operativo a la vez que cambia la asignación entre títulos. Los tramos vinculados a hitos, las preferencias de liquidación y los derechos de gobierno pueden afectar tanto a la protección como a los incentivos.

El comité debe evaluar el precio y las condiciones en conjunto. Una valoración nominal más alta con derechos económicos senior puede producir un resultado distinto de un precio más bajo con condiciones más sencillas. El paquete de decisión debe conservar la fuente de la tabla de capitalización, los supuestos y la sensibilidad para que el resultado pueda reproducirse.

36. Diseñar las protecciones de la inversión

Las protecciones deben responder a riesgos materiales y evidenciados. Pueden incluir condiciones suspensivas, financiación por etapas, derechos de información, derechos de representación en el consejo, materias reservadas, covenants, controles del uso de fondos, cláusulas de persona clave, manifestaciones, indemnizaciones o planes de remediación específicos. Su viabilidad y efecto requieren asesoramiento legal, regulatorio y fiscal.

El equipo debe evitar usar condiciones como sustituto de comprender el negocio. Un covenant no puede crear valor para el cliente ni portabilidad del modelo. Puede aportar derechos de información, consentimiento o intervención, a la vez que potencialmente restringe la operación y la financiación futura. Cada protección debe tener un riesgo, un desencadenante, un remedio y una fuente de seguimiento definidos.

Las condiciones de cierre deben poder verificarse objetivamente. Los requisitos vagos de tecnología mejorada o rendimiento satisfactorio pueden generar disputas. La evidencia del registro de diligencia debida puede respaldar entregables específicos, pruebas de aceptación y una aprobación autorizada. Los riesgos residuales deben mantenerse en la recomendación de inversión.

37. Elaborar el cuadro de mando de la inversión

El cuadro de mando de la inversión debe combinar la solidez de la evidencia, el resultado operativo, la consecuencia financiera y la respuesta propuesta. Debe evitar un único total opaco que oculte un problema fatal. Las categorías pueden incluir valor para el cliente, retención, economía, dependencia, derechos sobre los datos, seguridad, equipo, mercado, previsión, liquidez y condiciones del instrumento.

Cada puntuación debe seguir una rúbrica aprobada y vincularse con la evidencia subyacente. El comité debe ver la confianza y la limitación por separado del resultado. Un resultado observado sólido respaldado por una muestra pequeña difiere de un resultado débil respaldado por una población completa. Ambas dimensiones importan.

El cuadro de mando debe apoyar el juicio, no automatizarlo. Los responsables de la decisión deben registrar los motivos, las discrepancias, las condiciones y los asuntos no resueltos. Los cambios entre la revisión inicial, la aprobación final y el cierre deben tener versiones. El registro puede entonces respaldar la gobernanza posterior a la inversión.

El comité debe considerar el resultado operativo, la confianza en la evidencia, la limitación, el efecto sobre el valor y la acción propuesta.

Tabla 5. Campos del cuadro de mando de la inversión

Una puntuación no anula una condición material de detención ni el asesoramiento especializado.

38. Prepare el dossier del comité de inversiones

El dossier del comité debe indicar la decisión solicitada, el valor, el rango de precios, los fondos obtenidos, la propiedad, la gobernanza, los casos de retorno y las condiciones. Después debe presentar la tesis operativa, la cadena de evidencia, los hallazgos materiales, el modelo de escenarios, la necesidad de capital, el waterfall de distribución, las protecciones, las limitaciones y la recomendación. Los apéndices deben conservar el registro detallado y los informes de los especialistas.

El dossier debe distinguir entre hechos, cálculos contrastados, manifestaciones de la dirección y escenarios. Las fechas y versiones de las fuentes importan porque la evidencia sobre productos y finanzas puede cambiar durante un proceso. Los cambios materiales posteriores a la circulación deben destacarse en lugar de incorporarse de forma silenciosa.

El comité debe disponer de tiempo suficiente para cuestionar las hipótesis. Las preguntas y respuestas deben incorporarse al registro de decisiones. La aprobación debe identificar la autoridad delegada para la negociación final y definir los cambios que requieren una nueva aprobación. Un rango de valoración sin límites de condiciones ni condiciones de cierre deja el mandato incompleto.

El dossier debe incluir un puente claro desde la tesis inicial hasta la recomendación final. Todo cambio material debe identificar la evidencia que lo provocó, la variable del modelo afectada y la respuesta propuesta del comité. Esta disciplina ayuda a los revisores a distinguir el aprendizaje genuino de los movimientos inexplicados en el rango de valoración. También reduce el riesgo de que la evidencia operativa favorable se incorpore rápidamente mientras los hallazgos adversos permanecen aislados en apéndices de especialistas.

Las conclusiones de los especialistas deben conservar su alcance. Un revisor técnico puede confirmar que un modelo alternativo supera una prueba definida, dejando a otros asesores la portabilidad contractual, el consentimiento del cliente y el coste de migración. El dossier integrado debe conectar estos límites sin sugerir un aseguramiento más amplio. Las opiniones legales, fiscales, contables, de ciberseguridad y de valoración deben atribuirse al proveedor cualificado y utilizarse dentro de sus hipótesis declaradas.

39. Establecer el seguimiento posterior a la inversión

El seguimiento posterior a la inversión debe continuar la arquitectura de evidencia de la diligencia debida. La empresa puede informar sobre la aceptación de la versión, el uso recurrente exitoso, la retención, el coste directo, la exposición a dependencias, los incidentes, la tesorería, la previsión y el estado de los covenants con una cadencia controlada. Las definiciones deben mantenerse estables o mostrar un puente documentado.

La información al consejo debe centrarse en umbrales vinculados a la tesis de inversión. Un aumento de los lanzamientos puede ser favorable si se mantienen el éxito del cliente y la fiabilidad. Puede requerir intervención si aumentan el soporte, los incidentes o el abandono de clientes. Las pruebas de dependencia y las renovaciones de contratos deben programarse antes de que las opciones de cambio se vean limitadas.

El inversor debe hacer seguimiento de los compromisos de subsanación, el uso de los fondos y los hitos de financiación. Las excepciones deben tener responsables y fechas. El seguimiento debe seguir siendo proporcionado y respetar la autoridad de la dirección, la confidencialidad y la legislación aplicable. El objetivo es disponer de evidencia oportuna para la toma de decisiones, no de duplicar la operativa.

El diseño del seguimiento debe abordar la deriva de las métricas. A medida que cambian los productos, los precios y los segmentos de clientes, la dirección puede necesitar revisar las definiciones. El paquete para el consejo debe conservar la medida anterior, la medida revisada, el motivo del cambio y una conciliación para los periodos comparables cuando sea practicable. Una métrica que mejora tras un cambio de denominador no debe presentarse como progreso operativo sin la conciliación.

El inversor también debe programar las decisiones de dependencia antes del vencimiento del contrato o de la renovación de capacidad. Una prueba de migración tiene un valor limitado cuando el plazo restante es demasiado corto para ejecutarla. Los controles de calendario pueden conectar la renovación de proveedores, los compromisos con clientes, las condiciones de liquidez y las hojas de ruta de producto. Esto hace observable la opcionalidad y da al consejo tiempo para aprobar un cambio, negociar protección, financiar la duplicación o aceptar la exposición con una justificación documentada.

40. Conclusión

La diligencia debida de capital crecimiento nativa de AI debe seguir la cadena completa desde el lanzamiento hasta el valor para el cliente, la retención, la economía recurrente y el resultado en materia de seguridad. La velocidad de producto proporciona evidencia útil cuando los lanzamientos están definidos, probados, adoptados y asociados con flujos de trabajo duraderos. Los registros de clientes y financieros deben completar la conciliación.

Las dependencias de modelos, datos, nube y cómputo determinan la calidad, la continuidad, el margen y la necesidad de capital. Deben mapearse a nivel de flujo de trabajo y probarse mediante contratos, evaluación en condiciones similares a producción y planes de migración viables. Las afirmaciones no respaldadas de portabilidad o ventaja propietaria deben seguir considerándose limitaciones.

El comité de inversiones necesita un registro de decisiones reproducible. El libro mayor de evidencia, los escenarios coherentes, la conciliación de valoración, el waterfall de seguridad y el cuadro de mando conectan la diligencia debida con el precio, los términos, la gobernanza, la acción o la detención. También crean una línea base controlada para el seguimiento posterior a la inversión. La decisión final sigue dependiendo de los hechos y requiere criterio profesional y asesoramiento especializado.

Un proceso disciplinado debe seguir siendo utilizable bajo presión de tiempo. Responsables designados, fuentes fechadas, cálculos controlados y derechos de decisión explícitos permiten al equipo actualizar la evidencia sin reconstruir todo el caso. Esta disciplina operativa puede mejorar la preparación para la negociación, el control del cierre y la calidad de las primeras decisiones del consejo tras la inversión.

Referencias

1. Instituto Nacional de Estándares y Tecnología, Marco de Gestión de Riesgos de Inteligencia Artificial 1.0, https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
2. National Institute of Standards and Technology, Núcleo del RMF de AI, https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
3. Instituto Nacional de Estándares y Tecnología, Marco de Gestión de Riesgos de Inteligencia Artificial: Perfil de Inteligencia Artificial Generativa, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
4. Fundación IFRS, IFRS 13 Medición del valor razonable, https://www.ifrs.org/issued-standards/list-of-standards/ifrs-13-fair-value-measurement/
5. Fundación IFRS, NIIF 15 Ingresos de Actividades Ordinarias Procedentes de Contratos con Clientes, https://www.ifrs.org/issued-standards/list-of-standards/ifrs-15-revenue-from-contracts-with-customers/
6. Comisión Europea, Marco regulador para la inteligencia artificial, https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
7. Organización para la Cooperación y el Desarrollo Económicos, Principios AI de la OCDE, https://oecd.ai/en/ai-principles
8. Consejo de Normas Internacionales de Valoración, Normas Internacionales de Valoración, https://www.ivsc.org/standards/
9. Organización Internacional de Normalización, sistemas de gestión de inteligencia artificial ISO/IEC 42001, https://www.iso.org/standard/81230.html
10. Comisión de Bolsa y Valores de EE. UU., base de datos de presentaciones de empresas de EDGAR, https://www.sec.gov/edgar/search/
11. Comisión de Bolsa y Valores de Estados Unidos, Observaciones en la mesa redonda sobre inteligencia artificial en el sector financiero, 27 de marzo de 2025, https://www.sec.gov/newsroom/speeches-statements/crenshaw-remarks-ai-roundtable-032725
12. Junta de Normas de Contabilidad Financiera, Codificación de Normas de Contabilidad, Tema 606, https://asc.fasb.org/topic&trid=2129938
13. Banco de Pagos Internacionales, publicaciones sobre inteligencia artificial, https://www.bis.org/topic/artificial_intelligence.htm
14. Amplitude Inc., informes anuales y presentaciones ante la SEC, https://investors.amplitude.com/financial-information/sec-filings
15. DigitalOcean Holdings Inc., resultados del cuarto trimestre y anuales de 2025 presentados ante la SEC, https://www.sec.gov/Archives/edgar/data/1582961/000158296126000015/a2025-q4dopressrelease.htm
16. Atlassian Corporation, informe anual de 2025, https://www.sec.gov/Archives/edgar/data/1650372/000165037225000060/team2025annualreport.pdf
17. Microsoft Corporation, informe anual de 2025 presentado ante la SEC, https://www.sec.gov/Archives/edgar/data/789019/000095017025100235/msft-20250630.htm
18. Alphabet Inc., informe anual de 2025 presentado ante la SEC, https://www.sec.gov/Archives/edgar/data/1652044/000165204426000018/goog-20251231.htm
19. CoreWeave Inc., informe anual de 2025 presentado ante la SEC, https://www.sec.gov/Archives/edgar/data/1769628/000176962826000104/crwv-20251231.htm
20. Oracle Corporation, informe anual de 2026 presentado ante la SEC, https://www.sec.gov/Archives/edgar/data/1341439/000119312526277521/orcl-20260531.htm
21. Snowflake Inc., informes anuales y presentaciones ante la SEC, https://investors.snowflake.com/financials/sec-filings/default.aspx
22. C3.AI Inc., informes anuales y presentaciones ante la SEC, https://ir.c3.ai/financials/sec-filings/default.aspx
23. NVIDIA Corporation, informes financieros y presentaciones ante la SEC, https://investor.nvidia.com/financial-info/financial-reports-and-sec-filings/default.aspx
24. Instituto Nacional de Estándares y Tecnología, AI Manual del RMF, https://airc.nist.gov/airmf-resources/playbook/
25. Instituto Nacional de Estándares y Tecnología, Marco TEVV-Athlon para la evaluación de sistemas AI, https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems
26. Fundación IFRS, material educativo sobre la medición del valor razonable de instrumentos de fondos propios no cotizados, https://www.ifrs.org/content/dam/ifrs/supporting-implementation/ifrs-13/education-ifrs-13-eng.pdf