El sector público necesita una contratación que sepa decir que no

La autoridad pública no se vuelve responsable al firmar por un sistema de IA. Se vuelve responsable cuando sus requisitos, evidencias, autoridad humana,...

El sector público necesita una contratación que sepa decir que no

El documento que puede acabar con una compra

Un expediente de contratación pública suele comenzar con una petición que parece inofensiva: encontrar un sistema que ayude a realizar una tarea. La petición avanza a través de un enunciado del problema, una consulta al mercado, una serie de requisitos, una evaluación, un contrato y, si el proceso es saludable, una decisión que aún puede detener el trabajo. Esa última posibilidad es fácil de perder de vista. Cuando el dinero, los calendarios y la atención política se han reunido en torno a una compra, la palabra no empieza a sonar como un fracaso en la entrega. En el trabajo público, puede ser la decisión más útil del expediente.

La legislación europea sobre contratación ya trata una oferta como algo más que un concurso de promesas atractivas. La Directiva 2014/24/UE establece que los criterios de adjudicación deben permitir una competencia efectiva y justa y deben ir acompañados de disposiciones que permitan al poder adjudicador verificar la información facilitada por los licitadores. La directiva también señala que los criterios no deben otorgar al poder adjudicador una libertad de elección sin restricciones. Un comprador público tiene que describir qué es lo importante, explicar cómo se ponderará y comprobar si la oferta realmente lo cumple. Esto no es una nota administrativa al pie. Es la forma jurídica de una decisión que otras personas deben poder entender e impugnar.

La IA dificulta la antigua disciplina porque un proveedor puede ofrecer un sistema cuyo comportamiento depende de los datos, las actualizaciones del modelo, las indicaciones, los umbrales, las integraciones, las personas y un servicio que puede cambiar mientras el contrato sigue en vigor. El folleto puede permanecer igual mientras lo que hay detrás se mueve. Por tanto, un equipo de contratación tiene que comprar algo más que una interfaz. Tiene que comprar una capacidad delimitada, la evidencia de que esa capacidad es adecuada, la autoridad para supervisarla y una forma creíble de detenerla o sustituirla.

El sector público necesita una contratación que pueda decir no porque el sector público no puede externalizar su criterio. Un proveedor puede ofrecer un modelo, un flujo de trabajo, un servicio alojado o un conjunto de herramientas. Lo que no puede ofrecer es la legitimidad de la decisión tomada con ellos. La autoridad sigue teniendo que saber qué problema está resolviendo, qué intereses pueden verse afectados, qué evidencia respalda el sistema, qué persona puede intervenir y cómo continuará el servicio si el proveedor cambia de rumbo. Una firma no es una transferencia de responsabilidad. Es un registro de que la responsabilidad ha sido organizada.

Este artículo sigue esa organización desde la primera frase de un requisito hasta la última línea de un registro de salida. Utiliza orientación pública europea y material de contratación como evidencia. Los patrones prácticos son recomendaciones, no afirmaciones de que toda autoridad deba usar una única forma. Cualquier situación inventada está marcada como hipotética. Una oficina plausible, una oferta impecable y un fracaso dramático no son evidencia solo porque encajen en una historia conocida.

Un comprador público compra una promesa dos veces

Toda compra pública conlleva dos promesas. La primera es la promesa del proveedor sobre un producto o servicio. La segunda es la promesa de la autoridad a las personas que dependen del trabajo: que el dinero se gastó para un fin público definido, que la decisión puede explicarse, que se tuvieron en cuenta los derechos pertinentes y que alguien sigue siendo responsable cuando el sistema falla. La segunda promesa es la que sobrevive al acto de presentación.

La contratación de IA a menudo hace que la primera promesa sea vívida y la segunda, vaga. Una demostración puede mostrar un resumen fluido, una lista clasificada o una respuesta rápida. Rara vez muestra quién puede rechazar el resultado, qué ocurre cuando falta una fuente, cómo se aprueba un cambio, si los registros pueden exportarse o qué persona puede pausar el servicio sin tener que negociar su propia autoridad en medio de un incidente. Esas preguntas son menos cinematográficas. También son las preguntas que deciden si un organismo público puede seguir teniendo el control.

La Comunidad de Compradores Públicos de la Comisión Europea describe sus cláusulas contractuales modelo actualizadas sobre IA en tres partes: una versión completa para IA de alto riesgo alineada con el Reglamento de IA, una versión ligera que puede personalizarse para IA que no sea de alto riesgo y un comentario sobre cómo utilizar y adaptar las cláusulas. La distinción importa. Una cláusula modelo no es un sello mágico que haga idónea una contratación. Es un punto de partida para asignar obligaciones entre una organización pública y un proveedor, en un contrato cuyo alcance, finalidad y pruebas aún debe decidir el comprador.

Por tanto, el comprador debe preguntarse qué está prometiendo realmente al público antes de preguntar qué puede demostrar un proveedor. ¿Promete la autoridad una vía más rápida para resolver un atasco, una primera revisión más coherente, una inspección más segura, un mejor aprovechamiento de un conocimiento escaso o simplemente un experimento cuyos límites son visibles? Cada finalidad genera pruebas distintas y motivos distintos para detenerse. Un sistema que redacta notas internas puede necesitar un límite de autoridad distinto de otro que clasifica solicitudes para un servicio que las personas no pueden evitar.

Consideremos un hipotético equipo de evaluación que revisa una herramienta que resume las presentaciones de los proveedores. El equipo puede decidir que la tarea es adecuada para recibir asistencia, pero solo si el resumen conserva las exclusiones, las condiciones y las fechas y remite a los revisores a los pasajes originales. Si el proveedor no puede demostrar cómo se probarán esos requisitos, el equipo debería poder rechazar la herramienta o acotar el contrato. Eso no es una acusación contra el proveedor. Es una conclusión sobre las pruebas disponibles para la finalidad definida.

