Has actualizado a WordPress 7, te has ido a Ajustes > Conectores, has pegado tu clave de OpenAI, de Anthropic o de Gemini, y desde ese momento cualquier plugin compatible de tu web puede usarla. Cómodo ¿verdad?.

El problema es que esa clave se queda guardada en tu base de datos tal cual, sin cifrar, así que la respuesta corta a la pregunta del título es que sí, que puedes meter las claves de tu IA en WordPress, pero con cuidado y sabiendo qué estás aceptando.

Y te lo cuenta alguien que tiene un plugin, AI Share & Summarize, que usa precisamente esos conectores para hacer sus resúmenes con IA, así que esta duda me la comí yo el primero, como casi siempre, y ahora a ti te toca aprende de mis errores, para variar.

Vamos a verlo con calma, sin agobios y con las fuentes en la mano, que de esto se está hablando mucho y no siempre bien.

Índice de contenidos

Para qué sirven los conectores, y por qué la idea no es mala

Empecemos por lo que está bien, que también hay que decirlo. Hasta WordPress 7 cada plugin de IA se buscaba la vida por su cuenta.

Uno te pedía la clave de OpenAI por aquí, otro la de Gemini por allá, cada cual con su formulario, su pantalla de ajustes y su pequeño reino de taifas.

Al final acababas con la misma clave copiada en cinco sitios distintos y, cuando querías cambiar de proveedor, te tocaba ir plugin por plugin rezando para no romper nada.

WordPress 7 ordena ese caos, metes la clave una sola vez en Ajustes > Conectores, eliges proveedor, y todos los plugins compatibles tiran de esa misma conexión a través del cliente de IA nativo.

Cambiar de proveedor pasa a ser un clic, y como idea de inteconexión está muy bien, como te cuentan con todo detalle en la nota de desarrollo de la Connectors API. Ahora bien, que la idea sea buena no significa que venga sin letra pequeña, y la letra pequeña está en dónde acaba esa clave.

Dónde se guardan tus claves de IA

Tu clave se guarda en la base de datos de WordPress, en la tabla de opciones, en texto plano y sin cifrar. En la pantalla la ves con puntitos, enmascarada, pero eso es maquillaje de cara a la galería, porque internamente está entera y legible para cualquiera que pueda leer esa tabla.

No es una sospecha mía, lo reconoce la propia documentación del proyecto, que admite que las claves no se cifran y que el cifrado todavía está en estudio en un ticket abierto del núcleo.

¿Y por qué no la cifran y a correr, o por qué no la guardan con un hash como las contraseñas? Pues porque una clave de API no es una contraseña.

La contraseña WordPress puede convertirla en un churro irreversible (un hash) y compararla, porque solo necesita saber si coincide.

La clave de IA, en cambio, tiene que recuperarla entera cada vez que llama a OpenAI o a Claude, porque hay que enviársela al proveedor tal cual, y un hash aquí no vale, lo único que ayudaría es cifrado reversible, que es justo lo que falta hoy.

Las dos posibles amenazas

Aquí está la madre del cordero, y lo más complicado. Cuando hablamos del riesgo de esa clave que se guarda tal cual, abierta, en realidad hay dos peligros distintos, y conviene no mezclarlos porque no se arreglan igual.

Robo en frío

El primero es que alguien se lleve tu base de datos sin siquiera pisar tu web, y es que un backup mal guardado en una carpeta pública, un volcado que acaba donde no debe, una inyección SQL, la clave que se cuela en un registro de errores.

En todos esos casos la clave viaja en ese paquete, legible. Aquí el cifrado sí serviría, porque quien se llevara la base de datos se encontraría un montón de caracteres ilegibles en lugar de tu clave, y por eso el ticket de cifrado es importante, aunque hoy no esté.

Código malicioso dentro

El segundo peligro es código malicioso ejecutándose dentro de tu propia web, y este es el gordo.

Un plugin que instalas se ejecuta en el mismo proceso que WordPress, con sus mismos permisos, así que puede leer esa opción de la base de datos y quedarse con tu clave.

