La evaluación del riesgo de proveedores de API de IA se complica cuando el proveedor es una pasarela multimodelo en lugar de un proveedor de modelo único. El comprador no solo está aprobando un endpoint de API. El comprador está aprobando una ruta de solicitud que puede incluir una cuenta de pasarela, claves de API, rutas de modelos, comportamiento de conmutación por error, registros de uso, registros de facturación, flujos de trabajo de soporte y proveedores de modelos descendentes.
Esta guía está dirigida a los equipos de compras, seguridad, plataforma, cumplimiento y riesgo de proveedores que revisan una pasarela de API de IA antes del tráfico de producción. No constituye asesoramiento legal, de auditoría ni de cumplimiento. Úsela como un banco práctico de preguntas: qué preguntar, qué evidencia solicitar, qué probar en staging y qué conservar en el expediente de compras.
Flatkey es relevante porque flatkey.ai actualmente posiciona el producto como una pasarela de API para equipos de IA en producción, con una sola clave, acceso a modelos, enrutamiento, facturación, análisis de uso, controles operativos y una consola. Una instantánea de la API de precios tomada el 19 de junio de 2026 devolvió 638 filas de modelos, 23 proveedores listados y familias de endpoints que incluyen OpenAI-compatible, Anthropic, Gemini, generación de imágenes, Responses y video. El pie de página público de Flatkey también enlaza a páginas de consulta de certificados SOC 2 Type II e ISO 27001:2022 de VOC AI Inc. Trátelos como evidencia pública de evaluación preliminar con fecha, no como sustituto del informe privado, el acuerdo firmado, el DPA, la configuración de la cuenta, la prueba de rutas o la confirmación de soporte.
Respuesta rápida: Lo que debe demostrar una evaluación de riesgos de proveedores de API de IA
Una evaluación de riesgos de proveedores de API de IA debe demostrar cuatro cosas: por dónde fluyen los datos, quién puede cambiar ese flujo, qué evidencia existe cuando el flujo cambia y qué responsabilidades siguen recayendo en el comprador. Un cuestionario genérico para proveedores rara vez profundiza lo suficiente para una puerta de enlace que puede enrutar a través de múltiples proveedores.
| Área de riesgo | Pregunta que hacer | Evidencia que solicitar | Condición de detención |
|---|---|---|---|
| Exposición a proveedores | ¿Qué proveedores de modelos downstream, familias de endpoints, regiones y cuentas pueden recibir cada flujo de trabajo aprobado? | Inventario de rutas, catálogo de modelos, política del proveedor, registro de cambios de ruta y estado actual de disponibilidad. | El proveedor no puede mostrar qué proveedor puede procesar prompts y salidas. |
| Flujo de datos | ¿Qué datos de prompt, salida, metadatos, errores, soporte y facturación se procesan o retienen? | Política de privacidad, ruta del DPA, política de retención, modo de registro de cargas útiles, proceso de eliminación/exportación y términos del proveedor. | El manejo o la retención de cargas útiles no está claro para la clase de datos que se está enrutando. |
| Controles de seguridad | ¿La evidencia de controles cubre el servicio de puerta de enlace que va a utilizar? | Informe SOC 2 Type II, alcance de ISO 27001, bridge letter si es necesaria, excepciones, CUECs y tratamiento de subservicios. | El alcance del informe no puede vincularse con la puerta de enlace real, las claves, los registros, el soporte o el flujo de trabajo de enrutamiento. |
| Auditabilidad | ¿Puede el comprador reconstruir quién envió tráfico, qué ruta lo gestionó, cuánto costó y qué cambió? | Exportación de registros de muestra, rastro de eventos administrativos, campos del propietario de la clave, campos de intento de ruta, unidades de uso y registros de facturación. | Los registros solo muestran éxito/fracaso sin contexto de propietario, ruta, modelo, proveedor o costo. |
| Continuidad | ¿Qué sucede cuando falla un proveedor, modelo, cuenta, región o ruta? | Política de respaldo, política de reintentos, metadatos de intento de proveedor, runbook de incidentes, ruta de reversión y proceso de notificación al cliente. | El respaldo puede mover silenciosamente el tráfico a un proveedor o límite de datos no aprobado. |
| Controles de facturación | ¿Puede atribuirse el uso al equipo, la clave, el flujo de trabajo, el modelo y el responsable de costos correctos? | Panel de uso, exportación de facturación, controles de cuota/presupuesto, registros de recargos, unidad de precio y proceso de revisión de anomalías. | Compras no puede conectar una decisión de ruta con la evidencia de gasto. |
Empiece con un mapa de rutas de solicitudes
El primer error en la evaluación de riesgos de proveedores de API de IA es tratar la pasarela como un sustituto de caja negra de la incorporación directa del proveedor. Una pasarela reduce la dispersión operativa solo si el comprador puede describir la nueva ruta de la solicitud con suficiente precisión para la revisión de seguridad y de compras.
Para cada flujo de trabajo de producción, trace estos campos antes de calificar al proveedor:
| Campo | Qué capturar | Por qué importa |
|---|---|---|
| Aplicación y entorno | Nombre de la aplicación, propietario, límite entre staging/producción, clase de datos y caso de uso empresarial. | La misma pasarela puede ser de bajo riesgo para la generación de contenido público y de alto riesgo para soporte al cliente o datos regulados. |
| Límite de credenciales | Propietario de la clave, proceso de rotación, ruta de revocación, cuenta de servicio y quién puede crear o ver claves. | Una clave compartida puede ocultar la responsabilidad; las claves separadas facilitan la auditoría y la contención de incidentes. |
| Ruta de la pasarela | Familia de endpoints, fila del modelo, proveedor, grupo/nivel, regla de respaldo y propietario de la ruta. | La selección de la ruta determina quién puede ver la solicitud y qué costo, disponibilidad y condiciones del proveedor se aplican. |
| Proveedor aguas abajo | Nombre del proveedor, modelo de cuenta del proveedor, región o ubicación de procesamiento si está disponible y condiciones de uso de datos. | La aprobación de la pasarela no aprueba automáticamente a todos los proveedores aguas abajo. |
| Superficie de evidencia | Registros, metadatos, eventos administrativos, registros de facturación, tickets de soporte y rutas de exportación. | La aprobación de compras debe depender de la evidencia que el comprador pueda inspeccionar más adelante. |
El Marco de Gestión de Riesgos de IA de NIST ofrece un lenguaje útil para este tipo de revisión porque separa gobernanza, mapeo, medición y gestión. En una revisión de pasarela, esas ideas se vuelven concretas: quién es responsable de la ruta, qué contexto está mapeado, cómo se miden los riesgos y cómo se gestionan los cambios después de la aprobación.
Haga preguntas sobre la exposición de proveedores antes que preguntas sobre los datos
Una puerta de enlace multimodelo puede simplificar las operaciones de las API de IA, pero también cambia la conversación sobre el riesgo de proveedores. El comprador debe saber si la puerta de enlace simplemente está pasando tráfico a un único proveedor aprobado, eligiendo entre varios proveedores o aplicando un comportamiento de conmutación por error/balanceo de carga que puede cambiar el destinatario aguas abajo.
Use estas preguntas de evaluación de riesgo de proveedores de API de IA para la exposición de proveedores:
| Pregunta | Evidencia | Nota del revisor |
|---|---|---|
| ¿Qué proveedores pueden recibir este flujo de trabajo hoy? | Fila actual del catálogo, familia de endpoints, proveedor, estado de disponibilidad y configuración de ruta. | No apruebe una categoría como "todos los modelos GPT" sin filas nombradas y responsables. |
| ¿Quién puede agregar, eliminar o reordenar proveedores? | Permisos de administrador, registro de auditoría de cambios de ruta, flujo de aprobación y configuración de notificaciones. | Un cambio de proveedor es un cambio de riesgo, no solo una optimización de ingeniería. |
| ¿Puede la puerta de enlace conmutar automáticamente a un proveedor diferente en caso de fallo? | Política de respaldo, metadatos del intento, condiciones de detención y proceso de reversión. | La conmutación por error debe estar preaprobada para cada flujo de trabajo y clase de datos. |
| ¿Son diferentes los términos específicos del proveedor entre las rutas de respaldo? | Términos de uso de datos del proveedor, declaraciones de retención, términos de entrenamiento, términos de procesamiento regional y vía de soporte. | Una ruta de respaldo puede cruzar un límite de uso o de retención de datos. |
| ¿Cómo se representan los modelos no compatibles, no disponibles o con fallos? | Estado de disponibilidad, mensaje de incidente, prueba de ruta actual y comportamiento esperado de cara al cliente. | Una entrada del catálogo no es lo mismo que una ruta lista para producción. |
La guía de OWASP sobre riesgo de la cadena de suministro de GenAI es útil aquí porque un flujo de trabajo de modelos a menudo depende de componentes y servicios fuera de la base de código directa del comprador. Para una puerta de enlace, el archivo práctico de la cadena de suministro debe incluir al proveedor de la puerta de enlace, los sistemas en la nube y de soporte, los proveedores de modelos aguas abajo, los sistemas de registro y análisis, los procesadores de facturación y cualquier servicio que pueda afectar el prompt, la salida, los metadatos o el manejo de claves.
Convierta el flujo de datos en una lista de verificación
Una sólida evaluación de riesgos del proveedor de API de IA no plantea una sola pregunta amplia como \"¿están seguros nuestros datos?\". Divide el flujo de datos en registros separados porque cada registro puede tener un perfil de riesgo y retención diferente.
| Tipo de datos | Preguntas para el proveedor de gateway | Evidencia del comprador para guardar |
|---|---|---|
| Prompts y entradas | ¿Se almacenan, inspeccionan, redactan, cifran o transmiten los prompts a proveedores posteriores? ¿Se puede desactivar el registro de cargas útiles? | Configuración de registro, política de privacidad, DPA o términos de procesamiento de datos, y confirmación específica de la cuenta. |
| Salidas | ¿Se almacenan las salidas junto con los prompts? ¿Se usan las salidas para depuración, soporte, revisión de calidad, revisión de abuso o mejora del proveedor? | Política de retención, política de datos de soporte y registro de prueba que muestre si se guardan las cargas útiles de salida. |
| Metadatos de solicitudes | ¿Qué campos de metadatos se conservan, como clave, proyecto, modelo, proveedor, estado, recuento de tokens, costo, clase de error y duración? | Exportación de muestra de registro solo de metadatos y diccionario de campos. |
| Eventos administrativos | ¿Son auditables la creación de claves, la revocación, los cambios de ruta, los cambios de permisos y los cambios de facturación? | Muestra de evento administrativo, matriz de roles y proceso de revisión de acceso. |
| Materiales de soporte | ¿Puede el personal de soporte acceder a registros de solicitudes, trazas de errores, prompts, salidas, capturas de pantalla o configuración de la cuenta? | Política de acceso de soporte, ruta de escalamiento y regla de minimización de datos. |
| Registros de facturación | ¿Qué campos de uso se almacenan para facturación, reembolso, disputa, impuestos, contabilidad o revisión de fraude? | Exportación de facturación, factura o registro de recargo y declaración de retención. |
La página pública de privacidad de Flatkey dice que las entradas y salidas pueden pasar por los sistemas de Flatkey y los servicios técnicos o de modelos pertinentes, y que el procesamiento puede estar sujeto a diferentes reglas de proveedor. También hace referencia a metadatos de solicitudes, registros de errores, registros de uso, registros necesarios, materiales de soporte y registros conservados para necesidades fiscales, contables, de seguridad, control de riesgos, pago, disputa, auditoría, cumplimiento o legales. Esas declaraciones públicas son evidencia inicial útil. Aun así, deben vincularse con la cuenta del comprador, la clase de datos, el contrato, la vía del DPA y la configuración del panel.
Revise SOC 2, ISO, GDPR y los controles del comprador en conjunto
Las certificaciones de seguridad ayudan a la clasificación inicial de compras, pero no cierran por sí solas una evaluación de riesgo de proveedor de API de IA. Una insignia pública responde a una pregunta de filtrado. El comprador aún necesita el alcance, el período, los criterios, las excepciones, los controles complementarios de la entidad usuaria, el tratamiento de las organizaciones de subservicio y la configuración específica de la cuenta.
| Evidencia | Qué puede ayudar a demostrar | Qué no demuestra por sí sola |
|---|---|---|
| Informe SOC 2 Tipo II | Controles sobre el sistema descrito para los Criterios de Servicios de Confianza cubiertos durante el período del informe. | No demuestra que cada ruta de modelo, proveedor, campo de registro, clase de datos o configuración del cliente esté aprobada. |
| Certificado ISO 27001:2022 | Alcance del sistema de gestión de seguridad de la información y estado de la certificación. | No sustituye un informe SOC 2, un DPA, una prueba de ruta ni la revisión de controles del comprador. |
| Documentos de GDPR | Asignación de roles, revisión del procesador, minimización de datos, seguridad del tratamiento, salvaguardas de transferencia y flujos de trabajo de derechos cuando intervienen datos personales. | No se considera satisfecho solo porque un proveedor tenga una insignia de seguridad. |
| Registros del gateway y eventos de administración | Evidencia operativa de quién usó la ruta, qué modelo/proveedor la gestionó, cuánto costó y qué cambió. | No demuestran términos contractuales, límites de retención ni reglas de uso de datos del proveedor a menos que estén vinculados a una política. |
| Controles del comprador | Casos de uso aprobados, clasificación de datos, taxonomía de claves, aprobaciones de rutas, límites de presupuesto y cadencia de revisión. | No sustituyen los controles del proveedor; hacen que la evidencia del proveedor sea utilizable en el entorno del comprador. |
En el caso de Flatkey, las páginas públicas de consulta de certificados revisadas el 19 de junio de 2026 mostraban a VOC AI Inc. con una entrada SOC 2 Tipo II, certificado USA-SOC2-220513, período indicado del 15 de julio de 2025 al 14 de julio de 2026 y estado activo; la página de ISO mostraba el certificado USA-I-270513, ISO 27001:2022, período indicado del 1 de mayo de 2024 al 30 de abril de 2027 y estado activo. Use esas páginas para iniciar el expediente de confianza y, después, solicite el informe privado y los detalles del alcance directamente a Flatkey antes de la aprobación.
Para una revisión más profunda específica de GDPR, combine este artículo con la lista de verificación de gateway de API de IA para GDPR. Para profundizar en la evidencia SOC 2, use la lista de verificación de evidencia SOC 2 para gateway de API de IA.
Exija registros que reconstruyan la decisión
Los registros más útiles para la evaluación del riesgo de proveedores de API de IA no son solo registros de depuración. Son evidencia de compras. Deben permitir que un revisor reconstruya el propietario de la solicitud, la ruta, el proveedor, el modelo, el estado, el uso, el costo y los cambios administrativos sin exponer más datos del prompt o de la salida de lo necesario.
La documentación pública de gateways muestra la forma de una evidencia útil. La documentación de registros de AI Gateway de Cloudflare describe registros con campos como proveedor, marca de tiempo, estado de la solicitud, uso de tokens, costo, duración y campos DLP opcionales, con un control de registro de payload que puede conservar metadatos mientras omite los cuerpos sin procesar de la solicitud y la respuesta. La documentación de metadatos personalizados de Cloudflare muestra etiquetas de solicitud como identificadores de usuario o equipo para filtrado y análisis. Úselas como evidencia pública de patrón, no como una afirmación sobre el comportamiento de Flatkey.
| Campo del registro | Por qué le importa a Compras | Medida de protección de privacidad |
|---|---|---|
| Marca de tiempo e ID de solicitud | Respalda la revisión de incidentes, la revisión de disputas de facturación y la reconstrucción de interrupciones del proveedor. | Evite incluir datos personales en los ID de solicitud. |
| Clave, proyecto, aplicación o propietario | Conecta el uso con un equipo y entorno responsables. | Use identificadores no sensibles en lugar de nombres de usuario cuando sea posible. |
| Modelo, proveedor y familia de endpoint | Muestra qué ruta descendente procesó la solicitud. | No suponga que el nombre visible del modelo refleja todos los detalles del proveedor o de la cuenta. |
| Estado, clase de error e intento de fallback | Explica si el gateway reintentó, falló o pasó a una ruta de respaldo. | Haga que los metadatos del intento de fallback estén disponibles sin exponer el contenido sin procesar del payload. |
| Unidades de uso de entrada/salida y costo | Respalda la revisión de cuotas, presupuesto, imputación de costos y anomalías. | Los metadatos de uso a menudo pueden conservarse por separado de los payloads de prompt/salida. |
| Cambios administrativos | Muestra quién creó claves, cambió permisos, cambió rutas o modificó los controles de facturación. | Restrinja el acceso al registro administrativo y consérvelo de acuerdo con la política de seguridad. |
Los usuarios de Flatkey deben verificar cuáles de estos campos son visibles en la cuenta actual y en la ruta de exportación. El texto publicitario público y las páginas de políticas no son suficientes. Guarde un registro de prueba de staging, un registro de denegación, un registro de cambio de ruta y un registro de facturación en el paquete de compras.
Separe la fiabilidad del fallback aprobado
Las afirmaciones de fiabilidad pueden crear un riesgo oculto del proveedor si una ruta de fallback no está aprobada. La documentación pública de fallback de AI Gateway de Vercel describe un patrón en el que los modelos de respaldo pueden probarse en orden cuando el modelo principal falla y los metadatos del proveedor pueden mostrar los intentos de modelo. Eso es evidencia útil de un patrón sobre lo que un gateway puede exponer. No prueba cómo se comporta Flatkey para una cuenta específica.
Para una evaluación de riesgo de proveedor de API de IA, haga estas preguntas sobre fallback antes de producción:
- ¿Qué fallos activan el fallback? El tiempo de espera agotado del proveedor, el límite de tasa, el modelo no disponible, los errores 5xx y los errores de red son diferentes de las solicitudes malformadas, los bloqueos de políticas, los fallos de autenticación o el agotamiento del presupuesto.
- ¿Qué rutas de respaldo están preaprobadas? Cada respaldo debe tener proveedor, modelo, familia de endpoint, clase de datos, costo y revisión de cumplimiento.
- ¿Qué metadatos muestran la cadena de intentos? Una respuesta final exitosa no debería ocultar los intentos fallidos del proveedor.
- ¿Puede deshabilitarse el fallback por flujo de trabajo? Algunos flujos regulados o de cara al cliente deberían fallar de forma cerrada en lugar de pasar a un proveedor diferente.
- ¿Quién recibe la notificación? Compras, seguridad, plataforma y finanzas pueden necesitar un registro del cambio de ruta o del incidente de fallback.
- ¿Cómo se gestiona la reversión? El equipo necesita un responsable, un runbook y una condición de detención clara.
Use el flujo de trabajo de rotación de claves de API de IA y la lista de verificación de logs de auditoría de API de IA como comprobaciones de evidencia adyacentes cuando las revisiones de fiabilidad y seguridad se solapan.
Realice la revisión de facturación y cuotas con anticipación
El costo forma parte de la evaluación de riesgos del proveedor de API de IA porque los cambios de ruta también pueden cambiar el gasto. Una pasarela puede simplificar la facturación, pero compras aún debe preguntar cómo se mide, atribuye, limita, disputa, reembolsa y conserva el uso.
| Pregunta de facturación | Evidencia a solicitar | Riesgo si falta |
|---|---|---|
| ¿Cuál es la unidad de precio para cada ruta aprobada? | Fila del catálogo, unidad de precio, proporción del modelo, proporción de finalización, proporción de caché o unidad por segundo/por imagen cuando corresponda. | Los equipos pueden aprobar un modelo sin entender cómo el uso se convierte en costo. |
| ¿Se puede atribuir el gasto por clave, proyecto, equipo, flujo de trabajo o entorno? | Panel de uso, campos de exportación, etiquetas de metadatos y muestra de informe de facturación. | El uso compartido se convierte en un problema de finanzas y responsabilidad. |
| ¿Pueden los presupuestos o límites de cuota detener el uso descontrolado? | Configuración de presupuesto, configuración de cuota, ajustes de alertas y comportamiento al superar el límite. | Un bucle de prompts, un bucle de respaldo o un error de integración pueden convertirse en un incidente de costos. |
| ¿Cómo se conservan los registros de recarga, reembolso, disputa e impuestos? | Términos, exportación de facturación, página de factura o recarga y declaración de retención. | Compras no puede conciliar el uso con el pago ni con la evidencia de una disputa. |
Los términos públicos y la página de inicio de Flatkey describen saldo prepago, acceso a modelos, uso, facturación, claves, configuración de equipos, permisos, presupuestos, modelos, registros y configuraciones de seguridad. Verifique las etiquetas exactas y los controles disponibles en la consola actual antes de confiar en ellos para la aprobación del comprador.
Preguntas de adquisición de Flatkey que hacer antes de la aprobación
Utiliza esta lista de verificación de evaluación de riesgo de proveedores de API de IA específica de Flatkey después de que se respondan las preguntas generales sobre la puerta de enlace. El objetivo es separar la evidencia pública de la evidencia específica de la cuenta.
| Elemento de revisión de Flatkey | Qué muestra la evidencia pública | Qué verificar directamente |
|---|---|---|
| Posicionamiento de la puerta de enlace | El texto público de Flatkey indica una sola clave, acceso a modelos, enrutamiento, facturación, analítica de uso, controles operativos y contexto de consola. | Qué cuenta, ruta, familia de endpoints y filas de modelos están habilitadas para tu flujo de trabajo de producción. |
| Alcance del catálogo | La instantánea de la API de precios del 19 de junio de 2026 devolvió 638 filas de modelos y 23 proveedores listados. | Fila actual, proveedor, unidad de precio, estado de la ruta y disponibilidad en el día de la aprobación. |
| Evidencia de SOC 2 e ISO | El pie de página público enlaza a páginas de consulta del certificado SOC 2 Type II e ISO 27001:2022 para VOC AI Inc. | Informe SOC 2 privado, alcance de ISO, período del informe, excepciones, CUECs, organizaciones de subservicios y carta puente si es necesaria. |
| Gestión de datos | La página de privacidad de Flatkey describe entradas, salidas, metadatos de solicitudes, registros de uso, logs, materiales de soporte, retención y procesamiento por parte de proveedores a nivel de política pública. | Ruta del DPA, configuración de registro de payloads, períodos de retención, acceso de soporte, términos de uso de datos del proveedor y proceso de eliminación/exportación para tu cuenta. |
| Administración | Los términos mencionan el control del administrador de la organización sobre permisos, presupuestos, modelos, logs, claves y configuraciones de seguridad. | Matriz exacta de roles, logs de eventos de administrador, aprobación de cambios de ruta y quién puede modificar el acceso de respaldo o a modelos. |
| Operaciones | El texto público describe conmutación automática y balanceo de carga. | Disparadores de fallo, condiciones de detención del respaldo, metadatos de intentos del proveedor, proceso de incidentes y notificación al comprador. |
Después de esas comprobaciones, envía al comprador a la lista de verificación de puerta de enlace de API de IA empresarial para la revisión más amplia de la arquitectura y a precios de Flatkey para la inspección del catálogo actual. Cuando la ruta sea aceptable, el proceso de conversión es simple: obtén una clave, ejecuta una prueba de staging de bajo riesgo, guarda la evidencia y solo entonces mueve el tráfico aprobado.
Plantilla de paquete de evidencias de compras
El resultado final de una evaluación de riesgo de proveedores de API de IA debe ser un paquete que otro revisor pueda volver a abrir más adelante. Manténgalo lo bastante breve para poder mantenerlo, pero lo bastante específico para resistir una revisión de incidentes.
| Sección del paquete | Contenido requerido | Responsable |
|---|---|---|
| Resumen del caso de uso | Flujo de trabajo, entorno, clase de datos, responsable del negocio, responsable técnico y fecha de aprobación. | Responsable del producto o de la plataforma |
| Inventario de rutas | Cuenta del gateway, clave/proyecto, fila del modelo, proveedor, familia de endpoints, rutas de respaldo y unidad de precio. | Ingeniería de plataforma |
| Archivo de seguridad | Informe SOC 2, evidencia ISO, excepciones, carta puente, CUEC, organizaciones de subservicios y notas de penetración/seguridad si se suministran. | Seguridad o GRC |
| Archivo de privacidad | Ruta del DPA, mapa de roles, categorías de datos, retención, registro de payloads, eliminación/exportación, acceso de soporte y términos del proveedor. | Privacidad o legal |
| Archivo de operaciones | Prueba de humo, prueba de denegación, prueba de respaldo si está habilitada, prueba de cambio de ruta, runbook de incidentes y responsable de la reversión. | Ingeniería de plataforma |
| Archivo de auditoría | Ejemplo de campo de registro, ejemplo de evento administrativo, ejemplo de facturación, captura de pantalla o exportación de cuota/presupuesto y proceso de revisión de acceso. | Seguridad y finanzas |
| Registro de decisiones | Rutas aprobadas, rutas no permitidas, riesgos no resueltos, fecha de renovación, desencadenantes de revisión y responsables de la aprobación final. | Compras o responsable de riesgos |
Flujo de trabajo paso a paso
- Clasifique el flujo de trabajo: nombre la aplicación, el propietario, el entorno, la clase de datos, la población de usuarios y el volumen esperado de solicitudes.
- Enumere las rutas aprobadas: registre la cuenta de gateway, la familia de endpoints, la fila del modelo, el proveedor, la ruta de respaldo, la unidad de precios y el propietario de la ruta.
- Solicite evidencia de confianza: recopile evidencia de SOC 2, ISO 27001, privacidad, DPA, subservicios, incidentes, soporte y retención.
- Ejecute una prueba de humo en staging: envíe tráfico de prueba inocuo y luego guarde el registro de logs, el registro de uso, el registro de facturación y el registro de ruta.
- Ejecute una prueba de denegación: pruebe un modelo no permitido, una clave expirada, una solicitud por encima de la cuota o una clase de datos bloqueada y guarde el resultado.
- Revise el comportamiento de respaldo: apruebe o desactive el respaldo según el flujo de trabajo; no permita cambios silenciosos de proveedor para flujos sensibles.
- Apruebe los controles del comprador: defina la rotación de claves, la revisión de acceso, la revisión de rutas, las alertas de presupuesto, la respuesta a incidentes y la cadencia de renovación.
- Guarde la decisión: documente qué está aprobado, qué está prohibido, qué necesita renovación y qué activa una nueva revisión.
Preguntas frecuentes
¿Qué es una evaluación de riesgo de proveedor de API de IA?
Una evaluación de riesgo de proveedor de API de IA es una revisión de compras y seguridad del flujo de datos, la evidencia de seguridad, la exposición a proveedores, los controles operativos, los registros, los controles de facturación, el proceso de continuidad y las responsabilidades del comprador de un proveedor de API de IA. Para una pasarela multimodelo, debe incluir los proveedores de modelos posteriores y el comportamiento de cambio de ruta.
¿En qué se diferencia una evaluación de riesgo de una pasarela multimodelo de una revisión de proveedor único?
Una revisión de proveedor único suele centrarse en el contrato de un proveedor, las condiciones de datos, la evidencia de seguridad y el comportamiento de la API. Una revisión de pasarela también debe cubrir la selección de rutas, la conmutación por error, los cambios en el catálogo, la propiedad de claves, los registros de la pasarela, la atribución de facturación, los proveedores posteriores y quién puede cambiar qué proveedor recibe el tráfico.
¿La aprobación SOC 2 significa que una pasarela de IA está aprobada para todos los casos de uso en producción?
No. La evidencia de SOC 2 puede ayudar a evaluar el diseño y la operación de los controles para el sistema descrito y los criterios cubiertos, pero no aprueba automáticamente cada flujo de trabajo del comprador, clase de datos, ruta de modelo, ruta de conmutación por error, condición del proveedor o configuración de la cuenta. Vincule el informe a una ruta específica y al archivo de controles del comprador.
¿Qué registros debería solicitar compras antes de aprobar una pasarela de IA?
Solicite muestras de registros o exportaciones que muestren marca de tiempo, clave o proyecto, propietario, modelo, proveedor, familia de endpoint, estado, clase de error, token o unidades de uso, coste, intento de ruta, cambios administrativos y modo de registro de payloads. Evite almacenar prompts y salidas sin procesar a menos que el caso de uso y la política lo requieran.
¿Qué deben verificar los compradores de Flatkey antes del tráfico de producción?
Los compradores de Flatkey deben verificar la fila actual del modelo, el proveedor, la familia de endpoint, la unidad de precio, la disponibilidad, el comportamiento de ruta, los registros, el manejo de payloads, la retención, la ruta del DPA, el alcance del informe SOC 2, el alcance de ISO, la matriz de roles de administrador, el comportamiento de conmutación por error, la exportación de facturación y los controles presupuestarios. Las páginas públicas son evidencia útil para la evaluación inicial, pero la aprobación para producción debe usar evidencia actual específica de la cuenta.
CTA final
Una evaluación de riesgos de proveedores de API de IA es más sólida cuando convierte las afirmaciones del proveedor en evidencia a nivel de ruta. Para Flatkey, comience con las páginas públicas de confianza, precios y políticas; luego verifique la ruta exacta del modelo, los registros, los controles y la vía contractual en su propia cuenta. Cuando la ruta esté lista para una prueba de staging de bajo riesgo, obtenga una clave y prepare el paquete de adquisición antes de que el tráfico de producción se ponga en marcha.
