Una herramienta promete ahorrar horas. Para cumplirlo, pide leer el correo, consultar el sistema de gestión de relaciones con clientes (CRM) y acceder a documentos internos. La conexión puede tomar minutos; decidir si ese acceso debe existir exige otro criterio.
La gobernanza de IA en empresas define quién puede usar una herramienta, con qué información, bajo qué límites y con qué responsabilidad. No busca frenar una oportunidad útil. Busca evitar que una prueba rápida se convierta en un acceso amplio que nadie sabe explicar, revisar o retirar.
A primera vista, la empresa parece tener dos opciones: autorizar o prohibir. Sin embargo, esa elección deja fuera una decisión intermedia que suele ser más útil. Un caso puede avanzar con límites mientras la empresa reúne evidencia, reduce permisos o valida el proceso.
Por eso, esta guía organiza cada caso en tres resultados:
- Permitir: el uso tiene propósito, alcance, datos, permisos y responsable definidos.
- Limitar: el caso puede probarse con menos información, acceso de solo lectura, usuarios reducidos o revisión adicional.
- No conectar todavía: faltan condiciones básicas para autorizar, supervisar o responder por el uso.
Esta clasificación funciona como filtro inicial. No sustituye una evaluación legal, de privacidad o seguridad cuando el contexto la exige. Su propósito es más concreto: convertir una preocupación general en una decisión que la empresa pueda documentar y revisar.
La empresa no puede gobernar los usos que no conoce
El primer vacío suele aparecer antes de evaluar permisos. Un equipo prueba una herramienta con una cuenta personal. Otro carga documentos para resumirlos. Un tercero conecta una extensión al correo. Cada uso puede parecer aislado, pero juntos crean una superficie de acceso que nadie está observando de forma completa.
La empresa registra cada uso de IA para volverlo visible. Un inventario inicial puede incluir la herramienta, la tarea, el equipo, la información utilizada, el acceso solicitado, el responsable y el estado de evaluación.
No hace falta comenzar con un sistema complejo. Una tabla compartida puede ser suficiente si responde preguntas básicas:
- ¿Qué problema intenta resolver la herramienta?
- ¿Qué información necesita realmente?
- ¿La herramienta solo consulta o también modifica?
- ¿Quién revisa sus resultados?
- ¿Quién puede suspender el uso?
De este modo, el inventario no se convierte en una lista de software. Se convierte en un mapa de decisiones pendientes.
Ahora bien, detectar una herramienta no indica si puede avanzar. El siguiente paso consiste en transformar cada uso visible en condiciones de autorización.
Cuatro condiciones convierten el inventario en una decisión
Una empresa puede conocer sus herramientas y seguir sin gobernarlas. El problema persiste si nadie define qué está permitido, qué información puede utilizarse o quién responde por el resultado.
El AI Risk Management Framework de NIST presenta la gobernanza como una función transversal y plantea una gestión continua del riesgo durante el ciclo de vida del sistema. En una adopción inicial, esa orientación puede aterrizarse en cuatro condiciones.
| Condición | Pregunta que debe resolver la empresa | Evidencia mínima |
|---|---|---|
| Política | ¿Qué herramientas y usos están permitidos, limitados o pendientes? | Lista vigente y canal para solicitar evaluación |
| Información | ¿Qué datos necesita el caso y qué sensibilidad tienen? | Clasificación interna y fuente identificada |
| Acceso | ¿Qué puede consultar o modificar la herramienta? | Permisos definidos por tarea, usuario y sistema |
| Responsabilidad | ¿Quién aprueba, revisa y responde por el uso? | Responsable operativo y punto de escalamiento |
La política clasifica herramientas y casos de uso. La empresa limita los permisos por tarea. El responsable documenta la decisión. Estas tres acciones hacen que la gobernanza deje de ser una declaración general y empiece a operar dentro del proceso.
La clasificación de información también necesita contexto. Una empresa puede distinguir información pública, interna, confidencial y restringida, pero esas etiquetas no crean por sí solas una obligación legal. El tratamiento depende de la jurisdicción, los contratos, la naturaleza de los datos y el proceso involucrado.
En cuanto al acceso, el principio de menor privilegio ofrece una referencia práctica: conceder solo la visibilidad y las acciones necesarias para la tarea. NIST SP 800-207 aplica este criterio a la protección de recursos y a decisiones de autorización basadas en riesgo.
Con estas condiciones definidas, la pregunta cambia. Ya no es “¿podemos conectar la herramienta?”, sino “¿bajo qué condiciones debería avanzar?”.
Matriz para permitir, limitar o no conectar IA
Permitir todo tras una prueba funcional expone a la empresa a accesos que todavía no comprende. Prohibir todo, por otra parte, puede dejar sin resolver la necesidad que llevó al equipo a buscar la herramienta. La matriz introduce una tercera vía: limitar el caso hasta que exista evidencia suficiente.
La siguiente orientación debe adaptarse a los sistemas, obligaciones y tolerancia al riesgo de cada empresa.
La matriz se lee como fichas por caso de uso. Cada ficha conserva la misma lógica de decisión para que la comparación siga siendo clara sin depender de una tabla ancha.
Documentos internos
- Condición mínima para avanzar: carpeta y finalidad definidas; herramienta evaluada; responsable asignado.
- Señal para limitar: el caso requiere documentos confidenciales o fuentes más amplias.
- Señal para no conectar todavía: no existe clasificación o la herramienta pide acceso a todo el repositorio.
- Decisión inicial: permitir con fuentes acotadas; limitar si aumenta la sensibilidad.
CRM
- Condición mínima para avanzar: campos necesarios identificados; acceso por rol; revisión antes de cambios.
- Señal para limitar: la herramienta necesita preparar actualizaciones o consultar datos sensibles.
- Señal para no conectar todavía: solicita escritura general, exportación masiva o no deja registro de actividad.
- Decisión inicial: empezar con lectura limitada; no habilitar escritura sin control adicional.
Correo
- Condición mínima para avanzar: buzón, etiqueta o tarea específica; mensajes revisados antes del envío.
- Señal para limitar: el caso requiere historiales amplios o datos de terceros.
- Señal para no conectar todavía: solicita acceso global sin filtro, envía automáticamente o no permite revocar el acceso.
- Decisión inicial: limitar a un alcance definido; no conectar si el acceso no puede acotarse.
Calendario
- Condición mínima para avanzar: tarea concreta; permisos separados para lectura y edición.
- Señal para limitar: necesita crear o modificar eventos.
- Señal para no conectar todavía: puede invitar, cancelar o exponer información sin aprobación.
- Decisión inicial: permitir lectura si aporta valor; limitar acciones de escritura.
Información financiera o regulada
- Condición mínima para avanzar: caso documentado; revisión especializada; controles técnicos y contractuales.
- Señal para limitar: la evaluación legal, de privacidad o seguridad sigue abierta.
- Señal para no conectar todavía: no existe autorización aplicable o no puede demostrarse cómo se protege la información.
- Decisión inicial: no conectar hasta completar la revisión correspondiente.
Asistencia de redacción
- Condición mínima para avanzar: fuentes permitidas; revisión humana antes de publicar o enviar.
- Señal para limitar: el contenido afecta compromisos, clientes o decisiones sensibles.
- Señal para no conectar todavía: se usa como decisión final sin responsable ni verificación.
- Decisión inicial: permitir como apoyo; limitar su uso en decisiones de mayor impacto.
La matriz clasifica cada caso como permitido, limitado o no listo. Además, obliga a explicar por qué se tomó esa decisión.
Cuando el resultado es limitar, la empresa puede reducir el alcance sin cancelar el aprendizaje. Puede trabajar con una carpeta de prueba, habilitar solo lectura, reducir usuarios, utilizar información sintética cuando sea adecuado o exigir aprobación antes de una acción externa.
Cuando el resultado es no conectar todavía, la decisión debe identificar la brecha. Puede faltar una clasificación de datos, evidencia del proveedor, un responsable, un registro de actividad o la capacidad técnica para limitar permisos.
Así, “no conectar” deja de ser una prohibición indefinida. Se convierte en una decisión con una condición de reentrada.
Sin embargo, los controles internos resuelven solo una parte. La empresa también depende de lo que el proveedor pueda demostrar sobre el servicio.
Una demostración funcional no evalúa al proveedor
La herramienta puede responder bien durante una prueba y seguir dejando preguntas abiertas: dónde almacena la información, cuánto tiempo la conserva, qué terceros participan o qué ocurre cuando termina el contrato.
El perfil de IA generativa de NIST señala que las cadenas de valor de estos sistemas incorporan modelos, datos, software y otros componentes de terceros. Esa dependencia vuelve necesaria una revisión que vaya más allá del resultado visible.
La empresa solicita al proveedor de IA evidencia sobre:
- los datos que procesa y la finalidad declarada;
- la ubicación y el periodo de almacenamiento;
- el uso de datos del cliente para entrenamiento o mejora del servicio;
- los controles de acceso, autenticación y roles;
- los registros de actividad disponibles;
- los terceros o subprocesadores involucrados;
- la recuperación o eliminación de información al terminar el servicio;
- la notificación de incidentes y cambios de condiciones.
El proveedor documenta el tratamiento de los datos. La empresa contrasta esa documentación con el contrato, la configuración real y las revisiones que exige su contexto.
Estas preguntas no demuestran por sí solas cumplimiento. Aun así, permiten distinguir entre una promesa comercial y una condición que puede verificarse.
¿Qué ocurre cuando los equipos ya usan herramientas que nunca pasaron por esta evaluación? Ahí aparece el shadow AI.
El shadow AI revela una necesidad que quedó fuera del proceso
Shadow AI es el uso de herramientas de inteligencia artificial fuera de los canales evaluados por la organización. Puede introducir accesos no conocidos, pero también puede revelar tareas que los procesos actuales no resuelven bien.
Una respuesta exclusivamente punitiva puede hacer menos visible el problema. En cambio, una ruta de declaración y evaluación permite convertir el uso informal en un caso que la empresa puede revisar.
La empresa puede habilitar un canal sencillo para registrar herramientas, explicar qué información no debe compartirse, ofrecer alternativas aprobadas y definir límites temporales mientras evalúa el caso.
Por un lado, los equipos necesitan una vía para proponer usos que aportan valor. Por otro lado, la empresa necesita conservar control sobre datos, accesos y responsabilidades. La política debe conectar ambas necesidades.
De esta manera, el objetivo no es premiar ni castigar la exploración. El objetivo es reducir usos invisibles y llevarlos a una decisión explícita.
Una vez clasificado el caso, todavía falta evitar otro vacío: que la decisión quede registrada, pero nadie la ejecute o revise.
Cada resultado necesita una acción y una fecha de revisión
Una autorización sin responsable puede expandirse más allá de su propósito inicial. Una limitación sin criterio de salida puede convertirse en un piloto permanente. Del mismo modo, un caso no autorizado puede quedar suspendido sin que nadie resuelva la brecha.
Cada resultado debe terminar con una acción verificable.
| Resultado | Acción siguiente | Criterio para revisar de nuevo |
|---|---|---|
| Permitir | Documentar alcance, responsable, permisos y fecha de revisión | Cambio de herramienta, datos, usuarios, finalidad o nivel de acceso |
| Limitar | Ejecutar una prueba acotada y registrar resultados e incidentes | Evidencia suficiente para ampliar, mantener o retirar el uso |
| No conectar todavía | Registrar la brecha y asignar responsable | Cierre de la revisión o implementación del control faltante |
El responsable documenta la decisión y programa su revisión. El cambio de alcance activa una nueva evaluación. De este modo, la empresa evita que una autorización puntual se convierta, por inercia, en un acceso permanente.
Los principios de IA de la OECD relacionan la responsabilidad y la trazabilidad con los roles, el contexto y la gestión continua del riesgo. En la práctica, la empresa debe poder explicar quién decidió, con qué evidencia y cuándo volverá a revisar el caso.
La matriz ya permite clasificar el acceso. Las preguntas frecuentes resuelven los límites que suelen quedar abiertos al llevar esta decisión a la operación.
Preguntas frecuentes sobre gobernanza de IA en empresas
¿Qué es la gobernanza de IA en empresas?
La gobernanza de IA en empresas define las políticas, responsabilidades, límites y evidencias que orientan el uso de inteligencia artificial. Cada empresa adapta esos controles a sus procesos, datos, obligaciones y nivel de riesgo.
¿Quién debe ser responsable de un uso de IA dentro de la empresa?
La empresa asigna un responsable operativo a cada uso de IA. Ese responsable coordina la decisión y sus revisiones, aunque tecnología, seguridad, privacidad o legal participen según el contexto.
¿Cada cuánto conviene revisar una política de uso de IA?
La empresa revisa la política de uso de IA cuando cambian las herramientas, los datos, los accesos, la finalidad o las condiciones del proveedor. Además, puede definir una revisión periódica acorde con su nivel de exposición.
¿Qué evidencia conviene pedir a un proveedor de IA?
La empresa solicita al proveedor evidencia sobre tratamiento y retención de datos, controles de acceso, registros de actividad, terceros involucrados, eliminación de información y respuesta ante incidentes. La profundidad de la revisión aumenta con la sensibilidad y el impacto del caso.
¿Cuándo debe intervenir una revisión legal, de privacidad o seguridad?
El nivel de riesgo determina cuándo intervienen las revisiones legal, de privacidad o seguridad. Estas revisiones pueden ser necesarias cuando el caso utiliza datos personales, confidenciales, regulados o restringidos por contrato, conecta sistemas críticos o permite acciones con impacto externo.
La gobernanza resuelve el acceso, no toda la implementación
Al llegar a este punto, la empresa ya puede decidir si una conexión está lista, necesita límites o debe esperar. Esa respuesta evita avanzar sin control, pero no decide si el caso merece prioridad, qué enfoque técnico necesita ni cómo debe probarse.
A partir de ahí comienza una decisión distinta: comparar el caso con otras oportunidades, elegir entre una herramienta, un workflow u otra alternativa, definir métricas y diseñar un piloto proporcional al riesgo.