El mismo razonamiento se aplica cuando el problema resulta atractivo pero está mal delimitado. Un organismo público puede querer predecir la demanda, priorizar inspecciones o encauzar correspondencia. Esos verbos ocultan las decisiones que hay debajo. Qué cuenta como demanda. Qué cambia la prioridad. Qué correspondencia puede encauzarse de forma segura sin que la lea una persona. El primer no puede referirse al alcance del problema, no al uso del software. Rechazar una compra poco clara es a menudo la forma en que una autoridad protege la parte útil del trabajo frente a una parte que no puede someterse a prueba.

Definir el problema antes que la solución

La contratación se vuelve frágil cuando una categoría de producto llega antes de que se haya nombrado un problema público. La inteligencia artificial es especialmente buena para crear este orden porque el mismo modelo puede presentarse como asistente de redacción, clasificador, capa de búsqueda o agente según la diapositiva. La autoridad necesita describir el trabajo en términos que sigan teniendo sentido cuando se eliminen el proveedor, la familia de modelos y la interfaz.

El Algoritmekader neerlandés, mantenido para organizaciones públicas, sitúa este trabajo entre sus medidas recomendadas. Pide a las organizaciones que describan la finalidad prevista y los datos utilizados, determinen el grupo de riesgo aplicable, establezcan el impacto si el algoritmo no funciona como se prevé y decidan si una solución debe desarrollarse o comprarse. También señala una arquitectura de inicio de proyecto para desarrollar o adquirir algoritmos. No son adornos de contratación. Son formas de hacer legible el problema antes de ofrecer una respuesta.

Un buen requisito comienza por la decisión o el servicio que debe mejorar, las personas que lo realizan o lo reciben, la información que el sistema puede utilizar, la información que no debe utilizar y la autoridad humana que permanece. Establece las condiciones en las que el sistema es útil y las condiciones en las que no debe utilizarse. Nombra los registros que deben existir cuando el resultado se acepta, se rechaza, se corrige o se eleva. No necesita predecir el diseño interno del proveedor. Necesita definir la capacidad pública que puede inspeccionarse.

Aquí es donde importan los requisitos funcionales y de rendimiento. La Directiva 2014/24/UE exige que las especificaciones técnicas sean lo bastante precisas para que los licitadores comprendan el objeto del contrato y las autoridades puedan evaluar si las ofertas cumplen los criterios. Un requisito como «proporcionar una solución inteligente» no es una prueba útil. Un requisito como «conservar los pasajes de la fuente utilizados en un borrador, mostrar la fecha de recuperación, permitir que un revisor rechace el borrador y exportar el registro resultante» se acerca más a una necesidad pública comprobable. Describe un comportamiento y una vía de evidencia, no una moda.

Los requisitos también deben delimitar el alcance de la tarea. Una autoridad pública puede decir que un sistema puede sugerir una ruta, pero no puede tomar la determinación final. Puede establecer que una recomendación no debe utilizarse cuando una fuente especificada esté ausente o sea contradictoria. Puede exigir una vía humana para la persona afectada que quiera impugnar el resultado. Estas no son restricciones hostiles. Son las condiciones bajo las cuales la compra sigue siendo un servicio público y no un flujo de trabajo privado con el logotipo de un gobierno.

Un planteamiento del problema acotado no es falta de ambición. Es una forma de hacer que la ambición sea verificable. Si la autoridad no puede explicar qué paso cambia el sistema, quién se beneficia, qué puede salir mal y qué puede hacer una persona a continuación, no está lista para comparar proveedores. La acción correcta puede ser más investigación, una solución sin IA, un piloto pequeño y controlado o no comprar nada. El expediente de contratación debe tener espacio para cada respuesta.

Convertir los requisitos en evidencia

La palabra «evidencia» se usa con poca precisión en la contratación de tecnología. Una presentación del proveedor, una demostración del producto y una declaración de que el sistema es fiable pueden ser aportaciones útiles. Ninguna es automáticamente una prueba de que se cumple un requisito. La evidencia debe estar vinculada a una afirmación, una prueba, un alcance y una persona que pueda inspeccionarla. Sin esa conexión, la evaluación se convierte en una competición en la que gana la frase más pulida.

La directiva de contratación es clara sobre la relación básica: los criterios de adjudicación deben ir acompañados de disposiciones que permitan verificar eficazmente la información facilitada por los licitadores. Ese principio es especialmente importante para la IA porque un resultado puede parecer convincente mientras las condiciones que lo produjeron permanecen ocultas. El comprador debe preguntar qué se mostrará, bajo qué condiciones de datos y de tarea, con qué referencia, y cómo puede un revisor reproducir o impugnar el resultado.

El Algoritmekader neerlandés plantea la misma exigencia en un lenguaje práctico. Sus medidas de contratación pública incluyen incorporar los requisitos sobre algoritmos a los documentos del contrato y al propio contrato, exigir que los proveedores aporten evidencia del cumplimiento de los requisitos como parte de la evaluación, evaluar las condiciones de responsabilidad del proveedor, exigir capacidad de auditoría en el contrato, acordar qué ocurre con los datos y los artefactos, y solicitar un plan para detener el algoritmo. La lista es una orientación, no una lista de verificación legal universal. Su valor reside en que trata la prueba como un objeto de la contratación.

Un comprador puede dividir la evidencia en tres categorías útiles. La evidencia demostrada es lo que el proveedor muestra en una evaluación controlada: la entrada, la salida, la gestión de errores, el uso de fuentes y la vía humana pueden observarse. La evidencia inspeccionable es lo que la autoridad puede examinar sin depender de una demostración: documentación, resultados de pruebas, registros, interfaces, registros de cambios, descripciones de datos y la capacidad de ejecutar una comprobación acordada. La evidencia contractual es lo que el proveedor debe seguir aportando: avisos de cambios sustanciales, información sobre incidentes, acceso para una auditoría, registros de servicio, facilidades de exportación y apoyo para una salida controlada. Las categorías se solapan, pero evitan que una sola sesión impresionante sostenga todo el contrato.

