# Pliego de requisitos para licitar una pasarela LLM o una plataforma de IA

Actualizado el 9 de noviembre de 2026. Libre para copiar, modificar y usar en sus propios pliegos.

Una empresa o un organismo público que contrata acceso a modelos de lenguaje de gran tamaño para su personal y sus aplicaciones suele contratar una pasarela: una cuenta y una API delante de varios proveedores de modelos. Este pliego recoge 43 requisitos para esa contratación, agrupados en el orden en que los recorre una revisión de seguridad y de compras. Para cada requisito indica por qué importa y qué evidencia conviene pedir al licitador.

Es neutral respecto al proveedor y sirve como anexo de requisitos para una solicitud de ofertas, una licitación pública o una evaluación de seguridad de proveedores. Para las condiciones contractuales propias de la IA, combínelo con las cláusulas contractuales tipo de la UE para la contratación de IA (MCC-AI) (https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses), de carácter voluntario, publicadas en marzo de 2025 en la Public Buyers Community de la Comisión Europea.

Cada requisito está redactado para que el licitador pueda responderlo en un párrafo y adjuntar la evidencia. Marque los que sean obligatorios para usted, pondere el resto y elimine lo que no aplique.

## 1. Ubicación de los datos

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 1 | Región de tratamiento. El proveedor puede limitar la inferencia a una región que indique el órgano de contratación, como la UE/EEE o Europa, para toda la organización, un equipo o una sola clave de API, incluidos los reintentos y las conmutaciones por error. | Las pasarelas cambian de proveedor cuando uno falla. Sin una regla de región que cubra cada intento, una conmutación puede llevar un prompt a otra jurisdicción sin que nadie lo advierta. | La política de enrutamiento para el tráfico restringido, los endpoints permitidos en cada región con su ubicación y qué ocurre cuando ningún endpoint de la región puede atender una solicitud. |
| [ ] | 2 | Definición de la región. El proveedor indica qué países abarca cada región, por ejemplo solo la UE/EEE, o también el Reino Unido, Suiza u otros países. | Los materiales comerciales suelen usar Europa y UE como sinónimos. Su evaluación de las transferencias depende de la lista exacta. | Una definición por escrito de cada región y la ubicación del tratamiento de cada subencargado incluido en ella. |
| [ ] | 3 | Ubicación de la entrada y de la pasarela. El proveedor indica dónde termina TLS, dónde se ejecuta la pasarela y qué nombre de host debe usarse para el tratamiento regional. | Una solicitud puede atenderla un modelo en la región correcta y aun así pasar antes por una red perimetral global. | Los nombres de host por región, el proveedor de alojamiento y la región del balanceador de carga y de la pasarela, y un diagrama de flujo de datos. |
| [ ] | 4 | Ubicación de metadatos y registros. El proveedor indica dónde se almacenan y tratan los datos de la cuenta, los registros de uso, los registros operativos, las copias de seguridad y el correo electrónico. | Las respuestas sobre residencia de datos suelen cubrir solo los prompts. Los metadatos también contienen datos personales, como nombres, direcciones de correo electrónico y direcciones IP. | Una ubicación de almacenamiento por categoría de datos, incluidas las copias de seguridad y el correo transaccional. |

