¿Qué es un flujo de aprobación de IA?
Gobernanza, riesgo y aseguramiento
Un flujo de aprobación de IA es el proceso de decisión por etapas que determina si un caso de uso de IA puede avanzar desde la idea hasta el piloto y, finalmente, hasta el uso en producción. Establece las verificaciones, las evidencias, los revisores y las autorizaciones requeridas en cada etapa. Un flujo sólido abarca cuestiones legales, de privacidad, seguridad, contratación, pruebas técnicas y supervisión humana, y registra quién asumió el riesgo residual. En la práctica, es el camino de control que convierte las reglas de gobernanza de la IA en decisiones de despliegue.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Un flujo de aprobación de IA no es un documento único ni una reunión única. Es el recorrido que utiliza una organización para llevar un sistema de IA a través de etapas definidas: habitualmente desde el concepto hasta el experimento o piloto, luego hasta la producción, y después a través de cambios posteriores. En cada etapa, alguien debe presentar evidencia suficiente para que se autorice el siguiente paso.
También es distinto de otros artefactos de gobernanza relacionados. No es lo mismo que una política de IA, un registro de riesgos, una evaluación de impacto, un comité de gobernanza o un proceso de cambio. Esos son insumos o controles dentro del flujo. El flujo es el camino de decisión que indica cuándo se necesita cada uno de esos elementos, quién los revisa y quién tiene autoridad para decir "adelante", "todavía no" o "detener".
No existe un único estatuto global que defina el término en una sola frase. Sin embargo, en los marcos oficiales y las orientaciones regulatorias, el patrón es claro: se espera que las organizaciones tomen decisiones sobre IA mediante revisiones documentadas y basadas en riesgos, con responsables identificados, evidencia, supervisión y seguimiento continuo.
Por qué importa
Los flujos de aprobación de IA importan porque los sistemas de IA suelen avanzar más rápido que la gobernanza que los rodea. Los equipos pueden adquirir herramientas, ajustar modelos, conectar servicios externos o lanzar copilotos internos antes de que nadie haya verificado adecuadamente el uso de datos, los impactos sobre derechos, las dependencias de proveedores, la supervisión humana o los planes de contingencia. Un flujo bien definido frena lo que debe frenarse y agiliza lo que debe agilizarse: las ideas débiles se detienen pronto, el trabajo de menor riesgo sigue un camino más ligero, y los usos de mayor riesgo se someten a una revisión más profunda.
También importan porque los reguladores y los organismos de normalización esperan cada vez más pruebas concretas, no solo buenas intenciones. Esas pruebas pueden incluir evaluaciones de impacto, documentación técnica, registros de pruebas, comentarios de revisión, registros de aceptación de riesgos, planes de seguimiento, registros e informes de incidentes. Sin un flujo, esos artefactos suelen faltar, ser inconsistentes o elaborarse demasiado tarde. Eso dificulta demostrar el cumplimiento, investigar incidentes y explicar a directivos, clientes, reguladores o auditores por qué se autorizó el uso de un sistema de IA.
Cómo funciona
Comienza con el alcance y la clasificación inicial
Un flujo de aprobación comienza por determinar qué se está proponiendo exactamente. ¿Es un asistente interno sencillo para redacción, un modelo que ayuda al personal a tomar decisiones, o un sistema que afecta directamente a personas, al acceso a servicios, al empleo, al crédito, a la seguridad o a derechos? ¿La organización lo está desarrollando, comprando o combinando datos internos con un modelo de terceros? ¿Es solo una prueba o está destinado a un uso empresarial en producción?
Esa primera clasificación importa porque los marcos oficiales están basados en riesgos, no son de talla única. NIST enmarca la gestión del riesgo de IA como algo que comienza en la fase de planificación y diseño y continúa a lo largo de todo el ciclo de vida de la IA. La orientación federal canadiense exige una Evaluación de Impacto Algorítmico al inicio de la fase de diseño y de nuevo antes de la producción. El EU AI Act obliga primero a la clasificación, porque las obligaciones cambian significativamente si un sistema es de alto riesgo. En otras palabras, la primera etapa suele ser una etapa de clasificación.
Un flujo maduro plantea, por tanto, un conjunto reducido de preguntas iniciales: para qué sirve el sistema, quiénes pueden verse afectados, si se manejan datos personales, si se está informando una decisión regulada, si el sistema utiliza componentes de terceros y si alguna ley o norma sectorial activa controles adicionales. Si la respuesta es "esto es de bajo riesgo y está bien delimitado", el camino puede ser ligero. Si la respuesta es "esto podría afectar derechos, seguridad o decisiones reguladas", el camino debe profundizarse rápidamente.
Asigna responsables, revisores y tomadores de decisiones
Un flujo solo funciona si los roles están claros. Alguien debe ser responsable del caso de uso. Alguien debe coordinar la revisión. Alguien debe tener autoridad para aceptar el riesgo residual. Y los revisores deben incluir más que ingenieros.
Las orientaciones oficiales apuntan de forma consistente a una gobernanza multidisciplinar. NIST describe la gobernanza y supervisión, la evaluación de impacto, la contratación, la experiencia en el dominio y las pruebas como tareas de actores distintos a lo largo del ciclo de vida. La ICO señala que la alta dirección no puede simplemente delegar la gobernanza de la IA en los equipos técnicos y pasar a otra cosa. La orientación canadiense indica que la evaluación debe completarse con un equipo multidisciplinar y menciona específicamente la consulta con áreas de privacidad y legal. La política federal estadounidense vigente exige consejos de gobernanza de IA con representación de TI, ciberseguridad, datos, legal, privacidad, derechos civiles, libertades civiles, contratación y oficinas de programa.
En la práctica, esto suele traducirse en cuatro niveles de responsabilidad. Primero, un patrocinador de negocio o propietario del producto define el propósito y es responsable del uso operativo. Segundo, revisores especializados, como legal, privacidad, seguridad, contratación, riesgos y expertos en el dominio, evalúan la propuesta desde su propia perspectiva. Tercero, un órgano de gobernanza o un ejecutivo autorizado decide si se ha superado la etapa. Cuarto, los equipos operativos son responsables del cumplimiento tras el lanzamiento, incluido el seguimiento, el reentrenamiento, la reversión y la escalada de incidentes.
Cada etapa depende de evidencia, no de entusiasmo
El núcleo de un flujo de aprobación de IA es el paquete de evidencia. Un equipo no debería llegar al piloto o a la producción porque un modelo parecía prometedor en una demostración. Debería avanzar porque la organización ha reunido evidencia suficiente para evaluar el propósito, los riesgos, los controles y la incertidumbre residual.
El contenido de ese paquete varía según el contexto, pero las fuentes oficiales muestran un patrón común. La ICO considera que una DPIA es una forma ideal de demostrar el cumplimiento para sistemas de IA que tratan datos personales, y señala que puede servir como hoja de ruta para identificar y controlar riesgos. También indica que las organizaciones deben justificar y documentar las compensaciones con un estándar auditable, con un proceso de aprobación sólido, basado en riesgos e independiente. La política federal estadounidense vigente para IA de alto impacto exige una evaluación de impacto de IA antes del despliegue, que incluya el propósito previsto, la calidad e idoneidad de los datos, los impactos potenciales, los procedimientos de reevaluación, la revisión independiente y la aceptación formal del riesgo. La orientación canadiense espera evidencia sobre el contexto del servicio, los clientes afectados, los impactos potenciales, los datos de entrada, los algoritmos, el aseguramiento de la calidad y las aprobaciones pertinentes. El EU AI Act exige, para los sistemas de alto riesgo, documentación técnica, instrucciones de uso, capacidad de registro, medidas de supervisión humana y un sistema de gestión de la calidad.
Un paquete de evidencia práctico suele incluir: una declaración breve del caso de uso; descripción del sistema; nivel de riesgo; alcance legal y regulatorio; evaluaciones de impacto de privacidad u otras cuando sean necesarias; diligencia debida con proveedores; registros de pruebas técnicas; diseño de supervisión humana; plan de contingencia y reversión; plan de seguimiento; y una recomendación clara para la siguiente etapa. El objetivo no es el papeleo por sí mismo, sino la calidad de la decisión y su trazabilidad.
Las etapas de piloto son más ligeras, pero siguen siendo etapas
Uno de los fallos de gobernanza más frecuentes es tratar el "piloto" como una zona sin reglas. Las fuentes oficiales apuntan en la dirección contraria. Los pilotos pueden justificar controles más reducidos, pero siguen necesitando condiciones, límites y autorización.
La política federal estadounidense vigente es un buen ejemplo. Permite que programas piloto limitados avancen sin el conjunto completo de prácticas mínimas para IA de alto impacto, pero solo si el piloto es limitado en escala y duración, el Director de IA de la agencia lo certifica, la certificación se registra de forma centralizada y se aplican las prácticas mínimas donde sea factible. Esta es una etapa de piloto clásica: no es una publicación completa en producción, pero sigue siendo una decisión de aprobación documentada con autoridad identificada y límites definidos.
La práctica canadiense muestra una lógica similar desde otro ángulo. La Evaluación de Impacto Algorítmico se realiza al inicio del diseño para que los equipos conozcan qué mitigaciones y consultas aplican durante la implementación. Luego se completa de nuevo antes de la producción, de modo que se aprueba la versión final construida, no solo el concepto inicial. Esto crea una distinción formal entre el trabajo exploratorio y el despliegue en producción.
Una buena etapa de piloto responde claramente a cinco preguntas: qué se está probando, sobre quién o sobre qué datos, durante cuánto tiempo, bajo qué supervisión humana y qué hará que el piloto se detenga. Si esas preguntas no pueden responderse, el piloto probablemente es demasiado vago para aprobarse.
La aprobación de producción es una decisión formal de publicación
El paso de piloto a producción es donde un flujo de aprobación de IA se vuelve más visiblemente regulatorio. Es el punto en que "interesante" se convierte en "en uso", y muchas obligaciones oficiales se activan aquí o poco antes.
Para la gobernanza interna, la aprobación de producción suele significar que las evaluaciones requeridas están completas, los revisores obligatorios han dado el visto bueno o han condicionado la publicación, los problemas sin resolver son visibles y una persona autorizada ha aceptado el riesgo residual. Según la política federal estadounidense vigente para IA de alto impacto, esto incluye pruebas previas al despliegue, una evaluación de impacto de IA, revisión independiente y aceptación formal del riesgo. Según la orientación de la ICO, si una DPIA muestra que el alto riesgo para las personas no puede reducirse suficientemente, la organización debe consultar al regulador antes de iniciar el tratamiento. Según las normas federales canadienses, los resultados finales de la AIA se publican y los sistemas de mayor impacto pueden requerir revisión por pares y mayor participación humana.
Para algunos sistemas, la aprobación de producción es también un paso de conformidad legal. El EU AI Act es el ejemplo más claro. Los proveedores de sistemas de IA de alto riesgo deben operar un sistema de gestión de la calidad documentado, mantener documentación técnica, llevar a cabo la evaluación de la conformidad pertinente antes de comercializar el sistema o ponerlo en servicio, y garantizar la supervisión humana, el registro y el seguimiento poscomercialización. Los desplegadores de sistemas de alto riesgo deben utilizarlos conforme a las instrucciones, asignar supervisión humana competente y supervisar el funcionamiento. Esto ya no es solo una preferencia de gobernanza interna: forma parte del camino legal hacia un despliegue conforme a derecho.
La aprobación no termina con el lanzamiento
Un flujo sólido trata la aprobación de producción como el inicio de un estado operativo supervisado, no como el fin de la gobernanza. Los modelos se degradan. El contexto cambia. Los servicios de terceros se actualizan silenciosamente. Los equipos de negocio amplían el uso más allá del propósito original. Los reguladores publican nuevas orientaciones. Todo eso puede convertir el uso aceptable de ayer en un cambio material de hoy.
Las fuentes oficiales son explícitas en este punto. NIST trata la gobernanza como algo transversal a todo el ciclo de vida, no como un punto de control puntual. El perfil GenAI de NIST subraya la revisión continua, el inventario de terceros, la diligencia debida en la adquisición y el despliegue, los procesos de incidentes y la necesidad de detener el desarrollo o el despliegue cuando el riesgo se vuelve inaceptable. La ICO señala que las organizaciones deben estar preparadas para detener el despliegue si no pueden lograr un equilibrio que cumpla con los requisitos de protección de datos. La orientación canadiense indica que las AIA deben revisarse, aprobarse y actualizarse según un calendario y siempre que cambie la funcionalidad o el alcance. La política federal estadounidense vigente exige reevaluación periódica y seguimiento tras modificaciones significativas. El EU AI Act exige seguimiento poscomercialización e informes de incidentes graves para los sistemas de alto riesgo.
Esto significa que un flujo de aprobación debe conectarse directamente con el seguimiento operativo y el control de cambios. El reentrenamiento material, la expansión de funcionalidades, nuevas fuentes de datos, un nuevo proveedor, un cambio en la población afectada o el paso de un uso asistido a un soporte de decisiones pueden requerir una nueva revisión o una nueva aprobación. Un flujo que termina con el lanzamiento está incompleto.
Ejemplos
Ejemplo actual, administración federal de Canadá. Un departamento que planea utilizar un sistema de toma de decisiones automatizada debe completar la Evaluación de Impacto Algorítmico al inicio de la fase de diseño para identificar el nivel de impacto y los requisitos de mitigación correspondientes. Antes de que el sistema entre en producción, la AIA se completa de nuevo y los resultados finales se publican. El mismo marco exige consulta temprana con las áreas de privacidad y legal, y los proyectos de mayor impacto deben someterse a revisión por pares de expertos cualificados.
Ejemplo actual, IA federal de alto impacto en EE. UU. Según OMB M-25-21, un caso de uso de IA de alto impacto no puede simplemente pasar a uso en producción por decisión de un responsable. Antes del despliegue, las agencias deben completar pruebas previas al despliegue, documentar una evaluación de impacto de IA, obtener revisión independiente y registrar la aceptación formal del riesgo. Los programas piloto pueden seguir un camino más reducido, pero solo si están limitados en escala y duración y el CAIO de la agencia certifica que el piloto puede avanzar.
Ejemplo actual, sistema de IA de alto riesgo en la UE. Un proveedor que comercializa un sistema de IA de alto riesgo en el mercado de la UE debe contar con el sistema de gestión de la calidad y la documentación técnica requeridos, completar la evaluación de la conformidad pertinente y garantizar la supervisión humana, el registro y el seguimiento poscomercialización. El desplegador tiene, a su vez, sus propias obligaciones: utilizar el sistema conforme a las instrucciones, asignar supervisión humana competente y supervisar el uso. Como punto de implementación actual, el calendario de la UE para algunas obligaciones de alto riesgo está siendo reformulado a través del proceso AI Omnibus, por lo que las organizaciones deben consultar el material más reciente de la Comisión antes de fijar fechas de entrega.
Malentendidos frecuentes
"Flujo de aprobación" significa simplemente la firma del área legal. No es así. La revisión legal es un insumo de una etapa. El flujo completo suele requerir también privacidad, seguridad, contratación, pruebas técnicas, revisión del dominio y una decisión de riesgo autorizada.
Si una persona permanece "en el circuito", el sistema es automáticamente de bajo riesgo. No necesariamente. Las orientaciones oficiales consideran algunos usos de IA como de alto impacto incluso cuando los humanos permanecen involucrados, porque el problema real es el efecto sobre derechos, seguridad o decisiones importantes.
La IA comprada es problema del proveedor. No lo es. Las organizaciones siguen necesitando su propia diligencia debida y evaluación independiente de las herramientas de terceros, especialmente cuando están en juego la protección de datos, la dependencia del proveedor, los términos contractuales, el registro, el acceso a pruebas o las obligaciones sectoriales.
La aprobación ocurre una sola vez, en el lanzamiento. No debería ser así. Los cambios materiales en los datos, el comportamiento del modelo, los acuerdos con proveedores, el contexto de uso o la población afectada pueden activar una reevaluación, pruebas adicionales o una nueva aprobación.
Más capas de comités siempre significan mejor gobernanza. A menudo no es así. El objetivo es una aprobación proporcionada y basada en evidencia. Un control insuficiente crea puntos ciegos, pero demasiado teatro genera retrasos sin mejorar el juicio.
Riesgos y límites
Un flujo de aprobación de IA es un mecanismo de gobernanza, no un término legal universal con una plantilla obligatoria única. Las distintas organizaciones lo implementarán de forma diferente, y las leyes sectoriales pueden añadir pasos adicionales. Un hospital, un banco, una autoridad pública y una empresa de software no deberían utilizar exactamente el mismo diseño de etapas.
También debe ser proporcionado. Aplicar el proceso completo de producción a cada prueba interna de bajo riesgo desperdicia tiempo y lleva a las personas a eludir el proceso. Pero utilizar un flujo ligero para sistemas que afectan derechos, seguridad, elegibilidad, empleo o decisiones reguladas es igualmente peligroso. El arte está en establecer umbrales claros y dirigir cada caso al camino adecuado.
Otro límite es que la firma de aprobación por sí sola no hace que un sistema sea legal ni fiable. Si la evidencia es débil, si la organización no puede evaluar adecuadamente una herramienta de terceros, o si los riesgos graves no pueden reducirse, la decisión correcta puede ser pausar, rediseñar, restringir el piloto o detener el uso por completo.
También existe cierta incertidumbre vigente en el entorno regulatorio. El EU AI Act está en vigor, pero el proceso de simplificación de la Comisión para 2025-2026 está reformulando las fechas de algunas obligaciones de alto riesgo. Las orientaciones en otras jurisdicciones también evolucionan. Esto significa que la estructura del flujo puede mantenerse estable, pero los puntos de activación, los artefactos requeridos y los plazos deben revisarse periódicamente.
Qué hacer a continuación
Establecer primero la autoridad de aprobación. Identificar quién puede clasificar un caso de uso, quién puede aprobar un piloto y quién puede aceptar el riesgo residual para la producción.
Crear dos o tres niveles de riesgo, no diez. Los equipos necesitan una regla de clasificación inicial utilizable que distinga la experimentación de bajo riesgo del despliegue de mayor riesgo.
Estandarizar el paquete de evidencia de cada etapa. Como mínimo, exigir propósito, nivel de riesgo, descripción de datos y proveedores, evaluaciones requeridas, registro de pruebas, plan de supervisión humana, plan de seguimiento y registro de la decisión final.
Integrar los pilotos en el mismo flujo, no como una vía de escape. Todo piloto debe tener un patrocinador, un límite de alcance, una fecha de finalización y criterios de parada.
Vincular la aprobación con la gestión del cambio y el seguimiento. Si el modelo, los datos, el proveedor, el contexto de decisión o el grupo afectado cambian de forma material, el flujo debe reabrirse automáticamente.
Por último, mantener el registro de auditoría simple pero completo. Si no es posible demostrar posteriormente qué se revisó, quién decidió y por qué, el flujo de aprobación es más débil de lo que parece.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Un flujo de aprobación de IA es solo para sistemas de alto riesgo?
No. La mayoría de las organizaciones deberían utilizar caminos más ligeros y más exigentes según el caso. La IA de menor riesgo puede avanzar por una ruta más corta, mientras que los sistemas que afectan derechos, seguridad, decisiones reguladas o datos sensibles necesitan una revisión más profunda.
¿Quién debería dar la aprobación final de un sistema de IA?
La aprobación final debe recaer en un responsable senior autorizado que pueda aceptar el riesgo en nombre de la organización. Esa decisión debe estar respaldada por revisiones legales, de privacidad, seguridad, contratación, técnicas y del dominio, y no ser tomada por una sola función.
¿Cuándo debe comenzar el flujo?
Tan pronto como en la etapa de concepto o diseño, antes de que se fijen compromisos importantes de contratación, desarrollo o integración. La clasificación temprana evita que los equipos descubran tarde en el proceso que eligieron los datos, la herramienta o el modelo operativo equivocados.
¿Una evaluación de impacto de IA es lo mismo que un flujo de aprobación?
No. Una evaluación de impacto es un artefacto importante dentro del flujo. El flujo es más amplio: determina cuándo se requiere una evaluación, quién la revisa, qué otra evidencia es necesaria y quién toma la decisión final.
¿Puede un piloto entrar en producción antes de que todos los controles de producción estén completos?
A veces sí, pero solo bajo un camino de piloto definido con límites, salvaguardas y autoridad identificada. Un piloto debe tener un alcance reducido, una duración clara, seguimiento y una regla de salida. Nunca debe tratarse como un espacio libre de gobernanza.
¿Seguimos necesitando aprobación si compramos una herramienta de IA de terceros reconocida?
Sí. La reputación externa no elimina la responsabilidad propia. Sigue siendo necesario evaluar el contexto de uso, los contratos, la privacidad, la seguridad, el acceso a pruebas, el registro, los cambios de proveedor y si la herramienta se ajusta a las obligaciones legales aplicables.
¿Qué debería activar una nueva aprobación?
Cualquier cambio material en el modelo, los datos de entrenamiento o entrada, el proveedor, el propósito previsto, el grupo de usuarios, el diseño de supervisión humana, la relevancia de la decisión o el contexto de despliegue. Los incidentes graves, los problemas de rendimiento reiterados o las nuevas orientaciones regulatorias también pueden activar una nueva revisión.