Revisión del gateway de API de IA SOC 2 debe comenzar antes de que el comprador pida un paquete de seguridad. La pregunta de procurement no es "¿tiene una insignia?" Es si el gateway, las rutas de modelos, los registros, las claves, los registros de facturación, el proceso de soporte y los proveedores downstream pueden vincularse con evidencia que un revisor de seguridad pueda inspeccionar realmente.
Esta guía está dirigida a los equipos de procurement, seguridad, plataforma, cumplimiento y riesgo de proveedores que evalúan un gateway de API de IA antes del tráfico de producción. No es asesoramiento legal ni de auditoría. Úsela como una lista práctica de verificación de evidencia: qué solicitar, qué verificar en el informe SOC 2, qué probar en el gateway y qué conservar en su propio archivo del lado del comprador.
Flatkey es relevante porque flatkey.ai posiciona públicamente el producto como un gateway de una sola API para equipos de IA en producción, con acceso a modelos, enrutamiento, facturación, análisis de uso, controles operativos, un panel y una sola clave para múltiples proveedores. El pie de página público de Flatkey también enlaza a páginas de consulta de certificados para VOC AI Inc. que muestran una entrada SOC 2 Type II y una entrada ISO 27001:2022, y la instantánea actual de la API de precios consultada el 19 de junio de 2026 devolvió 638 filas de modelos en 23 proveedores. Trate esos datos como evidencia pública fechada, no como sustituto del informe SOC 2 privado, el acuerdo firmado, el DPA, la configuración de la cuenta o la validación de registros de producción.
Respuesta rápida: qué debe demostrar la evidencia de un gateway de API de IA SOC 2
Una revisión de gateway de API de IA SOC 2 debe demostrar tres cosas: que el informe de controles del proveedor cubre el servicio relevante, que el gateway puede generar evidencia operativa de su tráfico de IA y que su propio equipo tiene controles para las responsabilidades que el informe del proveedor deja en manos de los clientes.
| Área de revisión | Evidencia a solicitar | Qué verificar |
|---|---|---|
| Alcance del informe SOC 2 | Informe SOC 2 Type II vigente, período del informe, auditor, descripción del sistema y carta puente si el período del informe está desactualizado. | El gateway de IA, el enrutamiento de API, el registro, el soporte, la facturación y la infraestructura relevante están dentro del límite del sistema. |
| Criterios de Servicios de Confianza | Categorías cubiertas por el informe, normalmente seguridad más cualquier criterio de disponibilidad, confidencialidad, integridad del procesamiento o privacidad. | Las categorías cubiertas coinciden con el riesgo del comprador. No asuma que la privacidad o la disponibilidad están cubiertas a menos que el informe lo indique. |
| Controles complementarios del usuario | CUECs y responsabilidades del comprador enumeradas en el informe SOC 2. | Su equipo puede cumplir con la gestión de claves, la aprobación de rutas, la clasificación de datos, el acceso de usuarios, la retención y las responsabilidades de incidentes. |
| Organizaciones de subservicio | Descripción de organización de subservicio con carve-out o inclusiva, lista de proveedores y controles de monitoreo. | Los proveedores downstream de modelos, los servicios en la nube, las herramientas de soporte, la observabilidad y los proveedores de facturación se manejan de forma coherente con el modelo del informe. |
| Operaciones del gateway de IA | Muestras de registros, campos de propiedad de claves, historial de cambios de rutas, inventario de rutas de proveedores de modelos y proceso de exportación de incidentes. | El gateway puede mostrar quién envió el tráfico, qué modelo/proveedor lo recibió, qué cambió y qué evidencia se conserva. |
| Datos y privacidad | Política de privacidad, ruta del DPA, ubicaciones de procesamiento de datos, política de retención, política de registro de payload y términos de uso de datos del proveedor. | Los prompts, las salidas, los metadatos, los materiales de soporte y los registros de facturación tienen reglas claras de manejo. |
| Evidencia del lado del comprador | Su propio registro de implementación, casos de uso aprobados, taxonomía de claves, política de rutas, modo de registro y cadencia de revisión. | La evidencia del proveedor está vinculada a cómo su equipo usará realmente el gateway. |
Empiece por el alcance de SOC 2, no por la insignia
Una insignia pública puede ser útil para el filtrado inicial, pero compras aún debe solicitar el informe SOC 2 real a través del proceso de confianza del proveedor. La AICPA describe la presentación de informes SOC 2 como un examen de los controles en una organización de servicios relevantes para seguridad, disponibilidad, integridad del procesamiento, confidencialidad o privacidad. Eso significa que la pregunta útil de compras es el alcance: ¿qué sistema, servicio, rango de fechas, criterios, controles, excepciones y afirmaciones de la dirección están cubiertos?
Para una pasarela de API de IA SOC 2, la revisión del alcance debería responder:
| Campo de alcance | Pregunta del comprador | Por qué importa para el tráfico de API de IA |
|---|---|---|
| Entidad legal | ¿Qué entidad se nombra en el informe y el contrato? | La búsqueda pública de certificados de Flatkey hace referencia a VOC AI Inc.; su expediente de compras debe coincidir con la entidad contratante y el propietario del servicio. |
| Límite del sistema | ¿El informe cubre la pasarela de IA, el enrutamiento de API, el panel, las claves, la facturación, los registros de uso y el proceso de soporte? | Un informe de una plataforma más amplia de datos o analítica puede no demostrar el flujo de trabajo específico de la pasarela que planea usar. |
| Período del informe | ¿Qué rango de fechas probó el informe de Tipo II, y se necesita una carta puente? | Por lo general, compras quiere evidencia operativa actual, no solo una declaración histórica en un momento puntual. |
| Categorías de confianza | ¿Qué Criterios de Servicios de Confianza están cubiertos? | La cobertura de seguridad no significa automáticamente cobertura de disponibilidad, confidencialidad, integridad del procesamiento o privacidad. |
| Excepciones | ¿Hubo controles calificados, exceptuados o remediados? | Las excepciones pueden afectar la gestión de claves, el registro, el control de cambios, la respuesta a incidentes o la supervisión de proveedores. |
| Organizaciones de subservicio | ¿Qué servicios de nube, proveedor, soporte, observabilidad y pago están excluidos o incluidos? | El riesgo de la pasarela de IA a menudo depende de los proveedores de modelos e infraestructura posteriores. |
La regla práctica es simple: si un comprador no puede vincular el informe SOC 2 con el servicio exacto de la pasarela y la ruta del tráfico, el informe es evidencia de filtrado, no evidencia final de compra.
Mapea los criterios de SOC 2 a los controles de la pasarela de IA
Los Criterios de Servicios de Confianza de la AICPA cubren seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. Un paquete de evidencia de pasarela de API de IA SOC 2 debería traducir esas categorías amplias en comprobaciones concretas de la pasarela.
| Tema de control | Evidencia a verificar | Preocupación relacionada con SOC 2 |
|---|---|---|
| Propiedad de la clave de API | Las claves están vinculadas a propietarios, entornos, aplicaciones y flujos de trabajo; la creación y revocación de claves son auditables. | Acceso lógico, rendición de cuentas, control de cambios y contención de incidentes. |
| Aprobación de rutas y modelos | Los proveedores aprobados, las familias de endpoints, las filas de modelos, las reglas de respaldo y los registros de cambios pueden revisarse. | Gestión de cambios, supervisión de proveedores, integridad del procesamiento y confidencialidad. |
| Registros de auditoría | Los registros muestran marca de tiempo, clave o proyecto, ruta, proveedor, modelo, familia de endpoints, estado, clase de error, unidades de uso y cambios administrativos. | Monitoreo, respuesta a incidentes, revisión de accesos y evidencia operativa. |
| Gestión de cargas útiles | El modo de registro de prompts/salidas, la redacción, la restricción de acceso, el período de retención y la ruta de eliminación están documentados. | Confidencialidad, privacidad y minimización de datos. |
| Uso y facturación | Los registros de uso y los registros de facturación se separan de las cargas útiles sin procesar y se vinculan al propietario, modelo, ruta y centro de costos. | Integridad del procesamiento, rendición de cuentas y apoyo a la revisión financiera. |
| Revisión de incidentes | Los eventos de seguridad, fallos del proveedor, uso sospechoso, claves filtradas, bucles de respaldo y eventos por encima del límite tienen un manual de procedimientos y una ruta de exportación. | Monitoreo de seguridad, respuesta y remediación. |
| Cambios del proveedor y del prestador | Las altas, bajas, cambios regionales y cambios en la política de uso de datos del proveedor activan una nueva revisión. | Monitoreo de la organización subcontratada y evaluación de riesgos. |
Aquí es donde las pasarelas de IA difieren de las pasarelas de API genéricas. La ruta no es solo una decisión de host/ruta. Puede determinar qué proveedor de modelos ve los prompts, qué política de datos se aplica, qué regla de retención se aplica, qué ruta de respaldo está permitida y qué unidad de uso se factura.
Evidencia de Flatkey para verificar antes de la adquisición
Flatkey tiene evidencia pública útil para una revisión inicial de pasarela de API de IA SOC 2. El sitio público indica que Flatkey unifica el acceso a modelos, el enrutamiento, la facturación, el análisis de uso y los controles operativos para equipos que lanzan productos de IA. El pie de página enlaza a una búsqueda de Cert Assure SOC 2 Type II para VOC AI Inc., certificado `USA-SOC2-220513`, con un período indicado del 15 de julio de 2025 al 14 de julio de 2026 y un estado activo en el momento de la consulta. El mismo pie de página enlaza a una búsqueda ISO 27001:2022 para VOC AI Inc., certificado `USA-I-270513`, con un período indicado del 1 de mayo de 2024 al 30 de abril de 2027 y un estado activo en el momento de la consulta.
Use esas páginas públicas como punto de partida del expediente y luego verifique estos detalles directamente con Flatkey antes de la adquisición:
| Comprobación de Flatkey | Qué capturar | Salvaguarda |
|---|---|---|
| Solicitud de informe SOC 2 | Informe actual, auditor, período, alcance, criterios cubiertos, excepciones, organizaciones subcontratadas y carta puente si es necesaria. | No dependa únicamente de la insignia pública o de la consulta del certificado. |
| Verificación cruzada ISO 27001:2022 | Entidad del certificado, alcance de actividad, fechas y cualquier declaración de aplicabilidad o resumen de seguridad disponible bajo revisión de confianza. | La certificación ISO respalda una revisión del SGSI, pero no sustituye el informe SOC 2 ni la validación de la ruta de IA. |
| Catálogo y compatibilidad de endpoints | Fila de modelo actual, proveedor, familia de endpoint, estado de disponibilidad y unidad de precio de precios de Flatkey. | Los conteos de modelos, los conteos de proveedores y la disponibilidad pueden cambiar; verifique el mismo día en que apruebe la ruta. |
| Evidencia del panel | Propietario principal, ruta, modelo, proveedor, estado, unidad de uso, registro de facturación y cualquier ruta de exportación en el actual panel de Flatkey. | No asuma etiquetas exactas del panel a partir del texto de marketing público. |
| Registros y retención | Campos de metadatos, comportamiento de registro de cargas útiles, período de retención, permisos de visualización, manejo de datos de soporte y proceso de eliminación/exportación. | La política de privacidad pública de Flatkey menciona metadatos de solicitud, registros de errores, registros de uso, registros necesarios y materiales de soporte, pero un comprador necesita términos específicos de la cuenta. |
| Política de ruta del proveedor | Proveedores aprobados, restricciones de respaldo, términos de uso de datos del proveedor y quién puede cambiar las rutas. | El respaldo de fiabilidad puede convertirse en un cambio de riesgo de proveedor si cambia el proveedor downstream. |
Cómo probar la puerta de enlace antes de la aprobación de seguridad
No espere a que el tráfico real de clientes descubra si su evidencia de puerta de enlace API de IA SOC 2 está completa. Ejecute una prueba de humo controlada por ruta y guarde el paquete de revisión.
- Cree identificadores de ruta no secretos: use claves o proyectos separados para entorno de pruebas, producción, lotes, tráfico orientado al cliente y evaluación.
- Elija una ruta de modelo de bajo riesgo: registre proveedor, fila del modelo, familia de endpoint, unidad de precio y clase de datos esperada.
- Envíe una solicitud de prueba inocua: evite datos reales de clientes, datos personales, secretos o contenido regulado.
- Revise el registro: confirme la marca de tiempo, la clave/proyecto, el propietario, la ruta, el proveedor, el modelo, el estado, las unidades de uso, la clase de error y la visibilidad del coste.
- Revise la evidencia administrativa: confirme quién creó la clave, quién aprobó la ruta, quién puede cambiar la alternativa de reserva y dónde se registran los cambios.
- Pruebe una ruta de denegación: intente un modelo no permitido, una clase de datos bloqueada, una clave caducada o un límite de cuota y guarde el resultado.
- Documente la retención: identifique dónde se conservan los metadatos, las cargas útiles si las hay, los tickets de soporte, los registros de facturación y los registros de seguridad.
- Adjunte documentos de adquisición: informe SOC 2, carta puente, evidencia ISO, política de privacidad, términos, ruta DPA, revisión del proveedor y su nota de implementación.
- Repita ante cambios: vuelva a ejecutar el paquete cuando cambien el proveedor, el modelo, la familia de endpoint, la alternativa de reserva, la clase de datos, el modo de registro o los términos contractuales.
- Separe la evidencia pública y privada: las páginas públicas ayudan al cribado; el informe privado y la validación específica de la cuenta cierran la adquisición.
SOC 2 es solo una capa de la revisión de la puerta de enlace de IA
Una revisión de puerta de enlace de API de IA SOC 2 debe situarse junto con las comprobaciones de ISO 27001, GDPR, seguridad de aplicaciones y riesgo de proveedores. Estos marcos están relacionados, pero responden a preguntas diferentes.
| Marco O Fuente | Qué Ayuda A Verificar | Qué No Demuestra Por Sí Solo |
|---|---|---|
| SOC 2 | Examen independiente de los controles para el sistema descrito y los Criterios de Servicios de Confianza cubiertos durante el período del informe. | No demuestra que cada función de Flatkey, configuración de cuenta del cliente, ruta de modelo aguas abajo o flujo de trabajo del comprador esté cubierto. |
| ISO/IEC 27001:2022 | Alcance del sistema de gestión de seguridad de la información, gestión de riesgos y estado de certificación. | No sustituye un informe SOC 2 ni demuestra un esquema específico de registro de solicitudes de IA. |
| GDPR | Revisión del encargado del tratamiento, seguridad del tratamiento, minimización de datos, retención, salvaguardas de transferencia y asignación de roles para datos personales. | No queda satisfecho solo porque una puerta de enlace haya sido revisada bajo SOC 2. |
| Orientación de registro de OWASP | Diseño práctico de registros, atributos de eventos, datos que excluir, protección de registros y preocupaciones de monitoreo. | No define la política de retención de su proveedor ni demuestra que el manejo de sus prompts/resultados sea aceptable. |
| Controles del comprador | Su taxonomía de claves, acceso de usuarios, aprobación de rutas, clasificación de datos, fallback del modelo, retención y revisión de incidentes. | No sustituyen los controles del proveedor; hacen que la evidencia del proveedor sea utilizable en su entorno. |
Use la lista de verificación de puerta de enlace de API de IA empresarial adyacente de Flatkey para la pila de compras más amplia y registros de auditoría para el uso de la API de IA para los campos de evidencia que los equipos de seguridad suelen solicitar.
Plantilla de paquete de evidencia de compras
El resultado más útil de una revisión de pasarela de API de IA SOC 2 es un paquete compacto que los equipos de ingeniería de ventas, seguridad, legal y plataforma puedan leer.
| Sección del paquete | Campos a incluir | Responsable |
|---|---|---|
| Identidad del proveedor | Entidad legal, entidad contratante, contacto de soporte, ruta del portal de confianza, enlaces de búsqueda de certificados y estado actual. | Compras |
| Archivo SOC 2 | Tipo de informe, período, auditor, límite del sistema, Criterios de Servicios de Confianza, excepciones, organizaciones de subservicio, CUECs y carta puente. | Seguridad |
| Archivo de rutas de la pasarela | Proveedores aprobados, modelos, familias de endpoints, reglas de respaldo, clases de datos, responsable de la ruta y aprobador del cambio. | Ingeniería de plataforma |
| Archivo de registros y evidencias | Campos de metadatos de solicitud, registros administrativos, política de carga útil, clase de retención, método de exportación y lista de acceso de visualizadores. | Operaciones de seguridad |
| Archivo de protección de datos | Ruta del DPA, política de privacidad, términos, revisión del uso de datos por parte del proveedor, ubicaciones de procesamiento, lista de subencargados y notas de rol del RGPD. | Legal y privacidad |
| Controles del lado del comprador | Taxonomía de claves, cadencia de revisión de acceso, proceso de cambio de ruta, política de cuota, manual de respuesta a incidentes y desencadenantes de nueva revisión. | Plataforma y gobernanza |
| Aprobación de lanzamiento | Aprobador final, casos de uso aprobados, clases de datos bloqueadas, fecha de lanzamiento, fecha de revisión y riesgos residuales. | Seguridad y producto |
Banderas rojas durante la revisión
Pausa la adquisición si la evidencia de la pasarela API de IA SOC 2 deja sin resolver estas brechas:
- Respuesta solo con insignia: el proveedor señala una insignia, pero no puede proporcionar el informe SOC 2 actual bajo NDA o acceso de confianza.
- Desajuste de alcance: el informe cubre un producto, entidad, perímetro de infraestructura o período de tiempo diferente al de la pasarela que se está adquiriendo.
- Sin plan de CUEC: el informe enumera responsabilidades del cliente, pero el comprador no les ha asignado responsables internamente.
- Organizaciones de subservicio opacas: los proveedores de modelos posteriores, herramientas de soporte, herramientas de registro o proveedores de nube no se gestionan con claridad.
- Sin evidencia de cambio de ruta: el equipo no puede demostrar quién agregó un proveedor, cambió un modelo o habilitó el fallback.
- Ambigüedad en el registro de cargas: los prompts y las salidas pueden almacenarse, pero la retención, el acceso y la eliminación no están claros.
- Prueba solo en el panel: existen capturas de pantalla, pero no hay un archivo de evidencia exportable o revisable para la revisión de seguridad.
- Sin desencadenante de nueva revisión: los nuevos modelos, regiones, familias de endpoints y cambios en la política del proveedor pueden ocurrir sin revisión de compras/seguridad.
Preguntas frecuentes
¿Qué es la evidencia de un gateway de API de IA SOC 2?
La evidencia de un gateway de API de IA SOC 2 es el conjunto de documentos, registros, registros de rutas, mapeos de controles y notas del lado del comprador que muestran cómo los controles de un gateway de IA respaldan la revisión de compras. Incluye el informe SOC 2 del proveedor, la revisión del alcance, el manejo de organizaciones subproveedoras, registros de auditoría, propiedad de claves, aprobaciones de rutas, política de retención y responsabilidades del cliente.
¿Es suficiente una insignia SOC 2 para aprobar un gateway de API de IA?
No. Una insignia puede ayudar con el filtrado inicial, pero compras debe verificar el informe SOC 2 actual, el sistema cubierto, el período del informe, los criterios, las excepciones, las organizaciones subproveedoras y los controles complementarios de la entidad usuaria. El informe privado y la prueba de ruta del comprador importan más que la insignia por sí sola.
¿SOC 2 debe cubrir a todos los proveedores de modelos detrás de un gateway?
No necesariamente. Los informes SOC 2 describen el sistema de la organización de servicios y cómo se manejan las organizaciones subproveedoras, a menudo mediante métodos de carve-out o inclusivos. Los compradores deben verificar cómo se representan los proveedores de modelos, los servicios en la nube, las herramientas de soporte y los servicios de observabilidad, y luego revisar los datos y términos de seguridad propios de cada proveedor.
¿Cómo se conectan SOC 2 y GDPR para un gateway de API de IA?
SOC 2 puede respaldar la evidencia de controles de seguridad, mientras que la revisión de GDPR se centra en los roles de tratamiento, la base jurídica, la minimización de datos, los términos del encargado, las transferencias, la retención y los derechos de los interesados. Un gateway de API de IA SOC 2 puede centralizar evidencia útil, pero no resuelve automáticamente las obligaciones de GDPR.
¿Qué debo verificar en Flatkey antes de comprar?
Verifique el informe SOC 2 actual de Flatkey, los detalles del certificado ISO 27001, la entidad legal, los términos firmados, la ruta del DPA, la ruta del modelo/proveedor, la familia de endpoints, los campos de evidencia del panel, la retención de registros, el manejo de payloads, el manejo de datos de soporte y el comportamiento de fallback. También confirme la fila del modelo actual y la unidad de precio el día en que apruebe el uso en producción.
Último paso de adquisición
Antes de aprobar una pasarela API de IA con SOC 2, prepare el paquete de evidencias de la misma forma en que lo revisará un auditor o un comprador empresarial: entidad, alcance del informe, criterios, período, excepciones, organizaciones de subservicio, registros, controles de acceso, cambios de ruta, manejo de datos y responsabilidades del cliente. Flatkey puede centralizar el acceso al modelo, el enrutamiento, la visibilidad del uso y los controles operativos, pero su expediente de compras aún debe verificar el informe vigente y la ruta exacta que ejecutará.
Obtenga una clave cuando esté listo para centralizar el acceso al modelo, el enrutamiento, la visibilidad del uso y las pruebas para revisión del comprador detrás de una sola pasarela API de IA.