O ni siquiera eso, porque puede llamar directamente a la función del cliente de IA y dejarte sin un token, tieso, sin haber tenido siquiera la necesidad de ver la clave.

Ni siquiera el cifrado, cuando llegue, te protegerá de este segundo caso. Un plugin cabrón que ya está funcionando dentro de tu web puede pedirle la clave descifrada al propio WordPress, igual que se la pides tú.

Al ser un ajuste del sitio, cualquier plugin puede acceder a la clave, y ponerla como variable de entorno o como constante en wp-config.php tampoco lo arregla, porque el código de terceros que instalas se ejecuta con los mismos privilegios.

O sea, que tu clave compartida es tan de fiar como el menos de fiar de los plugins que tengas instalados. Te doy la bienvenida al modelo de confianza de WordPress de toda la vida.

¡Pues yo he visto una pantalla de aprobación de conectores!

Aquí toca un aviso, porque circula por ahí y se presta a malentendidos. Hay un plugin oficial de pruebas, llamado AI Experiments, que añade una pantalla en Herramientas > Aprobaciones de conectores donde apruebas (o no), plugin por plugin y proveedor por proveedor, quién puede usar la IA.

Suena de maravilla, y tiene su lógica.

Pero hay dos detalles que debes tener en cuenta:

Esa pantalla no es de WordPress, es de ese plugin de pruebas, un plugin canónico para experimentar que ni tienes instalado ni tienes por qué instalar.
La aprobación solo controla a los plugins que pasan por la puerta principal y piden permiso. El plugin que viene con malas intenciones no pide permiso a nadie, lee la clave directamente de la base de datos y se salta esa pantalla como si no existiera.

Una aprobación así es buena idea, está bien para tener orden, pero no es un muro contra código hostil que ya está dentro de tu web.

Si la ves y piensas que con eso ya estás cubierto, te estás engañando, y te recuerdo, además, que el plugin se llama AI Experiments, es para pruebas, no es un plugin para usarlo en producción.

¡Mujeres y niños primero!

A ver, ni es el próximo WordPress Drama ni tampoco es para no darle importancia, que la tiene, sino no me habría estado informando, ni llevaría más de 2 horas preparando y redactando este artículo.

Una clave de IA comprometida es, básicamente, una tarjeta de crédito sin límite de gasto metida en un cajón que abre cualquiera que entre en tu casa.

Quien se haga con ella puede tirar de tu cuenta hasta dejarte una factura de las que duelen, y de paso llevarse la clave para usarla en su propia infraestructura, fuera de tu web, hasta que te des cuenta y la cambies.

Si encima reutilizas esa misma clave en otro servicio, el estropicio se multiplica. Así que no es cosa de broma.

¡Que no cunda el pánico!

No nos vengamos arriba, que esto no es un algo que sea ni nuevo ni exclusivo de WordPress 7.

Cualquier plugin que instalas lleva años pudiendo leer todo lo que hay en la tabla de opciones, y ahí dentro hay claves de pasarelas de pago, tokens de servicios de email y mil cosas más.

Tampoco es nada nuevo que WordPress confíe en el código que tú decides instalar. Lo que sí es nuevo, y lo que de verdad complica la cosa es el mejunje, y que hay pasta detrás.

Esta clave es dinero al instante, no como una clave de analítica que como mucho te ensucia datos, la comparten muchos plugins por diseño en lugar de uno solo, y el núcleo la guarda en claro justo cuando todo el sector iba hacia, como mínimo, ofuscarla.

Cómo hacerlo bien si desarrollas plugins

Esto es para quien programa, así que si no es tu caso puedes saltarte esto.

Si tu plugin necesita IA, la regla de oro es no tocar la clave, para eso está la función wp_ai_client_prompt() del núcleo, la del cliente de IA de WordPress 7.

Tú le pasas el prompt y WordPress se encarga de coger la clave del conector y hablar con el proveedor, así que tu plugin no ve la clave, no la guarda y no puede filtrarla por un descuido. Lo explican en la nota de desarrollo del cliente de IA.