La evidencia también necesita un alcance. Un proveedor puede demostrar que un sistema funciona bien con un conjunto de ejemplos. El comprador aún necesita saber si los ejemplos representan el idioma previsto, la calidad documental, la mezcla de casos, las necesidades de accesibilidad y las restricciones operativas. Una afirmación sobre un modelo en un laboratorio no es automáticamente una afirmación sobre un servicio público. Es una afirmación sobre el experimento que se realizó. El equipo de contratación debe conservar la tarea, las condiciones de los datos, la versión y el resultado para que la decisión posterior no quede desvinculada de la prueba.

Imaginemos, como hipótesis, que un licitador proporciona un conjunto de muestra de resúmenes generados y una declaración general de precisión. La autoridad puede solicitar los documentos de origen, la regla de selección, la versión utilizada, el tratamiento del material faltante, el procedimiento de revisión y el artefacto que permanecerá tras la aceptación. Si la respuesta es que los detalles son propietarios y no pueden inspeccionarse, el equipo ha aprendido algo importante. No ha aprendido que el sistema sea malo. Ha aprendido que el límite de evidencia propuesto puede ser demasiado débil para el propósito público.

La evidencia debe ser proporcionada. Una pequeña herramienta interna de redacción no necesita el mismo paquete de inspección que un sistema que influye en el acceso a un servicio público. La proporcionalidad no significa aceptar un eslogan en caso de bajo riesgo. Significa ajustar la profundidad de la prueba a la consecuencia, la reversibilidad, las personas afectadas y la capacidad de detectar y reparar un error. El proveedor debe conocer la evidencia requerida antes de que se presente la licitación. De lo contrario, la autoridad está cambiando el concurso después de la carrera, una forma conocida de producir una sorpresa costosa.

Un requisito debe conducir a una prueba, y la prueba debe poder cambiar la decisión de adjudicación.

El comprador debe poder discrepar

La responsabilidad pública no es lo mismo que la transparencia del proveedor. Un proveedor puede explicar su servicio mientras la autoridad aún carece de una vía para que un residente, trabajador, empresa o profesional impugne la forma en que se utilizó el servicio. El expediente de contratación debe, por tanto, preguntar cómo funciona el desacuerdo, no solo cómo produce el sistema una respuesta.

El Algoritmekader sitúa el control humano, los derechos fundamentales, la transparencia y las vías de reclamación entre sus materias del sector público. Sus medidas recomendadas incluyen una intervención humana significativa en la toma de decisiones, un proceso mediante el cual los ciudadanos u otras partes interesadas puedan presentar una queja, objeción o recurso, una decisión pública sobre el uso del algoritmo y una forma de publicar los algoritmos de impacto en el Registro de Algoritmos neerlandés. Estas medidas no convierten cada algoritmo en un espectáculo público. Hacen que la responsabilidad de la autoridad sea lo bastante visible para poder cuestionarse.

Un requisito de contratación sobre supervisión humana debe nombrar la acción humana concreta. ¿Puede el revisor ver la información que dio forma a la recomendación? ¿Puede corregir el registro? ¿Puede rechazar el resultado sin obtener antes permiso del sistema? ¿Puede solicitar una segunda vía cuando falta una fuente? ¿Puede detener un lote, aislar una versión o elevar una preocupación a alguien con autoridad? Si la respuesta es solo que hay una persona presente en algún punto del proceso, el requisito describe mobiliario, no supervisión.

El desacuerdo también necesita tiempo. Un revisor al que se espera que revise cada resultado mientras mantiene su carga de trabajo original puede estar técnicamente en el circuito y prácticamente fuera de él. La contratación puede exigir formación, apoyo, pruebas utilizables y una hipótesis de carga de trabajo para la revisión. Puede definir qué casos requieren aprobación previa a la acción y qué acciones reversibles y de bajo riesgo pueden continuar con registro y muestreo posterior. Puede pedir al proveedor que respalde la vía en lugar de ocultarla tras una interfaz de programación de aplicaciones.

La autoridad también tiene que discrepar de su propio entusiasmo. Un piloto exitoso puede crear presión para extender una herramienta a una población o decisión que nunca formó parte de la prueba. El contrato debe preservar el propósito original y exigir una nueva decisión cuando cambien el propósito, los datos, las personas afectadas o las consecuencias. Una actualización no es automáticamente inofensiva porque se entregue como servicio. Un uso nuevo no está automáticamente cubierto porque el mismo logotipo aparezca en la parte superior de la pantalla.

Cuando un proveedor dice que el modelo es solo consultivo, la autoridad debe observar lo que el trabajo hace realmente. Si se instruye al personal para que acepte la clasificación, si no hay tiempo para revisarla o si el sistema controla qué casos llegan a una persona, el consejo puede haberse convertido en una decisión en la práctica. El equipo de contratación no necesita discutir sobre la etiqueta perfecta. Necesita documentar la vía desde el resultado hasta la consecuencia y conservar la autoridad para cambiar esa vía.

Los límites del proveedor forman parte del contrato

La contratación de IA se describe a menudo como una elección entre construir y comprar. La elección más difícil es cómo dividir el límite entre el proveedor y la organización pública. El proveedor puede controlar un modelo, un servicio, una vía de actualización, la infraestructura, el equipo de soporte y parte del procesamiento de datos. La autoridad controla el propósito público, la decisión, la población afectada y el deber de prestar un servicio lícito y utilizable. Un contrato debe conectar estas responsabilidades en lugar de dejarlas como dos diagramas corteses.

