TwinLadder Weekly

Número #29 | Marzo 2026

Nota del editor

El mes pasado estuve en una sala de reuniones en Róterdam, observando cómo el equipo de compras de una empresa logística europea evaluaba las propuestas de proveedores de IA para una nueva plataforma de optimización de transporte de mercancías. Cuatro proveedores, cuatro propuestas impecables, cuatro promesas de "pleno cumplimiento del Reglamento Europeo de IA". Estaba allí como asesor. En veinte minutos, supe que teníamos un problema.

El equipo de compras contaba con un sólido marco de evaluación de TI: garantías de disponibilidad, residencia de datos, documentación de API, condiciones del acuerdo de nivel de servicio. Sabían cómo comprar software. Lo que no sabían era cómo comprar IA. Ninguna de las cuatro propuestas de proveedores especificaba los datos de entrenamiento utilizados en sus modelos. Ninguna revelaba una tasa de error medida para el caso de uso específico de la empresa. Ninguna explicaba, en términos operativos, cómo un responsable de almacén debería verificar las recomendaciones de enrutamiento del sistema antes de actuar en consecuencia. Y el equipo de compras no había pedido nada de esto, porque no sabían que debían hacerlo.

Cuando planteé estas lagunas, el responsable de compras dijo algo que se me ha quedado grabado: "Asumimos que el proveedor se encarga de la parte de IA. Nosotros solo necesitamos que funcione".

Si eso le parece razonable, siga leyendo. Porque esa frase recoge la suposición más peligrosa en la contratación europea de IA hoy en día. Según el Reglamento Europeo de IA, el proveedor no se encarga de la parte de IA. Se encarga usted. Y lo que compra o bien hace que esa obligación sea gestionable, o bien la convierte en imposible.

El punto ciego de la contratación: cuando comprar IA significa comprar riesgo de incumplimiento

Por qué el Artículo 4 cambia radicalmente la forma de evaluar a los proveedores de IA

Alex Blumentals, con análisis jurídico de Liga Paulina y análisis técnico de Edgars Rozentals

He aquí una cifra que debería preocuparle si alguien de su equipo compra herramientas de IA: solo el 14% de las organizaciones disponen de marcos formales de evaluación de proveedores de IA que van más allá de los criterios estándar de contratación de TI. [cite:gartner-ai-vendor] Mientras tanto, el 65% de las organizaciones utilizan ya con regularidad la IA generativa, casi el doble que diez meses antes. [cite:mckinsey-ai-procurement]

14% | Organizaciones con marcos de evaluación de proveedores de IA específicos | highlight
65% | Organizaciones que utilizan regularmente IA generativa | ↑2x en 10 meses
18% | Organizaciones que han adaptado la contratación a los riesgos de la IA | highlight

La brecha entre la velocidad de adopción de la IA y la sofisticación de la contratación no es una molestia. Es una responsabilidad de cumplimiento que existe ahora mismo en su organización.

Con casi total seguridad, usted sigue tratando la compra de IA como cualquier otra adquisición de software. Comparación de funcionalidades, negociación de precios, revisión de seguridad, firma de contrato. El proveedor dice "potenciado por IA". Su equipo dice "suena bien". Nadie pregunta qué significa eso en la práctica: qué puede y qué no puede hacer el modelo, dónde falla, cómo debe su personal verificar sus resultados y si la documentación respalda sus obligaciones legales como implantador.

El Artículo 4 cambia esta ecuación por completo. [cite:eu-ai-act-article4] El reglamento impone obligaciones de alfabetización en IA al implantador: su empresa, la que compra y utiliza el sistema de IA, no la empresa que lo construyó. Esto significa que cada herramienta de IA que adquiere o bien le ayuda a cumplir sus obligaciones del Artículo 4, o bien crea una laguna que usted debe cubrir por su cuenta. Y su equipo de compras casi con seguridad no tiene forma de distinguir entre ambas.

Lo que sus proveedores no le están diciendo

Permítame ser específico sobre lo que he observado en las propuestas comerciales y los procesos de venta de proveedores en toda Europa durante los últimos seis meses. He revisado o asesorado en contratación de IA para once organizaciones en siete países. Los patrones son lo suficientemente consistentes como para que los reconozca.

