Riesgo algorítmico de las operaciones: deriva de precios, dependencia y exposición al cambio de control

1. Definir el riesgo algorítmico de las operaciones en términos de flujos de caja

El riesgo algorítmico de las operaciones es la posibilidad de que la tecnología, los derechos, las personas o los servicios externos necesarios para producir un resultado para el cliente habilitado por AI modifiquen los flujos de caja suscritos en una operación. El riesgo puede surgir antes de la firma, entre la firma y el cierre, o después de la transferencia de control. Adquiere relevancia financiera a través de la pérdida de clientes, una menor conversión, un mayor coste de inferencia, créditos de servicio, inversión en remediación, retrasos en el lanzamiento de productos, restricciones regulatorias o un calendario de integración más prolongado.

Por lo tanto, una conclusión de diligencia debida debería indicar la capacidad operativa afectada, la evidencia disponible, el mecanismo de cambio, la vía de flujo de caja, el tiempo para detectarlo, el tiempo para remediarlo y la parte capaz de controlar el resultado. Describir un modelo como de alto riesgo sin esta cadena no respalda una decisión de precio o contractual. Describir un producto como preciso sin definir la población, el periodo y el umbral sometidos a prueba ofrece igualmente poca protección.

El equipo de la transacción debería establecer un registro único que conecte la evidencia técnica con las decisiones comerciales y jurídicas. Cada partida recibe un responsable, un rango de materialidad, una mitigación, una exposición residual y una prueba posterior al cierre. El registro debería distinguir las condiciones que afectan al valor de empresa, al valor de los fondos propios, a la certeza de cierre, al coste de integración y a la gobernanza continua. Una misma cuestión puede afectar a varias de estas categorías mediante mecanismos diferentes.

2. Establecer la línea base operativa del estado a la firma

El comprador necesita una imagen reproducible del producto y de sus aspectos económicos en la fecha de medición. La línea base debería identificar las versiones exactas de modelos y prompts, las reglas de enrutamiento, las instantáneas de datos, las suites de evaluación, la infraestructura, los pasos de revisión humana, los servicios upstream, las configuraciones de clientes y las asignaciones de costes. Debería registrar el periodo durante el cual se observaron el rendimiento, la disponibilidad, los ingresos y el margen. Este es el estado de referencia para las garantías, los covenants intermedios, las pruebas de cierre y la medición posterior del valor.

Las presentaciones de la dirección suelen combinar versiones de producto o cohortes de clientes. El comprador debería conciliar las métricas principales con registros, facturas, registros de clientes y evaluaciones controladas. Si los resultados históricos no pueden reproducirse, el comprador puede tratar la diferencia como una limitación de medición y construir un rango de valoración más amplio. El objetivo es una línea base defendible, no una reconstrucción de laboratorio perfecta de cada decisión pasada.

La línea base debería conservarse mediante artefactos con hash, exportaciones con control de acceso y procedimientos de prueba documentados. El comprador y el vendedor deberían acordar qué cambios son operación ordinaria y cuáles requieren notificación o consentimiento antes del cierre. Un cambio de versión que parece técnico puede alterar el coste, la calidad de los resultados, la explicabilidad o el cumplimiento. Por lo tanto, los controles intermedios deberían aplicarse al sistema operativo completo y no solo al nombre del modelo.

3. Mapear la cadena completa de dependencias algorítmicas

Un producto AI puede depender de API de modelos fundacionales, regiones de nube, bases de datos vectoriales, proveedores de etiquetado, herramientas de seguridad, bibliotecas de código abierto, conjuntos de datos propietarios, sistemas de pago y personas concretas. Un mapa de dependencias debería rastrear el resultado para el cliente a través de cada componente material. Debería identificar la contraparte contractual, la interfaz técnica, la titularidad, la jurisdicción, la concentración, los derechos de cambio, las condiciones de terminación, la opción de sustitución y los ingresos expuestos.

La evidencia en tiempo de ejecución es esencial. Los diagramas de arquitectura pueden omitir servicios en la sombra, modelos de respaldo y rutas específicas de clientes. El comprador puede comparar repositorios de código, configuración del entorno, telemetría, llamadas de red, facturas y registros de incidentes. Las diferencias deberían resolverse antes de puntuar la dependencia. Un componente de bajo coste puede seguir siendo muy material si interviene en cada solicitud de producción y no puede sustituirse rápidamente.

La dependencia debería medirse mediante el impacto y la sustituibilidad. El impacto considera los ingresos, el margen, los clientes, las obligaciones y la seguridad. La sustituibilidad considera la equivalencia técnica, la portabilidad de los datos, la autorización contractual, el esfuerzo de integración, el tiempo de evaluación y la aprobación del cliente. La combinación determina si el riesgo exige un ajuste de precio, una condición de cierre, un depósito en garantía, un covenant, un plan de sustitución financiado o una supervisión continua.

Cada dependencia operativa está vinculada al resultado para el cliente, al flujo de caja expuesto y a la respuesta de la transacción.

Tabla 1. Evidencia de dependencias y respuesta de la transacción

La materialidad combina el impacto en el flujo de caja, el tiempo de sustitución y el control.

4. Separar la deriva del modelo del fallo del modelo

La deriva es un cambio en las entradas, las relaciones, las salidas o el contexto operativo que puede alejar el rendimiento del rango aprobado. La deriva de datos cambia las características de las entradas. La deriva de concepto cambia la relación entre las entradas y los resultados deseados. La deriva de rendimiento cambia la calidad medida. La deriva operativa puede surgir por el enrutamiento, los prompts, el contenido de recuperación, la infraestructura o la revisión humana. Estas condiciones pueden existir incluso cuando el archivo del modelo subyacente permanece sin cambios.

Una transacción debe distinguir la variación normal de la superación de un umbral. El equipo de diligencia debida debe identificar métricas, segmentos, ventanas de observación, límites de confianza y consecuencias empresariales. Un promedio global puede ocultar un deterioro material para un caso de uso regulado, un idioma, una cohorte de clientes o un flujo de trabajo de alto valor. Por lo tanto, el monitoreo debe seguir el valor y la obligación en riesgo, en lugar de una única puntuación del modelo.

El fallo es la incapacidad de satisfacer un requisito acordado, como disponibilidad, precisión, seguridad o servicio contractual. La deriva puede generar una alerta temprana antes del fallo. Un comprador solo puede valorar esa alerta si el objetivo cuenta con medición, responsabilidad y procedimientos de respuesta estables. Cuando el monitoreo es débil, el comprador puede necesitar una línea base independiente, un período de observación financiado y escenarios de desventaja más amplios.

5. Construir escenarios de deriva en torno a la evidencia observada

El modelo de valoración debe utilizar un conjunto limitado de escenarios de deriva coherentes. Un caso base puede reflejar el rendimiento observado y el gasto actual en remediación. Un caso moderado puede modelar el deterioro en un segmento material, una mayor revisión humana y ventas retrasadas. Un caso grave puede modelar restricciones de clientes, la sustitución de un modelo upstream, remediación regulatoria o la pérdida de una fuente de datos. Cada escenario debe indicar el desencadenante, la duración, la respuesta y la evidencia de recuperación.

