Lista de comprobación de due diligence técnica para MVP de IA antes de financiar

La due diligence técnica de un MVP de IA examina las mismas capas que cualquier revisión de desarrollo de software a medida, incluido código, infraestructura, seguridad, dependencias y riesgo de equipo. También debe comprobar evidencia específica de IA: diseño de evaluación, configuración de prompts y modelos, trazas respetuosas con la privacidad, comportamiento ante fallos, economía por tarea y derechos sobre datos de entrenamiento o recuperación. Una demo y unas pocas salidas seleccionadas no demuestran rendimiento sobre la carga prevista. Un proceso de evaluación versionado, con casos representativos y registros reproducibles, ofrece evidencia inspeccionable.

Esta es una lista de ingeniería, no asesoramiento jurídico, de inversión ni de aseguramiento. Las solicitudes de evidencia varían según comprador, inversor, sector y transacción. Volvimos a comprobar las referencias regulatorias y normativas el 2 de septiembre de 2026.

¿Quiere una DD técnica independiente antes de su ronda?

Reservar consulta gratuita

Por qué evidencia, no una demo

Los resultados de benchmarks dependen de la carga, pero muestran por qué una demo no basta. Un estudio prerregistrado de Stanford con más de 200 consultas jurídicas abiertas informó, en el momento de la prueba, información incorrecta en más del 17% de respuestas de Lexis+ AI y Ask Practical Law AI y en más del 34% de Westlaw AI-Assisted Research. Estas cifras no se trasladan a otro dominio ni a versiones actuales. Sí muestran que una interfaz especializada no demuestra fiabilidad por sí sola. El revisor necesita mediciones sobre el uso previsto y previsible del producto, con incertidumbre, fallos y límites documentados. Véanse el resumen y estudio de Stanford.

Comprobaciones específicas de IA que añadir

Estas comprobaciones amplían la revisión normal de software. Cada punto indica qué inspeccionar y una señal de alarma.

Un conjunto de evaluación. Una muestra versionada de usos previstos, casos límite, no respondibles, adversarios y subgrupos relevantes, con etiquetas o rúbricas y justificación del muestreo. Los tests unitarios siguen sirviendo para propiedades deterministas; las salidas juzgadas también necesitan puntuación calibrada. Señal de alarma: solo ejemplos seleccionados, sin análisis de cobertura o incertidumbre.
Evaluación de regresión. Ejecute la suite relevante ante cambios materiales de prompt, recuperación, modelo, política o herramientas antes de lanzar y supervise señales de producción. La cadencia y las reglas bloqueantes deben reflejar la gravedad de las consecuencias. Señal de alarma: cambios de comportamiento sin comparación con la base aprobada.
Observabilidad respetuosa con la privacidad. Registre los metadatos mínimos para investigar calidad, seguridad, latencia y coste. Los prompts y respuestas pueden contener datos personales, confidenciales o privilegiados, por lo que debe justificar, redactar, restringir y caducar su contenido. Señal de alarma: ninguna trazabilidad o registro de contenido ilimitado e indefinido.
Registros de prompt, modelo y configuración. Versione prompts, ajustes de recuperación, políticas, herramientas e identificadores de modelo. El proveedor puede cambiar el comportamiento con un identificador estable; conserve resultados y metadatos de release en vez de prometer reproducción exacta. Señal de alarma: no se sabe qué configuración sirvió un incidente.
Gestión de fallos. Defina timeouts, reintentos acotados, comportamiento degradado, escalado humano y objetivos de recuperación. Un segundo proveedor es una opción, no un requisito universal, y añade riesgos de coste y consistencia. Señal de alarma: una dependencia externa puede fallar sin una ruta probada para el usuario.
Economía por tarea. Mida costes de entrada, salida, caché, herramientas, medios, reintentos y revisión humana por tarea completada, incluida la distribución real de llamadas. Señal de alarma: previsiones de margen con una única llamada ideal o precios invariables.
Derechos y uso lícito de datos. Conserve procedencia, licencia u otra base, restricciones contractuales, consentimiento si se invoca, deberes de borrado y usos permitidos de entrenamiento o recuperación por fuente. Señal de alarma: corpus extraído sin explicación o datos sin origen trazable.
Modos de fallo y controles medidos. Informe categorías de error, gravedad e intervalos de confianza por tarea y conecte cada riesgo material con recuperación, validación, rechazo, escalado u otro control probado. Señal de alarma: "RAG arregla las alucinaciones" o una cifra agregada sin análisis.
Elección de modelo y riesgo de concentración. Documente por qué modelo y alojamiento cumplen calidad, privacidad, disponibilidad, jurisdicción y coste. Pruebe portabilidad donde importe, sin asumir que una abstracción hace intercambiables a los proveedores. Señal de alarma: sin plan de salida ante un cambio material.