"Potenciado por IA" no es una especificación funcional. Es un término de marketing. Cuando un proveedor le dice que su plataforma de revisión de contratos está "potenciada por IA", eso le dice aproximadamente lo mismo que un fabricante de automóviles diciendo que su vehículo está "propulsado por motor". Todas las propuestas de proveedores que revisé utilizaban esa expresión. Ninguna la definió con precisión técnica. ¿"Potenciado por IA" significa un modelo de lenguaje grande? ¿Un clasificador ajustado? ¿Un sistema basado en reglas con una capa de aprendizaje automático? La respuesta importa enormemente para comprender la fiabilidad, las limitaciones y los requisitos de cumplimiento, y casi nunca se proporciona.

Compartí las afirmaciones de los proveedores de la reunión de Róterdam con Edgars durante un café la semana siguiente. Apenas echó un vistazo a las propuestas antes de responder. "Si un proveedor no puede explicar la arquitectura de su IA en dos frases", dijo, devolviendo los papeles por encima de la mesa, "o bien no entiende su producto o bien no quiere que usted lo entienda. Ambas cosas son descalificantes".

La procedencia de los datos de entrenamiento rara vez se revela. De los once procesos de contratación que observé, solo dos proveedores proporcionaron alguna información sobre los datos con los que se entrenaron sus modelos. Ninguno proporcionó el detalle suficiente para evaluar si los datos de entrenamiento eran representativos del dominio específico del implantador. El Índice de Transparencia de Modelos Fundacionales de Stanford encontró una puntuación media de transparencia de solo 37 sobre 100 entre los principales proveedores, siendo la documentación de datos de entrenamiento una de las áreas más débiles. [cite:stanford-hai-transparency]

Las tasas de error casi nunca se publican. A cada proveedor que encontré le hice una pregunta sencilla: "¿Cuál es la tasa de error medida de su sistema de IA para el caso de uso específico de este cliente?" Ninguno pudo responder. Algunos ofrecieron referencias genéricas de precisión de entornos de prueba controlados. Ninguno disponía de datos de error específicos del sector para las industrias a las que vendían. Un representante comercial me dijo, de manera memorable, "Nuestro sistema es muy preciso". Cuando le pedí el dato concreto, respondió: "No publicamos eso".

Pruebe esto: vuelva a la última propuesta de un proveedor de IA que evaluó su equipo. Busque las palabras "tasa de error", "modo de fallo" o "limitación". Si no encuentra nada específico, compró un sistema cuyas debilidades nadie reveló, y nadie en su lado preguntó al respecto.

"Cumplimiento" es marketing, no una garantía legal. Siete de las once propuestas de proveedores que revisé afirmaban alguna forma de "cumplimiento del Reglamento Europeo de IA". Pedí a Liga que revisara tres de estas afirmaciones de cumplimiento en detalle. Pasó una tarde con ellas y me llamó a la mañana siguiente. "Cada afirmación de cumplimiento que examiné era o bien una declaración de intenciones — 'estamos comprometidos con el cumplimiento' — o bien una referencia a funcionalidades que abordan parcialmente un artículo del reglamento mientras ignoran otros", dijo. "Ningún proveedor que revisé ofrecía una garantía contractual de que su sistema, tal como se implanta, satisfaría las obligaciones específicas del implantador conforme a los Artículos 4, 13, 14 o 26".

Este último punto es crítico. El cumplimiento del proveedor no es su cumplimiento. Incluso si el sistema de IA de un proveedor cumple perfectamente desde la perspectiva del proveedor, eso no descarga sus obligaciones separadas como implantador. Y sus obligaciones — en particular el requisito de alfabetización del Artículo 4 y el requisito de supervisión humana del Artículo 26 — dependen enteramente de cómo se utiliza el sistema, por quién y con qué grado de comprensión. [cite:eu-ai-act-article26]

El dilema del implantador

Liga y yo pasamos una tarde mapeando la arquitectura jurídica para los implantadores. Ella sacó su copia anotada del reglamento y lo expuso con claridad. "El Reglamento Europeo de IA crea un modelo de responsabilidad compartida", dijo. "El proveedor debe construir un sistema transparente y documentado. Pero el implantador debe asegurar que las personas que utilizan ese sistema lo comprenden lo suficiente como para usarlo adecuadamente. [cite:eu-ai-act-articles13-14] Son obligaciones separadas, y no pueden satisfacerse con las mismas acciones. La documentación del producto de un proveedor no se convierte automáticamente en su programa de alfabetización en IA".

