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 software (código, infraestructura, seguridad, equipo) más un conjunto de comprobaciones específicas de IA que un generalista pasa por alto: ¿tiene un conjunto de evaluación y evals de regresión, están versionados los prompts y los modelos, registra cada llamada al modelo, qué ocurre cuando el modelo falla, cuánto cuesta de verdad una inferencia, y tiene los derechos sobre los datos con los que entrena o recupera. Lo único que separa un MVP de IA financiable de una demo es la evidencia. Los inversores tratan cada vez más una suite de evals privada y versionada como la prueba de que su IA funciona. "Lo probamos a mano" no supera ese listón. Esta es la lista que debe pasarse a sí mismo antes de que se la pasen a usted.

Esta es una visión de ingeniería dirigida a fundadores, con las preguntas del inversor hechas explícitas. Las fechas regulatorias son válidas a mediados de 2026; una en particular es una trampa si planifica en torno a un retraso que no ha ocurrido, señalado más abajo.

Por qué evidencia, no una demo

Dos hallazgos independientes marcan el listón. Un estudio de Stanford sobre herramientas de IA jurídica creadas a medida, del tipo que se vende como preciso, midió aun así alucinaciones en más del 17 por ciento de las consultas de referencia en algunos productos y en más del 34 por ciento en otros. Y un informe vinculado al MIT, muy citado en 2025, halló que alrededor del 95 por ciento de los pilotos empresariales de IA generativa no produjeron un impacto medible en la cuenta de resultados. La lección para un fundador que levanta capital es rotunda: una demo que funciona no prueba casi nada, y el inversor lo sabe. Lo que mueve una ronda es la evidencia medida de que su sistema funciona, no regresiona y es económica y legalmente sólido a escala.

Las comprobaciones específicas de IA que un generalista pasa por alto

Este es el núcleo del artículo y la parte que una revisión de software genérica se salta. Para cada una: qué comprobar, por qué importa y la señal de alarma.

1. Un conjunto de evaluación. Un dataset dorado versionado más una rúbrica de puntuación. Los tests unitarios le dicen verde o rojo; no pueden decirle si una respuesta fue correcta o fiel a la fuente. Señal de alarma: "revisamos las salidas a ojo", sin conjunto dorado, sin cifras.
2. Evals de regresión como puerta de CI. La suite de evals se ejecuta en cada cambio de prompt o de modelo antes del deploy. El mismo prompt da una salida distinta cuando cambia la versión del modelo o la entrada, y un arreglo para un caso rompe en silencio otro. Señal de alarma: los cambios de prompt van directos a producción.
3. Observabilidad de las llamadas al modelo. Trazado de cada llamada al modelo, con contabilidad de tokens y coste y captura del prompt y la respuesta. No puede depurar una mala respuesta que no puede reconstruir. Señal de alarma: "usamos el panel del proveedor" como toda la historia.
4. Versionado de prompts y modelos. Los prompts son artefactos versionados y el modelo está fijado, no llamado como "latest", que se autoactualiza sin avisar. Señal de alarma: prompts codificados en línea, modelo apuntando a latest.
5. Un fallback cuando el modelo falla. Reintentos, un modelo o proveedor secundario, degradación elegante. Su disponibilidad ahora está limitada por una API de terceros. Señal de alarma: un proveedor, un modelo, sin timeout ni ruta degradada, de modo que una caída del proveedor es una caída total.
6. Economía unitaria por inferencia. Coste modelado por llamada, luego por acción, y luego dentro del margen bruto. Los flujos agénticos despliegan una acción en cientos de llamadas. Señal de alarma: ninguna métrica de coste por acción y un margen que se asume "tipo SaaS".
7. Derechos sobre los datos de entrenamiento y recuperación. Procedencia documentada y una licencia o permiso por fuente. La pregunta ya no es "¿es uso legítimo?" sino "¿puede probar de dónde vino cada dato y que se obtuvo de forma lícita?". Señal de alarma: datos extraídos de origen desconocido, un corpus de RAG sin derechos de uso.
8. Una tasa de alucinación medida más guardarraíles. Una tasa de error sobre un benchmark del dominio, más anclaje por recuperación y validación de la salida. Señal de alarma: ninguna tasa medida y "RAG arregla las alucinaciones" afirmado como si estuviera resuelto.
9. Elección de modelo y dependencia. Una justificación para API propietaria frente a pesos abiertos, y una capa de abstracción que le permita cambiar de proveedor. Señal de alarma: acoplado de forma rígida al SDK de un solo proveedor, con una economía que solo funciona al precio subvencionado de hoy.

Los artefactos de traspaso que un MVP de IA financiable tiene listos

Si existen, la due diligence es rápida y su valoración se mantiene. Si viven solo en la cabeza de un fundador, cada hueco se convierte en un descuento.

Datos, privacidad y procedencia

Para un MVP de IA en la UE, aquí es donde se revalúan los acuerdos. La due diligence comprueba su registro de actividades de tratamiento (RGPD Artículo 30), una base jurídica para entrenar con datos personales (Artículos 6 y 9, con una evaluación de interés legítimo archivada), una evaluación de impacto sobre protección de datos antes de un tratamiento de alto riesgo (Artículo 35) y acuerdos de tratamiento de datos con los subencargados. Tenga en cuenta algo que los fundadores pasan por alto: una API de modelo que ingiere los prompts de sus usuarios es un subencargado, así que necesita un DPA y una configuración de no entrenamiento y retención cero, no condiciones de consumo. La Opinión 28/2024 del EDPB también advierte de que un modelo entrenado con datos personales no es automáticamente anónimo, de modo que datos de entrenamiento ilícitos pueden contaminar el producto desplegado. Sobre el EU AI Act, la fecha vinculante vigente para la mayoría de las obligaciones de alto riesgo y transparencia es el 2 de agosto de 2026. En 2026 circulaba una propuesta para aplazarla, pero no está promulgada, y un plan de cumplimiento que apueste por el aplazamiento es en sí mismo una señal de alarma.

Lo que los inversores señalan de verdad

Desde el lado del inversor y del comprador, y estas fuentes son partes interesadas, así que pondérelas como tales, las señales recurrentes son: un envoltorio fino sobre un solo modelo sin profundidad de flujo de trabajo; un foso débil (los duraderos hoy son datos propietarios o con permiso, integraciones y contexto persistente, no el modelo base); el margen bruto tras el coste de inferencia, ya que la inferencia es un coste variable real que rompe la suposición de margen SaaS; retención frágil cuando los costes de cambio son bajos; y, cada vez más, la ausencia de evals continuos privados. En cuanto a la adquisición en concreto, espere cláusulas de retención sobre los ingenieros de IA clave e indemnizaciones ligadas a las declaraciones sobre la procedencia de los datos. El ángulo del vibe-coding de todo esto, seguridad, propiedad de la PI y qué comprueba un comprador en el código generado por IA, es una lista propia en nuestro artículo sobre due diligence de Lovable, Bolt y Replit, y la disciplina de evals que sustenta los puntos uno y dos está en cuándo merece la pena construir evals de LLM.

"Una demo prueba que puede obtener una buena respuesta una vez. Un conjunto de evals prueba que obtiene buenas respuestas de forma consistente y que se dará cuenta cuando dejen de serlo. Los inversores dejaron de impresionarse con lo primero y empezaron a pedir lo segundo. Ese cambio es todo el juego en la due diligence de IA."