Qué debería pedir un pliego de desarrollo de software con IA para que la IA llegue al código

Una prueba para antes de publicar el pliego: imagina que el adjudicatario escribe en su oferta «usaremos asistentes de IA en todo el desarrollo». ¿Qué cláusula de tu pliego le obliga a demostrarlo? ¿Y cuál te permite comprobar, al tercer mes, que la IA ha llegado al código y no se ha quedado en la oferta?

Si la respuesta es «ninguna», no hay mala fe de nadie. Algunos pliegos de desarrollo y mantenimiento se escribieron para comprar el tiempo de un equipo, y ahora se les han añadido tres palabras. El pliego sigue premiando lo que premiaba, y el adjudicatario hace lo que el pliego mide.

La tesis de esta pieza es que un pliego que menciona la IA pero puntúa precio y horas compra horas, con IA o sin ella. Para que la IA llegue al código, el pliego tiene que pedir cuatro cosas que se puedan comprobar: especificaciones verificables, trazabilidad, verificación humana y métricas de entrega. Escribimos para quien redacta o revisa pliegos y para quien contesta a ellos: son las mismas preguntas desde los dos lados de la mesa. El lado del licitador, el de la oferta, lo tratamos en cómo redactar la memoria técnica de una licitación; este es el del comprador.

Lo que vimos al leer 21 licitaciones

El 3 de octubre de 2026, onext revisó 21 licitaciones públicas que su radar había marcado por su relación con la IA o con el software y dejó cada una en su registro interno. Es un recuento propio, no una muestra representativa ni un estudio de mercado; por eso damos solo cifras agregadas y ningún órgano de contratación por su nombre.

• En 5 de las 21, la IA aparece en el objeto del contrato, como producto, licencia o formación. En las otras 16, no: son mantenimientos y evolutivos de sistemas, servicios de datos o suministros.
• En 6 fichas el registro anota el peso del precio en la puntuación: 50 %, 50 %, 51 %, 60 %, 80 % y 95 %. Ninguna por debajo del 50 %. Las otras 15 no lo anotan, así que no sabemos qué pesaba allí.
• En una de las fichas el registro deja escrito que el desarrollo guiado por especificaciones (Spec-Driven Development, SDD: la especificación es la fuente de verdad y el código se deriva de ella) no puntuaba.

Esas cifras no prueban que la administración compre mal. Dicen algo más modesto y más útil: en lo que revisamos, los pliegos de software que revisamos describen sobre todo equipo, perfiles u horas y un precio, y la IA, cuando aparece, aparece como etiqueta. Es comprensible: pedir bien una forma de trabajar que ha cambiado en dos años no es trivial, y en lo que hemos visto hay pocos ejemplos donde copiar.

Por qué «usaremos IA» no es una evidencia

En julio de 2025, METR publicó un ensayo aleatorizado con 16 desarrolladores con experiencia y 246 tareas reales en repositorios de código abierto en los que llevaban años contribuyendo (de media, más de 22.000 estrellas y un millón de líneas). Con herramientas de IA —sobre todo Cursor Pro con Claude 3.5 y 3.7 Sonnet, los modelos de frontera de entonces— tardaron un 19 % más en cerrar las tareas. Antes de empezar esperaban ir un 24 % más rápidos; al terminar, seguían creyendo que habían ido un 20 % más rápidos.

El resultado importa por la última cifra, no por la primera. Si quienes hacen el trabajo no distinguen, con la tarea en la mano, si van más rápido o más lento, una frase en una oferta no demuestra nada, y un informe de satisfacción tampoco. Hace falta una medida.

La ley de contratos ya permite pedirlo

A veces se da por hecho que pedir un método de trabajo en un pliego es arriesgado. La Ley 9/2017 de Contratos del Sector Público deja más margen del que se suele usar:

• Artículo 126.2: las prescripciones técnicas «podrán referirse al proceso o método específico de producción o prestación» de los servicios, siempre que estén vinculadas al objeto del contrato y guarden proporción con su valor y objetivos.
• Artículo 145.2: los criterios cualitativos pueden incluir la calidad, «incluido el valor técnico», y la organización, cualificación y experiencia del personal; deben ir acompañados de un criterio relacionado con los costes.
• Artículo 145.5: los criterios han de estar vinculados al objeto, formulados de manera objetiva y «acompañados de especificaciones que permitan comprobar de manera efectiva la información facilitada por los licitadores».
• Artículos 145.3.g y 145.4: en los servicios de carácter intelectual el precio no puede ser el único factor, y los criterios de calidad han de sumar al menos el 51 %. Que el desarrollo de software entre en esa categoría lo decide el órgano de contratación: la ley no lo dice de forma expresa.