A continuación me guió por tres obligaciones específicas del implantador que su equipo de compras casi con seguridad está pasando por alto. Lea la columna central junto a la columna de la derecha. La brecha entre lo que exige el reglamento y lo que actualmente pregunta su equipo es donde reside su riesgo de cumplimiento.

Obligación	Artículo del Reglamento de IA	Lo que le exige como implantador	Lo que probablemente pregunta su equipo de compras
Alfabetización en IA	Artículo 4	Su personal debe tener un conocimiento suficiente de las capacidades y limitaciones del sistema de IA	"¿Ofrece el proveedor formación?" (casilla de verificación)
Supervisión humana	Artículo 26	Su personal asignado a la supervisión debe tener la competencia, formación y autoridad necesarias	"¿Tiene el sistema un humano en el bucle?" (verificación de funcionalidad)
Transparencia hacia las personas afectadas	Artículos 13-14	Usted debe poder explicar las decisiones asistidas por IA a las personas afectadas	"¿Es el sistema explicable?" (sí/no)

Sea sincero: ¿la columna de la derecha describe su proceso de contratación actual? Si es así, está evaluando herramientas de IA con preguntas diseñadas para software tradicional. Es como utilizar una lista de verificación de seguridad de vehículos para evaluar una aeronave.

Las cinco preguntas que toda solicitud de propuesta de IA debe incluir

Basándome en lo que he observado — los procesos de contratación que salieron bien, los que generaron arrepentimiento y las directrices regulatorias emergentes en toda Europa — estas son cinco preguntas que deberían aparecer en cada evaluación de proveedores de IA que realice. Ninguna de ellas es estándar en los marcos de contratación actuales. Todas son necesarias.

1. ¿Cuáles son las limitaciones documentadas de su sistema de IA en nuestro caso de uso específico?

No limitaciones genéricas. No "la IA puede cometer errores a veces". Limitaciones específicas, documentadas y relevantes para el caso de uso. Si está comprando una herramienta de revisión de contratos, ¿qué tipos de cláusulas omite sistemáticamente? Si está comprando un sistema de selección de recursos humanos, ¿qué perfiles de candidatos generan resultados poco fiables? Si el proveedor no puede responder esta pregunta con datos concretos, no ha probado su sistema en su dominio, o lo ha probado y no quiere que usted vea los resultados.

Compartí este marco con Edgars, y sugirió una prueba práctica que puede realizar de inmediato. "Pida al proveedor que proporcione tres ejemplos de casos en los que su sistema produjo resultados incorrectos o engañosos en una implantación comparable", dijo. "Si dicen que no hay ninguno, o no están midiendo o no están siendo honestos. Ambas cosas son un problema".

2. ¿Qué formación ofrece su plataforma para ayudar a nuestro personal a comprender la fiabilidad de los resultados de la IA?

El Artículo 4 le exige, como implantador, garantizar una alfabetización en IA suficiente. [cite:eu-ai-act-article4] Si el proveedor ofrece formación, esa formación debe ir más allá de los tutoriales del producto. Debe enseñar a su personal a evaluar si los resultados de la IA son fiables en su contexto específico. Pida el plan de estudios de la formación. Pregunte cómo aborda las limitaciones y los modos de fallo. Pregunte si diferencia por rol de usuario y nivel de experiencia.

Si la formación del proveedor es un vídeo de incorporación de 30 minutos seguido de un cuestionario sobre funcionalidades de la interfaz, eso es formación sobre el producto, no formación en alfabetización en IA. Tendrá que presupuestar para cubrir esa brecha.

3. ¿Cuál es su tasa de error medida para nuestro dominio, y cómo se estableció?

Esta pregunta resulta incómoda para los proveedores. Hágala de todos modos. Un proveedor que no puede proporcionar datos de rendimiento específicos del dominio le está pidiendo que implante su sistema basándose en la fe. La metodología de medición importa tanto como la cifra: ¿se probó con una muestra representativa de sus datos? ¿Por quién? ¿En qué condiciones?

4. ¿Cómo respalda su sistema la supervisión humana tal como exige el Reglamento Europeo de IA?