Las estimaciones de probabilidad no deben implicar una precisión que la historia no respalde. El comprador puede utilizar rangos y umbrales de decisión, y luego probar la sensibilidad de la valoración a la probabilidad y duración de cada estado. La cuestión central es si el precio de compra y el plan de capital siguen siendo aceptables cuando la evidencia operativa se sale del rango suscrito.

El modelo debe evitar el doble conteo. Unos ingresos inferiores, un mayor coste operativo, la inversión en remediación y la compresión de múltiplos pueden reflejar la misma causa raíz. El equipo debe especificar qué efectos sobre los flujos de caja entran en la previsión y qué riesgos influyen en la tasa de descuento o en las condiciones de la transacción. Un puente documentado facilita el escrutinio del comité de inversiones y la medición posterior al cierre.

Los escenarios ilustrativos muestran cómo la evolución operativa puede afectar a los ingresos, el margen y la remediación.

Tabla 2. Registro ilustrativo de escenario de deriva

Los valores son supuestos analíticos y requieren evidencia específica de la operación.

6. Evaluar la estabilidad del benchmark y su relevancia para la decisión

Un benchmark puede generar una falsa sensación de seguridad cuando sus datos están desactualizados, contaminados, son limitados o tienen una conexión débil con el resultado para el cliente. El comprador debería reproducir las afirmaciones materiales utilizando entornos bloqueados, prompts documentados, muestras representativas, ejecuciones repetidas y una puntuación clara. Debería examinar la varianza y la distribución de errores en lugar de depender únicamente de un resultado medio.

La relevancia del benchmark debería vincularse a los ingresos y las obligaciones. Una puntuación de programación puede no predecir el rendimiento en un flujo de trabajo del cliente que depende de recuperación, herramientas, permisos y revisión humana. Un benchmark de seguridad puede no cubrir el idioma o el dominio en el que se vende el producto. El plan de diligencia debida debería incluir pruebas específicas de la operación diseñadas en torno al uso por parte del cliente, el coste del fallo y los cambios de integración previstos.

El perfil generativo de AI de NIST destaca que los sistemas suelen depender de múltiples componentes y fuentes de datos de terceros, lo que complica la atribución. Esto es relevante para un comprador porque un resultado reproducido debería identificar el modelo, el sistema que lo rodea y el propietario de la evidencia. Una afirmación que no puede atribuirse no puede protegerse de forma fiable mediante una simple garantía del modelo.

7. Identificar los derechos de cambio de los proveedores upstream

Los proveedores de modelos fundacionales e infraestructura pueden cambiar versiones, retirar endpoints, ajustar los límites de velocidad, revisar los filtros de seguridad, alterar el tratamiento de datos y modificar el precio del uso. El equipo de diligencia debida debería leer los acuerdos vigentes y la documentación del servicio, y conciliarlos con la configuración de producción. Las descripciones de marketing y las garantías informales no deberían sustituir a los derechos contractuales.

El análisis debería identificar los periodos de preaviso, las disposiciones de cambio unilateral, los niveles de servicio, los límites de responsabilidad, las restricciones de cesión, las condiciones de uso de datos, los derechos de resolución y los compromisos disponibles. Debería comprobar si la sociedad objetivo recibe condiciones empresariales o depende de un acuerdo en línea estándar. Una aplicación técnicamente portátil puede seguir bloqueada comercialmente si un rendimiento comparable exige un nuevo desarrollo costoso o una revalidación por parte del cliente.

El comprador debería cuantificar el plazo de sustitución y la exposición de caja durante el periodo transitorio. Esto incluye ingeniería, evaluación, aprobación del cliente, revisión de seguridad, migración de datos, ejecución en paralelo y posible pérdida de ingresos. Un plan de contingencia creíble es una capacidad operativa probada, no el nombre de un proveedor alternativo en una diapositiva.

8. Precio de API y concentración de cómputo

El margen bruto de AI puede cambiar rápidamente cuando cambian el precio de los tokens, la longitud del contexto, el enrutamiento, el almacenamiento en caché, la utilización o la revisión humana. El comprador debería reconstruir el coste por resultado exitoso para el cliente utilizando facturas y telemetría. El coste unitario debería distinguir entre entrada, salida, embeddings, recuperación, herramientas, almacenamiento, red, capacidad reservada, llamadas fallidas y mano de obra de revisión.

El análisis de concentración debería mostrar el gasto y los ingresos expuestos a cada proveedor, familia de modelos, región de nube y compromiso de capacidad. El equipo puede modelizar aumentos de precios, descuentos que vencen, crecimiento del volumen, prompts ineficientes y uso de alternativas. La fijación de precios basada en ingresos puede ocultar la sensibilidad al coste hasta que aumente el uso o cambie el comportamiento del cliente.

La protección de la transacción puede combinar un escenario de precio de compra con controles operativos. Estos pueden incluir un covenant transitorio que limite cambios materiales de proveedores, una prueba de cierre para el acceso continuado, una reserva financiada para migración o una métrica de earn-out basada en el margen de contribución en lugar de solo en los ingresos. Los especialistas en contratos deberían redactar e interpretar todas las disposiciones.

9. Construir un waterfall de derechos y licencias

El producto adquirido puede incluir código, pesos, prompts, datos, contenido, etiquetas, documentación, marcas registradas, patentes, componentes de código abierto y desarrollos específicos para el cliente. Cada activo puede tener distintos titulares, licencias y reglas de cesión. El waterfall de derechos debe comenzar con la funcionalidad del cliente y rastrear cada derecho requerido a través de la cadena de colaboradores y proveedores.

El análisis debe distinguir la titularidad de la autorización. La sociedad objetivo puede ser titular del código fuente y, al mismo tiempo, carecer del derecho a entrenar con datos de clientes tras un cambio de control. Una licencia de software permisiva puede imponer requisitos de notificación. Un conjunto de datos puede estar disponible públicamente mientras que su recopilación, los datos personales o los derechos sobre bases de datos siguen estando limitados. Se requiere asesoramiento especializado para las jurisdicciones y los hechos pertinentes.

El equipo de la operación debe vincular las deficiencias con los remedios. Un consentimiento faltante puede ser una condición de cierre. Un derecho de entrenamiento ambiguo puede exigir una garantía específica, una indemnización, un covenant de subsanación o una limitación del producto. Un componente reemplazable puede justificar una reserva cuantificada. La respuesta debe reflejar la exigibilidad, la materialidad y la capacidad del comprador para verificar el cumplimiento.

Una funcionalidad del cliente solo está respaldada cuando cada derecho material de la cadena está acreditado y es transferible.

Tabla 3. Registro de diligencia debida del waterfall de licencias

Los especialistas cualificados deberían interpretar los derechos y restricciones aplicables.

10. Examinar la exposición de los datos de entrenamiento y de los resultados