Artefactos que preparar en la sala de evidencias

La lista exacta varía, pero estos artefactos permiten probar afirmaciones sin depender de la memoria de un fundador. Su presencia no garantiza financiación ni valoración.

Artefacto	Por qué le importa a la due diligence	Señal de alarma si falta
Diagrama de arquitectura (fechado, nombra dependencias externas)	Permite revisar límites de confianza, supuestos de escala, concentración y riesgo de persona clave	Dependencias u ownership materiales sin aclarar
Mapa de flujo de datos e inventario de tratamiento	Muestra qué datos recibe cada parte, por qué, dónde y durante cuánto tiempo	No se explican flujos personales o confidenciales
Informes de evaluación (harness, dataset, configuración y resultados versionados)	Permiten revisar cobertura, incertidumbre, fallos y decisiones de regresión	Solo ejemplos elegidos o una cifra agregada sin explicar
Registro de modelos, prompts, recuperación, políticas y herramientas	Vincula una release o incidente a su configuración de servicio	El comportamiento no se puede atribuir a una configuración
Runbook, objetivos de servicio y respuesta a incidentes	Muestra ownership, detección, escalado, recuperación y comunicación	Rutas de fallo y responsables sin probar
SBOM actual, revisión de licencias y proceso de vulnerabilidades	Facilita revisar dependencias, licencias y vulnerabilidades conocidas	Dependencias y responsabilidad de remediación desconocidas
Cadena de derechos de PI y datos	Muestra derechos sobre contribuciones, código abierto, modelos y datasets según contrato y ley	Un activo central sin propietario o uso permitido documentado
Evidencia de seguridad basada en riesgo	Puede incluir modelo de amenazas, desarrollo seguro, pruebas y aseguramiento independiente relevante	Las afirmaciones no corresponden a amenazas y controles

Datos, privacidad y procedencia

Para despliegues en la UE, asigne las obligaciones del RGPD al tratamiento y los roles reales. Pueden incluir registros cuando los exige el artículo 30, una base jurídica, una EIPD del artículo 35 antes de tratamientos que probablemente entrañen alto riesgo para derechos y libertades, y términos del artículo 28 cuando exista una relación de encargado. Un proveedor de modelos puede ser responsable, encargado o subencargado según hechos y contratos. La Opinión 28/2024 del EDPB exige evaluar el anonimato caso por caso. Conforme al EU AI Act modificado, el artículo 50 contiene deberes de transparencia específicos de rol y sistema, aplicables en su mayoría desde el 2 de agosto de 2026. Las reglas de alto riesgo del anexo III aplican desde el 2 de diciembre de 2027 y las integradas en productos del anexo I desde el 2 de agosto de 2028. Documente clasificación, rol, deber y fecha aplicables.

Preguntas que un revisor puede comprobar

Un revisor puede comprobar si el producto depende de un modelo o proveedor, si la diferenciación alegada tiene evidencia, si el margen incluye todos los costes de inferencia y revisión, si la retención está medida y si los resultados reflejan producción. Documentos, retención, declaraciones e indemnizaciones dependen de cada acuerdo, por lo que una lista genérica no predice términos. Las cuestiones de seguridad y propiedad en código asistido por IA están en nuestro artículo sobre due diligence de Lovable, Bolt y Replit; el diseño de evaluación, en cuándo merece la pena construir evals de LLM.

"Una demo muestra un camino. Un proceso de evaluación gobernado muestra qué carga se midió, con qué frecuencia falla y si una release cambió el resultado. Esa es evidencia que un revisor puede inspeccionar."

Preguntas frecuentes

¿Qué es la due diligence técnica para una startup de IA?

Una revisión acotada de código, infraestructura, seguridad, dependencias, flujos de datos, comportamiento de IA, evidencia operativa y riesgos de equipo. Puede añadir diseño de evaluación, registros de configuración de servicio, economía por tarea, controles de fallo, privacidad y derechos sobre datos y modelos. No certifica que la empresa escale o esté jurídicamente limpia.