Las cláusulas contractuales modelo actualizadas de la UE sobre IA son útiles porque reconocen que los compradores públicos necesitan enfoques distintos para la IA de alto riesgo y la que no lo es, y necesitan orientación para personalizar las cláusulas en la práctica. No sustituyen a una estrategia de contratación ni a una revisión jurídica. Son un vocabulario común para hacer explícitas las responsabilidades. El comprador todavía tiene que decidir qué pruebas, derechos sobre los datos, acceso de auditoría, aviso de cambios, soporte, responsabilidad y condiciones de salida son proporcionados al sistema que se adquiere.

Los datos y los artefactos merecen especial atención. Un sistema puede tocar documentos fuente, etiquetas, indicaciones, incrustaciones, borradores generados, correcciones humanas, conjuntos de evaluación, registros y expedientes finales. El contrato debe distinguir qué aporta la autoridad, qué crea el proveedor, qué puede usar cada parte, qué debe devolverse, qué debe eliminarse y qué prueba de eliminación o conservación se exige. Decir que la autoridad es dueña de sus datos no responde dónde residen los artefactos derivados ni cómo puede la autoridad recuperar los registros que explican un resultado.

Los derechos de auditoría necesitan una forma práctica. El comprador debe saber qué registros pueden inspeccionarse, cómo se solicita el acceso, qué aviso es razonable, qué protecciones de confidencialidad se aplican y qué ocurre cuando una auditoría detecta una deficiencia. Una cláusula de auditoría sin una vía utilizable es una sentencia a la espera de un conflicto. Lo mismo ocurre con una cláusula de incidentes que diga que el proveedor cooperará sin nombrar la información, el plazo y el responsable necesarios para la cooperación.

El control de cambios no debería dejarse en manos de las notas de versión. La autoridad puede exigir un aviso de cambio sustancial en el modelo, las fuentes de datos, la ubicación del tratamiento, los subcontratistas, las interfaces, los umbrales, el método de evaluación o la vía humana. Puede definir qué evidencia se necesita antes de que una versión modificada se utilice para la tarea pública. Puede exigir el derecho a pausar, rechazar o revertir cuando el servicio modificado ya no cumpla un requisito sustancial. Estas son recomendaciones para que el contrato sea operativo. No son afirmaciones de que una sola cláusula pueda resolver todas las relaciones con proveedores.

La responsabilidad también incluye lo que el proveedor no puede ofrecer. Un servicio puede depender de un modelo o una infraestructura de terceros cuyos cambios escapan al control inmediato del proveedor. El comprador debe conocer esa dependencia y saber qué obligaciones le corresponden. Una organización pública no puede evaluar una cadena inspeccionando solo la puerta principal. El contrato debería preservar una vía hacia la evidencia pertinente, o el comprador debería reconocer que la incertidumbre es un motivo para acotar o rechazar la compra.

Los límites bien definidos también protegen a los proveedores. Un comprador público que solicite todos los documentos posibles, todos los detalles del código fuente y soporte ilimitado sin un propósito definido puede reducir la competencia y hacer el contrato poco atractivo para proveedores europeos más pequeños. La proporcionalidad, la claridad y un alcance de evidencia creíble permiten que un proveedor diga qué puede hacer y que un comprador diga qué necesita. La contratación pública debe ser exigente sin ser teatral. Un muro hecho de requisitos imposibles mantiene fuera a los malos sistemas y a los buenos con la misma eficacia.

El cambio tras la adjudicación sigue siendo contratación

La adjudicación no es el final de la decisión. Es el punto en el que el servicio entra en un tipo distinto de escrutinio. Durante la operación, los datos cambian, las políticas se modifican, las interfaces se sustituyen, el personal aprende atajos, los proveedores revisan los modelos y un sistema puede utilizarse en situaciones que el equipo original no imaginó. La autoridad necesita una forma de detectar estos cambios antes de que se conviertan en un nuevo propósito público por accidente.

El Algoritmekader recomienda comprobaciones periódicas de que un algoritmo funciona como se espera, el seguimiento de los cambios en los datos y la evaluación del rendimiento y los resultados cuando los datos cambian, así como el mantenimiento de un plan de supervisión continua. También incluye una medida para un plan de emergencia que detenga el algoritmo. Estas recomendaciones incorporan el tiempo al modelo de gobernanza. Una contratación que capture solo la especificación inicial ha comprado una fotografía de un servicio en movimiento.

No todas las actualizaciones deberían desencadenar el mismo procedimiento. Un parche de seguridad que no altere el modelo, el límite de datos ni el papel de decisión puede seguir una vía distinta de la de una nueva familia de modelos, un origen de recuperación modificado o un nuevo umbral. El contrato puede definir la materialidad en términos operativos: un cambio es sustancial cuando altera la tarea, las personas afectadas, la vía de evidencia, la consecuencia de la decisión, la jurisdicción de despliegue, el subcontratista, el uso de datos o la capacidad de intervención. La definición exacta requiere criterio jurídico y técnico. El principio es simple: el cambio forma parte de la capacidad adquirida.

La supervisión debe conservar la información necesaria para tomar una decisión. Un panel puede mostrar que un servicio está ocupado; puede que no muestre que una fuente se ha quedado obsoleta o que los revisores están anulando la misma recomendación. La autoridad debe conservar la versión pertinente, el alcance de la tarea, las condiciones de la evidencia, la acción humana y el motivo de un cambio. Debe saber qué cambios se aceptaron, cuáles se revirtieron, cuáles se restringieron y cuáles generaron una nueva cuestión de contratación.

