Un pliego bien planteado para un chatbot municipal debe fijar cinco cosas: que el asistente responda solo con la información publicada por la entidad, que los contenidos y los datos sean de titularidad municipal, cómo se actualiza la base de conocimiento, qué ocurre al terminar el contrato y cómo se mide si funciona. Sin esas cláusulas, lo habitual es adjudicar por precio y descubrir el problema en el segundo año.
La mayoría de pliegos que hemos leído describen bien lo que quieren —«un asistente virtual que resuelva las dudas de la ciudadanía»— y muy mal cómo comprobar que lo hace. El resultado es previsible: se compara por precio, se adjudica a la oferta más barata y a los seis meses la entidad tiene un asistente que responde cosas que nadie ha aprobado, o que no responde nada porque su base de conocimiento se quedó congelada el día del lanzamiento.
Este artículo no es un modelo de pliego para copiar y pegar: cada entidad tiene su fiscalización, su volumen y sus instrucciones internas. Es la lista de decisiones que conviene tomar antes de redactar, y las cláusulas que evitan los tres fracasos que más se repiten.
Los tres fracasos que se repiten
Antes de las cláusulas conviene entender qué falla, porque cada una de ellas responde a un problema concreto que hemos visto varias veces.
- El asistente inventa. Se contrata un modelo generativo sin acotar de dónde saca la información, y acaba respondiendo con conocimiento general en lugar de con la ordenanza municipal. Una respuesta inventada sobre un plazo administrativo no es un error simpático: es información oficial errónea.
- La información envejece. Nadie definió quién actualiza qué ni con qué frecuencia. A los ocho meses el asistente sigue anunciando el plazo de un trámite que cambió en enero.
- La entidad queda atrapada. Los contenidos estructurados, las conversaciones y la configuración están en la plataforma del proveedor. Cambiar de empresa significa empezar de cero, así que no se cambia.
Las cinco cláusulas que no deberían faltar
Cada una responde a uno de esos fallos. Son las que marcan la diferencia entre un pliego que compara ofertas y uno que solo compara precios.
Las cinco cláusulas
Comprobable, no declarado.
1 · Fuente de la respuesta acotada
El pliego debería exigir que el asistente responda únicamente a partir del contenido publicado por la entidad, y que cite o enlace la página de origen. Cuando no encuentre respuesta, debe decirlo y derivar, no aproximar. Conviene pedir en la oferta una descripción de cómo se garantiza técnicamente esa restricción, no una declaración genérica de que «no alucina».
2 · Titularidad de contenidos y datos
Los contenidos estructurados para alimentar al asistente, las conversaciones y las estadísticas deben ser de titularidad municipal, con derecho a exportarlos en un formato reutilizable durante la vigencia del contrato y a su finalización. Sin esta cláusula, el trabajo de estructuración —que suele ser la parte más costosa del proyecto— se queda en casa del proveedor.
3 · Mantenimiento de la base de conocimiento
Es la cláusula que más se olvida y la que decide si el proyecto sigue vivo al segundo año. Debe fijar quién actualiza el contenido cuando cambia una ordenanza o un plazo, con qué frecuencia se revisa el conjunto y qué plazo máximo hay para reflejar un cambio urgente. Y debe quedar claro si esa tarea es del proveedor, de la entidad o compartida.
4 · Reversibilidad y salida
Qué se entrega al terminar el contrato: la base de conocimiento estructurada, el histórico de conversaciones anonimizado, la documentación de configuración y, si procede, el plazo de acompañamiento a un nuevo proveedor. Una salida ordenada bien definida es lo que permite que el segundo contrato sea competitivo.
5 · Protección de datos desde el diseño
Lo más recomendable en un asistente informativo es que no recoja datos personales: si el ciudadano necesita hacer un trámite, el asistente le lleva a la sede electrónica en lugar de pedirle el DNI. Eso simplifica enormemente el encaje normativo. Si por el caso de uso sí hay tratamiento, el pliego debe recoger la figura del encargado, la ubicación de los servidores y el periodo de conservación.
La prueba que debería exigirse antes de adjudicar
Este es el punto que más cambia el resultado de una licitación, y casi ningún pliego lo incluye. En lugar de valorar una memoria técnica de sesenta páginas que todas las empresas saben escribir, exige una demostración funcional acotada: se entregan a los licitadores diez o quince consultas reales de la entidad, con sus respuestas correctas, y cada uno debe mostrar cómo responde su solución.
Memoria técnica
Sesenta páginas que todas las empresas saben escribir. Valora la redacción, no la solución.
60 páginasDemostración funcional acotada
Se entregan diez o quince consultas reales con sus respuestas correctas, y cada licitador muestra cómo responde.
10 consultas realesLo importante no es solo si acierta. Hay que observar tres cosas: si cita la fuente de donde saca cada respuesta, si reconoce cuando no sabe en lugar de improvisar, y si el tono es el que la entidad quiere usar con su ciudadanía. Una de las consultas debería ser deliberadamente imposible de responder con el contenido publicado: ahí se ve enseguida qué soluciones inventan.
Cómo repartir los criterios de valoración
Si el precio pesa el 60% de la valoración, el pliego está comprando precio por mucho que diga otra cosa. Un reparto que en nuestra experiencia funciona mejor da más peso a lo que se puede comprobar que a lo que se puede prometer.
Reparto orientativo de la valoración
Lo demostrable debe pesar más que lo declarado.
Fíjate en que la prueba funcional y el plan de mantenimiento suman más que el precio. Son, respectivamente, la garantía de que la solución funciona hoy y de que seguirá funcionando en dos años. Cada entidad debe ajustar los porcentajes a sus criterios de fiscalización, pero el principio se sostiene: lo demostrable debe pesar más que lo declarado.
Cuatro errores frecuentes al redactar
- Describir la tecnología en lugar del resultado. Exigir «un modelo de lenguaje de última generación» no dice nada. Exigir «que cite la fuente de cada respuesta» sí.
- Dejar el mantenimiento fuera del contrato. Contratar solo la implantación garantiza que el proyecto muera en cuanto cambie la primera ordenanza.
- No definir qué es un error. Sin una definición de respuesta incorrecta y un umbral aceptable, no hay forma de reclamar nada.
- Pedir integración con todo por si acaso. Encarece la oferta y rara vez se usa. Es mejor acotar el alcance inicial y prever ampliaciones.
Conclusión
Un pliego para un chatbot municipal no necesita ser largo: necesita ser comprobable. Si define de dónde sale cada respuesta, quién mantiene el contenido, qué se lleva la entidad al terminar y cómo se demuestra que funciona antes de adjudicar, la mayoría de los problemas conocidos desaparecen.
Y si algo de esto no está claro, casi siempre es mejor retrasar la licitación unas semanas que adjudicar un contrato que nadie sabe cómo evaluar.