La respuesta rápida: evaluar un proveedor de IA significa pedir evidencia en lugar de promesas. Antes de firmar, quiere cuatro cosas por escrito: resultados de pruebas independientes que pueda verificar, términos claros sobre cómo se utilizan y conservan sus datos, un compromiso de monitorear el sistema después de la activación, y una forma de verificar cada afirmación de seguridad que hace el proveedor sin aceptar su palabra. El resto de esta guía convierte eso en un proceso funcional, una lista de preguntas que puede enviar a los proveedores, y los términos contractuales que hacen que las respuestas sean vinculantes.

La diligencia debida en IA difiere de la revisión ordinaria de software porque un sistema de IA puede producir una respuesta confiadamente incorrecta, ser convencido de abandonar sus propias reglas, filtrar datos, o cambiar comportamiento después de una actualización de modelo que el proveedor implementa un martes. Encuentra esos riesgos probando comportamiento, y los controla con términos contractuales que dicen qué sucede cuando el comportamiento se desvía.

Por qué la diligencia debida en proveedores de IA es ahora una expectativa formal

Comprar IA solía tratarse como una compra de software con un párrafo extra sobre datos. Los compradores públicos y legisladores en ambos lados del Atlántico han cambiado eso.

Compradores federales de EE.UU.: memorándum OMB M-25-22

El 3 de abril de 2025, la Oficina de Administración y Presupuesto de la Casa Blanca emitió el memorándum M-25-22, Driving Efficient Acquisition of Artificial Intelligence in Government. Se aplica a contratos adjudicados conforme a solicitudes emitidas 180 días o más después del memorándum, y a opciones de renovación ejercidas después de ese momento. La Sección 4(d) dice que las agencias "deben incluir términos que aborden" una lista de temas en contratos para sistemas y servicios de IA. Entre ellos:

• Monitoreo continuo del desempeño. Los contratos deben permitir que la agencia monitoree y evalúe regularmente el desempeño, riesgos y efectividad del sistema, con revisiones trimestrales o bianuales como ejemplos.
• Pruebas independientes. Las agencias deben probar con sus propios conjuntos de datos que "no deben ser accesibles al proveedor", los proveedores deben proporcionar "el acceso y tiempo necesarios para que las agencias completen la evaluación independiente", y los resultados de pruebas deben ser "lo suficientemente detallados para que las pruebas sean independientemente verificables o reproducibles, si es practicable."
• Protección contra bloqueo. Los términos pueden incluir transferencia de conocimiento, "portabilidad de datos y modelos", y transparencia en licencias y precios.
• Límites en el entrenamiento con sus datos. La Sección 3(e) requiere que los contratos "prohíban permanentemente el uso de datos de entrada no públicos de la agencia y resultados generados" para entrenar más IA disponible públicamente o comercialmente, a menos que la agencia consienta explícitamente.
• Aviso antes de cambios. Las agencias deben considerar requerir a los proveedores que las notifiquen antes de integrar nuevas mejoras de IA, y se les anima a requerir que los proveedores cumplan con estándares de desempeño antes de desplegar nuevas versiones y a revertir si es necesario.

Un segundo memorándum, OMB M-26-04 del 11 de diciembre de 2025, dice que "complementa" M-25-22. Para contratos de modelos de lenguaje de gran escala, enumera información que las agencias deben solicitar a los proveedores: una política de uso aceptable, fichas de modelo, sistema o datos, recursos para usuarios finales, y un mecanismo para comentarios de usuarios finales. También permite que las agencias soliciten más, como resultados de evaluación.

Estos memorándums vinculan a las agencias federales, no a empresas privadas. Aun así, constituyen la declaración pública más detallada de lo que un comprador sofisticado de IA solicita, y los equipos de adquisiciones privadas pueden tomar prestada su estructura directamente.

Usuarios de la UE: lo que la Ley de IA pide al comprador

La EU AI Act, Regulación (UE) 2024/1689, llama a la organización que utiliza un sistema de IA bajo su propia autoridad "usuario". Si compra un sistema de IA de alto riesgo y lo pone en funcionamiento, el artículo 26 le impone obligaciones, separadas de las obligaciones del proveedor. En el texto refundido publicado en la Mesa de Asistencia de la Ley de IA de la Comisión Europea, el artículo 26 dice:

