¿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
- ¿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:
- Tu app manda el prompt + la descripción de las herramientas disponibles.
- El modelo decide: ¿lo puedo responder solo o necesito una herramienta?
- Si necesita, devuelve un JSON con el nombre de la función y parámetros.
- Tu backend valida y ejecuta la función real (API, DB, script).
- 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.
- Registro de herramientas: catálogo con descripciones y esquemas JSON.
- Orquestador: recibe el JSON del LLM, valida y ejecuta. Aquí entra n8n, un backend propio o un servidorless.
- Sandbox/Executor: si vas a ejecutar scripts generados por el modelo, hazlo en un entorno aislado.
- Auditoría: logs de cada llamada, inputs y outputs. Esto no es solo para depurar; es para seguridad y cumplimiento.
- 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:
- Define las 3 funciones más críticas que quieres exponer (consulta de pedidos, emitir reembolso, crear ticket).
- Escribe schemas JSON mínimos para cada una y prueba el loop: prompt → LLM → JSON → backend → resultado.
- 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?
JSON Schema es estricto: defines tipos, campos y enums y el modelo debe devolver estructura predecible. Formato libre permite flexibilidad para análisis o scripts complejos, pero requiere parsing y sandboxes adicionales.
No. Para escrituras (POST/DELETE/PUT) exige validación adicional en backend o confirmación humana. Es la regla de oro indicada en el artículo.
Aplica límites de tasa y reglas que detecten y rompan llamadas recursivas. Evita diseños donde una función cause regeneración automática de prompts sin control.
Logs de cada llamada, inputs y outputs. Auditoría para depuración, seguridad y cumplimiento. Guarda también decisiones de validación y aprobaciones humanas.
Para operaciones críticas que afecten dinero, permisos o borrados irreversibles. También cuando las reglas automáticas no pueden garantizar seguridad suficiente.
Solo en sandboxes aislados, con containers efímeros y timeouts rígidos. El artículo recomienda ejecutar código en entornos aislados y con controles estrictos.
