Las empresas suelen responder a la llegada de la IA con una carta de unas pocas páginas: no compartir datos confidenciales, verificar los resultados y respetar la ley. Estas reglas son necesarias, pero no permiten saber qué sistemas se utilizan, quién decide, qué versiones están en producción ni si los riesgos se supervisan realmente.
Por el contrario, un programa demasiado pesado empuja a los equipos a eludir el proceso. La gobernanza debe ser, por lo tanto, proporcional: ligera para un asistente de redacción sin datos sensibles, exigente para un agente conectado al sistema de información o una decisión que afecte a personas.
La gobernanza debe adaptarse al contexto de la organización y acercarse a sus obligaciones legales, contractuales, sectoriales y de seguridad.
La gobernanza no es un comité
Un comité puede arbitrar, pero no constituye por sí solo un sistema de gestión. Una gobernanza operativa responde permanentemente a seis preguntas:
- qué sistemas existen;
- quién es responsable;
- qué usos están autorizados;
- qué pruebas respaldan la decisión;
- qué cambios han ocurrido;
- cuándo se debe reevaluar o detener.
Se integra en los procesos ya existentes: compra, seguridad, protección de datos, arquitectura, desarrollo, control interno, recursos humanos y gestión de incidentes.
Definir un perímetro claro
El término «sistema de IA» debe traducirse al lenguaje de la empresa. El registro puede incluir:
- modelos desarrollados internamente;
- API externas;
- funciones de IA de un SaaS;
- RAG documentales;
- agentes y automatizaciones;
- herramientas de generación de contenidos;
- asistentes de desarrollo;
- modelos integrados;
- experimentos utilizando datos reales.
Un simple motor de reglas no necesariamente necesita el mismo circuito. El objetivo no es inflar artificialmente el registro, sino cubrir los sistemas cuyo comportamiento, los datos o la autonomía crean un riesgo particular.
Escribir una política que ayude a decidir
Una política útil se basa en algunos principios comprensibles, complementados por procedimientos. Ella especifica:
- los usos libremente autorizados;
- las herramientas aprobadas;
- los datos prohibidos o condicionales;
- los usos que requieren revisión;
- las decisiones que siguen siendo humanas;
- las reglas de transparencia;
- la propiedad de los contenidos y del código;
- los requisitos de seguridad;
- la notificación de errores e incidentes;
- las sanciones o medidas en caso de elusión voluntaria.
Los ejemplos concretos son más útiles que una fórmula general. « No enviar datos personales » a menudo es impracticable. Es mejor distinguir datos públicos, internos, confidenciales, secretos, datos personales comunes y datos sensibles, y luego asociar a cada nivel los entornos autorizados.
El registro mínimo viable
El registro comienza con un número limitado de campos obligatorios:
- identificador y nombre;
- descripción del propósito;
- propietario del negocio;
- propietario técnico;
- estado del ciclo de vida;
- usuarios y personas afectadas;
- proveedor, modelo y versión;
- datos utilizados;
- sistemas conectados;
- nivel de autonomía;
- principales riesgos;
- evaluaciones disponibles;
- decisión y condiciones;
- fecha de la próxima revisión.
Debe aceptar la incertidumbre. Un valor « versión desconocida » es preferible a un campo vacío, ya que desencadena una acción. La calidad del registro se mide por su capacidad para revelar lo desconocido y no por su apariencia perfecta.
Modelo de datos de un registro de IA que vincula casos de uso, responsables, versiones, datos, evaluaciones, decisiones e incidentes.
Clasificar los usos por nivel de control
Una clasificación interna simple facilita la proporcionalidad.
Nivel 1: asistencia sin datos sensibles
Redacción, traducción o ideación a partir de contenido público, sin decisión significativa. Controles: herramienta aprobada, formación, revisión humana y reglas de propiedad.
Nivel 2: datos internos o recomendación empresarial
Resumen de documentos internos, ayuda al análisis o investigación aumentada. Controles adicionales: contrato, acceso, retención, evaluación, fuentes y seguimiento de errores.
Nivel 3: acción o impacto importante
Agente conectado, automatización de un proceso, recomendación que influye en una persona o uso de datos sensibles. Controles reforzados: análisis de impacto, seguridad, aprobación, supervisión, registros, recursos, pruebas adversas y plan de incidentes.
Nivel 4: uso prohibido, regulado o crítico
El proyecto está bloqueado hasta la calificación por los roles competentes y la implementación de los requisitos específicos.
Esta escala interna no reemplaza las clasificaciones legales. Sirve para orientar el proceso.
Poner en marcha puertas de decisión
El ciclo de vida comprende como mínimo cuatro etapas.
Idea hacia experimentación
Verificar finalidad, propietario, herramienta, datos autorizados y entorno aislado. Un POC no debe recibir automáticamente los accesos de producción.
Experimentación hacia piloto
Exigir un conjunto de evaluación, resultados, un análisis de errores, la cartografía de datos, los costos y una primera revisión de seguridad/GDPR.
Piloto hacia producción
Validar umbrales, monitoreo, responsabilidad, soporte, contrato, recuperación, documentación del usuario, supervisión humana y plan de retiro.
Producción hacia un cambio mayor
Una nueva versión de modelo, una nueva herramienta, otra población o un derecho de escritura adicional desencadena una reevaluación dirigida.
Cada puerta produce una decisión fechada: aprobado, aprobado con condiciones, rechazado o información complementaria.
Repartir las responsabilidades
El propietario del negocio responde de la finalidad, del uso y de los resultados esperados. El propietario técnico responde de la arquitectura, de las versiones, de las integraciones y de la explotación. El DPO, la seguridad, lo jurídico y el control interno intervienen según el riesgo.
El comité de IA no debe examinar cada prompt. Arbitra los casos complejos, define los niveles, sigue los incidentes y decide sobre las excepciones. Los casos estándar siguen un recorrido automatizado o delegado.
Un tipo de RACI especifica quién:
- propone;
- evalúa;
- aprueba;
- despliega;
- supervisa;
- informa a las personas;
- gestiona los incidentes;
- decide la retirada.
Organizar las pruebas
Cada entrada del registro apunta a los documentos, no a una simple casilla «conforme». Las pruebas incluyen:
- ficha del proveedor;
- contrato y subcontratistas;
- arquitectura y flujo;
- análisis AI Act/RGPD/seguridad;
- conjunto de evaluación;
- informe de resultados;
- modelo de supervisión;
- instrucciones y recorridos;
- decisiones;
- incidentes;
- historial de versiones.
La organización puede inspirarse en la ISO/IEC 42001 para estructurar liderazgo, riesgos, ciclo de vida, medición y mejora continua, sin pretender estar certificada si no lo está.
Gobernar los cambios
Un sistema de IA evoluciona a veces sin despliegue de código: el proveedor reemplaza un modelo, modifica un filtro, aumenta una ventana de contexto o agrega una memoria. El contrato y la supervisión deben permitir detectar estos cambios.
Definir los eventos que desencadenan una revisión:
- nueva versión;
- nuevo dato;
- nueva población;
- nueva acción;
- disminución de calidad;
- incidente;
- evolución regulatoria;
- fin de soporte;
- cambio de subcontratista.
Un diario relaciona el evento con la decisión y las pruebas realizadas.
Medir la gobernanza
Los indicadores útiles no son el número de reuniones o páginas producidas. Sigues en cambio:
- porcentaje de sistemas con propietario;
- proporción de versiones conocidas;
- cobertura de las evaluaciones;
- plazos de procesamiento de las solicitudes;
- número de excepciones vencidas;
- incidentes por nivel;
- sistemas sin revisión reciente;
- acciones de remediación atrasadas;
- usos detectados fuera del registro;
- tiempo de retirada o de reversión.
Estas métricas revelan la capacidad real de controlar la cartera.
Gestionar las excepciones sin crear una puerta trasera
Una excepción contiene una justificación, un alcance, un propietario, medidas compensatorias y una fecha de caducidad. No se renueva automáticamente.
Por ejemplo, una prueba limitada puede usar un proveedor no estándar con datos sintéticos, un entorno separado y una eliminación verificada. La excepción no permite el paso silencioso a producción.
Relacionar gobernanza y experiencia de usuario
La gobernanza se materializa en el producto: mensajes de transparencia, fuentes, posibilidad de corregir, consentimientos si son necesarios, control humano, historial y recursos. No es solo un trabajo de oficina administrativa.
Los comentarios de los usuarios alimentan el registro: errores recurrentes, malentendidos, sesgos, abandono o soluciones alternativas. Un sistema «conforme sobre el papel» pero inutilizable genera sus propios riesgos.
Comenzar pequeño, pero con un modelo escalable
Una empresa puede comenzar en seis semanas:
- nombrar a un responsable;
- inventariar los veinte usos más visibles;
- adoptar tres o cuatro niveles de control;
- definir las puertas de decisión;
- crear una ficha de registro versionada;
- tratar los cinco riesgos prioritarios;
- integrar la compra y la seguridad;
- publicar una política simple;
- formar a los equipos;
- medir y ajustar.
Partitech puede diseñar el registro, automatizar los flujos de trabajo, conectar las pruebas e integrar los controles en el ciclo de desarrollo. Una buena gobernanza no impide la experimentación: permite saber dónde se experimenta, con qué límites y quién es responsable de lo que sigue.
Hablemos de su proyecto
Diseñar un sistema de gobernanza de IA proporcionado e integrado en sus procesos con Partitech. Contacte a Partitech.