Los datos de entrenamiento y ajuste fino deberían rastrearse por origen, finalidad, jurisdicción, licencia y retención. El comprador debería identificar si la sociedad objetivo creó un modelo, modificó un modelo de terceros o actúa como proveedor descendente. El marco actual de AI de propósito general de la UE impone obligaciones de documentación, política de derechos de autor y resumen del contenido de entrenamiento a los proveedores pertinentes, con obligaciones adicionales para los modelos con riesgo sistémico. La aplicabilidad exige un análisis jurídico específico de los hechos.

La exposición de los resultados incluye confidencialidad, datos personales, propiedad intelectual, contenido nocivo, discriminación y dependencia. Los contratos de la sociedad objetivo pueden asignar estos riesgos de forma diferente entre clientes. Los controles del producto, como el filtrado, los permisos de recuperación, la revisión y el registro, deberían probarse frente a los compromisos reales. Un documento de política sin aplicación técnica tiene un valor limitado para la transacción.

El comprador debería distinguir una laguna documental subsanable de un modelo operativo que depende de un uso prohibido o no autorizado. La primera puede requerir coste y tiempo. El segundo puede afectar al perímetro operativo legal del producto y a su valor terminal. Las condiciones de la transacción deberían reflejar esa diferencia.

11. Asignar las responsabilidades del proveedor y del responsable del despliegue

La regulación de AI distingue cada vez más entre la entidad que desarrolla o introduce un modelo o sistema en el mercado y la entidad que lo despliega. Una adquisición puede cambiar la marca, la integración, la finalidad, la distribución y el control. Esos cambios pueden alterar las responsabilidades de las partes. El equipo de diligencia debida debería mapear cada producto y jurisdicción antes de asignar una etiqueta genérica de cumplimiento.

El mapa debería identificar el sistema pertinente, la finalidad prevista, los usuarios, las personas afectadas, la clasificación de riesgo, la documentación, la supervisión humana, la monitorización, la notificación de incidentes y la información para la cadena descendente. También debería identificar qué entidad puede aportar las pruebas. Una asignación contractual no elimina una obligación legal, aunque puede facilitar la cooperación y las vías de recurso entre las partes.

El comprador puede vincular la capacidad faltante con las decisiones de cierre e integración. Si la sociedad objetivo no puede suministrar la información exigida por los clientes posteriores, la retención de ingresos puede quedar expuesta. Si la integración prevista por el comprador crea un nuevo rol de proveedor, el presupuesto de integración debería incluir la evaluación, la documentación y los controles resultantes.

12. Revisar las obligaciones de AI en los servicios financieros de UAE

El Banco Central de UAE publicó en febrero de 2026 directrices sobre AI responsable para las instituciones financieras con licencia. Las directrices se centran en la protección del consumidor, la transparencia, el sesgo, la rendición de cuentas, la explicabilidad, la privacidad de los datos y el uso responsable. Una transacción que implique a una institución financiera regulada o a su proveedor tecnológico relevante debería examinar cómo se aplican estos principios al producto específico y a la cadena contractual.

El comprador debería probar la gobernanza, la información al cliente, la aprobación de modelos, la protección de datos, la monitorización de resultados, las reclamaciones, la revisión humana y la supervisión de terceros. Debería identificar qué registros respaldan las declaraciones de la dirección y si los controles operan en los modelos externalizados. El análisis puede afectar a los consentimientos de los clientes, los cambios de producto, la secuenciación de la integración y el coste continuo de aseguramiento.

La interpretación regulatoria corresponde a asesoría jurídica cualificada y a especialistas pertinentes. No obstante, el modelo de transacción puede recoger trabajos de remediación observables, ingresos afectados, fechas de decisión y necesidades de capital. Esto crea un puente entre la evidencia de cumplimiento y la valoración sin tratar una conclusión jurídica como una puntuación técnica.

13. Analizar los desencadenantes de cambio de control contrato por contrato

La exposición al cambio de control puede aparecer en acuerdos con clientes, proveedores, de datos, de servicios en la nube, laborales, de financiación, de seguros, de subvenciones y de asociación. Las cláusulas pueden exigir consentimiento, notificación, reembolso, renegociación o resolución. El equipo de diligencia debida debe examinar el conjunto completo de contratos y confirmar los resultados mediante revisión jurídica y entrevistas con los responsables de negocio.

La materialidad debe reflejar más que el valor del contrato. Un acuerdo de datos pequeño puede habilitar un producto importante. Un proveedor de modelos con bajo gasto puede sustentar la mayor parte de los ingresos. Un cliente con derecho de resolución puede influir en otros clientes o en una aprobación regulatoria. Por tanto, el registro debe vincular cada cláusula con dependencias técnicas y flujos de caja.

La estrategia de consentimiento necesita un responsable, un mensaje, una secuencia, una alternativa y un plazo. Las solicitudes tempranas pueden revelar la transacción o debilitar el poder de negociación. Las solicitudes tardías pueden poner en riesgo el cierre. Las partes deben alinear el enfoque con el asesoramiento jurídico, las condiciones de la transacción y la continuidad operativa. Los covenants provisionales deben evitar nuevas exposiciones evitables.

14. Evaluar la transferencia y la confianza de los clientes

Los clientes de AI pueden haber aprobado un modelo concreto, una región de alojamiento, una arquitectura de seguridad, un uso de datos, un subcontratista o un proceso de revisión humana. Una adquisición puede cambiar uno o varios de estos elementos incluso cuando el proveedor legal sigue siendo el mismo. El comprador debe vincular los compromisos contractuales, los informes de aseguramiento, los cuestionarios y las cartas complementarias con el plan de integración previsto.

La diligencia debida de clientes debe segmentar los ingresos según la sensibilidad al modelo, a los datos, a la propiedad y a los cambios de servicio. Las entrevistas o los procedimientos de confirmación permitidos pueden verificar los motivos de compra, el coste de cambio, la confianza y los criterios de renovación. El comprador debe evitar prometer cambios futuros en el producto antes de que se establezcan la autoridad y la viabilidad.

Los escenarios de retención deben reflejar la evidencia de clientes y los derechos contractuales. Una protección de la transacción podría vincular parte de la contraprestación al beneficio bruto recurrente retenido, al consentimiento o a la renovación del cliente, sujeto a definiciones cuidadosas y a consideraciones sobre el control del vendedor. El plan operativo debe incluir una secuencia de comunicación, un responsable de cuenta designado y una vía de escalado.

15. Medir la dependencia de personas críticas

Los productos de AI suelen concentrar conocimiento en un grupo reducido que entiende el linaje de datos, el diseño de evaluaciones, el despliegue, la respuesta a incidentes o la configuración de clientes. Los títulos de los puestos no revelan esta dependencia. El comprador debe asignar decisiones, sistemas, credenciales, relaciones y conocimiento tácito a roles designados, y después probar la cobertura de respaldo y la documentación.

La concentración se convierte en riesgo de transacción cuando la pérdida de una persona puede interrumpir el servicio, impedir un lanzamiento, socavar una afirmación, retrasar la integración o debilitar la confianza de los clientes. El análisis debe considerar los periodos de preaviso, la retención, los incentivos, la inmigración, la ubicación, los covenants restrictivos, la sucesión, la carga de trabajo y la adecuación cultural. El derecho laboral y la exigibilidad local requieren asesoramiento especializado.