Un proveedor puede no poder avisar con antelación de todos los cambios internos. El contrato puede exigir igualmente una notificación utilizable y un paquete de evidencia antes de que se confíe en el comportamiento modificado. La autoridad puede optar por un despliegue por fases, una evaluación controlada o una suspensión temporal. La capacidad de pausar no es un castigo. Es lo que permite que un servicio público siga siendo responsable mientras se establecen los hechos.

Un registro de cambios también protege contra la falsa certeza. Si la autoridad no puede determinar si una diferencia provino de un modelo nuevo, un cambio de datos, una instrucción, una solución manual humana o una dependencia externa, no debe afirmar que el sistema se comportó de manera coherente. La respuesta correcta puede ser limitar el uso, recopilar mejor evidencia o detener la ruta afectada. El dinero público no se vuelve más seguro porque la explicación sea ordenada.

La interoperabilidad es la palabra cortés para irse

La gente suele hablar de la interoperabilidad como si fuera una cortesía técnica entre sistemas. En la contratación pública también es un control de continuidad. Si un servicio público no puede trasladar sus registros, configuraciones, evidencia, interfaces y conocimiento operativo a otra ruta, la autoridad puede ser legalmente libre de irse y prácticamente incapaz de hacerlo. El contrato ha creado una dependencia que el expediente de contratación no mencionaba.

El informe del JRC de la Comisión sobre el avance de la adopción de la IA en las administraciones públicas de la UE califica la contratación como un papel crucial de facilitación y afirma que la interoperabilidad debe integrarse desde el principio. También presenta la contratación estratégica como una forma de reducir la dependencia de proveedores no pertenecientes a la UE y de apoyar a las empresas emergentes europeas de IA, las soluciones de código abierto y GovTech. No se trata de un argumento para comprar europeo por eslogan ni de tratar el código abierto como una garantía automática. Es un argumento para que la capacidad técnica e institucional de cambiar de rumbo forme parte del valor que se compra.

La salida comienza con una lista de lo que debe sobrevivir. Esto puede incluir registros de origen, identificadores, etiquetas, instrucciones, versiones de modelos y configuraciones, conjuntos de evaluación, registros de auditoría, asignaciones de usuarios y roles, contratos de integración, estado de retención, material de seguridad y el significado de los campos. La lista depende del servicio. Un archivo portátil sin contexto puede ser menos útil que un registro más pequeño con su semántica y permisos intactos. La exportación es una capacidad que hay que probar, no una casilla que marcar.

La interoperabilidad también significa que la autoridad puede realizar una comparación significativa. ¿Puede un destino procesar los registros sin cambiar silenciosamente su significado? ¿Pueden los revisores comparar una salida antigua y una nueva en las mismas condiciones de tarea? ¿Puede el servicio público continuar en un modo reducido si una dependencia no está disponible? ¿Puede la evidencia seguir siendo legible después de que la interfaz desaparezca? Estas preguntas pertenecen a los requisitos, la evaluación y el contrato, porque una salida descubierta durante una emergencia suele ser una excavación arqueológica.

La portabilidad no implica necesariamente que un proveedor deba entregar todos los detalles internos de su implementación. Sí implica que la autoridad pueda preservar la función pública y los registros de los que es responsable, con sujeción a los derechos legales y a las restricciones de seguridad. El límite debe fijarse antes de la firma. Si el modelo del proveedor es inaccesible, la autoridad puede exigir igualmente entradas, salidas, registros de decisiones, evaluaciones, configuración y una vía para reconstruir las obligaciones públicas del servicio. Si no puede obtener esa vía, debe valorar la dependencia con honestidad o rechazarla.

Un ensayo de salida es valioso porque convierte una promesa contractual en una capacidad observada. Un comprador público puede probar una exportación, inspeccionar los campos, ejecutar una carga de trabajo representativa en un destino controlado y comparar los registros resultantes. Puede anotar lo que no se trasladó y decidir si la diferencia es aceptable. El ejercicio no tiene por qué ser espectacular. Un ensayo pequeño realizado antes de la renovación es mejor que una migración heroica ejecutada cuando el proveedor ya es la única persona que recuerda el sistema.

Salir es una secuencia de autoridad, exportación, significado, verificación, continuidad y cierre. Un botón etiquetado como exportación no es la secuencia.

El coste es más que la línea de la licitación

El precio es fácil de comparar cuando el objeto de la compra es estable. La contratación de IA tiene un horizonte de costes más largo. Puede haber trabajo de integración, preparación de datos, tiempo de revisión, controles de seguridad, almacenamiento, evaluación, actualizaciones del modelo, trabajo de accesibilidad, respuesta a incidentes, soporte, exportación y sustitución. Algunos costes los asume la autoridad. Otros se trasladan a los trabajadores o al público cuando un servicio se vuelve más difícil de impugnar. Una contratación que compara solo la tarifa inicial no es necesariamente económica. Simplemente cuenta una parte visible.

La Directiva 2014/24/UE prevé el cálculo del coste del ciclo de vida cuando la autoridad opta por ese enfoque. La directiva describe costes como los de adquisición, uso, mantenimiento, fin de vida útil y, cuando proceda y sea verificable, las externalidades medioambientales. También exige que los documentos de contratación indiquen los datos que los licitadores deben aportar y el método utilizado para evaluar el coste del ciclo de vida. Esta es una disciplina útil para la IA porque obliga al comprador a decir qué se va a contar, en lugar de invitar a cada proveedor a aportar una definición distinta de lo barato.

El mismo principio se aplica a la atención humana. Si un sistema genera recomendaciones que requieren revisión, el trabajo de revisarlas forma parte del modelo operativo. Si un servicio público necesita una vía de corrección, esa vía necesita un responsable y tiempo. Si una actualización del proveedor exige una nueva evaluación, la autoridad necesita la capacidad de llevarla a cabo. Estos no son argumentos en contra de la automatización. Son recordatorios de que la automatización cambia dónde ocurre el trabajo. Un ahorro en la factura puede convertirse en un gasto en la cola si la contratación no identifica el nuevo trabajo.

