Si WordPress 7.0 mete las API keys de IA en el admin, la lectura correcta no es «qué lindo, un toggle nuevo». Es una decisión de operaciones: una credencial que paga por token, accede a un servicio externo y, si se filtra, te vacía la cuenta. La configuración de API keys de IA en WordPress hay que tratarla como política operacional, con acceso restringido y auditoría, no como un switch que activás entre dos cafés.
Una API key de IA es una credencial secreta que autentica a tu sitio contra un proveedor de modelos (OpenAI, Anthropic, Google) para que el core o un plugin puedan generar texto, clasificar contenido o moderar comentarios. No es una preferencia de usuario: es un secreto con costo asociado y permisos de gasto. Por eso dónde la guardás y quién la toca importa más que el feature en sí.
En 30 segundos
- Una API key no es un toggle: es una credencial que gasta plata por uso y, filtrada, deja la factura abierta.
- Guardala fuera de la base de datos: en
wp-config.phpo variables de entorno, nunca en una opción legible de la tablawp_options. - Acceso restringido: solo dev/ops debería tocarla, no quien edita contenido. Eso pide separación de roles real.
- Rotala: una key que vive dos años sin cambiar es un problema esperando a pasar.
- Ojo con el alcance: WordPress 7.0 todavía no salió en versión estable a junio 2026, así que parte de esto es criterio operativo, no doc oficial.
WordPress es un sistema de gestión de contenidos de código abierto desarrollado por la Fundación WordPress. Se utiliza para crear y administrar sitios web, blogs y aplicaciones.
¿Por qué una credencial de IA no se maneja como una opción más del sitio?
Ponele que activás un plugin de SEO. Ajustás opciones, las guardás, y si te equivocás lo peor que pasa es que un meta título quede feo. Ahora cambiá ese escenario por una API key de Anthropic con saldo cargado. Si esa credencial termina en un backup público, en un commit de GitHub o en un campo legible de la base, cualquiera puede usarla para quemar tu cuota o, peor, para extraer datos a través de tu integración.
Esa es la diferencia. Una opción de contenido la podés arreglar. Una credencial filtrada ya está afuera, y revocarla no borra lo que pasó mientras estaba viva. Esto se conecta con lo que analizamos en cambios recientes en el núcleo de WordPress.
Los casos de uso típicos que justifican meter una key de IA en un WordPress son tres: generación de borradores de contenido, clasificación o etiquetado automático de posts, y moderación de comentarios. Los tres tienen algo en común: corren del lado del servidor, hablan con un proveedor externo y cobran por volumen. Nada de eso es «casual».
¿Cuál es la diferencia entre un feature toggle y una política operacional?
Un feature toggle es un control de interfaz: lo prendés o apagás desde el admin, sin tocar el servidor, y la decisión es reversible en un clic. Sirve para «mostrar bloque de IA en el editor: sí/no». Una política operacional es otra cosa: es configuración a nivel de infraestructura, definida durante el despliegue, que requiere acceso seguro y deja rastro de quién la cambió.
¿Por qué la credencial cae en la segunda categoría? Porque mezcla dinero, acceso externo y riesgo de fuga. Tres cosas que no querés que un editor de contenido toque sin querer un martes a la tarde.
| Aspecto | Feature toggle | Política operacional (API key) |
|---|---|---|
| Dónde se cambia | Admin / UI | wp-config.php, env vars, secrets manager |
| Quién lo toca | Admin de contenido | Dev / Ops |
| Reversible al instante | Sí | No (rotar key + redeploy) |
| Deja rastro de auditoría | Opcional | Obligatorio |
| Impacto de un error | Estético / funcional | Financiero / seguridad |
¿Dónde se almacenan y cómo se protegen las API keys en WordPress?
La regla base es vieja y sigue valiendo: el secreto no vive en la base de datos en texto legible. Si está en wp_options sin cifrar, cualquier dump de la base lo expone. Estas son las opciones reales, de menos a más robusta:
- Constante en wp-config.php: definís
define('AI_API_KEY', '...');arriba del «happy publishing». Está fuera de la base y fuera del control de versiones si tenés el.gitignorebien armado. - Variables de entorno: la key vive en el entorno del servidor (
$_ENV,getenv()), no en ningún archivo del proyecto. Es la opción más limpia para equipos. - Secrets manager: AWS Secrets Manager, Azure Key Vault o similar. Para sitios grandes donde la rotación tiene que ser automática y auditada.
Acá entra la infraestructura. Una key necesita un servidor que la lea por entorno sin exponerla en logs ni en la respuesta HTTP. Si vas a alojar un WordPress con IA nativa, asegurate de que tu hosting te deje definir variables de entorno y constantes sin pelearte (el hosting WordPress de Donweb te da acceso a wp-config.php y SSH, que es lo mínimo para hacer esto bien).
Sobre el cifrado en reposo: si por algún motivo la key tiene que pasar por la base, debería ir cifrada con una clave que esté fuera de la base. Guardar el candado al lado de la llave no sirve de nada.
¿Quién puede acceder y cambiar los API keys de IA?
Corto: dev y ops. No el editor, no el autor, ni siquiera el administrador de contenido por defecto. La capability de WordPress que define quién toca la configuración del sitio (manage_options) es demasiado amplia para esto, porque agrupa cosas inocuas con la credencial que paga la factura.
¿Por qué tanto cuidado? Por escalada de privilegios y por rotación. Si diez personas pueden ver la key, rotarla deja de ser un trámite y pasa a ser una negociación. Y un audit trail (registro de quién la cambió, cuándo y desde dónde) es lo único que te salva cuando algo se filtra y tenés que reconstruir qué pasó.
En equipos grandes la respuesta es no compartir el secreto en absoluto: cada entorno lee su propia key desde el secrets manager, y nadie la ve en texto plano. El acceso se concede al servicio, no a la persona. Te puede servir nuestra cobertura de probar cambios en entorno de prueba.
Configuración paso a paso: cómo definir y verificar una API key de IA
- Generá la key en el proveedor: creá una credencial dedicada en el panel de OpenAI o Anthropic, con el menor scope posible y, si se puede, un límite de gasto mensual.
- Definila como constante: en
wp-config.php, agregádefine('OPENAI_API_KEY', 'sk-...');antes derequire_once ABSPATH . 'wp-settings.php';. - Mejor todavía, usá entorno: seteá la variable en el servidor y leela con
define('OPENAI_API_KEY', getenv('OPENAI_API_KEY'));para no escribir el secreto en ningún archivo del repo. - Probá la conexión: hacé una llamada mínima de prueba y revisá que el proveedor responda 200. Un 401 es key mal copiada; un 429 es cuota.
- Verificá que no se loguea: revisá que la key no aparezca en logs de debug ni en respuestas de error.
WP_DEBUG_LOGactivado y un proveedor charlatán es una combinación peligrosa.
Errores críticos al manejar credenciales de IA en WordPress
Estos son los que veo una y otra vez. Ninguno es exótico, y todos se evitan con criterio.
- Pegar la key en un archivo del tema o en un commit: termina en GitHub público y los bots la encuentran en minutos. Solución:
wp-config.phpo env, y.gitignorebien armado. - Usar la misma key en staging y producción: si se filtra una, caen las dos. Una credencial por entorno, siempre.
- Guardarla en wp_options sin cifrar: cualquier backup de la base la expone. Si tiene que ir a la base, cifrada y con la clave afuera.
- No rotar nunca: una key de dos años acumuló riesgo en cada deploy, cada backup y cada dev que pasó. Rotación periódica, aunque sea trimestral.
- No poner límite de gasto: un loop mal escrito o una key robada te puede generar una factura de varios cientos de dólares en una noche. Seteá tope en el proveedor.
- Dejar WP_DEBUG_LOG activo con la key viajando: el secreto puede quedar escrito en
debug.log, un archivo que muchos sitios sirven sin querer.
Un detalle: si tu preocupación principal pasa a ser malware, fuerza bruta o hardening del servidor, eso ya es terreno de seguridad pura y lo cubre mejor el blog hermano seguridadenwordpress.com. Acá nos quedamos en el plano operativo de la credencial.
WordPress 7.0 (core con IA) vs plugins de IA de terceros
La distinción importa. Cuando un plugin de terceros maneja IA, la credencial suele vivir en su propia configuración y su alcance es el del plugin. Si el core integra IA de forma nativa, la credencial pasa a ser global: la usa todo el sitio, y un error de manejo impacta en todo, no en un módulo.
Por eso una key de core merece más cuidado que una de plugin. Más superficie, más impacto. Si vas a correr ambos (core con IA más un plugin de IA), entendé que tenés dos credenciales con dos ciclos de vida y dos lugares donde algo puede salir mal.
Qué está confirmado y qué no sobre WordPress 7.0
Seamos honestos, porque acá hay mucho ruido. A junio de 2026, WordPress 7.0 no tiene una versión estable publicada en el listado oficial de releases. Buena parte de lo que circula sobre «IA nativa en el core» es discusión de roadmap, no funcionalidad cerrada.
- Confirmado (y de siempre): guardar secretos en
wp-config.phpo variables de entorno es la práctica recomendada, documentada en el handbook de desarrollo. Eso no depende de la 7.0. - Confirmado: los proveedores de IA (OpenAI, Anthropic) permiten límites de gasto y keys con scope acotado. Real y disponible hoy.
- Pendiente / especulativo: que el core de WordPress incorpore un panel nativo de gestión de credenciales de IA con audit trail integrado. Si aparece, va a estar documentado en make.wordpress.org. Hasta entonces, tomalo con pinzas.
- Pendiente: cualquier cifra de adopción o benchmark de «WordPress 7.0 con IA». No hay datos verificables todavía.
Preguntas Frecuentes
¿Qué es una API key de IA en WordPress?
Es una credencial secreta que autentica a tu sitio contra un proveedor de modelos como OpenAI o Anthropic, para que WordPress o un plugin puedan generar contenido, clasificar posts o moderar comentarios. Tiene costo por uso y, si se filtra, permite gastar tu saldo o acceder a tu integración. Relacionado: mantener tu sitio en buen estado.
¿Dónde se guarda de forma segura una API key en WordPress?
En wp-config.php como constante o, mejor, en variables de entorno del servidor. Nunca en la tabla wp_options sin cifrar ni en archivos del tema. La regla es que el secreto viva fuera de la base de datos y fuera del control de versiones.
¿Por qué se trata como política operacional y no como un toggle?
Porque una credencial mezcla dinero, acceso externo y riesgo de fuga. Un toggle se revierte en un clic sin consecuencias; una key filtrada ya está afuera y revocarla no deshace el daño previo. Eso pide acceso restringido y auditoría.
Profundizamos en este tema en WordPress 7.0 put AI API keys in the admin. Treat that as an análisis específico.
¿Cada cuánto conviene rotar la API key?
Como mínimo de forma trimestral, y de inmediato si sospechás de una filtración o si se va alguien del equipo que tenía acceso. Una credencial que vive años sin cambiar acumuló exposición en cada deploy y cada backup.
¿WordPress 7.0 ya trae gestión de IA en el core?
A junio de 2026 no hay una versión estable de WordPress 7.0 publicada con esa funcionalidad confirmada. Lo que sí está disponible y documentado son las prácticas de manejo de secretos vía wp-config.php y variables de entorno, que aplican uses la versión que uses.
Conclusión
Lo que cambia con la IA en WordPress no es la interfaz: es que ahora una credencial paga dinero real y habla con un servicio externo desde tu sitio. Tratarla como un toggle es el error de fondo. La configuración de API keys de IA en WordPress pide el mismo rigor que cualquier secreto de producción: fuera de la base, fuera del repo, con acceso de dev/ops y rotación periódica.
Si vas a probar IA nativa cuando la 7.0 madure, armá la base ahora: definí dónde van a vivir tus secretos, quién los toca y cada cuánto rotás. Cuando llegue el feature, la decisión difícil ya va a estar resuelta. Mientras tanto, no creas todo lo que se escribe sobre la 7.0 hasta que aparezca en la doc oficial.
