Gobernanza de IA en empresa: comités, políticas, auditorías
Actualizado: 2026-05-03
La gobernanza de la IA en empresa dejó de ser un ejercicio académico cuando entraron en vigor las primeras disposiciones del AI Act europeo: la prohibición de determinadas prácticas (puntuación social, manipulación subliminal, categorización biométrica sensible) y la obligación de que el personal que usa IA alcance un nivel mínimo de alfabetización. Las sanciones por prácticas prohibidas pueden llegar al 7 por ciento de la facturación global anual, lo que concentra la atención incluso de los consejos más distraídos.
Este texto comparte lo que funciona al montar o acompañar la gobernanza de IA en varias organizaciones. No es un análisis legal del AI Act, sino una guía práctica sobre cómo se organiza el trabajo real: comité, políticas, inventario, evaluación de riesgo, auditorías.
Puntos clave
- El comité de IA funciona mejor con cinco a siete personas que deciden, no con quince en rol consultivo.
- La política de uso debe separar tres capas: herramientas aprobadas, casos permitidos y obligaciones transversales.
- Sin inventario de sistemas vivo no hay gobernanza posible; el registro nace de procesos, no de trabajo manual.
- Una evaluación de riesgo en cinco dimensiones orienta el nivel de controles para cada sistema.
- Las auditorías internas bien hechas construyen capacidad; las externas validan para clientes y reguladores.
El comité de IA y a quién debe incluir
El error más frecuente es montar un comité de IA solo con perfiles técnicos. La gobernanza trata aspectos que van más allá de lo técnico: impacto en personas, cumplimiento legal, reputación, coste. Un comité útil combina cuatro sensibilidades:
- Técnica (ingeniería, datos, seguridad).
- Legal y cumplimiento.
- Negocio y riesgos.
- Ética o recursos humanos que represente al empleado o cliente afectado.
El tamaño ideal es pequeño: cinco a siete personas con capacidad de decidir, no quince con rol consultivo. La cadencia que funciona es reunión mensual con lectura previa, y sesiones extraordinarias cuando aparece un caso urgente. El comité debe tener un mandato escrito que aclare qué decide por sí mismo, qué eleva al comité de dirección y qué es competencia operativa.
Una pregunta que conviene resolver pronto es dónde cuelga organizativamente. Los tres patrones habituales son:
- Dependiendo del CIO o CTO.
- Del CDO o responsable de datos.
- Del director de cumplimiento.
Lo que sí es pernicioso es que dependa funcionalmente del área que más casos de IA propone, porque crea conflicto de intereses estructural. Más sobre el contexto regulador en nuestra guía de cumplimiento de la Ley de IA europea.
Política de uso aceptable, no solo política de seguridad
La política de uso de IA debe cubrir cosas que la política de seguridad informática tradicional no cubre. Conviene separar tres capas:
- Capa de herramientas aprobadas: qué productos concretos se pueden usar, con qué cuenta corporativa y bajo qué licencia.
- Capa de casos de uso permitidos: redacción de correos, asistencia en programación, resúmenes y traducción; diferenciados de los que requieren autorización expresa (análisis de datos de cliente, decisiones sobre personas, contacto con cliente final).
- Capa de obligaciones transversales: marcar contenido generado, conservar evidencia, no cargar secretos en prompts.
Una tentación a evitar es escribir una política larguísima que nadie va a leer. Es mejor una política corta, legible en veinte minutos, acompañada de ejemplos concretos por área funcional. La alfabetización que exige el AI Act se cumple mejor con talleres y casos reales que con un PDF de cincuenta páginas enterrado en la intranet.
Inventario de sistemas: la base invisible
Sin inventario de sistemas de IA no hay gobernanza posible. En la mayoría de organizaciones el inventario no existe o está desactualizado. El AI Act obliga a registrar los sistemas de alto riesgo, pero para gobernanza útil hace falta registrar todos.
Los campos mínimos de un registro utilizable son:
- Nombre del sistema y área que lo opera.
- Caso de uso.
- Modelos subyacentes y proveedores.
- Datos de entrenamiento o fine-tuning si los hay.
- Datos de inferencia a los que accede.
- Destinatarios de las salidas.
- Clasificación de riesgo propia.
- Fecha de última revisión y persona responsable.
Con ese registro se pueden responder preguntas importantes: qué sistemas toman decisiones sobre personas, cuáles envían datos personales a terceros, cuáles quedarán cubiertos por las obligaciones de alto riesgo cuando entren en vigor.
Lo difícil del inventario es mantenerlo vivo. La recomendación es integrarlo en el ciclo de compra y el ciclo de cambios: cualquier software nuevo con componente de IA pasa por un formulario que actualiza el inventario, y cualquier cambio significativo se refleja en su ficha. El inventario no es un archivo que alguien mantiene a mano; es la consecuencia de procesos operativos bien definidos.
Evaluación de riesgo y escalado
El AI Act clasifica los sistemas en cuatro niveles: riesgo inaceptable (prohibidos), alto riesgo, riesgo limitado (obligación de transparencia) y riesgo mínimo. Un marco que funciona evalúa cinco dimensiones para cada sistema:
- Impacto en derechos de personas (empleados, clientes, terceros).
- Sensibilidad de los datos que procesa.
- Grado de autonomía de las decisiones (puramente asistiva vs. decidiendo sin humano).
- Reversibilidad de los efectos (fácil de deshacer vs. decisiones de contratación o crédito).
- Dependencia de proveedor externo y riesgos asociados (bloqueo contractual, continuidad, acceso a datos).
La puntuación combinada orienta el nivel de controles exigido:
- Riesgo bajo: se autogestiona con la política general.
- Riesgo medio: propietario formal, plan de monitorización y revisión anual.
- Riesgo alto: evaluación del comité, evaluación de impacto detallada, controles técnicos de trazabilidad y supervisión humana, revisión semestral.
Para equipos de seguridad que integran estas evaluaciones con el stack técnico, el artículo sobre integración de Zero Trust con SIEM ofrece contexto complementario útil.
Auditorías: internas primero, externas después
Las auditorías de IA tienen dos ángulos complementarios:
- Cumplimiento: verifica que los sistemas se ajustan a políticas y regulación (consentimientos obtenidos, datos retenidos solo el tiempo previsto, decisiones documentadas, accesos limitados).
- Calidad: verifica que los sistemas funcionan como se espera (tasa de error, equidad entre grupos demográficos, deriva del modelo, explicabilidad suficiente).
El consejo es empezar por auditorías internas bien hechas antes de contratar auditores externos. El equipo interno conoce los sistemas y tiene acceso a datos que un tercero tarda en obtener. Las auditorías internas construyen capacidad organizativa y detectan problemas antes. Las externas son útiles cuando se necesita validación independiente para clientes, reguladores o certificaciones, pero no deben ser el primer paso.
Una práctica que vale la pena adoptar es la autoauditoría trimestral basada en una lista corta de comprobaciones. Para cada sistema de riesgo medio o alto, diez o quince preguntas respondidas con evidencia: ¿se está ejecutando la revisión humana prevista? ¿se conservan los logs acordados? ¿hay incidentes sin documentar? ¿está el responsable actualizado?
Mi lectura
La gobernanza de IA en empresa determina si la organización puede sostener el uso de IA en los próximos años sin sustos. El AI Act marca un suelo de cumplimiento, pero la razón profunda para hacer esto bien no es la multa: es que las organizaciones sin inventario, política y comité se enterarán tarde de los problemas que ya están ocurriendo dentro de sus flujos.
La gobernanza no debe ser un freno al uso de IA, sino un habilitador: cuando las reglas están claras, los equipos se atreven a probar más cosas porque saben dónde pueden moverse. Las organizaciones que la usan para prohibirlo todo terminan con una IA-sombra (gente usando ChatGPT desde el móvil personal) que es peor de todos los mundos. Las que la usan para habilitar con criterio avanzan más rápido que las que no la tienen en absoluto.