## 2. Conservación y retención cero de datos

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 5 | Sin almacenamiento de contenido por el proveedor. El proveedor trata los prompts y las respuestas solo para atender la solicitud, o indica con exactitud qué contenido almacena, dónde y durante cuánto tiempo. | La pasarela ve cada prompt que envía su organización. Su propia conservación de datos es la primera exposición que hay que revisar. | Una descripción del flujo de datos, el esquema de registro con los campos que se escriben y la cláusula correspondiente del contrato de encargo. |
| [ ] | 6 | Retención cero de datos en los proveedores de modelos. El órgano de contratación puede exigir que las solicitudes vayan solo a endpoints de modelos que se comprometen a no guardar ninguna copia del contenido, a nivel de organización, equipo o clave, sin que los niveles inferiores puedan desactivarlo. | Los proveedores de modelos suelen conservar los prompts durante un tiempo para vigilar abusos, salvo que el endpoint tenga un acuerdo de retención cero. | Las condiciones de conservación de cada proveedor, cómo se aplica el ajuste en cada solicitud y qué funciones quedan desactivadas mientras está activo. |
| [ ] | 7 | Funciones que almacenan contenido. El proveedor enumera cada función que almacena contenido (caché de prompts, respuestas almacenadas, estado de la conversación, archivos, trabajos por lotes) con su plazo de conservación y el ajuste que la desactiva. | Los compromisos de conservación suelen incluir excepciones para ciertas funciones. La lista muestra dónde están esas excepciones. | Una lista de funciones con el plazo de conservación de cada una y el control que la desactiva. |
| [ ] | 8 | Supresión al final del contrato. El proveedor suprime o devuelve los datos del órgano de contratación en un plazo determinado tras el fin del servicio y lo confirma por escrito. | El artículo 28, apartado 3, letra g), del RGPD exige que el contrato con el encargado del tratamiento regule la supresión o devolución al finalizar la prestación de los servicios. | La cláusula del contrato de encargo con el plazo, el tratamiento de las copias de seguridad y un modelo de confirmación de supresión. |

## 3. Entrenamiento y uso de los datos

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 9 | Sin entrenamiento por el proveedor. El proveedor no usa prompts, respuestas ni metadatos para entrenar o mejorar modelos. | El entrenamiento es el uso que los compradores excluyen con más frecuencia, y la exclusión solo vincula si figura en el contrato. | La cláusula del contrato o del contrato de encargo y el apartado correspondiente de la política de privacidad. |
| [ ] | 10 | Sin entrenamiento por los proveedores de modelos. El proveedor envía el tráfico del órgano de contratación solo a proveedores que se comprometen a no entrenar con él, y explica cómo se aplica en cada solicitud. | El compromiso de la pasarela no vincula a los proveedores de modelos que hay detrás. | Las condiciones de cada proveedor por endpoint, el mecanismo de aplicación y el tráfico que cubre. |
| [ ] | 11 | Otros usos secundarios. El proveedor indica si el contenido o los metadatos se usan para analítica, comparativas, mejora del producto o revisión humana, y cómo oponerse. | Los usos secundarios quedan fuera de las instrucciones que un responsable del tratamiento da a un encargado, salvo que se hayan acordado. | Una lista de usos secundarios, la política de revisión humana y el ajuste para excluirse. |

## 4. Subencargados y contrato de encargo

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 12 | Contrato de encargo del tratamiento. Antes de la firma se dispone de un contrato conforme al artículo 28 del RGPD que regula objeto, duración, instrucciones, confidencialidad, seguridad, asistencia, supresión y auditorías. | El artículo 28, apartado 3, enumera lo que debe contener el contrato con el encargado. Una pasarela trata datos personales en cada prompt que menciona a una persona. | El texto del contrato de encargo, la ley aplicable y la forma de firma. |
| [ ] | 13 | Lista de subencargados. El proveedor publica cada subencargado del tratamiento con su finalidad, los datos que trata y su ubicación, incluidos los proveedores de modelos y de inferencia. | En una pasarela, cada proveedor de modelos que puede atender su tráfico es un subencargado. | La URL de la lista y la fecha de su último cambio. |
| [ ] | 14 | Aviso de nuevos subencargados. El proveedor avisa con una antelación determinada antes de añadir o sustituir un subencargado, con derecho de oposición. | El artículo 28, apartado 2, exige informar al responsable del tratamiento de los cambios y darle la oportunidad de oponerse. | La cláusula del contrato de encargo con el plazo de aviso y el canal por el que se avisa. |
| [ ] | 15 | Transferencias internacionales. Para cualquier tratamiento fuera del EEE, el proveedor indica el mecanismo de transferencia (decisión de adecuación, cláusulas contractuales tipo, UK IDTA). | Las transferencias necesitan una base jurídica conforme al capítulo V del RGPD, y el órgano de contratación documenta su evaluación. | Los anexos de las cláusulas contractuales tipo y un resumen de la evaluación de impacto de las transferencias del proveedor. |
| [ ] | 16 | Notificación de violaciones de seguridad. El proveedor notifica las violaciones de la seguridad de los datos personales sin dilación indebida y en un número de horas determinado. | El responsable del tratamiento dispone de 72 horas para notificar a la autoridad de control según el artículo 33, así que el plazo del encargado debe ser igual o más corto. | La cláusula del contrato de encargo, un resumen del proceso de respuesta a incidentes y el contacto de seguridad. |

