Pasas el mensaje de un usuario a la API de GPT y, en lugar de una respuesta en lenguaje natural, el modelo te devuelve un objeto JSON estructurado que te dice exactamente qué función llamar y con qué argumentos. Eso es las llamadas a funciones — y cambia el tipo de aplicaciones que puedes construir con LLMs.
La mayoría de los desarrolladores escuchan “function calling” y suponen que el modelo está ejecutando código en su nombre. No es así.
Al usar llamadas a funciones, el propio LLM no ejecuta la función. En su lugar, identifica la función adecuada, reúne todos los parámetros requeridos y proporciona la información en un formato JSON estructurado.
Tu aplicación sigue siendo responsable de ejecutar la lógica real. El modelo solo te indica qué ejecutar y con qué entradas.
Esa distinción importa más de lo que parece, y da forma a todo, desde cómo diseñas tu integración hasta cómo piensas en la seguridad.
Qué son las llamadas a funciones — y en qué se suele fallar
Las llamadas a funciones (también conocidas como llamadas a herramientas) proporcionan una forma potente y flexible para que los modelos de OpenAI se conecten a sistemas externos y accedan a datos fuera de su entrenamiento.
El nombre es la primera fuente de confusión. La gente cree que el modelo está ejecutando algo. No es así.
Hay muchos nombres y explicaciones para las llamadas a funciones, pero todo se reduce a una afirmación: “las llamadas a funciones son un tipo de capacidad de salida estructurada de un modelo de lenguaje grande”. Los LLMs no llaman a ninguna función por sí mismos; sugieren qué función deberías llamar de entre funciones predefinidas que tú proporcionas al LLM en un prompt.
La segunda confusión tiene que ver con la superficie de la API antigua.
Los parámetros functions y function_call se han quedado obsoletos con el lanzamiento de la versión 2023-12-01-preview de la API. El reemplazo de functions es el parámetro tools.
Si estás siguiendo un tutorial que usa el parámetro antiguo functions, ya estás trabajando con sintaxis obsoleta. Usa tools y tool_choice en su lugar.
Una función es un tipo específico de herramienta, definida por un esquema JSON. Una definición de función permite que el modelo pase datos a tu aplicación, donde tu código puede acceder a datos o realizar acciones sugeridas por el modelo.
Ese esquema es lo que le da a las llamadas a funciones su ventaja de fiabilidad sobre el simple prompting: no estás esperando a que el modelo formatee la salida correctamente, estás imponiendo la estructura a nivel de API.
Cómo funcionan las llamadas a funciones en la API de OpenAI — paso a paso
Las llamadas a herramientas son una conversación de varios pasos entre tu aplicación y un modelo a través de la API de OpenAI. El flujo de llamadas a herramientas tiene cinco pasos de alto nivel: hacer una solicitud al modelo con las herramientas que podría llamar...
Esto es lo que realmente parece cada uno de esos pasos en la práctica.
Paso 1: Define los esquemas de tus funciones. Describes cada función disponible como un objeto JSON dentro del parámetro tools. El esquema incluye el nombre de la función, una descripción en lenguaje natural que el modelo usa para decidir cuándo invocarla, y un bloque parameters que sigue las convenciones de JSON Schema.
Cuanto más detallada sea tu description —en términos de las situaciones en las que puede y debe llamar a la función—, mejor. Ten en cuenta, sin embargo, que las descripciones de funciones forman parte del prompt y, por lo tanto, consumen tokens igualmente.
Paso 2: Envía la solicitud. Llamas a la Chat Completions API con el mensaje del usuario y tu lista de tools. El modelo ve ambos.
Paso 3: El modelo decide si llamar a una función.
Una llamada a función se refiere a un tipo especial de respuesta que puedes recibir del modelo si examina un prompt y determina que, para seguir las instrucciones, necesita llamar a una de las herramientas que tiene disponibles. Si el modelo recibe un prompt como “¿Cuál es el clima en París?”, podría responder con una llamada a la herramienta get_weather, con París como el argumento de ubicación.
Paso 4: Tu código ejecuta la función. Analizas la respuesta del modelo, extraes el nombre de la función y los argumentos, y ejecutas el código real en tu runtime. La API devolvió JSON estructurado — tú decides qué hacer con él.
Paso 5: Envía el resultado de vuelta.
Luego envías toda la definición de la herramienta, el prompt original, la llamada a la herramienta del modelo y la salida de la llamada de la herramienta de vuelta al modelo para finalmente recibir una respuesta de texto
— algo como “El clima en París hoy es de 25 °C”.
Un detalle que la mayoría de los tutoriales pasan por alto:
cuando configuras strict: true en la definición de tu función, Structured Outputs garantiza que los argumentos generados por el modelo para una llamada a función coinciden exactamente con el JSON Schema que proporcionaste.
Configurar strict en true garantizará que las llamadas a funciones cumplan de forma fiable con el esquema de la función, en lugar de ser un esfuerzo “best effort”. OpenAI recomienda habilitar siempre el modo estricto.
Siempre. No hay una buena razón para no hacerlo.
También hay que conocer las llamadas a funciones en paralelo.
Dependiendo de la consulta del usuario, el modelo invocará llamadas a funciones en paralelo si usas los modelos más recientes lanzados el 6 de noviembre de 2023 o posteriormente.
Esto significa que una sola solicitud como “¿Cuál es el clima en Londres y Tokio?” puede desencadenar dos llamadas a herramientas simultáneas en lugar de encadenarlas secuencialmente.
Casos de uso reales de las llamadas a funciones
El ejemplo del clima está en todas partes porque es limpio. Los casos de uso reales en producción son más desordenados e interesantes.
Flujos de soporte al cliente con datos en tiempo real
Las llamadas a funciones son útiles para una gran cantidad de casos de uso — por ejemplo, un asistente de IA que necesita obtener los datos de cliente más recientes de un sistema interno cuando un usuario pregunta “¿Cuáles son mis pedidos recientes?” antes de poder generar una respuesta.
El modelo determina la intención, extrae el ID de cliente del contexto y llama a la API interna de tu CRM. Sin regex frágiles. Sin plantillas de prompt lo bastante delicadas como para romperse por una coma faltante.
Extracción de datos estructurados a escala
Una canalización de extracción de datos que obtiene texto sin procesar, lo convierte en datos estructurados y lo guarda en una base de datos es otro buen encaje. Obtienes esquemas consistentes en miles de documentos sin ajustar a mano la lógica de análisis por tipo de documento.
De lenguaje natural a llamadas de API
Soluciones impulsadas por LLM para extraer y etiquetar datos, aplicaciones que pueden ayudar a convertir lenguaje natural en llamadas de API o consultas de base de datos válidas, y motores de recuperación de conocimiento conversacional que interactúan con una base de conocimiento: todos se benefician de la garantía de formato de salida de las llamadas a funciones. Cuando necesitas que la salida impulse sistemas downstream, no puedes tolerar la variabilidad.
Flujos de trabajo agénticos con múltiples herramientas
Para desarrolladores, las llamadas a funciones permiten acceso a datos en tiempo real para superar los límites de entrenamiento obteniendo precios de acciones, clima o entradas recientes de bases de datos. También habilitan la ejecución de acciones — transformando al LLM de un observador pasivo a un participante activo que modifica el estado, como enviar correos, actualizar CRMs o desplegar código.
La distinción clave respecto a un chatbot simple: el modelo no solo genera texto, está orquestando operaciones reales en tus sistemas.
Buenas prácticas de llamadas a funciones — lo que los desarrolladores suelen hacer mal
Esta es la sección que la mayoría de los tutoriales omiten por completo, por eso los equipos acaban depurando fallos raros en producción a las 2 de la mañana.
Escribir descripciones demasiado vagas. El modelo usa la descripción de tu función para decidir cuándo llamarla. Si tu descripción es genérica —algo como “procesa solicitudes de usuario”—, el modelo no tiene una señal fiable de cuándo activarla. Sé específico sobre la condición de disparo y la forma de entrada esperada. Piensa en la descripción como un contrato, no una etiqueta.
Exponer demasiadas funciones a la vez
Las descripciones de funciones pueden consumir una cantidad significativa de tokens en el prompt de entrada.
Cargar definiciones para 50+ herramientas en el prompt del sistema crea dos problemas: costo y latencia, ya que las definiciones de herramientas consumen tokens de entrada; y degradación de la exactitud, puesto que al aumentar el número de opciones de herramientas disminuye la capacidad del modelo para seleccionar la correcta.
Empieza con el conjunto más pequeño de funciones que tu caso de uso realmente necesita.
Suponer que el modelo no va a alucinar parámetros. Lo hará.
El modelo puede alucinar parámetros
— especialmente en campos opcionales que no están claramente acotados por un enum. Esta es exactamente la razón por la que strict: true importa: elimina la capacidad del modelo de inventar campos fuera de tu esquema.
No gestionar el bucle de múltiples turnos. Los desarrolladores a menudo construyen el camino feliz — el usuario pregunta, el modelo llama a la función, listo.
Los modelos pueden generar llamadas a funciones que no coinciden con el esquema que definiste o intentar llamar a una función que no incluiste. Si el modelo está generando llamadas a funciones inesperadas, intenta incluir una frase en el mensaje del sistema que diga “Usa únicamente las funciones que se te han proporcionado.”
Diseña para los casos límite.
Omitir el paso de confirmación antes de operaciones de escritura.
Sé consciente del impacto real de las llamadas a funciones que planeas ejecutar, especialmente aquellas que desencadenan acciones como ejecutar código, actualizar bases de datos o enviar notificaciones. Para funciones que realizan acciones, se recomienda encarecidamente implementar un paso en el que el usuario confirme la acción antes de la ejecución.
Si una llamada a función puede borrar datos, enviar dinero o modificar estado externo, debería aprobarla un humano primero.
Consideraciones de seguridad y fiabilidad
Las llamadas a funciones amplían lo que un LLM puede hacer. También amplían lo que un atacante puede hacer que haga.
La amenaza principal aquí es la inyección de prompt.
Los objetivos finales de las inyecciones de prompt varían, pero pueden incluir exfiltrar datos privados mediante llamadas a herramientas downstream, realizar acciones desalineadas o cambiar el comportamiento del modelo de forma no intencionada.
Cuando tus llamadas a funciones pueden enviar correos, consultar bases de datos o disparar webhooks, un ataque de inyección no es solo un chatbot saliéndose del guion — es una posible brecha.
A medida que los sistemas de IA van más allá del chat y comienzan a llamar herramientas y tomar acciones, la inyección de prompt se convierte en un problema mucho más serio. Una instrucción maliciosa oculta en una página web, documento o herramienta externa puede intentar anular el comportamiento del sistema, exponer información sensible o desencadenar acciones que el modelo nunca debería realizar.
La estrategia de mitigación tiene algunas capas concretas.
Diseña flujos de trabajo para que los datos no confiables nunca dirijan directamente el comportamiento del agente. Extrae únicamente campos estructurados específicos —como enums o JSON validado— de entradas externas para limitar el riesgo de inyección que fluye entre nodos.
Además,
verifica siempre las llamadas a funciones generadas por el modelo. Esto incluye comprobar los parámetros, la función que se está llamando y garantizar que la llamada se alinea con la acción prevista.
Una verdad incómoda:
“La inyección de prompt, al igual que las estafas y la ingeniería social en la web, probablemente nunca se ‘resuelva’ por completo.”
Esa es la propia evaluación de OpenAI. La implicación práctica es que no deberías diseñar sistemas agénticos con llamadas a funciones asumiendo que el modelo siempre se comportará como se pretende. Defensa en profundidad —validación, permisos con ámbito, humanos en el bucle para operaciones destructivas— es la única postura sensata.
Llamadas a funciones vs. ingeniería de prompts — cuándo usar cada una
Esta comparación surge constantemente. La respuesta corta: resuelven problemas distintos, y confundirlos conduce a prompts sobre-ingenierizados cuando bastarían las llamadas a funciones, o a esquemas de funciones frágiles cuando un buen prompt de sistema sería más simple.
La ingeniería de prompts implica crear entradas de texto para guiar el razonamiento interno del LLM — pedirle que “piense paso a paso”, por ejemplo.
Da forma a cómo razona el modelo. Las llamadas a funciones, en cambio, determinan lo que el modelo produce como salida y lo enrutan directamente a tu sistema.
Las llamadas a herramientas son la capacidad que permite al LLM interactuar con sistemas externos. Si bien utilizas la ingeniería de prompts para ayudar al modelo a decidir qué herramienta usar, las llamadas a herramientas son el mecanismo que realmente ejecuta la acción. Probablemente necesites ambas, pero sirven a propósitos diferentes.
Una ventaja técnica clave de las llamadas a funciones sobre la salida estructurada basada en prompts:
las llamadas a herramientas son un concepto integrado directamente en el modelo. No hay necesidad de desperdiciar tokens y energía tratando de explicarle al modelo que debe devolver un formato específico.
Cuando creas un prompt que dice “devuelve tu respuesta como JSON con los campos X, Y y Z”, estás gastando tokens en instrucciones que el modelo podría seguir de forma inconsistente. Con las llamadas a funciones, la aplicación del esquema ocurre a nivel de API.
Las APIs de llamadas a funciones, ahora compatibles de forma nativa en muchas plataformas de LLM, proporcionan una interfaz formal impulsada por esquemas que permite una validación estricta de datos e integración con flujos de trabajo programáticos.
Esa es la razón del mundo real para elegirlas sobre la ingeniería de prompts para cualquier dato que deba fluir hacia sistemas downstream: la fiabilidad no es opcional una vez en producción.
| Dimensión | Ingeniería de prompts | Llamadas a funciones |
|---|---|---|
| Propósito principal | Moldear el razonamiento y el tono del modelo | Producir salida estructurada para integración con sistemas |
| Formato de salida | Texto libre (o JSON con forma de texto) | Esquema JSON impuesto |
| Fiabilidad del esquema | Best-effort; propenso a desviaciones | Garantizado con strict: true |
| Costo en tokens | Menor para salidas simples | Mayor (las definiciones de funciones agregan tokens) |
| Cuándo usar | Tareas de razonamiento, generación de texto, estilo | Extracción de datos estructurados, orquestación de APIs, acciones agénticas |
| Exposición a inyección | Menor (sin ejecución de herramientas externas) | Mayor (las llamadas pueden desencadenar acciones del mundo real) |
La heurística práctica: si la salida debe impulsar un sistema downstream —una escritura en BD, una llamada a API, una rama de decisión en tu código— usa llamadas a funciones. Si la salida es para que la lea un humano, la ingeniería de prompts suele ser suficiente y más barata.
Conclusiones clave
| Tema | Qué recordar |
|---|---|
| Qué es | El modelo produce JSON estructurado describiendo qué función llamar — no ejecuta la función |
| Superficie de API actual | Usa tools y tool_choice; los parámetros antiguos functions y function_call están obsoletos |
| Modo estricto | Configura siempre strict: true en las definiciones para imponer el cumplimiento del esquema |
| Llamadas en paralelo | Compatibles en modelos lanzados después de noviembre de 2023; una solicitud puede disparar múltiples llamadas |
| Costo en tokens | Los esquemas de funciones consumen tokens de entrada; minimiza el número de funciones expuestas |
| Seguridad | Valida todas las salidas de llamadas a funciones; nunca permitas que contenido externo no confiable dirija llamadas |
| vs. ingeniería de prompts | Las llamadas imponen la estructura a nivel de API; los prompts moldean el razonamiento interno |
| Pasos de confirmación | Cualquier función con efectos en el mundo real (escribir, enviar, eliminar) debe requerir confirmación del usuario |
Si quieres experimentar con llamadas a funciones en distintos modelos — GPT-5.4, claude opus 4.7, gemini 3.1 pro — sin mantener credenciales de API separadas para cada uno, CometAPI te da acceso a todos mediante un único endpoint y clave, lo que hace que las pruebas entre modelos tengan mucha menos fricción.
CometAPI resuelve la sobrecarga de infraestructura:
✅ Sintaxis unificada de llamadas a funciones en más de 15 modelos
✅ Una sola clave de API — sin cuentas separadas para OpenAI/Anthropic/Google
✅ Traducción automática de esquemas — escribe una vez, prueba en todas partes
✅ Seguimiento de costes integrado — compara el uso de tokens por modelo en tiempo real
Empieza a probar con créditos gratuitos → Obtener acceso