Licitación de inteligencia artificial para ayuntamientos: requisitos y criterios técnicos

Preparar una licitación de inteligencia artificial para un ayuntamiento exige mucho más que pedir “una solución con IA”. La Administración debe identificar un problema concreto, definir qué decisiones o tareas se automatizarán, establecer cómo se medirá la calidad y determinar qué controles necesita el sistema antes de convertir la tecnología en una prestación contractual.

La inteligencia artificial puede aportar valor en clasificación documental, extracción de información, atención ciudadana, búsqueda interna, análisis de datos, apoyo a empleados o automatización de tareas. Sin embargo, no todos los procesos necesitan IA y no todas las soluciones deben evaluarse con los mismos criterios.

Además de la normativa general de contratación, cualquier proyecto debe analizar su encaje en el Reglamento (UE) 2024/1689 de Inteligencia Artificial, en su versión vigente, junto con protección de datos, seguridad, transparencia y las obligaciones sectoriales que correspondan. La referencia contractual general sigue siendo la Ley 9/2017, de Contratos del Sector Público.

Empezar por el caso de uso, no por el modelo

El primer paso es describir qué problema se quiere resolver. “Implantar inteligencia artificial” no es un objeto suficientemente preciso. El ayuntamiento debería identificar una tarea concreta: clasificar documentos, extraer campos de facturas, responder preguntas sobre información pública, resumir expedientes, detectar incidencias o ayudar a localizar normativa interna.

La inteligencia artificial para servicios públicos debe partir de procesos donde exista un beneficio verificable frente a una automatización convencional.

Antes de licitar puede resultar útil una auditoría tecnológica municipal para conocer datos, integraciones y sistemas disponibles.

Cuándo no hace falta inteligencia artificial

Muchas tareas repetitivas se resuelven mejor mediante reglas, APIs o automatizaciones deterministas. Si una decisión depende de condiciones claras, incorporar un modelo probabilístico puede añadir complejidad innecesaria.

La IA tiene más sentido cuando interviene información no estructurada, lenguaje natural, clasificación o patrones que no pueden describirse fácilmente mediante reglas.

La guía sobre licitación de automatización de procesos ayuda a separar ambos enfoques.

Casos de uso que conviene estudiar por separado

La contratación cambia mucho según el objetivo. Un chatbot con inteligencia artificial para ayuntamientos exige controlar fuentes y respuestas; un cuadro de mando municipal y BI depende especialmente de la calidad e integración de datos; y una automatización de procesos administrativos puede combinar reglas deterministas con IA solo en los pasos donde aporte una mejora medible.

Separar estos escenarios evita redactar un único pliego genérico que intente resolver necesidades distintas con la misma herramienta.

Definir el objeto del contrato

El objeto debe indicar el servicio o resultado esperado, no simplemente la tecnología. Puede incluir análisis, diseño, desarrollo, integración, configuración, pruebas, formación, soporte y mantenimiento.

También conviene separar una fase inicial de descubrimiento cuando todavía existe incertidumbre sobre datos o viabilidad.

La guía de pliego técnico para digitalización municipal permite estructurar alcance, entregables y criterios de aceptación.

Analizar el Reglamento Europeo de IA

El Reglamento de IA establece un marco basado en riesgos y obligaciones diferentes según el tipo de sistema y su uso. La Administración debe analizar el caso concreto antes de contratar, porque la clasificación no depende únicamente de la tecnología utilizada.

El pliego puede exigir al adjudicatario documentación suficiente para identificar su papel, el del ayuntamiento y las obligaciones aplicables durante desarrollo, puesta en servicio y operación.

No conviene limitarse a una declaración comercial de “cumplimiento del AI Act”. Deben existir evidencias y responsabilidades concretas.

Inventario y clasificación del sistema

El ayuntamiento debería registrar qué sistema de IA utiliza, con qué finalidad, qué proveedor lo suministra, qué modelo emplea, qué datos procesa y qué unidades lo utilizan.

Este inventario facilita supervisión, auditoría y gestión del cambio.

También debe actualizarse cuando se sustituye un modelo o se modifica significativamente el caso de uso.

Datos de entrada

La calidad del resultado depende en gran medida de los datos. El pliego debe describir qué fuentes se utilizarán, quién puede acceder a ellas y qué nivel de calidad existe.