## 5. Identidad y acceso

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 17 | Inicio de sesión único. Acceso mediante SAML 2.0 u OpenID Connect con el proveedor de identidad del órgano de contratación, como Microsoft Entra ID, Okta o Google Workspace, para la consola de administración y para los usuarios. | Las cuentas de trabajo vinculan el acceso a la relación laboral y aplican las políticas de MFA y de inicio de sesión del comprador. | Los protocolos y proveedores de identidad admitidos, la guía de configuración y una conexión de prueba. |
| [ ] | 18 | SSO obligatorio. El órgano de contratación puede exigir SSO a todos los usuarios y desactivar las contraseñas y otros métodos de acceso. | Un SSO que convive con contraseñas deja cuentas fuera del control del proveedor de identidad. | El ajuste y cómo trata las sesiones abiertas y las claves de API existentes. |
| [ ] | 19 | Aprovisionamiento de usuarios. Aprovisionamiento y desaprovisionamiento SCIM 2.0 desde el proveedor de identidad, con asignación de grupos a roles o equipos. | Sin desaprovisionamiento, quienes dejan la organización conservan el acceso hasta que alguien se acuerda de retirarlo. | Los recursos SCIM admitidos (usuarios, grupos) y en cuánto tiempo el desaprovisionamiento revoca sesiones y claves. |
| [ ] | 20 | Roles y claves de API. Control de acceso basado en roles, una clave por persona y por aplicación, claves con alcance limitado y revocación inmediata. | Las claves compartidas ocultan quién envió cada solicitud y no se pueden revocar para una sola persona. | La matriz de roles y el ciclo de vida de las claves: creación, alcance, rotación y revocación. |
| [ ] | 21 | Aplicaciones de escritorio y agentes de programación. El proveedor indica cómo se autentican los empleados en aplicaciones de IA de escritorio y agentes de programación (por ejemplo Claude Desktop, Claude Code y extensiones de IDE): con su cuenta de trabajo o con claves distribuidas. | En estas herramientas aparecen cuentas personales y claves copiadas fuera del proceso de compras. | La guía de configuración y la lista de herramientas compatibles. |

## 6. Control del gasto

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 22 | Presupuestos en los niveles que usted gestiona. Límites mensuales estrictos por usuario, por aplicación y por equipo o departamento, que detienen el gasto al alcanzar el límite. | Los agentes y los trabajos por lotes pueden gastar el presupuesto de un mes en horas. Un límite que solo avisa es un informe. | Los niveles admitidos y qué ocurre al llegar al límite: bloqueo, aviso o exceso facturado. |
| [ ] | 23 | Tope de la organización y alertas. Un tope para toda la organización y alertas antes de alcanzar cualquier límite. | Finanzas necesita una cifra que no se pueda superar, pase lo que pase por debajo. | Los ajustes y los canales de alerta. |
| [ ] | 24 | Precios y facturación. Precio por modelo o por plan, la moneda de facturación, facturas con los datos de la empresa y el NIF-IVA del comprador, e informes de costes por usuario y aplicación para la imputación interna. | Los precios por token difieren entre modelos en órdenes de magnitud, así que la evaluación necesita la base de precios y los informes. | La lista de precios, una factura de ejemplo y un informe de uso de ejemplo. |

