Agentes de IA para pymes: del primer proceso a un piloto medible

Un agente de IA puede consultar información y utilizar herramientas para completar una tarea. La distinción que recoge Anthropic en su artículo de diciembre de 2024 es útil: un flujo sigue pasos predefinidos; un agente decide parte del recorrido. Aquí usamos esa distinción como punto de partida conceptual. No asumimos que una arquitectura más autónoma produzca mejores resultados en tu empresa ni reproducimos una implementación de ese proveedor.

El resto de esta guía desarrolla una propuesta propia con un caso ficticio: Taller Norte recibe peticiones de mantenimiento por correo y las convierte en borradores de órdenes de trabajo. Cada petición puede incluir una máquina, un síntoma y una ubicación. El objetivo inicial es preparar una ficha que una persona pueda revisar. Enviar presupuestos, asignar técnicos y prometer fechas quedan fuera de esta primera versión.

Escribe una frase comprobable: «A partir de una petición, preparar una ficha con máquina, síntoma, ubicación y datos pendientes, enlazada al mensaje original». Si el equipo no acuerda esa frase, instalar herramientas solo trasladará la ambigüedad a otra pantalla. Guarda además dos ejemplos de fichas buenas y uno de una ficha que sería peligrosa por inventar una ubicación. Serán el comienzo de tus pruebas.

Antes de automatizar, acompaña a quien hace el trabajo. Anota qué mira primero, dónde busca una referencia y cuándo necesita preguntar. Una entrevista general suele producir frases como «leemos el correo y creamos la orden». Observar casos concretos revela detalles: una misma máquina tiene dos nombres, el remitente no siempre trabaja en la ubicación afectada y un archivo adjunto puede corregir el texto del mensaje.

Para el ejercicio, recoge veinte peticiones ficticias representativas: diez completas, cuatro sin ubicación, tres con identificadores ambiguos y tres que no son solicitudes de mantenimiento. Esa distribución es una muestra de aprendizaje elegida para esta guía, no una estimación del tráfico de una empresa real. Describe para cada caso el resultado esperado antes de probar ningún modelo. Así evitarás adaptar la respuesta correcta a lo que el sistema acaba de generar.

Mide también cuánto tarda una persona en resolver cada clase de petición y qué significa «terminada». Leer un borrador no equivale a haberlo corregido y guardado. Si comparas el tiempo manual completo con solo el tiempo de generación, el ahorro parecerá mayor de lo que realmente es. Conserva las excepciones: probablemente expliquen más sobre el diseño necesario que los diez casos fáciles.

Divide el proceso por decisiones. Comprobar que existe un identificador, validar una fecha o impedir dos órdenes con la misma clave son tareas que puedes expresar de forma determinista. Interpretar «hace un ruido raro desde ayer» y convertirlo en un resumen legible requiere otro tratamiento. No hace falta pedir al modelo que decida todo: puedes reservarlo para la parte de lenguaje y mantener el resto en código o reglas visibles.

En Taller Norte, la primera propuesta tiene cuatro pasos: recibir la solicitud, extraer campos, comprobar el resultado y guardar un borrador. El modelo no elige nuevas herramientas ni busca libremente por todas las carpetas. Aunque comercialmente alguien pudiera llamar agente al conjunto, lo relevante es entender su comportamiento. Dibuja el recorrido y marca cada paso donde una decisión depende del modelo; esos puntos necesitarán ejemplos y criterios de revisión.

Prueba primero si esta versión basta. La autonomía adicional tendría sentido si apareciera una necesidad concreta, como elegir entre dos fuentes autorizadas según el tipo de equipo. Incluso entonces, define qué decisiones puede tomar y cuántos intentos tiene. «Que investigue hasta resolverlo» no describe un límite operativo. Una ruta corta que se detiene cuando falta información puede ser más útil que una conversación larga que parece convincente.

Define la salida antes de redactar instrucciones. Nuestra ficha contiene solicitud_id, maquina_id, sintoma, ubicacion, datos_pendientes, evidencia y estado. Para cada campo, escribe su tipo y una condición de aceptación. La ubicación puede ser un texto o un valor vacío explícito; datos_pendientes es una lista; estado solo admite borrador o necesita_revision. El identificador de la solicitud procede del sistema de entrada, no de una invención del modelo.