Esto no es asesoramiento jurídico, y cada redacción tiene que validarla el servicio jurídico del órgano. Pero la idea de fondo es sólida: pedir cómo se trabaja no es una rareza, es algo que la ley contempla mientras esté vinculado al objeto del contrato y se pueda comprobar. El artículo 145.5 es, además, el que nos sirve de criterio de diseño: si una exigencia no se puede comprobar, no puntúa.

Las cuatro peticiones

Son cuatro porque cada una cierra un hueco por el que la IA se queda en el título. Todas piden un rastro que existe si el trabajo se hace de determinada manera y no existe si no se hace.

1. Especificación verificable: el contrato se firma antes del código

Cuando un agente escribe el código, el sitio donde se decide qué se construye pasa a ser la especificación. Es la idea de fondo de la especificación como el lugar donde se firma y de el desarrollo guiado por especificaciones. Para un comprador, la traducción es directa: que el adjudicatario entregue, antes de programar cada incremento, un documento con criterios de aceptación que se puedan ejecutar, y que el comprador lo valide. Es lo contrario de la bolsa de horas: el comprador sabe qué ha aceptado construir.

2. Trazabilidad: reconstruir de dónde viene cada cambio

Pedir que cada cambio enlace con su requisito y con la prueba que lo cubre no es burocracia: es lo que permite auditar. El registro de si hubo asistencia de IA, y con qué herramienta y modelo, va como dato de auditoría, no como puntuación: sirve para entender un fallo, no para castigar a nadie. Con el muestreo de cinco cambios al azar, el comprador comprueba con una muestra lo que ningún informe le asegura.

3. Verificación humana: una persona firma, y no es quien envió el cambio

La IA acelera escribir código; revisarlo sigue siendo trabajo de una persona con criterio. El pliego puede pedir que cada cambio lo revise alguien distinto del autor, que las pruebas no salgan del propio código que verifican (los tests generados desde el código describen lo que hace, no lo que debería hacer) y que, en la aceptación, quien envió el cambio sepa explicarlo sin el asistente delante. Es la versión contractual de un review que sigue esperando a un autor. Y, en administración, enlaza con algo que ya se exige a la IA que atiende a ciudadanos: la supervisión humana diseñada, no supuesta.

4. Métricas de entrega: medir antes, medir después

La lección de METR es una lección de medida. Una línea base al comenzar y una medición mensual de cuatro o cinco números (tiempo hasta producción, cambios que fallan, retrabajo, defectos tras la entrega) permiten ver si la IA ha llegado al código. Los datos salen del repositorio y del sistema de despliegue, no de un informe escrito a mano. Qué medir, y qué dejar de medir porque miente, lo desarrollamos en los KPIs de equipos de desarrollo con IA.

Cómo ponerle puntos sin caer en lo subjetivo

El riesgo de pedir un método es acabar con criterios que dependen de quién lea la oferta. El artículo 145.5 da la salida: criterios objetivos con especificaciones que permitan comprobar lo que dice el licitador. Una escalera con escalones comprobables funciona mejor que un «hasta 10 puntos por la calidad del enfoque». Un ejemplo de redacción, como propuesta nuestra que el servicio jurídico tendrá que validar:

• 0 puntos: no presenta evidencia de cómo trabajará, o solo declara que usará IA.
• Puntuación intermedia: describe el procedimiento (cómo se especifica, cómo se registra, quién revisa y qué se mide).
• Puntuación máxima: además de describirlo, aporta un ejemplo real y anonimizado de un cambio con su especificación, su rastro hasta el requisito y su registro de revisión.

El tercer escalón es el que separa a quien ya trabaja así de quien promete hacerlo: lo primero deja ejemplos, lo segundo deja frases.

El precio: si se paga por horas, no se puede pedir ahorro

Aquí hay un incentivo que conviene tener presente, y es razonamiento nuestro, no un dato. Si el contrato paga horas y la IA reduce las horas necesarias, el adjudicatario cobra menos por trabajar mejor. No es una acusación: nadie comparte voluntariamente un ahorro que le baja la factura. Hay dos salidas habituales: ligar el precio a incrementos aceptados, y no a horas, o incluir una cláusula que reparta el ahorro medido contra la línea base. Las dos dependen de la cuarta petición (sin métricas no hay ahorro que repartir) y las dos exigen un diseño que valide el servicio jurídico del órgano. Para quien contesta al pliego, el reverso es el mismo que veíamos en IA para licitaciones: comprar o construir: la ventaja está en tener el material y el método ya ordenados antes de que llegue el pliego.

Lo que un pliego no debería pedir

• Una herramienta o un modelo concretos. Choca con la igualdad entre licitadores y envejece en meses. Pide el resultado y el rastro, no la marca.
• Un porcentaje de código generado por IA. Mide uso, no resultado, y se maquilla con facilidad. Cuando una cifra se convierte en objetivo, deja de medir lo que medía.
• IA sin condición sobre datos. Si la ejecución implica ceder datos del sector público al contratista, el artículo 202.1 ya obliga a una condición especial de protección de datos. Con IA conviene precisar a qué servicios de terceros pueden llegar el código y las especificaciones del comprador.

