Clave API OpenAI: cómo rotarla antes de que caduque

OpenAI incorporó una fecha de caducidad para las claves API de proyecto el 10 de septiembre de 2026. Eso convierte la rotación de una clave API OpenAI en mantenimiento de producción programado: cualquier agente que opere sin supervisión necesita un responsable, una ventana de reemplazo y una verificación antes de que venza su clave.

Caducidad de claves API: una fecha límite, no una rotación automática

Una clave API es el secreto que una aplicación envía para demostrar que puede utilizar la API de OpenAI. Es habitual guardarla en un gestor de secretos, conectar a ella un proceso programado y no volver a prestarle atención hasta que algo falla.

OpenAI permite ahora definir una fecha de caducidad al crear una clave API de proyecto. Además, un administrador puede establecer la vigencia máxima de las claves en la configuración de Platform, ya sea para toda la organización o para un proyecto. Cuando existe esa política, cada nueva clave debe caducar dentro del plazo permitido.

Cada control cumple una función distinta:

La jerarquía importa. La configuración de un proyecto no puede prolongar una clave más allá de lo que permite la política de la organización; debe mantenerse dentro de ese límite.

Esto no es un sistema de rotación automática. La guía de OpenAI para entornos de producción indica que hay que crear un reemplazo antes de la caducidad, actualizar las aplicaciones, comprobar la nueva clave y solo entonces revocar la anterior. El equipo sigue siendo responsable de todos esos pasos.

La rotación de claves API también necesita presupuesto de mantenimiento

La función no altera el precio de los tokens. Lo que cambia es el cálculo de trabajo y posibles interrupciones para cada tarea programada que se autentica con una clave de proyecto.

Un modelo sencillo permite dimensionarlo. Las cifras siguientes son supuestos de carga de trabajo, no límites de OpenAI.

Supongamos que un proyecto ejecuta un agente cada 15 minutos, es decir, 96 veces al día. Una rotación planificada exige 30 minutos de trabajo de un operador. Si el equipo adopta una frecuencia trimestral y valora el costo laboral total en $75 por hora, cada rotación cuesta $37.50 y cada proyecto suma $150 al año. En diez proyectos, el mantenimiento anual ya representa $1,500.

Ahora supongamos que una clave caduca sin que nadie lo advierta y la interrupción dura 4 horas. En ese intervalo se pierden 16 inicios programados. Si inspeccionar y repetir cada ejecución fallida requiere 10 minutos, la recuperación consume 160 minutos, o 2 horas 40 minutos. A la misma tarifa de $75, solo la mano de obra asciende a $200, antes de contar trabajos de clientes retrasados, informes no entregados o ingresos perdidos.

Esa es la consecuencia operativa. La caducidad acorta el tiempo durante el cual una credencial olvidada puede seguir siendo válida, pero convierte un riesgo de seguridad oculto en una tarea recurrente. Hace falta reservarle presupuesto y dejar en el calendario el nombre de la persona responsable.

Si el problema real es un gasto descontrolado en la API, la caducidad de la clave no es el control adecuado. La guía independiente Controles de presupuesto para la API de agentes de IA aborda ese límite. Tanto un tope presupuestario como el vencimiento de una credencial pueden detener el trabajo, pero resuelven problemas distintos y exigen planes de recuperación diferentes.

Quién necesita este procedimiento

Un fundador en solitario con un agente SaaS sin supervisión

Quien ejecute un resumen de soporte, un procesador de documentos o una tarea de enriquecimiento de datos debe vincular la credencial a un responsable, aunque ese responsable sea quien fundó el negocio. El registro debe indicar qué programador de tareas, despliegue y entrada del gestor de secretos utilizan la clave. El reemplazo se inicia mientras la clave vigente todavía funciona y se valida observando una ejecución programada real con el nuevo secreto.

El beneficio es la continuidad. La rotación se convierte en un pequeño despliegue planificado, en lugar de descubrir por medio de un cliente que el trabajo del día anterior nunca llegó.

La persona responsable de operaciones en una agencia con proyectos de clientes

Una agencia puede mantener una ficha de rotación por cada proyecto de cliente: proyecto, responsable de la clave, tareas desplegadas, fecha de caducidad, estado del reemplazo y resultado de la verificación. Así, el esfuerzo se puede medir y ninguna automatización olvidada queda escondida detrás de una credencial compartida que nadie quiere tocar.

El beneficio es proteger el margen. El tiempo de rotación entra en la planificación de las entregas y la persona responsable de la cuenta sabe qué tareas del cliente debe comprobar antes de que desaparezca el secreto anterior.

Un equipo de plataforma que define la política de la organización

El equipo de backend o plataforma debería decidir primero la vigencia máxima de la organización y permitir después que cada proyecto adopte un límite dentro de ese marco. Puede fijar una política de proyecto más corta cuando la carga o el riesgo lo justifiquen, pero no ampliar la vigencia para eludir el límite de la organización.