## 7. Acceso a modelos y listas de permitidos

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 25 | Catálogo de modelos. Los modelos de frontera y de pesos abiertos ofrecidos, y cuáles están disponibles con cada regla de región. | Un modelo que no está disponible en su región deja de estar disponible para usted en cuanto activa la regla de región. | Una lista de modelos por región y la política para añadir modelos. |
| [ ] | 26 | Listas de modelos permitidos. Los administradores eligen qué modelos puede usar cada equipo, aplicación o clave. Las solicitudes a otros modelos se rechazan. | La aprobación de un modelo que solo figura en un documento de política no impide a nadie llamar a otro modelo. | El ajuste y el error que se devuelve para un modelo no permitido. |
| [ ] | 27 | Listas de proveedores permitidos. Los administradores eligen qué proveedores de inferencia pueden atender el tráfico. Las conmutaciones respetan la lista y nunca se añaden proveedores nuevos sin aprobación. | Un proveedor que añade el licitador es un nuevo lugar donde se tratan sus datos. | El ajuste, cómo lo aplican las conmutaciones y qué ocurre cuando el licitador añade un proveedor. |
| [ ] | 28 | Cambios de modelo. El proveedor avisa con antelación de las retiradas de modelos y los cambios de versión, y el órgano de contratación puede fijar una versión. | Un cambio de modelo silencioso altera la calidad de las respuestas y puede invalidar la evaluación hecha para un caso de uso. | La política de retirada de modelos y el canal de aviso. |
| [ ] | 29 | Transparencia del enrutamiento. Si el proveedor enruta automáticamente entre modelos o proveedores, por coste o disponibilidad, documenta las reglas y registra qué modelo y qué proveedor atendió cada solicitud. | El enrutamiento automático solo aporta valor si usted puede ver adónde fue cada solicitud. | La documentación del enrutamiento y un registro de ejemplo por solicitud. |

## 8. Registros de auditoría y exportación

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 30 | Registro de auditoría de administración. Cada cambio en usuarios, claves, presupuestos y políticas, con autor, fecha y hora, y los valores anterior y nuevo. | Los revisores preguntan quién cambió una política y cuándo. Sin los valores anterior y nuevo, el registro no puede responder qué cambió. | Una entrada de registro de ejemplo y el plazo de conservación. |
| [ ] | 31 | Registro de solicitudes. Para cada solicitud: fecha y hora, usuario o clave, modelo, proveedor que la atendió, regla de región, estado, tokens y coste, sin contenido salvo que el comprador lo active, con un plazo de conservación determinado. | Para los usos de alto riesgo, el artículo 26, apartado 6, del Reglamento de IA pide a los responsables del despliegue conservar los archivos de registro que estén bajo su control durante al menos seis meses. El registro de solicitudes es también la evidencia del inventario de IA. | La lista de campos, el plazo de conservación y una exportación de ejemplo. |
| [ ] | 32 | Exportación. Los registros se exportan en CSV o mediante una API y pueden enviarse al SIEM del órgano de contratación. | Los registros que el comprador no puede extraer no le sirven para su propia auditoría. | Los formatos, los límites de filas o de periodo y la documentación de la API. |

## 9. Obligaciones del responsable del despliegue según el Reglamento de IA

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 33 | Apoyo al inventario y a la alfabetización. El proveedor facilita la información que el comprador necesita para su inventario de IA y sus medidas de alfabetización en materia de IA del artículo 4: los modelos usados en cada aplicación, sus proveedores y sus limitaciones documentadas. | El artículo 4 se aplica desde el 2 de febrero de 2025, y el inventario es el punto de partida de todas las demás obligaciones del Reglamento de IA. | Registros de modelo y proveedor por aplicación, y enlaces a la documentación de los modelos. |
| [ ] | 34 | Usos de alto riesgo. Si el comprador va a usar el servicio para una finalidad del anexo III, el proveedor indica su papel según el Reglamento de IA y acepta las cláusulas pertinentes de las cláusulas contractuales tipo de la UE para la IA. | Las obligaciones del responsable del despliegue para el anexo III se aplican desde el 2 de diciembre de 2027 y dependen de información que solo tienen el proveedor y el proveedor del modelo. | La declaración del proveedor sobre su papel y un anexo MCC-AI cumplimentado (High Risk o Light). |
| [ ] | 35 | Documentación de los modelos de IA de uso general. Para cada modelo de IA de uso general ofrecido, el proveedor enlaza la documentación que su proveedor pone a disposición de los proveedores posteriores y el resumen público del contenido de entrenamiento. | El artículo 53 obliga a los proveedores de modelos de IA de uso general a ponerla a disposición, y los compradores la archivan por modelo. | Los enlaces por modelo y la fecha de consulta. |
| [ ] | 36 | Transparencia. El proveedor indica si las respuestas llevan un marcado legible por máquina y cómo apoya las obligaciones de información del comprador. | Las obligaciones de transparencia del artículo 50 se aplican desde el 2 de agosto de 2026. | La información de marcado por modelo y orientaciones para informar. |