Los pagos de retención por sí solos no transfieren conocimiento. Un plan de transición debe asignar artefactos, acompañamiento, aprobación dual, transferencia de accesos, traspaso de clientes y pruebas de aceptación. El comprador puede vincular la finalización con la liberación del depósito en garantía, la operativa del earn-out o los hitos de integración cuando sea apropiado y jurídicamente defendible.

La concentración combina el impacto operativo con el tiempo necesario para establecer una cobertura creíble.

Tabla 4. Evidencia y plan de protección para personas críticas

La retención debe combinarse con una transferencia de conocimiento controlada y la aceptación operativa.

16. Conciliar accesos, credenciales y autoridad operativa

El comprador debe saber quién puede modificar el entorno de producción, acceder a datos sensibles, aprobar versiones, alterar la facturación, comunicarse con clientes y declarar incidentes. Las credenciales en manos de personas o proveedores generan exposición de continuidad y seguridad. El equipo de diligencia debida debe probar el acceso mediante observación y evidencia aprobadas, sin interferir con producción.

El mapa de accesos debe conciliar los sistemas de identidad, las consolas en la nube, los repositorios, los registros de modelos, los almacenes de datos, la monitorización, el soporte y los portales de terceros. Debe identificar cuentas compartidas, administradores inactivos, registros faltantes y procedimientos de acceso de emergencia. Es posible que la remediación deba esperar hasta el cierre para no interrumpir la sociedad objetivo, por lo que el plan del día uno debe priorizar la secuencia y la reversión.

Los documentos de la transacción pueden respaldar la entrega de evidencia de acceso y la cooperación, mientras que el plan de integración establece la nueva autoridad. El comprador debe conservar los registros forenses y respetar las obligaciones aplicables de privacidad y laborales. La transferencia de cuentas nunca debe basarse en el intercambio informal de contraseñas.

17. Inspeccionar el historial de incidentes como evidencia de valoración

Los incidentes revelan cómo se comporta el producto bajo tensión y cómo responde la organización. El comprador debe examinar incidentes de seguridad, privacidad, disponibilidad, resultados perjudiciales, calidad de datos, clientes y regulatorios. Debe conciliar tickets, páginas de estado, registros, avisos de seguros, créditos a clientes e informes al consejo para identificar eventos omitidos o clasificados de forma diferente.

El análisis debe medir el tiempo de detección, la contención, la recuperación, la recurrencia, la calidad del análisis de causa raíz y la finalización de las acciones correctivas. Los eventos repetidos de baja gravedad pueden poner de manifiesto un diseño débil de los controles. Un único evento grave puede ser menos predictivo si se eliminó la causa y la corrección se probó de forma independiente. El equipo de la operación debe conservar el contexto en lugar de puntuar únicamente el número de incidentes.

Las acciones no resueltas pueden convertirse en una condición de cierre, una partida de depósito en garantía, una indemnización específica o un plan de remediación financiado. Los eventos históricos también pueden afectar a las garantías, la información revelada, los seguros y la retención de clientes. Los asesores cualificados deben determinar el tratamiento jurídico y contable adecuado.

18. Evaluar la monitorización y la observabilidad

Un producto AI necesita visibilidad sobre la calidad de las entradas, las versiones de modelos y prompts, la recuperación, las llamadas a herramientas, la calidad de las salidas, la latencia, el coste, la seguridad, la revisión humana y los resultados para el cliente. El comprador debe comprobar si la monitorización cubre segmentos materiales y si las alertas conducen a actuaciones con responsabilidad asignada. Un panel de control solo es útil cuando las definiciones, el linaje de datos y la responsabilidad sobre la respuesta son fiables.

La monitorización debe distinguir entre indicadores adelantados y rezagados. Los cambios en las entradas, los avisos de proveedores, la latencia y el escalado de revisiones pueden advertir antes del abandono de clientes o de la pérdida de ingresos. Las reclamaciones de clientes y las renovaciones fallidas muestran el impacto materializado. El modelo de la operación puede vincular ambos tipos con umbrales y costes de respuesta.

Los covenants posteriores al cierre o los earn-outs que dependen de métricas técnicas requieren definiciones estables y controles anti-manipulación. Cuando las métricas puedan verse influidas por el enrutamiento, la selección de muestras o los cambios de umbral, las partes necesitan procedimientos de medición acordados y acceso a la evidencia. Las medidas comerciales más simples pueden ser más exigibles cuando la instrumentación técnica es inmadura.

19. Verificar la seguridad en toda la cadena de suministro de AI

El riesgo de la cadena de suministro de AI incluye artefactos de modelos, canalizaciones de entrenamiento, código, datos, API, plugins, infraestructura en la nube y herramientas de terceros. El comprador debe examinar el control de acceso, los secretos, la procedencia, la gestión de vulnerabilidades, el registro de eventos, la separación de entornos, la respuesta a incidentes y el aseguramiento de proveedores. También debe comprobar riesgos específicos del producto, como la inyección de prompts, la fuga de datos, el uso inseguro de herramientas y la extracción de modelos.

La guía secure-AI del Centro Nacional de Ciberseguridad del Reino Unido organiza la seguridad a lo largo del diseño, el desarrollo, el despliegue y la operación. Esta visión del ciclo de vida es útil en las operaciones porque el comprador adquiere tanto un sistema actual como el proceso utilizado para cambiarlo. Una instantánea segura no puede compensar una canalización de publicación no controlada.

Los hallazgos de seguridad deben traducirse en explotabilidad, activos afectados, probable impacto empresarial, remediación y exposición residual. La respuesta en la operación puede incluir subsanación previa al cierre, precio, depósito en garantía, revisión de seguros, covenant específico o una condición de integración. Los especialistas en seguridad deben validar los hallazgos graves y la remediación.

20. Probar la resiliencia y el funcionamiento de respaldo

Las afirmaciones sobre mecanismos de respaldo deben demostrarse. El comprador debe observar o reproducir la conmutación por error del proveedor, la sustitución de modelos, el modo degradado, la gestión de colas, la reversión, la restauración de copias de seguridad y la comunicación de incidentes. Las pruebas deben reflejar volúmenes realistas de clientes y restricciones de datos. Un mecanismo de respaldo que mantenga el tiempo de actividad pero degrade materialmente la calidad o incumpla un contrato es incompleto.

El análisis de resiliencia debe identificar el tiempo de recuperación, el punto de recuperación, la capacidad, la dependencia regional, el esfuerzo manual y el impacto en el cliente. Debe incluir incidentes de terceros y errores internos de despliegue. El coste de mantener capacidad paralela debe incluirse en el modelo de valoración cuando sea necesario para el nivel de servicio asumido en la suscripción.

Una prueba de cierre puede confirmar el acceso a proveedores críticos y a los procedimientos de recuperación. Una condición posterior al cierre puede retrasar la consolidación de plataformas hasta que se demuestre la resiliencia. El comprador debe evitar eliminar redundancias únicamente para capturar una sinergia temprana si esa redundancia protege ingresos materiales.

21. Cuantificar la inversión en remediación

