Contratación de IA y requisitos de seguridad

En una contratación pública, el pliego fija las reglas para todos los oferentes por igual. Lo que no está en él es difícil de exigir después a quien ganó: habría que renegociar con una sola empresa, sin competencia y con el servicio ya en marcha. Por eso los requisitos de seguridad de un sistema de IA se escriben en el pliego, y los que no son negociables se ponen como habilitantes: si no se cumplen, la propuesta queda fuera, sin importar su precio.

Para un asistente con un modelo dentro, los habituales son: dónde se guardan los datos, la prohibición de usarlos para entrenar o mejorar modelos, registros que la entidad pueda pedir, plazo para avisar de un incidente, pruebas de seguridad del asistente hechas por un tercero, lista cerrada de subcontratistas y una salida ordenada al terminar. Cada uno pide un soporte concreto: un requisito que se acredita con una simple declaración no prueba nada.

La columna de respuesta es lo que el oferente dice de sí mismo. El trabajo del comité es leer el soporte, porque ahí aparecen las frases que importan, a menudo en las condiciones generales del servicio y no en la propuesta.

El recuento de habilitantes es binario: cumple o no habilita. Un «parcial» no es medio punto; el pliego de La Fiquera lo dice expresamente.

A veces un requisito no lo cumple ningún oferente. Puede ser una señal de que el pliego pide algo que el mercado aún no da, o de que todos esperan que el comité lo deje pasar. Antes de decidir, hay que ver qué presentó cada uno: pruebas del propio equipo, pruebas de otro producto o una promesa futura no son lo que pide el pliego.

Con el recuento completo, ninguna de las tres propuestas cumple todos los habilitantes. Un integrante del comité propone adjudicar a la de mejor precio y exigir lo que le falte en el contrato, para no perder la convocatoria. Decide qué le contestas.