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

01 /Empieza por la tarea, no por el agente

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.

Esa diferencia importa más que el nombre del modelo. Si puedes escribir los pasos y las excepciones correctas, un flujo fijo suele ser más barato, rápido y fácil de probar. Usa un agente para la parte ambigua, no como adorno alrededor de un proceso que ya tiene reglas.

02 /Tareas que pueden ser un buen primer agente

Los mejores candidatos llegan como texto o documentos desordenados, pero terminan en un resultado estrecho y comprobable. Por ejemplo: clasificar solicitudes dentro de una cola que ya existe, encontrar la política relevante antes de que responda un compañero, comparar un documento del proveedor con un pedido o preparar un borrador que una persona ya revisa.

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 ejemplos reales suficientes, incluidos los incómodos, para probar antes de lanzar.

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.

Lo mismo ocurre cuando no hay una forma fiable de juzgar la respuesta. Un párrafo fluido puede esconder una decisión floja. Si quien revisa tiene que investigar el caso desde cero cada vez, el agente ha ahorrado poco y puede añadir una confianza que no merece.

05 /Diseña el traspaso a una persona antes que el caso perfecto

La revisión humana no es un botón que se añade al final. Decide qué verá quien revise: el material original, la acción propuesta, las pruebas utilizadas y qué ha cambiado. Aprobar y corregir debe ser tan sencillo que la gente use el sistema en vez de buscar atajos.

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 /Construye el piloto más pequeño que pueda demostrar que te equivocas

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, estrecha la tarea o usa reglas. Un piloto que demuestra que el agente no es la herramienta adecuada también ha evitado un error mayor.

07 /Limita lo que el agente puede ver y hacer

Dale herramientas hechas para una sola finalidad: leer un pedido, preparar una tarea, proponer una actualización. No le entregues una credencial general de base de datos ni una sesión de navegador sin restricciones. Valida en código corriente todos los argumentos de las herramientas, limita reintentos y gasto, y exige aprobación para 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á.