La gobernanza de la IA empieza antes de firmar el contrato

Una empresa puede discutir durante meses cómo gobernar la inteligencia artificial y perder su capacidad de decisión en una tarde: la tarde en que firma un contrato que no le permite examinar el sistema, conocer sus límites ni recuperar sus datos. La compra no es un trámite posterior a la estrategia. Es el momento en que una promesa técnica se convierte en obligaciones, dependencias y derechos exigibles.

La decisión importante empieza antes de la demostración

Imaginemos que un proveedor ofrece una herramienta para ordenar solicitudes de empleo. En la demostración, el panel luce claro, los resultados llegan rápido y el equipo de selección cree que podrá ahorrar tiempo. La pregunta inmediata suele ser cuánto cuesta y cuándo puede instalarse. Pero hay preguntas anteriores: ¿de dónde salen los datos de entrenamiento?, ¿qué significa exactamente la puntuación?, ¿cómo se detectan errores para distintos grupos?, ¿quién puede cuestionar una recomendación?, ¿qué ocurre si cambia el modelo después de la compra? Una interfaz convincente no responde por sí sola a ninguna de ellas.

Comprar IA implica adquirir, o contratar acceso a, una combinación de datos, modelo, interfaz, infraestructura, mantenimiento y criterios de decisión. Algunas partes quedan dentro de la organización; otras permanecen en manos del proveedor y de sus subcontratistas. Por eso la negociación determina mucho más que el precio. Define qué puede saber el comprador, qué puede probar y qué podrá corregir cuando el sistema afecte a personas reales. Las directrices británicas de contratación de IA aconsejan comenzar por el problema y los resultados buscados, identificar riesgos y exigir capacidad de evaluación durante el ciclo de vida, no solo en la selección inicial.

La comparación con una compra convencional ayuda, pero tiene un límite. Si una impresora no funciona, el defecto suele ser visible. Un modelo puede operar sin fallos técnicos aparentes y, sin embargo, producir recomendaciones poco fiables para un grupo, una región o una situación no representada en las pruebas. También puede cambiar por actualizaciones del proveedor. El contrato debe anticipar esa variabilidad. Dejarla para después equivale a negociar las reglas del juego cuando ya se depende del sistema.

Primero, describir el uso y su frontera

Una solicitud de propuestas responsable debería explicar la tarea concreta, quién utilizará la salida y qué decisiones no se delegarán. No basta con escribir «automatizar recursos humanos» o «mejorar la eficiencia». Hay que distinguir si la herramienta resume documentos, recomienda candidatos, clasifica reclamaciones o toma decisiones vinculantes. Cada caso tiene consecuencias diferentes. Una recomendación que un humano puede revisar de verdad no equivale a una decisión automática apenas confirmada con un clic.

También importa el contexto local. Un sistema probado en otro idioma, mercado laboral o estructura de datos puede rendir de forma distinta. Por eso el comprador debe definir conjuntos de prueba representativos de su entorno y preguntas que la demostración comercial no controla: registros incompletos, casos atípicos, instrucciones ambiguas y cambios en la población usuaria. El AI Risk Management Framework del NIST organiza esta disciplina en gobernar, mapear, medir y gestionar riesgos. No convierte una lista de comprobación en garantía, pero recuerda que medir un modelo sin entender primero su contexto de uso es insuficiente.

La frontera incluye los usos prohibidos internamente. Si la herramienta se compra para asistir una revisión documental, no debería reutilizarse automáticamente para vigilar productividad, inferir estados de ánimo o puntuar personas. Cambiar el propósito cambia riesgos, bases de datos, expectativas de las personas afectadas y posiblemente obligaciones jurídicas. La revisión de alcance debe estar escrita, asignada a un responsable y repetirse antes de ampliar la aplicación.

Seis exigencias que deben poder probarse

Una cláusula genérica según la cual el proveedor «cumple principios éticos» ofrece poca ayuda cuando aparece un problema. Lo útil es traducir principios en evidencia, responsables y remedios. La investigación de Isabel Gallego Córcoles sobre IA confiable y contratación pública muestra por qué la fase de adquisición puede incorporar requisitos de transparencia y control. Aunque su objeto es el sector público, la pregunta práctica también vale para empresas: ¿qué evidencia debe entregar el oferente para que el comprador pueda ejercer supervisión real?