No "¿tiene su sistema una opción de humano en el bucle?" Esa es una pregunta de funcionalidad. La pregunta de cumplimiento es: ¿cómo permite el diseño del sistema las capacidades de supervisión específicas que exige el Artículo 26? [cite:eu-ai-act-article26] ¿Puede su supervisor humano comprender el razonamiento de la IA? ¿Puede anular el sistema? ¿Puede identificar cuándo el sistema está operando fuera de sus parámetros fiables? ¿Cómo respalda — y no solo permite — el diseño de la interfaz una supervisión humana significativa?

5. ¿Qué documentación proporcionan que podamos utilizar como evidencia de cumplimiento del Artículo 4?

Pregunte esto explícitamente. Necesita demostrar cumplimiento. Eso significa documentación: sobre las capacidades y limitaciones del sistema, sobre la formación proporcionada a sus usuarios, sobre los mecanismos de supervisión humana, sobre cómo su organización garantiza la alfabetización en IA de forma continuada. Si la documentación del proveedor está diseñada para su propio cumplimiento en lugar del de usted, tiene una laguna que sus equipos jurídico y de cumplimiento tendrán que cubrir.

El marco de competencia del proveedor

Estas cinco preguntas son un punto de partida. Pero las preguntas individuales no constituyen un marco. Lo que necesita — y lo que casi ninguna organización tiene actualmente — es una metodología estructurada para evaluar si un proveedor de IA respalda o socava sus obligaciones del Artículo 4.

Durante los últimos tres meses, trabajando con equipos de compras, asesores jurídicos y evaluadores técnicos en siete organizaciones, he desarrollado un marco de puntuación que aplica la metodología de competencia en IA de TwinLadder al contexto de evaluación de proveedores. Evalúa a los proveedores en cinco dimensiones. Utilícelo como herramienta de autoevaluación: puntúe a su proveedor de IA más reciente en cada fila.

Dimensión	Qué evalúa	Respalda el cumplimiento	Neutral respecto al cumplimiento	Socava el cumplimiento
Transparencia	Con qué claridad documenta el proveedor las capacidades, limitaciones y arquitectura del sistema	Documentación técnica detallada, revelación de limitaciones específicas del dominio, explicación de la arquitectura	Documentación genérica del producto, afirmaciones generales de precisión	Respuesta "propietario" a preguntas técnicas, sin revelación de limitaciones
Apoyo formativo	Si la formación del proveedor desarrolla una verdadera alfabetización en IA o solo competencia en el producto	Formación específica por rol, estudios de casos de fallos, ejercicios de verificación	Tutoriales del producto, recorridos por funcionalidades, "concienciación sobre IA" genérica	Sin formación, o formación que presenta los resultados de la IA como fiables por defecto
Calidad de la documentación	Si la documentación del proveedor sirve a sus necesidades de cumplimiento	Documentación de cumplimiento orientada al implantador, mapeo al Artículo 4, guías de supervisión	Documentación orientada solo al proveedor, sin guía de cumplimiento para el implantador	Sin documentación, o documentación con cláusulas de descargo que trasladan toda la responsabilidad
Transparencia en errores	Si el proveedor mide y revela datos de rendimiento	Tasas de error específicas del dominio publicadas, datos de monitorización continua compartidos con usted	Referencias de precisión genéricas, métricas solo de entornos controlados	Sin datos de error, o afirmaciones de precisión casi perfecta sin evidencias de respaldo
Diseño de supervisión humana	Si la experiencia de usuario del sistema respalda un control humano significativo	Interfaz diseñada para la verificación, indicadores de incertidumbre, mecanismos de anulación	Flujo básico de aprobación/rechazo, sin señales de incertidumbre	Valores predeterminados automatizados, fricción para anular, indicadores de confianza sin calibración

Cada dimensión puede puntuarse en una escala del 1 al 5. Un proveedor que obtiene 3 o más en las cinco dimensiones respalda activamente su postura respecto al Artículo 4. Un proveedor que obtiene menos de 3 en cualquier dimensión crea una laguna de cumplimiento que usted debe cubrir con sus propios recursos — formación, documentación, protocolos de supervisión — a su propio coste. Un proveedor que obtiene 1 en transparencia o en transparencia de errores, en mi opinión, no es apto para su implantación en un entorno de Artículo 4 sin una mitigación interna sustancial.