El coste también debería incluir el coste de no poder irse. Una dependencia puede parecer barata cuando es nueva y volverse cara cuando se acumulan registros, experiencia, integraciones y expectativas públicas en torno a ella. El comprador puede solicitar una estimación de migración, un inventario de datos y artefactos, una obligación de soporte y un calendario de ensayos. Puede comparar esas condiciones como parte del valor de la oferta. La elección no es entre optimismo y pesimismo. Es entre una dependencia visible y una oculta en el tiempo futuro.

El pensamiento de ciclo de vida ayuda a un equipo de contratación a decir no sin fingir que la oferta visible más barata es la opción neutral. El equipo puede rechazar una propuesta porque su evidencia, carga de revisión, vía de cambio o coste de salida no es compatible con el propósito público. Puede explicar la decisión según criterios publicados. Eso no es un gesto contra el mercado. Es lo que un mercado con requisitos verificables debería permitir.

Los compradores públicos necesitan autoridad para decir no

Un equipo de contratación no puede ejercer un poder que la organización no le ha otorgado. Muchas autoridades tienen personas capaces de evaluar cuestiones legales, técnicas, financieras y de servicio, pero la autoridad para combinar esas evaluaciones en una pausa o negativa no está clara. El resultado es conocido: las preocupaciones se registran en un documento, el entusiasmo en otro y la adjudicación avanza porque nadie sabe qué rol puede cerrar la puerta.

La autoridad debería nombrar los roles que pueden aceptar, rechazar, limitar o pausar una compra en cada etapa. Los roles necesitan acceso a la evidencia relevante y una vía para registrar el motivo. Un responsable de contratación puede gestionar el proceso, un responsable de servicio el propósito público, un delegado de protección de datos una condición de privacidad, un responsable de seguridad un control, un revisor técnico una prueba y un rol directivo superior la decisión final. La distribución exacta varía. La ausencia de una distribución es la parte peligrosa.

Una condición de detención útil no es una insignia roja que indique alto riesgo. Es un hecho que bloquea la siguiente decisión. El propósito previsto no está suficientemente definido. El proveedor no puede aportar evidencia para un requisito material. La persona afectada no tiene una vía de revisión utilizable. La autoridad no puede inspeccionar el cambio relevante. Los derechos sobre datos o artefactos no están claros. El sistema no puede exportarse ni sustituirse dentro del plan de continuidad. El revisor humano tiene responsabilidad pero no autoridad. Cada condición puede tener un remedio distinto. Algunas requieren aclaración, algunas un cambio de contrato, algunas un alcance más limitado y algunas un no.

Las condiciones de detención deberían conocerse antes de evaluar la oferta. Deberían estar vinculadas a los criterios de adjudicación y al contrato para que un comprador no invente un nuevo estándar después de ver la respuesta del proveedor. También deberían revisarse después de la adjudicación. Un requisito satisfecho en el lanzamiento puede dejar de cumplirse tras un cambio material o un nuevo uso. La capacidad de decir no no es una única puerta al final. Es una autoridad mantenida durante toda la vida del servicio.

Consideremos un hipotético organismo público que contrata un servicio de enrutamiento de documentos. Sus requisitos publicados incluyen trazabilidad del origen, una vía de revisión humana, un aviso para cambios materiales del modelo, una exportación de registros y un procedimiento de detención definido. Un licitador ofrece una demostración sólida, pero no puede permitir que la autoridad inspeccione la selección del origen ni conserve la evidencia de enrutamiento versionada. Otro licitador ofrece menos funciones, pero cumple los requisitos de evidencia y salida. El organismo no está obligado a preferir la demostración más llamativa. Puede aplicar los criterios establecidos, formular preguntas proporcionadas y rechazar la primera oferta si un requisito material sigue sin demostrarse.

Esa decisión no debe redactarse como un juicio moral sobre el proveedor o la tecnología. Debe exponer el propósito público, el requisito, la evidencia recibida, la condición no resuelta y la decisión que permiten los documentos de contratación. Un no claro es más respetuoso que un quizá vago que más tarde se convierte en una renovación obligatoria. También envía una señal útil al mercado: los compradores públicos pagarán por evidencia y control, no solo por teatro de capacidades.

La autoridad humana para detener debe poder ejercerse durante un incidente. El operador debe saber a quién llamar, qué estado del sistema conservar, qué ruta de servicio puede continuar y qué comunicación se requiere. El registro de la decisión debe distinguir la contención inmediata de una decisión de contratación a más largo plazo. Un organismo público no necesita esperar a una investigación perfecta antes de evitar más daños, pero debe evitar afirmar más certeza de la que tiene. La detención es un control. La explicación puede desarrollarse después.

La contratación pública configura el mercado

La contratación pública es una de las vías por las que Europa decide qué capacidades merece la pena construir. El informe del JRC sobre el avance de la adopción de la IA en las administraciones públicas de la UE describe el sector público como una fuerza importante que configura el mercado. Vincula la adopción exitosa con la gobernanza, la preparación de la fuerza de trabajo, la contratación responsable, la interoperabilidad y la confianza pública. También señala que la contratación estratégica puede reducir la dependencia de proveedores no pertenecientes a la UE y respaldar a las empresas emergentes europeas, el código abierto y las soluciones GovTech. La cuestión no es que una autoridad pública deba convertirse en un fondo de capital riesgo. La cuestión es que sus requisitos pueden recompensar una capacidad responsable o recompensar un envoltorio persuasivo alrededor de la dependencia.