Te lo digo con conocimiento de causa, porque mi plugin AI Share & Summarize está hecho exactamente así. Usa wp_ai_client_prompt(), nunca lee la clave del conector, no llama a ningún proveedor de IA por su cuenta y, si no hay IA disponible, hace un resumen extractivo en PHP en local sin gastar un céntimo.

Ese es el camino correcto, y de paso te ahorras ser el responsable de custodiar credenciales ajenas.

Y un par de avisos más, de cajón pero que se olvidan. Si registras abilities que puedan invocar el modelo, ponles siempre su permission_callback con una capacidad propia, nunca un __return_true que deja la puerta abierta de par en par.

Y sé honesto con lo que no controla nadie, porque aunque lo hagas todo bien, el contenido que resumes o procesas viaja igualmente al proveedor de IA, que eso es inevitable con cualquier IA en la nube.

Lo que tú evitas es ver y guardar la clave, que no es poco, pero no vendas que «no sale nada de tu web», porque no sería verdad.

Qué puedes hacer hoy mismo

Aclarado esto vamos a lo práctico, que es a lo que has venido. Por orden, de lo que más te protege a lo que menos:

Si no vas a usar la IA, apágala del todo: Parece de perogrullo pero es así. Con una línea en tu wp-config.php, define( 'WP_AI_SUPPORT', false ); desactivas todas las funciones de IA nativas y no hay clave que guardar ni conexión que vigilar. La opción más segura siempre es la que no existe.
Pon un tope de gasto y avisos en el panel de tu proveedor: Esto es lo único que limita de verdad el «arruinar», porque acota la factura aunque te roben la clave. En OpenAI, en Anthropic o en Google tienes límites de uso y alertas de consumo, así que configúralos antes de conectar nada. Es la red de seguridad más importante de toda la lista.
Rota la clave cada cierto tiempo, y al instante si sospechas: Generas una nueva en el panel del proveedor, la pegas en Conectores, revocas la vieja, y cualquier copia robada se queda muerta.
Reduce el número de administradores: Cuantas menos personas con permisos de administración, menos manos que pueden ver o tocar esa pantalla. Roles mínimos para cada uno, que es de cajón.
No instales plugins de cualquier sitio: Ya lo conté largo y tendido en el artículo sobre los ataques a la cadena de suministro de plugins, y aquí aplica igual, porque el riesgo de esa clave es, literalmente, el riesgo del peor plugin que tengas.
Añade una capa de vigilancia, como por ejemplo mi plugin de seguridad Vigilante, que con su registro de actividad te avisa si alguien toca los ajustes de conectores y con su escáner de archivos te ayuda a pillar un plugin haciendo cosas raras. Eso sí, ningún plugin, ni el mío ni el de nadie, cifra hoy esa clave del núcleo, eso es tarea de WordPress, no de un plugin.

Por cierto, un detalle sobre lo de meter la clave por constante o por variable de entorno en vez de en la base de datos.

Eso te protege del robo en frío, porque un volcado de la base de datos ya no la contiene, pero no te protege del plugin malicioso, que sigue pudiendo leerla porque corre en tu mismo servidor.

Entonces, ¿meto la clave o no?

Pues mira, depende de lo que valores. Si vas a usar la IA y te tomas en serio el tope de gasto, la rotación de la clave y el cuidado con lo que instalas, adelante, que los conectores son cómodos y la idea está bien resuelta, pero si no la vas a usar, la apagas y a otra cosa.

Lo que no haría nunca es pegar la clave y olvidarme, porque esa comodidad tiene un precio, y el precio es que estás dejando una llave que vale dinero en un cajón que abre cualquier inquilino que metas en casa.

Desde hace tiempo hemos pasado de ser dueños de nuestro software a ser inquilinos de la inteligencia artificial, y esto es un recordatorio más de que la llave de esa inteligencia, ahora, la guardas tú en tu propia web, con todo lo que eso conlleva.

La IA en el núcleo de WordPress ha venido para quedarse, simplemente recuerda dónde dejas la llave, al final es tu decisión.