Inicio / Artículos / Agentes de IA

Agentes de IA

Construir agentes de IA que hacen trabajo real, no demos

Llamadas a herramientas, barreras de seguridad y la diferencia entre un chatbot vistoso y un agente al que le confiarías un flujo de trabajo.

Por Hagumi Lab· feb 2026· 10 MIN DE LECTURA ·Read in English →
Una mesa con pequeños interruptores etiquetados de latón y negro mate, relés y un dial de precisión cableados entre sí, con una luz indicadora turquesa encendida.

TL;DR — Un agente de demo habla. Un agente de producción actúa: a través de herramientas estrechas y bien nombradas, permisos de mínimo privilegio, operaciones idempotentes, reintentos, un bucle de evaluación, registro completo y un punto de control humano antes de cualquier acción irreversible. El modelo es la parte más pequeña y menos importante. La fontanería que lo rodea es el trabajo.

Es fácil filmar a un agente haciendo algo impresionante una vez. Conecta un modelo de lenguaje a un par de APIs, dale un prompt ingenioso, dale a grabar, y reserva una reunión o redacta una factura. Ese clip se gana las reacciones. Luego lo pones frente a entradas reales —un correo malformado, una solicitud duplicada, un nombre con un apóstrofo— y la magia se corta. La distancia entre una demo y un sistema que de verdad dejarías corriendo no es un modelo más inteligente. Es todo lo que rodea al modelo: las herramientas que puede alcanzar, los rieles que evitan que cause daño y el bucle que te dice si sigue funcionando. Así construimos agentes a los que estamos dispuestos a confiar un flujo de trabajo real.

Herramientas y acciones, no conversación

La salida de un chatbot es texto. La salida de un agente es cambio en el mundo: una fila escrita, un correo enviado, un reembolso emitido. Ese cambio lo es todo, y vive en cómo defines las herramientas.

Las buenas herramientas son estrechas e inequívocas. “Gestionar el calendario” es un deseo; create_event(start, end, title, attendees) es una herramienta. Cada una hace una sola cosa, valida sus entradas y devuelve un resultado estructurado sobre el que el modelo puede razonar. Un alcance así de ajustado hace tres favores: el modelo elige la herramienta correcta con más fiabilidad, puedes probar cada acción de forma aislada, y una llamada mala falla en pequeño en lugar de propagarse en cascada.

# Una herramienta que el modelo no puede usar mal con facilidad
name: refund_order
description: Emite un reembolso para un solo pedido. El monto no puede exceder el total del pedido.
input:
  order_id: string      # requerido, debe existir
  amount_cents: integer # requerido, > 0, <= total del pedido
  reason: string        # requerido, texto libre para el registro de auditoría
returns: { refund_id, status }

Haz cada acción idempotente siempre que puedas. Las redes se caen, los timeouts saltan, el modelo reintenta. Si “enviar factura” se ejecuta dos veces, al cliente no se le debería cobrar dos veces: pasa una clave de idempotencia, o comprueba el estado existente antes de escribir. Esta sola disciplina elimina toda una categoría de incidentes a las 2 de la madrugada.

Barreras de seguridad y mínimo privilegio

El agente más peligroso es el que tiene credenciales amplias y un tono amable. Trata al modelo como a un colaborador capaz al que conoces desde hace una semana: dale exactamente el acceso que la tarea necesita, y nada que no necesite.

  • Limita las credenciales, no el prompt. Un agente de informes de solo lectura recibe una clave de solo lectura. “Por favor no borres nada” en el prompt del sistema no es un control de seguridad.
  • Restringe en el límite de la herramienta. Pon un tope al monto del reembolso, una lista de destinatarios permitidos, rechaza escrituras fuera de la tabla esperada. Aplica los límites en código, donde el modelo no puede convencerte de saltárselos.
  • Separa las herramientas peligrosas. Leer datos y borrar datos no deberían vivir detrás del mismo permiso. La mayoría de los flujos necesitan mucho menos acceso de escritura del que se les concede.
  • Asume que la entrada es adversaria. La inyección de prompts es real: una página web o un correo pueden llevar instrucciones dirigidas a tu agente. La capa de herramientas —no las buenas intenciones del modelo— es lo que la detiene.

El modelo es el componente menos confiable del sistema. Diseña todo lo demás como si, tarde o temprano, fuera a equivocarse con total seguridad.

Verificación, evaluación y observabilidad

Una demo se juzga por una buena ejecución. Un agente de producción se juzga por las mil ejecuciones que nunca ves. Necesitas saber que sigue funcionando sin tener que mirarlo, lo que significa que el registro y la evaluación son funcionalidades, no ocurrencias tardías.

Registra cada paso: las entradas, las llamadas a herramientas, los argumentos, los resultados, la acción final. Cuando algo salga mal —y saldrá— querrás una traza que puedas reproducir, no un encogimiento de hombros. Trata estos registros como cualquier dato sensible: a menudo contienen información de clientes.

Luego cierra el bucle con un conjunto de evaluación: una colección fija de entradas reales y complicadas con resultados conocidos como correctos. Ejecútalo en cada ajuste de prompt, cambio de modelo o cambio de herramienta. Los modelos derivan; una versión nueva que es mejor con la poesía puede ser peor eligiendo tu herramienta refund_order. Sin evaluaciones, descubres esa deriva en producción, de boca de un cliente. Con ellas, la atrapas antes de desplegar. Sigue unas pocas métricas honestas: tasa de éxito de la tarea, tasa de herramienta equivocada y con qué frecuencia tuvo que intervenir un humano.

Puntos de control humanos para lo irreversible

La autonomía total es el valor por defecto equivocado para cualquier cosa que no puedas deshacer. La línea reversible/irreversible es la más útil que puedes trazar a través de las acciones de un agente.

El trabajo reversible —redactar una respuesta, etiquetar un ticket, proponer un horario— puede correr sin supervisión; el coste de un error es una corrección rápida. El trabajo irreversible —enviar dinero, borrar registros, escribir a un cliente, firmar un documento— debería pausarse para un humano hasta que el agente se haya ganado la confianza en esa acción concreta, medida por tus evaluaciones. El patrón es simple: el agente propone, una persona aprueba, la acción se dispara con la decisión del humano registrada junto a ella.

Esto no es falta de ambición. Es cómo entregas algo real este trimestre en lugar de perseguir una versión totalmente autónoma que nunca llega del todo. Mueve el punto de control antes a medida que los datos lo justifiquen.

La conclusión

Un agente digno de confianza no es un chatbot más inteligente: es una máquina pequeña y bien instrumentada. Herramientas estrechas con entradas validadas. Acciones idempotentes y reintentos. Credenciales de mínimo privilegio aplicadas en código. Registros que puedes reproducir y un conjunto de evaluación que ejecutas en cada cambio. Un humano en el bucle para todo lo que no puedas revertir. Acierta con ese andamiaje y un modelo modesto hace trabajo genuinamente útil, de forma fiable, mientras duermes. Sáltatelo, y el modelo más inteligente del mercado te sigue dando solo una gran demo.

Escrito por Hagumi Lab

The engineering & R&D notebook of Hagumi Studio. Escribimos lo que aprendemos construyendo y autoalojando las herramientas detrás de nuestro trabajo.

HAGUMISTUDIO.COM · X · RSS

No te lo pierdas

Recibe las notas del Lab en tu correo.

Un correo cuidado al mes — qué construimos, qué se rompió y qué haríamos distinto. Sin relleno.

Sin spam. Cancela cuando quieras · enviado con nuestro Listmonk autoalojado.