Una lista de verificación del DPA para AI gateway debería hacer más que confirmar que un proveedor tiene una página legal. Para los compradores de enrutamiento de modelos, la verdadera pregunta es si el acuerdo de tratamiento de datos firmado coincide con la ruta que realmente utilizará su aplicación: registros del gateway, proveedores de modelos upstream, acceso de soporte, enrutamiento regional, controles de retención, derechos de eliminación y notificación de incidentes.
Utilice esta lista de verificación del DPA para AI gateway antes de aprobar una capa unificada de acceso a modelos, un DPA de AI gateway para LLM o un acuerdo de tratamiento de datos para API de IA. No es asesoramiento legal. Es una lista práctica de evidencias para los equipos de plataforma, seguridad, compras y legales que necesitan que el DPA esté alineado con el comportamiento técnico de enrutamiento.
Flatkey encaja en esta revisión porque el sitio público actual posiciona flatkey.ai en torno a una sola clave de API, una URL base compatible con OpenAI en https://router.flatkey.ai/v1, visibilidad de uso y costes, registros de solicitudes, enrutamiento de modelos y acceso a proveedores a través de un solo panel. Trate esas páginas de producto como evidencias de evaluación desactualizadas. Para la aprobación, adjunte su formulario de pedido firmado, el DPA, la configuración de la cuenta y cualquier confirmación de soporte que controle su carga de trabajo real.
Si está construyendo el conjunto de controles más amplio, combine esta revisión con la lista de verificación del gateway de API de IA para GDPR, la lista de verificación del gateway de API de IA para empresas, la lista de verificación de retención de datos de la API de IA y los precios actuales de Flatkey.
Lista de verificación del DPA para AI Gateway: empiece por la ruta
El primer error es revisar al proveedor en general. El DPA tiene que coincidir con una ruta específica. Un chatbot de soporte, un clasificador de documentos por lotes, un asistente de programación y un flujo de trabajo multimedia multimodal pueden tener distintas clases de datos, endpoints, términos del proveedor, comportamiento de almacenamiento y acceso de soporte.
Antes de la revisión legal, congele estos datos de la ruta:
| Campo de la ruta | Pregunta a responder | Evidencia a guardar |
|---|---|---|
| Propietario de la carga de trabajo | ¿Quién es el propietario de la funcionalidad y de los datos enviados a través de ella? | Propietario del producto, propietario de la plataforma, revisor de seguridad |
| Entorno | ¿Es desarrollo, preproducción, producción o específico de un cliente? | Configuración de la ruta, nombre del proyecto, etiqueta de entorno |
| Familia de endpoint | ¿La llamada es chat, responses, mensajes, imagen, vídeo, embeddings, archivos o un flujo de trabajo de herramientas? | Endpoint del gateway y endpoint del proveedor upstream |
| Clase de datos | ¿Pasarán por ella prompts, archivos, imágenes, audio, contenido de clientes, credenciales o datos regulados? | Nota de clasificación de datos y muestra de carga útil redactada |
| Ruta del proveedor | ¿Qué proveedores de modelos pueden recibir la solicitud bajo el enrutamiento normal y de contingencia? | Política de ruta, lista de proveedores, orden de fallback |
| Ruta de registro | ¿Qué sistemas pueden almacenar metadatos de solicitudes, prompts, salidas, errores, tickets de soporte o exportaciones? | Configuración del gateway, documentación del proveedor, configuración de observabilidad |
| Ruta de retención | ¿Qué retiene el gateway, el proveedor upstream, las herramientas de soporte y las copias de seguridad? | DPA, documentación de privacidad, configuración de retención, procedimiento de eliminación |
| Alcance de aprobación | ¿Qué está aprobado y qué requeriría una nueva revisión? | Registro de decisión y fecha de vencimiento de la revisión |
La lista de verificación del DPA para AI gateway debería terminar con un registro de aprobación específico de la ruta, no con una afirmación general de que "la IA está aprobada".
Las diez preguntas sobre tratamiento de datos que deben hacer los compradores
Use estas preguntas como la lista de verificación DPA de proveedor de IA principal para cualquier compra de enrutamiento de modelos.
| # | Pregunta del DPA | Por qué importa para el enrutamiento de modelos | Evidencia aceptable |
|---|---|---|---|
| 1 | ¿Quién es el responsable del tratamiento, el encargado del tratamiento y el subencargado para cada ruta? | Una pasarela puede tratar datos directamente y también transferirlos a proveedores de modelos posteriores. | DPA firmado, lista de subencargados, mapa de rutas/proveedores |
| 2 | ¿Qué categorías de datos están dentro del alcance? | "Los datos de la API" pueden incluir prompts, salidas, archivos cargados, imágenes, registros, metadatos, datos de facturación y tickets de soporte. | Anexo de categorías de datos, ejemplos de cargas útiles, configuración de la cuenta |
| 3 | ¿Qué proveedores pueden recibir la solicitud? | El enrutamiento dinámico y el fallback pueden cambiar la cadena de tratamiento. | Política de rutas, lista de proveedores अनुमतिdos, reglas de fallback |
| 4 | ¿Se almacenan los prompts y las salidas? | Los registros de la pasarela y los registros de monitorización de abuso del proveedor pueden tener un comportamiento de retención diferente. | Configuración de retención de la pasarela, controles de datos del proveedor, prueba de ZDR/MAM cuando corresponda |
| 5 | ¿Qué metadatos se conservan? | Aunque el contenido no se almacene, los metadatos pueden revelar usuarios, cargas de trabajo, costes, tiempos, IP o ID de clientes. | Esquema de registros, campos analíticos, muestra de exportación de facturación |
| 6 | ¿Qué acceso de soporte está permitido? | Las investigaciones de soporte pueden exponer registros de solicitudes, capturas de pantalla, registros o metadatos de cuenta. | Política de acceso de soporte, registros de transparencia de acceso, proceso de redacción de tickets |
| 7 | ¿Qué subencargados se utilizan? | Un DPA está incompleto si no divulga los servicios que tratan datos de clientes. | Lista actual de subencargados y proceso de notificación |
| 8 | ¿Qué proceso de eliminación o devolución existe? | Las compras necesitan saber cómo se eliminan o exportan el contenido conservado, los registros, los archivos y los registros de la cuenta. | SLA de eliminación, pasos de API/panel, nota sobre excepciones de copias de seguridad |
| 9 | ¿Dónde se tratan y almacenan los datos? | El enrutamiento regional, las regiones de los proveedores, los equipos de soporte y los registros pueden no compartir la misma ubicación. | Condiciones de residencia de datos, ajuste de región de ruta, documentación de la región del proveedor |
| 10 | ¿Qué aviso de incidente y evidencia de auditoría estarán disponibles? | Los compradores necesitan un plazo para la notificación de brechas, la comunicación del incidente y la evidencia después de un problema de enrutamiento. | Términos de notificación del DPA, SLA, contacto de seguridad, informe de auditoría, flujo de trabajo de incidentes |
Si la respuesta cambia según el endpoint, la función, el proveedor o el nivel de cuenta, registre esa excepción en la lista de verificación del DPA de la pasarela de IA en lugar de suavizarla.
Haga coincidir el lenguaje del DPA con el tratamiento técnico
Los contratos de encargado de tratamiento al estilo del artículo 28 se centran en el objeto, la duración, la naturaleza, la finalidad, las categorías de datos, los derechos del responsable, las instrucciones del encargado, la confidencialidad, la seguridad, los subencargados, la eliminación o devolución y la asistencia con los derechos de los interesados. Esos son términos jurídicos. Un comprador de una pasarela aún tiene que traducirlos en hechos de ingeniería.
Utilice este mapeo:
| Término del DPA | Traducción técnica para una pasarela de IA |
|---|---|
| Objeto | Inferencia de modelos, enrutamiento, medición, registro, facturación, soporte y administración de cuentas |
| Duración | Cuánto dura el contrato, más cuánto tiempo permanecen los registros, archivos, tickets de soporte y copias de seguridad |
| Naturaleza y finalidad | Enviar solicitudes a proveedores de modelos, devolver salidas, medir el uso, detectar abusos, dar soporte a incidentes |
| Categorías de datos personales | Contenido del prompt, contenido de la salida, archivos cargados, identificadores de usuario, direcciones IP, metadatos de la cuenta, contactos de facturación |
| Instrucciones del encargado | Rutas permitidas, clases de datos bloqueadas, proveedores aprobados, compromisos de no entrenamiento, configuraciones de retención |
| Subencargados | Proveedores de modelos posteriores, alojamiento en la nube, pagos, analítica, soporte, monitorización, correo electrónico y proveedores de seguridad |
| Medidas de seguridad | Cifrado, controles de acceso, registro, gestión de claves, segmentación, proceso de vulnerabilidades, evidencia de auditoría |
| Eliminación o devolución | Eliminación de contenido, eliminación de archivos, caducidad de registros, redacción de tickets de soporte, formato de exportación, excepciones de copias de seguridad |
Aquí es donde se rompen muchas revisiones de acuerdos de tratamiento de datos de API de IA. El DPA puede decir que un encargado actúa según instrucciones, mientras que la ruta del producto permite en silencio el fallback a varios proveedores. El registro de aprobación debe indicar qué proveedores están permitidos, cuáles están bloqueados y quién puede cambiar esa política.
Verifique la retención por endpoint y función
Los controles de datos de los proveedores suelen ser específicos de cada función. Los controles de datos de la plataforma de OpenAI describen restricciones de entrenamiento de API, retención predeterminada de monitorización de abuso, controles aprobados de Zero Data Retention o Modified Abuse Monitoring, y comportamiento de estado de la aplicación específico de cada endpoint. La documentación de retención de datos de la API de Anthropic separa el procesamiento de Claude API del procesamiento en marketplace cloud y explica la elegibilidad para ZDR por función. La documentación de ZDR de Gemini Developer API de Google explica las restricciones de entrenamiento de servicios de pago y los casos a nivel de función en los que los prompts, respuestas, archivos, grounding, estado o comportamiento de caché pueden seguir importando.
Eso significa que "tenemos ZDR" no es suficiente para un DPA de una pasarela de LLM. Pregunte:
- ¿Es el endpoint exacto elegible para el control de retención?
- ¿Está aprobado el proyecto, la organización o la cuenta exactos?
- ¿La ruta de fallback dirige a un proveedor o función que no está cubierto?
- ¿Los archivos, imágenes, audio, vídeo, herramientas, búsqueda web, ejecución de código, caché de contexto, trabajos por lotes o conversaciones con estado cambian la retención?
- ¿Los registros de supervisión de abuso, el estado de la aplicación, los registros de gateway, los registros de soporte, los registros de facturación y las copias de seguridad se gestionan por separado?
Para una ruta de producción, guarde una matriz de retención de una sola fila:
| Sistema | ¿Contenido almacenado? | ¿Metadatos almacenados? | Período de retención | Ruta de eliminación | Evidencia |
|---|---|---|---|---|---|
| Aplicación | Sí o no | Sí o no | Política interna | Proceso de eliminación de la app | Mapa interno de datos |
| Gateway | Sí o no | Sí o no | Configuración de la cuenta o término del proveedor | Panel/API/soporte | Evidencia del gateway |
| Proveedor A | Sí o no | Sí o no | Control del proveedor | Política del proveedor | Documentación del proveedor |
| Proveedor B de fallback | Sí o no | Sí o no | Control del proveedor | Política del proveedor | Documentación del proveedor |
| Herramienta de soporte | Sí o no | Sí o no | Política de tickets | Redacción/eliminación de tickets | Evidencia de soporte |
La lista de verificación del DPA para AI gateway solo está completa cuando cada copia retenida tiene un propietario, una razón y una ruta de eliminación o expiración.
Revise los registros del gateway por separado de los términos del proveedor
Los registros del gateway son útiles para la fiabilidad, el control de costes, la depuración y la revisión de auditoría. También son una superficie de tratamiento de datos independiente. La documentación pública de gateways de proveedores de infraestructura muestra por qué los compradores deberían preguntar esto explícitamente: los registros de solicitudes pueden incluir prompts del usuario, respuestas del modelo, proveedor, marca de tiempo, estado, uso de tokens, coste, duración y metadatos del cliente, y los límites de registros persistentes pueden variar según el plan.
Haga estas preguntas sobre los registros antes de firmar:
- ¿Puede el gateway almacenar prompts o salidas completos, o solo metadatos?
- ¿Se pueden desactivar los registros de prompts y respuestas por ruta, entorno, espacio de trabajo o cliente?
- ¿Se pueden omitir, enmascarar, hashear o redactar campos sensibles antes de registrar?
- ¿Los registros se copian en analíticas, almacenes de datos, alertas, tickets de soporte o exportaciones?
- ¿Quién puede ver los registros y se registra cada acceso?
- ¿Se pueden eliminar los registros antes de tiempo, exportar para auditoría o excluir de los flujos de trabajo de soporte?
- ¿El DPA cubre los registros como datos del cliente, datos del sistema o ambos?
Esta es la diferencia entre una revisión legal del DPA y una lista de verificación operativa del DPA para AI gateway. Si su política de seguridad dice que los prompts no deben almacenarse, la ruta debe demostrar que el gateway, el proveedor y las rutas de soporte siguen la misma regla.
Compruebe los subencargados y el cambio de proveedor
Una cuenta directa de proveedor suele tener una cadena principal de tratamiento. Un enrutador de modelos puede tener una cadena más amplia porque una ruta de la aplicación puede tocar un gateway, un proveedor ascendente, herramientas de observabilidad, infraestructura de pagos, herramientas de soporte y alojamiento en la nube. Si el fallback está habilitado, una solicitud puede ir a un segundo proveedor cuando falle el primero.
El paquete del DPA debería responder:
| Pregunta sobre subencargados | Qué inspeccionar |
|---|---|
| Subencargados actuales | ¿Hay una lista publicada y se incluyen alojamiento, proveedores de modelos, soporte, analítica y proveedores de facturación? |
| Aviso de cambios | ¿Cómo recibirá el comprador aviso de nuevos subencargados? |
| Derechos de objeción | ¿Puede el comprador objetar, rescindir, desactivar una ruta o restringir un proveedor? |
| Lista de अनुमति de proveedores | ¿Puede compras aprobar un conjunto limitado de proveedores para una carga de trabajo específica? |
| Comportamiento de fallback | ¿Se puede desactivar el fallback para rutas sensibles? |
| Cobertura regional | ¿Están alineados los subencargados y las regiones de los proveedores con los requisitos de residencia de datos del comprador? |
| Flujo contractual descendente | ¿Cubren los compromisos de los subencargados la confidencialidad, la seguridad, la eliminación y el soporte ante incidentes? |
Para los compradores de Flatkey, combine la evidencia pública de rutas y precios con los controles específicos de la cuenta. Si su ruta usa una sola clave en varios modelos, la evidencia del DPA aún debe indicar qué proveedores ascendentes pueden procesar cada clase de datos aprobada.
Solicite evidencia de soporte, incidentes y auditoría
El acceso de soporte es fácil de pasar por alto porque normalmente ocurre después de que algo falla. Para una revisión del DPA de gateway, el soporte forma parte del tratamiento.
Solicite:
- El contacto de soporte y la ruta de escalado para incidentes de seguridad o privacidad.
- Si el personal de soporte puede ver prompts, salidas, registros, archivos cargados, capturas de pantalla o metadatos del cliente.
- Si el acceso de soporte está limitado en el tiempo, aprobado y registrado.
- Si hay disponibles registros de transparencia de acceso para las cuentas elegibles.
- Cómo se redactan los tickets de soporte cuando contienen ejemplos de prompts o salidas.
- Qué plazo de notificación de incidentes se aplica según el DPA, los términos, el SLA o el anexo de seguridad.
- Si el proveedor ayudará con solicitudes de interesados, eliminación, exportación y consultas de reguladores.
El Marco de Gestión de Riesgos de IA de NIST es útil aquí como referencia de gobernanza porque anima a las organizaciones a gobernar, mapear, medir y gestionar los riesgos de la IA en lugar de aprobar una ruta una vez y olvidarse de ella. Para un enrutador de modelos, eso significa que la revisión del DPA debe ser renovable. Establezca una fecha de revisión, asigne responsables de las evidencias y vuelva a comprobar los términos del proveedor antes de cambios importantes de ruta.
Construya el paquete de evidencias
El resultado práctico es un pequeño paquete de evidencias que los equipos legales, de seguridad, de compras y de plataforma puedan leer.
| Elemento del paquete | Archivo o registro que guardar |
|---|---|
| Resumen de la ruta | Carga de trabajo, propietario, endpoint, clase de datos, proveedores aprobados, comportamiento de respaldo |
| DPA | Acuerdo de tratamiento de datos firmado y cualquier anexo de seguridad o regional |
| Mapa de datos | Flujo de prompt/salida desde la aplicación al gateway, al proveedor y a los registros/soporte |
| Matriz de retención | Retención del gateway, proveedor, aplicación, soporte, facturación y copias de seguridad |
| Evidencia de subencargados | Lista actual de subencargados y proceso de notificación de cambios |
| Controles de cuenta | Aprobación ZDR/MAM, residencia de datos, ajustes de registro, lista de अनुमति de rutas, ajustes de redacción |
| Muestra de registro | Ejemplo redactado que muestre los campos almacenados, no los secretos |
| Flujo de eliminación | Cómo se eliminan o devuelven el contenido, los archivos, los registros, los tickets y los registros de la cuenta |
| Flujo de incidentes | Plazo de notificación, contacto, escalado y evidencias disponibles después de un evento |
| Decisión de aprobación | Revisores, excepciones, fecha de caducidad y desencadenantes de cambio de ruta |
Para Flatkey, añada la evidencia pública actual de la página principal, la política de privacidad, la página de precios, los términos, el SLA y el panel de la cuenta. Las páginas públicas pueden ayudar a los compradores a filtrar el servicio, pero la evidencia específica de la cuenta debe determinar la decisión final.
Señales de alerta que deben pausar la aprobación
Pare la revisión de la ruta cuando cualquiera de estos puntos no esté resuelto:
- El DPA nombra al proveedor del gateway, pero no la ruta del proveedor de modelo upstream.
- El respaldo puede enviar datos sensibles a un proveedor no aprobado.
- Los registros de prompts o salidas están habilitados, pero el DPA o la revisión de seguridad no los cubren.
- El proveedor dice "sin entrenamiento" pero no puede responder sobre retención, acceso de soporte, eliminación o subencargados.
- Se promete ZDR de forma amplia, pero el endpoint, la función o la cuenta seleccionados no son elegibles.
- Los tickets de soporte pueden incluir prompts en bruto sin un proceso de redacción.
- Los cambios de subencargado no tienen una vía de notificación.
- Se supone que existe enrutamiento regional, pero no se demuestra mediante contrato, ajuste de cuenta o evidencia de uso.
- Los precios, registros y exportaciones de uso contienen identificadores de clientes que no se incluyeron en el mapa de datos.
- La aprobación no tiene propietario ni fecha de revisión.
Estas señales de alerta no siempre significan que el proveedor sea inutilizable. Significan que la lista de verificación del DPA del AI gateway no está completa.
Cómo se ve una buena aprobación
Un registro de aprobación sólido es breve y comprobable:
| Campo de aprobación | Redacción de ejemplo |
|---|---|
| Alcance | "Ruta de triaje de soporte en producción, solo prompts de texto, sin carga de archivos, solo proveedores aprobados A y B." |
| Clase de datos | "Texto de atención al cliente después de la redacción a nivel de aplicación de secretos y pagos." |
| Registro | "El gateway almacena solo metadatos. La aplicación almacena la transcripción redactada durante 30 días. La retención del proveedor sigue el control de cuenta aprobado." |
| Restricciones | "Sin búsqueda web, carga de archivos, entrada de imágenes, carga por lotes ni respaldo fuera de la lista de अनुमति." |
| Evidencia | "DPA firmado, lista de subencargados guardada, matriz de retención adjunta, configuración de la ruta exportada." |
| Renovación | "Volver a revisar antes de añadir proveedores, cambiar familias de endpoints, habilitar registros completos de prompts o enviar datos regulados." |
Este formato hace operativo el DPA. Los desarrolladores saben qué pueden enrutar. Compras sabe qué se aprobó. Seguridad sabe qué vigilar. Legal dispone de evidencias en lugar de promesas dispersas.
Lista final de verificación del DPA para AI Gateway
Antes de comprar o ampliar un enrutador de modelos, confirme estos puntos:
- La lista de verificación del DPA del AI gateway nombra la ruta exacta, el endpoint, la lista de proveedores, la política de respaldo y la clase de datos.
- El acuerdo de tratamiento de datos de la API de IA cubre prompts, salidas, archivos, registros, metadatos, tickets de soporte, registros de facturación y subencargados cuando corresponda.
- El registro del gateway y la retención del proveedor se revisan como sistemas separados.
- Las reclamaciones de ZDR, sin entrenamiento o retención modificada están vinculadas a la cuenta, el proyecto, el endpoint y la función exactos.
- El cambio de proveedor tiene una lista de अनुमति, un propietario y un desencadenante de revisión.
- La eliminación, exportación, acceso de soporte, notificación de incidentes y notificación de cambios de subencargados están documentados por escrito.
- Las páginas públicas del proveedor se tratan como evidencias de filtrado fechadas, no como sustituto del DPA firmado.
- La aprobación tiene un propietario, una fecha de caducidad y una regla para los cambios de ruta.
Si su equipo quiere una sola clave API y un solo panel para acceso multimodelo, empiece con Flatkey y mantenga esta lista de verificación del DPA del AI gateway junto a la revisión técnica de la ruta. Obtenga una clave, confirme los controles actuales de la cuenta y apruebe cada ruta con la misma disciplina que utiliza para cualquier otro procesador de datos de producción.
Fuentes para revisar
- Página principal de Flatkey
- Precios de Flatkey
- Política de privacidad de Flatkey
- Términos de servicio de Flatkey
- Acuerdo de nivel de servicio de Flatkey
- Guía de contratos del ICO
- Controles de datos de OpenAI
- Addendum de tratamiento de datos de OpenAI
- API de Anthropic y retención de datos
- Retención cero de datos de la API para desarrolladores de Gemini
- Registro de Cloudflare AI Gateway
- Precios de Cloudflare AI Gateway y registros persistentes
- Marco de gestión de riesgos de IA del NIST
