Plantilla de política de gobernanza de IA para equipos empresariales
Una plantilla completa de política de gobernanza de IA que cubre inventario de modelos, niveles de riesgo, requisitos de supervisión humana, gestión de proveedores y respuesta a incidentes. Adáptala para tu organización.
Una política escrita de gobernanza de IA ya no es opcional para organizaciones empresariales. El EU AI Act requiere procesos de gobernanza documentados para sistemas de alto riesgo. Los aseguradores de ciberseguridad están empezando a pedirla como condición de cobertura. Las juntas directivas la están solicitando tras las fallas de IA de alto perfil en organizaciones similares. Legal la está pidiendo porque el riesgo regulatorio ahora es una preocupación a nivel de junta directiva, no solo de TI.
Esta plantilla cubre cada sección esencial. El texto de la política a continuación está diseñado para ser adaptado — completa los campos entre corchetes con los datos específicos de tu organización, ajusta los umbrales de riesgo para que coincidan con tu industria y contexto regulatorio, y haz que legal lo revise antes de publicarlo internamente.
Cómo usar esta plantilla
No intentes implementar cada sección simultáneamente. Comienza con las Secciones 3 y 4 — clasificación de riesgos e inventario de modelos. Esas dos secciones te dan una base que todo lo demás referencia. Luego construye la estructura de gobernanza (Sección 2) y los requisitos de supervisión humana (Sección 5). Las Secciones 6 a 10 pueden seguir a medida que tu programa madura.
POLÍTICA ORGANIZACIONAL DE GOBERNANZA DE IA
ID del Documento: [POLICY-AI-001] Versión: [1.0] Fecha de vigencia: [FECHA] Próxima fecha de revisión: [FECHA + 1 AÑO] Propietario de la política: [Oficial de Riesgo de IA / CTO / CISO] Aprobado por: [Junta Directiva / Comité Ejecutivo]
Sección 1: Alcance y definiciones
1.1 Alcance
Esta política aplica a todos los sistemas de IA operados por [Nombre de la Organización], incluyendo:
- Sistemas de IA desarrollados internamente
- Sistemas de IA adquiridos de proveedores externos o accedidos vía API
- Capacidades de IA integradas en productos de software de terceros usados por la organización
- Sistemas de IA operados por contratistas o socios en nombre de la organización
Esta política cubre cualquier sistema que use machine learning, modelos de lenguaje grandes, o lógica de toma de decisiones automatizada que afecte resultados de negocio, interacciones con clientes, decisiones sobre empleados u obligaciones de cumplimiento.
1.2 Definiciones
| Término | Definición |
|---|---|
| Sistema de IA | Cualquier sistema de software que use machine learning, modelado estadístico o automatización basada en reglas para producir salidas (predicciones, clasificaciones, contenido generado, decisiones) que influyan en decisiones organizacionales o resultados para clientes |
| IA de alto riesgo | Un sistema de IA que opera en un contexto donde los errores podrían causar daño significativo a individuos, crear responsabilidad legal o activar acciones regulatorias. Ver Sección 3 para criterios de clasificación. |
| Modelo | El artefacto entrenado en el núcleo de un sistema de IA — los pesos y parámetros que producen salidas a partir de entradas. Distinto de la aplicación construida alrededor de él. |
| Humano en el loop (HITL) | Una configuración de supervisión donde un humano revisa y aprueba cada salida de IA antes de que se tome cualquier acción consecuente |
| Humano sobre el loop (HOTL) | Una configuración de supervisión donde la IA opera autónomamente pero un humano monitorea las salidas y tiene autoridad de anulación definida |
| Humano fuera del loop (HOOTL) | Una configuración automatizada sin revisión humana de salidas individuales; los humanos revisan solo métricas de rendimiento agregadas |
| Rastro de auditoría | Un registro inmutable, con marcas de tiempo, de entradas, salidas, pasos de procesamiento, decisiones de revisión humana y cambios del sistema de IA |
| Inventario de modelos | El registro formal de la organización de todos los sistemas de IA en operación, como se define en la Sección 4 |
Sección 2: Estructura de gobernanza
2.1 Comité de gobernanza de IA
El Comité de Gobernanza de IA (CGA) es el órgano principal de toma de decisiones para política de IA, tolerancia al riesgo y decisiones escaladas.
- Composición: Director de Tecnología, Director de Riesgos, Director Legal, Director de Seguridad de la Información y representante rotativo de unidad de negocio
- Frecuencia de reuniones: Reuniones regulares trimestrales; ad hoc para incidentes P0/P1 o decisiones de política materiales
- Autoridad de decisión: Aprueba despliegues de sistemas de IA de alto riesgo; establece umbrales de tolerancia al riesgo; aprueba cambios de política; revisa informes de incidentes para eventos P0 y P1
2.2 Propietario del sistema de IA
Cada sistema de IA en el inventario de modelos debe tener un propietario de sistema de IA nombrado.
- Responsabilidades: Mantener la entrada de inventario precisa; asegurar que la validación se complete según el calendario; responder a incidentes dentro de los SLAs definidos; asegurar que la supervisión humana se implemente como se especifica; escalar al CGA cuando cambie el nivel de riesgo o el alcance
- Asignación: Los propietarios del sistema de IA se asignan en el momento del registro en el inventario de modelos y deben ser aprobados por el jefe de la unidad de negocio relevante
2.3 Oficial de riesgo de IA
El oficial de riesgo de IA tiene la responsabilidad a nivel empresarial de la efectividad del programa de gobernanza de IA.
- Responsabilidades: Mantener la política de gobernanza de IA; supervisar el inventario de modelos; reportar al CGA trimestralmente sobre el estado del programa; coordinar con auditores externos y reguladores; monitorear cambios regulatorios y actualizar la política dentro de 30 días de cambios materiales
Sección 3: Clasificación de riesgo de IA
Todos los sistemas de IA deben clasificarse en uno de tres niveles de riesgo al momento del registro en el inventario de modelos. El propietario del sistema de IA propone el nivel; el oficial de riesgo de IA confirma o ajusta.
Nivel 1 — Alto riesgo
Sistemas que afectan el acceso de individuos a servicios, oportunidades de empleo, resultados de salud, estatus legal, productos financieros u oportunidades educativas. También incluye cualquier sistema clasificado como alto riesgo bajo el Anexo III del EU AI Act o como modelo bajo SR 11-7 en un contexto financiero regulado.
Ejemplos: evaluación de elegibilidad de préstamos, puntuación de rendimiento de empleados, soporte de triaje médico, revisión de contratos con recomendaciones a nivel individual, detección de fraude con consecuencias a nivel de cuenta.
Controles requeridos:
- Supervisión humano en el loop (HITL) — aprobación humana antes de cualquier acción consecuente
- Rastro de auditoría completo (inmutable, con marcas de tiempo, retención mínima de [X] años)
- Validación trimestral
- Tarjeta del modelo documentada
- Registro en el inventario de modelos antes del despliegue
Nivel 2 — Riesgo medio
Herramientas de productividad internas, generación de contenido para uso interno, dashboards de analítica sin consecuencias a nivel individual, y herramientas dirigidas al cliente que producen recomendaciones en vez de decisiones.
Ejemplos: resumen de documentos internos, dashboards de pronóstico de ventas, chatbot de soporte al cliente (con ruta de escalamiento humano), transcripción y resumen de reuniones.
Controles requeridos:
- Supervisión humano sobre el loop (HOTL) con proceso de anulación definido
- Registro de incidentes
- Revisión de validación semestral
- Registro en el inventario de modelos dentro de [X] días del despliegue
Nivel 3 — Bajo riesgo
Sistemas sin impacto individual directo, alta tolerancia a errores y sin alcance regulatorio.
Ejemplos: filtros de spam, sugerencias de autocompletado, recomendaciones de etiquetas de contenido, ranking de búsqueda interna.
Controles requeridos:
- Registro básico de entradas/salidas
- Revisión anual
- Registro en el inventario de modelos dentro de [X] días del despliegue
Escalamiento de nivel: Si un sistema de Nivel 2 o Nivel 3 se modifica para afectar resultados a nivel individual, o si sus salidas se usan para alimentar una decisión de Nivel 1, debe ser reclasificado. El propietario del sistema de IA es responsable de identificar y reportar los desencadenantes de escalamiento de nivel.
Sección 4: Requisitos del inventario de modelos
4.1 Requisito de registro
Todos los sistemas de IA deben registrarse en el inventario de modelos de [Nombre de la Organización]:
- Sistemas de Nivel 1: antes del despliegue en producción
- Sistemas de Nivel 2: dentro de [10] días hábiles del despliegue
- Sistemas de Nivel 3: dentro de [30] días hábiles del despliegue
La IA en las sombras (sistemas desplegados fuera del proceso formal de adquisición de TI) debe reportarse y registrarse dentro de [30] días de su descubrimiento. Los propietarios de sistemas de IA y los jefes de unidad de negocio son conjuntamente responsables de identificar y reportar la IA en las sombras.
4.2 Campos requeridos del inventario
Consulta la Plantilla de inventario de modelos de IA para la especificación completa de campos y un ejemplo completado. Como mínimo, cada entrada de inventario debe incluir: ID del modelo, nombre del modelo, versión, tipo, proveedor/fuente, entorno de despliegue, propósito de negocio, nivel de riesgo, propietario, estado de validación, fecha de última validación, próxima fecha de revisión, alcance regulatorio, nivel de supervisión humana y enlace al registro de incidentes.
4.3 Cadencia de revisión
| Nivel de riesgo | Cadencia mínima de revisión |
|---|---|
| Nivel 1 (Alto riesgo) | Trimestral |
| Nivel 2 (Riesgo medio) | Semestral |
| Nivel 3 (Bajo riesgo) | Anual |
| Cualquier nivel (post-incidente) | Dentro de 5 días hábiles del cierre del incidente |
Sección 5: Requisitos de supervisión humana
Los requisitos de supervisión humana se determinan por nivel de riesgo y se implementan usando la Hoja de trabajo de diseño de flujo HITL antes del despliegue.
Sistemas de Nivel 1: Se requiere aprobación humana antes de cualquier acción que afecte a un individuo. Los revisores deben tener acceso a: la salida de la IA, las entradas que la produjeron, la versión del modelo y el contexto de política relevante. Los SLAs de revisión deben definirse y monitorearse. Las tasas de anulación deben rastrearse.
Sistemas de Nivel 2: Se requiere monitoreo humano con un proceso de anulación definido. El monitoreo incluye: muestreo regular de salidas, alertas automatizadas para patrones de salida anómalos y una ruta documentada de escalamiento para preocupaciones identificadas por el revisor.
Sistemas de Nivel 3: Se permite la operación automatizada con registro de salidas y monitoreo de rendimiento agregado. Si las salidas de Nivel 3 se usan como entradas para sistemas de Nivel 1 o Nivel 2, todo el pipeline se trata como Nivel 1 para propósitos de supervisión.
Prevención del sesgo de automatización: Todos los sistemas con revisión humana deben implementar revisión retrospectiva aleatorizada de decisiones auto-aprobadas. Tasa mínima de revisión retrospectiva: [5]%. Desviaciones de la tasa de anulación mayores al [20]% de la línea base activan una revisión de la configuración de umbrales.
Sección 6: Gestión de proveedores
6.1 Evaluación previa al despliegue
Todos los proveedores de IA deben evaluarse usando la Tarjeta de evaluación de proveedores de IA antes de desplegar cualquier sistema de IA usando su tecnología. Esto incluye: proveedores de API comerciales, IA integrada en productos SaaS y modelos de fundación open-source donde existe una relación con el proveedor.
Puntuación total mínima aceptable en la tarjeta: 3.0 general. Ningún sistema de Nivel 1 de misión crítica puede depender de un proveedor con puntuación inferior a 3.0 en Dimensión 2 (Auditoría y registro) o Dimensión 4 (Gobernanza de datos).
6.2 Evaluación continua
Se requiere re-evaluación anual para todos los proveedores activos. Los siguientes eventos activan re-evaluación inmediata fuera del ciclo anual:
- Adquisición del proveedor o cambio de control
- Cambios materiales en los términos de gobernanza de datos del proveedor
- Actualizaciones de modelo del proveedor que afecten un sistema de Nivel 1
- Cualquier acción regulatoria que involucre al proveedor
6.3 Requisitos contractuales
Antes de desplegar cualquier sistema de IA de Nivel 1 usando un modelo de proveedor, lo siguiente debe confirmarse por escrito:
- Acuerdo de procesamiento de datos o equivalente confirmando los términos de manejo de datos
- Confirmación de que los datos de la organización no se usan para entrenamiento de modelos (u opt-out explícito)
- Disponibilidad de fijación de versión y compromisos de notificación de cambios
- Capacidad de exportación de registros que cumpla los requisitos de retención de la organización
Sección 7: Gobernanza de datos
Los datos de entrenamiento y los datos en tiempo de inferencia usados con sistemas de IA deben cumplir con la política de clasificación de datos de la organización.
- PHI (información de salud protegida) y PII (información personal identificable): requieren aprobación explícita de procesamiento de IA del oficial de privacidad antes de usarse en cualquier sistema de IA (entrenamiento o inferencia)
- Datos privilegiados (legales, financieros, secretos comerciales): requieren aprobación del jefe de la función relevante y de Legal antes de usarse en cualquier sistema de IA
- Datos de terceros: deben revisarse los términos de licencia que permitan el uso de IA antes de incluirlos en datasets de entrenamiento o pipelines de inferencia
Ningún dato personal puede enviarse a un proveedor de IA de terceros sin un acuerdo de procesamiento de datos aprobado que confirme las obligaciones de manejo del proveedor.
Sección 8: Rastro de auditoría y registro
Sistemas de Nivel 1: Todas las entradas, salidas, versión del modelo, marca de tiempo y decisiones de revisión humana deben registrarse para cada inferencia. Los registros deben ser inmutables (a prueba de manipulación), con marcas de tiempo en UTC y almacenados por un mínimo de [X años según la regulación aplicable].
Sistemas de Nivel 2: Todas las entradas, salidas, versión del modelo y marca de tiempo deben registrarse. Las decisiones de revisión humana deben registrarse para cualquier caso que haya recibido revisión humana. Retención mínima: [X años].
Sistemas de Nivel 3: Las métricas de rendimiento agregadas deben registrarse. Retención mínima: [1 año].
El acceso a los registros está restringido a personal autorizado. Los registros deben estar disponibles para el oficial de riesgo de IA, auditoría interna y reguladores autorizados bajo solicitud. La infraestructura de registros debe incluir protección contra pérdida accidental.
Sección 9: Respuesta a incidentes
Un incidente de IA es cualquier evento en el que un sistema de IA produce una salida que causa o contribuye a daño no intencionado a un individuo, una brecha regulatoria, una pérdida financiera significativa o un riesgo reputacional material.
9.1 Niveles de severidad
| Severidad | Definición | SLA de respuesta inicial |
|---|---|---|
| P0 — Crítico | Daño físico; pérdida financiera mayor a $[100K]; brecha regulatoria; más de 1,000 individuos afectados | Notificar al oficial de riesgo de IA dentro de 1 hora |
| P1 — Alto | Errores sistemáticos para un grupo definido; brecha de cumplimiento descubierta; riesgo reputacional si se hace público | Notificar al oficial de riesgo de IA dentro de 4 horas |
| P2 — Medio | Salidas incorrectas para un subconjunto de entradas; sin daño inmediato | Notificar al propietario del sistema de IA dentro de 24 horas |
| P3 — Bajo | Degradación de calidad; sin daño individual; sin implicación de cumplimiento | Registrar y revisar dentro de [5] días hábiles |
9.2 Proceso de respuesta
Sigue el Playbook de respuesta a incidentes de IA para todos los incidentes P0 y P1. Pasos clave: preservar evidencia antes de la remediación; confirmar alcance antes de la contención; notificar a Legal y Cumplimiento para P0/P1; realizar revisión post-incidente dentro de [10] días hábiles.
9.3 Requisitos de notificación
- Notificación a junta/ejecutivos: P0 dentro de 24 horas
- Notificación regulatoria: según la regulación aplicable (EU AI Act, GDPR Artículo 33, Regla de notificación de brechas HIPAA)
- Notificación individual: si individuos fueron afectados por decisiones incorrectas de IA, Legal asesorará sobre las obligaciones de notificación
Sección 10: Revisión y actualizaciones de la política
Esta política es revisada anualmente por el oficial de riesgo de IA y aprobada por el Comité de Gobernanza de IA.
El oficial de riesgo de IA actualizará esta política dentro de 30 días de cualquiera de los siguientes:
- Cambio material en la regulación aplicable (actos de implementación del EU AI Act, actualizaciones de guía SR 11-7, revisiones del NIST AI RMF)
- Incidente P0 con hallazgos que requieran respuesta a nivel de política
- Dirección de la junta directiva o ejecutivos
- Cambio material en el perfil de uso de IA de la organización (nuevo caso de uso de alto riesgo, nuevo mercado regulado)
Todas las actualizaciones de política tienen control de versiones. Las versiones anteriores se retienen por [5] años.
Guía de implementación
La falla de implementación más común es intentar construir todo el programa de gobernanza de una vez. Comienza aquí:
Mes 1: Implementa la Sección 3 (clasificación de riesgos). Clasifica cada sistema de IA actualmente en producción. Esto hace visible tus sistemas de Nivel 1 y te dice dónde están las brechas de mayor urgencia.
Mes 2: Implementa la Sección 4 (inventario de modelos). Registra cada sistema. Acepta que tu primer inventario será incompleto — el proceso de construirlo hará visible la IA en las sombras que no sabías que existía.
Mes 3: Implementa la Sección 2 (estructura de gobernanza). Asigna propietarios de sistema de IA a cada sistema registrado. Convoca el Comité de Gobernanza de IA por primera vez. Revisa los sistemas de Nivel 1 y confirma que los controles de supervisión están en su lugar.
Meses 4-6: Implementa las Secciones 5-8 (supervisión, gestión de proveedores, gobernanza de datos, registro). Estas se construyen sobre la base que los primeros tres meses establecieron.
El rastro de auditoría integrado y el registro de operadores de Ertas Data Suite satisfacen directamente los requisitos de las Secciones 4 y 8 — cada transformación de datos se registra con marca de tiempo e ID del operador, generando los registros de auditoría inmutables que esta política requiere sin herramientas adicionales.
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading
AI Model Governance in Production: The Complete Enterprise Guide
Model governance isn't a compliance checkbox — it's the operational framework that determines whether your AI is accountable, auditable, and correctable. Here's what it actually requires.
AI in High-Stakes Environments: What Responsible Deployment Actually Requires
High-stakes AI isn't just about better models — it's about accountability, oversight, and the infrastructure to catch and correct failures before they cause harm.
The EU AI Act's High-Risk System Requirements: What They Demand and What They Don't Tell You
The EU AI Act's Annex III defines high-risk AI categories. If you're deploying in healthcare, legal, finance, or HR, you're almost certainly in scope. Here's what compliance actually requires.