Añade una regla para el conflicto: si el mensaje dice nave A y el adjunto dice nave B, la ficha debe mostrar la discrepancia. No conviene resolverla eligiendo la última cadena de texto encontrada. Guarda las dos evidencias y señala qué dato necesita confirmación. En este ejercicio, una ficha incompleta pero fiel a la entrada es preferible a una ficha aparentemente completa que oculta una suposición.

Prepara un ejemplo con datos suficientes y otro con datos ausentes. Pide que cada valor extraído pueda vincularse a un fragmento o a una consulta autorizada. Después comprueba esa relación fuera del modelo cuando sea posible: ¿el identificador existe en el catálogo permitido?, ¿la ubicación pertenece a ese equipo? Esta separación permite distinguir errores de formato, errores de extracción y conflictos reales del proceso.

Si la ficha necesita consultar instrucciones internas, empieza por un conjunto reducido y revisado. Para nuestro caso bastan un catálogo de máquinas, una tabla de ubicaciones y un procedimiento de clasificación. Registra quién mantiene cada documento, qué versión está vigente y qué equipo puede consultarlo. Una carpeta con cien archivos duplicados no se convierte en una fuente fiable por añadirle búsqueda semántica.

Crea deliberadamente un documento antiguo y comprueba cómo se distingue del vigente. Por ejemplo, el catálogo anterior ubica la máquina M-17 en la nave A y el actual la sitúa en la nave B. La prueba debe especificar la fecha o versión que gobierna la consulta. Si esa regla no está definida en el negocio, el sistema no puede descubrir por sí solo qué traslado fue autorizado. Necesitará una decisión del responsable del dato.

Separa los documentos de referencia del contenido enviado por terceros. Una frase dentro de un adjunto no tiene autoridad para cambiar el destino de una exportación ni ampliar permisos. Diseña la integración para que el contenido se trate como información que analizar. El control de herramientas, destinatarios y acceso debe vivir en la aplicación. En la guía sobre RAG encontrarás un ejercicio complementario para revisar recuperación, vigencia y evidencia por separado.

Escribe una tabla sencilla con herramienta, operación, alcance y persona responsable. En la primera versión, la cuenta de Taller Norte puede leer una carpeta de prueba y crear borradores en una lista concreta. No puede borrar documentos, enviar correos ni modificar el catálogo. La autorización debe aplicarse en las credenciales y en el servidor, aunque las instrucciones también describan esos límites. Un texto que dice «no borres» no elimina un permiso de borrado.

Prueba el límite con dos usuarios ficticios. Alicia puede consultar los equipos de la nave A; Bruno, los de la nave B. Haz la misma pregunta desde ambas identidades y comprueba que la respuesta no incluye registros del otro ámbito. Repite la prueba con búsquedas indirectas: preguntar por el último incidente de una máquina también puede revelar datos. Ocultar una fila en la interfaz no sustituye filtrar el acceso a la fuente.

Anota cómo retirar el acceso cuando termine el piloto. Evita depender de la cuenta personal de alguien que podría cambiar de puesto. Guarda las credenciales en la configuración del servidor y documenta qué conexión las utiliza, sin copiarlas al cuaderno ni al repositorio. El resultado de esta parte debería ser una lista breve de capacidades reales que otra persona pueda verificar, no una declaración genérica de seguridad.

Una instrucción útil contiene la tarea, las fuentes permitidas, el formato esperado y las condiciones para detenerse. Para el ejercicio: «Prepara un borrador de mantenimiento con la información de la solicitud y del catálogo autorizado. No inventes ubicación ni prioridad. Si hay conflicto, conserva las evidencias y marca necesita_revision». Añade los ejemplos que preparaste al definir la ficha. El objetivo es expresar decisiones, no acumular adjetivos como experto, preciso o infalible.

