--- title: "Due diligence técnica para MVP de IA" canonical: https://wavect.io/es/blog/technical-due-diligence-ai-mvp/ language: es description: "Due diligence técnica para MVPs de IA: evaluación, configuración, economía por tarea, seguridad, privacidad, derechos de datos y EU AI Act." image: "https://wavect.io/img/blog/headers/header_technical-due-diligence-ai-mvp.png" author: ["Kevin Riedl"] published: "2026-06-16" updated: "2026-09-02" reviewed: "2026-09-02" --- # Lista de comprobación de due diligence técnica para MVP de IA antes de financiar [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min de lectura · 16 Jun 2026 Última revisión 2 de septiembre de 2026 [**Siguiente**](/es/blog/llm-evaluation-cost-roi-production/) Resumen La due diligence de un MVP de IA añade evidencia específica del modelo: evaluación representativa y versionada, registros de configuración, observabilidad respetuosa con la privacidad, fallos probados, costes por tarea y derechos documentados sobre código, modelos y datos. Prepara arquitectura y flujos actuales, informes, registros, evidencia de dependencias y vulnerabilidades y la cadena de derechos aplicable. Los requisitos varían por transacción. El artículo 50 del EU AI Act depende de sistema y rol; las fechas modificadas de alto riesgo son el 2 de diciembre de 2027 para el anexo III y el 2 de agosto de 2028 para el anexo I. La due diligence técnica de un MVP de IA examina las mismas capas que cualquier revisión de [desarrollo de software a medida](/es/services/software-development/), 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. ## 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](https://hai.stanford.edu/news/ai-trial-legal-models-hallucinate-1-out-6-or-more-benchmarking-queries%26quot). ## 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. 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. 6. **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. 7. **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. 8. **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. 9. **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](https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en) exige evaluar el anonimato caso por caso. Conforme al [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689) 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](/es/blog/lovable-bolt-replit-app-due-diligence/); el diseño de evaluación, en [cuándo merece la pena construir evals de LLM](/es/blog/llm-evaluation-cost-roi-production/). ![Kevin Riedl](/img/team/kevin.webp) "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. ## También te puede gustar.. [**Cuándo merece la pena construir evals de LLM** Cómo combinar comprobaciones deterministas, evaluación de modelos calibrada y revisión humana, y decidir cuándo el harness vale su coste.](/es/blog/llm-evaluation-cost-roi-production/) [**Habilitación de IA frente a una consultora de IA genérica** Compare el alcance de asesoría con una implementación que su equipo pueda poseer y operar.](/es/compare/ai-enablement-vs-generic-ai-consultancy/) ## 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. - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [NIST Secure Software Development Framework](https://csrc.nist.gov/projects/ssdf) - [OWASP LLM Security Verification Standard](https://owasp.org/www-project-llm-verification-standard/) - [Opinión 28/2024 del EDPB sobre modelos de IA](https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en) - [EU Cyber Resilience Act](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) - [Directiva 2009/24/CE sobre programas de ordenador](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32009L0024) Validación de MVP ## Qué leer después Comprobar demanda, pilotos y viabilidad técnica antes de ampliar la inversión. [Empieza aquí**Cómo validar una idea SaaS B2B en DACH**](/es/blog/validate-b2b-saas-idea-dach/) - [Solicitud a Y Combinator: checklist técnico para startups](/es/blog/yc-application-technical-readiness-checklist/) - [Cómo validar una idea SaaS B2B en DACH](/es/blog/validate-b2b-saas-idea-dach/) - [Piloto de Pago vs PoC vs Design Partner: ¿Qué Valida Demanda?](/es/blog/paid-pilot-vs-poc-vs-design-partner/) - [El MVP ha muerto. Construye un producto mínimo creíble.](/es/blog/minimum-credible-product/) [Artículo anterior**El MVP ha muerto. Construye un producto mínimo creíble.**](/es/blog/minimum-credible-product/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min de lectura · 16 Jun 2026 Última revisión 2 de septiembre de 2026 [**Siguiente**](/es/blog/llm-evaluation-cost-roi-production/)