Una revisión del alcance del API gateway de IA en SOC 2 no debería comenzar con la insignia. Debería comenzar con una pregunta simple: ¿qué sistema, período, controles, dependencias y responsabilidades propiedad del comprador cubrió realmente el informe?
Esa distinción importa para el enrutamiento de modelos. Un API gateway de IA puede situarse entre tu aplicación y múltiples proveedores de modelos, familias de endpoints, registros, flujos de trabajo de soporte, registros de facturación y rutas de fallback. Un informe SOC 2 Type 2 puede ser una evidencia útil del sistema descrito por el proveedor del gateway y de los criterios de servicios de confianza cubiertos. No debe tratarse como prueba de que cada proveedor de modelo upstream, cada ruta, cada configuración de retención de prompts, cada configuración de cuenta del comprador o cada cambio futuro de modelo esté aprobado.
Utiliza esta lista de verificación de alcance del API gateway de IA en SOC 2 cuando compras, seguridad, legal y ingeniería de plataforma necesiten decidir qué debe probar el informe, qué no debe probar y qué evidencia de seguimiento debe incluirse en el paquete de aprobación.
Flatkey es relevante para esta revisión porque el sitio público actual posiciona a flatkey.ai como un API gateway de IA y una plataforma de operaciones de modelos para enrutar tráfico oficial de GPT, Claude, Gemini y otros modelos a través de una sola clave, con superficies de panel, facturación, enrutamiento, uso y evidencia operativa. Las páginas públicas de Flatkey y las páginas de búsqueda de certificados son solo evidencia de filtrado con fecha. Para la aprobación en producción, solicita el informe SOC 2 privado, el contrato/DPA firmado cuando corresponda, la configuración de la cuenta, la configuración de rutas y la confirmación de soporte para la carga de trabajo que vas a ejecutar.
Para un contexto más amplio de compras, combina este artículo con la lista de verificación de evidencia del API gateway de IA en SOC 2, el paquete de evidencia de compras del gateway de IA y la evaluación de riesgo del proveedor de API de IA.
Alcance del API Gateway de IA en SOC 2: tabla rápida de decisión
La primera página de la revisión debería separar la evidencia del informe de la evidencia de seguimiento del comprador.
| Área de revisión | Qué debería ayudar a probar el informe SOC 2 | Qué no debería probar por sí solo |
|---|---|---|
| Entidad legal | Qué organización de servicios fue examinada | Que cada afiliado, revendedor o proveedor de modelos upstream esté cubierto |
| Límite del sistema | Qué plataforma, servicios, ubicaciones, infraestructura, personas y procesos están en el sistema descrito | Que cada función del panel, familia de endpoints, ruta del cliente o integración futura esté en alcance |
| Período del informe | El período cubierto por la revisión Type 2 | Que los controles actuales no hayan cambiado después de que terminó el período |
| Categorías de servicios de confianza | Qué criterios se cubrieron, como seguridad, disponibilidad, confidencialidad, integridad del procesamiento o privacidad | Que se examinaran categorías no seleccionadas |
| Controles probados | Qué controles probó el auditor y los resultados del período | Que se hayan probado la configuración del comprador, la política de rutas o la clase de datos de la carga de trabajo |
| Excepciones | Si se registraron excepciones de control y cómo respondió la dirección | Que las excepciones sean inmateriales para tu carga de trabajo específica |
| Organizaciones de servicios subcontratadas | Si las dependencias principales están incluidas, excluidas o tratadas por otros informes | Que la retención, el entrenamiento, el registro o el comportamiento regional del proveedor de modelos upstream estén cubiertos |
| CUECs | Qué controles complementarios de la entidad usuaria debe operar el comprador | Que el proveedor sea responsable del almacenamiento de claves del comprador, la redacción, las listas de अनुमति de proveedores o la clasificación de datos a nivel de aplicación |
Esta es la regla central del alcance del API gateway de IA en SOC 2: el informe es evidencia sobre un sistema de organización de servicios descrito durante un período definido. No es una aprobación general para cada ruta de IA que tu equipo pueda crear.
Fija los cinco campos de alcance antes de leer los controles
No empieces buscando una opinión limpia. Empieza con cinco campos.
| Campo | Pregunta del comprador | Evidencia que guardar |
|---|---|---|
| Entidad | ¿Quién es la organización de servicios auditada? | Página de portada del informe, entidad legal, contraparte contractual, búsqueda de certificado si es pública |
| Sistema | ¿Qué servicios, infraestructura, equipos, procesos y flujos de datos están incluidos? | Descripción del sistema, lista de productos/servicios, diagrama del límite del sistema |
| Período | ¿Qué período Type 2 cubrió el informe? | Fecha de inicio, fecha de fin, carta puente si es necesario |
| Criterios | ¿Qué categorías de servicios de confianza se incluyeron? | Alcance de seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad |
| Dependencias | ¿Qué organizaciones de servicios subcontratadas y CUECs afectan la opinión? | Método de inclusión/exclusión, lista de subservicios, lista de controles del comprador |
Para un gateway de IA, el campo sistema merece la mayor atención. "API gateway" puede significar solo el enrutamiento de URL base, o también puede incluir acceso al panel, catálogo de modelos, saldo de cuenta, medición de uso, registros de solicitudes, alertas, flujos de trabajo de soporte, respuesta a incidentes y gestión de claves. El informe privado debería decirte qué estaba incluido en la descripción del sistema. Si no lo hace, pide al proveedor que mapee el alcance del informe a la ruta exacta que planeas usar.
Qué debería probar un informe SOC 2 para un gateway de IA
Un informe SOC 2 Type 2 delimitado debería ayudar a un comprador a responder estas preguntas.
| Área de prueba | Evidencia útil de SOC 2 | Traducción para un gateway de IA |
|---|---|---|
| Diseño y operación de controles | Controles probados durante el período del informe | Si los controles de acceso, gestión de cambios, monitoreo, respuesta a incidentes, gestión de proveedores y controles relacionados operaron para el sistema del gateway descrito |
| Alcance de disponibilidad | Criterios de disponibilidad, monitoreo cercano a SLA, procesos de incidentes si se incluyen | Si el servicio cubierto tenía controles definidos de monitoreo y respuesta, no si cada proveedor de modelo seguirá disponible |
| Alcance de confidencialidad y privacidad | Criterios y controles si se incluyen estas categorías | Si se examinaron los controles de manejo de datos del cliente para el sistema descrito, no si cada función del proveedor tiene la misma configuración de retención |
| Gestión de cambios | Controles probados de liberación, aprobación y cambios | Si los cambios de código/configuración del gateway estuvieron controlados, no si una ruta aprobada por el comprador no puede ser cambiada después por el comprador |
| Controles de acceso | Acceso del personal, acceso privilegiado, revisión de administradores, controles de gestión de cuentas | Si el acceso del lado del proveedor estuvo controlado, no si el comprador almacenó de forma segura las claves de API |
| Seguridad lógica | Controles de autenticación, autorización, registro, vulnerabilidades y monitoreo | Si existían los controles de seguridad descritos del gateway, no si las aplicaciones del comprador redactan secretos antes de enviar prompts |
| Gestión de proveedores | Controles de organización de subservicios y monitoreo de proveedores | Si se gestionaron las dependencias de proveedores, no si el SOC 2, el DPA o la configuración de retención de cada proveedor upstream cubren su ruta |
Aquí es donde el alcance del API gateway de IA en SOC 2 se vuelve práctico. El informe puede respaldar la evaluación del riesgo de proveedores. Aun así, debe traducirse en hechos de la ruta: familia de endpoints, clase de datos, lista de अनुमति de proveedores, política de fallback, registro de prompts/outputs, retención de metadatos, acceso de soporte y ruta de eliminación.
Qué No Debe Probar El Informe
El error de compras más común es dejar que un informe SOC 2 sustituya decisiones para las que no fue diseñado.
No use el informe por sí solo para probar:
| Reclamación | Por qué necesita seguimiento |
|---|---|
| "Todos los proveedores de modelos están cubiertos." | Los proveedores upstream pueden ser organizaciones de subservicios, quedar fuera por carve-out o estar fuera del alcance del informe del gateway. Pida el mapa de proveedores y la evidencia aplicable de cada proveedor. |
| "No se almacenan prompts ni outputs en ningún lugar." | Los registros del gateway, los logs de monitoreo de abuso del proveedor, el estado de la aplicación, los tickets de soporte y las copias de seguridad pueden tener un comportamiento de retención diferente. |
| "No hay entrenamiento que aplique a todas las rutas." | Los compromisos de entrenamiento y retención suelen ser específicos del proveedor, la cuenta, el endpoint y la función. Guarde evidencia a nivel de cuenta. |
| "El fallback está aprobado." | Una ruta de fallback puede enviar datos a un proveedor o región diferente. El registro de aprobación debe nombrar los proveedores de fallback permitidos. |
| "La aplicación del comprador cumple con los requisitos." | SOC 2 trata sobre los controles de la organización de servicios. La redacción del comprador, el almacenamiento de claves, la clasificación de datos y los controles de acceso de la aplicación son responsabilidades del comprador. |
| "La revisión de privacidad o DPA está hecha." | SOC 2 no es un DPA firmado, una evaluación de transferencia de datos, un aviso de privacidad, un BAA ni un compromiso de procesamiento regional. |
| "El estado actual es idéntico al período del informe." | El período del informe puede haber terminado hace meses. Pida cartas puente, políticas actuales, configuración actual de la ruta y evidencia reciente. |
| "Se garantizan los precios, la disponibilidad del modelo y los resultados del SLA." | Los catálogos de modelos, los precios, los límites de tasa de los proveedores y la disponibilidad de terceros pueden cambiar fuera del informe SOC 2. |
Si un proveedor dice "SOC 2 cubre eso", pídale que señale la sección exacta, el lenguaje del límite del sistema, el criterio cubierto, el control, el resultado de la prueba y cualquier nota de CUEC u organización de subservicios.
Lea las Organizaciones de Subservicios Antes de Aprobar Proveedores
Un gateway de IA puede depender de alojamiento en la nube, sistemas de pago, analítica, herramientas de soporte, proveedores de observabilidad, herramientas de seguridad y proveedores upstream de modelos. El informe SOC 2 debe explicar cómo se manejan las organizaciones de subservicios. Los compradores suelen ver uno de dos enfoques:
| Método | Qué significa para el comprador |
|---|---|
| Método inclusivo | Los controles relevantes de la organización de subservicios están incluidos en el alcance del informe. Revise qué controles están incluidos. |
| Método de carve-out | La organización de subservicios queda excluida del alcance del informe. Revise evidencia aparte y los controles complementarios de la organización de subservicios. |
Para el enrutamiento de modelos, los carve-outs importan. El informe SOC 2 de un gateway puede cubrir los controles de gestión de proveedores del gateway y dejar a OpenAI, Anthropic, Google u otro proveedor upstream fuera del sistema auditado. Eso no hace inútil el informe. Significa que la revisión del alcance del API gateway de IA en SOC 2 debe incluir una fila de evidencia de proveedor para cada ruta aprobada.
La documentación del proveedor muestra por qué esto no puede inferirse. La documentación de control de datos de la API de OpenAI separa los registros de monitoreo de abuso, el estado de la aplicación, la retención cero de datos, el monitoreo de abuso modificado y el comportamiento específico de cada endpoint. La documentación de retención de datos de la API de Anthropic explica que distintas APIs y funciones tienen diferentes necesidades de almacenamiento y que ZDR es un acuerdo que los clientes solicitan para casos de uso elegibles. La documentación de registro de AI Gateway de Cloudflare muestra cómo un gateway puede exponer prompts, respuestas, proveedor, marca de tiempo, uso de tokens, costo, duración, acciones de DLP y controles de registro a nivel de payload. Esos son ejemplos de superficies de control que un comprador debe inspeccionar para cualquier ruta del gateway, no afirmaciones sobre el informe privado de Flatkey.
Trate los CUEC como trabajo del comprador, no como texto estándar
Los controles complementarios de la entidad usuaria no son relleno. Son los controles que el comprador debe operar para que los controles de la organización de servicios tengan sentido.
Para un gateway de IA, el trabajo habitual de CUEC del lado del comprador incluye:
| Control propiedad del comprador | Pruebas que conservar |
|---|---|
| Almacenamiento y rotación de claves | Ruta del gestor de secretos, propietario, fecha de rotación, runbook de rotación de emergencia |
| Aprobación de rutas | Familias de endpoints aprobadas, allowlist de proveedores, política de fallback, clases de datos |
| Redacción de prompts | Reglas de redacción a nivel de aplicación, transcripción de prueba, ejemplos de campos bloqueados |
| Revisión de acceso | Lista de administradores, propietarios de claves, registro de baja, revisión de acceso al panel |
| Política de registro | Si se almacenan prompts y salidas, regla de solo metadatos, calendario de retención |
| Monitoreo de uso | Propietario del presupuesto, ajustes de cuota, umbrales de alerta, cadencia de revisión financiera |
| Flujo de incidentes | IDs de solicitud, ruta de escalamiento al soporte, paquete de evidencia, responsables de notificación |
| Disparador de renovación | Fecha de revisión y disparadores para nuevos proveedores, familias de endpoints, clases de datos o cambios de registro |
Un buen memorando de alcance del API Gateway de IA en SOC 2 debe adjuntar la lista de CUEC al trabajo de ingeniería. Si el comprador debe redactar secretos antes de enviar prompts, la aprobación debe apuntar a la prueba de redacción. Si el comprador debe aprobar proveedores de modelos, la configuración de ruta debe mostrar la allowlist.
Pruebas de filtrado específicas de Flatkey que solicitar y guardar
Las páginas públicas actuales de Flatkey, revisadas el 11 de julio de 2026, respaldan el uso de Flatkey en este flujo de adquisición, pero no sustituyen la evidencia específica de la cuenta.
| Evidencia | Qué mostró la comprobación pública | Cómo usarla |
|---|---|---|
| Página principal | Flatkey se posiciona públicamente alrededor de las API oficiales de GPT, Claude y Gemini a través de una sola clave, enrutamiento de modelos, revisión del panel, visibilidad de uso, costo, enrutamiento y errores. | Úsela como evidencia de filtrado del producto con fecha. No la trate como alcance del informe SOC 2 privado. |
| Página de precios y API de precios | Las superficies públicas de precios/catálogo devolvieron una página de precios activa y una respuesta de la API de precios con 158 filas de modelos y familias de endpoints que incluyen openai, openai-response, anthropic, image-generation y openai-video. |
Úsela solo como una instantánea del catálogo con fecha. La disponibilidad de modelos y endpoints puede cambiar. |
| Página de SLA | El SLA indica que aplica al panel alojado operado por Flatkey, el API gateway, el enrutamiento, la medición y los servicios de cuenta, y excluye a los proveedores de modelos de IA de terceros y otros sistemas externos. | Úsela para delimitar qué opera directamente Flatkey frente a las dependencias de terceros. |
| Páginas de privacidad y términos | Las páginas públicas de políticas hablan sobre acceso a la API, enrutamiento de modelos, registros de uso, facturación, soporte, proveedores de modelos de terceros y cambios en las reglas de modelos/proveedores. | Úselas como evidencia de filtrado; la aprobación final aún necesita términos firmados y pruebas específicas de manejo de datos por ruta. |
| Búsqueda de certificado | La búsqueda pública de CAI mostró el certificado USA-SOC2-220513 de VOC AI Inc., SOC 2 Tipo II, activo, período del 15 de julio de 2025 al 14 de julio de 2026. |
Úsela solo como búsqueda pública. Solicite el informe SOC 2 real y confirme el sistema cubierto, los criterios, el período, las excepciones, los CUEC y el tratamiento de los subservicios. |
Para Flatkey o cualquier API gateway de IA, la aprobación debe decir: "Se revisaron las páginas públicas; se solicitó el informe privado; se adjuntó evidencia de la ruta; se enumeraron las suposiciones no respaldadas."
Construya un paquete de evidencia de alcance a ruta
El resultado de esta revisión debe ser un pequeño paquete de evidencia, no una aprobación vaga.
| Elemento del paquete | Archivo a guardar | Responsable |
|---|---|---|
| Informe SOC 2 | Informe privado, periodo del informe, criterios, opinión, excepciones, carta puente si es necesaria | Compras/seguridad |
| Mapa de alcance | Perímetro del sistema del informe asignado al panel, gateway, API, medición, registros, soporte y configuración de rutas | Ingeniería de plataforma |
| Mapa de proveedores | Proveedores aprobados, orden de respaldo, tratamiento de subservicios, evidencia separada de proveedores | Seguridad/plataforma |
| Mapa de datos | Prompts, salidas, archivos, metadatos, registros de facturación, registros, tickets de soporte, copias de seguridad | Seguridad/legal |
| Matriz de retención | Retención de gateway, proveedor, aplicación, soporte y copias de seguridad por familia de endpoint | Seguridad/legal |
| Registro de CUEC | Controles del comprador y prueba de que cada uno está implementado | Plataforma/seguridad |
| Evidencia de pruebas | Una solicitud exitosa de bajo riesgo y un fallo esperado con IDs de solicitud y registros redactados | Ingeniería de plataforma |
| Memorando de aprobación | Alcance, restricciones, riesgos abiertos, nombres de revisores, disparador de renovación | Propietario del negocio/compras |
Este paquete también es el puente entre la revisión SOC 2 y las operaciones de ingeniería. Cuando se añade un nuevo proveedor, clase de modelo, modo de registro o clase de datos, el equipo debe saber qué archivos necesitan actualización.
Señales de alerta que deberían pausar la aprobación
Pausa la aprobación si cualquiera de estos puntos no está resuelto:
- El informe SOC 2 no está disponible y solo se proporciona una insignia o una consulta de certificado.
- El periodo del informe terminó y no hay carta puente ni evidencia actual disponible.
- La descripción del sistema no incluye claramente la ruta del gateway que planeas usar.
- El informe excluye organizaciones de subservicio relevantes y no se adjunta evidencia separada del proveedor.
- Las categorías de servicios de confianza seleccionadas no coinciden con el riesgo declarado por el comprador, como privacidad o confidencialidad.
- Los CUEC requieren controles del comprador que no se han implementado.
- Se supone que el registro de prompts/salidas está desactivado, pero ninguna evidencia de cuenta o de ruta lo demuestra.
- El fallback puede enviar datos a un proveedor no aprobado.
- El soporte puede inspeccionar el contenido de las solicitudes, pero no están documentados el acceso de soporte, la retención de tickets y la redacción.
- La aprobación no tiene propietario, fecha de expiración ni disparador de cambio de ruta.
Estas señales de alerta no siempre significan que el proveedor falle. Significan que la revisión del alcance del gateway de API de IA SOC 2 está incompleta.
Una declaración práctica de aprobación
Una declaración de aprobación útil es corta, específica y verificable:
| Campo | Redacción de ejemplo |
|---|---|
| Evidencia del informe | "Informe SOC 2 Tipo 2 revisado para el Proveedor X, periodo A a B, criterios de seguridad y disponibilidad, sin excepciones no aceptadas para esta ruta." |
| Alcance aprobado | "Flujo de trabajo de soporte de texto en producción a través de la URL base del gateway aprobada y el endpoint de chat." |
| Proveedores | "Proveedor A principal, Proveedor B de respaldo; sin endpoint de imagen, video, archivo, búsqueda web o lote." |
| Clase de datos | "Texto de soporte al cliente después de la redacción a nivel de aplicación; sin datos de pago, secretos, PHI ni registros regulados." |
| Registro | "Se permiten registros de metadatos del gateway; el registro bruto de prompts/salidas está desactivado o aprobado por separado; evidencia de retención del proveedor adjunta." |
| Controles del comprador | "Claves almacenadas en gestor de secretos, revisión trimestral de acceso, allowlist de rutas, revisión mensual de uso, propietario de incidentes asignado." |
| Disparador de renovación | "Actualizar antes de añadir proveedores, habilitar nuevas familias de endpoints, cambiar el registro, enrutar datos regulados o después de que expire el periodo SOC 2." |
Esto es lo que debería significar "aprobado". Los desarrolladores saben qué ruta pueden usar. Compras sabe qué evidencia se revisó. Seguridad sabe qué supervisar. Legal sabe qué supuestos aún requieren lenguaje contractual.
Conclusión
Una revisión del alcance del gateway de API de IA SOC 2 es valiosa cuando se mantiene precisa. El informe debería ayudar a probar el sistema descrito de la organización auditada, los criterios cubiertos, el funcionamiento de los controles, el periodo del informe, las excepciones, el tratamiento de subservicios y las responsabilidades del comprador. No debería ampliarse para convertirlo en prueba de cada ruta, proveedor, configuración de retención, comportamiento de fallback, término del DPA, afirmación de residencia de datos o configuración del comprador.
Para Flatkey, empieza con la evidencia pública actual y luego solicita el informe privado SOC 2 y asígnalo a la ruta que tu equipo ejecutará realmente. Si quieres una sola clave API y un solo panel para acceso multimodelo, obtén una clave, adjunta la lista de verificación de alcance del gateway de API de IA SOC 2 al paquete de compras y aprueba cada ruta de producción con evidencia explícita de proveedor, registro, retención y CUEC.
Preguntas frecuentes
¿Qué es el alcance del gateway de API de IA SOC 2?
El alcance del gateway de API de IA SOC 2 es el límite del informe SOC 2 en la medida en que se aplica a un gateway de API de IA. Incluye la entidad auditada, el sistema descrito, el periodo del informe, las categorías de servicios de confianza, los controles probados, las organizaciones de subservicio, las exclusiones y los CUEC propiedad del comprador.
¿SOC 2 demuestra que todos los proveedores de modelos de IA están cubiertos?
No. SOC 2 puede mostrar cómo el proveedor del gateway gestiona el sistema descrito y sus dependencias, pero los proveedores de modelos upstream pueden incluirse, excluirse o estar cubiertos por evidencia por separado. Los compradores deberían guardar un mapa de proveedores para cada ruta aprobada.
¿Un informe SOC 2 Type 2 demuestra que no hay retención de prompts?
No por sí solo. La retención de prompts y de resultados puede diferir entre el gateway, los proveedores upstream, el estado de la aplicación, los tickets de soporte, los registros y las copias de seguridad. El comprador debería verificar la evidencia de retención específica del endpoint, de la cuenta y de la ruta.
¿Qué debería pedir compras después de ver una insignia SOC 2?
Pida el informe privado de SOC 2, el período del informe, los criterios cubiertos, la descripción del sistema, las excepciones, el tratamiento de la organización de servicios subcontratados, los CUECs, la carta puente si es necesaria, el mapa de proveedores, la configuración de la ruta, los ajustes de registro, la matriz de retención y la evidencia firmada del contrato/DPA cuando corresponda.
¿Con qué frecuencia debe actualizarse la revisión del alcance?
Actualice la revisión del alcance del API gateway de IA SOC 2 cuando venza el período del informe, cuando el proveedor entregue un nuevo informe, antes de añadir un proveedor o una familia de endpoints, antes de enrutar una nueva clase de datos, cuando cambien el registro o la retención, y después de incidentes materiales.
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
- Búsqueda de certificado SOC 2 de CAI para USA-SOC2-220513
- Suite de servicios SOC de AICPA
- Criterios de servicios de confianza de AICPA 2017 con puntos de enfoque revisados de 2022
- Criterios de descripción SOC 2 de AICPA 2018
- Controles de datos de la API de OpenAI
- API de Anthropic y retención de datos
- Registro de Cloudflare AI Gateway