El Informe Especial n.º 28/2023 del Tribunal de Cuentas Europeo se titula Public procurement in the EU: less competition for contracts awarded for works, goods and services in the ten years up to 2021. Su resumen público describe la competencia por las licitaciones públicas en Europa como decreciente. Un mercado con menos competidores efectivos es un mal lugar para ocultar requisitos vagos. Si la autoridad no puede comparar evidencia, puede acabar eligiendo entre estilos de marketing en lugar de entre servicios. Decir que no a una oferta no comprobable puede preservar las condiciones para una mejor competencia en el futuro.

Al mismo tiempo, un comprador puede excluir accidentalmente a proveedores útiles si pide evidencia en un formato que solo el mayor proveedor puede producir. Los requisitos proporcionados, las interfaces claras, los formatos abiertos y las evaluaciones por etapas pueden permitir que organizaciones más pequeñas demuestren una capacidad acotada sin pretender tener los recursos de una multinacional. El comprador debe ser estricto con el propósito público y flexible con la implementación cuando esta no afecte a dicho propósito. Así es como un no se convierte en una mejor pregunta en lugar de una puerta cerrada.

Configurar el mercado también significa negarse a convertir la arquitectura privada de un proveedor en la definición de la necesidad pública. Si un requisito menciona un modelo, una nube o un flujo de trabajo propietario concreto sin un vínculo justificado con la tarea, la competencia puede reducirse antes de que se examine la evidencia. Los requisitos funcionales y los resultados verificables dan a los compradores públicos más margen para comparar enfoques. También hacen que el contrato sea menos frágil cuando cambia el componente elegido.

Una autoridad pública puede ser un cliente exigente sin convertirse en un cliente difícil. Puede publicar las pruebas que espera, explicar el motivo de una condición de detención, ofrecer una vía de aclaración y pagar por un trabajo que genere capacidad pública duradera. Así, el mercado tiene algo útil a lo que responder. No tiene que adivinar si el factor decisivo fue una preferencia oculta, una demostración atractiva o el precio de un problema futuro.

Un patrón de trabajo para una contratación que puede negarse

El siguiente patrón es una recomendación práctica, no un nuevo procedimiento legal. Es una forma de mantener visible la decisión pública mientras un sistema pasa de la idea a la operación. Una autoridad debe adaptarlo a su legislación, sector, riesgo y método de contratación. Lo importante es que cada compuerta tenga un responsable, unas pruebas y un resultado permitido que incluya la pausa o la negativa.

Primero, redacte el propósito público. Nombre el servicio, las personas que lo prestan, las personas que lo reciben, la decisión o acción que puede cambiar y el motivo por el que se está considerando un sistema. Indique qué queda fuera del alcance. Si el propósito no puede describirse sin el vocabulario de producto del proveedor, la autoridad sigue en fase de descubrimiento de mercado. El resultado de esta compuerta es un enunciado del problema y una decisión sobre si la contratación es el siguiente paso adecuado.

Segundo, redacte el límite de las pruebas. Para cada afirmación relevante, indique qué demostraría que es cierta en la tarea prevista. Nombre las condiciones de los datos, el idioma, las necesidades de accesibilidad, los registros de origen, la versión, la base de referencia y la vía de revisión que hacen significativa la prueba. Especifique qué debe ser inspeccionable, qué puede mantenerse confidencial y qué debe entregarse como registro contractual. El resultado de esta compuerta es un conjunto de requisitos que los licitadores puedan entender y un plan de evaluación que pueda modificar la adjudicación.

Tercero, redacte el límite de la autoridad. Nombre las acciones que el sistema puede sugerir, las acciones que puede realizar, las acciones que requieren aprobación y las acciones que están prohibidas. Nombre quién puede corregir una fuente, rechazar un resultado, cambiar una regla, pausar un servicio y hablar con una persona afectada. Defina qué ocurre cuando el sistema no está seguro o las pruebas entran en conflicto. El resultado de esta compuerta es una vía humana más específica que una casilla de verificación.

Cuarto, redacte el límite del cambio. Identifique los cambios que requieren aviso, evaluación, aprobación o una nueva decisión de contratación. Incluya modelo, datos, proveedor, subcontratista, infraestructura, ubicación del procesamiento, interfaz, umbral, población, propósito y vía humana. Decida qué pruebas se conservan con el registro del cambio y cuáles pueden omitirse por motivos legítimos. El resultado de esta compuerta es un registro mantenido, no una promesa de que el sistema permanecerá estático.

Quinto, redacte el límite de salida. Enumere los registros, datos, configuración, pruebas, permisos, integraciones y conocimiento operativo que deben sobrevivir. Defina formatos, plazos, soporte, verificación, servicio reducido, transición, cierre de acceso y eliminación. Ensaye una exportación pequeña antes de una renovación o una ampliación importante. El resultado de esta compuerta es una vía que puede probarse mientras el proveedor sigue siendo un socio, no solo después de que la relación se haya convertido en una disputa.

Sexto, redacte el registro público. Decida qué puede publicarse sobre el propósito, el papel del sistema, las pruebas, la vía humana, los cambios, los incidentes y el contacto para impugnaciones. Proteja la información confidencial y personal sin convertir toda la decisión en una conversación privada. Un registro público puede decir qué se sabe, qué no se sabe y cuándo se realizará la próxima revisión. Su función no es hacer que el sistema parezca perfecto, sino hacer que el criterio de la autoridad sea inspeccionable.

Por último, redacte la denegación. La denegación no es un comunicado de prensa dramático. Es un resultado normal en el registro de decisiones: el requisito era material, la evidencia no lo cumplía, se consideró el remedio y la autoridad optó por rechazar, limitar, pausar o buscar una vía diferente. Una contratación que no puede producir este registro ha hecho que la compra parezca inevitable antes de haber merecido esa conclusión.