Incluye una entrada irrelevante: «¿Podéis enviarme vuestro catálogo comercial?». El resultado esperado es clasificarla fuera del proceso, sin fabricar una incidencia. Añade otra entrada que intente dar instrucciones al sistema dentro del mensaje. Comprueba que ese texto se interpreta como contenido de la petición y no como una orden para cambiar la configuración. Estas pruebas no demuestran protección universal, pero sí permiten detectar fallos concretos antes de conectar datos reales.

Versiona las instrucciones junto con los ejemplos. Si cambias una frase, vuelve a ejecutar los casos afectados y compara los resultados. No mezcles en la misma prueba un modelo nuevo, un catálogo distinto y una instrucción reescrita: perderías la capacidad de explicar qué provocó la mejora o el fallo. Guarda una breve razón para cada cambio, especialmente cuando altera cómo se tratan datos ausentes o peticiones fuera de alcance.

La primera ejecución puede funcionar con archivos locales y una pantalla de borradores. No necesita enviar mensajes ni escribir en el sistema definitivo. Prepara un recorrido visible: entrada recibida, extracción completada, validación superada y borrador disponible. Si una etapa falla, conserva el identificador y explica qué falta. Mostrar «algo ha ido mal» obliga a revisar todo el proceso; mostrar «ubicación no encontrada en catálogo v3» orienta la siguiente acción.

En el piloto ficticio, la persona revisora ve el mensaje original a la izquierda y los campos propuestos a la derecha. Puede aceptar cada campo, corregirlo o devolver la ficha para aclaración. Cuando cambia una ubicación, el sistema guarda la corrección y su motivo. Esa información sirve para mejorar los ejemplos de evaluación; no implica reentrenar automáticamente el modelo ni convertir cada edición en una regla permanente.

Evita añadir funciones que no ayudan a validar la hipótesis inicial. Un panel con veinte gráficos no resuelve si el borrador ahorra trabajo. Para esta fase basta saber qué se recibió, qué se propuso, qué corrigió una persona y cuánto tardó. Cuando esas cuatro preguntas tengan respuesta, podrás decidir si conviene integrar el sistema de órdenes. El prototipo habrá producido evidencia incluso si decides no continuar.

Si más adelante permites crear órdenes reales, la aprobación debe mostrar el contenido exacto: máquina, ubicación, descripción, destino y efecto. Un botón que dice «aprobar agente» es demasiado amplio para revisar una acción concreta. La persona debería poder comparar el borrador con la solicitud original y ver si algo cambió después de su revisión. Si cambió un campo relevante, pide una nueva aprobación antes de ejecutarlo.

En nuestro diseño, la aprobación queda asociada al identificador de la solicitud y a la versión del borrador. El servidor comprueba esa relación al crear la orden. No basta con que una respuesta del modelo contenga aprobado: la decisión viene de una interacción autenticada de la persona autorizada. El registro distingue quién aprobó de quién generó la propuesta y guarda el identificador que devolvió el sistema de destino.

Define también qué ocurre si la persona no responde. Para el piloto, el borrador permanece pendiente y aparece en una cola revisable; no se envía por vencimiento de un temporizador. Puedes fijar un aviso o una escalada interna, pero debe ser una regla explícita. Si la cola crece, mide su volumen y antigüedad: la automatización podría estar desplazando trabajo hacia revisión en lugar de reducirlo.

Imagina que el sistema de órdenes guarda una ficha, pero la conexión se corta antes de devolver la confirmación. Reintentar sin comprobar el estado podría crear una segunda orden. El problema no depende de la calidad del texto generado. Define una clave estable para la operación, por ejemplo solicitud más tipo de acción, y conserva su relación con el identificador de destino. La estrategia concreta dependerá de las garantías de la API que utilices.

En una prueba local, simula recibir dos veces la solicitud S-17. El resultado esperado es una sola orden asociada a esa petición. Después simula un fallo después de guardar y antes de responder. El proceso de recuperación debe consultar el estado registrado o reconciliarlo con el destino, no asumir que todo fallo significa que no ocurrió nada. Si no puedes conocer el resultado, marca la operación como incierta y envíala a revisión.

