Function calling: qué es y cómo usa herramientas una IA

Function calling es un patrón que permite a un modelo de IA describir una llamada a una función con datos estructurados. El modelo no ejecuta por sí mismo el código: devuelve el nombre de la herramienta y los argumentos para que la aplicación los revise y decida qué hacer.

También puede servirte: RAG: qué es y cómo conecta documentos con un chatbot

La herramienta puede representar una consulta a una API, una búsqueda interna, un cálculo o una acción de un producto. El modelo interpreta el pedido y elige una herramienta disponible, pero el servidor mantiene la autoridad sobre permisos, validaciones, costos y efectos externos.

El nombre function calling cambia entre proveedores. OpenAI documenta herramientas y llamadas de funciones; Anthropic habla de tool use y Gemini de function calling. El concepto común es un intercambio de mensajes con un esquema que describe entradas y una respuesta que vuelve al modelo.

Primero la aplicación envía el pedido del usuario junto con las herramientas disponibles. Cada herramienta declara un nombre, una descripción y un esquema de argumentos. El modelo puede responder con texto o con una solicitud estructurada de uso de herramienta, según lo que necesite para completar el pedido.

Después el programa recibe esa solicitud y valida el nombre, los tipos, los valores permitidos y la identidad del usuario. Si la herramienta tiene efectos, conviene aplicar autorización y límites antes de ejecutar. Un argumento bien formado no prueba que la acción sea segura ni adecuada para ese usuario.

La aplicación ejecuta la función fuera del modelo y agrega el resultado al historial con el formato que espera el proveedor. Luego el modelo puede explicar el resultado, pedir otro dato o reconocer un error. El ciclo termina cuando la aplicación obtiene una respuesta final o alcanza un límite definido.

Un esquema JSON hace explícitos los campos, sus tipos y los valores requeridos. También puede restringir un estado a una lista de opciones o impedir propiedades desconocidas. Cuanto más preciso es el contrato, menos trabajo queda escondido en instrucciones ambiguas y más sencillo resulta rechazar entradas incompletas.

La descripción de cada campo orienta al modelo, pero no reemplaza la validación del servidor. El backend debe convertir fechas, comprobar rangos, verificar que un identificador exista y aplicar reglas de negocio. Los errores se devuelven como resultados controlados para que el modelo pueda corregir o informar el problema.

Una herramienta debería recibir sólo los datos necesarios para su tarea. Separar una función de lectura de otra que modifica información ayuda a revisar permisos y a registrar auditoría. También permite pedir confirmación para operaciones irreversibles sin convertir cada conversación en una lista de excepciones difíciles de mantener.

El modelo puede elegir una herramienta incorrecta, interpretar mal una fecha o inventar un identificador. Por eso la aplicación debe tratar la llamada como una propuesta, no como una orden. Los permisos, la autenticación, los límites de uso y los registros deben vivir en la capa que ejecuta el código.

Las instrucciones que llegan desde documentos, páginas o mensajes también pueden intentar cambiar el objetivo de una herramienta. La aplicación debe separar datos de instrucciones, filtrar contenido y limitar qué campos pueden afectar una acción. Nunca conviene pasar texto recuperado directamente a un comando con privilegios.

Los resultados de una herramienta pueden contener información sensible o estar desactualizados. Es útil conservar el origen, la hora y el identificador de la consulta, además de ocultar secretos antes de devolver el resultado al modelo. El registro debe permitir reconstruir qué se pidió, qué se ejecutó y quién lo autorizó.

Definí la intención de la herramienta y separá lectura, escritura y operaciones con costo. Escribí un esquema pequeño con campos requeridos, valores permitidos y descripciones concretas. Elegí qué modelo puede llamarla y qué ocurre si el modelo responde con texto en lugar de una llamada estructurada.

Implementá una validación independiente del modelo, autenticación del usuario, límites de frecuencia y un registro de cada ejecución. Probá argumentos ausentes, tipos equivocados, fechas ambiguas, respuestas vacías y errores del proveedor. La prueba debe verificar tanto el resultado correcto como la negativa segura.

Por último, decidí cuándo pedir confirmación humana y cuándo una operación puede ser automática. Medí llamadas inválidas, latencia, errores y costos por herramienta. Function calling conecta lenguaje con software, pero la confiabilidad depende del contrato, la ejecución y los controles que rodean al modelo.