## 10. Salida y portabilidad

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 37 | Interfaz estándar. La API sigue una interfaz de uso extendido, como el formato de chat completions compatible con OpenAI, de modo que las aplicaciones puedan cambiar sin reescribirse. | Una interfaz propietaria convierte un cambio de proveedor en un proyecto de software. | La referencia de la API y los SDK y herramientas que se sabe que funcionan con ella. |
| [ ] | 38 | Exportación de datos a la salida. El órgano de contratación puede exportar la configuración, los usuarios, los metadatos de las claves, el uso y los registros en un formato legible por máquina antes y después de la resolución del contrato. | Si el servicio es un servicio de tratamiento de datos en el sentido del Reglamento de Datos, el capítulo VI da al cliente derechos de cambio de proveedor, y desde el 12 de enero de 2027 no pueden imponerse costes por cambio. | Los formatos de exportación, la asistencia ofrecida para la transición y el tiempo que los datos siguen disponibles tras el preaviso. |
| [ ] | 39 | Duración y preaviso. Duración del contrato, plazo de preaviso, posibles cargos por resolución y periodo de transición. | Las duraciones largas y los cargos por resolución determinan lo que cuesta salir. | Las condiciones comerciales y la cláusula de resolución. |

## 11. Soporte y SLA

| Obligatorio | N.º | Requisito | Por qué importa | Evidencia que pedir |
| --- | --- | --- | --- | --- |
| [ ] | 40 | SLA de disponibilidad. Un compromiso de disponibilidad mensual con créditos de servicio, el método de medición y las exclusiones. | La IA está entrando en procesos productivos, donde una caída tiene un coste. | El documento del SLA, la página de estado pública y la disponibilidad de los últimos 12 meses. |
| [ ] | 41 | Conmutación entre proveedores. Cuando un proveedor de modelos no está disponible, las solicitudes pasan a otro proveedor aprobado del mismo modelo, dentro de las reglas de región y de las listas de permitidos. | Una conmutación que ignora la región o la lista de permitidos incumple las reglas justo cuando ya hay un incidente en curso. | El diseño de la conmutación y el número de proveedores por modelo con cada regla de región. |
| [ ] | 42 | Soporte y comunicación de incidentes. Canales de soporte, tiempos de respuesta por gravedad, idiomas y cómo se comunican los incidentes. | El proceso de incidentes del comprador depende del del proveedor. | La política de soporte, la URL de la página de estado e informes de incidentes recientes. |
| [ ] | 43 | Documentación de seguridad. Una descripción general de la seguridad, un cuestionario de seguridad cumplimentado y los informes de aseguramiento o certificaciones que tienen el proveedor y sus proveedores de alojamiento. | Es lo que revisa el equipo de seguridad del comprador antes de aprobar. Pedirlo con la licitación ahorra una ronda. | La página de seguridad, un cuestionario cumplimentado como el cuestionario de seguridad abierto para pasarelas LLM (https://standardcompute.com/cuestionario-de-seguridad-pasarela-llm) y los informes que haya. |

---

## Fuentes

- [Cláusulas contractuales tipo de la UE para la IA actualizadas (MCC-AI High Risk y Light), Public Buyers Community, 5 de marzo de 2025](https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses)
- [Reglamento (UE) 2016/679, Reglamento General de Protección de Datos (RGPD), artículos 28 y 33, EUR-Lex](https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32016R0679)
- [Reglamento (UE) 2024/1689, Reglamento de Inteligencia Artificial, artículos 4, 26, 50 y 53, EUR-Lex](https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32024R1689)
- [Reglamento (UE) 2023/2854, Reglamento de Datos, capítulo VI sobre el cambio entre servicios de tratamiento de datos, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2023/2854/oj)
- [RFC 7644, protocolo SCIM 2.0](https://www.rfc-editor.org/rfc/rfc7644) y [SAML 2.0 Core, OASIS](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

_Pliego gratuito de requisitos para licitar una pasarela LLM o una plataforma de IA, de https://standardcompute.com/pliego-prescripciones-tecnicas-pasarela-llm (versión del 9 de noviembre de 2026). Libre para copiar y modificar. No constituye asesoramiento jurídico._