• Los usuarios "tomarán las medidas técnicas y organizativas apropiadas para garantizar que utilicen tales sistemas de conformidad con las instrucciones de uso que acompañan a los sistemas" (Artículo 26(1)).
• Los usuarios "asignarán supervisión humana a personas físicas que tengan la competencia, capacitación y autoridad necesarias" (Artículo 26(2)).
• Los usuarios "supervisarán el funcionamiento del sistema de IA de alto riesgo sobre la base de las instrucciones de uso", y si tienen motivos para pensar que el sistema presenta un riesgo, deben informar al proveedor o distribuidor y a la autoridad competente de vigilancia del mercado e interrumpir el uso (Artículo 26(5)).
• Los usuarios "guardarán los registros generados automáticamente por ese sistema de IA de alto riesgo" en la medida en que esos registros estén bajo su control, durante al menos seis meses a menos que otra ley disponga lo contrario (Artículo 26(6)).
• Los usuarios de sistemas del Anexo III que toman o ayudan en decisiones sobre personas "informarán a las personas físicas de que están sujetas al uso del sistema de IA de alto riesgo" (Artículo 26(11)).

Cada una de esas obligaciones depende de algo que solo puede obtener del proveedor. No puede seguir instrucciones de uso que nunca recibió, guardar registros que el sistema no exporta, o supervisar comportamientos que no tiene forma de medir. El artículo 13 es el lado del proveedor del mismo acuerdo: los sistemas de alto riesgo deben incluir instrucciones de uso que incluyan, entre otras cosas, "el nivel de precisión, incluidas sus métricas, robustez y ciberseguridad" (Artículo 13(3)(b)(ii)). La debida diligencia es donde confirma que esos materiales existen y son lo suficientemente buenos para que usted cumpla su parte.

El tiempo es importante. Conforme a las enmiendas del Omnibus Digital, el artículo 113 ahora aplica las normas de alto riesgo a partir del 2 de diciembre de 2027 para sistemas independientes listados en el Anexo III y a partir del 2 de agosto de 2028 para IA integrada en productos cubiertos por el Anexo I. Los contratos que firme hoy a menudo seguirán en vigor en esas fechas, por lo que tiene sentido escribir las obligaciones ahora. Aparte, el artículo 4 pide a proveedores y usuarios de sistemas de IA en general, no solo de alto riesgo, que "tomen medidas para apoyar el desarrollo de alfabetismo en IA" del personal que los opera y utiliza. Para una visión legal más completa, consulte nuestra guía completa sobre la EU AI Act y leyes de IA estadounidenses.

Los marcos voluntarios apuntan en la misma dirección

El núcleo del NIST AI RMF da a la IA de terceros su propia categoría. GOVERN 6.1 dice "Las políticas y procedimientos están en vigor para abordar los riesgos de IA asociados con entidades de terceros", GOVERN 6.2 dice "Los procesos de contingencia están en vigor para manejar fallos o incidentes en datos de terceros o sistemas de IA considerados de alto riesgo", y MANAGE 3.1 dice que los riesgos de recursos de terceros deben ser "monitoreados regularmente, y los controles de riesgo se aplican y documentan". Si su organización ya se alinea con el NIST AI RMF o ejecuta un sistema de gestión ISO/IEC 42001, la debida diligencia con proveedores es cómo cumple esas expectativas para la IA que compra. Nuestra guía sobre NIST AI RMF, ISO/IEC 42001 y estándares relacionados cubre cómo se integran los marcos.

Las seis áreas a evaluar

Toda revisión de proveedor de IA se reduce a seis áreas.

1. Qué es el sistema y para qué sirve

Comience con el alcance. ¿Qué modelos subyacen al producto, y es el proveedor su desarrollador o un revendedor que envuelve el de otro? ¿Qué propósito previsto documenta el proveedor, y su uso planeado cae dentro de él? Conforme a la EU AI Act, el propósito previsto es el primer elemento que las instrucciones de uso deben indicar, y usar un sistema fuera de él significa asumir riesgos que el proveedor nunca probó.