Esto no es abstracto. He observado a equipos de compras utilizar una versión de este marco en evaluaciones reales. Cambia la conversación. Cuando usted dice a un proveedor, "Hemos puntuado su apoyo formativo con 2 sobre 5 porque su programa de incorporación no aborda las limitaciones del sistema", obtiene una respuesta muy diferente a cuando pregunta: "¿Proporcionan formación?" La especificidad genera responsabilidad.

Pruebe esto: tome su herramienta de IA adquirida más recientemente y puntúe al proveedor en estas cinco dimensiones ahora mismo. Donde la puntuación sea inferior a 3, esa es una laguna de cumplimiento que su organización posee actualmente, le haya presupuestado o no.

Lo que Europa ya está haciendo

Los marcos de contratación más inteligentes que he visto están surgiendo de organizaciones del sector público — no porque los gobiernos sean compradores más sofisticados, sino porque las normas de contratación pública imponen una transparencia que el sector privado puede eludir. La pregunta es si usted esperará a que estos estándares sean obligatorios, o los adoptará antes que sus competidores.

El gobierno neerlandés mantiene un registro público de algoritmos que exige a las agencias gubernamentales documentar los sistemas de IA, incluyendo su finalidad, fuentes de datos, mecanismos de supervisión humana y limitaciones conocidas. [cite:dutch-algo-register] Más importante aún, los marcos de contratación pública neerlandeses ahora exigen a los proveedores completar la documentación de transparencia antes de la adjudicación del contrato. Los Países Bajos fueron pioneros en esto. Otras jurisdicciones les están siguiendo.

Alemania actualizó sus directrices de contratación federal en 2025 para incluir criterios de evaluación específicos de IA. [cite:german-procurement-ai] Los proveedores que licitan en contratos públicos deben proporcionar documentación técnica que cubra la procedencia de los datos de entrenamiento, las tasas de error conocidas y el diseño de la supervisión humana. La asociación industrial Bitkom publicó orientaciones complementarias para ayudar a los equipos de compras a evaluar estas presentaciones, reconociendo que solicitar la documentación es solo la mitad de la batalla. También hay que saber leerla.

La Comisión Europea publicó una guía de contratación que recomienda a los compradores públicos evaluar los sistemas de IA en transparencia, explicabilidad y capacidades de supervisión humana, y no solo en funcionalidad y precio. [cite:ec-ai-procurement] La guía es consultiva, no vinculante. Pero señala hacia dónde se dirige la expectativa regulatoria.

En los países nórdicos, he observado organizaciones del sector privado construyendo sus propios marcos de evaluación de proveedores. Una empresa sueca de servicios financieros desarrolló una lista de verificación de 40 puntos para la evaluación de proveedores de IA que incluye preguntas sobre calendarios de reentrenamiento de modelos, políticas de retención de datos y requisitos de notificación al implantador cuando cambia el modelo. Una organización sanitaria finlandesa ahora exige a los proveedores realizar un "taller de modos de fallo" como parte del proceso de contratación: una sesión estructurada en la que el proveedor guía al comprador a través de escenarios donde su sistema de IA presenta un rendimiento deficiente conocido.

La situación en los países bálticos es menos madura. En Letonia, Lituania y Estonia, la mayoría de las organizaciones con las que trabajo siguen utilizando marcos estándar de contratación de TI para las compras de IA. La infraestructura regulatoria se está desarrollando — la CDPC letona ha señalado su interés en orientaciones sobre contratación de IA — pero las herramientas prácticas aún no están disponibles. Esta es una brecha que se cerrará, pero todavía no se ha cerrado. Si opera en los países bálticos, tiene una ventana para adelantarse, pero se está estrechando.

El mercado que aún no existe

Aquí es donde este análisis se vuelve incómodo, porque apunta a una brecha de capacidades que ningún servicio existente cubre adecuadamente, y puede que describa a su propia organización.

Su equipo de compras no tiene alfabetización en IA. No en el sentido del Artículo 4. Comprenden la compra. Comprenden la gestión de proveedores. No comprenden, en la mayoría de los casos, cómo evaluar si el sistema de IA de un proveedor respaldará o socavará su postura de cumplimiento. No pueden evaluar la calidad de los datos de entrenamiento. No pueden evaluar si una tasa de error es aceptable. No pueden determinar si el diseño de supervisión humana de un proveedor es genuino o cosmético.

