Antes de poner un agente de IA a trabajar, documenta esto
Un agente de inteligencia artificial puede redactar, clasificar, buscar, responder, actualizar registros o encadenar acciones entre varias herramientas. La demostración suele ser rápida. Lo difícil empieza cuando deja de ser una prueba y entra en un proceso real.
Antes de poner un agente de IA a trabajar, yo no empezaría por el modelo ni por la lista de funciones. Empezaría por documentar qué puede hacer, con qué datos, dentro de qué límites y quién responde cuando algo sale mal.
La diferencia entre una automatización útil y una fuente de problemas no está solo en la calidad de sus respuestas. Está en el diseño operativo que la rodea.
Un agente no es un chatbot con más botones
Un chatbot responde. Un agente puede actuar. Puede consultar documentos, generar propuestas, enviar información a otra aplicación, modificar un registro o decidir qué paso ejecutar después.
Esa capacidad resulta atractiva porque reduce trabajo manual. También amplía el impacto de cada error. Una respuesta incorrecta en una conversación puede corregirse. Una acción incorrecta sobre datos, clientes o procesos puede propagarse antes de que alguien la detecte.
Por eso trato un agente como trataría a un nuevo participante en un proceso: necesita una función concreta, acceso limitado, instrucciones verificables y una persona responsable.
1. Define el trabajo que puede iniciar y el que solo puede proponer
No todas las acciones necesitan el mismo nivel de autonomía. Conviene separar tres niveles:
- Consultar: leer información y preparar una respuesta sin modificar nada.
- Proponer: generar un borrador, una clasificación o una acción para que una persona la apruebe.
- Ejecutar: realizar el cambio directamente dentro de unas reglas cerradas.
La tentación es saltar al tercer nivel porque parece el más productivo. En muchos procesos, el segundo ofrece casi todo el ahorro con bastante menos riesgo. Si una decisión afecta a dinero, datos personales, compromisos con clientes o información pública, la aprobación humana suele ser el punto de partida más sensato.
2. Especifica qué datos puede consultar
“Acceder a la información de la empresa” no es un permiso. Es una ambigüedad peligrosa.
La documentación debería indicar las fuentes exactas: una carpeta, una base de conocimiento, una tabla, una cuenta de correo concreta o determinados campos de una aplicación. También debería dejar claro qué información queda fuera.
Yo aplicaría una regla sencilla: si el agente no necesita un dato para completar su función, no debería poder verlo. Esto reduce exposición, facilita las auditorías y obliga a pensar mejor el proceso.
También conviene diferenciar entre datos de lectura y datos que pueden modificarse. Consultar el estado de un proyecto no equivale a cambiarlo. Leer una lista de contactos no equivale a enviarles un mensaje.
3. Fija límites que una instrucción no pueda saltarse
Un texto del tipo “no hagas nada peligroso” no sustituye un control técnico. Las instrucciones ayudan, pero los límites importantes deben estar fuera del alcance del propio agente.
Algunos ejemplos:
- importe máximo que puede gestionar;
- número de registros que puede modificar en una ejecución;
- destinatarios o dominios autorizados;
- horarios en los que puede actuar;
- acciones que siempre requieren aprobación;
- datos que nunca pueden salir de la organización.
Si un límite solo existe en el prompt, depende de que el modelo lo interprete siempre bien. Si existe en permisos, validaciones y reglas de negocio, el sistema puede impedir el error.
4. Decide qué evidencia debe guardar
Un agente empresarial no debería limitarse a producir un resultado. Tiene que dejar rastro suficiente para entender cómo llegó hasta él.
Como mínimo, registraría:
- qué tarea recibió;
- qué fuentes consultó;
- qué herramientas utilizó;
- qué decisión propuso o ejecutó;
- qué persona la aprobó, cuando corresponda;
- qué cambió finalmente;
- qué error o excepción apareció.
No se trata de almacenar cada razonamiento interno del modelo. Se trata de conservar evidencia operativa: entradas, fuentes, acciones, aprobaciones y resultado.
Sin esa trazabilidad, una automatización puede parecer eficaz mientras todo funciona, pero resulta muy difícil de corregir cuando aparece una incidencia.
5. Diseña la intervención humana antes de necesitarla
“Habrá supervisión humana” tampoco es un proceso. Hay que concretar quién revisa, qué revisa, en cuánto tiempo y qué ocurre si no responde.
La revisión puede aplicarse por riesgo. Una acción rutinaria y reversible puede ejecutarse automáticamente. Una acción excepcional, sensible o difícil de deshacer debería detenerse y pedir validación.
También hace falta una salida manual. Si el agente no entiende una solicitud, encuentra información contradictoria o supera un umbral, debe transferir el caso con el contexto necesario. Pedir ayuda no es un fallo: es una función de seguridad.
6. Define cómo se detiene
Todo agente que puede actuar necesita un mecanismo claro de parada.
Puede ser una desactivación completa, la retirada de una credencial, el bloqueo de una integración o la suspensión automática al superar un número de errores. Lo importante es que no dependa de localizar primero al desarrollador que lo configuró.
Yo documentaría además qué ocurre con las tareas que ya estaban en curso y cómo se comprueba que la parada ha sido efectiva. Apagar una interfaz no garantiza que no queden procesos ejecutándose en segundo plano.
7. Mide el proceso completo, no la velocidad del agente
Un agente puede terminar su parte en segundos y, aun así, empeorar el proceso. Puede generar más trabajo de revisión, aumentar duplicados, trasladar errores a otra fase o producir resultados que nadie utiliza.
Por eso mediría el recorrido completo:
- tiempo total hasta el resultado válido;
- porcentaje de acciones corregidas;
- excepciones que requieren intervención;
- errores evitados y errores creados;
- coste técnico y coste de supervisión;
- resultado empresarial conseguido.
Las horas teóricamente ahorradas no bastan. El agente tiene sentido cuando mejora de forma verificable el proceso, no cuando simplemente genera más actividad.
La ficha mínima antes de conectar un agente
Antes de activar una automatización con capacidad de actuar, prepararía una ficha de una sola página:
- Objetivo: qué problema concreto debe resolver.
- Alcance: qué tareas puede hacer y cuáles quedan excluidas.
- Datos: fuentes autorizadas y nivel de acceso.
- Acciones: qué puede consultar, proponer y ejecutar.
- Controles: límites técnicos y validaciones.
- Responsable: quién aprueba y quién atiende incidencias.
- Trazabilidad: qué evidencias debe guardar.
- Parada: cómo se desactiva y cómo se verifica.
- Medición: qué resultado demostrará que aporta valor.
Esta ficha no sustituye el desarrollo. Evita empezar a desarrollar algo cuya responsabilidad nadie ha definido.
Empezar con menos autonomía suele ser avanzar más rápido
La forma más segura de implantar un agente no es diseñarlo para que haga todo desde el primer día. Es comenzar con lectura y propuesta, observar dónde falla, cerrar los límites y aumentar la autonomía solo cuando existe evidencia.
Ese enfoque puede parecer más lento en una demostración. En producción suele evitar correcciones costosas y permite que el equipo confíe en el sistema por motivos concretos, no por entusiasmo.
Ya escribí sobre por qué una empresa madura con IA debe saber qué pilotos abandonar. La misma idea se aplica aquí: la capacidad técnica no obliga a utilizar toda la autonomía disponible.
En mis proyectos, la pregunta útil no es “¿puede hacerlo la IA?”. Es “¿qué condiciones deben cumplirse para que pueda hacerlo sin perder control, trazabilidad ni responsabilidad?”.
Antes de delegar trabajo a un agente de IA, delega también los límites, la evidencia y la responsabilidad.
Preguntas frecuentes
¿Un agente de IA debe tener acceso a todos los datos de la empresa?
No. Debe acceder únicamente a las fuentes y campos necesarios para su función. Separar lectura, modificación y ejecución reduce riesgos y simplifica la auditoría.
¿Cuándo puede actuar sin aprobación humana?
Cuando la acción es de bajo riesgo, está suficientemente acotada, es reversible y cuenta con validaciones técnicas. Las decisiones sensibles o difíciles de deshacer deberían empezar como propuestas para revisión.
¿Qué es más importante: el prompt o los permisos?
Ambos cumplen funciones distintas. El prompt orienta el comportamiento; los permisos y reglas impiden acciones no autorizadas. Los límites críticos no deberían depender solo de una instrucción textual.