2. Evidencia de comportamiento seguro

Esta es el área que la mayoría de los compradores manejan peor, porque es la más difícil de preguntar en un cuestionario. "¿Prueba sesgos?" recibe un sí de todos. Las mejores preguntas piden el método y el resultado: qué se probó, contra qué escenarios, con qué tasa de aprobación, por quién, y cuándo. Los riesgos de comportamiento dignos de cobertura se alinean con los siete pilares del marco A.E.G.I.S.™:

• Hallucination Integrity: ¿el sistema declara falsedades como hechos, especialmente bajo presión, ambigüedad o cuestionamiento específico del dominio?
• Guardrail Resistance: ¿puede ser manipulado para comportarse de manera insegura a través de intentos de jailbreak o inyección de prompts?
• Data Handling & Privacy: ¿qué recopila, retiene y filtra, incluidos datos personales?
• Ethical Alignment: ¿se comporta apropiadamente con usuarios vulnerables y temas sensibles?
• Autonomy & Control: ¿hasta qué punto puede actuar por su cuenta, y puede un humano detenerlo?
• Adversarial Robustness: ¿cómo se comporta ante un atacante motivado?
• Explainability & Transparency: ¿se puede entender y auditar su comportamiento después del hecho?

Para ver cómo se prueba cada una de estas, consulte cómo se prueban los sistemas de IA para garantizar la seguridad. La distinción clave para un comprador es entre los resultados que el proveedor produjo sobre sí mismo y los resultados que produjo un tercero independiente. Las pruebas internas tienen valor, pero el proveedor se califica a sí mismo. M-25-22 plantea el mismo punto desde el lado del comprador cuando pide pruebas detalladas lo suficiente para ser "verificadas o reproducidas de forma independiente".

3. Manejo de datos

Pregunte dónde van sus datos, cuánto tiempo permanecen, quién puede verlos y si entrenan algo. El estándar federal en M-25-22 es un punto de referencia útil: los proveedores pueden recopilar y retener información de la agencia solo cuando sea "razonablemente necesario" para el contrato, y las entradas y salidas no públicas no pueden usarse para entrenar modelos públicos o comerciales sin consentimiento. Pregunte también si tiene acceso a los registros del sistema, ya que los operadores de alto riesgo en la UE deben mantener los registros bajo su control.

4. Supervisión y control

Averigüe qué puede hacer un operario cuando el sistema se equivoca. ¿Puede un operador revisar o anular resultados, o pausar el sistema? El artículo 26(2) asume que asignará personas competentes a la supervisión; el proveedor debe darles algo con lo que trabajar.

5. Gestión de cambios y monitoreo

Los productos de IA cambian bajo sus pies: un nuevo modelo base o un reentrenamiento, y el comportamiento que aprobó ya no es el comportamiento en producción. Pregunte cómo le notifica el proveedor sobre cambios materiales, si puede probar antes de que una nueva versión llegue a sus usuarios y si se puede hacer retroceder una versión. M-25-22 pide a las agencias que consideren o requieran los tres. Luego pregunte qué monitoreo existe después del lanzamiento y si los resultados se comparten con usted.

6. Incidentes y responsabilidad

Solicite al proveedor su proceso de respuesta a incidentes para fallos específicos de IA, como un resultado dañino o un jailbreak exitoso. Los operadores de sistemas de alto riesgo en la UE deben informar al proveedor y a la autoridad de vigilancia del mercado cuando crean que un sistema presenta un riesgo, por lo que su contrato debe garantizar que el proveedor trabajará con usted cuando esto suceda. Nuestra guía sobre incidentes de IA documentados y qué pruebas detectan muestra los patrones de fallo que vale la pena planificar.

Una lista de preguntas que puede enviar a proveedores de IA

Copie estas en su RFP. Cada una solicita algo que pueda verificar.

Alcance y propósito

1. ¿Qué modelos potencian el producto, quién desarrolla cada uno y qué versiones están en producción hoy?
2. ¿Cuál es el propósito documentado, y hay usos que desaconseja? Por favor comparta las instrucciones de uso o documentación equivalente.
3. ¿Publica fichas de modelo, sistema o datos para el producto? Por favor adjúntelas.
4. ¿Cuál es su política de uso aceptable para usuarios finales?