La subsanación debe presupuestarse como un programa y no como una lista de hallazgos. La estimación debe incluir personas, asesores especializados, licencias, infraestructura, ejecución en paralelo, trabajo con clientes, validación, documentación, contingencia y atención de la dirección. Debe identificar qué trabajos son necesarios para operar, cumplir, integrar o materializar la tesis de adquisición.

El momento importa. Un coste incurrido antes del crecimiento de los ingresos tiene un efecto distinto sobre el valor que uno financiado con flujos de caja posteriores. Los retrasos también pueden aplazar sinergias o lanzamientos de productos. Por tanto, el modelo de valoración debe situar costes y beneficios en los periodos correspondientes e indicar las dependencias.

El comprador debe distinguir entre la subsanación por el vendedor, el ajuste del precio de compra, la partida similar a deuda, los trabajos financiados con depósito en garantía y la inversión del comprador. El tratamiento contable depende de los hechos y de las normas aplicables. El modelo comercial puede mostrar la consecuencia en caja, mientras que asesores cualificados determinan la clasificación.

22. Trasladar el riesgo a escenarios de valoración

La valoración debe comenzar por la base operativa observada y por supuestos explícitos. A continuación, el registro algorítmico de riesgos modifica los ingresos, el margen bruto, el coste operativo, la inversión, el capital circulante o los plazos. El equipo puede calcular la sensibilidad del valor de empresa bajo escenarios coherentes e identificar qué supuestos determinan el rango.

La compresión de múltiplos debe utilizarse con cautela. Si el menor crecimiento, margen y sostenibilidad ya están recogidos en los flujos de caja, una reducción adicional arbitraria puede duplicar el riesgo. Un múltiplo terminal inferior puede justificarse cuando la incertidumbre sobre dependencias o derechos afecta a la capacidad de defensa a largo plazo más allá del periodo de previsión. Debe documentarse la justificación.

El comité de inversiones debe ver tanto el valor esperado como la liquidez en escenarios adversos. Una operación puede mantener el valor esperado y, al mismo tiempo, requerir más caja para subsanar o resistir una interrupción. Los prestamistas y los sponsors financieros deben evaluar la holgura de covenant, el servicio de la deuda y la disponibilidad de financiación bajo los mismos escenarios.

23. Elegir entre precio y contraprestación contingente

Un ajuste fijo del precio puede abordar una exposición cuyo efecto esperado en caja es medible y queda en gran medida fuera del control del vendedor tras el cierre. La contraprestación contingente puede abordar incertidumbre que se resuelve con el tiempo, como la retención de clientes, el consentimiento, el rendimiento o el margen. La métrica, el periodo, los derechos de control y el proceso de resolución de disputas determinan si el mecanismo refleja la economía o genera conflicto.

Las métricas técnicas pueden ser precisas en el código y ambiguas en el ámbito comercial. El rendimiento del modelo puede variar según la muestra, el enrutamiento, el umbral y la combinación de clientes. Las métricas comerciales, como el beneficio bruto recurrente, pueden capturar el valor de forma más directa, pero pueden verse influidas por las decisiones de integración. Las partes necesitan definiciones que alineen el control y la medición.

El comprador debe modelar los incentivos de comportamiento. Un earn-out vinculado a los ingresos puede fomentar un uso costoso o una selección deficiente de clientes. Una métrica de margen puede desincentivar la inversión necesaria. Un cuadro de mando integral puede volverse demasiado complejo de gestionar. Los especialistas en transacciones deben seleccionar el conjunto medible más pequeño que refleje el riesgo no resuelto.

24. Diseñar el depósito en garantía y la retención en torno a eventos de liberación verificables

El depósito en garantía puede respaldar la recuperación por incumplimientos de garantías o asegurar el cumplimiento de obligaciones específicas, con sujeción a la legislación aplicable y a los términos negociados. Un evento de liberación debe ser objetivo, tener un plazo definido y estar respaldado por pruebas accesibles para ambas partes. Los ejemplos pueden incluir la recepción de un consentimiento relevante, la finalización de una subsanación de derechos, la transferencia de un acceso crítico o una subsanación verificada de forma independiente.

El importe del depósito en garantía debe guardar relación con la exposición plausible y con la capacidad de ejecución, no con un porcentaje genérico. El equipo puede modelar el coste de sustitución, el beneficio bruto afectado, la responsabilidad frente a clientes, la subsanación y el retraso. Los límites máximos, los umbrales, las exclusiones y los seguros interactúan con la recuperación práctica.

Los tests técnicos de aceptación deben definirse antes de la firma cuando sea posible. Si un test depende de un entorno futuro controlado por el comprador, el contrato debe abordar la cooperación y los cambios. Asesores jurídicos cualificados deben redactar todas las disposiciones relativas a depósitos en garantía, retenciones y reclamaciones.

25. Redactar declaraciones basadas en pruebas, no en adjetivos

Una declaración de que un modelo es preciso, robusto o conforme puede ser difícil de interpretar. Las disposiciones más útiles pueden abordar los sistemas revelados, la titularidad y los derechos, los contratos materiales, los incidentes, las reclamaciones, la documentación, las pruebas, el historial de cambios y el funcionamiento conforme a políticas u obligaciones especificadas. El lenguaje adecuado depende de la operación y la jurisdicción.

La divulgación debe vincular las excepciones con el activo, el cliente y el flujo de caja afectados. Una sala de datos grande no aporta claridad si el comprador no puede identificar qué documento rige una dependencia de producción. Los anexos deben conciliar con el registro de riesgos algorítmicos y el análisis de materialidad.

Las declaraciones no sustituyen la diligencia debida ni el control operativo. Su valor depende de las limitaciones por conocimiento, la vigencia, los límites máximos, las exclusiones, el seguro y la cobrabilidad. Los asesores jurídicos deben asesorar sobre la redacción y la exigibilidad. El equipo de la operación debe mantener pruebas que respalden la justificación comercial.

26. Utilizar covenants provisionales para preservar el sistema objeto de la suscripción

El periodo entre la firma y el cierre puede ser material para una empresa AI. Los modelos, prompts, conjuntos de datos, proveedores, precios, personal y compromisos con clientes pueden cambiar a través de las operaciones ordinarias. Los covenants provisionales deben preservar los elementos acordados del negocio mientras permiten el desarrollo y el cumplimiento necesarios.

Las partes pueden definir la notificación o el consentimiento para la sustitución material de modelos, el nuevo uso de datos, la terminación de proveedores, el cambio de precios, la salida de personas clave, los incidentes de seguridad, el contacto regulatorio y el compromiso con clientes. El umbral debe centrarse en la materialidad económica y operativa. Un covenant excesivamente rígido puede impedir correcciones responsables o la entrega de productos.

El comprador debe operar mediante la gobernanza acordada y respetar las normas de competencia aplicables antes del cierre. Pueden ser necesarios acuerdos de equipo limpio y controles de información. Los asesores jurídicos deben determinar el proceso y la redacción permitidos.

27. Establecer condiciones de cierre para dependencias existenciales