Esta tabla no es un contrato modelo. Es una herramienta para identificar vacíos antes de que se vuelvan costosos. El alcance exacto de cada exigencia depende del riesgo, la jurisdicción, el tipo de datos y el poder de negociación. Una pequeña organización no necesita reproducir toda la infraestructura de control de un banco, pero sí saber qué perderá si acepta una caja negra sin derechos de prueba ni salida.

La documentación debe preceder a la confianza

El proveedor puede proteger secretos comerciales sin exigir fe ciega. Hay distintas formas de compartir información: fichas del modelo, descripción de datos, informes de evaluación, acceso controlado a pruebas, auditorías independientes o acuerdos de confidencialidad. La combinación adecuada varía, pero la respuesta «es propietario» no resuelve qué necesita saber quien asume la responsabilidad ante trabajadores, clientes o autoridades. La información debe permitir evaluar finalidad, limitaciones conocidas y procedimientos de corrección.

Preguntar por un porcentaje agregado de precisión es solo el comienzo. ¿Sobre qué población se calculó? ¿Con qué período de datos? ¿Qué errores son más graves: falsos positivos o falsos negativos? ¿Se analizó desempeño por subgrupos relevantes sin introducir nuevas inferencias invasivas? ¿Qué evidencia se conservará para explicar una decisión concreta? Las métricas sin denominador, contexto ni distribución pueden dar una apariencia de certeza superior a la que realmente existe.

Los informes también deben tener fecha y versión. Si el proveedor modifica el modelo, la documentación vieja puede dejar de representar el sistema usado. Conviene establecer qué cambios requieren aviso previo, una evaluación adicional o autorización del comprador. Esto es especialmente importante en servicios que actualizan modelos de forma remota. No se trata de impedir toda mejora: se trata de saber cuándo la mejora anunciada altera el riesgo que se había aceptado.

Auditar no significa pedir el código fuente de todo

El derecho de auditoría suele negociarse mal porque se presenta como una elección binaria: acceso ilimitado al código o ninguna inspección. Entre ambos extremos hay opciones útiles. El comprador puede exigir registros de decisiones, documentación técnica bajo confidencialidad, resultados de pruebas reproducibles, acceso a entornos de ensayo, evaluación por terceros independientes y cooperación ante incidentes. El contrato debería especificar quién activa cada derecho, con qué frecuencia, en qué plazo y quién paga.

Una auditoría tampoco basta por sí misma. Puede ser formal, incompleta o incapaz de detectar un daño que aparece después. Por eso debe conectarse con medidas concretas: corregir datos, ajustar umbrales, retirar una función, revisar decisiones pasadas, compensar daños cuando proceda y suspender el servicio si el riesgo no puede controlarse. Un informe que no abre ninguna vía de corrección es más parecido a un certificado decorativo que a un mecanismo de gobernanza.

En sistemas que afectan a personas, la trazabilidad debe permitir que alguien investigue una reclamación sin reconstruir a ciegas lo sucedido. Eso exige conservar la versión del modelo, las entradas relevantes conforme a reglas de privacidad, la salida, las intervenciones humanas y el motivo de cualquier excepción. Conservarlo todo indefinidamente tampoco es responsable; los períodos de retención y el acceso a registros deben tener un propósito definido.

Incidentes, responsabilidades y el derecho a detenerse

Muchos contratos detallan disponibilidad del servicio y guardan silencio sobre un fallo discriminatorio, una filtración de datos o una recomendación manifiestamente errónea. Antes de contratar, hay que definir qué cuenta como incidente material, cómo se reporta, qué información recibe el comprador y cuándo puede desactivar el sistema. También conviene identificar quién comunica lo sucedido a personas afectadas y autoridades, según corresponda. Una promesa de «soporte prioritario» no sustituye un procedimiento verificable.

El proveedor conoce su producto, pero el comprador conoce el contexto de despliegue. Ninguno puede trasladar toda la responsabilidad al otro con una frase. Si una empresa utiliza una recomendación automática en selección de personal, sigue teniendo deberes sobre el proceso que controla. Si el proveedor oculta limitaciones conocidas o modifica silenciosamente una función crítica, su conducta también importa. Un reparto sensato de responsabilidades reconoce esa interdependencia y exige cooperación, no una ficción de control absoluto.