Pruebas y evidencia

5. ¿Contra cuáles riesgos de seguridad ha probado el producto (por ejemplo alucinación, jailbreaks e inyección de instrucciones, fuga de privacidad, comportamiento con usuarios vulnerables, límites de autonomía, ataque adversarial, explicabilidad)? Para cada uno, ¿cuál fue el método y el resultado?
6. ¿Realizó alguna de esas pruebas un tercero independiente? ¿Quién, cuándo, contra qué versión, y podemos verificar el resultado nosotros mismos?
7. ¿Nos permitirá acceder y tener tiempo para ejecutar nuestra propia evaluación, usando datos de prueba que usted no ve?
8. ¿Cuáles son los niveles documentados de precisión, robustez y seguridad cibernética, y cómo se midieron?

Datos

9. ¿Qué datos de nuestro uso recopila y retiene, durante cuánto tiempo y por qué es necesario cada elemento?
10. ¿Se utilizarán nuestros datos de entrada o salida para entrenar o mejorar algún modelo, ya sea suyo o de terceros? ¿Se puede prohibir contractualmente?
11. ¿Qué subprocesadores, incluidos proveedores de modelos, reciben nuestros datos?
12. ¿Qué registros genera el sistema y podemos exportarlos y conservarlos?

Control, cambios e incidentes

13. ¿Qué controles de supervisión humana e invalidación están disponibles para nuestros operadores?
14. ¿Cómo y cuándo nos notificará antes de un cambio material en el modelo o su comportamiento? ¿Podemos probar una nueva versión antes de que llegue a nuestros usuarios y podemos revertirla?
15. ¿Cómo supervisa el producto después del despliegue y compartirá los resultados de supervisión con nosotros?
16. ¿Cuál es su proceso de respuesta ante incidentes causados por fallos específicos de IA y cuáles son sus compromisos de notificación con nosotros?
17. Si nos vamos, ¿cómo obtenemos nuestros datos y personalizaciones, y en qué formato?

Convertir respuestas en términos contractuales

Las respuestas del cuestionario son declaraciones. El contrato es donde se convierten en obligaciones. M-25-22 proporciona una plantilla para los temas, y los compradores privados pueden adaptarla sin grandes cambios.

• Compromisos de desempeño y seguridad. Incorpore el comportamiento probado en el acuerdo: los niveles documentados de precisión y seguridad, un cronograma de revisión periódica y qué ocurre si los resultados caen por debajo de ellos.
• Derecho a evaluar. Resérvese el derecho de realizar sus propias pruebas o contratar a un tercero independiente para hacerlas, con acceso y tiempo del proveedor.
• Límites de uso de datos. Prohíba el entrenamiento con sus datos de entrada y salida sin consentimiento escrito, limite la retención a lo necesario e identifique los subprocesadores.
• Notificación de cambios. Exija notificación previa de cambios materiales del modelo y una ventana de prueba antes de que lleguen a producción, con opción de reversión.
• Registros y documentación. Exija que el sistema genere y exporte los registros que necesita, y establezca cuánto tiempo retiene el proveedor los suyos.
• Cooperación ante incidentes. Establezca cronogramas de notificación para incidentes de IA y una obligación de ayudarle a cumplir cualquier deber de presentación de informes que tenga.
• Portabilidad. Cubra la portabilidad de datos y modelos, la transferencia de conocimiento y la concesión de licencias transparente para que pueda cambiar de proveedor si es necesario.

M-26-04 añade una técnica de redacción útil: ordena a las agencias identificar ciertos requisitos como "materiales para la elegibilidad y el pago conforme al contrato". Hacer que los términos de seguridad y transparencia sean materiales les da peso, porque su incumplimiento se convierte en base para recursos en lugar de una nota al margen.

Dónde suele fallar la debida diligencia

La mayoría de revisiones fallidas de proveedores de IA fracasan de una de varias formas predecibles.

