¿Qué es la llamada a funciones?
Fundamentos, modelos y capacidades de IA
La llamada a funciones es una forma de que un modelo de IA solicite a un software que realice algo concreto, en un formato estructurado, en lugar de limitarse a generar texto libre. Se definen las funciones que el modelo puede utilizar, como "consultar un pedido" o "programar una reunión", y el modelo decide cuándo solicitar una. La aplicación valida la solicitud, ejecuta la acción real y devuelve el resultado para que el modelo pueda continuar la conversación.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Un modelo mental útil es que el modelo no es el trabajador, sino el coordinador. Puede leer la solicitud, decidir qué acción disponible parece relevante y generar una llamada estructurada para esa acción. Pero no accede directamente al CRM, al sistema financiero ni al calendario. Eso sigue siendo tarea del software.
Esta distinción importa. En una interacción normal con un chatbot, el modelo solo dispone de su entrenamiento y del texto que se le proporciona en el prompt. Si un usuario pregunta: "¿Se ha pagado la factura 18492?", el modelo no puede saberlo a menos que esté conectado al sistema financiero. La llamada a funciones es el puente. Se le indica al modelo de antemano: "Puedes llamar a check_invoice_status con estos campos." Si decide que esa función es necesaria, devuelve los argumentos solicitados en un formato legible por máquina. La aplicación los verifica, ejecuta la consulta y devuelve el resultado.
Por tanto, la llamada a funciones no consiste en convertir un modelo de IA en un operador sin restricciones. Consiste en ofrecerle un menú controlado de acciones y permitirle elegir de ese menú en un formato predecible. En la práctica, eso es lo que permite que un asistente de IA pase de ser una "demo interesante" a ser una "parte útil de un flujo de trabajo".
También ayuda a separar el lenguaje de la ejecución. El modelo es bueno interpretando entradas humanas desordenadas. Los sistemas empresariales son buenos ejecutando acciones precisas. La llamada a funciones permite que cada parte haga lo que mejor sabe hacer.
Por qué importa
Para los responsables de organizaciones, la llamada a funciones importa porque es una de las formas más claras en que la IA puede conectarse con el trabajo real sin reemplazar los sistemas existentes. La mayoría de las organizaciones no necesitan otra interfaz de chat que haga suposiciones. Necesitan software capaz de obtener información actualizada, actualizar registros con cuidado y encajar en los controles que ya tienen.
Esto hace que la IA sea más útil de tres maneras prácticas. En primer lugar, puede acceder a datos actuales en lugar de depender de un conocimiento de entrenamiento desactualizado. En segundo lugar, puede devolver información estructurada que otros sistemas pueden utilizar posteriormente. En tercer lugar, puede ayudar al personal a realizar acciones rutinarias con mayor rapidez, manteniendo el sistema de registro donde corresponde.
También cambia el panorama económico. Muchos pilotos de IA fracasan porque el modelo produce un lenguaje correcto pero no genera ningún cambio operativo. La llamada a funciones es a menudo donde el valor empieza a ser tangible. Un modelo que puede clasificar solicitudes entrantes, consultar la cuenta correcta, sugerir la siguiente acción y preparar la actualización adecuada está mucho más cerca de una capacidad empresarial real que un modelo que solo redacta texto.
También existe un beneficio en términos de control. Con la llamada a funciones, se elige qué puede invocar el modelo, qué argumentos son válidos, qué requiere aprobación humana y qué queda registrado. Eso se adapta mejor a la realidad empresarial que otorgar al modelo un acceso amplio y mal definido.
Cómo funciona
En términos básicos, la llamada a funciones tiene cuatro componentes.
El primero es la definición de la función. Se describe una herramienta de forma estructurada. Esto suele incluir un nombre, una breve descripción de lo que hace y un esquema para las entradas. Un esquema es simplemente una descripción legible por máquina de los campos que espera la herramienta, como customer_id, invoice_number, date o priority. También especifica el tipo de cada campo, como texto, número, lista o sí/no.
El segundo componente es la decisión del modelo. Se envía la solicitud del usuario junto con las definiciones de herramientas disponibles al modelo. El modelo decide si responde directamente o solicita una de las herramientas. Si solicita una herramienta, devuelve el nombre de la función y los argumentos que considera que deben pasarse. Las descripciones de herramientas claras son importantes aquí. Si los nombres de las herramientas y las descripciones de los campos son vagos, el modelo tendrá que adivinar.
El tercer componente es la validación y ejecución en el lado de la aplicación. Aquí es donde muchos equipos cometen errores de diseño. La solicitud del modelo no es la acción. Es una acción propuesta. La aplicación aún debe verificar que la solicitud está bien formada, que el usuario tiene permiso para realizarla, que los registros referenciados existen y que ejecutar la acción es seguro. Si el modelo sugiere reembolsar el pedido incorrecto o eliminar el registro equivocado, el sistema debe detectarlo antes de que ocurra nada.
El cuarto componente es el bucle de retorno. Después de que la aplicación ejecuta la función, envía el resultado de vuelta al modelo. El resultado puede ser simple, como "la factura está pagada el 12 de mayo", o más detallado, como un objeto JSON con fechas, importes y códigos de estado. El modelo utiliza ese resultado para producir el siguiente mensaje, hacer una pregunta de seguimiento o llamar a otra herramienta.
Este bucle puede ocurrir una vez o varias veces. Un asistente útil puede necesitar identificar al cliente, obtener los detalles de la cuenta, consultar el historial de pedidos y luego redactar una respuesta. En otras palabras, la llamada a funciones suele ser parte de un bucle de interacción y no un evento de un solo paso.
Los sistemas modernos hacen esto más fiable mediante el uso de esquemas más estrictos. Algunas plataformas admiten salidas estructuradas "estrictas", lo que significa que los argumentos generados por el modelo deben ajustarse exactamente al esquema proporcionado. Eso no garantiza que la acción sea correcta en términos empresariales, pero reduce considerablemente los errores de formato. Si los sistemas posteriores esperan fechas válidas, valores de enumeración permitidos o estructuras de objetos fijas, esto tiene una gran importancia.
Otra decisión de diseño es dónde se ejecutan las herramientas. En algunas arquitecturas, el proveedor del modelo ofrece herramientas integradas del lado del servidor, como búsqueda web o ejecución de código. En otras, es la propia aplicación la que ejecuta las herramientas. El segundo patrón es el que la mayoría de las organizaciones utilizan para los sistemas internos, porque les permite mantener las verificaciones de identidad, los registros de auditoría, los límites de uso y las reglas de negocio dentro de su propio entorno.
La llamada a funciones también se sitúa cerca, pero no por encima, de otros patrones de integración. No es lo mismo que la generación aumentada por recuperación, que se centra en obtener contenido relevante para mejorar las respuestas. No es lo mismo que una pasarela de API, que gestiona el tráfico entre sistemas. No es lo mismo que el Model Context Protocol, que es un estándar más amplio para conectar aplicaciones de IA con herramientas y fuentes de datos. La llamada a funciones es el primitivo más específico en el que el modelo elige una acción con nombre y devuelve los argumentos en un formato estructurado.
En producción, las buenas implementaciones suelen añadir algunas salvaguardas adicionales. Utilizan descripciones de herramientas claras. Mantienen las herramientas pequeñas y con un único propósito. Prefieren acciones reversibles sobre las irreversibles. Tratan las acciones con efectos secundarios, como pagos, cambios en cuentas o notificaciones, como una clase separada que puede requerir confirmación explícita. Registran cada llamada propuesta, cada llamada ejecutada, cada resultado y cada fallo. También planifican para la ambigüedad, porque los usuarios a menudo expresan sus solicitudes de forma incompleta. Un diseño sólido permite al modelo hacer una pregunta aclaratoria en lugar de forzar una suposición incorrecta.
Un último punto es que la llamada a funciones no elimina la necesidad del diseño de software. Cambia la forma del problema. En lugar de codificar de forma rígida cada camino desde la formulación del usuario hasta la acción del sistema, se definen herramientas, restricciones y verificaciones, y se deja que el modelo gestione la capa de lenguaje. Eso es poderoso, pero solo cuando los contratos en torno a esas herramientas son precisos.
Ejemplos
En atención al cliente, la llamada a funciones suele operar en segundo plano. Un usuario pregunta dónde está su pedido, el asistente llama a una función de consulta de envíos, obtiene el último evento del transportista y responde en lenguaje claro. Si el paquete está retrasado y la política permite una compensación, el asistente puede preparar una solicitud de compensación pero esperar la aprobación del personal antes de emitir nada.
En operaciones, puede integrarse en la gestión de excepciones. Un supervisor de almacén informa de que un número de serie no coincide con la lista de empaque. El asistente llama a una función de inventario, una función de envío y una función de creación de casos, y luego reúne los hallazgos en un resumen de incidente claro para el equipo de operaciones.
En administración financiera, un modelo puede extraer campos de una factura recibida por correo electrónico, llamar a la validación de proveedores, cotejar con una orden de compra y marcar las discrepancias. El punto clave es que el modelo no reemplaza las reglas contables. Ayuda a enrutar y estructurar el trabajo.
En TI interna, un asistente de soporte puede convertir "No puedo acceder al panel de ventas" en un conjunto de verificaciones controladas. Puede verificar la identidad, inspeccionar los grupos de acceso, leer el registro de incidentes recientes y proponer los siguientes pasos. Si la solicitud implica cambiar permisos, el paso final puede seguir requiriendo la aprobación de una persona.
En operaciones de ventas, un representante podría preguntar: "Muéstrame los acuerdos abiertos en manufactura por encima de cien mil que no han tenido actividad en dos semanas." El modelo puede convertir esa solicitud en una consulta estructurada al CRM, llamar a la función correspondiente y presentar los resultados en un formato sobre el que el representante pueda actuar.
Malentendidos frecuentes
Un malentendido habitual es que la llamada a funciones significa que el modelo puede "hacer cualquier cosa". No es así. Solo puede solicitar las herramientas que se le exponen. Si no existe ninguna función para una tarea, el modelo no puede realizarla.
Otro malentendido es que los argumentos estructurados implican un juicio empresarial fiable. Una llamada a función perfectamente formateada puede seguir siendo la llamada incorrecta. La llamada a funciones mejora la fiabilidad de la interfaz, no el juicio directivo.
Un tercer malentendido es que esto es solo para agentes avanzados. En la práctica, muchos asistentes sencillos utilizan la llamada a funciones sin parecer agentes en absoluto. Si un sistema consulta datos de cuentas, obtiene un documento de política o actualiza un ticket, es posible que ya esté usando este patrón.
Los equipos también confunden la llamada a funciones con la integración ordinaria de API. Están relacionadas, pero no son idénticas. La API es la interfaz del sistema. La llamada a funciones es la forma en que el modelo decide usar esa interfaz y cómo expresa la solicitud.
Por último, algunos equipos asumen que más herramientas siempre es mejor. Por lo general, ocurre lo contrario. Demasiadas herramientas superpuestas dificultan la selección, aumentan el uso de tokens y hacen que el comportamiento sea menos predecible.
Riesgos y límites
El límite más importante es que el modelo sigue siendo un modelo de lenguaje. Puede malinterpretar la intención del usuario, rellenar huecos con valores plausibles pero incorrectos, o elegir una herramienta con exceso de confianza cuando debería hacer una pregunta aclaratoria.
También existen riesgos de seguridad. Si se devuelve contenido no confiable al modelo tras una llamada a una herramienta, ese contenido puede contener instrucciones maliciosas o intentos ocultos de inyección de prompt. Un documento recuperado, una página web o el resultado de una herramienta no deben tratarse automáticamente como confiables solo porque provengan de un sistema. Hay que validar, sanear donde sea posible y separar los "datos de las herramientas" de las "instrucciones al modelo" con el mayor cuidado que permita la arquitectura.
La autorización es otro límite importante. El modelo nunca debe ser la fuente de verdad para los permisos. No debe decidir si un usuario tiene autorización para emitir un reembolso, leer un expediente de personal o cambiar un indicador de contrato. La aplicación debe hacer cumplir eso.
Operativamente, los efectos secundarios requieren especial atención. Enviar un correo electrónico, modificar un registro, activar un pago o llamar a un flujo de trabajo externo puede tener consecuencias reales. Las acciones de alto impacto suelen requerir confirmación explícita, revisión humana o ambas.
Este artículo es orientación práctica, no asesoramiento en materia de seguridad, legal o de sectores regulados. Si la llamada a funciones afecta a pagos, datos de salud, datos de empleo o registros regulados, la arquitectura y los controles deben ser revisados por los especialistas internos adecuados.
Próximos pasos
Comenzar con un flujo de trabajo acotado que ya tenga reglas claras, sistemas fuente fiables y un problema medible. Buenos candidatos iniciales son el estado de pedidos, la consulta de cuentas, la clasificación de facturas, la programación de reuniones y el enrutamiento interno de tickets.
A continuación, definir el conjunto mínimo de herramientas. Mantener cada función con un alcance reducido, un nombre claro y un tipado estricto. Evitar una herramienta vaga de tipo "hacer_todo". Es más difícil de gobernar y de probar.
Después, separar las acciones de lectura de las de escritura. Las funciones de solo lectura son más fáciles de pilotar de forma segura. Para las acciones de escritura, añadir pasos de confirmación, lógica de aprobación y registro completo desde el principio.
Luego, probar con lenguaje real, no solo con prompts de laboratorio. Los usuarios serán imprecisos, apresurados, ambiguos e inconsistentes. La evaluación debe incluir campos faltantes, solicitudes contradictorias, solicitudes no autorizadas y formulaciones inusuales.
Por último, ejecutar el piloto con métricas operativas que importen. Hacer seguimiento de la tasa de finalización de tareas, la tasa de corrección, la tasa de escalado, el tiempo ahorrado y los modos de fallo. El objetivo no es solo que el modelo haya llamado a una función. El objetivo es que el flujo de trabajo circundante se haya vuelto más fiable y más útil.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿La llamada a funciones significa que el modelo ejecuta código por sí mismo?
Por lo general, no. En la mayoría de los diseños empresariales, el modelo propone una llamada a una herramienta y la aplicación ejecuta el código real tras la validación.
¿Es la llamada a funciones lo mismo que la salida estructurada?
Se superponen, pero no son idénticas. La salida estructurada consiste en devolver datos en un formato definido. La llamada a funciones utiliza un formato definido para solicitar una acción o una consulta externa.
¿Necesito la llamada a funciones para todo asistente de IA?
No. Si la tarea consiste únicamente en redactar, resumir o transformar texto proporcionado, puede que no sea necesaria. Se vuelve importante cuando el asistente debe obtener datos en tiempo real o activar acciones.
¿Puede la llamada a funciones reducir las alucinaciones?
Puede reducir un tipo de alucinación al permitir que el modelo obtenga datos reales en lugar de adivinar. No elimina los malentendidos, el mal juicio ni un diseño de ejecución deficiente.
¿Es la llamada a funciones lo mismo que un agente de IA?
No. La llamada a funciones es un bloque de construcción. Un agente suele combinar la llamada a funciones con memoria, planificación, reintentos y lógica de control de múltiples pasos.
¿Qué debe quedar siempre fuera del control del modelo?
Los permisos, la aplicación de políticas, las acciones irreversibles y la validación final de los pasos de alto impacto deben permanecer fuera del modelo y dentro de la lógica de aplicación gobernada.
Fuentes
JSON Schema specification (JSON Schema). Primary source for the concept of schemas and meta-schemas that underpin structured function arguments.
LLM Prompt Injection Prevention Cheat Sheet (OWASP). Secondary source for prompt injection and insecure output handling risks relevant to tool-enabled AI systems.