¿Qué podría comprobar un revisor en un MVP de IA?

La solicitud depende de transacción y sector. Áreas comprobables habituales son concentración de proveedor, evidencia de diferenciación y calidad, economía completa de inferencia, controles de privacidad y seguridad, retención medida, preparación ante incidentes y derechos sobre código, modelos y datos.

¿Qué evidencia de evaluación debo preparar?

Dataset y rúbrica representativos y versionados, justificación del muestreo, resultados ligados a la configuración, análisis de incertidumbre y subgrupos, fallos materiales, umbrales, historial de regresión y vínculos a monitorización. La revisión humana puede formar parte del método; las comprobaciones puntuales sin documentar no son reproducibles.

¿En qué se diferencia la due diligence de IA de la de software normal?

Conserva la revisión de código, infraestructura, seguridad, dependencias y equipo. Añade comportamiento variable del modelo, cobertura de evaluación, configuración de prompts y servicio, costes por tarea, concentración de modelos externos, gestión de fallos, trazas respetuosas con la privacidad y derechos y restricciones de datos.

¿Necesito un SBOM para la due diligence?

Es útil cuando las dependencias son materiales. Mantenga un SBOM actual en formato estándar legible por máquina, valídelo contra el build y acompáñelo de procesos de licencias y vulnerabilidades. Cuando las reglas correspondientes del Cyber Resilience Act apliquen desde el 11 de diciembre de 2027, los productos incluidos deberán contener un SBOM en su documentación técnica, en formato habitual legible por máquina y al menos para dependencias de primer nivel. No cubre todo MVP o transacción.

¿Qué es la cadena de derechos de PI y datos?

Evidencia de quién posee o puede usar código, datasets, modelos, medios y otros activos conforme a ley y contratos. Las reglas de software de la UE distinguen programas de empleados de otras autorías, y los contratos de proveedores varían. Revise cesiones o licencias, código abierto, términos de modelos y permisos de datasets con asesoría, sin asumir que una factura resuelve la titularidad.

¿Cómo afecta el RGPD a la due diligence de IA en la UE?

Mapee registros del artículo 30 cuando se exijan, bases jurídicas y condiciones del artículo 9, EIPD del artículo 35 para tratamiento probablemente de alto riesgo, derechos, transferencias, retención, seguridad y términos del artículo 28. El rol del proveedor depende de hechos y contratos. La Opinión 28/2024 exige evaluación individual antes de considerar anónimo un modelo.

¿Se aplica ya el EU AI Act a mi MVP?

Depende de sistema y rol. Aplican las prohibiciones, pueden aplicar obligaciones de proveedor GPAI y el artículo 50 contiene deberes específicos, en su mayoría desde el 2 de agosto de 2026. Las reglas del anexo III aplican desde el 2 de diciembre de 2027 y las integradas en productos del anexo I desde el 2 de agosto de 2028.

¿Es diferente la due diligence técnica en Austria?

El método técnico es similar, pero los hechos corporativos, laborales, de PI, financiación, impuestos y regulación austriacos requieren revisión local. Si hay financiación pública, aporte el acuerdo, costes elegibles, informes, cambio de control y reembolso aplicables, sin asumir una cláusula estándar.

¿Cómo muestro que mi producto es más que un envoltorio de modelo?

No dependa de la etiqueta. Muestre resultados de usuario medidos, profundidad de flujo e integración, activos permitidos o propietarios donde existan, conocimiento operativo, retención, portabilidad probada y economía con uso y escenarios de precio realistas.

Reflexiones finales

La due diligence técnica de un MVP de IA es más amplia que una revisión genérica de código. La capa específica debe conectar evidencia de evaluación, configuraciones de servicio, economía por tarea, controles de fallo, privacidad y derechos sobre datos y modelos con las afirmaciones del producto.

Prepare la evidencia antes: gobierne el set, registre releases, pruebe fallos, calcule costes desde trazas reales, documente derechos y mantenga artefactos actuales. No convierte la revisión en trámite, pero hace comprobables las afirmaciones y visibles los huecos cuando aún hay tiempo de corregirlos.

¿Quiere el conjunto de evals y los artefactos listos antes de levantar capital?

Reservar consulta gratuita

Fuentes primarias de esta guía de diligence

Esta lista se apoya en referencias públicas de riesgo de IA, desarrollo seguro, privacidad, seguridad de producto y Derecho de la UE.