Puede ser apropiada una condición de cierre cuando un consentimiento, derecho, acceso o aprobación faltante impide al comprador operar una parte material del negocio. La condición debe ser específica y susceptible de determinación objetiva. Las partes deben entender quién controla el cumplimiento y las consecuencias de un retraso.

Las condiciones también pueden abordar la entrega de artefactos, acuerdos clave o aprobaciones regulatorias. Una condición no debe convertirse en un sustituto de completar la diligencia debida ordinaria. El comprador debe evaluar los derechos de terminación, las fechas límite absolutas, la financiación y los efectos sobre los clientes.

Cuando una condición plena es desproporcionada, las alternativas incluyen una renuncia con protección de precio, depósito en garantía, un servicio de transición, licencia, exclusión o sustitución financiada. La decisión depende de la materialidad, el control, el tiempo y la exigibilidad. Es esencial contar con asesoramiento especializado.

28. Construir el term sheet de protección de la operación

El term sheet de protección debe enumerar cada exposición material, prueba, vía de flujo de caja, responsable del control, acción previa al cierre, respuesta contractual, prueba posterior al cierre y riesgo residual. Esto crea un documento de trabajo compartido entre los equipos comercial, técnico, jurídico, financiero, fiscal, regulatorio, de seguridad y de integración.

El term sheet debe preservar la distinción entre una respuesta comercial propuesta y la redacción jurídica aprobada. Puede identificar opciones, rangos de valoración y dependencias antes de que las partes acuerden el texto. Las decisiones y las alternativas rechazadas deben registrarse para respaldar la gobernanza.

El paquete final debe seguir siendo coherente internamente. Una reducción del precio de compra presupone que el comprador acepta y financia el riesgo. Un depósito en garantía presupone que puede definirse un evento recuperable. Un covenant presupone que la parte obligada puede cumplir. Una indemnización presupone que el proceso de pérdidas y reclamaciones es viable. Cada mecanismo necesita un plan operativo.

Las protecciones se seleccionan en función del momento, el control, la medibilidad y la gravedad.

Tabla 5. Term sheet ilustrativo de protección algorítmica de transacciones

Las condiciones requieren negociación específica para cada transacción y asesoramiento jurídico cualificado.

29. Alinear las protecciones con el control tras el cierre

Las condiciones de la transacción deben reflejar quién controla el resultado. El vendedor puede tener una capacidad limitada para cumplir una métrica de producto posterior al cierre después de que el comprador cambie modelos, personal, precios o clientes. El comprador puede tener una capacidad limitada para obtener el consentimiento de un proveedor antes del cierre. Un control desalineado genera disputas y debilita el diseño de incentivos.

La protección debe definir las acciones permitidas y exigidas, el acceso a la evidencia, la cooperación, los procedimientos de cambio y la resolución de disputas. Si el comprador necesita libertad para integrar, un precio fijo o un depósito en garantía pueden ser más sencillos que un earn-out técnico prolongado. Si el vendedor sigue operando el negocio, unas medidas de rendimiento definidas con cuidado pueden seguir siendo útiles.

La gobernanza debe incluir responsables de decisión designados y vías de escalado. Las discrepancias técnicas pueden requerir un experto independiente con acceso a los artefactos y a los métodos acordados. Los asesores jurídicos deben determinar cómo interactúa la determinación por experto con las reclamaciones contractuales.

30. Integrar sin destruir la evidencia

La integración posterior al cierre puede sobrescribir registros, repositorios, cuentas, versiones de modelos y configuraciones de clientes necesarios para validar garantías o earn-outs. El comprador debe preservar la evidencia relevante antes de cambiar los sistemas. La conservación debe respetar los requisitos de privacidad, seguridad, preservación legal y contractuales.

El plan de integración debe secuenciar la transferencia de accesos, la rotación de claves, la monitorización, la respuesta a incidentes, la remediación de derechos, la transición de personas y el cambio de plataforma. Las migraciones de alto riesgo deben utilizar hitos de aceptación y reversión. La mejora del producto puede comenzar pronto, mientras que los cambios que afectan a la medición o a las reclamaciones necesitan líneas base controladas.

El registro de riesgos de la operación se convierte en un libro de control de la integración. Cada protección debe asignarse a un responsable, un plazo, una evidencia y una decisión de liberación. Finanzas debe vincular el gasto y los resultados con el caso de valoración. Esto permite al consejo ver si el riesgo se eliminó, se transfirió, se aceptó o se materializó.

31. Gobernar los cambios de modelo y de proveedor después de la adquisición

El comprador debe establecer un proceso de cambio que abarque versiones de modelos, prompts, recuperación, herramientas, conjuntos de datos, umbrales, proveedores e infraestructura. Los cambios deben indicar el propósito, los usuarios afectados, la evidencia de evaluación, la evaluación de seguridad, el coste, el impacto regulatorio, la aprobación, la monitorización y la reversión. El nivel de control debe escalar con la materialidad.

Los avisos de los proveedores deben incorporarse al mismo proceso. Compras, ingeniería, producto, riesgo, legal y finanzas necesitan un registro común de cambios que puedan afectar a los resultados para los clientes y a la economía del negocio. La organización debe mantener mecanismos de respaldo probados para dependencias cuyo fallo supere el apetito de riesgo.

La gobernanza debe favorecer la velocidad mediante umbrales claros y evidencia reutilizable. Un comité lento que revise cada cambio de prompt puede generar prácticas en la sombra. Una delegación definida, pruebas estándar y vías de excepción pueden preservar la rendición de cuentas y permitir un desarrollo responsable.

32. Conectar las métricas operativas con la tesis de inversión

El cuadro de mando posterior al cierre debe vincular medidas técnicas, de clientes y financieras. Puede incluir rendimiento por cohorte relevante, disponibilidad, tasa de revisión, severidad de incidentes, concentración de proveedores, coste unitario, retención de clientes, beneficio bruto, gasto en remediación y finalización de hitos. Cada medida necesita un responsable, una definición, una fuente y un umbral de decisión.

Los indicadores adelantados deben vincularse con la acción del consejo. Un aumento del uso de alternativas puede preceder a una presión de costes. Un deterioro de la calidad de recuperación puede preceder a tickets de soporte. Una notificación de proveedor puede activar una evaluación y la comunicación con el cliente. El cuadro de mando debe registrar la decisión y el resultado en lugar de mostrar datos sin gobernanza.

Finanzas debe conciliar los efectos de caja realizados con el modelo de adquisición. Los beneficios y las pérdidas deben atribuirse con cuidado porque interactúan factores de integración, de mercado y algorítmicos. El objetivo es un aprendizaje disciplinado y una asignación de capital disciplinada, no una precisión artificial.

33. Aplicar disciplina contable y de deterioro

La tecnología adquirida, las relaciones con clientes, el fondo de comercio y otros activos requieren contabilización conforme al marco aplicable. La NIIF 3 regula el reconocimiento y la medición en combinaciones de negocios, mientras que la NIC 36 aborda el deterioro de los activos relevantes. La dependencia algorítmica, las restricciones de derechos, la pérdida de clientes o previsiones más débiles pueden orientar las hipótesis de flujos de caja y los indicadores de deterioro, con sujeción al juicio contable.