El Reglamento europeo de IA ilustra que determinadas obligaciones dependen del tipo de sistema, su riesgo y el rol de cada actor de la cadena. No debe suponerse que una cláusula contractual reemplaza las obligaciones legales ni que toda compra fuera de Europa queda sujeta al mismo régimen. El punto transferible es más modesto: identificar desde el inicio quién es proveedor, quién despliega, qué documentación corresponde y qué decisiones requieren supervisión.

El costo oculto de no poder salir

Una oferta barata puede resultar cara si los datos quedan en formatos cerrados, las integraciones no pueden trasladarse y el equipo pierde capacidad de operar sin el proveedor. La dependencia no es siempre evitable, pero puede hacerse visible. Pregunte qué datos se exportan, en qué formato, con qué costo, en cuánto tiempo y qué sucede con los derivados. Pida un procedimiento de borrado verificable y un período de transición suficiente. Incluya la posibilidad de que el servicio termine por quiebra, cambio de condiciones o deterioro del rendimiento.

El análisis de Giovanni Fabio Licata sobre contratación transformadora de IA invita a mirar la adquisición como una decisión que configura capacidades institucionales, no solo como la elección de una herramienta. Esta lectura importa también fuera del sector público: cada compra enseña a una organización qué puede exigir, qué sabe medir y cuánto control está dispuesta a ceder. El precio inicial no captura el costo de reconstruir esa capacidad después.

La salida debe ensayarse, al menos sobre una muestra, antes de depender por completo del servicio. Un archivo «exportable» que nadie puede abrir o interpretar no es portabilidad. Tampoco basta con recuperar registros si las reglas de transformación, categorías y configuraciones indispensables permanecen inaccesibles. Una buena negociación convierte la portabilidad en una prueba aceptable, con responsables y fecha, en vez de dejarla como una palabra amable en el anexo.

Una negociación que puede empezar mañana

No hace falta esperar a disponer de un equipo jurídico especializado en IA para mejorar la próxima compra. Reúna a quien conoce el proceso, a seguridad y privacidad, a compras y a las personas que supervisarán las salidas. Escriban una página con el uso permitido, los datos necesarios, las decisiones afectadas, los daños plausibles y las condiciones para detener la herramienta. Luego conviertan cada riesgo importante en una pregunta que el proveedor pueda responder con evidencia.

Soliciten una prueba limitada con criterios de aceptación definidos antes de ver los resultados. Prueben casos normales y difíciles; registren errores y la respuesta del proveedor. Pregunten qué no puede hacer el producto y qué cambiará en los próximos doce meses. Una respuesta honesta sobre limitaciones es más valiosa que una promesa de exactitud universal. Si no hay datos suficientes para medir un daño potencial, anótenlo como incertidumbre y reduzcan el alcance del piloto.

En la negociación final, distingan entre requisitos imprescindibles y mejoras deseables. Para un uso de bajo impacto, bastarán controles proporcionados. Para una aplicación que puede afectar oportunidades de empleo, acceso a servicios o derechos, la falta de documentación, revisión humana efectiva o mecanismo de reclamación puede ser una razón para no desplegar. Esta proporcionalidad evita tanto la compra impulsiva como la burocracia indiscriminada.

La pregunta rectora es sencilla: si mañana una persona impugna una decisión, ¿podremos explicar qué pasó, revisar el caso, corregir el sistema y cambiar de proveedor si es necesario? Cuando la respuesta depende exclusivamente de la buena voluntad futura del vendedor, la gobernanza todavía no está negociada. Firmar después de resolver esa pregunta no garantiza ausencia de fallos, pero deja a la organización en condiciones reales de responder por ellos.

Referencias

• World Economic Forum (2022). AI Procurement in a Box. Marco de preguntas para adquisición de IA.
• UK Government. Guidelines for AI procurement.
• National Institute of Standards and Technology (2023). AI Risk Management Framework.
• Gallego Córcoles, I. (2023). Trustworthy Artificial Intelligence and Public Procurement. DOI: 10.1007/16495_2023_67.
• Licata, G. F. (2025). Transformative Public Procurement of Artificial Intelligence. DOI: 10.3390/laws14060097.
• Unión Europea (2024). Reglamento (UE) 2024/1689 sobre inteligencia artificial.

¿Qué derecho de información, auditoría o salida incluirías primero en la próxima compra de IA de tu organización?

Elaborado por Ricardo Gaibor.

Este artículo fue elaborado por Ricardo Gaibor con ayuda de sistemas de inteligencia artificial en tareas de investigación, organización y edición. La selección, interpretación y responsabilidad editorial del contenido corresponden al autor.