El cuestionario es un formulario de seguridad con preguntas sobre IA añadidas. Un informe SOC 2, según la propia descripción de AICPA, es un examen de controles en una organización de servicios relevantes para seguridad, disponibilidad, integridad del procesamiento, confidencialidad o privacidad. Eso es valioso y responde a una pregunta diferente a si el modelo puede ser comprometido o con qué frecuencia inventa hechos. Mantenga la seguridad de la información y el comportamiento de IA como secciones separadas con evidencia separada.

Toda respuesta es autodeclarada. El revisor no tiene forma de verificar el formulario o la política adjunta, por lo que el comprador acepta afirmaciones que no puede verificar o encarga sus propias pruebas.

La aprobación se trata como permanente. Seis meses después de la compra el proveedor ha cambiado el modelo y nadie volvió a verificar. Tanto M-25-22 como el NIST AI RMF tratan la supervisión como continua exactamente por esta razón.

La evidencia no es comparable entre proveedores. Tres proveedores describen sus pruebas de tres formas diferentes, por lo que el precio y las características deciden por defecto.

Por qué una clasificación verificable e independiente acelera el proceso

Los dos últimos problemas son los más costosos. Cuando un sistema de IA ha sido evaluado por una tercera parte independiente frente a un marco estándar, tres cosas cambian para el comprador.

Primero, la evidencia es independiente. RateAI no tiene interés en la clasificación de un sistema y sus honorarios están vinculados a hitos de evaluación, no a resultados. Un sistema puede no obtener la certificación; cuando esto ocurre, el desarrollador recibe un informe detallado de hallazgos y una ruta de remediación, y puede reingresar a la evaluación una vez que se hayan solucionado los problemas.

Segundo, la evidencia es comparable. Cada evaluación A.E.G.I.S.™ califica los mismos siete pilares, y los parámetros de puntuación se fijan por época de calificación para que las evaluaciones sigan siendo comparables en el tiempo. Los sistemas certificados reciben una tarjeta de puntuación A.E.G.I.S.™ con una Calificación General de Seguridad de A (Seguridad Máxima) a F (Peligroso), una calificación para cada pilar y un sello de certificación de A-5 Guardian hasta A-1 Unrestricted. Sus revisores pueden ver en un solo lugar dónde es fuerte un sistema y dónde se requiere precaución, y comparar dos proveedores en la misma escala.

Tercero, la evidencia es verificable y actual. Todos los casos de prompts, votos de validadores y decisiones de certificación se encadenan con hash SHA-256 en un registro de auditoría de escritura única, por lo que los registros no pueden ser alterados ni antedatados. Cualquiera puede verificar una certificación RateAI en el Registro Público de Seguridad sin iniciar sesión, y confirmar que es actual y no ha sido degradada. Las certificaciones también incluyen un ciclo de recertificación, y los cambios materiales en un sistema desencadenan una reevaluación, lo que aborda directamente el problema de gestión del cambio mencionado anteriormente.

Una clasificación no reemplaza su debida diligencia. Aún necesita respuestas sobre alcance, términos del contrato, flujos de datos y adecuación para su caso de uso, y una certificación RateAI no es una determinación legal: respalda su trabajo de cumplimiento normativo, y las decisiones regulatorias quedan en manos de las autoridades pertinentes. Los niveles Pro y Enterprise de RateAI incluyen mapeo de cumplimiento a la EU AI Act, NIST AI RMF e ISO 42001. Lo que una clasificación verificable hace es responder las preguntas sobre evidencia, números 5 a 8 en la lista anterior, con algo que su equipo puede verificar en lugar de simplemente confiar. Para un análisis más profundo de cómo funciona la certificación de terceros, lea qué es la certificación de seguridad de IA y cómo funciona.

Un flujo de debida diligencia práctico

