Serie IA 360° · Parte 6: Gobernanza
Los trenes de alta velocidad no corren rápido a pesar de los rieles. Corren rápido gracias a ellos. Sin una vía definida, un tren no acelera: descarrila. La gobernanza de inteligencia artificial funciona bajo la misma lógica, aunque buena parte de los comités directivos todavía la interprete al revés, como si cada control fuera un freno más entre la idea y la ejecución.
En la entrada anterior de esta serie prometimos volver sobre uno de los temas que más malentendidos genera en los equipos directivos: la gobernanza. Dijimos que no significa burocracia paralizante ni comités interminables de aprobación, sino exactamente lo contrario: rieles claros que permiten experimentar rápido, fallar de forma controlada y escalar lo que funciona, todo dentro de límites definidos que protegen el negocio sin frenar la innovación. Esta entrada cumple esa promesa.
El malentendido que más cuesta caro
Precisamente porque hoy cualquier persona en la empresa puede abrir una pestaña y empezar a usar IA sin pedir permiso a nadie, la gobernanza se vuelve más crítica, no menos. La IA sin gobernanza eventualmente genera una crisis: información empresarial que termina de dominio público porque nadie verificó qué ocurre con los datos que procesa un modelo de terceros, una decisión automatizada que nadie en la empresa puede explicar frente a un cliente, un agente que operó fuera del alcance para el que fue diseñado. Ya hablamos en la entrada anterior de lo que pasa cuando se conecta un agente autónomo a los sistemas centrales de un negocio sin haber resuelto antes esas preguntas.
Según una publicación de BCG, el 85% de las empresas ya tiene en marcha algún programa de IA responsable, pero solo el 25% cuenta con un marco realmente maduro. La brecha no está en la intención: la enorme mayoría ya empezó. Está en la claridad, en tener procesos definidos, roles asignados y mecanismos de auditoría reales que sostengan ese programa el día que deja de ser un documento y se convierte en operación diaria.
La gobernanza sin claridad se parece más a un membrete corporativo que a un sistema de control.
Tres preguntas antes de escribir una sola política
Un framework efectivo no requiere cincuenta páginas de políticas. Requiere respuestas claras a tres preguntas, y un proceso de escalamiento definido para el momento en que la respuesta no sea obvia.
¿Quién autoriza nuevos usos de IA dentro de la empresa? Sin un responsable claro, cada equipo termina decidiendo por su cuenta, y lo que en apariencia es autonomía se convierte, con el tiempo, en una colección de soluciones inconexas que nadie puede auditar.
¿Cómo auditamos los modelos para evitar que los datos empresariales terminen de dominio público? Cada integración con un proveedor externo debería responder, antes de firmarse, qué pasa con la información que procesa, quién más puede acceder a ella y bajo qué condiciones se retiene o se elimina. En Evolvis AI, por ejemplo, esta pregunta define buena parte de cómo diseñamos cada implementación: la información de nuestros clientes permanece dentro de su propio entorno empresarial, sin salir hacia terceros. No es una cláusula de contrato añadida al final, es una condición de diseño desde el primer piloto.
¿Qué datos pueden usarse, y para qué? No toda la información de una empresa debería fluir hacia cualquier sistema de IA solo porque técnicamente es posible conectarla.
Lo crítico —y aquí es donde la mayoría de las organizaciones llega tarde— es implementar estas respuestas desde el primer piloto, no como reflexión posterior a un incidente. Cuando el incidente ya ocurrió, el costo no se mide en horas de comité: se mide en confianza perdida y en un liderazgo que tiene que explicar por qué nadie estaba mirando.
Cómo se ve la gobernanza cuando deja de ser un documento
Una gobernanza que funciona no arranca por la regla, arranca por la pregunta que la justifica. Antes de configurar un solo permiso vale la pena preguntarse por qué debería existir: qué se está protegiendo, y de quién. No es lo mismo cuidar al negocio de un uso irresponsable de la IA que cuidar a un empleado de una responsabilidad que no le corresponde y para la que nadie lo preparó. Cuando esa razón está clara, todo lo demás se vuelve mucho más fácil de diseñar.
Después viene el cómo, los mecanismos concretos que convierten ese propósito en control real. En la práctica casi siempre se reduce a tres palancas que se pueden ajustar independientemente: quién puede hacer qué dentro del sistema, a qué información puede acceder cada quién según lo que su trabajo realmente requiere, y cuánto detalle recibe cada persona de lo que la IA genera. No todos necesitan ver todo; necesitan ver lo que les permite decidir bien en su función específica.
Y solo al final llega el qué: las reglas específicas, los roles configurados, los límites que finalmente se traducen en pantallas y permisos dentro del sistema. Es la parte más visible del trabajo, pero también la más sencilla de resolver una vez que el por qué y el cómo ya están acordados. El error más común es el orden inverso: empezar a configurar permisos sin haber discutido antes qué se está protegiendo, y terminar con un mapa de accesos que, un año después, nadie recuerda por qué se diseñó así.
Así lo aplicamos en los proyectos de Evolvis AI
En uno de nuestros proyectos de ingeniería, los usuarios con perfil administrador pueden gestionar proyectos completos, crear nuevos proyectos a partir de los requerimientos que entrega el cliente final y guardarlos en la base de datos interna, además de consultar listas de materiales generadas por la IA, precios, cotizaciones y costos unitarios de cada parte de una oferta. Los usuarios con permisos más limitados, en ese mismo sistema, solo pueden hacer consultas técnicas sobre equipos de refrigeración: el acceso está acotado a la función que realmente desempeñan, sin exponerlos a información comercial que no necesitan y que tampoco deberían poder alterar.
En un cliente del sector de servicios de calibración, el asesor de IA que desplegamos aplica el mismo principio desde otro ángulo: cada usuario solo puede ver a los clientes que tiene asignados, ya sea para dar seguimiento a oportunidades de venta o para resolver quejas. No es una limitación técnica arbitraria; es una decisión de diseño que refleja cómo opera realmente esa empresa y protege información de cuentas que no le corresponden a esa persona.
El mismo criterio gobierna la configuración del sistema. Los usuarios con mayores privilegios pueden ajustar los componentes críticos que activan la generación de insights —las variables que determinan qué información se prioriza y cómo se interpreta—, mientras que los usuarios con permisos limitados solo pueden consultarla, nunca modificarla. Y el nivel de detalle también se gobierna: un usuario privilegiado accede a insights completos y granulares sobre el negocio, mientras que un usuario operativo recibe una versión resumida, enfocada en lo que necesita para hacer su trabajo, sin el ruido de información que no le corresponde.
Ninguno de estos controles ralentiza el trabajo diario. Cada persona interactúa con el asesor de IA de forma fluida, dentro del carril que le corresponde. Eso es, literalmente, gobernanza funcionando como rieles y no como frenos.
Implementarlo desde el primer piloto, no después del incidente
La tentación, sobre todo en proyectos piloto, es posponer estas decisiones hasta que el sistema demuestre valor: «primero probamos que funciona, después definimos los permisos.» Es exactamente el orden equivocado. Un piloto que arranca sin rieles definidos no es más rápido que uno que los tiene desde el diseño; simplemente traslada el costo de definir esos rieles al momento en que ya hay datos reales en juego, usuarios reales dependiendo del sistema, y mucho más que perder si algo sale mal.
Diseñar los permisos, el alcance de datos y los niveles de detalle desde la primera versión del piloto no añade semanas al proyecto. Añade horas de conversación con quienes conocen el negocio, exactamente el mismo tipo de conversación que ya se necesita para definir qué debería hacer el sistema en primer lugar.
«Si la gobernanza define ‘cómo’ usar IA, la ética define ‘cuándo no’ usarla.»
En la próxima entrada de la serie IA 360° hablaremos de escalamiento: cómo llevar del piloto a toda la organización lo que ya demostró funcionar, sin perder en el camino los rieles que construimos aquí. La pregunta de cuándo no usar la IA, aunque técnicamente se pueda, la dejamos para la entrega que sigue después de esa.
Sobre el autor: Carlos Carrasco es CTO de Evolvis AI. Es Doctor en Sistemas Inteligentes por el Tecnológico de Monterrey, candidato a MBA y ex investigador senior del Barcelona Supercomputing Center. Cuenta con más de 20 publicaciones científicas y ha liderado proyectos de gran escala, impulsando el desarrollo y la aplicación de inteligencia artificial en diversas industrias.
Contacto: info@evolvis.ai
