Una llamada de función propuesta por Gemini no acredita que la aplicación haya ejecutado la acción
La guía de funciones personalizadas separa la decisión del modelo y el código que actúa fuera de él. Una ficha de comprobación ayuda a distinguir argumentos, ejecución y resultado.
En el flujo de funciones personalizadas descrito por Google, el modelo puede indicar qué función utilizar y con qué argumentos. La guía separa ese paso de la ejecución del código, que corresponde a la aplicación. Recibir un nombre de función y sus parámetros no demuestra que se haya completado una acción en el sistema externo.
El proceso documentado define la función, envía la petición con esa declaración, ejecuta el código correspondiente y devuelve el resultado al modelo para producir una respuesta al usuario. Puede repetirse en varios turnos. El punto útil para quien construye una integración es identificar dónde sucede cada paso y qué evidencia deja.
Ejemplo propio, sin ejecutar una API: una aplicación recibe una propuesta para crear una cita, pero su servicio externo rechaza la operación. Si la interfaz muestra «cita creada» únicamente porque leyó los argumentos del modelo, oculta el fallo. Debería conservar y representar el resultado real de la ejecución.
Para comprobar un caso proponemos registrar por separado función solicitada, argumentos validados, intento de ejecución y respuesta del servicio. La autorización y las comprobaciones de la aplicación deben resolverse en su propio flujo; no se deducen del texto fluido que genere el modelo al final.
Esta explicación se limita al esquema de funciones personalizadas de la documentación consultada. No afirma que todos los SDK o herramientas incorporadas funcionen igual, ni que una integración concreta sea segura por registrar estos campos. No se han creado citas, enviado mensajes o probado un sistema del usuario para elaborar el ejemplo.