Un GPT que solo responde con texto es un chatbot. Un GPT con Actions puede consultar tu inventario, crear un ticket o programar una cita real. Así se diseñan Actions que funcionan de forma segura en producción.
Una Action es la conexión entre un GPT y una API HTTP externa, definida mediante un esquema OpenAPI (3.0 o 3.1) que describe endpoints, parámetros y respuestas esperadas. Cuando el usuario escribe algo en la conversación, el modelo evalúa si alguna de las operaciones disponibles es relevante, construye los parámetros necesarios a partir del contexto, hace la llamada HTTP real, y usa la respuesta para formular su contestación final.
Es el mismo mecanismo conceptual que function calling en la API, pero con una capa de configuración visual (GPT Builder) en vez de código explícito, y con la restricción de que solo funciona dentro del entorno de ChatGPT.
El esquema debe ser preciso: descripciones claras en cada `operationId` y parámetro, porque el modelo las usa como guía semántica para decidir cuándo invocar cada endpoint. Un esquema con descripciones vagas produce invocaciones incorrectas o el modelo simplemente ignora la Action disponible.
Las Actions soportan tres modos de autenticación: sin autenticación (endpoints públicos), API key (enviada como header, configurada una sola vez por quien crea el GPT), y OAuth 2.0 (donde cada usuario autoriza su propia sesión, ideal cuando la acción debe ejecutarse "como" ese usuario específico, no con una credencial compartida).
Para operaciones sensibles (crear registros, modificar datos, procesar pagos), OAuth por usuario es la opción correcta porque permite auditoría individual y revocación granular. Usar una única API key compartida para todo el GPT significa que, desde la perspectiva de tu backend, todas las acciones parecen venir del mismo "usuario", lo cual complica la trazabilidad.
La práctica recomendada es no apuntar la Action directamente a tu API interna de producción, sino a una capa intermedia (un API gateway o microservicio dedicado) que: valide y sanitice los parámetros recibidos (el modelo puede generar valores inesperados o mal formados), aplique rate limiting específico para tráfico proveniente de ChatGPT, exponga solo operaciones explícitamente permitidas (idealmente de solo lectura para casos de consulta), y registre cada llamada con el contexto de qué GPT y qué conversación la originó, cuando sea posible.
Si el GPT se publica en el GPT Store público, OpenAI exige una URL de política de privacidad válida para cualquier Action que envíe o reciba datos de usuario. Para GPTs de uso interno (workspace privado en Team/Enterprise) este requisito es más laxo, pero sigue siendo buena práctica documentar qué datos se envían a sistemas externos.
El modelo puede encadenar múltiples llamadas a Actions distintas dentro de una misma respuesta, pero cada llamada añade latencia perceptible para el usuario (varios segundos por request HTTP externo), así que Actions con muchas dependencias secuenciales se sienten lentas. Además, el tamaño de la respuesta que la Action devuelve está limitado — respuestas muy grandes (dumps completos de bases de datos) deben paginarse o resumirse en el propio endpoint antes de devolverse al modelo.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel