Scheduled Tasks en ChatGPT debe diseñarse como un prompt que se ejecuta según un calendario, más las capacidades de ChatGPT que estén disponibles y autorizadas en la cuenta o workspace. No es un agente autónomo con acceso garantizado a todos los chats antiguos, archivos de proyecto, adjuntos de otros chats, archivos locales, GPTs, voz, webhooks o acciones arbitrarias en cuentas conectadas.
La frontera rápida es esta:
- Base estable: instrucción de la tarea, calendario, notificaciones, ajustes y página o chat asociado a la tarea.
- Solo con condiciones: Memory, herramientas o apps conectadas y autorizadas, historial propio de una tarea de monitoreo.
- No asumir: todos los chats pasados, archivos de proyecto, archivos subidos en otros chats, GPTs, chats de voz, archivos locales, red interna o acciones externas sin permiso.
- Usar otra ruta: webhook, API cron, script local, CI, cola, workflow con retry y logs, tareas de sistema de archivos o ejecución determinista externa.
Si un dato debe estar presente cuando la tarea se ejecute, escríbelo en la instrucción. Memory puede ayudar con tono, unidades y preferencias, pero no debe cargar umbrales de clientes, contenido de archivos, límites legales, secretos, rutas locales ni pasos que deban ejecutarse siempre de la misma forma.
Nota de hechos: las páginas de OpenAI Help Center sobre Tasks in ChatGPT, ChatGPT capabilities, Memory, Projects y Data Controls se revisaron el 30 de junio de 2026. La disponibilidad por plan, límites de tareas activas, nombres de modelo, herramientas, apps, región, política de workspace y rutas de interfaz siguen siendo variables por cuenta y rollout.
Respuesta rápida: diseña alrededor del contexto explícito
Una tarea programada fiable debe entenderse sin que estés presente. La instrucción debe incluir objetivo, alcance, fuentes permitidas, formato de salida, condiciones de parada y cualquier hecho que cambiaría la respuesta si ChatGPT no lo viera.
| Límite | Regla segura | Qué verificar |
|---|---|---|
| Instrucción de la tarea | Escribe hechos, fechas, formato, restricciones y stop rule | Si la instrucción tiene sentido mañana sin leer el chat antiguo |
| Calendario | Elige ejecución única, recurrente o de monitoreo | La página oficial indica que no se ejecuta con frecuencia menor a una hora |
| Memory | Trátala como personalización, no como base exacta | Si Memory o referencia de historial están activadas |
| Archivos de proyecto | No dependas de ellos | La página oficial dice que tareas creadas en un proyecto con archivos no acceden a esos archivos |
| Herramientas y apps | Usa solo capacidades disponibles y autorizadas | Plan, región, conexión, scope, política de admin y review |
| Automatización externa | Asigna otro propietario | API cron, workflow, CI, cola, script local o agente de repositorio |
Si no puedes llenar la última columna, la tarea no está lista para ejecutarse sin supervisión. Puede ser un buen prompt manual en ChatGPT, pero todavía no es un workflow programado estable.
Qué contexto recibe una ejecución programada
Empieza por la instrucción de la tarea, no por contexto oculto. Ahí es donde puedes fijar lo que la ejecución futura debe ver. Una buena instrucción dice qué revisar, qué fuentes están permitidas, qué ignorar, cómo devolver el resultado y cómo detenerse cuando falte un dato obligatorio.
El chat o la página asociada importa como contenedor del producto. Sirve para administrar la tarea, verla, pausarla, editarla y revisar resultados. También importa porque borrar el chat asociado puede pausar la tarea. Pero eso no convierte cada línea de cada conversación previa en una entrada fiable.
Las tareas de monitoreo tienen un matiz útil. Pueden recordar ejecuciones anteriores de la propia tarea para comparar cambios o detenerse cuando se cumple una condición. Ese historial sirve como estado de monitoreo: qué vio la tarea la vez pasada y qué cambió ahora. No sustituye el material de referencia obligatorio. Si un monitor semanal necesita un baseline, pon el baseline en la instrucción o señala una fuente autorizada.
La frecuencia también tiene límite. En la revisión del 30 de junio de 2026, la página oficial indica que una tarea no puede ejecutarse más de una vez por hora. Si necesitas polling por minuto, eventos, webhooks, consumidores de cola, retry garantizado, logs y escalado, Scheduled Tasks no es el owner correcto.
Memory personaliza, pero no es el brief de la tarea
Memory puede ser útil, pero se malinterpreta con facilidad. La Memory FAQ de OpenAI separa saved memories y chat-history referencing. Eso afecta la personalización de chats futuros; no crea una base determinista y auditable para que cada ejecución programada recuerde exactamente un archivo, un umbral o una instrucción.
Memory encaja con preferencias de bajo riesgo:
- tono, unidades, nombres, longitud de resumen o estilo de escritura;
- preferencias estables que no deciden la corrección;
- contexto que mejora la forma, pero no cambia el resultado factual.
Memory no debe sostener datos exactos:
- cuenta de cliente, umbral financiero, requisito legal o límite de incidente;
- resumen de documento, cláusula contractual, baseline de reporte o política;
- secret, token, ruta local, repo privado o URL interna;
- pasos específicos que deben ejecutarse igual en cada corrida.
La práctica segura es simple: la instrucción es el brief y Memory es un ajuste suave. “Cada lunes resume novedades de política de IA en tono ejecutivo” puede aprovechar una preferencia de estilo. “Avísame cuando el uso de este cliente supere 80%” necesita cliente, umbral, fuente de datos, herramienta autorizada y conducta si el dato falta.
Archivos de proyecto y subidas no son entradas seguras
Projects en ChatGPT se sienten como espacios persistentes, pero Scheduled Tasks tiene una frontera de archivos más estrecha. La página oficial de Tasks in ChatGPT indica que las tareas creadas en un proyecto con archivos no pueden acceder a esos archivos de proyecto.
Eso descarta el diseño “subo documentos al Project y la tarea los revisa cada mañana” como supuesto seguro. Si el contenido de un archivo importa, usa una de tres rutas: resume lo estable en la instrucción, conecta una fuente realmente soportada y autorizada, o mueve el workflow a una herramienta que sí tenga acceso a archivos.
Los archivos subidos en otros chats merecen la misma cautela. Un PDF, CSV o screenshot agregado a una conversación no se convierte en entrada de fondo para todas las tareas futuras. Si cambia el resultado, reduce el contenido a hechos dentro de la tarea, usa una fuente conectada o cambia a script local, CI, agente de repo o plataforma de workflow.
Los archivos locales y redes internas son una zona de parada. Scheduled Tasks no debe usarse para leer Downloads, .env, repos sin commit, dashboards internos o servicios en localhost. Para eso necesitas un owner con frontera de archivos, permisos explícitos y logs.
Herramientas y apps pasan por una cadena de permisos
Una herramienta no se ejecuta solo porque el prompt lo pida. La lectura segura es: la capacidad debe existir para la cuenta, la app debe estar conectada, el scope debe permitirlo, la política de workspace no debe bloquearlo y cualquier review requerido debe resolverse.
Antes de depender de una herramienta en una tarea recurrente, verifica cinco capas:
| Capa | Pregunta | Modo de fallo |
|---|---|---|
| Soporte de función | ¿La cuenta o workspace expone esa capability a tareas? | La tarea corre, pero responde de forma genérica |
| Conexión | ¿La app está conectada con el scope necesario? | No puede ver los datos de la cuenta |
| Política de workspace | ¿El admin permite el conector o acción? | Business o Enterprise controls bloquean el flujo |
| Revisión de usuario | ¿Enviar correo, cambiar datos o acción externa requiere review? | La tarea prepara algo, pero no lo completa en silencio |
| Prueba de salida | ¿Puedes inspeccionar qué se usó después de la ejecución? | El resultado parece correcto, pero no es verificable |
Esto importa especialmente con Gmail, Drive, Calendar, Health, Finance, análisis de datos o cualquier app con información privada. Empieza con una tarea pequeña y segura, que lea el mínimo necesario y no modifique nada. Revisa historial, notificación y resultado en la app antes de llevarla al calendario real.
Cuándo Scheduled Tasks no es el owner adecuado
Scheduled Tasks es fuerte cuando el trabajo es salida recurrente de ChatGPT: recordatorios, briefings, chequeos de estado, monitoreo ligero y resúmenes periódicos. Es débil cuando el trabajo en realidad es infraestructura.
Usa otra ruta si el workflow requiere:
- webhook trigger desde otro sistema;
- polling por minuto, queue processing, retry, idempotencia o garantías de entrega;
- acceso directo a archivos locales, red interna o working tree sin commit;
- editar repos, correr tests, ejecutar comandos o scripts de producción;
- comportamiento de custom GPT, instrucciones específicas de GPT o flujos de voz;
- acciones externas auditables sin review humano.
Para esos casos, API cron, workflow automation, CI, script local, queue worker o repo-native agent suelen ser más claros. No significa que Scheduled Tasks sea débil; significa que posee otro tipo de trabajo.
Un prompt que sobrevive a ejecuciones futuras
La ejecución futura debe ser aburrida. Si no puedes saber qué hará la tarea leyendo solo la instrucción, depende demasiado de contexto no escrito.
textObjetivo: Cada [cadencia], hacer [trabajo concreto] para [audiencia]. Contexto obligatorio: - [Dato 1 que no debe inferirse] - [Dato 2 que no debe inferirse] - [Fuente, cuenta, proyecto o app si se requiere herramienta autorizada] Herramientas permitidas: - Usa [tool/app] solo si está disponible y autorizado en esta cuenta de ChatGPT. - Si no está disponible, di qué no pudo verificarse y no adivines. Formato de salida: - Empieza con respuesta o estado. - Luego lista evidencia, cambios, excepciones y huecos. - Termina con next action o “sin acción necesaria”. Regla de parada: - No asumas project files, uploads de otros chats, local files, webhooks, GPTs, voice chats ni acciones externas no autorizadas. - Si falta un dato obligatorio, informa la falta.
Esta receta encaja con digest semanal, briefing antes de reunión, monitoreo de información pública, recordatorios y status checks ligeros. No es el lugar para esconder ejecución de código, cambios de producción, lectura de repos locales o aprobaciones complejas.
Diagnóstico: qué frontera se rompió
Cuando el resultado no coincide con lo esperado, no reescribas todo el prompt primero. Aísla la frontera: estado de la tarea, contexto explícito, ruta de archivo, permiso de herramienta o owner incorrecto.
| Síntoma | Límite probable | Primer arreglo |
|---|---|---|
| La tarea dejó de ejecutarse | Estado de tarea o chat asociado | Revisar si está deshabilitada o si se borró el chat |
| Ignoró un dato importante | Falta contexto explícito | Poner el dato directamente en la instrucción |
| No pudo usar un archivo | Supuesto de project/upload/local file | Resumirlo o mover a una ruta con archivos |
| No corrió la herramienta | Función, conexión, política admin o review | Verificar soporte, conexión, scope e historial |
| Resultado demasiado genérico | Ruta de fuente no definida | Nombrar fuente, recency y prueba de salida |
| Necesita ejecución externa | Owner incorrecto | Mover a API cron, workflow, CI, script local o agente repo |
La mejor revisión posterior es concreta: ¿qué usó realmente la tarea? Mira notificación, historial, resultado en la app o página asociada. Si no puedes verificar la ruta de fuente, trata la ejecución como no probada.
Checklist antes de ponerla en producción
Antes de depender de una tarea, haz una aceptación mínima. No busca burocracia; busca detectar supuestos equivocados antes de que el calendario los repita.
| Revisión | Criterio de pase |
|---|---|
| Prompt autocontenido | Objetivo, inputs, outputs y stop rule se entienden sin chat antiguo |
| Cadencia aceptable | Frecuencia y notificación encajan con la frontera oficial |
| Memory no sostiene hechos | Datos críticos están en prompt o fuente autorizada |
| Ruta de archivo clara | Project, otros uploads y local files no se asumen |
| Cadena de permisos probada | Función, conexión, política, review y output proof revisados |
| Owner alternativo elegido | webhook, API cron, script local, CI y workflow no se fuerzan dentro de la tarea |
La primera ejecución es una prueba, no producción. Pide a la tarea que reporte qué fuentes usó, qué no pudo verificar y qué permisos necesitó. Después amplía permisos o frecuencia de una capa a la vez.
Preguntas frecuentes
¿Scheduled Tasks puede usar Memory?
Puede beneficiarse de Memory cuando está activada y es relevante, pero no diseñes la tarea alrededor de recuerdo oculto exacto. Los datos obligatorios deben estar en la instrucción o en una fuente conectada y permitida.
¿Puede acceder a archivos de proyecto?
No lo asumas. La página oficial de Scheduled Tasks indica que las tareas creadas en un proyecto con archivos no pueden acceder a esos archivos de proyecto. Si el contenido importa, resúmelo o usa otra ruta.
¿Puede usar Gmail, web search, Health, Finance u otras apps?
Solo si la capability está soportada, activada, conectada, autorizada y permitida por la cuenta o workspace. También debes revisar si una acción sensible requiere review. Un ejemplo de app no prueba ejecución automática para todos.
¿Soporta webhooks?
No. En la revisión del 30 de junio de 2026, la página oficial indica que webhooks no están soportados. Para automatización por eventos usa scheduler backend, plataforma de workflow, queue consumer o API cron.
¿Soporta GPTs o chats de voz?
No para esta frontera. La página oficial dice que GPTs y voice chats no están soportados para tasks. Si dependes de custom GPT behavior o voz, necesitas otra ruta.
¿Por qué se pausó mi tarea?
Una causa común es borrar el chat asociado. También revisa si la tarea fue deshabilitada, si se cumplió una condición de monitoreo, si cambió la disponibilidad de una herramienta, la política de workspace o la conexión de una app.
¿Sirve como API cron?
No si necesitas ejecución determinista, retry, logs, archivos locales o llamadas externas garantizadas. Scheduled Tasks sirve para salidas recurrentes de ChatGPT; API cron y workflow sirven para ejecución de sistemas.
¿Cuál es la primera prueba más segura?
Un prompt con una fuente pública, una cadencia, una salida corta y ninguna acción privada. Después de que funcione, agrega una herramienta permissioned por vez y revisa historial y fuente.