Hay una diferencia enorme entre pedirle a una inteligencia artificial que redacte un correo y permitirle enviarlo. El texto puede ser idéntico; la responsabilidad, no. En el primer caso todavía queda una decisión humana antes de actuar. En el segundo, esa decisión tuvo que tomarse antes: al conectar herramientas, conceder acceso y fijar límites. La pregunta interesante no es solamente qué tan lista parece la IA, sino quién le dio las llaves y para qué puertas.
El cambio hacia los asistentes de IA que pasan de responder a decidir obliga a separar controles que suelen meterse en la misma bolsa. Como base documental, IBM describe los riesgos de usar IA sin autorización y propone políticas, límites de acceso, monitoreo y auditorías. Es una explicación de un proveedor tecnológico, no una medición independiente del desempeño de agentes. A partir de ella, conviene distinguir cuatro preguntas: qué se aprueba, qué se permite, quién interviene y qué queda registrado.
Una herramienta aprobada no tiene permiso para todo
Autorizar una herramienta significa aceptar su uso dentro de la organización bajo ciertas condiciones. Delimitar permisos es resolver algo más concreto: a qué información puede acceder y qué operaciones puede realizar. Una aprobación general no responde automáticamente esas preguntas. IBM plantea marcos de gobernanza con reglas sobre los sistemas permitidos, el manejo de información sensible y la capacitación necesaria. La lectura práctica es sencilla: aprobar el producto no sustituye la evaluación de cada uso.
Pensemos en un ejemplo hipotético: un asistente encargado de preparar respuestas para clientes. Consultar materiales aprobados, redactar un borrador y enviar el mensaje son tareas distintas, aunque aparezcan juntas en una interfaz. Para ese encargo convendría preguntar si necesita leer todo el historial, si puede modificarlo y si el envío requiere confirmación. No se trata de atribuir estas funciones a un producto específico, sino de desarmar una tarea aparentemente simple para ver dónde cambia el control.
El acceso a datos merece una conversación propia. ¿Qué información entra en la herramienta y quién aprobó compartirla? IBM advierte que el uso de aplicaciones no supervisadas puede exponer información sensible. Entre sus ejemplos aparece el análisis de conjuntos de datos empresariales mediante servicios externos sin autorización. La pregunta no termina en si el resultado es útil: también importa el recorrido de los datos. Un informe impecable no vuelve aceptable cualquier forma de obtenerlo.
Supervisar no es mirar cómo trabaja la máquina
La supervisión humana necesita una función concreta. Decir que alguien “está pendiente” deja sin resolver cuándo debe intervenir y qué puede detener. Como criterio de evaluación, conviene identificar las acciones que requieren aprobación previa y distinguirlas de las que pueden revisarse después. Una recomendación todavía puede rechazarse antes de ejecutarse; una acción ya realizada exige otro tipo de respuesta. La presencia de una persona en el proceso solo sirve si conserva una capacidad real de decisión.
En el ejemplo del correo, una confirmación antes del envío cumple una función diferente de revisar una muestra de mensajes al final del día. La primera condiciona la acción; la segunda examina lo ocurrido. Ninguna modalidad debería presentarse como equivalente a la otra. Antes de delegar, vale preguntar quién atiende una excepción, quién puede suspender el acceso y qué sucede cuando esa persona no está disponible. Son preguntas de diseño operativo, no garantías automáticas de seguridad.
Una bitácora no es la conciencia de la IA
La trazabilidad responde a otra necesidad: reconstruir lo ocurrido. Para evaluar un sistema, sería útil preguntar si sus registros permiten identificar la solicitud, los accesos utilizados, las acciones ejecutadas y las aprobaciones humanas asociadas. Esa es una propuesta de revisión, no una afirmación de que todas las herramientas registren esos elementos. IBM recomienda auditorías periódicas y monitoreo para detectar aplicaciones no autorizadas; revisar una cadena de acciones exige comprobar, además, qué información conserva realmente cada implementación.
Un registro puede ayudar a establecer que una acción ocurrió sin explicar por completo por qué el modelo la produjo. Tampoco basta guardar una respuesta final si la tarea incluyó pasos intermedios relevantes. Por eso conviene separar evidencia operativa de explicación: qué hizo el sistema, bajo qué permisos y con qué intervención humana no es exactamente lo mismo que conocer todo su razonamiento. Reconstruir responsabilidades requiere esa modestia: documentar lo comprobable, sin convertir la bitácora en una lectura de mente.
La IA no autorizada rompe el mapa antes de empezar
IBM define shadow AI como el uso de herramientas o aplicaciones de inteligencia artificial sin aprobación formal o supervisión del área de tecnologías de la información. El problema de control es distinto al de una herramienta autorizada que funciona mal: aquí puede faltar incluso el conocimiento de que se está usando. Si la organización desconoce el servicio, resulta más difícil verificar qué datos recibió, qué condiciones se aceptaron y quién debía revisar sus resultados. No hace falta un agente autónomo para abrir ese hueco.
La explicación tampoco se reduce a empleados imprudentes. IBM identifica motivos como acelerar tareas, resolver necesidades inmediatas o sortear opciones aprobadas que se perciben como insuficientes o lentas. Eso ayuda a entender la tensión: la facilidad de uso puede adelantarse al proceso interno de autorización. El atajo resuelve una fricción individual, pero deja preguntas para otros equipos. Si pedir permiso no ofrece una ruta clara, la política puede existir en un documento sin orientar las decisiones cotidianas.
Entre las medidas que IBM propone están el diálogo entre áreas técnicas y de negocio, entornos de prueba, controles de acceso y comunicación periódica sobre riesgos. El punto útil no es acumular prohibiciones, sino ofrecer una forma reconocible de experimentar sin borrar los límites. Una organización podría revisar si sus equipos saben dónde consultar una herramienta nueva y qué información pueden utilizar durante una prueba. La alternativa aprobada necesita ser identificable; de otro modo, “usa la IA correcta” queda demasiado abierto.
Control, productividad y cumplimiento son conversaciones distintas
Estos controles no responden por sí solos cuánto valor genera una herramienta. Como plantea la distinción entre medir resultados y contar entregables, producir más no equivale necesariamente a trabajar mejor. Del mismo modo, registrar más actividad no demuestra que el resultado sea correcto. Tampoco conviene confundir la supervisión interna con el debate sobre regulación y seguridad de la IA: documentar acciones puede apoyar una revisión, pero no acredita por sí solo el cumplimiento de una obligación legal específica.
Antes de delegar una tarea, queda una comprobación breve: ¿la herramienta está autorizada para ese uso?, ¿sus accesos corresponden al encargo?, ¿hay una persona con capacidad de intervenir?, ¿se podrá reconstruir lo ejecutado? Si una respuesta depende de “suponemos”, falta una conversación o una verificación técnica. Conservar el control no consiste en observar cada movimiento ni en frenar toda automatización. Consiste en poder explicar, después y con evidencia, quién permitió que ocurriera cada cosa.
