Una lista de decisiones de supervisión registra quién tomó qué decisión sobre qué sistema de IA, con base en qué información, y con qué reserva. Suena sencillo. En la práctica, la primera versión suele fracasar porque se presenta como un proceso nuevo junto a las reuniones existentes. Un segundo proceso junto al existente se ignora, no porque las personas sean reticentes, sino porque nadie reserva tiempo para algo que no encaja en una agenda que ya está llena.
La lista no es un registro de actividades ni un registro de riesgos. Contiene decisiones: momentos en los que alguien con autoridad aprobó, rechazó, postergó o dejó continuar algo bajo condiciones. Cada línea debe contener como mínimo cuatro elementos: el sistema o la aplicación sobre la que trata la decisión, el nombre y el cargo de quien la tomó, la fecha, y la motivación o la reserva. Sin motivación, una lista de decisiones es una lista de asistencia. Con motivación, se convierte en la prueba de que se pensó, no solo de que se marcó una casilla.
La lista también debe dejar espacio para la revisión. Una decisión tomada hace medio año, con base en la información disponible entonces, puede haber quedado desactualizada. Una buena lista de decisiones muestra cuándo una decisión ha sido reconfirmada o revocada, no solo cuándo se tomó originalmente.
Los consejos y direcciones ya tienen un ritmo propio: reuniones trimestrales, comités de riesgo, comisiones de auditoría. Quien monta una nueva estructura de supervisión desconectada de ese ritmo, pide a las personas que encuentren tiempo adicional para algo que no tiene un lugar claro. Eso rara vez ocurre de forma estructural. Las primeras veces puede funcionar, con esfuerzo. Después desaparece de la agenda en cuanto surge algo más urgente, y siempre surge algo más urgente.
La solución no consiste en construir un proceso nuevo, sino en hacer que la lista de decisiones se apoye en lo que ya ocurre. Si ya existe un comité de riesgo que se reúne cada trimestre, la lista de decisiones sobre IA debe ser un punto fijo de esa agenda, no una sesión aparte. Si ya existe una vía de auditoría para decisiones financieras, la lógica de esa vía —quién firma, quién controla, dónde se almacena— debe reutilizarse para las decisiones sobre IA. Esa es también la razón por la que conectar con la estructura de riesgo existente es un tema aparte: una lista de decisiones que no se conecta con cómo se trata el riesgo en otros ámbitos, sigue siendo un documento aislado que nadie consulta.
Una lista de decisiones no funciona por sí sola. Alimenta el informe que un consejo necesita para poder afirmar que tiene visibilidad sobre el riesgo de IA, y presupone que existe una vía para cuando una decisión resulta ya insostenible. Sin un informe de una página para el consejo que resuma la lista de decisiones, la información desaparece en un archivo que nadie hojea. Sin vías de escalada que funcionen, una decisión desactualizada simplemente permanece vigente, porque nadie sabe a quién plantearla.
Los tres elementos están conectados: la lista de decisiones registra lo que se ha decidido, el informe lo hace visible en el nivel donde tiene peso, y la escalada garantiza que una decisión pueda reabrirse si la situación cambia. Si se construye uno sin los otros dos, se crea una apariencia de control que, ante la primera prueba real —un incidente, una pregunta de un supervisor, un periodista— no llega a cubrir lo que realmente ocurre.
Una lista de decisiones es tan buena como la información que contiene. Si nadie sabe qué sistemas de IA están realmente en uso —incluido lo que se ha adquirido o implementado fuera del ámbito de TI— la lista solo registrará decisiones sobre las aplicaciones visibles y formalmente aprobadas. El resto queda sin decidir, no porque no fuera necesaria una decisión, sino porque nadie sabía que había algo sobre lo que decidir. Por eso un inventario siempre precede a una lista de decisiones, no la sigue. Lo que un consejero debe saber al respecto se describe en qué debe saber un consejero sobre el riesgo de IA; lo que un CIO debe reconocer en ese inventario se describe en qué debe saber un CIO sobre el riesgo de IA.
Lo que es fijo: una lista de decisiones sin conexión con una reunión existente no se mantiene, y una lista de decisiones sin una visión completa de lo que está en funcionamiento solo registra una parte de la realidad. Lo que depende de la organización: qué reunión es el punto de anclaje adecuado, con qué frecuencia se reúne, y quién tiene la autoridad para tomar una decisión que acabe en la lista. Esto varía según el sector, la estructura de gobierno y la cultura de riesgo, por lo que no existe una plantilla fija que funcione en todas partes sin adaptación.
El Responsible AI Scan está en construcción. Quien necesite ahora mismo una lista de decisiones que se conecte con la estructura existente, puede inscribirse en la lista de espera; todavía no se ofrece nada que aún no exista.
Una lista de decisiones indica quién decidió, no cuánto trabajo asume realmente un sistema o podría asumir. Para esa pregunta —qué parte de una tarea puede transferirse a la IA, y qué parte no— se necesita una mirada distinta a la que ofrece solo la gobernanza. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte del trabajo puede transferirse, como complemento a la visión que ofrecen una lista de decisiones y la estructura de supervisión correspondiente.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.