El modelo de diligencia debida debe conservar la evidencia utilizada en previsiones y valoraciones. El seguimiento posterior al cierre puede identificar cambios en el rendimiento, el coste, la vida útil o el beneficio económico. La dirección y los auditores necesitan hipótesis transparentes y conciliación.

Este documento no determina la clasificación contable, el valor razonable ni el deterioro. Contadores cualificados y especialistas en valoración deben aplicar las normas a los hechos de la transacción. El marco operativo les ayuda a localizar evidencia y trayectorias de flujos de caja.

34. Proporcionar a los prestamistas un escenario adverso algorítmico

Los prestamistas necesitan visibilidad sobre la calidad de los ingresos recurrentes, el margen bruto, la concentración, las necesidades de capital y la liquidez en escenarios adversos. Una empresa AI puede mostrar un crecimiento fuerte mientras depende de un proveedor que puede cambiar el precio o las condiciones. Por lo tanto, el modelo de financiación debe incluir escenarios de proveedor, deriva, cliente y remediación.

El margen disponible del covenant debe probarse tras costes de caja y retrasos realistas. Los ajustes EBITDA por remediación o integración puntual requieren escrutinio porque parte del gasto en tecnología y aseguramiento puede ser recurrente. Los prestamistas pueden solicitar protecciones en materia de información periódica, consentimiento, liquidez o seguro según el riesgo y la estructura.

El prestatario debe evitar detalles técnicos que oscurezcan las variables económicas relevantes. Un calendario conciso de dependencias y mitigación puede apoyar el análisis de crédito. La información sensible debe compartirse mediante controles adecuados y asesoramiento legal.

35. Utilizar un ejemplo práctico de transacción

Consideremos un comprador hipotético que evalúa una empresa AI de flujos de trabajo con ingresos recurrentes anuales de USD 30 million y un margen de contribución declarado del 58 por ciento. El producto depende de una única familia de modelos externos para el 72 por ciento de las solicitudes de producción, de un conjunto de datos propietario licenciado por tres fuentes y de seis empleados sénior que poseen conocimiento sobre lanzamientos o específico de clientes. Estas cifras son hipótesis ilustrativas.

La reproducción muestra que una cohorte de clientes de alto valor rinde por debajo de la afirmación agregada. Un escenario de precio del proveedor reduce el margen de contribución en cuatro puntos porcentuales. Una licencia de datos requiere consentimiento para la cesión, y dos capacidades de lanzamiento carecen de suplentes efectivos. El comprador estima un programa de remediación de doce meses y modela ingresos, margen, inversión y retraso sin tratar ninguna probabilidad supuesta como un hecho observado.

La respuesta de trabajo del comprador incluye un rango de valoración que refleja el escenario de deriva moderada, una condición de cierre para el consentimiento sobre datos relevantes, un covenant provisional sobre cambios de proveedor y modelo, un depósito en garantía medido para la subsanación de derechos y hitos de retención y transferencia de conocimiento. Asesores legales, contadores, especialistas en seguridad y reguladores pertinentes tendrían que asesorar sobre la transacción real.

36. Ejecutar la puerta de decisión del comité de inversiones

El comité de inversiones debe recibir la línea base del estado firmado, el mapa de dependencias, los escenarios de deriva, el waterfall de derechos, la evaluación de personas críticas, el term sheet de protección y el plan de integración financiado. El documento debe separar la evidencia observada, los supuestos analíticos, las opiniones de especialistas y las cuestiones no resueltas. Debe identificar qué exposiciones se aceptan, reducen, transfieren o son capaces de dar por terminada la transacción.

Los criterios de decisión pueden incluir el rango de valoración, la liquidez en escenarios adversos, la certeza de cierre, el perímetro operativo legal, la continuidad de clientes, la capacidad de integración y el encaje estratégico. El comité debe saber qué supuestos requieren verificación antes de la firma, antes del cierre y después de la transferencia de control.

La aprobación debe registrar condiciones, responsables y evidencia. Un riesgo aceptado implícitamente tiende a reaparecer como una sorpresa de integración. Una aceptación documentada respalda la rendición de cuentas y la revisión posterior.

El comité también debe recibir un puente de valor ajustado por dependencias. Este puente parte de la valoración independiente y muestra el efecto de la concentración de clientes, la exposición a proveedores, la remediación de derechos, la cobertura de personas críticas, la inversión en resiliencia y las sinergias retrasadas. Cada ajuste debe remitir a la evidencia de diligencia debida pertinente e indicar si cambia el flujo de caja esperado, los plazos, la liquidez o la durabilidad terminal. El puente ayuda a los revisores a cuestionar solapamientos e identificar dónde una protección contractual respalda la conclusión de valoración.

Una prueba de estrés inversa puede identificar la combinación de deriva, pérdida de clientes, aumento de costes y retraso en la remediación que agota la liquidez o incumple un umbral de financiación. El ejercicio es un escenario analítico, no una previsión. Muestra qué indicadores tempranos importan más y qué mitigaciones deben financiarse en el cierre. Cuando el escenario adverso depende de varios eventos correlacionados, el comité debe examinar sus causas comunes, incluyendo un único proveedor, conjunto de datos, persona o clasificación regulatoria.

37. Implementar los primeros 100 días

El Día uno debe asegurar autoridad, acceso, continuidad y respuesta a incidentes. Los primeros treinta días deben preservar la evidencia, conciliar activos y derechos, probar la monitorización, confirmar los compromisos con clientes y comenzar la transferencia de conocimiento. Los días treinta y uno a sesenta deben completar la remediación prioritaria, reproducir evaluaciones materiales y probar mecanismos de respaldo. Los días sesenta y uno a cien deben escalar solo los cambios que hayan superado las puertas de cliente, técnicas, de seguridad y económicas.

El cronograma debe adaptarse al riesgo de la transacción. Un producto regulado, una migración material de datos o la sustitución de un proveedor pueden requerir más tiempo. La celeridad del calendario nunca debe sustituir la evidencia de aceptación. Las excepciones deben indicar el control temporal, el responsable, el plazo y la exposición residual aceptada por un ejecutivo responsable.

El registro de protección de la transacción debe revisarse junto con los hitos de integración. Las liberaciones de depósitos en garantía, los cálculos de earn-out, los covenants y las garantías pueden depender de evidencia operativa. Los equipos jurídicos y financieros deben mantenerse conectados al trabajo técnico.

38. Mantener un repositorio de evidencia para el sistema adquirido

El comprador debe mantener un repositorio de evidencia controlado que contenga inventarios de arquitectura, modelos y datos, evaluaciones, licencias, contratos, consentimientos, aprobaciones, incidentes, monitorización, registros de cambios y compromisos con clientes. El acceso, la retención y el privilegio legal requieren un diseño cuidadoso. El repositorio debe apoyar las operaciones y el aseguramiento sin convertirse en una copia no controlada de datos sensibles.

