WordPress 7.0 y la IA: ¿una imposición? Cómo cambia el trabajo de las web agency

Quien esperaba un redactor automático en el escritorio se llevó una decepción, y menos mal. El core no impuso ningún proveedor de IA: puso tres ladrillos bajo el suelo, y son ladrillos de sistemas, no de marketing.

WP AI Client: un único canal hacia los modelos

Es una interfaz PHP independiente del proveedor: los plugins hablan con los modelos generativos sin reescribir la integración cada vez, y el enrutado de las peticiones lo gestiona el core. Quien desarrolla puede declarar una preferencia de modelo con using_model_preference() y construir los prompts con WP_AI_Client_Prompt_Builder. Traducido: el modelo pasa a ser un detalle de configuración, no una decisión grabada en el código del tema.

Abilities: el sitio se vuelve invocable

Las Abilities, introducidas en WordPress 6.9 y disponibles también en el cliente con 7.0, son acciones registradas con esquema de entrada y salida, permisos y anotaciones: solo lectura, idempotente, destructiva. Así un asistente —o un flujo interno— descubre qué sabe hacer el sitio y lo ejecuta, sin un endpoint REST artesanal por cada plugin. Encima está el adaptador MCP: herramientas como Claude, ChatGPT o Gemini pueden ver esas acciones e invocarlas. No es magia, es un contrato.

Connectors: dónde acaban las claves API

En Ajustes → Connectors se gestionan las conexiones a los proveedores: Anthropic, Google y OpenAI por defecto, más conectores propios. Ojo a un detalle que en producción marca la diferencia: las claves introducidas desde esa pantalla están enmascaradas en pantalla pero no cifradas en la base de datos. En un sitio en producción deben venir de variables de entorno o constantes PHP.

El ciclo posterior a un major siempre dice más que el propio major. Aquí dijo dos cosas: el core se estabilizó rápido y la seguridad no esperó vuestros planes de publicación.

9 de julio de 2026 — 7.0.1, mantenimiento

Versión menor con 31 correcciones repartidas entre core, editor de bloques y medios. Nada que contar al cliente, todo que planificar.

17 de julio de 2026 — 7.0.2, la versión que se instaló sola

Versión de seguridad con una vulnerabilidad crítica y otra alta (CVE-2026-60137 y CVE-2026-63030). WordPress.org forzó las actualizaciones automáticas en las versiones afectadas, con backports en 6.9.5 y 6.8.6. Si gestionáis cincuenta o doscientos sitios, este es el punto que duele: un update de core puede arrancar de noche sobre un catálogo que nadie probó en staging. Si aún tenéis instalaciones por debajo de 6.8, ese backport no os cubre.

19 de agosto de 2026 — 7.1 «Mary Lou»

Menos IA de manifiesto, más trabajo diario: barra de administración coherente en todo el backend, visibilidad responsive de los bloques sin CSS a medida, nuevo editor de medios con recorte libre, volteo y rotación, Notes con texto enriquecido y @menciones en cualquier punto del contenido, bloques Playlist y Tabs, API para registrar conjuntos de iconos SVG. La 7.1 no contradice a la 7.0: la hace usable por un equipo.

Depende de qué entendáis por imposición. Conviene separar las dos caras, porque la respuesta no es la misma.

Qué no es obligatorio

• Ningún proveedor incluido. El core no trae un proveedor de IA: sin conectores configurados, no se ejecuta nada.
• Funciones opt-in. Resúmenes, extractos y textos alternativos generados viven en gran parte entre los experimentos de IA, que se activan a mano.
• Ningún coste oculto. Los tokens los paga quien conecta su clave. Un sitio 7.x puede quedarse mudo hacia los modelos y funcionar como antes.

Qué sí tenéis que asumir