Si se trabaja con expedientes, documentos o bases municipales, conviene limitar el acceso a la información estrictamente necesaria.

El proyecto debe evitar copiar grandes volúmenes de datos a sistemas externos simplemente por comodidad.

Protección de datos

Cuando el sistema trata datos personales, el diseño técnico debe coordinarse con las obligaciones aplicables. Debe quedar claro dónde se procesan los datos, cuánto tiempo se conservan y qué subencargados intervienen.

También debe analizarse si la información se utiliza para entrenamiento o mejora del servicio del proveedor.

El contrato debería prohibir usos no autorizados y definir mecanismos de eliminación o devolución al finalizar.

Modelos propios y modelos de terceros

Una solución puede utilizar un modelo desarrollado por el adjudicatario, un servicio de un proveedor externo o una arquitectura híbrida.

El ayuntamiento debe conocer esta cadena para entender dependencias, costes y responsabilidades.

Si el proveedor puede sustituir el modelo durante el contrato, debe definir cómo se validará que la nueva versión mantiene o mejora las métricas acordadas.

IA generativa

Los sistemas generativos pueden producir texto, resúmenes, respuestas o propuestas. Su principal reto es que pueden generar información incorrecta con apariencia convincente.

Por eso el pliego debe definir en qué tareas se permite su uso, qué fuentes puede consultar y cuándo la salida necesita revisión humana.

Un chatbot municipal, por ejemplo, debería priorizar información institucional verificable y dejar claro cuándo no puede responder con suficiente seguridad.

RAG y fuentes documentales

En muchos proyectos resulta útil combinar un modelo con una base documental controlada mediante técnicas de recuperación de información. Esto permite fundamentar respuestas en contenidos seleccionados.

El contrato debería definir cómo se indexan documentos, con qué frecuencia se actualizan y cómo se muestran las fuentes utilizadas.

La gestión del expediente electrónico y la calidad de los metadatos condicionan mucho este tipo de soluciones.

Supervisión humana

La automatización no debe eliminar la responsabilidad cuando el proceso necesita juicio administrativo. El pliego debería identificar qué resultados pueden utilizarse automáticamente y cuáles necesitan revisión.

La interfaz debe facilitar que el empleado comprenda la salida, acceda a la información relevante y pueda corregirla.

También conviene registrar cuándo una persona modifica o rechaza una propuesta generada por IA.

Transparencia hacia ciudadanos y empleados

Dependiendo del caso, puede ser necesario informar de que se interactúa con un sistema de IA o explicar el papel que tiene la tecnología en el proceso.

El contrato debe permitir a la entidad controlar mensajes, avisos y documentación de transparencia.

La experiencia no debería inducir a pensar que un sistema automatizado es una persona o que tiene competencias administrativas que no posee.

Métricas de calidad

Una licitación de IA necesita métricas específicas. Exactitud, precisión, recall, tasa de extracción correcta, respuestas fundamentadas o tiempo ahorrado pueden ser más útiles que una descripción genérica de “alta calidad”.

La métrica debe adaptarse al caso de uso. Un sistema que clasifica documentos no se evalúa igual que un asistente conversacional.

También debe definirse un conjunto de prueba representativo antes de la aceptación.

Errores y alucinaciones

En sistemas generativos conviene medir respuestas incorrectas, inventadas o no fundamentadas. La entidad debe establecer un umbral y un procedimiento de revisión.

No basta con demostrar unos pocos ejemplos correctos durante una presentación.

Las pruebas deberían incluir preguntas ambiguas, información ausente y situaciones donde la respuesta correcta es reconocer que no existe información suficiente.

Sesgos y comportamiento desigual

Cuando la IA afecta a personas o ayuda a priorizar actuaciones, debe analizarse si los datos o el modelo generan resultados sistemáticamente distintos entre grupos o casos similares.

El alcance de estas pruebas dependerá del uso y del riesgo.

El adjudicatario debe explicar qué controles aplica y qué capacidad tiene la Administración para revisar resultados.

Explicabilidad y trazabilidad

El nivel de explicación necesario depende del caso. En una extracción documental puede ser suficiente mostrar el fragmento origen; en un sistema de apoyo a decisiones puede necesitarse una trazabilidad mayor.

