Agentes de IA para pymes: dónde ayudan y dónde no.

01 /Decide qué necesita la tarea

Una automatización normal sigue un recorrido definido: cuando llega una factura pagada, la adjunta al pedido correspondiente y cierra la tarea. A un agente se le da un objetivo y un conjunto limitado de herramientas, y decide algunos pasos: leer una solicitud poco habitual, elegir qué registro importa, pedir un dato que falta o preparar una respuesta.

Si puedes definir los pasos y las excepciones, un flujo fijo suele ser más sencillo de mantener y probar. Un agente puede resultar útil en la parte que requiere interpretación, siempre que puedas comprobar su resultado.

Antes de elegir un modelo, comprueba cuándo compensa automatizar un proceso con reglas.

02 /Tareas adecuadas para una primera prueba

Un buen punto de partida es una tarea que recibe texto o documentos de formatos distintos y debe producir un resultado concreto y comprobable. Por ejemplo: clasificar solicitudes en una lista existente, localizar la política pertinente para responder, comparar un documento del proveedor con un pedido o preparar un borrador para revisión.

La tarea debe repetirse lo suficiente como para medirla, tolerar una pequeña espera y contar con ejemplos de resultados aceptables. También necesita una salida clara: si las pruebas se contradicen, falta un campo o hay demasiada incertidumbre, el agente debe detenerse y pasar el caso a una persona en vez de improvisar.

• Una persona puede comprobar el resultado deprisa sin repetir todo el trabajo.
• Los documentos disponibles contienen pruebas suficientes para decidir.
• Un error se puede contener antes de afectar a dinero, accesos o promesas a clientes.
• Las herramientas ofrecen acciones pequeñas, no una cuenta con poder ilimitado.
• Hay suficientes ejemplos reales, incluidos errores y excepciones, para hacer pruebas antes de publicarlo.

Si la tarea conecta programas existentes, compara qué son los bots y RPA y cómo trabajan juntos.

03 /Ejemplo práctico: clasificar un buzón compartido

Imagina una empresa ficticia de mantenimiento con un único buzón para averías, solicitudes de presupuesto y mensajes de proveedores. Hoy una coordinadora lee cada correo, busca al cliente en el sistema de trabajos, crea una tarea y reenvía lo urgente. El agente útil no «gestiona atención al cliente». Extrae unos pocos campos, consulta un cliente, propone categoría y urgencia, y deja una tarea preparada para revisión.

El flujo fijo sigue comprobando los campos obligatorios, escribe la tarea aprobada y envía el acuse estándar. Una persona aprueba lo urgente y lo que el agente no puede asociar. Así el modelo se ocupa de leer lo variable, mientras las promesas al cliente y los cambios en la base de datos siguen siendo deterministas.

El piloto se puede evaluar con los mensajes de un mes anterior: categoría correcta, cliente correcto, urgencias omitidas, escalados innecesarios y tiempo de revisión. «Las respuestas parecen buenas» no es un criterio de lanzamiento.

04 /Qué debería seguir siendo predecible

No pidas a un modelo que calcule un precio que ya tiene fórmula, decida un permiso que ya tiene política o mueva dinero porque un mensaje parece convincente. Los cálculos exactos, el control de acceso, la retención legal, los cambios de inventario y los pagos finales pertenecen al código y a reglas explícitas. El agente puede reunir pruebas o explicar una excepción; el sistema debe imponer el límite.

Si no hay una forma fiable de comprobar la respuesta, conviene mantener la decisión en manos de una persona. Un texto bien redactado puede contener errores. Si revisarlo exige repetir toda la investigación, es posible que el agente no ahorre tiempo.

05 /Define cuándo debe intervenir una persona

Define qué verá la persona que revise el resultado: el material original, la acción propuesta, la información utilizada y los cambios. El sistema debe permitir aprobar o corregir la propuesta sin pasos innecesarios.

Define condiciones que siempre requieran revisión: importes altos, clientes nuevos, datos sensibles o documentos contradictorios. Deja pasar casos ordinarios de poco impacto solo cuando la tasa de error medida lo respalde. Conserva la entrada original y un registro de acciones para poder reconstruir una decisión.

Las guías de riesgo de IA del NIST tratan la gobernanza, las pruebas, la observación y la asignación clara de responsabilidades humanas como un trabajo continuo, no como una lista que se marca una vez. En una pyme la implementación puede ser modesta, pero los responsables también deben tener nombre.

06 /Prueba una tarea concreta y mide los resultados

Elige un canal de entrada, un tipo de caso y una salida. Ejecuta primero el agente sobre ejemplos históricos y luego en paralelo, sin intervenir en el proceso actual. Registra cuándo acierta, cuándo se abstiene, cuánto cuesta y cuánto tarda la revisión. Incluye casos deliberadamente difíciles en vez de pulir una demo alrededor de los diez más fáciles.

Fija una condición de parada antes de probar: por ejemplo, ninguna urgencia omitida en el conjunto de pruebas, una reducción clara del tiempo de revisión y un coste máximo por caso. Si no se cumple, reduce el alcance de la tarea o usa reglas. Un piloto que demuestra que el agente no es la herramienta adecuada también ha evitado un error mayor.

Para acotar esa prueba, distingue qué demuestra una demo, un prototipo y un MVP.

07 /Limita lo que el agente puede ver y hacer

Limita cada herramienta a una función concreta: leer un pedido, preparar una tarea o proponer una actualización. Evita credenciales generales de base de datos y sesiones de navegador sin restricciones. Valida los argumentos mediante código, limita los reintentos y el gasto, y exige aprobación para las acciones irreversibles.

Trata los documentos, páginas web y correos entrantes como datos no fiables. Pueden contener instrucciones dirigidas al modelo en vez de al proceso de negocio. Separa ese contenido de las instrucciones del sistema, restringe permisos y registra llamadas y resultados. OWASP describe el exceso de agencia—demasiadas funciones, permisos o autonomía—como un riesgo central de estos sistemas.

Por último, prepara el cambio. Los modelos, las instrucciones y los documentos fuente evolucionan. Conserva un pequeño conjunto de casos reales, vuelve a ejecutarlo antes de cada cambio y observa los resultados en producción en vez de dar por hecho que el acierto de ayer continuará.

Para entender cómo cambia esta revisión con modelos más capaces, lee agentes de hacking con IA: avances reales y límites.