Gobernanza de claves de OpenAI API: creación, propiedad, caducidad y rotación sin interrupciones
OpenAI añadió en septiembre de 2026 controles de organización y proyecto para crear nuevas claves de API y limitar su vigencia. Esta guía explica la prioridad de las políticas, cómo elegir entre claves de cuenta de servicio y claves de usuario, cómo migrar claves antiguas y cómo rotarlas con solapamiento para evitar cortes.
Índice
Quieres poner fecha de caducidad a las claves de OpenAI API, pero no quieres que una regla nueva detenga una aplicación ni descubrir en la siguiente rotación que ya no puedes emitir la clave sustituta correcta. También necesitas decidir si producción debe usar una cuenta de servicio mientras cada desarrollador conserva una clave propia.
Esta guía te da un orden práctico: elige la propiedad según la carga, fija una vigencia que tu equipo pueda rotar de verdad y sustituye las claves antiguas con un periodo controlado de solapamiento. Parte de dos hechos: las reglas nuevas no cambian las claves existentes y la política de la organización prevalece sobre la del proyecto.
Empieza por la respuesta: los controles nuevos gobiernan claves futuras, no las antiguas
Puedes entender los cambios de septiembre como dos controles: qué tipos de claves nuevas se pueden emitir y cuánto pueden durar las nuevas claves de proyecto.
| Fecha | Actualización de OpenAI | Consecuencia operativa |
|---|---|---|
| 10 de septiembre de 2026 | Las claves de API de proyecto pueden crearse con fecha de caducidad. Los administradores pueden imponer una vigencia máxima a nivel de organización o proyecto. | Las claves nuevas pueden dejar de ser indefinidas, pero el equipo necesita un proceso repetible de rotación antes de imponer plazos cortos. |
| 15 de septiembre de 2026 | Una organización o proyecto puede permitir solo service-account keys, solo user-owned project keys, o desactivar por completo la creación de nuevas claves de API. | Producción, desarrollo individual y proyectos congelados pueden aplicar reglas de emisión distintas. |
| 15 de septiembre de 2026 | Las restricciones de la organización prevalecen sobre los ajustes del proyecto. | Un proyecto puede ser más restrictivo, pero no puede relajar el límite definido por la organización. |
| 15 de septiembre de 2026 | Las claves de API existentes no se ven afectadas por los controles nuevos de creación. | Activar una regla no revoca credenciales antiguas ni completa su migración. |
Hay dos límites que conviene conservar. “Desactivar la creación de claves nuevas” no equivale a “revocar todas las claves actuales”. Además, la descripción del 10 de septiembre aplica la vigencia máxima a claves nuevas. No presupongas que una clave antigua recibirá una fecha de caducidad retroactiva sin comprobarlo en el proyecto real.
Separa tres decisiones: quién crea, cuánto dura la clave y cómo se retira
Diseña estas tres decisiones por separado; un interruptor de Platform no completa por sí solo el gobierno del ciclo de vida.
La política de emisión define si se pueden crear claves de cuenta de servicio, claves de proyecto propiedad de usuarios o ninguna clave nueva.
La política de caducidad define si una clave nueva debe caducar y cuál es la duración máxima permitida por la organización y el proyecto.
La ejecución del ciclo de vida define quién crea la sustituta, dónde se guarda, cómo la reciben las aplicaciones, qué pruebas validan el cambio, cuándo se revoca la anterior y cómo se revierte una publicación fallida.
Las dos primeras pueden imponerse desde OpenAI Platform. La tercera sigue dependiendo del gestor de secretos, del despliegue, de la observabilidad, de la asignación de responsables y de los procedimientos de incidentes. Imponer una vigencia máxima sin responsable de rotación ni tiempo suficiente para publicar convierte un control de seguridad en una interrupción programada.
Elige según el uso: cuenta de servicio para producción, clave de usuario para desarrollo personal
Prioriza una service-account key para producción y cargas compartidas, una user-owned project key para trabajo local o temporal y bloquea la emisión solo en proyectos realmente congelados o en retirada.
| Carga de trabajo | Suele encajar mejor con | Motivo | Riesgo principal |
|---|---|---|---|
| Servicio de producción, backend compartido, tarea programada, agente operado por un equipo | service-account key | La credencial pertenece a la carga y no a una persona; los cambios de plantilla no determinan la continuidad. | Una cuenta de servicio compartida por muchas aplicaciones crea un radio de impacto grande. Sepárala por proyecto o carga. |
| Desarrollo local, depuración temporal, script exploratorio | user-owned project key | El propietario y la responsabilidad individual quedan claros, y la baja del usuario puede incluir sus credenciales. | Una clave personal no debe convertirse de forma silenciosa en dependencia de producción compartida. |
| Proyecto archivado, en retirada o congelado temporalmente | Desactivar claves nuevas | Evita que crezca el inventario mientras el proyecto se cierra o investiga. | Bloquear demasiado pronto puede impedir crear una sustituta necesaria para rotar o recuperar. |
Una pregunta útil es: ¿debe la aplicación seguir funcionando cuando una persona concreta abandone el equipo? Si la respuesta es sí, la credencial de producción no debería depender normalmente de la cuenta de esa persona. En sentido contrario, repartir una clave de servicio compartida entre todos los portátiles reduce la atribución y multiplica las copias del secreto.
Ningún tipo es seguro por sí solo. El riesgo real depende del alcance, el almacenamiento, el acceso, la vigencia, la rotación y la revocación. Una clave de servicio de larga duración copiada en decenas de aplicaciones sigue siendo un punto único de exposición.
La organización marca el techo: el proyecto puede endurecerlo, no relajarlo
La restricción de la organización es el techo de todos los proyectos, así que prueba la siguiente rotación antes de aplicarla de forma general.
Si la organización solo permite claves de cuenta de servicio, un proyecto de desarrollo no podrá relajar el ajuste para emitir claves de usuario. El proyecto puede endurecer su regla dentro del límite organizativo, pero no hacerlo más permisivo.
Antes de cambiar una política para toda la organización:
- Enumera los proyectos y clasifícalos como producción, preproducción, desarrollo, pruebas, temporales, archivados o en retirada.
- Registra el tipo de clave que cada proyecto necesitará en su próxima rotación, no solo el que ya utiliza.
- Identifica la credencial de sustitución para cada carga activa y confirma que la futura regla permitirá crearla.
- Ensaya creación, distribución, validación y revocación en un proyecto de bajo riesgo.
- Aplica la restricción organizativa después de demostrar que una rotación normal sigue siendo posible.
Como las claves antiguas siguen funcionando, una política demasiado estricta puede parecer inocua el día de su activación. El fallo aparece semanas después, cuando se acerca una caducidad y la política impide emitir la sustituta adecuada. Ensaya la próxima rotación; no te limites a observar que el tráfico actual sigue funcionando.
No impongas la misma vigencia a todo: parte del tiempo real de rotación
La vigencia máxima debe superar el tiempo completo de aprobación, emisión, distribución, despliegue, observación y reversión.
Define para cada clase de proyecto:
| Campo | Pregunta que debe responder |
|---|---|
Vigencia máxima N | ¿Cuánto tiempo puede existir una clave nueva desde su creación hasta su caducidad? |
Antelación de rotación R | ¿Con cuánto tiempo debe iniciarse la sustitución? |
| Responsable principal y suplente | ¿Quién actúa y quién lo sustituye si no está disponible? |
| Método de distribución | ¿La aplicación carga una versión nueva del secreto o requiere reinicio/republicación? |
| Evidencia de validación | ¿Qué peticiones, registros, errores y señales de uso demuestran que la nueva clave recibe tráfico? |
| Ventana de reversión | ¿Cuánto tiempo se mantiene la clave anterior tras el cambio? |
| Excepciones | ¿Quién puede aprobar una ampliación, durante cuánto tiempo y con qué controles compensatorios? |
R tiene que cubrir toda la cadena. Una vigencia muy corta combinada con copia manual, aprobaciones entre zonas horarias y ausencia de suplente es menos fiable que una duración algo mayor con alertas automáticas y un procedimiento practicado.
Usa el máximo organizativo como techo común. Los proyectos de mayor riesgo pueden adoptar un límite más corto, nunca más largo. Producción, desarrollo personal, pruebas temporales y proyectos en retirada tienen responsables, impacto y velocidad de recuperación distintos, por lo que no necesitan compartir mecánicamente el mismo número.
Rota sin cortes con estos siete pasos de solapamiento
El patrón más seguro es mantener durante poco tiempo la clave antigua y la nueva, y revocar la anterior solo cuando el tráfico real confirme el cambio.
1. Construye un inventario de claves actuales
Registra proyecto, tipo de propietario, carga, aplicación, entorno, responsable, ubicación del secreto, método de despliegue, fecha de creación, caducidad conocida y último uso observado. Una clave de finalidad o propietario desconocidos debe entrar en una investigación prioritaria, no en una revocación masiva a ciegas.
La entrada del changelog del 4 de agosto de 2026 indica que los paneles Usage y Costs, la Usage API y la Costs API admiten filtrar y agrupar por clave de API. Esa dimensión puede aportar evidencia sobre el uso de una credencial. No basta por sí sola: un proceso mensual, una ruta de recuperación o una tarea poco frecuente pueden estar inactivos durante mucho tiempo.
2. Crea una sustituta conforme a la política
Crea la clave nueva en el proyecto correcto, con el tipo de propiedad permitido por las reglas vigentes. Asigna una fecha que no supere la vigencia máxima aplicable. Comprueba la posibilidad de emisión antes de la ventana de mantenimiento.
3. Guárdala como una versión nueva del secreto
No sobrescribas inmediatamente la única copia del valor anterior. Mantén ambas versiones durante la transición controlada, con estados claros como “producción actual”, “candidata de rotación” y “pendiente de revocación”. No guardes claves en código, imágenes, tickets, registros ni conversaciones.
4. Desplaza el tráfico de forma gradual
Empieza con una instancia, una tarea de bajo riesgo o una parte pequeña del tráfico. Verifica autenticación, atribución al proyecto, permisos y comportamiento de las peticiones antes de ampliar. Si el proceso solo lee la variable al arrancar, incorpora reinicios y capacidad al plan.
5. Observa la salud y el uso por clave
Revisa peticiones correctas, fallos de autenticación, límites, latencia y resultados del negocio. Confirma además que la clave nueva empieza a registrar el uso esperado y que el de la antigua disminuye. Un despliegue marcado como exitoso no demuestra que el tráfico se haya movido.
6. Mantén una ventana de reversión limitada
Conserva la clave antigua durante un periodo definido después de estabilizar la nueva y después revócala. La ventana debe cubrir trabajadores retrasados, regiones y tareas poco frecuentes, pero no quedar abierta indefinidamente. Operar siempre con dos claves solo duplica el número de secretos válidos.
7. Revoca, comprueba y programa la próxima rotación
Tras revocar, confirma que la clave anterior ya falla y que la nueva sigue funcionando. Actualiza inventario, instrucciones de guardia, responsable, caducidad y fecha de la siguiente rotación.
Las claves antiguas no se ajustan solas: migra primero las de mayor riesgo
Después de activar las reglas nuevas, todavía necesitas una cola separada para las claves antiguas porque conservan su propietario y su vigencia.
Crea una cola de migración independiente y prioriza:
- credenciales expuestas en código, tickets, registros o chats;
- claves cuyo dueño o finalidad no se puede identificar;
- claves personales de personas que se marcharon o cambiaron de función;
- claves compartidas por varias aplicaciones de producción;
- claves con alcance amplio o impacto alto;
- claves con propietario claro, una sola carga y una ruta de sustitución probada.
No midas el éxito por revocar todas las claves antiguas el mismo día. Es más seguro exigir que cada una tenga mapa de dependencias, sustituta aprobada, evidencia del cambio y fecha de revocación. Para una excepción temporal, documenta el bloqueo exacto, el responsable, los controles compensatorios y la fecha de finalización. “Sistema heredado” no es una excepción permanente.
Tu política interna necesita al menos estos 11 campos
Una política ejecutable debe indicar la regla, el responsable, las pruebas de validación, la ventana de reversión y la condición de revocación.
| Elemento | Qué registrar |
|---|---|
| Alcance | Organización, proyectos, entornos y clases de carga cubiertos |
| Tipo permitido | Solo servicio, solo usuario o ninguna clave nueva |
| Justificación | Continuidad, responsabilidad individual, congelación u otro motivo documentado |
| Vigencia máxima | Techo de organización y cualquier límite de proyecto más estricto |
| Antelación | Momento en que se crea la alerta o tarea antes de caducar |
| Almacenamiento | Gestor de secretos aprobado y roles de acceso |
| Publicación | Canary o fases, reinicios necesarios y procedimiento de reversión |
| Evidencia | Peticiones correctas, métricas de error, uso por clave y tráfico antiguo a cero |
| Condición de revocación | Nueva clave estable, tareas tardías cubiertas y ventana cerrada |
| Excepción | Aprobador, motivo, control compensatorio y vencimiento de la excepción |
| Auditoría | Creación, cambios de política, despliegue, revocación y cambios de propietario |
Asigna la responsabilidad duradera a una carga o función del equipo, pero identifica también a la persona que ejecutará cada rotación. “Lo lleva el equipo de plataforma” no es operativo si no existen guardia, plazo y escalado.
Antes de imponer la regla, ensaya la siguiente rotación
Activa restricciones de organización o proyecto solo después de resolver cada punto de esta lista y completar un ensayo de bajo riesgo.
- toda aplicación activa está asociada a un proyecto y una credencial concretos;
- se conoce el tipo que necesitará cada proyecto en la próxima rotación;
- la regla organizativa no bloqueará una sustituta crítica;
- producción no depende de la clave personal de una sola persona;
- el almacén de secretos admite versiones o una reversión fiable;
- se ha probado cómo carga la aplicación el secreto nuevo, incluido el reinicio;
- se puede observar uso o coste por clave considerando tareas poco frecuentes;
- hay responsable principal y suplente;
- las alertas llegan con antelación suficiente;
- los criterios de revocación impiden que el solapamiento sea permanente; y
- cada clave heredada pendiente tiene bloqueo, responsable y fecha límite.
Preguntas frecuentes
¿Una restricción nueva rompe de inmediato las aplicaciones existentes?
Según la actualización de OpenAI del 15 de septiembre de 2026, las claves existentes no se ven afectadas por los nuevos controles de creación. Cambiar qué claves nuevas se pueden emitir no revoca automáticamente las actuales. Sí puede bloquear la siguiente rotación, por lo que conviene ensayarla.
¿La vigencia máxima caduca retroactivamente las claves antiguas?
La actualización del 10 de septiembre describe el límite para claves nuevas. No presupongas una fecha retroactiva; comprueba los detalles de la credencial y migra el legado por separado.
¿Puede un administrador de proyecto relajar la regla de la organización?
No. La restricción de organización prevalece sobre la configuración del proyecto.
¿Toda la organización debería usar solo claves de cuenta de servicio?
Prioriza las claves de cuenta de servicio para producción, backends compartidos, tareas programadas y agentes operados por un equipo. Prioriza las claves de proyecto de usuario para desarrollo local y exploración temporal. Limitar toda la organización a cuentas de servicio solo tiene sentido cuando casi todos los proyectos pertenecen al primer grupo y desarrollo ya dispone de una alternativa viable.
¿Cuándo conviene impedir cualquier clave nueva?
En proyectos archivados o en retirada, o como congelación temporal durante una investigación. Verifica primero que no se necesite una clave nueva para rotar o recuperar el servicio.
¿Qué demuestra que una clave antigua se puede revocar?
Una combinación de evidencias: estado del despliegue, peticiones correctas con la nueva clave, errores, uso por clave, ejecución de tareas infrecuentes y cierre de la ventana de reversión. Un periodo corto sin tráfico no suele ser suficiente.
Qué debes hacer primero
Empieza por tres acciones: anota el tipo de clave que necesitará cada proyecto en la próxima rotación, completa una rotación con solapamiento en un proyecto de bajo riesgo y solo después aplica las restricciones de organización y proyecto.
El orden importa. Si primero impones el techo, las aplicaciones actuales pueden seguir funcionando mientras la política bloquea silenciosamente la sustituta que necesitarás más adelante. Demuestra que la siguiente rotación funciona antes de endurecer las reglas.
Fuente oficial:
