Un flujo de trabajo para la aprobación de modelos de IA es la puerta de lanzamiento que decide si una ruta de modelo puede gestionar el tráfico de producción. La ruta no es solo el nombre del modelo. Es el proveedor, la familia de puntos de conexión, la versión del prompt, los permisos de las herramientas, el comportamiento de respaldo, la configuración de registro, el límite de costes, el propietario y la ruta de reversión que se ejecutarán detrás de una característica del producto.
Por eso la aprobación debe realizarse antes de que una nueva ruta entre en producción. Un modelo puede parecer seguro en una demostración y aun así fallar en producción porque se implementa la versión incorrecta del prompt, un respaldo envía tráfico a un proveedor no revisado, una llamada a una herramienta obtiene demasiada autoridad, una configuración de registro almacena cargas útiles durante más tiempo del esperado o el departamento financiero no puede conciliar el gasto después del lanzamiento.
Utilice este flujo de trabajo para la aprobación de modelos de IA para convertir un cambio de modelo en un archivo de evidencia propiedad del comprador. El resultado debe ser lo suficientemente claro para que los departamentos de ingeniería, seguridad, adquisiciones, finanzas y producto puedan responder la misma pregunta más adelante: ¿qué se aprobó, por qué se aprobó, qué evidencia se revisó y qué desencadena una nueva revisión?
Para los compradores de Flatkey, esta revisión corresponde a la ruta de la puerta de enlace. El sitio público actual de Flatkey posiciona el producto como una puerta de enlace de API de IA para el acceso a modelos, enrutamiento, facturación, análisis de uso y controles operativos, con una clave de API, una URL base y un panel de control. Eso convierte a la puerta de enlace en un lugar útil para centralizar la evidencia de la ruta. No elimina la necesidad de verificar el registro específico de la cuenta, los términos del proveedor, el comportamiento del modelo, el manejo de datos y las responsabilidades de aprobación antes del lanzamiento a producción.
Qué aprueba el flujo de trabajo
Un flujo de trabajo para la aprobación de modelos de IA debe aprobar una ruta, no el eslogan de un proveedor. El registro de aprobación debe identificar el comportamiento exacto en producción que existirá después del lanzamiento.
| Superficie de la ruta | Pregunta de aprobación | Evidencia a conservar | Bloqueador del lanzamiento |
|---|---|---|---|
| Caso de uso | ¿Qué tarea de usuario o sistema realizará esta ruta? | Resumen del producto, clasificación de datos, impacto en el usuario, casos de abuso | La tarea es vaga o la propiedad no está clara |
| Modelo y proveedor | ¿Qué modelo, proveedor, punto de conexión, región y ruta de cuenta servirán el tráfico? | Documentación del proveedor, estado del modelo/versión, configuración de la ruta, lista de respaldo | Un respaldo puede seleccionar un modelo no aprobado |
| Política de prompts y herramientas | ¿Qué instrucciones, herramientas, esquemas y permisos están permitidos? | Versión del prompt, manifiesto de la herramienta, esquema tipado, revisión de código | La herramienta puede realizar una acción irreversible sin un control |
| Paquete de evaluación | ¿Qué pruebas demuestran que la ruta es suficientemente buena para este caso de uso? | Conjunto de datos de evaluación, métricas, umbrales, notas del revisor, ejemplos de fallos | No existe un umbral de aprobado/suspenso específico para la tarea |
| Controles de seguridad y abuso | ¿Cómo se gestionan la inyección de prompts, las salidas no seguras, la fuga de datos y la omisión de políticas? | Casos de equipo rojo, configuración de filtros, pruebas de denegación, alertas de monitorización | Un fallo conocido no tiene mitigación ni propietario |
| Datos y registro | ¿Qué prompts, salidas, metadatos, trazas y filas de facturación se almacenan? | Mapa de flujo de datos, muestra de registro, clase de retención, prueba de redacción | El almacenamiento de la carga útil sin procesar no está claro o no tiene límites |
| Coste y capacidad | ¿Qué gasto, cuota, límite de velocidad, tiempo de espera y comportamiento de respaldo están permitidos? | Límite de presupuesto, muestra de uso, prueba de estrés, propietario financiero | Un modo de fallo puede generar un gasto incontrolado |
| Lanzamiento y reversión | ¿Cómo se iniciará, ampliará, pausará y revertirá el tráfico? | Indicador de función, plan canario, comando de reversión, contacto para incidentes | La reversión depende de una suposición manual |
| Desencadenante de renovación | ¿Qué cambio obliga a una nueva aprobación? | Fecha de revisión, seguimiento de la obsolescencia del modelo, política de cambio de ruta | Nadie es responsable de la deriva después del lanzamiento |
El punto clave: la aprobación no es una reunión. La aprobación es un paquete de evidencia más un control de ruta.
Utilice un marco de ciclo de vida, no una lista de verificación única
El Marco de Gestión de Riesgos de IA del NIST es un marco práctico porque organiza el trabajo en torno a Gobernar, Mapear, Medir y Gestionar. Eso se corresponde claramente con un flujo de trabajo para la aprobación de modelos de IA:
| Función del AI RMF | Traducción para la aprobación de rutas |
|---|---|
| Gobernar | Asignar propietario de la ruta, propietario del riesgo, propietario financiero, revisor de seguridad, política de aprobación y reglas de desmantelamiento |
| Mapear | Describir el caso de uso, los usuarios, los datos, el proveedor ascendente, los límites del modelo, las dependencias de la ruta y el impacto empresarial |
| Medir | Ejecutar evaluaciones funcionales, pruebas adversariales, comprobaciones de seguridad, pruebas de coste, pruebas de latencia y comprobaciones de observabilidad |
| Gestionar | Aprobar, lanzar, monitorizar, pausar, renovar o desmantelar la ruta basándose en la evidencia |
El Perfil de IA Generativa del NIST también es importante porque los sistemas generativos introducen riesgos que las revisiones de cambios de API ordinarias a menudo pasan por alto: inyección de prompts, alucinaciones, exposición de datos, expansión de capacidades no seguras, deriva del modelo y uso indebido posterior. Trate el marco como una forma de estructurar las decisiones, no como un sustituto de su propia evidencia.
Lista de verificación del flujo de trabajo para la aprobación de modelos de IA
Utilice esta lista de verificación para cada nueva ruta de modelo, cambio material en el prompt, cambio de permisos de herramientas, respaldo de proveedor o migración de punto de conexión.
- Defina la ruta.
Registre el ID de la ruta, el propietario, la característica del producto, el entorno, la familia de puntos de conexión, el modelo principal, los modelos de respaldo permitidos, las cuentas de proveedor, la versión del prompt, el manifiesto de la herramienta, las clases de datos y el patrón de tráfico esperado.
- Clasifique el caso de uso.
Decida si la ruta afecta a datos de clientes, datos de empleados, flujos de trabajo regulados, decisiones financieras, decisiones de soporte, revisión legal, ejecución de código, acciones externas o contenido sensible a la seguridad. Una ruta de resumen y un agente de reembolso autónomo no deben compartir la misma profundidad de aprobación.
- Recopile pruebas del modelo y del proveedor.
Conserve los documentos del modelo del proveedor, las tarjetas de modelo o las tarjetas de sistema cuando estén disponibles, el estado de obsolescencia, los documentos de filtrado de contenido, los términos de manejo de datos, las restricciones regionales y la configuración a nivel de cuenta. La guía de versiones de modelos de Google es un recordatorio para registrar si un modelo es estable, está en vista previa, es experimental, está obsoleto o retirado. No apruebe solo un nombre de visualización amigable.
- Versione las instrucciones y las herramientas.
La guía de instrucciones de OpenAI recomienda instrucciones de producción gestionadas por código, entradas tipadas, revisión de código, pruebas, verificaciones de evaluación y despliegue por etapas. Ese es el patrón correcto para un flujo de trabajo de aprobación de modelos de IA propiedad del comprador: el comportamiento de las instrucciones pertenece al mismo proceso de lanzamiento que el comportamiento del código.
- Cree evaluaciones específicas para cada tarea.
Las mejores prácticas de evaluación de OpenAI enmarcan las evaluaciones como pruebas estructuradas de precisión, rendimiento y fiabilidad en sistemas de IA variables. La aprobación debe requerir un paquete de evaluación específico para la tarea, no solo una captura de pantalla de un benchmark genérico. Incluya casos típicos, casos límite, casos adversarios, casos multilingües, casos de herramientas y ejemplos de fallos conocidos.
- Ejecute pruebas de seguridad y de uso indebido.
La guía de inyección de instrucciones LLM01 de OWASP distingue entre la inyección de instrucciones directa e indirecta. Añada pruebas para ambas. Si la ruta puede llamar a herramientas, recuperar documentos, escribir registros, enviar mensajes o ejecutar código, pruebe la autoridad excesiva, la manipulación de argumentos de herramientas, el conflicto de instrucciones del sistema y las instrucciones ocultas en el contenido recuperado.
- Verifique la retención de datos y el registro.
Decida si se almacenan las instrucciones, los resultados, los argumentos de las herramientas, los archivos, los fragmentos recuperados, los seguimientos, los metadatos de las solicitudes, los eventos de auditoría y las filas de facturación. Utilice la lista de verificación de retención de datos de la API de IA para separar el contenido de la carga útil de los metadatos, y utilice los registros de auditoría para el uso de la API de IA para demostrar quién cambió las claves, las rutas, el registro, la cuota y la política del modelo.
- Establezca límites de coste, fiabilidad y respaldo.
Registre los presupuestos de tokens, los presupuestos de solicitudes, los límites de cuota, la estrategia de tiempo de espera, la política de reintentos, la lista de modelos de respaldo, el disyuntor y los umbrales de alerta. Un respaldo que desvía silenciosamente el tráfico a un modelo más potente, más caro o menos revisado es un fallo de gobernanza, incluso cuando la experiencia del usuario parece correcta.
- Apruebe el despliegue por etapas y la renovación.
Realice el lanzamiento a través de un canary, un indicador de función, un peso de ruta o una lista de inquilinos permitidos. Defina la verificación de la primera hora, la verificación del primer día, la verificación de la primera semana y el activador de renovación. Vuelva a aprobar cuando cambie la versión del modelo, cambien los términos del proveedor, cambie el comportamiento de las instrucciones, cambien los permisos de las herramientas, cambie el registro, cambie el perfil de costes o cambie la población de usuarios.
Cree el paquete de aprobación
El flujo de trabajo de aprobación de modelos de IA más sólido deja tras de sí un paquete de aprobación compacto. Debe ser lo suficientemente corto como para revisarlo, pero lo suficientemente específico como para auditarlo.
| Campo del paquete | Respuesta requerida | Artefacto de prueba | Desencadenante de renovación |
|---|---|---|---|
| ID de la ruta | ID estable para esta ruta de producción | Configuración de la ruta del gateway o solicitud de cambio | Renombrar, fusionar o dividir la ruta |
| Propietario del negocio | ¿Quién acepta el riesgo del producto? | Registro de aprobación | Cambio de propietario |
| Propietario técnico | ¿Quién puede pausar o revertir? | Documento de guardia, runbook | Cambio de equipo o de guardia |
| Clase de datos | ¿Qué datos pueden entrar en los prompts, herramientas, archivos y recuperación? | Mapa de flujo de datos, clase de payload de muestra | Nueva fuente de datos o segmento de clientes |
| Lista de modelos | Modelo principal, modelos de respaldo, familia de endpoints, cuenta del proveedor | Documentos del modelo/versión, lectura de la ruta | Nuevo modelo, respaldo, endpoint o proveedor |
| Versión del prompt | Constructor de prompts actual, esquema y fuente de instrucciones del sistema | Commit de Git o configuración revisada | Cambio de prompt, esquema o herramienta |
| Paquete de evaluación | Conjunto de datos, métricas, umbrales, fallos, aprobación del revisor | Informe de evaluación | Cambio en el modelo, prompt, datos o distribución de usuarios |
| Controles de seguridad | Filtros de contenido, política de rechazo, pruebas de inyección de prompts, escalamiento a humanos | Informe de prueba y configuración de filtros | Cambio de filtro, política o clasificación de riesgos |
| Controles de herramientas | Herramientas permitidas, ámbitos, argumentos, requisitos de aprobación | Manifiesto de la herramienta y prueba de permisos | Cambio de permiso de la herramienta o de efecto secundario |
| Registros y retención | Campos de metadatos, política de payload, clase de retención, comportamiento de redacción | Muestra de registro y lectura de retención | Cambio de exportación, observabilidad o retención |
| Controles de costos | Presupuesto, cuota, límite de velocidad, alerta, propietario de la factura | Muestra de uso y umbral de costo | Cambio de precios, tráfico o combinación de modelos |
| Plan de despliegue | Tamaño del canary, método de reversión, condiciones de detención | Registro de feature flag o peso de la ruta | Expansión de la cohorte de despliegue |
| Monitoreo posterior al lanzamiento | Métricas, alertas, cadencia de revisión, ruta de incidentes | Captura de pantalla del panel o lectura de la API | Alerta omitida, incidente o deriva |
Este paquete es también un activo de adquisición. Hace que la revisión del proveedor sea concreta: en lugar de preguntar si un proveedor está "listo para la empresa", el comprador pregunta qué evidencia demuestra que esta ruta está lista.
Pruebas de preproducción antes de que una ruta se ponga en marcha
El conjunto de pruebas debe coincidir con el caso de uso aprobado. Una ruta que solo etiqueta tickets de soporte necesita pruebas diferentes a las de una ruta que escribe SQL, emite reembolsos, edita código o resume notas médicas.
| Carril de prueba | Qué probar | Evidencia a conservar | Condición de detención |
|---|---|---|---|
| Corrección funcional | Resultados esperados en tareas normales | Puntuación de evaluación, ejemplos de fallos, notas del revisor | Tasa de aprobación por debajo del umbral |
| Jerarquía de instrucciones | Prompt del sistema vs. prompt del usuario en conflicto | Casos adversarios | El prompt del usuario anula la política del sistema |
| Inyección de prompts | Inyección directa e indirecta en el texto del usuario, documentos recuperados, archivos y salidas de herramientas | Transcripción del equipo rojo | La instrucción oculta cambia la tarea |
| Autoridad de la herramienta | Selección de herramientas, extracción de argumentos, ámbito y efectos secundarios | Registros de llamadas a herramientas y casos de denegación | La herramienta puede realizar una acción no aprobada |
| Fuga de datos | Secretos, datos privados, identificadores de clientes y exposición del contexto recuperado | Prueba de fixture | El fixture sensible aparece en la salida o en los registros |
| Filtrado de contenido | Categorías de políticas de entrada/salida y umbrales de gravedad | Configuración del filtro y casos bloqueados | La categoría requerida no se monitorea ni se bloquea |
| Costo y cuota | Presupuesto de tokens, límite de velocidad, gasto de respaldo, ráfaga de abuso | Filas de uso y prueba de alerta | El gasto puede aumentar sin alerta al propietario |
| Fiabilidad | Tiempo de espera, reintento, streaming, respaldo, interrupción del proveedor, cortocircuito | Simulacro de fallo | El tráfico de usuarios sigue reintentando hasta fallar |
| Auditabilidad | Cambio de clave, cambio de ruta, cambio de prompt, acceso a registros, cambio de cuota | Muestra de evento de auditoría | El cambio no se puede vincular al actor y al momento |
| Reversión | Deshabilitar ruta, revertir prompt, eliminar respaldo, restaurar modelo anterior | Simulacro de reversión | La reversión no se puede completar rápidamente |
Los documentos de filtrado de contenido de Azure OpenAI de Microsoft son útiles como recordatorio de que los filtros tienen categorías, gravedades, opciones de configuración y comportamientos opcionales. Su registro de aprobación debe capturar la configuración real utilizada para la ruta, no solo la existencia de una función de seguridad en algún lugar de la pila.
Ejemplo de política de ruta
La aprobación debe producir una política de ruta que los ingenieros puedan implementar y los revisores puedan inspeccionar. El esquema exacto depende de su gateway, pero la forma debe ser explícita.
route_id: support-summary-prod
owner:
product: support_ops
engineering: ai_platform
security: appsec
finance: finops
use_case:
task: summarize_support_threads
data_class: customer_support_confidential
allowed_environments: [production]
models:
primary: approved_summary_model_2026_07
fallbacks:
- approved_summary_backup_2026_07
denied:
- any_preview_model_without_reapproval
prompt:
source: app/prompts/support_summary.ts
reviewed_commit: 8f3c2d1
schema_required: true
tools:
allowed:
- read_ticket_metadata
denied:
- refund_customer
- send_email
logging:
payload_storage: disabled
metadata_retention_class: ops_metadata_90d
audit_events:
- route_change
- model_change
- prompt_change
- key_rotation
controls:
max_input_tokens: 8000
max_output_tokens: 700
monthly_budget_usd: 500
fallback_requires_same_data_policy: true
evals:
pack: support_summary_eval_2026_07
min_pass_rate: 0.95
required_tests:
- prompt_injection
- sensitive_data_fixture
- tool_scope
rollout:
canary_percent: 5
expand_after_hours: 24
rollback: disable_route_weight
renewal:
review_by: 2026-10-04
triggers:
- model_version_change
- prompt_change
- new_tool
- logging_change
- provider_terms_changeAquí es donde el flujo de trabajo para la aprobación de modelos de IA se vuelve operativo. Si la configuración de una ruta no puede expresar la decisión, la aprobación es demasiado abstracta.
Cómo encaja esto con Flatkey
Flatkey puede servir como la superficie operativa para este flujo de trabajo porque la superficie pública del producto se centra en el acceso unificado a modelos, el enrutamiento, la facturación, los análisis de uso, los límites de cuota y un único panel para claves y enrutamiento. La página de inicio actual también muestra un patrón de solicitud compatible con OpenAI usando https://router.flatkey.ai/v1/chat/completions, mientras que las páginas de precios y modelos describen el saldo prepago, los análisis de uso, los precios de los modelos y la cobertura de proveedores.
Utilice Flatkey como la superficie de evidencia de la puerta de enlace y, a continuación, verifique estos detalles específicos de la cuenta antes de la aprobación:
- Qué modelos y proveedores están habilitados para la ruta.
- Qué familia de puntos de conexión utiliza cada ruta.
- Qué modelos de respaldo están permitidos y denegados.
- Qué claves de API, equipos, proyectos y entornos pueden llamar a la ruta.
- Qué controles de uso, coste y cuota están disponibles para la cuenta del comprador.
- Qué metadatos de solicitud, eventos de auditoría y registros de facturación son visibles.
- Si se almacenan las instrucciones sin procesar, los resultados, los argumentos de las herramientas, los archivos o los seguimientos.
- Si los cambios de ruta, los cambios de clave, los cambios de cuota y los cambios de registro producen evidencia revisable.
No convierta esto en una declaración de confianza genérica. Una puerta de enlace puede reducir la proliferación de proveedores y centralizar la evidencia, pero el comprador sigue siendo el propietario del flujo de trabajo para la aprobación de modelos de IA.
Preguntas que debe hacer el departamento de adquisiciones
Los equipos de adquisiciones y seguridad deben solicitar evidencia que coincida con la ruta, no solo una descripción general de la plataforma.
| Pregunta | Buena evidencia | Evidencia débil |
|---|---|---|
| ¿Qué modelo servirá a esta ruta? | Lectura de la ruta con modelos primarios y de respaldo | «Utilizamos los mejores modelos de su clase» |
| ¿Qué sucede si el modelo falla? | Política de tiempo de espera, reintento, respaldo y reversión | «La puerta de enlace se encarga de ello» |
| ¿Qué datos se registran? | Evento de metadatos de muestra y política de carga útil | «Tenemos registros» |
| ¿Quién puede cambiar la ruta? | Lista de roles y muestra de eventos de auditoría | «Los administradores pueden gestionarlo» |
| ¿Qué evaluaciones se han superado? | Conjunto de datos, umbral, fallos y notas del revisor | «Funcionó en las pruebas» |
| ¿Qué controles de seguridad están activos? | Configuración de filtros, pruebas de denegación, casos de inyección de instrucciones | «La seguridad está habilitada» |
| ¿Qué revisa el departamento de finanzas? | Filas de uso, instantánea de precios, alerta de presupuesto, ruta de la factura | «Hay un panel de control» |
| ¿Qué obliga a una nueva aprobación? | Lista de activadores por escrito y propietario | «Revisamos cuando es necesario» |
Conecte esta revisión con la lista de verificación de la puerta de enlace de la API de IA empresarial para los controles a nivel de puerta de enlace, la evaluación de riesgos de proveedores de API de IA para los límites de los proveedores ascendentes y los registros de auditoría para el uso de la API de IA para obtener evidencia de cambios duradera.
Renovación y retirada
El mayor fallo de la aprobación es la desviación. La ruta que se aprobó en julio puede no ser la que se esté ejecutando en octubre.
Establezca activadores de renovación antes del lanzamiento:
- Una versión del modelo queda obsoleta, se retira, pasa a ser solo de vista previa o se sustituye.
- Un proveedor cambia el manejo de datos, el filtrado de contenido, los precios, la región o el soporte de funciones.
- Cambia un modelo de respaldo, el peso de la ruta, la familia de puntos de conexión o la cuenta del proveedor.
- Cambia una instrucción, un esquema, una fuente de recuperación, una instrucción del sistema o un permiso de herramienta.
- Un nuevo grupo de usuarios, nivel de cliente, geografía o clase de datos comienza a usar la ruta.
- Una alerta de monitorización muestra una desviación en la calidad, la seguridad, la latencia, el coste o el abuso.
- Un incidente, una escalada de soporte, una queja de un cliente o un hallazgo de adquisiciones afecta a la ruta.
La retirada debe formar parte del mismo flujo de trabajo para la aprobación de modelos de IA. Cuando se retira una ruta, registre la ruta de reemplazo, la fecha de drenaje del tráfico, las claves deshabilitadas, los secretos eliminados, los registros conservados, el cierre de la facturación y la aprobación final del propietario.
Preguntas frecuentes
¿Qué es un flujo de trabajo para la aprobación de modelos de IA?
Un flujo de trabajo para la aprobación de modelos de IA es el proceso de gobernanza que decide si una ruta de modelo puede gestionar el tráfico de producción. Registra el caso de uso, la ruta del modelo/proveedor, la política de prompts y herramientas, los resultados de la evaluación, los controles de seguridad, el comportamiento del registro, las barreras de protección de costos, el plan de despliegue y los activadores de renovación.
¿Quién debe aprobar una nueva ruta de modelo de IA?
Como mínimo, la aprobación debe incluir al propietario del producto, al propietario técnico, al revisor de seguridad o de riesgos y al propietario de finanzas u operaciones. Las rutas de mayor riesgo también pueden necesitar una revisión legal, de adquisiciones, de privacidad, de soporte o ejecutiva.
¿Es suficiente una tarjeta de modelo para la aprobación?
No. Una tarjeta de modelo o una tarjeta de sistema es una prueba útil, pero no demuestra que su prompt, herramientas, fallback, registro, flujo de datos, controles de costos y comportamiento de despliegue sean seguros para su caso de uso. La ruta sigue necesitando su propio paquete de aprobación.
¿Con qué frecuencia deben revisarse las aprobaciones de los modelos?
La cadencia de revisión depende del riesgo, pero cada ruta debe tener activadores de renovación. Vuelva a aprobar cuando cambie la versión del modelo, el proveedor, el prompt, los permisos de las herramientas, el registro, la clase de datos, el fallback, el perfil de costos o la población de usuarios.
¿Cómo ayuda un gateway de IA con la aprobación de modelos?
Un gateway de IA puede centralizar el acceso al modelo, la política de rutas, las claves, el uso, el costo, la cuota y la evidencia de auditoría. No sustituye a la gobernanza del comprador. Utilice el gateway como superficie de control y evidencia, y luego verifique el comportamiento específico de la cuenta.
Conclusión
Un flujo de trabajo para la aprobación de modelos de IA debe hacer que los cambios en los modelos de producción se puedan revisar antes de que se conviertan en incidentes. Apruebe rutas, no nombres de modelos vagos. Mantenga el archivo de evidencia cerca del gateway, exija evaluaciones específicas para cada tarea, pruebe la inyección de prompts y la autoridad de las herramientas, verifique los controles de registro y de costos, y establezca activadores de renovación antes de que se lance la primera solicitud. Cuando esté listo para centralizar el acceso a los modelos, el enrutamiento, el uso y la facturación detrás de un único gateway, revise el catálogo de modelos y precios actual de Flatkey y, a continuación, obtenga una clave.