Los logs deberían registrar versión del modelo, entrada relevante, salida y contexto suficiente para investigar incidencias sin almacenar información innecesaria.

La trazabilidad también facilita comparar cambios entre versiones.

Integración con sistemas municipales

La IA aporta más valor cuando se integra en los flujos reales. Puede necesitar consultar el gestor de expedientes, crear una tarea, recuperar documentación o enviar un resultado a otra aplicación.

La guía sobre integración de sistemas municipales y APIs explica cómo definir autenticación, errores y mantenimiento.

La solución no debería obligar a exportar manualmente información para introducirla en una herramienta aislada.

APIs y arquitectura

El pliego debería especificar si el sistema necesita API, procesamiento asíncrono, colas, almacenamiento temporal o conexión con servicios cloud.

También conviene definir límites de uso, latencia esperada y comportamiento cuando un proveedor externo no está disponible.

La arquitectura debe permitir sustituir componentes sin rehacer toda la solución cuando sea razonable.

ENS y ciberseguridad

La IA no queda fuera de las obligaciones generales de seguridad. Deben analizarse accesos, secretos, logs, continuidad, proveedores y exposición de datos.

La guía sobre ENS para ayuntamientos ayuda a integrar el sistema dentro del marco de seguridad municipal.

También es importante protegerse frente a entradas maliciosas, abuso del servicio y acceso no autorizado a fuentes internas.

Prompt injection y manipulación de contexto

Cuando un sistema de IA procesa documentos o instrucciones externas, puede recibir contenido diseñado para alterar su comportamiento.

El proveedor debe describir qué controles aplica para separar instrucciones del sistema, datos de usuario y fuentes documentales.

Las pruebas de seguridad deberían incluir intentos de acceder a información que el usuario no tiene permiso para consultar.

Control de permisos

La IA debe respetar los mismos permisos que el sistema fuente. Un usuario no debería poder obtener mediante un asistente información que no puede consultar directamente.

Esto requiere integrar identidad, roles y filtros de acceso en la capa de recuperación.

Los permisos deben comprobarse con perfiles reales durante las pruebas.

Entornos de desarrollo y pruebas

El proveedor debe disponer de un entorno donde validar modelos, prompts, integraciones y cambios antes de producción.

Las pruebas deberían utilizar datos sintéticos o controlados siempre que sea posible.

Las modificaciones importantes del modelo deben pasar de nuevo por una batería de evaluación.

Prueba piloto

Antes de desplegar a toda la organización puede resultar útil comenzar con una unidad o proceso limitado.

El piloto debe tener métricas de éxito, duración, usuarios y condiciones de paso a producción.

También debe recoger incidencias, correcciones y percepción de los empleados que utilizan la herramienta.

Aceptación del sistema

La aceptación debe basarse en una batería de casos predefinida y reproducible. El proveedor no debería seleccionar únicamente ejemplos favorables.

Conviene guardar el conjunto de pruebas para utilizarlo cuando se cambien modelos o configuraciones.

Si el sistema depende de IA generativa, debe evaluarse también consistencia y comportamiento ante casos no contemplados.

Monitorización en producción

La calidad de un sistema puede cambiar con el tiempo. Deben monitorizarse errores, costes, latencia, uso, incidencias y, cuando sea posible, métricas de calidad.

El ayuntamiento debería recibir un cuadro de mando o informes periódicos.

Los cambios de modelo deben quedar registrados para relacionarlos con variaciones de rendimiento.

Costes de uso

Algunas soluciones tienen un coste variable por tokens, consultas, documentos o capacidad de proceso. El pliego debe definir cómo se medirá y limitará ese consumo.

También conviene estimar escenarios de crecimiento y costes máximos.

Un precio de implantación bajo puede ocultar un coste operativo elevado durante varios años.

Propiedad de datos, prompts y configuraciones

El contrato debe aclarar qué activos recibe la Administración: prompts, configuraciones, flujos, conectores, índices, código y documentación.

Si existe entrenamiento específico, también debe definirse qué ocurre con datasets y artefactos generados.

La entidad necesita suficiente control para poder migrar o sustituir al proveedor.

Reversibilidad y cambio de modelo

