Un paquete de evidencia para la adquisición de un gateway de IA debería hacer que la aprobación sea repetible. No es una carpeta con las afirmaciones del proveedor. Es la prueba, propiedad del comprador, de que los equipos de seguridad, legal, ingeniería de plataforma, finanzas y el propietario del negocio revisaron el mismo comportamiento del gateway antes de que el tráfico pasara a través de él.
Esto es importante porque un gateway de IA se sitúa entre sus aplicaciones y los proveedores de modelos. Puede afectar a las claves, las rutas, el acceso a los proveedores, la facturación, el manejo de prompts y respuestas, los registros, las cuotas, el comportamiento de respaldo y la respuesta a incidentes. Si el registro de aprobación solo dice «página de confianza revisada», la siguiente renovación, auditoría, interrupción o consulta de datos empezará desde cero.
Flatkey está diseñado para equipos que desean una única superficie de gateway de API de IA para el acceso a modelos, el enrutamiento, la facturación, el análisis de uso y los controles operativos. Antes de aprobar cualquier gateway, incluido Flatkey, guarde evidencia fechada que muestre qué se revisó, quién lo aceptó, qué suposiciones aún necesitan pruebas a nivel de cuenta y qué debería desencadenar una revisión para la renovación.
Paquete de evidencia para la adquisición de un gateway de IA de un vistazo
Utilice esta tabla como la primera página del paquete. El nombre del archivo debe incluir el proveedor, el entorno, el propietario del negocio, la fecha de aprobación y la fecha de renovación.
| Archivo de evidencia | Guardar antes de la aprobación | Propietario | Desencadenante de renovación |
|---|---|---|---|
| Identidad del proveedor | Entidad legal, contacto de soporte, contraparte del contrato, términos actuales, política de privacidad, política de reembolso y páginas de SLA | Adquisiciones y legal | Cambio de entidad, términos, privacidad, pago o SLA |
| Alcance del gateway | Qué gestionará el gateway: familias de endpoints, aplicaciones, entornos, proveedores de modelos, alias de modelos y clases de datos | Ingeniería de plataforma | Nueva aplicación, nueva familia de endpoints, nuevo proveedor, carga de trabajo regulada |
| Manejo de datos | Política de privacidad, DPA o términos de datos, configuración de retención, política de carga útil de registros, términos de paso a través del proveedor y controles de redacción | Seguridad y legal | Cambio en el registro de prompts/respuestas, solicitud de ZDR, nueva categoría de datos |
| Controles de acceso | Propietarios de claves, proceso de creación de claves, programa de rotación, ruta de desvinculación, cuentas de servicio y límites de privilegio mínimo | Seguridad y plataforma | Nuevo equipo, clave compartida encontrada, propietario se va, clave de producción rotada |
| Auditoría y registros | Campos de ID de solicitud, exportaciones de uso, atribución de propietario, campos de facturación, registros de errores y límites de retención | Seguridad y finanzas | Solicitud de auditoría, incidente, falta de propietario de costos, cambio en el campo de registro |
| Facturación y cuotas | Página de precios actual, términos de prepago o factura, límites de cuota, política de recarga, proceso de reembolso y propietario del presupuesto | Finanzas y operaciones | Cambio de precio, nueva clase de modelo, agotamiento de crédito, problema con la factura |
| Fiabilidad | Página de estado o proceso de incidentes, SLA, lenguaje de mantenimiento, política de respaldo, prueba de estado de la ruta y propietario de la reversión | Ingeniería de plataforma | Interrupción, cambio de ruta del proveedor, latencia degradada, prueba de humo fallida |
| Aprobación final | Memorando de aprobación, riesgos abiertos, excepciones, transcripción de prueba, casos de uso aceptados y fecha de revisión | Propietario del negocio | Cualquier cambio material en el alcance, la política, los precios o la arquitectura |
La regla práctica: si un revisor necesitara el mismo artefacto durante una renovación, un incidente, un cuestionario de seguridad o una disputa financiera, pertenece al paquete de evidencia para la adquisición de un gateway de IA.
Comience con la identidad, la autoridad y el alcance
El departamento de adquisiciones debería poder responder a tres preguntas sin abrir un hilo de chat: ¿quién es la contraparte, qué estamos comprando y quién aprobó el alcance?
Para Flatkey, guarde copias fechadas de las páginas públicas que son importantes para el contrato y el registro operativo: la página de inicio, precios, términos, política de privacidad, acuerdo de nivel de servicio y política de reembolso. La página de precios de Flatkey en vivo describe actualmente las recargas prepagas de autoservicio, el soporte para adquisiciones empresariales, un saldo único para los modelos GPT, Claude, Gemini, DeepSeek, de imagen, audio y video, y la medición del uso por modelo, tipo de token y registros de solicitud. Guarde la página que revisó en lugar de confiar en un precio o una lista de modelos que recuerde.
Luego, defina el alcance en el lenguaje del comprador:
| Pregunta sobre el alcance | Evidencia a guardar | Por qué es importante |
|---|---|---|
| ¿Qué entornos utilizarán el gateway? | Lista de desarrollo, preproducción, producción, lotes y evaluación | Evita que el tráfico de producción herede una excepción de prueba no revisada |
| ¿Qué aplicaciones están dentro del alcance? | Nombres de aplicaciones, propietarios y clasificación de datos | Permite a seguridad mapear el uso del gateway a sistemas reales |
| ¿Qué familias de endpoints se requieren? | Rutas de chat, respuestas, mensajes, imágenes, video o específicas del proveedor | Evita aprobar una ruta y usar accidentalmente otra |
| ¿Qué proveedores y modelos están permitidos? | Lista de proveedores, alias de modelos, candidatos de respaldo y modelos no permitidos | Mantiene el enrutamiento alineado con las adquisiciones y la política |
| ¿Qué clases de datos pueden pasar a través? | Estado público, interno, de cliente, regulado, secretos, credenciales o PHI | Determina si la evidencia de DPA, retención y redacción es suficiente |
No trate una aprobación general del gateway como una aprobación para cada futuro modelo, proveedor o clase de datos. El paquete debe nombrar qué está aprobado y qué requiere otra revisión.
Guarde las pruebas de privacidad, DPA y retención como evidencia fechada
El error de mayor riesgo en la evidencia para la adquisición de un gateway de IA es confundir el lenguaje de marketing público con el manejo de datos específico de la cuenta. Los documentos públicos son evidencia útil para la selección. La aprobación final aún necesita el contrato firmado, el DPA, la configuración de la cuenta y cualquier término específico del proveedor que se aplique a tu tráfico.
Guarda estos archivos antes de la aprobación:
| Artefacto de datos | Qué capturar | Nota de revisión |
|---|---|---|
| Política de privacidad del proveedor | Fecha de entrada en vigor, categorías de datos cubiertas, datos de la cuenta, datos de uso de la API, datos de soporte, lenguaje de retención | La política pública no sustituye a un DPA |
| DPA o términos de datos | Entidad legal, subprocesadores, lenguaje de transferencia, derechos de auditoría, proceso de brecha | Confirma que coincide con tu entidad contratante |
| Retención de prompts y respuestas | Si se almacenan prompts, salidas, archivos, embeddings, imágenes o registros; TTLs predeterminados y configurables | Separa la retención del gateway de la retención del proveedor |
| Transferencia al proveedor (Passthrough) | Qué términos del proveedor ascendente se aplican cuando el gateway enruta a ese proveedor | Un gateway puede simplificar el acceso sin eliminar las obligaciones posteriores |
| Controles de redacción y omisión | Qué campos se pueden enmascarar, omitir o excluir de los registros | Necesario antes de cargas de trabajo sensibles o payloads de clientes |
| Residencia de datos | Región, copia de seguridad, acceso de soporte y declaraciones de procesamiento transfronterizo | Debe coincidir con los compromisos legales y del cliente |
Los documentos del proveedor muestran por qué esto debe ser explícito. La documentación de retención de datos de la API de Anthropic distingue la Retención Cero de Datos (Zero Data Retention) de otros acuerdos y señala que algunas características o modelos requieren almacenamiento durante períodos específicos. La documentación de la plataforma Gemini Enterprise Agent de Google Cloud también enmarca la retención cero de datos como algo que los clientes logran al cumplir con condiciones y configuraciones específicas. El Marco de Gestión de Riesgos de IA del NIST (AI Risk Management Framework) es una guía voluntaria, pero está claro que el uso confiable de la IA depende de la gestión de riesgos en el diseño, el uso y la evaluación, no de aceptar una única declaración del proveedor.
El paquete propiedad del comprador debe, por lo tanto, incluir tanto la documentación pública del proveedor como la evidencia específica de tu cuenta: capturas de pantalla de la configuración, adendas firmadas, confirmaciones de soporte y una breve declaración de lo que aún se asume.
Demuestra el control de acceso antes de compartir las claves de producción
La aprobación de acceso no es solo "quién puede iniciar sesión". Para un gateway de IA, significa quién puede crear claves, rotar claves, ver el uso, cambiar rutas, aprobar modelos, recargar saldo, exportar registros y deshabilitar el tráfico.
Guarda una página de control de claves en el paquete:
| Control | Evidencia a guardar | Fallo a evitar |
|---|---|---|
| Propietario de la clave | Propietario humano designado y propietario de respaldo para cada clave de producción | Clave huérfana después de cambios en el equipo |
| Alcance de la clave | Entorno, aplicación, ruta, conjunto de proveedores y conjunto de modelos | Clave compartida utilizada en cargas de trabajo no relacionadas |
| Rotación | Fecha de la última rotación, fecha de la próxima rotación y manual de rotación de emergencia | Clave de larga duración sin propietario |
| Proceso de baja (Offboarding) | Cómo se elimina el acceso cuando un ingeniero o proveedor se va | El exusuario conserva el acceso a la ruta o al panel de control |
| Uso de la cuenta de servicio | Si la automatización utiliza credenciales de usuario compartidas, credenciales de cuenta de servicio o identidad de carga de trabajo | Cambios de automatización no rastreables |
| Almacenamiento de secretos | Ruta del gestor de secretos, referencia de CI/CD y capturas de pantalla sin secretos | Claves de API que aparecen en tickets, documentos o registros |
El posicionamiento público de Flatkey en torno a una clave y un panel de control es útil para reducir la proliferación de cuentas de proveedores. El equipo de adquisiciones aún necesita pruebas de cómo tu equipo evitará que esa única clave del gateway se convierta en una superclave compartida. Combina este artículo con revisión de acceso a la API de IA y registros de auditoría para el uso de la API de IA al construir el flujo de trabajo de revisión interna.
Convierte las afirmaciones de registro en archivos de auditoría
Un paquete de evidencia para la adquisición de un gateway de IA debe responder qué sucedió, quién fue el responsable, cuánto costó y qué cambió. Guarda exportaciones de muestra, no solo capturas de pantalla de los gráficos del panel de control.
Campos de auditoría mínimos a probar:
| Campo de auditoría | Por qué los revisores lo necesitan |
|---|---|
| ID de solicitud y marca de tiempo | Apoya la reconstrucción de incidentes y los tickets de soporte |
| Clave o etiqueta del propietario | Vincula el tráfico a un equipo o servicio responsable |
| Familia de endpoints y ruta | Muestra si el tráfico utilizó la ruta del gateway aprobada |
| Modelo solicitado y modelo servido | Revela el comportamiento de enrutamiento, fallback y alias |
| Proveedor o cuenta ascendente | Separa la evidencia del gateway de la evidencia del proveedor posterior |
| Unidades de uso | Tokens, imágenes, segundos, unidades de caché u otras dimensiones de facturación |
| Costo estimado y real | Permite a finanzas revisar el gasto y la amplificación por reintentos |
| Clase de error y recuento de reintentos | Muestra si los fallos generaron un gasto adicional |
| Estado de redacción | Confirma si los prompts/respuestas se registraron, enmascararon u omitieron |
Conserva una prueba positiva y una prueba negativa. La prueba positiva demuestra que una solicitud normal es visible con los campos esperados de propietario, modelo, costo y ruta. La prueba negativa demuestra que una clave fallida, una ruta bloqueada, un evento de cuota o un modelo no válido se captura sin exponer secretos.
Para la revisión de riesgos de proveedores, conecte esta evidencia a la evaluación de riesgos de proveedores de API de IA. Para las operaciones, conéctela a los manuales de cuotas, reintentos e incidentes para que los registros sean útiles cuando algo falle.
Conserve la evidencia de precios, facturación y cuotas
El departamento de finanzas no debería aprobar un gateway de IA basándose únicamente en un titular de precios. El paquete debe mostrar cómo el equipo entenderá el costo unitario, el saldo prepagado, los registros de recarga, la gestión de facturas, los reembolsos y los límites presupuestarios una vez que comience el tráfico.
Guarde estos artefactos financieros:
| Artefacto financiero | Qué guardar |
|---|---|
| Página de precios actual | PDF o captura de pantalla con fecha, con clases de modelos, unidades y lenguaje del plan empresarial |
| Costo de la solicitud de prueba | ID de la solicitud, modelo, unidades de entrada/salida y costo mostrado en el panel de control |
| Flujo de saldo o facturación | Registro de recarga, muestra de factura, gestión de impuestos, procesador de pagos o contacto de facturación empresarial |
| Configuración de cuotas | Capturas de pantalla de las cuotas por clave, por equipo o a nivel de cuenta y su propietario |
| Política de reembolso o disputa | Proceso para cargos duplicados, deducciones incorrectas, fallos de entrega, errores en facturas y evidencia de soporte |
| Supuestos de renovación | Uso mensual esperado, combinación de modelos, rango de crecimiento y propietario para la revisión de cambios de precios |
El control clave no es si la tarifa actual es aceptable. Es si el departamento de finanzas puede reproducir el rastro de costos más adelante. Los precios y los catálogos de proveedores cambian, especialmente en los modelos de texto, imagen, audio y video. Guarde la evidencia con fecha y exija un activador de renovación cuando se agregue una nueva clase de modelo o ruta de proveedor.
Ejecute la prueba de humo de aprobación
Antes de la aprobación, ejecute una prueba controlada a través de la ruta del gateway propuesto. Si aún no hay una clave de producción disponible, ejecútela en un entorno de pruebas (sandbox) con configuraciones representativas y etiquete la evidencia como preproducción.
Utilice esta prueba de aprobación:
- Cree o seleccione la clave de prueba aprobada.
- Envíe una solicitud de bajo riesgo a través de la URL base y la familia de endpoints aprobadas.
- Capture el ID de la solicitud, el alias del modelo, el modelo servido si está disponible, la ruta, el proveedor, la latencia, las unidades de uso y el costo estimado.
- Confirme que la solicitud aparece en el panel de control o en la exportación bajo el propietario correcto.
- Provoque un fallo esperado, como un modelo no válido, una clave incorrecta, un límite de cuota o una ruta bloqueada.
- Confirme que el registro del fallo no revela secretos ni cargas útiles sensibles.
- Guarde la ruta de reversión: cómo deshabilitar la clave, desviar el tráfico o volver al acceso directo al proveedor.
El sitio público actual de Flatkey dirige a los usuarios a la consola, la página de precios, la página de modelos y el flujo de registro, y posiciona la plataforma en torno al acceso al gateway, el enrutamiento, la facturación, el análisis de uso y los controles operativos. Eso es suficiente para elaborar un plan de prueba de adquisición. No es suficiente para omitir la prueba específica de la cuenta.
La aprobación final debe incluir los riesgos abiertos
La página final del paquete de evidencia para la adquisición de un gateway de IA debe ser un registro de decisiones, no una lista de verificación para celebrar.
Incluya:
| Campo de decisión | Ejemplo |
|---|---|
| Caso de uso aprobado | Asistente de soporte de producción, resumen interno por lotes, evaluación de modelos o herramientas para desarrolladores |
| Ruta aprobada | URL base, familia de endpoints, conjunto de proveedores, alias de modelos y política de respaldo (fallback) |
| Datos aprobados | Solo públicos, solo internos, datos de clientes permitidos, datos regulados excluidos o PHI permitida solo después de un BAA |
| Controles requeridos | Propietario de la clave, límite de cuota, redacción de registros, revisión mensual, propietario del incidente |
| Riesgos abiertos | DPA pendiente, ZDR no habilitado, passthrough del proveedor no confirmado, respaldo (fallback) no aprobado |
| Fecha de revisión | Próxima renovación, primer mes de producción o antes de cualquier nueva clase de proveedor/modelo |
| Aprobadores | Adquisiciones, legal, seguridad, plataforma, finanzas y propietario del negocio |
Este registro mantiene la honestidad en la aprobación. Si se acepta un riesgo, indique quién lo aceptó y cuándo expira. Si una afirmación aún necesita pruebas, no la entierre en un hilo de chat.
En resumen
Una buena evidencia para la adquisición de un gateway de IA convierte las afirmaciones del proveedor en archivos que el comprador controla: páginas de políticas con fecha, términos del contrato, configuraciones de la cuenta, propietarios de acceso, exportaciones de auditoría, pruebas de costos, transcripciones de pruebas de humo y activadores de renovación.
Para Flatkey, comience guardando las páginas actuales de producto, precios, términos, privacidad, SLA y reembolso; defina las aplicaciones, rutas, modelos, proveedores, clases de datos y propietarios exactos dentro del alcance; luego ejecute una pequeña prueba del gateway antes de la aprobación para producción. Utilice la lista de verificación del gateway de API de IA empresarial como la revisión de control más amplia, luego obtenga una clave y mantenga el registro de aprobación adjunto al equipo que será propietario del tráfico.
Preguntas frecuentes
¿Qué es la evidencia para la adquisición de un gateway de IA?
La evidencia para la adquisición de un gateway de IA es el paquete de pruebas propiedad del comprador que respalda la aprobación de un gateway de API de IA. Incluye páginas del proveedor con fecha, términos firmados, evidencia de privacidad y retención, prueba de control de acceso, muestras de auditoría, registros de precios, pruebas de humo y la aprobación final.
¿Es suficiente una página de confianza para la aprobación de un gateway de IA?
No. Una página de confianza es evidencia de selección, no un registro de aprobación completo. Los compradores deben guardar la página de confianza, pero también necesitan el alcance del contrato, el estado del DPA, la configuración de la cuenta, la propiedad del acceso, muestras de registro, evidencia de precios y resultados de las pruebas.
¿Quién debería ser el propietario del paquete de evidencia para la adquisición del gateway de IA?
El departamento de adquisiciones o el legal pueden ser los propietarios de la carpeta del contrato, pero la ingeniería de plataforma debe ser la propietaria del alcance técnico y de la evidencia de las pruebas de humo (smoke tests). El equipo de seguridad debe ser el propietario de los datos, el acceso y las pruebas de auditoría. El departamento de finanzas debe ser el propietario de la evidencia de precios, uso, cuotas y facturas.
¿Con qué frecuencia se debe actualizar el paquete de evidencia?
Actualícelo en el momento de la renovación, después de cambios importantes en las políticas o los precios, antes de añadir un nuevo proveedor o una nueva clase de modelo, antes de enrutar datos regulados y después de cualquier incidente que cambie las suposiciones operativas del gateway.
¿Qué deben guardar los compradores de Flatkey antes de la aprobación?
Los compradores de Flatkey deben guardar copias fechadas de la página de inicio, la página de precios, los términos, la política de privacidad, el SLA, la política de reembolso, el alcance del modelo y la ruta, el plan del propietario de la clave, la configuración de cuotas, las muestras de auditoría/registros, la evidencia de facturación y la primera prueba de humo (smoke test) exitosa del gateway.
