Implementación de Function Calling en Modelos LLM para Automatización

¿Quieres que un modelo de IA deje de ser un loro elegante y empiece a hacer cosas reales por ti? Bienvenido a las Function calling.

Tiempo estimado de lectura: 5 min

Ideas clave

• Las Function calling permiten a un LLM devolver una estructura (normalmente JSON) indicando intención y parámetros para que el backend ejecute acciones reales.
• Existen dos estilos principales: JSON Schema (estricto) y formato libre (flexible), cada uno con trade-offs de seguridad y predictibilidad.
• Diseño seguro requiere validaciones, registros, sandboxes, rollback y, para operaciones críticas, un human-in-the-loop.
• Arquitectura práctica mínima: catálogo de herramientas, orquestador, executor aislado, auditoría y mecanismos de reversión.

Tabla de contenidos

• Título
• Ideas clave
• Introducción
• Resumen rápido (lectores con prisa)
• ¿Qué son, en una frase?
• ¿Por qué importa más que otra “nueva característica”?
• El ciclo real: cómo funciona sin volverte loco
• Dos estilos de herramientas
  • JSON Schema (estricto)
  • Formato libre (texto)
• ¿Cuándo usar cada una?
• Casos de uso que realmente importan
• Una advertencia sin eufemismos
• Regla de oro
• Human-in-the-loop
• Arquitectura práctica: qué componentes necesitas
• Un ejemplo mental (sin código complicado)
• Pistas y errores que nadie te dirá gratis
• Metáfora que pega y que funciona
• Urgencia realista
• ¿Quieres empezar ya?
• Dominicode Labs
• FAQ

Introducción

Poca gente habla claro sobre esto: las llamadas a funciones son la diferencia entre un chatbot inútil y un agente que mueve fichas en el mundo real. No es magia. Es arquitectura.

Resumen rápido (lectores con prisa)

Las Function calling permiten que un LLM deje de generar solo texto y devuelva una estructura (normalmente JSON) con intención y parámetros para que tu backend ejecute acciones reales. Usa JSON Schema para operaciones críticas y formato libre para prototipos; siempre valida y, para escrituras peligrosas, exige confirmación humana.

¿Qué son, en una frase?

Son el puente que permite a un LLM dejar de generar puro texto y pedirle a tu sistema: “oye, ejecuta esto”. El modelo no ejecuta nada por sí solo. Lo que hace es devolver una estructura (normalmente JSON) con la intención y los parámetros. Tu backend toma ese JSON, ejecuta la función y devuelve el resultado al modelo. Fin.

¿Por qué importa más que otra “nueva característica”?

Porque hasta ayer los LLMs eran como una enciclopedia parlante: óptimos para explicar, pésimos para actuar. Las Function calling rompen ese techo. Ahora el modelo puede:

• Consultar una base de datos en tiempo real.
• Lanzar un reembolso en Stripe.
• Generar y ejecutar una consulta SQL.
• Enviar un mensaje a Slack o disparar un workflow en n8n.

Es como si le dieras manos al loro: sigue hablando, pero ahora también abre puertas.

El ciclo real: cómo funciona sin volverte loco

No inventes un diagrama mental complejo. Hay cinco pasos claros y repetibles:

1. Tu app manda el prompt + la descripción de las herramientas disponibles.
2. El modelo decide: ¿lo puedo responder solo o necesito una herramienta?
3. Si necesita, devuelve un JSON con el nombre de la función y parámetros.
4. Tu backend valida y ejecuta la función real (API, DB, script).
5. Devuelves el resultado al modelo. Él sintetiza y responde al usuario.

Siempre hay una mano humana posible en el medio, sobre todo en operaciones peligrosas. Más abajo te explico por qué.

Dos estilos de herramientas: JSON Schema o texto libre

No todas las herramientas son iguales. Hay dos escuelas y cada una tiene su lugar.

JSON Schema (estricto)

Defines la función, tipos, campos obligatorios y enums. El modelo devuelve exactamente lo que espera tu backend. Es predecible, seguro y perfecto para integraciones REST y sistemas críticos. Ejemplo mental: la función crear_ticket exige titulo:string y prioridad:("alta"|"media"|"baja"). Punto y final.

Formato libre (texto)

El modelo genera un bloque de texto, código o comando. Ideal para análisis ad-hoc, scripts complejos o cuando necesitas flexibilidad absoluta. Requiere parsing robusto y sandboxes. Es más potente, pero también más peligroso si no controlas la entrada y la ejecución.

¿Cuándo usar cada una?

• Si tu operación cambia estados críticos (pagos, borrados, cambios de permisos): usa JSON Schema y validaciones humanas.
• Si estás haciendo análisis, prototipos o generación de consultas SQL que luego validarás: el modo libre puede acelerar prototipos, pero añade riesgo.

Casos de uso que realmente importan (no los anuncios)