Una distinción final, para no mezclar herramientas. Cuando lo que se compra es un sistema de IA, y no un desarrollo hecho con IA, existen las cláusulas modelo europeas de contratación pública de IA (MCC-AI), de la comunidad de práctica de la Comisión, disponibles desde junio de 2025 en las 24 lenguas oficiales. Esta pieza trata del caso contrario: la IA como método de trabajo del proveedor, no como producto que se entrega.

Una prueba de diez minutos antes de publicar

Coge el pliego y contesta cuatro preguntas, sin mirar la oferta de nadie:

1. ¿Qué documento prueba que se acordó qué se iba a construir antes de construirlo?
2. Si elijo un cambio al azar, ¿puedo reconstruir de dónde viene y quién lo revisó?
3. ¿Quién firma que el código es correcto, y es una persona distinta de quien lo envió?
4. ¿Qué número demostrará, al tercer mes, que la entrega mejora, y de dónde sale?

Si dos respuestas son «ninguno» o «no lo sé», el pliego compra horas aunque diga IA en la portada. Si las cuatro tienen respuesta, la IA tiene un sitio donde llegar. Y es el mismo test que haría un licitador serio con su propio equipo: quien no pueda contestarlas no puede prometer lo que promete.

Preguntas frecuentes

¿Puede un pliego público exigir que se use IA en el desarrollo?

La Ley de Contratos del Sector Público permite que las prescripciones técnicas se refieran al «proceso o método específico de producción o prestación» del servicio (art. 126.2), siempre que estén vinculadas al objeto del contrato y guarden proporción con su valor y objetivos. Por eso conviene pedir resultados y evidencias, y no una herramienta concreta. Cada redacción debe validarla el servicio jurídico del órgano de contratación.

¿Por qué no basta con puntuar la experiencia del equipo con IA?

Porque la experiencia declarada no demuestra cómo se va a trabajar en este contrato. La ley permite valorar la cualificación y experiencia del personal (art. 145.2), pero el ensayo de METR muestra que la percepción propia falla: desarrolladores con experiencia creían ir un 20 % más rápido con IA y habían tardado un 19 % más. Una evidencia útil es un rastro comprobable, no una impresión.

¿Cuánto debería pesar el precio en un pliego de desarrollo con IA?

No hay una cifra única. La ley exige que, en los servicios de carácter intelectual, el precio no sea el único factor (art. 145.3.g) y que los criterios de calidad sumen al menos el 51 % (art. 145.4); que el desarrollo de software sea «de carácter intelectual» lo decide cada órgano de contratación, porque la ley no lo dice de forma expresa. Cuanto más pesa el precio, más se compran horas. En las seis fichas de nuestro recuento que anotan el peso, iba del 50 % al 95 %.

¿Cómo se pide trazabilidad de la IA sin vigilar de más al equipo?

Como dato de auditoría, no como puntuación ni como sanción: se registra si hubo asistencia de IA en un cambio, con qué herramienta y qué modelo. Sirve para reconstruir el camino requisito, cambio y prueba cuando algo falla. Si el contrato implica ceder datos del sector público, además, el artículo 202.1 ya obliga a una condición especial de protección de datos: con IA conviene precisar a qué servicios de terceros pueden llegar.

¿Y si el adjudicatario no usa IA y cumple las métricas?

Entonces el pliego se cumple. Esa es la razón de pedir resultados medibles y no uso: si el equipo consigue los mismos plazos, calidad y trazabilidad sin IA, el comprador obtiene lo que quería. Si usa IA y no los consigue, también se ve. La métrica protege a los dos.

¿Sirve lo mismo para un cliente privado?

Sí, y es más fácil, porque no hay que encajarlo en la LCSP. Las cuatro peticiones (especificación verificable, trazabilidad, verificación humana y métricas de entrega) caben en cualquier contrato o RFP de desarrollo. La disciplina es la misma: pedir la evidencia de cómo se trabaja, no la promesa de una herramienta.

Fuentes

• Ley 9/2017, de 8 de noviembre, de Contratos del Sector Público, artículos 126, 145 y 202: texto consolidado en el BOE.
• METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», 10 de julio de 2025.
• Comisión Europea, comunidad de práctica de compra pública, cláusulas modelo para la contratación pública de IA (MCC-AI), accesibles en 24 lenguas de la UE desde el 16 de junio de 2025.
• Recuento propio de onext sobre 21 licitaciones públicas revisadas el 3 de octubre de 2026 (registro interno; solo cifras agregadas, sin nombres de órganos de contratación).