Un equipo utiliza IA para resumir documentos. Otro la conecta a una aplicación y un tercero empieza a compartir una herramienta con clientes. Si cada iniciativa avanza por separado, puede resultar difícil saber qué datos utiliza cada sistema y quién responde cuando falla.
La gobernanza de IA organiza las decisiones, responsabilidades y controles que acompañan al uso de inteligencia artificial. Su función es que la empresa conozca qué utiliza, para qué lo permite y cómo revisa sus resultados y cambios.
No hace falta empezar con una política extensa que nadie consulta. Conviene establecer unas reglas que las personas puedan aplicar y una forma clara de resolver dudas antes de ampliar los usos.
Qué decisiones necesita ordenar la gobernanza
Algunas decisiones pertenecen al negocio, como aprobar el propósito de una herramienta. Otras requieren revisar datos, accesos, tecnología o consecuencias de un error. La gobernanza conecta esas responsabilidades para que no queden sin dueño.
El marco de gestión de riesgos de IA de NIST ofrece una referencia voluntaria para organizar estas cuestiones durante el ciclo de vida de los sistemas. Utilizarlo como orientación no demuestra por sí solo cumplimiento normativo ni sustituye una evaluación específica.
La propuesta de este artículo es operativa: saber quién decide, qué información necesita y qué evidencia debe quedar antes y después de poner un uso en marcha.
Empieza con un inventario que pueda mantenerse
Registra las herramientas y los casos de uso conocidos, incluyendo pilotos. No mezcles el nombre de una plataforma con todos los usos que pueda tener. Dos equipos pueden utilizar el mismo servicio con datos y consecuencias diferentes.
Una ficha inicial puede recoger:
- Responsable del uso y equipo que lo utiliza.
- Propósito permitido y situaciones que quedan fuera.
- Datos que recibe y sistemas a los que puede acceder.
- Personas afectadas por los resultados.
- Proveedor, versión o configuración relevante.
- Comprobaciones realizadas y fecha de revisión.
Mantén la ficha cerca del trabajo real y asigna quién la actualiza. Un inventario completo una sola vez puede quedarse desfasado en cuanto cambie una conexión o se añada una nueva función.
Distingue consultar, recomendar y ejecutar
No tiene las mismas consecuencias resumir un texto que modificar un registro. Tampoco es igual una ayuda para una persona que una respuesta que se envía directamente a un cliente.
Para cada uso, describe qué puede producir y qué acciones puede desencadenar. Si requiere aprobación humana, especifica quién revisa, qué debe comprobar y cómo puede rechazar el resultado. «Hay una persona supervisando» es una condición demasiado vaga.
Un ejemplo para delimitar permisos
En un ejemplo ilustrativo, un asistente podría localizar una instrucción y mostrar sus fuentes, sin autorización para aprobar una devolución. Si posteriormente se plantea que registre operaciones, habría que revisar de nuevo permisos, validaciones y recuperación.
Los asistentes y agentes empresariales pueden tener capacidades distintas. La gobernanza debería seguir el uso real y sus accesos, no solo la etiqueta comercial del producto.

Qué reglas conviene explicar al equipo
Las personas necesitan saber qué herramientas están autorizadas, qué datos pueden utilizar y cuándo deben consultar a un responsable. Añade ejemplos cercanos a sus tareas en lugar de limitarte a frases generales.
Proponemos que cada regla responda una pregunta práctica. ¿Se puede cargar un documento interno? ¿Se puede enviar una respuesta sin revisarla? ¿Dónde se comunica un resultado incorrecto? La respuesta dependerá de la herramienta, de los datos y del alcance aprobado.
Si una situación no está resuelta, ofrece un canal de consulta. Una norma que solo prohíbe sin explicar alternativas puede dejar el trabajo bloqueado o desplazarlo a herramientas que la empresa desconoce.
Cómo preparar una aprobación con evidencia suficiente
Antes de ampliar un uso, revisa qué se ha probado y con qué limitaciones. Una demostración satisfactoria no sustituye una evaluación con ejemplos representativos, errores y situaciones sin respuesta.
Para una consulta documental, por ejemplo, habría que comprobar fuentes y permisos. En la guía de RAG con documentos de empresa explicamos cómo separar esos aspectos de la calidad de la respuesta redactada.
Deja registradas las condiciones de la aprobación: usuarios incluidos, datos permitidos, acciones habilitadas y motivos para detener o revisar el uso. Así se puede detectar si una ampliación sale del alcance evaluado.
Qué hacer cuando cambia el sistema
Cambiar el modelo, una fuente o una instrucción puede alterar resultados. Proponemos identificar qué modificaciones exigen repetir pruebas y quién decide si se pueden llevar a producción.
No hace falta tratar todos los cambios igual. La revisión debe ser proporcional a su alcance y a las consecuencias posibles. Lo importante es que exista un criterio compartido y no dependa de recordar lo que se habló al principio.
Cómo organizar incidencias y retirada
Define cómo se informa de un problema y qué datos sirven para investigarlo sin difundir contenido sensible por canales inadecuados. El equipo debería saber cuándo puede seguir trabajando con revisión y cuándo tiene que detener el uso.
También conviene prever la retirada de una herramienta. Revisa conexiones, permisos y documentación cuando se deja de utilizar. Mantener accesos activos a un sistema abandonado puede generar dependencias difíciles de detectar más adelante.
Qué medir para saber si las reglas funcionan
Puedes revisar cuántos usos tienen responsable, cuáles mantienen su evaluación vigente y qué incidencias se repiten. Añade las dudas del equipo que quedan sin resolver y el tiempo que tarda una revisión.
La ausencia de incidencias registradas no demuestra que no existan problemas. Comprueba si las personas conocen el canal y si pueden utilizarlo sin una carga innecesaria. Ajusta las reglas cuando no permitan tomar decisiones con claridad.
Preguntas frecuentes
¿La gobernanza de IA consiste solo en redactar una política?
No. La política puede recoger criterios, pero hacen falta responsables, registros y revisiones que se apliquen a las herramientas y usos concretos.
¿Se debe revisar una herramienta aunque solo la use un equipo pequeño?
El alcance de la revisión puede ser menor, pero conviene conocer los datos, permisos y resultados que intervienen. Pocos usuarios no significa necesariamente pocas consecuencias.
¿Cómo se empieza sin crear una estructura demasiado pesada?
Selecciona los usos actuales, asigna responsables y acuerda las decisiones que necesitan revisión. Desde el servicio de estrategia y adopción de IA podemos ayudarte a ordenar ese punto de partida. Cuéntanos qué usos tenéis en marcha.