• Customer Success: un agente recibe una queja, consulta el pedido en Shopify y, si procede, crea el reembolso en Stripe. Si la operación implica dinero, envía un checkpoint a un humano antes de ejecutar.
• DataOps: un usuario pide “ventas por región ayer”. El LLM traduce a SQL, ejecutas, devuelves los resultados y el modelo te da el resumen en lenguaje natural.
• Automatizaciones internas (n8n): en vez de tener flujos rígidos, el modelo decide qué nodos disparar, en qué orden y con qué parámetros, según la intención del usuario. Eso convierte tu automatización en dinámica, no en una secuencia predefinida.

Una advertencia sin eufemismos: los modelos mienten (a veces)

Alucinación de parámetros. Prompt injection. Errores sutiles. No es paranoia, es experiencia. Los LLMs pueden inventarse campos, malinterpretar enums o seguir instrucciones maliciosas ocultas en el prompt.

Regla de oro

• Automáticamente ejecuta lecturas (GET) si la operación es inofensiva.
• Para escrituras (POST/DELETE/PUT) exige validación adicional: reglas en el backend o confirmación humana. Siempre. No, no es opcional.

Human-in-the-loop: no es una filosofía, es ingeniería

La idea es simple: deja que el LLM proponga, pero que un humano o una lógica de negocio firme el cheque para operaciones críticas. Dos patrones útiles:

• Confirmación explícita: el LLM genera el payload, lo guardas y muestras a un humano para aprobar.
• Validación automática: reglas en el backend que verifican coherencia, límites y permisos antes de ejecutar.

Si haces esto bien, reduces riesgos drásticamente sin perder automatización.

Arquitectura práctica: qué componentes necesitas

No necesitas un stack del otro mundo. Necesitas disciplina.

1. Registro de herramientas: catálogo con descripciones y esquemas JSON.
2. Orquestador: recibe el JSON del LLM, valida y ejecuta. Aquí entra n8n, un backend propio o un servidorless.
3. Sandbox/Executor: si vas a ejecutar scripts generados por el modelo, hazlo en un entorno aislado.
4. Auditoría: logs de cada llamada, inputs y outputs. Esto no es solo para depurar; es para seguridad y cumplimiento.
5. Rollback y revocación: especialmente si permites crear o borrar recursos.

Un ejemplo mental (sin código complicado)

Usuario: “Reembolsa el pedido 123 si no se ha enviado.”

El LLM: decide que necesita verificar el estado del pedido → devuelve { action: "checkOrder", orderId: "123" }.

Tu backend: consulta y devuelve { status: "pending", paid: true }.

El LLM: con ese dato propone { action: "refund", orderId: "123", reason: "producto no enviado" }.

Tu backend: valida política de reembolsos y, si todo ok, lo ejecuta o pide OK humano.

Pistas y errores que nadie te dirá gratis

• Nunca confíes en que la respuesta del LLM está “bien formateada”. Valida siempre.
• Evita exponer funciones peligrosas sin restricciones de permiso.
• Ten límites de tasa para evitar loops: un LLM llamando a una función que regenere prompts puede convertirse en un bucle infinito.
• Si permites código, ejecútalo en containers efímeros con timeouts rígidos.

Metáfora que pega y que funciona

Las Function calling son como darle una tarjeta de crédito a un asistente. Con ella puede comprar lo que necesita, pero tú decides los límites, si necesita aprobación para ciertos tickets y a qué tiendas no puede entrar. Sin límites, te quedas sin dinero. Con límites y reglas, ganas productividad.

Urgencia realista

Si estás empezando a usar LLMs para interacción con sistemas reales y no diseñaste estas capas, estás pidiendo problemas. Empezar ahora con patrones sólidos (schemas, validaciones, humanos en la cadena) te ahorra migraciones dolorosas.

¿Quieres empezar ya?

Haz esto en 3 pasos prácticos:

1. Define las 3 funciones más críticas que quieres exponer (consulta de pedidos, emitir reembolso, crear ticket).
2. Escribe schemas JSON mínimos para cada una y prueba el loop: prompt → LLM → JSON → backend → resultado.
3. Añade validación humana para la más peligrosa y logs para todo.

No te dejo solo: ¿seguimos con la parte técnica?

Puedo enviarte:

• Un checklist para diseñar tus schemas JSON.
• Plantillas de orquestador para n8n con ejemplos de validación humana.
• Estrategias para sandboxing y rollback.

Respóndeme este mensaje y te doy la checklist completa y un ejemplo listo para copiar y pegar. Esto no acaba aquí: en la próxima entrega te muestro cómo migrar un flujo rígido de n8n a un agente LLM dinámico sin incendiar producción. ¿Te interesa?

Dominicode Labs

Si quieres ejemplos prácticos, plantillas y artículos relacionados con automatización, agentes y workflows, revisa Dominicode Labs. Es una continuación lógica para implementar patrones de Function calling en entornos productivos.

FAQ

• ¿Qué diferencia hay entre JSON Schema y formato libre?
• ¿Debo permitir que el modelo ejecute escrituras automáticamente?
• ¿Cómo prevengo loops entre el LLM y mis funciones?
• ¿Qué registros debo guardar?
• ¿Cuándo usar validación humana?
• ¿Es seguro ejecutar código generado por el modelo?