• La plataforma está lista para agentes. Los plugins serios registrarán abilities: el sitio se vuelve gobernable desde fuera, os guste o no.
• El mercado se mueve antes que vosotros. Los clientes preguntarán «¿también lo hace la IA?» y la competencia venderá paquetes de contenido automático.
• Las actualizaciones forzadas. La 7.0.2 entró en producción sin pedir permiso a ninguna agencia.

Así que no, la IA no está impuesta. Pero el modelo de responsabilidad cambió igualmente: la superficie que hay que gobernar se amplió, y el auto-update de seguridad recordó a todos que en WordPress el tiempo lo tiene quien tiene staging, copias de seguridad y una ventana de verificación. Los demás se enteran por el ticket del cliente.

En la construcción: del sitio al sistema

El valor se mueve de la página suelta a la instalación: theme.json, patrones cuidados, bloques registrados en PHP, abilities documentadas. Así se entregan diez sitios coherentes sin clonar a mano el maquetador. La IA no sustituye el design system: lo consume. Si los patrones son débiles, el resultado generado es débil; si los permisos de las abilities son amplios, ese resultado se convierte en un daño.

En el mantenimiento: hace falta el inventario de abilities

La cuota de mantenimiento ya no cubre solo versiones y copias. Ahora necesita respuestas a preguntas nuevas: qué plugins exponen abilities, cuáles son destructivas, dónde están las claves API, quién puede activar un proveedor. Y necesita un protocolo de actualización escrito, porque 7.0.1 y 7.0.2 demostraron que «actualizamos cuando hay tiempo» no es una estrategia.

En lo comercial: se vende gobernanza, no maquetación

Generar un borrador de página o un alt text cuesta poquísimo, y el cliente lo va a descubrir. Lo que no sabe hacer solo es sostener voz de marca, calidad, accesibilidad, SEO y responsabilidad. La agencia que vende horas de maquetación compite con un modelo de lenguaje. La que vende contenidos revisados, flujos con aprobación, monitorización y hosting aislado sube la cuota en lugar de bajar el presupuesto.

• Setup de IA y permisos — configuración de conectores, claves fuera de la base de datos, roles habilitados, lista de abilities activas con sus anotaciones. Una vez, por proyecto.
• QA editorial de la IA — revisión humana de los contenidos generados: tono, fuentes, accesibilidad, SEO. Por volumen o por cuota.
• Actualizaciones de core con staging — ventana de verificación, rollback, informe al cliente. Es el servicio que la 7.0.2 hizo vendible sin tener que explicar por qué hace falta.

Tres partidas que el cliente entiende y que defienden el margen: ninguna de las tres es replicable con un prompt.

• Llevad el parque a 7.1 (o al menos a 7.0.2 / 6.9.5 / 6.8.6 según la rama) después de una pasada por staging.
• Haced la lista de plugins y temas que registran abilities, marcando las destructivas.
• Decidid si la IA está encendida, para qué roles y en qué entornos. Dejadlo por escrito.
• Sacad las claves API de la base de datos, a variables de entorno o constantes PHP.
• Comprobad que copias y staging aguantan una actualización forzada en fin de semana.
• Explicad al cliente quién paga los tokens, quién ve los datos enviados al modelo y quién responde si acaba online un disparate.

WordPress no os obliga a que un modelo escriba los sitios. Os obliga a tratar el sitio como una plataforma con acciones invocables. Es la misma curva que con Gutenberg, los block themes y WooCommerce: quien se adapta vende mejores servicios, quien espera a que pase la moda acaba arreglando sitios que los clientes ya han empezado a tocar con IA por su cuenta.

En Host.it los sitios WordPress corren sobre infraestructura italiana, con copias de seguridad, SSL y Application Manager para publicar y actualizar sin dramas. Si gestionáis muchos clientes, lo que marca la diferencia sigue siendo banal y decisivo: staging, observabilidad y alguien a quien llamar cuando una actualización de seguridad cae un sábado por la noche. La IA en el core no elimina esa necesidad: la hace más urgente.