1. Clasifique el caso de uso. ¿A quién afecta el sistema, puede actuar por su cuenta y podría ser de alto riesgo según la EU AI Act? Mayores apuestas significan revisiones más profundas.
2. Envíe la lista de preguntas temprano. Inclúyala en la RFP para que los proveedores que no puedan responder se descarten antes de que invierta tiempo en demostraciones.
3. Busque evidencia independiente. Busque el producto del proveedor en cualquier registro independiente en el que afirme estar incluido, y confirme que la clasificación, fecha y versión coincidan con lo que está comprando.
4. Pruebe lo que queda. Donde falta evidencia independiente o no cubre su caso de uso, ejecute su propia evaluación con datos que el proveedor no haya visto, o encargue una.
5. Negocie los términos. Convierta las respuestas en obligaciones contractuales: rendimiento, derechos de prueba, uso de datos, notificación de cambios, registro, incidentes y portabilidad.
6. Establezca la cadencia de monitoreo. Acuerde con qué frecuencia revisará el rendimiento y qué desencadena una revisión, como un cambio de modelo o un incidente reportado.
7. Registre la decisión. Conserve la evidencia, su puntuación y las razones de la aprobación.

Si está del lado del proveedor en este proceso, la misma lista le dice qué van a preguntar los compradores. Tener evidencia independiente lista antes de que llegue el cuestionario acorta cada ciclo de ventas que sigue. Los niveles de certificación y monitoreo de RateAI describen cómo se define el alcance de un compromiso, y un benchmark de seguridad gratuito para un agente de IA está disponible como punto de partida.

Preguntas frecuentes

¿Qué es la debida diligencia de proveedores de IA?

Es el proceso de verificar el sistema, prácticas de datos y controles de un proveedor de IA antes de comprar, y mantener esas verificaciones actualizadas después. En comparación con la revisión ordinaria de software, añade pruebas del comportamiento del sistema, como alucinaciones, resistencia a ataques de jailbreak y fugas de privacidad.

¿Es suficiente un informe SOC 2 para aprobar un proveedor de IA?

Normalmente no por sí solo. Un informe SOC 2 examina los controles de una organización de servicios relevantes para seguridad, disponibilidad, integridad del procesamiento, confidencialidad o privacidad, por lo que aún necesita evidencia separada sobre cómo se comporta el modelo de IA, como respuestas falsas, manipulación y fuga de datos a través de salidas.

¿Qué requiere la EU AI Act de las empresas que compran IA?

Las organizaciones que utilizan sistemas de IA de alto riesgo son "desplegadores" según el Artículo 26, y deben usar el sistema de acuerdo con sus instrucciones, asignar supervisión humana competente, monitorear su operación, mantener los registros bajo su control e, en algunos casos, informar a las personas afectadas. Esas reglas de alto riesgo se aplican a partir del 2 de diciembre de 2027 para sistemas del Anexo III y del 2 de agosto de 2028 para IA integrada en productos cubiertos por el Anexo I.

¿Qué términos de contrato debe incluir una compra de IA?

Como mínimo: compromisos de rendimiento y seguridad, derecho a pruebas independientes, límites en el uso de sus datos para entrenamiento, notificación previa y prueba de cambios de modelo, acceso a registros, cooperación en incidentes y portabilidad. El memorando OMB M-25-22 enumera la mayoría de estos como temas obligatorios para contratos de IA federales estadounidenses.

¿Cómo ayuda una clasificación independiente de seguridad de IA en la adquisición?

Reemplaza las afirmaciones autodeclaradas con resultados estandarizados que un tercero ha producido y que usted puede verificar. Una calificación A.E.G.I.S.™ evalúa un sistema en los mismos siete pilares que cualquier otro sistema calificado, de modo que puede comparar proveedores y confirmar que la certificación está vigente en el Registro público de Seguridad.

¿Una certificación de RateAI hace que un sistema de IA sea legalmente conforme?

Ninguna certificación puede hacer esa determinación; las decisiones regulatorias formales siguen siendo responsabilidad de las autoridades competentes. La certificación de RateAI respalda el trabajo de cumplimiento, y sus niveles Pro y Enterprise incluyen mapeo de conformidad con la EU AI Act, NIST AI RMF e ISO 42001.

Verifique la calificación de un proveedor antes de firmar

La pregunta de debida diligencia más rápida es si el sistema ya ha sido evaluado de forma independiente. Consulte el Registro de Seguridad de RateAI para ver cómo se enumeran los sistemas de IA certificados, con su calificación A.E.G.I.S.™ y estado de certificación, y pregúnteles a sus proveedores si su producto figura en él.