Esto no es una crítica a su equipo. Es un problema estructural. El Artículo 4 creó una obligación que atraviesa todas las funciones que utilizan IA, incluida la función que la compra. Su equipo de compras no está exento del requisito de alfabetización. Y sin embargo, la competencia en IA específica para la contratación está casi completamente ausente del mercado de formación, de las ofertas de consultoría y de las orientaciones regulatorias.

Estuve en una llamada con Edgars la semana pasada cuando esto surgió de nuevo. "Recibo llamadas regularmente de equipos de compras que me piden evaluar las afirmaciones técnicas de un proveedor de IA", dijo. "Saben lo suficiente como para intuir que la presentación del proveedor no cuadra. No saben lo suficiente como para articular por qué. Esa brecha — entre la intuición de que algo está mal y el conocimiento técnico para identificar qué — es donde las organizaciones salen perjudicadas".

Pregúntese: si su equipo de compras evaluó a un proveedor de IA el mes pasado, ¿podría alguno de ellos explicar qué es una tasa de alucinación, por qué importa la procedencia de los datos de entrenamiento, o cómo distinguir una supervisión humana genuina de una casilla de verificación cosmética? Si la respuesta es no, ha identificado su próxima prioridad de formación.

El rol emergente es algo así como un "evaluador de contratación de IA": alguien que pueda situarse entre su equipo de compras, su equipo jurídico y la evaluación técnica para formular las preguntas que ninguna de esas funciones, individualmente, sabe que debe hacer. Algunas organizaciones están desarrollando esta capacidad internamente. La mayoría no. Las consultoras que atienden a las funciones de contratación han sido lentas en desarrollar competencia de evaluación específica para IA. Los propios proveedores de IA tienen un conflicto de intereses evidente.

Aquí es, con franqueza, donde vemos que la metodología de evaluación de TwinLadder se extiende de forma natural. Nuestro marco de competencia — los mismos siete pilares y cuatro niveles de madurez que utilizamos para la evaluación interna de alfabetización en IA — se aplica directamente a la evaluación de proveedores. Si puede evaluar la competencia en IA de su propia organización, puede evaluar si un proveedor la respalda o la socava. Las mismas preguntas de diagnóstico, los mismos requisitos de evidencia, la misma metodología de puntuación. Aplicados hacia fuera en lugar de hacia dentro.

Estamos construyendo esto. Lo menciono no como argumento comercial, sino como divulgación — porque la observación editorial y el desarrollo de producto proceden del mismo análisis, y usted debería saberlo.

La pregunta sobre competencia

Su compañía de seguros adquiere una herramienta de evaluación de reclamaciones "compatible con la IA" a principios de 2026. La propuesta del proveedor enfatiza la velocidad — un 70% más rápido en el procesamiento de reclamaciones — e incluye una sección titulada "Cumplimiento del Reglamento Europeo de IA" que describe el marco de gobernanza interno del proveedor. Su equipo de compras evalúa la herramienta según la velocidad de procesamiento, los requisitos de integración y el coste. Comprueban que la sección de cumplimiento existe, la confirman y siguen adelante.

Ocho meses después, un asegurado impugna la denegación de una reclamación. La reclamación fue marcada por el sistema de IA como potencialmente fraudulenta y remitida a un revisor humano de su equipo, que confirmó la denegación. El abogado del asegurado hace una pregunta directa: "¿Sobre qué base marcó el sistema de IA esta reclamación?" Su revisor no puede responder: el sistema proporcionó una puntuación de probabilidad de fraude, pero ninguna explicación de los factores subyacentes. La formación que el proveedor proporcionó cubría cómo leer el panel de control y procesar reclamaciones de forma eficiente. No cubría cómo cuestionar el razonamiento del sistema ni cuándo anularlo.

