Function calling es un patrón de integración en el que un modelo devuelve una petición estructurada para que una aplicación invoque una función. La función puede consultar una API, buscar en una base de datos o preparar una operación. El modelo describe lo que necesita; el software que lo rodea mantiene el control de la ejecución.
La diferencia con una respuesta de texto es operativa. Una aplicación puede analizar un objeto con nombre de función y argumentos, validar sus campos y decidir si continúa. Aun así, el formato estructurado no convierte una propuesta del modelo en una orden autorizada.
Definir las herramientas disponibles
La aplicación comunica al modelo qué funciones existen, para qué sirven y qué argumentos aceptan. Una definición concreta reduce llamadas ambiguas. Es preferible separar consultar_estado_pedido de modificar_pedido que exponer una única función genérica con una operación libre.
El esquema describe tipos y campos, pero debe mantenerse alineado con la implementación. Si la documentación permite un estado que el backend ya no acepta, el modelo generará solicitudes que fallarán. La versión de las funciones forma parte del contrato de la API.
La respuesta estructurada es una propuesta
Ante una consulta, el modelo puede devolver texto o una llamada con nombre y argumentos. El orquestador identifica la llamada, comprueba que el nombre está permitido para esa sesión y valida que el objeto tenga la forma esperada. Si falta un campo o aparece uno inesperado, debe rechazarlo o pedir una aclaración.
Un ejemplo: el modelo propone obtener_estado con un número de pedido. El backend no debe consultar ese número sin comprobar antes que el usuario está autenticado y autorizado para ver la información. El modelo no es el lugar donde se decide esa relación.
Validación de negocio y autorización
La validación sintáctica solo es el primer filtro. El servidor debe comprobar permisos, propiedad del recurso, límites y estado actual. También debe ignorar campos que el usuario no puede establecer, aunque aparezcan en el objeto generado.
Las credenciales de la API deben permanecer en el servidor o en un gestor de secretos. El navegador no debería recibir una clave que permita invocar directamente funciones sensibles. Registra la identidad y el motivo de la llamada sin guardar más datos personales de los necesarios.
Ejecutar y devolver el resultado
Tras la validación, la aplicación ejecuta la función con sus propios parámetros autorizados. El resultado se devuelve al modelo como un mensaje de herramienta para que pueda redactar una respuesta o decidir si necesita otro paso. El texto final no debe ocultar un error operativo ni convertir un resultado vacío en una afirmación.
Limita el resultado al mínimo necesario. Una función que consulta un cliente puede devolver estado y fecha sin incluir dirección, notas internas o credenciales. El filtrado debe ocurrir antes de construir el siguiente mensaje para el modelo.
Tiempo de espera, reintentos y fallos
Las APIs externas pueden tardar, devolver errores o estar temporalmente indisponibles. Define timeouts y estados claros para que la aplicación no mantenga una petición abierta indefinidamente. Un reintento automático debe distinguir un error de red de una respuesta que ya creó un recurso.
La idempotencia es especialmente importante en operaciones de escritura. Una clave de solicitud o una comprobación previa puede evitar crear dos tickets si el primer intento terminó en el servidor pero la respuesta se perdió. No repitas a ciegas una transferencia, un envío o un borrado.
Acciones sensibles y aprobación humana
La lectura de un dato y su modificación no tienen el mismo riesgo. Para cambiar permisos, cancelar un servicio o enviar un mensaje externo puede ser apropiado mostrar un resumen y pedir confirmación. La aplicación debe imponer esa condición, no limitarse a pedir al modelo que sea prudente.
Las herramientas también pueden devolver instrucciones no confiables desde sistemas externos. Ese contenido puede incorporarse como dato para una explicación, pero no debe modificar las reglas de autorización ni habilitar otra función por sí solo.
Observabilidad del contrato
Registra nombre y versión de la función, usuario o servicio que inició la petición, resultado de validaciones, duración, estado final y errores. Evita registrar el prompt completo o información sensible cuando no sea necesario. Las métricas de llamadas rechazadas pueden mostrar que el esquema es ambiguo o que los permisos están mal diseñados.
Qué validar antes de ejecutar una llamada propuesta por el modelo
Comprueba siempre el nombre, los tipos, los valores, la autorización, la vigencia del recurso y el efecto que tendrá la operación. Después define cómo se reintenta, cómo se deshace y qué verá el usuario si falla. Function calling facilita conectar modelos con software; la seguridad sigue perteneciendo al backend que ejecuta la función.
El contrato de una función cambia con la API
Las definiciones de herramientas forman parte del contrato entre el modelo y el backend. Si se renombra una función, se cambia un campo obligatorio o se altera el formato de error, hay que versionar y probar el flujo completo. Un esquema válido no evita que el significado de un parámetro sea ambiguo, por lo que la descripción debe incluir unidades, límites y efectos.
La función también debería devolver estados explícitos: completado, no encontrado, no autorizado o temporalmente no disponible. Es preferible que el modelo reciba un error controlado a que la aplicación convierta una excepción interna en un texto que parezca un resultado válido.
Separar lectura y escritura
Muchas integraciones pueden dividirse en consultas de solo lectura y operaciones que cambian datos. Esa separación permite ofrecer más automatización para obtener información y reservar la escritura para flujos con confirmación. Las pruebas de regresión deben comprobar tanto el caso correcto como los argumentos que deben rechazarse.