Entrada
ISO 56001: innovar no es lanzar más ideas, es aprender a decidir mejor
En muchas empresas el problema de innovación no es la falta de ideas. Ideas sobran. Lo difícil empieza después: decidir cuáles merecen tiempo y dinero, qué se quiere aprender con un piloto, cuándo aumentar la inversión y cuándo dejar de insistir.
La IA ha hecho este problema más visible. Hoy un equipo puede probar una herramienta en días y mostrar resultados atractivos muy rápido. Eso es útil. También puede crear la ilusión de que experimentar mucho equivale a innovar bien.
Un piloto no es una estrategia. Y una colección de ideas no es un sistema de innovación.
ISO 56001:2024 aborda justamente esa brecha. Plantea un sistema de gestión de la innovación para conectar dirección, oportunidades, portafolio, recursos, aprendizaje y mejora. No garantiza que todas las iniciativas funcionen —ningún sistema serio podría prometer eso—. Ayuda a que la organización aprenda a tomar mejores decisiones bajo incertidumbre.
La innovación necesita un mecanismo para decir sí, no y todavía no
Cuando no existen criterios claros, las iniciativas suelen avanzar por entusiasmo, influencia o urgencia. Algunas sobreviven porque tienen un patrocinador fuerte. Otras desaparecen cuando cambia la prioridad del trimestre. Y muchas quedan en ese lugar incómodo de los pilotos eternos: no generan suficiente evidencia para escalar, pero nadie toma la decisión de cerrarlos.
Un sistema de gestión ayuda a poner disciplina sin matar la exploración. No se trata de exigir un caso de negocio perfecto para una idea que todavía está aprendiendo. Se trata de definir qué necesitamos saber antes de pasar a la siguiente etapa.
En la práctica, las preguntas cambian según el momento. Al principio puede bastar con entender la oportunidad y la hipótesis. Más adelante aparecerán preguntas sobre viabilidad, recursos, riesgos, valor y escalabilidad. Lo importante es que la organización sepa qué decisión está intentando tomar y qué evidencia necesita para tomarla.
Medir actividad no es lo mismo que medir capacidad
Número de ideas recibidas. Número de hackathons. Número de pilotos. Son datos fáciles de contar y probablemente útiles para algunas conversaciones. Pero dicen poco, por sí solos, sobre la calidad del sistema de innovación.
Una organización puede tener cincuenta iniciativas abiertas y aprender muy poco. Otra puede tener cinco y ser mucho más rigurosa al validar hipótesis, compartir aprendizajes y reasignar recursos. Por eso conviene mirar también qué decisiones se tomaron, cuánto se aprendió, qué obstáculos se repiten y qué valor apareció frente a los objetivos definidos.
El fracaso de un experimento tampoco debería tratarse automáticamente como un fracaso de gestión. Si el piloto permitió descartar una hipótesis costosa antes de escalarla, probablemente produjo valor. El problema es cuando no sabemos qué aprendimos o repetimos el mismo error en otro proyecto.
Cuando la innovación usa IA, la gobernanza debe entrar temprano
Aquí se cruzan ISO 56001 e ISO/IEC 42001. No son lo mismo y no conviene confundirlas. ISO 56001 ayuda a gestionar la capacidad de innovar. ISO/IEC 42001 aporta una arquitectura específica para gestionar el uso o provisión de sistemas de IA.
Si un piloto de innovación incorpora IA, algunas preguntas de gobernanza deberían aparecer antes de que el proyecto se vuelva exitoso. Sí, antes. Porque el momento más barato para definir límites suele ser cuando todavía estamos experimentando.
- ¿Qué problema estamos intentando resolver con IA y qué no debería hacer la solución?
- ¿Qué datos necesita y bajo qué condiciones pueden utilizarse?
- ¿Quién es responsable del caso de uso si el piloto pasa a producción?
- ¿Qué riesgos o impactos cambiarían la decisión de continuar?
- ¿Qué controles tendrían que existir antes de escalar?
- ¿Qué evidencia necesitaremos para demostrar que el uso sigue bajo control?
Estas preguntas no tienen que convertir una prueba de concepto en un expediente de cien páginas. Ese sería otro error. La profundidad debe crecer con el riesgo, el impacto y la cercanía a producción.
La innovación responsable también sabe detenerse
Cerrar una iniciativa a tiempo puede ser una buena decisión. Limitar un uso porque cambió el riesgo también. Y retirar una solución que ya no cumple su propósito no debería verse como una derrota si la decisión está sustentada.
Con IA, esta disciplina es especialmente importante porque las condiciones pueden cambiar sin que el proyecto cambie de nombre. El proveedor actualiza el servicio. El modelo se comporta de otra manera. Se amplía el grupo de usuarios. El piloto comienza a recibir información más sensible. De repente, el caso de uso ya no es exactamente el que se evaluó al principio.
Escalar una innovación sin revisar qué cambió es una forma bastante eficiente de acumular deuda de gobernanza.
La realidad latinoamericana exige priorizar bien
En América Latina, los equipos de innovación y transformación suelen trabajar con recursos limitados y múltiples prioridades. Eso hace todavía más importante la capacidad de elegir. No hace falta montar un laboratorio sofisticado para empezar a gestionar la innovación mejor. Hace falta una lógica consistente para seleccionar, experimentar, aprender y decidir.
Para una organización que ya está adoptando IA, esa lógica puede evitar dos extremos bastante comunes: moverse demasiado lento por miedo al riesgo o avanzar demasiado rápido y descubrir tarde que el caso de uso no era gobernable como estaba diseñado.
ISO 56001 puede ayudar a ordenar la capacidad de innovación. ISO/IEC 42001 puede ayudar a gobernar la IA que forma parte de esa innovación. Y los sistemas de gestión existentes pueden servir como infraestructura común para que todo esto no se convierta en capas independientes de burocracia.
Innovar mejor no significa tener más ideas. Significa convertir incertidumbre en aprendizaje y aprendizaje en mejores decisiones.
Entrada
Tu organización ya usa IA. La pregunta es: ¿puedes demostrar que está bajo control?
La IA no siempre entra a una empresa con un gran proyecto, presupuesto aprobado y comité de transformación. A veces entra con una actualización de software. O con una herramienta que un equipo empezó a utilizar porque resolvía un problema en minutos. También puede venir escondida dentro de una plataforma que la organización ya tenía contratada.
Así que probablemente tu organización ya usa más inteligencia artificial de la que aparece en sus proyectos oficiales.
La pregunta útil ya no es “¿usamos IA?”. Es otra: ¿podemos explicar dónde se usa, para qué, quién responde y cómo sabemos que está bajo control?
Usar IA no es lo mismo que gobernarla.
Una empresa puede tener pilotos interesantes, equipos capaces y buenas intenciones y, al mismo tiempo, una gobernanza inmadura. También puede publicar una política de IA y creer que ya resolvió el problema. La política ayuda, claro. Pero una política no asigna por sí sola responsabilidades, no evalúa riesgos y no demuestra que un control opera.
La gobernanza empieza cuando esas intenciones se convierten en decisiones repetibles. Quién puede aprobar un uso. Quién puede detenerlo. Qué datos se pueden utilizar. Qué riesgos requieren escalamiento. Qué evidencia debe conservarse. Y qué se revisa cuando algo cambia.
Una prueba sencilla: intenta reconstruir un caso de uso
Elige una herramienta de IA que ya esté en operación. No la más sofisticada; una real. Tal vez un asistente para redactar, una solución que clasifica solicitudes, un motor de recomendación o una función incorporada por un proveedor.
Ahora intenta seguir su historia. ¿Por qué empezó a utilizarse? ¿Quién lo decidió? ¿Qué información procesa? ¿Qué puede hacer y qué no debería hacer? ¿Quién revisa sus resultados? ¿Qué riesgos se evaluaron? ¿Qué ocurre si el proveedor cambia la funcionalidad?
Si las respuestas están repartidas entre correos, conversaciones y memoria informal, ya tienes una señal. No necesariamente significa que el uso sea inaceptable. Significa que la organización puede tener dificultades para demostrar cómo lo está gobernando.
Seis preguntas que suelen ordenar la conversación
Cuando una organización no sabe por dónde empezar, estas seis preguntas ayudan a bajar la gobernanza de IA del discurso a la operación:
Propósito y perímetro. ¿Para qué usamos esta IA y hasta dónde permitimos que actúe?
Responsabilidad. ¿Quién decide, quién opera, quién supervisa y quién responde?
Uso visible. ¿Sabemos dónde está la IA, de qué depende, qué datos usa y qué proveedor interviene?
Evaluación. ¿Qué riesgos e impactos se analizaron y quién aceptó el riesgo que quedó?
Barreras y controles. ¿Qué previene, detecta o corrige resultados no deseados?
Assurance y aprendizaje. ¿Qué evidencia demuestra que lo anterior funciona y qué hacemos con lo que aprendemos?
No todas las respuestas necesitan el mismo nivel de formalidad. Un asistente interno de bajo impacto probablemente no requiere la misma intensidad de control que un sistema que influye en decisiones sobre empleo, crédito, seguridad o atención a clientes. Esa es justamente una de las claves: la gobernanza debe ser proporcional al riesgo.
ISO/IEC 42001 ayuda a construir el sistema, no a llenar una carpeta
ISO/IEC 42001:2023 especifica los requisitos para un Sistema de Gestión de Inteligencia Artificial. En términos simples, ofrece una estructura para que la organización conecte liderazgo, políticas, objetivos, riesgos, responsabilidades, operación, seguimiento y mejora alrededor de la IA.
Eso es mucho más interesante que convertir la norma en una lista de documentos por producir. Si el sistema solo existe para pasar una auditoría, probablemente se notará muy rápido. La operación diaria encontrará atajos, los responsables dejarán de consultarlo y la evidencia aparecerá solo cuando alguien la pida.
Una gobernanza útil debería hacer lo contrario: facilitar decisiones. Por ejemplo, permitir que usos de bajo riesgo avancen con reglas claras y que los casos más sensibles escalen a una revisión adicional. La intención no es poner cinco comités delante de cada experimento. Es saber qué puede avanzar rápido y qué no debería desplegarse sin una decisión consciente.
La IA de terceros no elimina tu responsabilidad
Este punto suele generar confusión. “Nosotros no desarrollamos IA; usamos una solución de un proveedor”. Bien. Eso cambia algunas responsabilidades técnicas, pero no elimina la responsabilidad organizacional sobre el uso.
La empresa sigue decidiendo qué herramienta contrata, qué datos comparte, para qué procesos la utiliza, quién puede acceder, cómo valida los resultados y qué hace si el servicio cambia. En muchos casos, además, el proveedor puede introducir nuevas funcionalidades de IA antes de que la organización haya evaluado su impacto.
No desarrollar el modelo no significa transferir el riesgo al proveedor.
¿Qué significa esto para una organización latinoamericana?
Probablemente no necesite copiar la estructura de gobierno de una multinacional con veinte especialistas. Sí necesita claridad. Un inventario razonable de usos de IA. Responsables. Criterios de riesgo. Reglas para terceros. Supervisión cuando el impacto lo justifique. Un mecanismo para reportar incidentes y cambios. Y evidencia suficiente para explicar las decisiones.
Si la organización ya tiene ISO/IEC 27001, gestión de riesgos, compliance, procesos de compras, auditoría interna o revisión por la dirección, parte de esa arquitectura puede reutilizarse. En la práctica, integrar suele ser más sostenible que crear otro sistema paralelo.
No hace falta esperar una regulación perfecta ni una decisión de certificación para comenzar. La IA ya está tomando espacio en procesos, datos y decisiones. Gobernarla temprano suele ser más barato que reconstruir controles después.
La pregunta no es cuánta IA usa tu organización. La pregunta es si puede demostrar que ese uso está siendo gobernado.
Entrada
ISO/IEC 27001: el problema no es tener controles, sino saber si realmente están funcionando
Una empresa puede tener firewall, autenticación multifactor, copias de respaldo y una larga lista de políticas. Y aun así estar mal preparada para responder una pregunta bastante incómoda: ¿cómo sabemos que nuestros controles están funcionando de verdad?
Ese es el punto en el que la conversación deja de ser puramente tecnológica y se convierte en una conversación de gestión. No basta con instalar controles. Hay que decidir qué se protege, frente a qué riesgo, quién responde y qué evidencia permite comprobar que la decisión sigue siendo válida.
Un control que existe en el papel puede no existir en la práctica. Y un control que opera hoy puede dejar de ser suficiente mañana.
En mi experiencia auditando sistemas de gestión, esta diferencia aparece una y otra vez. La organización tiene documentos. Tiene herramientas. Incluso puede tener responsables designados. Pero cuando uno sigue el rastro del riesgo hasta la evidencia, aparecen vacíos: accesos que nadie revisa, proveedores que cambiaron, excepciones que quedaron abiertas o controles que dependen de una persona que “siempre se acuerda”.
El SGSI no es una caja de herramientas
ISO/IEC 27001:2022 establece los requisitos de un Sistema de Gestión de Seguridad de la Información, o SGSI. La palabra importante aquí es sistema. Un SGSI no es el inventario de software de ciberseguridad de la empresa. Se parece más al tablero desde el que la organización decide qué riesgos acepta, cuáles trata, quién hace qué y cómo revisa si las medidas siguen siendo adecuadas.
Pensemos en un caso sencillo. La empresa contrata un nuevo proveedor en la nube. Tecnología puede revisar la configuración técnica, pero el riesgo no termina ahí. Compras necesita entender las condiciones del servicio; Legal, las obligaciones contractuales; el dueño del proceso, qué ocurriría si el servicio falla; y Seguridad, qué información se procesa y cómo se protegerá. Si cada área ve solo su pedazo, probablemente nadie esté viendo el riesgo completo.
Por eso la seguridad de la información no pertenece únicamente a TI. Un SGSI efectivo conecta negocio, tecnología, personas y terceros. Y obliga a que ciertas preguntas tengan respuesta antes de que ocurra el incidente, no después.
- ¿Qué información y servicios son realmente críticos para operar?
- ¿Quién puede aceptar un riesgo y quién debe escalarlo?
- ¿Qué terceros tienen acceso o procesan información sensible?
- ¿Qué cambia cuando una persona se va, un sistema se actualiza o un proveedor modifica su servicio?
- ¿Qué evidencia podemos mostrar para demostrar que los controles operaron?
La evidencia cambia la calidad de la conversación
Decir “tenemos un procedimiento de gestión de accesos” describe una intención. Mostrar revisiones periódicas, altas y bajas autorizadas, excepciones aprobadas y acciones tomadas ante desviaciones demuestra que el proceso está operando. No es lo mismo.
La evidencia tampoco tiene que convertirse en una montaña de registros. En la mayoría de los casos, lo importante es que sea suficiente para reconstruir una decisión: qué riesgo se identificó, qué control se seleccionó, quién era responsable, qué ocurrió y qué se hizo cuando algo no salió como se esperaba.
Ahí es donde la auditoría aporta valor. No debería limitarse a verificar que existe un documento. Debería seguir el hilo desde el riesgo hasta la operación del control y preguntar si el resultado es coherente con lo que la organización afirma.
¿Y qué tiene que ver esto con inteligencia artificial?
Mucho. Una organización que ya utiliza IA probablemente está incorporando nuevos proveedores, datos, integraciones, accesos y cambios frecuentes. El SGSI ofrece una base muy útil para controlar parte de esa exposición: seguridad, activos de información, incidentes, terceros, continuidad y gestión de accesos.
Pero no resuelve por sí solo todas las preguntas de gobernanza de IA. La organización también necesita definir para qué se usa el sistema de IA, qué impactos puede generar, qué nivel de supervisión humana requiere, cómo se controla su ciclo de vida y qué ocurre cuando cambia el modelo, el proveedor o el contexto de uso.
ISO/IEC 27001 e ISO/IEC 42001 no deberían convertirse en dos mundos separados. Si ya existe una arquitectura de gestión útil, lo sensato suele ser integrarla.
Eso evita duplicar comités, matrices, auditorías y procedimientos sin necesidad. Además, hace que la gobernanza sea más fácil de operar. Un responsable de negocio no debería tener que aprender tres sistemas paralelos para gestionar el mismo riesgo desde ángulos distintos.
Para muchas organizaciones latinoamericanas, menos duplicación es una ventaja real
No todas las organizaciones de la región tienen grandes equipos de GRC, ciberseguridad, compliance y auditoría interna. Eso obliga a diseñar sistemas proporcionales. Proporcional no significa débil. Significa concentrar el esfuerzo donde el riesgo lo justifica y reutilizar lo que ya funciona.
Si una empresa quiere empezar a fortalecer su SGSI, probablemente sea más útil comenzar por una línea base honesta que por una lista de documentos por crear. ¿Qué información es crítica? ¿Dónde están los riesgos que más preocupan? ¿Qué controles ya existen? ¿Cuáles dejan evidencia? ¿Cuáles dependen demasiado de la memoria de una persona?
Ese diagnóstico suele revelar más que una revisión superficial de políticas. Y, si la empresa ya está incorporando IA, permite construir la seguridad y la gobernanza sobre una misma lógica de gestión.
La seguridad de la información no se demuestra porque existan muchas herramientas. Se demuestra cuando la organización puede explicar sus decisiones, operar sus controles y aprender de la evidencia.