La evidencia debe estar versionada y vinculada a las decisiones. Una ficha de modelo preparada después de la diligencia debida no debe sobrescribir el registro del estado firmado. Un consentimiento debe vincularse al conjunto de datos y al control técnico que autoriza. Una prueba de remediación debe identificar el entorno y la autoridad de aceptación.

La automatización puede ayudar a conciliar registros y detectar vínculos faltantes. Los especialistas humanos siguen siendo responsables de la interpretación y la aprobación. El repositorio de evidencia apoya la integración, las auditorías, la diligencia debida de clientes, la financiación y la preparación de una futura salida.

39. Concluir con una asignación disciplinada de la incertidumbre

Las transacciones de AI conllevan una incertidumbre operativa que no siempre puede eliminarse antes de la firma. Un proceso disciplinado hace visible esa incertidumbre, la conecta con el flujo de caja, asigna el control y elige una respuesta medible. El comprador obtiene una valoración y un plan de integración más defendibles. El vendedor obtiene solicitudes más claras y una vía para demostrar valor.

La secuencia básica es coherente: reproducir la línea base, mapear las dependencias, probar la deriva, evidenciar los derechos, evaluar a las personas y las obligaciones, modelar los efectos en caja, seleccionar las protecciones de la transacción y preservar las pruebas posteriores al cierre. Cada paso debe mantenerse proporcional a la materialidad y contar con el respaldo de especialistas cualificados.

Los consejos de administración deben rechazar las meras garantías de que un modelo es de propiedad exclusiva, preciso o transferible cuando la evidencia operativa está incompleta. También deben rechazar hallazgos técnicos que carecen de una vía hacia el flujo de caja. La transacción tiene éxito cuando los derechos legales, el control operativo, los resultados para el cliente y la economía financiada siguen alineados tras los cambios de control.

El marco debe seguir siendo proporcional. Una pequeña herramienta de productividad y un sistema de decisión regulado no requieren una diligencia debida idéntica. La materialidad puede fijarse a partir de los ingresos afectados, el perjuicio al cliente, la exposición regulatoria, el plazo de sustitución, la necesidad de caja y la importancia estratégica. El equipo puede profundizar las pruebas cuando convergen varios indicadores y documentar por qué las áreas de menor riesgo recibieron un trabajo limitado. Este enfoque basado en el riesgo protege la calidad de las decisiones y, al mismo tiempo, controla el coste de la diligencia debida y la carga de gestión.

Los compradores futuros deben esperar que el estándar de evidencia aumente a medida que maduren la regulación, las compras de los clientes y el aseguramiento técnico. Una empresa objetivo que mantiene evaluaciones reproducibles, derechos trazables, lanzamientos controlados, mecanismos de respaldo probados y conocimiento transferible puede reducir la fricción de la transacción. Esas capacidades también mejoran las operaciones ordinarias. Por lo tanto, la preparación para la transacción comienza antes de un proceso de venta, mediante una gobernanza que hace que el sistema sea comprensible, modificable y sujeto a rendición de cuentas.

Referencias

1. National Institute of Standards and Technology, Marco de Gestión de Riesgos de Inteligencia Artificial (AI RMF 1.0), 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
2. Instituto Nacional de Estándares y Tecnología, Marco de Gestión de Riesgos de Inteligencia Artificial: Perfil de Inteligencia Artificial Generativa, 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
3. Instituto Nacional de Estándares y Tecnología, Manual de implementación del RMF de AI. https://airc.nist.gov/airmf-resources/playbook/
4. Comisión Europea, Directrices sobre las obligaciones de los proveedores de AI de uso general, 2025. https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
5. Comisión Europea, Directrices sobre el alcance de las obligaciones de los proveedores de modelos de AI de uso general, 2025. https://digital-strategy.ec.europa.eu/en/library/guidelines-scope-obligations-providers-general-purpose-ai-models-under-ai-act
6. Comisión Europea, Modelos de AI de uso general en el Reglamento de AI: preguntas y respuestas. https://digital-strategy.ec.europa.eu/en/faqs/general-purpose-ai-models-ai-act-questions-answers
7. Comisión Europea, marco regulatorio del Reglamento de AI. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
8. Comisión Europea, Código de prácticas de AI de uso general. https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
9. Banco Central de UAE, Nota de Orientación sobre la Protección del Consumidor y la Adopción y Uso Responsables de la Inteligencia Artificial y el Aprendizaje Automático, 2026. https://rulebook.centralbank.ae/en/rulebook/guidance-note-consumer-protection-and-responsible-adoption-and-use-artificial-intelligence
10. Centro Nacional de Ciberseguridad del Reino Unido, Directrices para el desarrollo seguro de sistemas de AI, 2023. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
11. Autoridad de Competencia y Mercados del Reino Unido, Modelos fundacionales de AI: documento de actualización, 2024. https://www.gov.uk/government/publications/ai-foundation-models-update-paper
12. Autoridad de Competencia y Mercados del Reino Unido, Directrices para la evaluación de fusiones, 2021. https://www.gov.uk/government/publications/merger-assessment-guidelines
13. Departamento de Justicia y Comisión Federal de Comercio de los Estados Unidos, Directrices sobre fusiones, 2023. https://www.justice.gov/atr/2023-merger-guidelines
14. Oficina del Comisionado de Información del Reino Unido, Guía sobre AI y protección de datos. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
15. Organización para la Cooperación y el Desarrollo Económicos, Principios de AI de la OCDE. https://oecd.ai/en/ai-principles
16. Organización Internacional de Normalización, ISO/IEC 42001 Sistema de gestión de inteligencia artificial. https://www.iso.org/standard/81230.html
17. Organización Internacional de Normalización, ISO/IEC 23894 Gestión de riesgos de inteligencia artificial. https://www.iso.org/standard/77304.html
18. Fundación IFRS, NIIF 3 Combinaciones de negocios. https://www.ifrs.org/issued-standards/list-of-standards/ifrs-3-business-combinations/
19. Fundación IFRS, NIC 36 Deterioro del valor de los activos. https://www.ifrs.org/issued-standards/list-of-standards/ias-36-impairment-of-assets/
20. Panel de Adquisiciones del Reino Unido, Código de Adquisiciones. https://www.thetakeoverpanel.org.uk/the-code/download-code
21. Agencia de la Unión Europea para la Ciberseguridad, Marco multicapa para buenas prácticas de ciberseguridad para AI, 2023. https://www.enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai
22. Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU., Hoja de ruta para la inteligencia artificial, 2023. https://www.cisa.gov/resources-tools/resources/roadmap-artificial-intelligence
23. Comisión de Bolsa y Valores de EE. UU., Gestión de riesgos de ciberseguridad, estrategia, gobernanza y divulgación de incidentes, 2023. https://www.sec.gov/files/rules/final/2023/33-11216.pdf
24. Consejo de Estabilidad Financiera, Implicaciones de la inteligencia artificial para la estabilidad financiera, 2024. https://www.fsb.org/2024/11/the-financial-stability-implications-of-artificial-intelligence/
25. Banco de Pagos Internacionales, Instituto de Estabilidad Financiera, Regulación de AI en el sector financiero: novedades recientes y principales retos, 2024. https://www.bis.org/fsi/fsipapers24.htm