No uses solo el texto del mensaje como identificador: dos clientes pueden escribir la misma frase y representar trabajos distintos. Tampoco generes una clave nueva en cada reintento, porque perderías la relación con la operación original. Documenta qué se puede repetir de forma segura y qué exige comprobar el estado. El tutorial de idempotencia del sitio permite practicar este patrón con datos ficticios antes de adaptarlo a una integración real.

Una puntuación única esconde diferencias importantes. Separa al menos tres medidas: campos correctos, datos inventados y decisiones de revisión correctas. En una petición sin ubicación, dejar el campo vacío y pedir aclaración es un acierto. Rellenarlo con una ubicación plausible es un error aunque el resto de la ficha esté bien escrito. Cuenta también los casos que el sistema rechaza sin necesidad, porque obligan a repetir trabajo manual.

Para los veinte ejemplos iniciales, prepara una hoja con resultado esperado, resultado observado, evidencia y decisión. Revisa cada error con quien conoce el proceso. Tal vez una supuesta equivocación revele que el catálogo estaba desactualizado; tal vez dos personas discrepen sobre la prioridad porque no existe una regla compartida. Resolver esas ambigüedades forma parte del proyecto y no debería ocultarse ajustando una puntuación hasta que parezca buena.

Reserva después ejemplos nuevos que no hayas utilizado para afinar instrucciones. Incluye mensajes breves, largos, contradictorios y fuera de alcance. Repite algunos casos para observar variación. Este pequeño conjunto no garantiza el rendimiento futuro: sirve para detectar problemas y decidir la siguiente prueba. Define un criterio de parada claro, como cualquier acceso fuera de permiso o creación duplicada, separado de las mejoras menores de redacción.

Usaremos números inventados para aprender el cálculo, no tarifas de un proveedor ni una previsión comercial. Supón 600 solicitudes mensuales y seis minutos de trabajo manual por solicitud: son 60 horas. Si el nuevo proceso requiere dos minutos de revisión por solicitud, consume 20 horas. Si además atender excepciones y mantener la integración requiere ocho horas, el ahorro de capacidad sería 32 horas al mes, siempre que la calidad siga siendo aceptable.

Con un valor interno hipotético de 20 euros por hora, esas 32 horas equivalen a 640 euros de capacidad. Si herramientas, infraestructura y llamadas cuestan 90 euros mensuales, quedarían 550 euros antes de amortizar la construcción y considerar otros costes. No confundas capacidad liberada con dinero que entra en caja: depende de que el equipo aproveche ese tiempo y de cómo se comporten los costes reales. Tampoco ignores el coste inicial de preparar datos y pruebas.

Haz una segunda cuenta menos favorable. Si la revisión tarda cuatro minutos, son 40 horas más ocho de mantenimiento: solo se liberan doce horas. Su valor hipotético sería 240 euros y, restando 90, quedarían 150. Esta sensibilidad indica dónde medir con más cuidado. Registra consumo por solicitud, reintentos, almacenamiento y tiempo humano; consulta las tarifas vigentes de tus proveedores al preparar un presupuesto real.

El piloto debe tener un alcance que puedas explicar en una frase: una clase de petición, una ubicación y dos personas revisoras durante un periodo acordado. La duración depende del volumen necesario para observar casos relevantes; una semana sin solicitudes no aporta la misma evidencia que una semana con cincuenta. Escribe qué resultados permitirían ampliar, cuáles exigen corregir y cuáles obligan a detener la integración.

Mantén disponible el procedimiento manual. Si el servicio externo falla, las solicitudes deben seguir siendo localizables y alguien debe saber cómo procesarlas. Comprueba esa salida antes del lanzamiento: desactiva temporalmente la integración en un entorno de prueba y recorre una solicitud pendiente. Si solo la persona que programó el flujo sabe recuperar el trabajo, todavía existe una dependencia operativa importante.

Explica al equipo qué cambiará en su trabajo y qué seguirá requiriendo su criterio. En nuestro caso, el sistema propone campos y muestra evidencia; las personas deciden sobre conflictos y autorizan órdenes. Invita a registrar problemas específicos, con identificador y resultado esperado, en lugar de pedir opiniones generales sobre si les gusta la IA. Las observaciones concretas permiten mejorar el proceso y detectar cuándo una interfaz está añadiendo pasos innecesarios.