El asegurado presenta una reclamación ante la autoridad nacional de protección de datos. La autoridad pide a su empresa que demuestre que el personal implicado tenía "suficiente alfabetización en IA" para comprender las capacidades y limitaciones del sistema — el estándar del Artículo 4. [cite:eu-ai-act-article4] Usted presenta los certificados de formación del proveedor. La autoridad hace una pregunta adicional: "¿Abordó la formación las limitaciones específicas del sistema de IA en la detección de fraude en reclamaciones? ¿Puede el personal revisor explicar cómo el modelo genera sus puntuaciones de riesgo?" Usted no puede demostrarlo. La formación del proveedor era formación de producto, no formación en competencia. Y su equipo de compras nunca pidió la diferencia.

La obligación del Artículo 4 recae sobre usted — el implantador — no sobre el proveedor. La laguna de cumplimiento se incorporó en la compra.

¿Cuándo fue la última vez que su equipo de compras preguntó a un proveedor de IA: "¿Qué no entenderá todavía nuestro personal después de su programa de formación?"

Qué hacer

Añada los requisitos del Artículo 4 a su plantilla estándar de solicitud de propuesta de proveedores de IA. Incluya las cinco preguntas anteriores — revelación de limitaciones, adecuación de la formación, tasas de error, diseño de supervisión humana y documentación de cumplimiento. No acepte "estamos comprometidos con el cumplimiento" como respuesta. Exija detalles concretos. Si su plantilla de solicitud no tiene una sección específica de IA, está evaluando herramientas de IA con un marco diseñado para software tradicional. Es como utilizar una lista de verificación de seguridad de vehículos para evaluar una aeronave.
Exija la documentación de transparencia del proveedor antes de la compra, no después. El momento de descubrir que un proveedor no puede explicar las limitaciones de su modelo es durante la evaluación, no después de la implantación. Solicite la documentación técnica del proveedor — descripción de la arquitectura, resumen de datos de entrenamiento, limitaciones conocidas, referencias de rendimiento — como requisito previo para avanzar hacia las negociaciones comerciales. Si el proveedor se niega, esa es su respuesta.
Ponga a prueba las afirmaciones del proveedor con escenarios específicos de su dominio. No acepte demostraciones genéricas. Proporcione al proveedor casos de prueba de sus operaciones reales: documentos representativos, casos límite realistas, escenarios de dificultad conocida. Pídales que ejecuten su sistema con sus datos y compartan los resultados, incluidos los errores. Un proveedor que rechaza las pruebas específicas del dominio le está pidiendo que compre un producto que no ha validado para su caso de uso.
Presupueste para la brecha de competencia que su proveedor no cierra. Si la formación del proveedor cubre las funcionalidades del producto pero no la alfabetización en IA en el sentido del Artículo 4, presupueste formación complementaria. Si la documentación del proveedor no se corresponde con sus obligaciones como implantador, presupueste para crear esa correspondencia internamente. El coste de cubrir estas lagunas debe formar parte de su cálculo del coste total de propiedad, no una sorpresa descubierta seis meses después de la implantación. Pruebe esto: tome su contrato de proveedor de IA más reciente y calcule el coste real — precio de compra más la formación, documentación e infraestructura de supervisión que tuvo que construir usted mismo. Ese es el precio real de comprar IA sin competencia en contratación.

Lecturas rápidas

Guía de la UE para la contratación pública de IA — manual oficial de contratación, redactado para el sector público pero ampliamente aplicable.
Stanford HAI, Índice de Transparencia de Modelos Fundacionales — puntuación media de transparencia: 37 sobre 100.
Registro de Algoritmos del Gobierno Neerlandés — la iniciativa más madura de transparencia en IA pública de Europa, con requisitos de documentación que reflejan buenas prácticas de contratación.
McKinsey, El estado de la IA en 2025 — 65% de adopción, 18% de adaptación en contratación.
Reglamento Europeo de IA, Artículo 26 — Obligaciones del implantador — las obligaciones de competencia, formación y conocimiento de limitaciones se aplican independientemente de las promesas del proveedor.

Una pregunta

Su proveedor de IA dice que su sistema "cumple con el Reglamento Europeo de IA". ¿Puede alguien de su equipo de compras explicar qué significa realmente esa afirmación — qué artículos específicos cubre, qué obligaciones del implantador deja sin abordar y qué lagunas de competencia sigue asumiendo su organización? Si la respuesta es no, está comprando riesgo de incumplimiento y llamándolo cumplimiento.

TwinLadder Weekly | Número #29 | Marzo 2026

Ayudando a los profesionales a desarrollar capacidades en IA a través de una formación honesta.