¿Puede un asistente de IA actualizar el sistema de gestión? Cómo delimitar las acciones

Un asistente que se equivoca en una respuesta se corrige releyendo. Un asistente que se equivoca en una escritura deja un dato erróneo en el sistema de gestión, y de ahí parten una factura, una entrega o una llamada a un cliente. Es la misma tecnología, pero el riesgo cambia de naturaleza: se pasa de una información discutible a una operación consumada.

La pregunta «¿puede la inteligencia artificial actualizar el sistema de gestión?» tiene por tanto una sola respuesta útil: sí, sobre operaciones definidas de antemano, con permisos propios, con un control antes de la escritura y con un registro de lo que ha hecho. El trabajo está todo en decidir qué operaciones.

Leer, proponer, escribir: tres niveles, tres riesgos

La distinción más útil no es técnica sino organizativa, y tiene que ver con quién asume el resultado.

Casi todos los proyectos útiles viven en los dos primeros niveles. El tercero se concede a las operaciones repetitivas y reversibles; el cuarto, en la práctica, no se concede.

El asistente no es un administrador: hereda los permisos de un rol

El error de configuración más frecuente es conectar el asistente con un acceso que puede hacerlo todo, porque es más rápido de configurar. A partir de ese momento cada límite depende únicamente de las instrucciones dadas al modelo, es decir, de la parte más fácil de sortear.

• El asistente tiene su propio usuario, distinto de los de las personas, con los permisos mínimos para las tareas asignadas.
• Si responde a usuarios distintos debe ver lo que vería ese usuario: un comercial no debe poder obtener a través del asistente datos que el sistema de gestión le niega.
• Las herramientas conectadas son una lista cerrada. «Puede consultar la base de datos» no es una lista: es un acceso general con otro nombre.
• Las pruebas se hacen en un entorno separado, no con los datos de producción, y hay que repetirlas cada vez que cambian los permisos.

Las escrituras se delimitan por campo, no por buenas intenciones

Delimitar significa escribir la lista de las operaciones admitidas, cada una con sus campos y sus condiciones. Lo que no está en la lista no es posible, no es desaconsejado: la diferencia está toda ahí.

• Qué campos puede tocar la operación, y cuáles permanecen de solo lectura incluso cuando el asistente habla de ellos.
• Qué valores están admitidos: una fecha futura, un estado entre los previstos, un cliente que exista. La validación está en el sistema, no en las instrucciones escritas al modelo.
• Sobre qué registros: los propios, los abiertos, los del periodo actual. El caso «actualiza todos los clientes» no debe poder existir.
• Cuántas veces: un límite al número de operaciones por sesión impide que un malentendido se convierta en un trabajo de horas que anular a mano.

Un flujo de ejemplo: cambiar una cita

Operación repetitiva, de bajo riesgo, con un cliente al otro lado. Secuencia ilustrativa.

1. Llega una solicitud: «¿Puede venir el técnico del jueves el viernes por la mañana?». El asistente identifica de qué cita se trata y, si los datos no bastan, pregunta en lugar de adivinar.
2. Verifica las condiciones: la cita existe, no está ya cerrada, quien escribe tiene derecho a cambiarla, la nueva fecha está disponible para ese técnico.
3. Prepara la propuesta con los valores rellenados: fecha antigua, fecha nueva, técnico, cliente.
4. Muestra la propuesta a quien debe autorizarla y espera un consentimiento explícito. El consentimiento vale para esa propuesta, no para las siguientes.
5. Ejecuta solo la operación autorizada, con un identificador que impide aplicarla dos veces si la solicitud se repite.
6. Registra el resultado y comunica qué ha cambiado. Si la operación no funciona, lo dice abiertamente: un asistente que informa de un éxito que nunca ha ocurrido es peor que uno que se equivoca.

El paso que se recorta primero, y que en cambio lo sostiene todo, es el cuarto. Sin una confirmación explícita el sistema ya no está delimitado: solo está bien instruido, y las instrucciones no son un límite.

Duplicados, repeticiones y cómo se vuelve atrás

Las solicitudes se repiten: alguien vuelve a escribir, la red se cae, el asistente lo intenta de nuevo. Si cada intento produce una operación, se acaba con tres citas cambiadas y dos avisos enviados al cliente.

• Cada operación lleva un identificador derivado de la solicitud: si llega dos veces, la segunda no produce nada.
• Antes de crear algo se busca si ya existe: un cliente, un pedido, una cita parecida el mismo día.
• Para cada operación hay que escribir cómo se anula y quién puede hacerlo. Algunas son reversibles, otras no: un mensaje enviado a un cliente no se retira, y esto basta para incluirlo entre las que requieren una confirmación humana.
• Las operaciones hechas en secuencia hay que pensarlas como un bloque: si la tercera falla, hay que decidir de antemano si las dos primeras se quedan o hay que anularlas.

El registro: qué, cuándo, a petición de quién

Sin registro no se puede responder a la pregunta que tarde o temprano llega: ¿por qué se ha cambiado esta cita? El registro sirve para reconstruir, no para culpar.

• La solicitud original, la operación ejecutada y los valores escritos.
• Quién ha autorizado, cuándo y a través de qué canal.
• El resultado, incluidos los intentos fallidos y las operaciones rechazadas por los controles.
• Cuánto tiempo se conserva y quién puede consultarlo: el registro contiene datos de la empresa y a veces personales, y se protege como el resto.

Los rechazos registrados son la parte más útil en los primeros meses: dicen qué ha intentado hacer el asistente y no ha podido. Es a partir de ahí como se entiende si los límites son demasiado estrechos o demasiado amplios, sin tener que descubrirlo por un error.

Lo que esta guía no cubre

Aquí se trata el control de las acciones: qué operaciones están permitidas, quién confirma, cómo se registran. Las verificaciones técnicas para conectar dos programas entre sí, es decir, qué expone cada uno y qué ocurre cuando uno cambia, son un tema aparte. También lo es la defensa frente a las instrucciones engañosas escondidas en los documentos o en los mensajes que lee el asistente: es un riesgo distinto, con contramedidas propias.