Diseña un registro operativo que permita responder preguntas concretas: qué solicitud entró, qué versión se utilizó, qué etapa falló y qué resultado quedó guardado. No necesitas copiar cada documento completo a todos los registros. En el ejemplo, basta una referencia al origen, identificadores de versión, tiempos, estado y motivo de revisión. Cuando necesites conservar una muestra para depurar, define su acceso y su plazo según las necesidades y obligaciones reales del proyecto.

Distingue los errores transitorios de los errores de contenido. Una conexión agotada puede justificar un reintento limitado; un identificador inexistente necesita corregir datos o pedir aclaración. Repetir diez veces una extracción sobre el mismo mensaje no resuelve una ubicación que nunca se proporcionó. Muestra al operador qué clase de problema ocurrió y qué acción está disponible, evitando exponer credenciales o contenidos de otros usuarios en los mensajes de error.

Prepara un resumen periódico con solicitudes recibidas, borradores revisados, pendientes, duplicados evitados, correcciones y tiempo de atención. Explica el denominador de cada porcentaje. Si recibiste veinte solicitudes y solo revisaste diez, una tasa de aceptación calculada sobre esas diez no describe todavía el conjunto. Conserva una forma de volver desde la métrica hasta los casos que la componen para investigar cambios inesperados.

Un piloto que funciona puede degradarse cuando cambia el catálogo, el modelo, una API o la forma en que las personas redactan las solicitudes. Define una persona responsable del proceso y otra de la integración, aunque ambas funciones recaigan en alguien del mismo equipo. Anota qué eventos requieren repetir pruebas: un campo nuevo, un permiso ampliado, un cambio de fuente o una actualización que altere la salida esperada.

Antes de desplegar un cambio, ejecuta el conjunto de casos guardados y revisa las diferencias. Si una nueva versión mejora los mensajes largos pero empieza a inventar ubicaciones en los cortos, no promedies ambos efectos hasta ocultar el problema. Compara por tipo de caso y conserva la versión anterior cuando técnicamente sea posible. Documenta también cómo volver al procedimiento manual si una dependencia externa no permite restaurar su comportamiento anterior.

Revisa el contenido de referencia con la persona que lo mantiene. Una orden correctamente extraída puede seguir siendo incorrecta si consulta una tabla obsoleta. Incluye en el mantenimiento preguntas sobre datos, permisos y carga de revisión, no solo sobre disponibilidad del servidor. El proyecto pertenece al proceso de negocio: si nadie puede explicar por qué una regla sigue vigente, conviene revisarla antes de ampliar la automatización a más equipos.

Al terminar el piloto, reúne una página de decisión con el problema inicial, los casos probados, los resultados, el coste completo y los límites conocidos. Incluye al menos un fallo relevante y cómo se resolvió o por qué permanece abierto. Un expediente que solo enseña ejemplos exitosos sirve para una demostración, pero ayuda poco a decidir si otras personas deberían depender del sistema todos los días.

Hay tres salidas razonables: ampliar el mismo proceso, corregir una limitación concreta o detenerlo. Ampliar no significa conectar todas las aplicaciones a la vez. Puedes incorporar una segunda ubicación manteniendo las mismas operaciones, repetir las pruebas de permisos y comparar si aumenta la revisión. Corregir puede consistir en mejorar el catálogo o eliminar un paso de la interfaz. Detener puede ser la mejor decisión si el volumen es pequeño o la tarea manual ya funciona bien.

Utiliza el cuaderno descargable de Eric Muriel para registrar estas decisiones y las guías relacionadas para profundizar en datos, documentos y validación. Si quieres practicar, empieza por los tutoriales con ejemplos locales antes de conectar sistemas de producción. El resultado que buscamos es un proceso entendible, verificable y mantenible. La tecnología elegida debería poder cambiar sin perder la definición del trabajo, los criterios de aceptación y el conocimiento que el equipo ha adquirido durante la prueba.