Licita
Un copiloto de IA para la contratación pública hospitalaria
Resumen
Un proyecto de investigación independiente que da al equipo de contratación de un hospital evidencia sobre la competencia en el momento clave: antes de publicar la licitación.
El problema
En la contratación pública, gran parte de la competencia por un contrato se decide antes de publicar la licitación, por cómo se redacta. Una licitación que recibe una sola oferta cuesta mucho más que una que recibe varias.
Sin embargo, los equipos de contratación redactan con prisas, sin evidencia de cómo compran lo mismo hospitales comparables ni de qué cláusulas se han anulado antes.
El enfoque
- Primero, descubrimiento: una guía de entrevistas para equipos de contratación, premisas cuestionadas antes de construir y cada decisión de alcance por escrito.
- Una base de datos versionada a partir de los archivos abiertos de contratación pública, con controles de cobertura que detienen la construcción si los campos clave se degradan.
- Los modelos de lenguaje leen resoluciones de tribunales y las estructuran con un esquema estricto y citas literales verificadas. Ningún número que lee el usuario lo calcula un modelo.
- Un sistema de evaluación que contrasta la extracción con el fallo publicado por cada tribunal, con intervalos de confianza y precios fechados. El siguiente paso es un conjunto etiquetado por expertos, del que depende la revisión de cláusulas.
- Anonimato desde el diseño: el código no nombra a ningún comprador, y una comprobación en CI lo garantiza.
Qué construí
Para cada contrato que vence, Licita redacta un informe en español o inglés: cuándo empezar, cómo licitan lo mismo hospitales comparables, cuánto vale un licitador más y a qué proveedores invitar.
Lo siguiente es la revisión de cláusulas: señalar las que se parecen a otras que un tribunal ha anulado, citadas literalmente.
Estado: la primera evaluación en vivo se hizo con modelos alojados de tres tamaños. El mismo código funciona con modelos abiertos autoalojados, que aún no se han medido.
Por qué importa
Recorre el ciclo de forward deployment sobre un único problema: descubrimiento, datos, seguridad, evaluaciones y un despliegue que un hospital podría operar por sí mismo. Aún no tiene cliente; es un proyecto de investigación independiente. El mismo sistema funciona con una API o autoalojado, así que nada tiene que salir de la red del hospital.
Decisiones
Tres decisiones que dieron forma a este proyecto, y por qué las tomé.
-
Ningún número que lee el usuario lo calcula un modelo
- Contexto
- El informe incluye importes y porcentajes sobre los que un equipo de contratación va a actuar. Una cifra que un modelo de lenguaje escribe de memoria no se puede auditar.
- Decisión
- Cada cifra sale de vistas SQL y fichas deterministas, con su fuente y la fecha de los datos; los modelos solo leen texto y extraen estructura.
- Por qué
- Los números se pueden probar contra casos calculados a mano, y las salvaguardas pueden retener uno engañoso. La tarea del modelo queda más acotada y medible, y eso es también lo que hace viable un modelo pequeño.
-
El mismo código, en la nube o en servidores propios
- Contexto
- Los compradores públicos preguntan adónde van sus datos y si el modelo puede funcionar dentro de su propia red.
- Decisión
- Mistral es el único proveedor en la nube, con llamadas REST directas, y las mismas peticiones van a los pesos abiertos de Mistral en un servidor propio cambiando un solo ajuste.
- Por qué
- El despliegue en la nube y el local comparten el mismo código, así que un piloto puede pasar a la red del cliente sin reescribir nada. Renuncié a tener integrada la comparación entre proveedores, porque la que le importa al comprador es la nube frente a sus propios servidores.
-
El anonimato lo garantiza la CI, no la memoria
- Contexto
- La primera versión nombraba a compradores concretos y a una región en el código, las pruebas y la documentación, a veces escondidos dentro de filtros y consultas SQL.
- Decisión
- Todo lo específico de un comprador o una región pasó a un perfil de despliegue que no entra en el repositorio, y una comprobación en CI revisa cada archivo contra una lista de hashes con clave.
- Por qué
- Una norma que hay que recordar acaba fallando; una comprobación automática detiene la construcción. Los hashes llevan clave porque una auditoría antes de publicar demostró que los hashes simples se podían revertir con una lista corta de topónimos.