El DEUC_v3_FINAL.xml — cómo la IA cierra el agujero entre el sobre y el pliego

Son las 16:47 del jueves. El plazo de presentación cierra a las 14:00 del lunes. Quedan tres días naturales, lo que en la práctica significa que el viernes por la tarde es el último momento real para detectar problemas.

Ana, técnica de licitaciones en una constructora mediana, abre el DEUC que acaba de firmar digitalmente. El archivo se llama DEUC_v3_FINAL.xml. Lo ha rellenado a partir del que presentaron hace tres meses en un concurso similar. Ha actualizado el NIF, la cifra de negocio y los técnicos de solvencia. Ha exportado el XML, lo ha firmado con AutoFirma y lo tiene listo para el Sobre 1 de PLACSP.

Lo que no ha revisado: en el apartado de integración de solvencia con medios ajenos, el DEUC sigue sin marcar la casilla. La empresa subcontratista con la que cuentan para la parte técnica sí aparece en la memoria técnica del Sobre 2. En dos sobres distintos, el mismo expediente cuenta dos historias diferentes.

El problema no es el DEUC. Es la incoherencia.

La plataforma PLACSP valida la firma electrónica. Comprueba que el archivo es un XML estructurado. Verifica que el licitador está registrado como operador económico. Pero no cruza lo que dice el Sobre 1 con lo que dice el Sobre 2.

Eso lo hace la mesa de contratación. Días después.

El Tribunal Administrativo Central de Recursos Contractuales, en su resolución 1512/2024 de 27 de noviembre, estimó el recurso de un licitador excluido exactamente por este motivo: había omitido en el DEUC la integración de solvencia con medios ajenos, pero los compromisos firmados con la empresa que aportaba esos medios estaban en el mismo sobre. La mesa debió requerir la subsanación; no lo hizo y excluyó al licitador. El TACRC corrigió la exclusión, pero el licitador perdió semanas y recursos en el proceso.

El artículo 141.2 LCSP establece que cuando la mesa aprecia defectos subsanables, da un plazo de tres días para corregirlos. Tres días naturales, según la disposición adicional duodécima de la misma ley. Sábados y domingos incluidos. Si el expediente lleva fondos europeos, el margen de error se estrecha todavía más.

La pregunta no es si el error es subsanable. Es si quieres descubrirlo tres días después de cerrar el plazo de presentación, con la mesa mirando tu expediente.

Lo que la IA puede hacer antes de abrir PLACSP

Hay una brecha concreta entre el momento en que se firma el DEUC y el momento en que la mesa lo abre. En esa brecha cabe toda la preparación que no se hizo.

La revisión automática asistida por IA no sustituye la lectura del pliego. Hace algo distinto: fuerza una confrontación sistemática entre lo que exige el PCAP y lo que declara cada documento de la oferta.

En un contrato de obras con valor estimado entre 80.000 y 2.000.000 de euros —rango en el que se tramita el procedimiento abierto simplificado del artículo 159 LCSP— el PCAP puede tener 80 páginas. Los requisitos de solvencia técnica se reparten entre el cuerpo del pliego, los anexos y las cláusulas particulares. Un análisis manual bajo presión de plazo falla. No porque el técnico no sepa leer, sino porque el cerebro humano no está diseñado para hacer búsquedas exhaustivas en documentos densos a las seis de la tarde del viernes.

Una herramienta que extrae automáticamente todos los criterios de solvencia del PCAP, los confronta con las declaraciones del DEUC y señala las discrepancias es, en este contexto, una lista de comprobación que se genera sola. No toma decisiones. Muestra el estado: cubierto, pendiente, no detectado en la oferta.

Los errores que señala con mayor frecuencia en licitaciones de construcción en España son conocidos:

Primero, el DEUC no indica a qué lote se presenta la empresa cuando el contrato está dividido en lotes. El pliego lo exige. La herramienta no lo deduce sola.

Segundo, la declaración de subcontratación en el DEUC no coincide con la memoria técnica. En la parte IV, sección D, el licitador ha marcado que no prevé subcontratación. En el Sobre 2 hay un esquema de organización que delega la instalación de sistemas contra incendios en una empresa externa.

