La mayoría de artículos sobre agentes de IA y modelos de lenguaje (LLM) se centran en la tecnología: qué modelo elegir, qué framework usar, cómo conectar herramientas. Esa parte, con las opciones actuales, se resuelve en días. Lo que decide si un agente termina resolviendo trabajo real o se queda en una demo que nadie vuelve a abrir después de la primera semana es la secuencia de decisiones que hay que tomar antes y durante la implantación: qué caso de uso elegir, cuánta autonomía darle, qué permisos hereda, qué no puede hacer nunca sin que lo revise una persona y cómo se prueba antes de que hable con un cliente real. Esta guía recorre esa secuencia paso a paso, pensada para una pyme española que quiere pasar de la curiosidad a un sistema que funciona todos los días.
Qué es —y qué no es— un agente antes de seguir
Antes de dar el primer paso conviene aclarar un término que se usa con demasiada libertad. Un LLM al que se le manda una instrucción y devuelve una respuesta —redactar un correo, resumir un documento, traducir un texto— no es un agente: es un modelo de lenguaje usado como herramienta puntual, y para la mayoría de estos usos no hace falta ninguna infraestructura adicional. Un agente, en el sentido en que lo usa esta guía, es un sistema que además decide qué pasos dar para completar una tarea, puede usar herramientas —consultar una base de datos, enviar un correo, actualizar un registro del CRM— y encadena esas acciones sin que una persona escriba cada paso intermedio.
La diferencia importa porque cada nivel exige una preparación distinta: un LLM simple necesita, sobre todo, un buen prompt; un agente necesita además permisos, guardarraíles y un plan para cuando se equivoca. Si todavía dudas cuál de las dos cosas encaja con lo que quieres resolver, conviene repasar primero la comparativa de opciones reales entre LLM y agentes antes de seguir con esta guía, porque el resto de pasos parte de que ya has elegido una de las dos vías.
Un LLM con un buen prompt y un agente con permisos y guardarraíles no son el mismo proyecto, aunque los dos usen el mismo modelo por debajo. Confundirlos es una causa habitual de calendarios que se disparan: se presupuesta como si fuera lo primero y se acaba construyendo, en realidad, lo segundo.
Paso 1 — Elegir un caso de uso acotado
El error más habitual al empezar no es técnico: es elegir «automatizar la atención al cliente» o «un agente para el back-office» como punto de partida, sin acotar más. Un caso de uso manejable tiene un disparador claro (llega un correo, se recibe una llamada, se sube una factura), un resultado medible (la factura queda registrada, el cliente recibe una respuesta correcta, el ticket se clasifica en la categoría correcta) y un volumen suficiente para que merezca la pena automatizarlo, pero no tan crítico como para que un primer fallo tenga consecuencias graves.
Procesar facturas de proveedor, clasificar correo entrante, cualificar leads que llegan por formulario o resumir actas de reunión son puntos de partida típicos en una pyme: se pueden medir en pocas semanas, y un fallo puntual se corrige sin que nadie fuera de la empresa lo note. Dejar «automatizar toda la atención al cliente» para cuando el primer caso ya funciona en producción, no para el primer sprint.
Paso 2 — Fijar el nivel de autonomía antes de escribir el primer prompt
Antes de escribir el primer prompt hay que decidir cuánta autonomía va a tener el sistema, porque esa decisión condiciona el resto del diseño. Conviene distinguir al menos tres niveles. El primero es de solo consulta: el agente lee información y responde preguntas, pero no modifica nada —un asistente que resume el estado de un expediente, por ejemplo—. El segundo es de propuesta con aprobación: el agente prepara una acción —una respuesta a un cliente, un asiento contable, un pedido a un proveedor— pero una persona la revisa y confirma antes de que se ejecute. El tercero es de ejecución autónoma: el agente actúa sin que nadie intervenga en cada caso, y solo se revisa el resultado por muestreo o cuando algo falla.
La tentación habitual es empezar por el tercer nivel porque es el que más automatiza, pero el orden correcto es el inverso: se empieza por consulta o por propuesta con aprobación, se mide durante semanas cuántas veces el agente acierta y cuántas se equivoca, y solo se sube de nivel cuando esa tasa de acierto está documentada, no estimada de memoria.
Paso 3 — Elegir arquitectura: LLM simple, RAG o agente con herramientas
Con el caso de uso y el nivel de autonomía decididos, toca elegir cómo se construye. Un LLM simple con un buen prompt basta cuando la tarea no necesita conocimiento específico de la empresa ni acceso a sistemas —redactar, resumir, clasificar texto que ya se le entrega completo—. Cuando la respuesta depende de documentación o datos internos que el modelo no conoce de memoria, hace falta añadir recuperación de información —lo que se conoce como RAG, o generación aumentada por recuperación—, que busca el fragmento relevante antes de generar la respuesta. Y cuando, además de consultar información, el sistema tiene que actuar sobre otros sistemas —crear un registro, enviar una notificación, consultar el stock en tiempo real—, hace falta la capa de herramientas que convierte al LLM en agente propiamente dicho: un conjunto de funciones concretas, con su propio contrato de entrada y salida, que el modelo puede decidir invocar según la conversación.
La mayoría de proyectos reales combinan las tres capas en distinta proporción; muy pocos casos de uso serios se resuelven con una sola.
Paso 4 — Elegir modelo, proveedor y dónde viven los datos
La elección de modelo suele generar más debate del que merece en esta fase: para la mayoría de casos de uso de una pyme, varios modelos de gama alta actuales resuelven la tarea con calidad suficiente, y la diferencia real está en el coste por uso, la latencia y las condiciones de tratamiento de datos del proveedor, no en pequeñas diferencias de calidad de escritura. Lo que sí importa desde el principio es decidir dónde va a vivir el dato que el agente consulta: si puede salir de la infraestructura de la empresa hacia una API en la nube, o si —por sector regulado, por cláusula contractual o por sensibilidad del dato— tiene que quedarse bajo control directo de la empresa.
Conviene distinguir además entre construir el agente con piezas propias y aprovechar un asistente ya integrado en las herramientas que la empresa usa. Microsoft 365 Copilot, por ejemplo, resuelve buena parte de los casos de uso de oficina —redactar, resumir, generar borradores sobre correo y documentos— sin montar nada a medida, aunque conviene tener claro qué se está comprando, porque hay dos productos distintos bajo el mismo nombre: el complemento Copilot Business, disponible hasta 300 usuarios y solo sobre planes Business Basic, Standard o Premium, cuesta 18,20 € (21,00 $) por usuario y mes con compromiso anual —15,60 € (18,00 $) en la promoción vigente hasta el 30 de septiembre de 2026— o 21,84 € (25,20 $) facturando mes a mes sin compromiso; la versión completa de Microsoft 365 Copilot, sin tope de usuarios y disponible tanto sobre planes Business como sobre Enterprise E3 o E5, cuesta 26,00 € (30,00 $) por usuario y mes con compromiso anual, o 27,30 € (31,50 $) facturando mes a mes con compromiso anual.
Para casos que no encajan en ese asistente genérico —un agente que actúa sobre el ERP, que atiende por WhatsApp, que orquesta varios sistemas a la vez— la alternativa habitual es construirlo con piezas propias: un modelo servido por API y una capa de orquestación, para la que muchas pymes usan n8n, una herramienta fair-code —bajo Sustainable Use License— que permite ver y modificar el código y usarlo internamente sin coste de licencia adicional, aunque restringe revenderlo o alojarlo como servicio para terceros, por lo que no es open source en el sentido estricto de la OSI.
Paso 5 — Diseñar las instrucciones y las herramientas que puede usar
El sistema de instrucciones —lo que en la jerga se llama el prompt de sistema— es el documento que define qué es el agente, qué tono usa, qué información tiene disponible y, sobre todo, qué debe hacer cuando no sabe la respuesta o cuando la petición se sale de su ámbito. Escribirlo bien lleva iteración: conviene empezar con una versión sencilla, probarla contra casos reales y ampliarla solo cuando un fallo concreto lo justifique, en lugar de intentar anticipar cada excepción posible desde el primer día.
Cuando el agente necesita actuar sobre otros sistemas, cada herramienta que se le entrega —enviar un correo, consultar un pedido, actualizar un campo— debe tener una descripción precisa de qué hace, qué parámetros necesita y qué puede fallar; un protocolo abierto como el Model Context Protocol (MCP) estandariza esa conexión entre el agente y las herramientas externas, lo que evita tener que reescribir la integración cada vez que se cambia de modelo o de proveedor. Cuantas menos herramientas tenga el agente al principio, más fácil es acotar dónde puede fallar: es preferible añadir una herramienta nueva cuando el caso de uso lo pide, no entregarle desde el primer día acceso a todo lo que podría necesitar algún día.
Paso 6 — Permisos: heredar, no inventar
El agente no debería poder ver ni tocar nada que la persona en cuyo nombre actúa no pudiera ver o tocar directamente. Si un empleado no tiene acceso a los datos de nómina de otro departamento, el agente que actúa en su nombre tampoco debería poder consultarlos, aunque técnicamente la herramienta que conecta con esos datos esté disponible en el sistema. El permiso debe heredarse del usuario o del proceso que invoca al agente, no decidirse aparte como una capa de seguridad genérica para todo el sistema.
Este diseño cuesta más tiempo al principio que dar acceso amplio y confiar en que el prompt «se comporte», pero evita el escenario más caro de corregir después: un agente que ya está en producción y que, por diseño, puede llegar a mostrar información que no debería.
Paso 7 — Guardarraíles: qué no puede hacer nunca sin aprobación humana
Además de los permisos técnicos, conviene fijar una lista explícita de acciones que el agente nunca ejecuta sin que una persona las apruebe, con independencia del nivel de autonomía general del sistema: operaciones que mueven dinero por encima de un umbral, comunicaciones que salen fuera de la empresa con contenido legal o contractual, cualquier decisión que afecte a una persona de forma individual —una solicitud de empleo descartada, una reclamación rechazada— y cualquier acción difícil o costosa de deshacer. Esta lista no sustituye a las pruebas ni a los permisos: es la última red cuando las dos anteriores fallan.
Conviene también decidir, antes de lanzar el sistema, quién es la persona responsable de revisar los casos que el agente escala o en los que se equivoca; sin ese nombre asignado, los fallos se acumulan sin que nadie los cierre, que es precisamente uno de los errores más caros al implantar agentes y LLM que solemos ver en proyectos que llegan a producción sin este punto resuelto.
Paso 8 — Cumplir la transparencia del artículo 50 desde el diseño
Si el agente interactúa directamente con personas —un cliente que escribe por chat, un candidato que habla con un asistente de selección, un usuario que llama a un agente de voz—, el artículo 50.1 del Reglamento (UE) 2024/1689 (AI Act) obliga a que esa persona sepa que está tratando con un sistema de IA, salvo que resulte evidente para alguien razonablemente informado y atento. Esta obligación es exigible desde el 2 de agosto de 2026, sin periodo transitorio: no hay margen para lanzarlo primero y añadir el aviso después.
Distinto es el marcado técnico de contenido generado —el requisito del artículo 50.2 de que el contenido sintético lleve una marca legible por máquina—, cuyo plazo se aplaza hasta el 2 de diciembre de 2026, y únicamente para proveedores de sistemas generativos que ya estaban comercializados antes del 2 de agosto de 2026; ese aplazamiento, introducido por el Reglamento (UE) 2026/1744 (Ómnibus Digital de IA, en vigor desde el 27 de julio de 2026), no se extiende a la obligación general de avisar de que se interactúa con IA, que sigue vigente desde agosto sin excepción.
El aplazamiento del marcado técnico de contenido sintético hasta diciembre de 2026 no aplaza el aviso de que se está hablando con un sistema de IA: esa obligación general del artículo 50.1 es exigible desde agosto, sin excepción para agentes conversacionales de atención al cliente, ventas o selección de personal.
En la práctica, cumplir esto no es complicado —un aviso visible al inicio de la conversación suele bastar—, pero conviene incorporarlo en el diseño del agente desde el primer prototipo, no como un parche justo antes de publicarlo. Si además el agente trata datos personales de clientes o candidatos, esa parte sigue rigiéndose por el RGPD exactamente igual que cualquier otro tratamiento de la empresa: el AI Act no sustituye esa obligación, la complementa.
Paso 9 — Probar con un banco de casos reales antes de producción
Antes de dar por lista la implantación, reúne entre veinte y cuarenta casos reales —preguntas, peticiones o situaciones que el agente va a encontrarse de verdad— y pruébalos uno a uno, registrando si la respuesta es correcta, si la acción que propone o ejecuta es la adecuada y si respeta los permisos y los guardarraíles definidos. Este banco de pruebas debe incluir también casos límite a propósito: peticiones ambiguas, información incompleta, intentos de que el agente haga algo fuera de su ámbito.
Un agente que funciona bien en los casos fáciles y falla en los límite no está listo para producción, aunque la demo con tres ejemplos preparados salga perfecta; la diferencia entre una demo convincente y un sistema evaluado es, de hecho, uno de los motivos por los que más proyectos se estancan después del piloto.
Paso 10 — Desplegar con supervisión y medir en producción
El primer despliegue en producción no debería ser «todo o nada»: empezar con un grupo reducido de usuarios o con un porcentaje del volumen real, mantener la revisión humana más cercana de lo que parece necesario y ampliar el alcance solo cuando las métricas lo respalden es la forma de detectar un problema de diseño antes de que afecte a todos los casos.
Conviene definir de antemano qué se mide: tasa de resolución sin intervención humana, tasa de escalado a una persona, tiempo medio de respuesta y, sobre todo, una muestra de casos revisados manualmente cada semana para detectar errores que las métricas automáticas no capturan, porque un agente puede cerrar un caso «con éxito» según su propia métrica interna y haber dado, aun así, una respuesta incorrecta.
Paso 11 — Mantenerlo vivo
Un agente no se entrega y se olvida. Los sistemas a los que se conecta cambian, la documentación que consulta se actualiza, y el propio modelo de lenguaje que lo sostiene recibe nuevas versiones con un comportamiento ligeramente distinto al que se probó en su día. Revisar con regularidad el banco de casos de prueba, ampliar los guardarraíles cuando aparece un caso nuevo que no se había previsto y volver a evaluar el sistema cada vez que cambia el modelo subyacente es lo que mantiene la calidad del agente en el tiempo, en lugar de dejar que se degrade en silencio hasta que un usuario reporta un fallo evidente.
Errores que conviene evitar en este proceso
- Dar autonomía de ejecución antes de haber medido la tasa de acierto en modo de propuesta con aprobación.
- Copiar los permisos «por defecto» del sistema en lugar de heredar los del usuario o proceso concreto que invoca al agente.
- Publicar el agente sin el aviso de transparencia del artículo 50 porque «ya se sabe que es un chatbot».
Estos tres son los que más veces frenan un proyecto ya avanzado; hay más —autonomía sin control, datos sin permisos por rol, pilotos que nunca se evalúan con criterio— y los repasamos con detalle en los errores más caros al implantar agentes y LLM.
Preguntas frecuentes
¿Cuál es la diferencia real entre usar un LLM y montar un agente?
Un LLM simple responde a una instrucción puntual: redacta, resume, traduce o clasifica lo que se le entrega en el propio mensaje, sin decidir ningún paso adicional. Un agente, además, decide qué acciones dar para completar una tarea y puede usar herramientas —consultar un sistema, enviar una notificación, actualizar un registro— encadenando esas acciones sin que una persona escriba cada paso intermedio. La consecuencia práctica es que un agente necesita, además de un buen prompt, permisos definidos y guardarraíles; un LLM simple normalmente no.
¿Por dónde debería empezar una pyme que nunca ha usado IA generativa?
Por un caso de uso acotado, con un disparador claro y un resultado medible en pocas semanas —clasificar correo entrante, procesar facturas de proveedor o resumir actas de reunión son puntos de partida habituales—, en modo de consulta o de propuesta con aprobación humana, nunca en modo de ejecución autónoma desde el primer día. Empezar por «automatizar toda la atención al cliente» sin haber acotado antes un caso más pequeño es la causa más frecuente de proyectos que se alargan sin llegar nunca a producción.
¿Es obligatorio avisar a los usuarios de que están hablando con IA?
Sí, desde el 2 de agosto de 2026 y sin periodo transitorio: el artículo 50.1 del AI Act obliga a que las personas sepan que interactúan con un sistema de IA, salvo que resulte evidente para alguien razonablemente informado. Es distinto del marcado técnico de contenido sintético del artículo 50.2, cuyo plazo sí se aplaza hasta el 2 de diciembre de 2026 para determinados proveedores; esa distinción conviene tenerla clara porque confundir ambos plazos lleva a lanzar un agente sin el aviso que sí es exigible desde agosto.
¿Necesito construir el agente desde cero o puedo usar un asistente ya integrado como Microsoft 365 Copilot?
Depende del caso de uso. Copilot resuelve bien tareas de oficina —redactar, resumir, generar borradores sobre correo y documentos— sin desarrollo a medida, con dos modalidades de precio según el plan de Microsoft 365 de partida. Para un agente que tiene que actuar sobre el ERP, atender por WhatsApp u orquestar varios sistemas a la vez, la vía habitual es construirlo con piezas propias: un modelo servido por API y una capa de orquestación.
¿Cuánto tiempo se tarda en tener un agente funcionando en producción?
Con un caso de uso bien acotado y sin necesidad de conectar sistemas complejos, un primer prototipo en modo de propuesta con aprobación puede estar probado con un banco de casos reales en pocas semanas. Lo que suele alargar el calendario no es la parte técnica, sino definir bien los permisos, redactar los guardarraíles y reunir el banco de pruebas con casos reales del negocio, que es trabajo que no se puede comprimir sin perder fiabilidad en el resultado.
Montar un agente o poner un LLM a trabajar dentro de la empresa es, sobre todo, una secuencia de decisiones bien ordenadas: qué caso de uso, cuánta autonomía, qué arquitectura, qué permisos y qué guardarraíles, en ese orden. La parte técnica, con las herramientas actuales, rara vez es el obstáculo. Si quieres revisar con criterio técnico por dónde empezar en tu empresa, el equipo de agentes de IA de Summum IA puede acompañar ese diagnóstico y el diseño del primer caso de uso.