WordPress 7.0 llegó con Armstrong prometiendo IA nativa, Connectors API y un hub central para conectar OpenAI, Anthropic o Google desde Settings → Connectors. Suena ordenado. Lo que no te cuentan en el anuncio es que, si pegas ahí tu API key, acaba en la base de datos en texto plano. Y en un ecosistema donde un plugin vulnerable ya te puede tumbar la web, ahora también te puede vaciar la cuenta de tokens de IA.
Yo llevo años montando y manteniendo WordPress para pymes. Cuando vi la Connectors API pensé: por fin dejaremos de repetir el mismo formulario de credenciales en quince plugins distintos. Tiene sentido arquitectónico. Pero la implementación por defecto me ha dejado con la misma sensación que cuando Gutenberg entró en core: la dirección es clara, el prudente eres tú.
Oliver Sild, de Patchstack, lo resumió sin rodeos en Search Engine Journal: «WordPress 7.0 combinado con vulnerabilidades de plugins equivale a tokens de IA gratis». No es alarmismo de Twitter. Es el tipo de frase que suena exagerada hasta que recuerdas cuántos sitios siguen con plugins sin actualizar semanas después de un parche.
El problema no es la IA, es dónde guardas la llave
La documentación oficial de la Connectors API deja claro que las claves guardadas en base de datos van sin cifrar. Hay un ticket abierto en Trac (#64789) para cifrado nativo, pero a fecha de hoy sigue en discusión. Mientras tanto, tu clave de OpenAI vive en wp_options como cualquier otra opción del panel.
En SecureWP lo explican bien: cifrar ayudaría si alguien roba un volcado de la base de datos o una copia de backup mal guardada. No te protege si ya hay código PHP malicioso ejecutándose dentro del WordPress, porque el propio core tiene permiso para usar el conector. Es decir, la centralización no reduce el radio de explosión ante un plugin comprometido: lo amplía, porque ahora un solo agujero puede darte acceso a varios proveedores de IA a la vez.
WordPress corrigió otro fallo (#64793) que enmascaraba la clave en la interfaz y desactivaba la edición desde pantalla, pero eso no arregla el almacenamiento. También salió un bug en el formulario de configuración donde el autocompletado del navegador mostraba la clave en texto claro en el desplegable. Perfecto para una demo en videollamada o un ordenador compartido en recepción.
Lo que dicen en inglés (y aquí aún no ha explotado el debate)
En Hacker News, el hilo de WordPress 7.0 está lleno de usuarios veteranos que plantean migrar a ClassicPress precisamente por la integración forzada de IA. No porque odien la tecnología, sino porque no quieren otra superficie de ataque en core. Un comentario lo resume: credenciales de IA en WordPress, un script PHP… qué puede salir mal.
La respuesta sensata de quienes conocen la API —la recogen en Digital Matters— es usar variables de entorno o constantes PHP para que la clave nunca pase por la base de datos. El propio diseño de Connectors evalúa credenciales en cascada: entorno → constante → opción de BD. El camino seguro existe. El camino cómodo, el del panel con tres clics, es el peligroso.
En hosting compartido, donde muchas pymes tienen su WordPress, pedir al cliente que configure wp-config.php o variables en el servidor es… digamos optimista. El flujo que WordPress empuja visualmente es pegar la clave en Connectors. Y ahí está el choque: la UX invita a lo fácil, la seguridad pide lo incómodo.
¿Y si no uso IA en mi web?
Aunque no actives ninguna ability, el conector sigue ahí. La infraestructura forma parte del core. Eso no te obliga a meter claves, pero sí cambia el perfil de riesgo del ecosistema: los atacantes buscan sitios con credenciales de servicios de pago por uso. Una clave de OpenAI con crédito puede generar miles de euros en horas. Un plugin desactualizado que antes solo defaceaba la home ahora puede convertirse en minero de tokens.
El plugin oficial de IA de WordPress incluye un experimento opt-in de cifrado con libsodium. Bien. Pero es opt-in, experimental, y no sustituye la necesidad de sacar las claves del panel en producción. Si gestionas webs de clientes, tu checklist de septiembre debería incluir: revisar quién tiene acceso a Connectors, auditar plugins con integración IA y mover claves a entorno antes de que alguien las pegue en un staging público.
Me fastidia ser pesimista porque la Abilities API y el AI Client, bien usados, pueden simplificar cosas reales: alt text, borradores, resúmenes. Pero venderlo como «IA integrada en todo WordPress» sin resolver primero dónde viven las credenciales es poner el carro delante de los bueyes. Otra vez.
Si tu proveedor de hosting te ofreciera activar Connectors con un clic pero te garantizara que la clave nunca toca la base de datos, ¿confiarías más en eso que en enseñarte a configurar la variable de entorno tú mismo?