Tercero, el DEUC reutilizado proviene de una licitación donde los umbrales de solvencia económica eran distintos. El nuevo PCAP exige una cifra de negocios mínima de 1,5 veces el valor estimado del contrato; el DEUC importado recoge la cifra de hace dos años.

Ninguno de estos tres errores es visible desde PLACSP. Los tres pueden generar un requerimiento de subsanación o, si la mesa no aprecia que son subsanables, una exclusión directa.

Qué automatiza y qué no

La automatización tiene un límite claro. Puede leer el PCAP y extraer los requisitos. Puede leer el DEUC y detectar los campos que están vacíos o contradictorios. No puede saber si los medios personales que declara la empresa existen realmente, ni si el responsable técnico que figura en el Sobre 2 tiene la titulación que exige el PPT.

Lo que automatiza es la confrontación mecánica. La parte que más tiempo consume y más errores produce cuando se hace a mano bajo presión de plazo.

En el procedimiento abierto supersimplificado del artículo 159.6 LCSP —obras bajo 80.000 euros, servicios y suministros bajo 60.000— la carga es menor: no se exige acreditar la solvencia, la oferta va en un único sobre y la valoración puede realizarse automáticamente mediante dispositivos informáticos, según el propio texto legal. Pero en el procedimiento abierto ordinario o simplificado, donde sí hay DEUC y varios sobres, la revisión automatizada tiene más recorrido y más impacto.

Algunas comunidades autónomas ya están integrando la generación del DEUC directamente en sus plataformas. El Consorci AOC de Cataluña incorporó en 2024 una funcionalidad en la Plataforma de Servicios de Contratación Pública para generar el formulario DEUC automáticamente según los estándares europeos, con más de 5.000 documentos generados desde su puesta en marcha. La Instrucción 1/2025 de la Junta Consultiva de Contratación Pública de Cataluña recoge directrices específicas para su uso. En Castilla y León, desde abril de 2025, robots de proceso automatizado (RPA) configuran el DEUC y los sobres electrónicos en PLACSP sin intervención manual del empleado público.

Esto no cambia las obligaciones del licitador. Cambia el entorno en el que opera. Una plataforma que genera el DEUC con los campos correctos ya rellenos no elimina la incoherencia entre sobres. Esa incoherencia es responsabilidad del equipo que prepara la oferta.

El archivo que necesita un sistema, no un nombre

El DEUC_v3_FINAL.xml no es el problema. Es el síntoma de un proceso sin estructura. La versión final existe porque hubo una v1 y una v2, editadas a mano, guardadas en carpetas compartidas, enviadas por correo entre personas que trabajan en documentos distintos al mismo tiempo.

El CAD resolvió el problema de los planos. El ERP resolvió el problema de la planificación de obra. La gestión documental de la oferta sigue siendo, para la mayoría de empresas constructoras que concurren a licitaciones por debajo de los umbrales SARA, un proceso artesanal con archivos nombrados por urgencia.

La revisión automatizada no transforma ese proceso. Pero sí introduce un punto de control obligatorio antes del cierre: un momento en que el sistema compara el pliego con la oferta y devuelve una lista de discrepancias. Que el equipo las resuelva o no es una decisión humana. Que esa lista exista antes del viernes por la tarde, y no el lunes a las 13:58, es lo que distingue una oferta presentada de una oferta excluida.

Así es como funciona una plataforma como Steinlog: el PCAP entra, los requisitos se extraen, el DEUC y el Sobre 2 se confrontan. El estado de cada requisito es visible en tiempo real para todo el equipo.

No hay un archivo v4. Solo un estado: listo o no listo.

---

Fuentes: Resolución TARC 1512/2024; artículos 141.2 y 159 de la Ley 9/2017 LCSP; disposición adicional duodécima LCSP; Orden HAC/1517/2025 (BOE); Instrucción 1/2025 JCCP Cataluña; Consorci AOC, 2025; Junta de Castilla y León, hiper-automatización PLACSP, 2025.