Estos controles pueden representarse en una respuesta a una licitación, una arquitectura inicial de proyecto, un calendario contractual, una reunión de revisión y un manual de incidentes. No deberían convertirse en un formulario más grande por el simple hecho de serlo. Si un control no cambia lo que el equipo puede decidir, probablemente sea teatro documental. Si le da a una persona evidencia y autoridad para actuar, forma parte del servicio.

Preguntas que merece la pena incluir en una licitación

Las mejores preguntas no son las que hacen que un proveedor repita su lenguaje de marketing. Son las que hacen visible el propósito público y el límite de la evidencia. El comprador puede adaptar las siguientes preguntas al sistema y al procedimiento:

  • ¿Qué tarea pública concreta respalda la capacidad propuesta y qué tareas quedan fuera de su uso previsto?
  • ¿Qué personas, registros y fuentes de datos están dentro del alcance y cuáles deben excluirse?
  • ¿Qué resultado produce el sistema y qué decisión o acción puede derivarse de él?
  • ¿Qué requisito puede demostrarse, cuál puede inspeccionarse y cuál se mantendrá por contrato?
  • ¿Cómo reproducirá la autoridad un resultado con la versión, las fuentes, la configuración y las condiciones de la tarea pertinentes?
  • ¿Qué puede ver, cambiar, rechazar, elevar o detener un revisor humano antes de que se produzca una acción con consecuencias?
  • ¿Qué cambios de modelo, datos, infraestructura, subcontratista o políticas requieren aviso y reevaluación?
  • ¿Qué registros y artefactos puede exportar la autoridad, en qué formatos, con qué significado, derechos y estado de conservación?
  • ¿Qué ocurre cuando el servicio no está disponible, la evidencia está incompleta o una persona impugna el resultado?
  • ¿Qué obligaciones de soporte, auditoría, incidentes, formación y salida continúan después del primer lanzamiento?

Estas preguntas no sustituyen a la directiva de contratación, la Ley de IA, la normativa de protección de datos ni las normas sectoriales. Son recordatorios para que la autoridad haga operativas sus propias obligaciones. Un proveedor que pueda responderlas con claridad puede no ser, aun así, el proveedor adecuado. Un proveedor que no pueda responderlas puede tener, no obstante, un componente útil, pero la autoridad no debería confundir un componente útil con una capacidad pública completa.

Nuestra breve nota

En Dweve, nuestro AI Compas incluye una ruta de contratación y gobernanza neutral respecto al proveedor para organizaciones europeas reguladas. El material de RFI y RFP pide a los equipos que clasifiquen el caso de uso, apliquen criterios de exclusión, comparen proveedores, ejecuten una prueba de concepto y conserven la evidencia mediante el seguimiento. Ese es nuestro contexto de implementación, no una evidencia independiente sobre la contratación pública ni una afirmación de que un único marco sirva para todas las autoridades. Lo mencionamos porque la disciplina descrita aquí es también la disciplina que intentamos aplicar en nuestro propio trabajo: definir el límite, exigir pruebas, mantener la decisión en manos humanas y hacer visible la salida.

Nuestro Trust Centre establece la misma distinción en un registro diferente. Un registro público puede describir lo que está documentado, lo que está preparado y lo que sigue siendo un evento futuro sin convertir una declaración de intención en una prueba. Un equipo de contratación merece la misma honestidad por parte de sus proveedores. El comprador debería poder ver el estado de una afirmación, la evidencia que la respalda y la vía para impugnarla.

La lección

Una autoridad pública no se vuelve responsable cuando firma por un sistema de IA. Se vuelve responsable cuando la contratación puede explicar por qué el sistema pertenece al trabajo, qué pruebas respaldan esa conclusión, quién puede intervenir, qué ocurre cuando el sistema cambia y cómo puede continuar la función pública si el proveedor no puede.

Las normas europeas de contratación ya aportan hábitos importantes: los criterios deben estar vinculados al objeto del contrato, la información debe ser verificable, las ponderaciones deben indicarse y las condiciones del contrato deben ser claras. Las cláusulas de contratación de IA de la Comisión Europea ofrecen a los compradores públicos una vía para tratar los sistemas de alto riesgo y los que no lo son y para asignar responsabilidades. El Algoritmekader neerlandés convierte la contratación responsable en medidas prácticas sobre finalidad, datos, pruebas, auditoría, control humano, suspensión y salida. El informe del JRC sitúa la contratación dentro del debate europeo sobre capacidades y soberanía. La advertencia del TCE sobre la reducción de la competencia recuerda que un concurso débil no se repara con una adjudicación confiada.

La palabra difícil sigue siendo no. No, la finalidad no está definida. No, las pruebas no pueden inspeccionarse. No, la vía humana es decorativa. No, la ruta de cambio es invisible. No, el registro público no puede mantenerse. No, el servicio no puede marcharse sin perder el trabajo que debía proteger. Cada no puede ser una negativa, una restricción, una pausa o una petición de una respuesta mejor. La autoridad debe decidir cuál de ellas es, registrar el motivo y mantener la decisión abierta a impugnación.

La contratación que sabe decir no no es una contratación que teme a la tecnología. Es una contratación que conoce la diferencia entre una capacidad y una promesa. Paga por un sistema que puede probarse, supervisarse, modificarse y abandonarse. Ofrece a los proveedores un concurso más justo porque la pregunta es visible. Da a los funcionarios una vía para intervenir antes de que un problema se convierta en política. Da a las personas afectadas por el servicio algo más útil que una declaración de que un proveedor ha sido aprobado.

Una compra pública debe terminar con un servicio que la autoridad aún pueda gobernar. Si las pruebas son sólidas, decir sí tiene sentido. Si las pruebas son débiles, decir no es el trabajo público. El expediente de contratación debe poder contener ambas frases.

Fuentes