El beneficio es una gobernanza coherente. El mismo equipo debería publicar el procedimiento de reemplazo al mismo tiempo que la regla de vigencia. Una fecha límite sin un mecanismo de relevo no es más que un incidente futuro con fecha marcada.

El equipo de seguridad que depura credenciales antiguas

La política para claves nuevas y el inventario de claves antiguas deben tratarse como dos líneas de trabajo. Primero se impone la vigencia máxima a las nuevas credenciales; después se localizan las credenciales de proyecto existentes y se les asigna un responsable. El alcance publicado no promete que esas claves anteriores vayan a caducar por sí solas.

El beneficio es una adopción transparente. La organización mejora de inmediato las nuevas credenciales sin confundir una política orientada al futuro con una limpieza ya terminada.

Cómo rotar una clave API OpenAI sin provocar una interrupción

Los detalles concretos del despliegue dependerán del proveedor de alojamiento y del gestor de secretos. La secuencia segura no cambia.

1. 1

   Confirmar la política y el responsable

   Antes de crear el reemplazo, hay que comprobar la vigencia máxima de la organización y la del proyecto. El registro debe incluir el proyecto de la clave actual, todas las tareas que la utilizan, la persona responsable y el momento en que comienza el reemplazo.

2. 2

   Crear el reemplazo con antelación

   La nueva clave API de proyecto debe crearse mientras la anterior aún sea válida, con una caducidad que respete la política activa. No debe incluirse en el código fuente ni en un repositorio público.

3. 3

   Prepararla mediante el gestor de secretos

   El reemplazo se guarda como una versión nueva en la variable de entorno o la ruta de gestión de secretos que ya utiliza la aplicación. Primero se actualiza un proceso controlado o una ruta de prueba. OpenAI también admite proyectos separados de preproducción y producción cuando se necesita un aislamiento mayor entre las pruebas y el entorno activo.

4. 4

   Verificar la tarea desplegada

   La aplicación debe ejecutarse a través de su ruta real de autenticación. Hay que revisar el resultado de la solicitud, la salida de la tarea, la cola y los registros del proceso. La página Usage de OpenAI puede aportar otra señal cuando está activado el seguimiento por clave, pero ningún panel sustituye la comprobación del resultado de negocio.

5. 5

   Completar el despliegue y retirar la clave anterior

   Hay que actualizar cada despliegue, programador de tareas, secreto de CI y proceso de larga duración que usaba la credencial anterior. Una vez confirmado que la nueva clave funciona en todas esas tareas, se puede revocar la antigua.

Lo que esta función todavía deja en manos del equipo

Las páginas públicas de OpenAI no indican una vigencia predeterminada universal ni una duración máxima única. Tampoco describen un periodo de gracia, un mecanismo de reemplazo automático o un calendario de avisos de caducidad. La configuración de la cuenta define la política; los recordatorios y el despliegue dependen del marco operativo que el equipo construya a su alrededor.

La configuración tampoco puede saber dónde se copió un secreto. No detecta si un desarrollador pegó la clave en un sistema de CI, un entorno serverless, una máquina local y un script de respaldo. El inventario es la parte que más equipos tenderán a subestimar.

La verificación es la otra dificultad. Una solicitud de prueba correcta demuestra que el reemplazo es válido, pero no que todos los procesos programados lo hayan recibido. Por eso la lista de tareas debe formar parte de la ficha de rotación y la clave anterior debe seguir activa hasta completar esa revisión.

Qué conviene hacer esta semana

Hay que actuar ya si un agente programado, un proceso por lotes, una automatización para clientes o un servicio backend utiliza una clave API de proyecto y la organización planea imponer una vigencia máxima. El trabajo de rotación debe entrar en el presupuesto operativo antes de que la política genere la primera fecha límite.

Es posible posponer el despliegue completo si no hay una vigencia máxima activa y ninguna clave de proyecto actual tiene fecha de caducidad. Aun así, conviene inventariar desde ahora las credenciales y sus responsables. El nuevo control deja clara la dirección y OpenAI ya recomienda rotarlas periódicamente.

Las claves existentes no aparecen descritas como credenciales que caduquen de forma retroactiva, de modo que no hay base para afirmar que todos los despliegues antiguos tengan de pronto una fecha límite en septiembre. Eso no justifica ignorarlas; exige revisarlas por separado en lugar de confiar en que la nueva política limpiará el pasado.

El lunes, hay que elegir un proyecto de producción, asignar la credencial a un responsable, preparar un reemplazo mientras la clave actual aún funciona, comprobar cada tarea desplegada con la nueva clave y retirar después la anterior. Ese relevo en cuatro partes es el plan de rotación.

Para recibir más notas operativas en lenguaje claro como esta, suscríbete al boletín.