La arquitectura debería minimizar dependencias innecesarias de un único proveedor. Esto no significa que todo deba ser intercambiable, pero sí que la salida esté documentada.

El pliego puede exigir exportación de configuraciones, fuentes, métricas y documentación.

La contratación de software a medida comparte esta misma necesidad de control de código y activos.

Mantenimiento y evolutivos

Los modelos, APIs y herramientas cambian rápidamente. El contrato debe diferenciar correcciones, actualizaciones obligatorias, mejoras de prompts, sustitución de modelos y nuevas funcionalidades.

La guía sobre mantenimiento de software municipal ayuda a definir SLA, soporte y evolutivos.

También conviene establecer qué cambios requieren una nueva validación formal.

Formación de empleados

Los usuarios deben conocer las capacidades y límites del sistema. La formación debería explicar cómo interpretar resultados, cuándo revisar y cómo reportar errores.

Un sistema útil puede fracasar si los empleados confían demasiado en sus respuestas o, por el contrario, no entienden cómo incorporarlo al trabajo.

La alfabetización en IA debe formar parte del despliegue cuando sea relevante.

Documentación técnica y funcional

La entidad debe recibir arquitectura, fuentes de datos, modelos utilizados, prompts relevantes, integraciones, métricas, procedimientos de despliegue y gestión de incidencias.

La documentación debe mantenerse actualizada durante el contrato.

Esto permite auditar cambios y transferir el servicio a otro equipo en el futuro.

Criterios técnicos de adjudicación

Los criterios pueden valorar metodología de evaluación, arquitectura, seguridad, calidad de datos, supervisión humana, monitorización, interoperabilidad, documentación y reversibilidad cuando guarden relación con el objeto.

También puede resultar útil pedir una explicación concreta de cómo se medirá el rendimiento sobre un caso de uso similar.

Debe evitarse premiar únicamente el nombre comercial del modelo o promesas genéricas de precisión.

Solvencia y perfiles

Según el proyecto, pueden ser necesarios perfiles de IA, datos, backend, integración, seguridad, UX y análisis funcional.

La solvencia debe ser proporcional al alcance y no impedir la concurrencia de equipos especializados capaces de ejecutar el proyecto.

La experiencia debe centrarse en complejidad, integración y evaluación, no únicamente en haber utilizado una marca concreta.

Qué puede aportar BlackHold Consulting

BlackHold Consulting trabaja en áreas directamente relacionadas con este tipo de proyectos: automatización de procesos con IA, automatización de tareas administrativas, automatización de gestión documental y agentes de IA.

También dispone de capacidades en digitalización e integración de procesos, automatización de procesos complejos, consultoría estratégica de IA y servicios de automatización. En el sector público, cualquier prestación debe formalizarse mediante el procedimiento contractual aplicable y con requisitos objetivos definidos por la Administración.

Checklist antes de licitar IA

Caso de uso

¿Existe un problema concreto que justifique utilizar IA?

Regulación

¿Se ha analizado la clasificación y obligaciones aplicables?

Datos

¿Se conocen fuentes, permisos y calidad?

Métricas

¿Está definido cómo se medirá el resultado?

Supervisión

¿Se sabe qué decisiones necesitan revisión humana?

Seguridad

¿Se han incluido permisos, logs y protección frente a manipulación?

Reversibilidad

¿La entidad puede cambiar de proveedor o modelo?

Mantenimiento

¿Existe un plan para cambios de modelos, APIs y costes?

Preguntas frecuentes

Conclusión

Una licitación de inteligencia artificial para ayuntamientos debe contratar resultados y controles, no una etiqueta tecnológica. El proyecto necesita un caso de uso concreto, datos adecuados, métricas, supervisión, seguridad y una arquitectura que pueda mantenerse.

La evolución normativa y tecnológica hace especialmente importante documentar modelos, versiones, fuentes y responsabilidades. La Administración debe poder comprobar qué hace el sistema y cómo cambia durante la vida del contrato.

Cuando el ayuntamiento identifica un proceso donde la IA puede aportar valor, un proveedor capaz de combinar desarrollo, integración, automatización y evaluación de modelos puede transformar una prueba de concepto en un servicio público útil, verificable y sostenible.

Fotografía: Google DeepMind / Pexels.