WordPress 7.0 y la IA nativa: cómo funciona el WP AI Client y qué cambia para los desarrolladores

WordPress 7.0 WP AI Client integración IA nativa

WordPress 7.0 integra por primera vez una infraestructura de inteligencia artificial directamente en el core. No se trata de un plugin o de una integración de terceros: es una API PHP nativa, agnóstica de proveedor, que permite a cualquier plugin enviar prompts a modelos de IA y recibir respuestas a través de una interfaz estandarizada. Esto convierte a WordPress en el primer CMS mainstream con soporte nativo para IA generativa.

En este artículo analizamos en profundidad los cuatro pilares de esta arquitectura y sus implicaciones prácticas para agencias de desarrollo y equipos técnicos.

Dónde estamos: la 7.0 ya está publicada y la 7.1 también

WordPress 7.0, con nombre en clave «Armstrong» en homenaje a Louis Armstrong, se publicó el 20 de mayo de 2026 tras retrasarse desde el objetivo inicial del 9 de abril. Fue una de las releases más participadas de la historia del proyecto —más de 875 contribuidores, de los cuales unos 200 debutaban— y abrió oficialmente la fase 3 de Gutenberg, la dedicada a la colaboración.

Desde entonces el ciclo ha seguido avanzando: la 7.1 «Mary Lou» salió el 19 de agosto de 2026 y la rama estable actual es la 7.1.2, publicada el 22 de septiembre de 2026. La 7.2 tiene como fecha objetivo el 10 de diciembre de 2026. Conviene tener presente que WordPress solo da soporte activo a la última versión, así que quedarse en la 7.0 no es una posición neutra: es quedarse sin parches de seguridad.

Línea temporal de los releases de WordPress desde la versión 6.9 Gene hasta la 7.2, con fechas y novedades de cada versión
El ciclo de releases de WordPress desde la 6.9: dos versiones mayores al año y soporte activo solo para la última.

Dos cambios de la 7.0 afectan a la planificación de cualquier proyecto en producción. El primero es que el mínimo de PHP sube a 7.4 (se abandonan 7.2 y 7.3), aunque la recomendación oficial es PHP 8.3 o superior; el mínimo de MySQL no se movió, pero lo recomendado es MySQL 8.0 o MariaDB 10.11. El segundo es lo que no llegó: la edición colaborativa en tiempo real se retiró de la 7.0 por problemas de rendimiento y carga de servidor, y tampoco entró en la 7.1. El plan de los contribuidores es sacarla antes como feature plugin, sin fecha comprometida. Si alguien ha vendido un proyecto prometiendo edición simultánea estilo Google Docs en el editor, conviene saberlo.

La 7.1, por su parte, añadió cosas menos vistosas pero útiles en el día a día: procesado de imágenes en el propio navegador, soporte de AVIF y HEIC, estilos responsive y los bloques Tabs y Playlist.

Los cuatro pilares de la arquitectura de IA en WordPress 7.0

La integración de IA en WordPress 7.0 se estructura en cuatro componentes que trabajan juntos:

WP AI Client: la API PHP central que permite a los plugins comunicarse con modelos de IA de forma agnóstica. Tu plugin describe qué necesita, WordPress enruta la petición al modelo adecuado según la configuración del sitio.

Client-Side Abilities API: extiende las capacidades de IA al navegador. Los agentes de IA y las herramientas de automatización pueden interactuar con WordPress desde dentro del browser: navegar por el admin, insertar bloques, ejecutar comandos y participar en flujos de trabajo.

Pantalla de Connectors: un hub centralizado en Settings > Connectors donde los administradores gestionan todas las conexiones a servicios de IA externos. Se acabó tener claves de API dispersas por configuraciones de plugins individuales.

Connectors API: la capa técnica detrás de la pantalla de Connectors. Gestiona el registro de proveedores, la autenticación, los metadatos y los tipos de conexión. Cualquier plugin puede registrar nuevos tipos de conectores.

wp_ai_client_prompt(): el punto de entrada

Toda interacción con la IA en WordPress 7.0 empieza con una llamada a wp_ai_client_prompt(). Esta función devuelve un objeto WP_AI_Client_Prompt_Builder con una interfaz fluida que permite encadenar configuraciones y generar respuestas de distintas modalidades: texto, imágenes, audio y vídeo.

El builder ofrece métodos como using_temperature(), using_max_tokens(), using_system_instruction() y using_model_preference() para controlar el comportamiento del modelo. La respuesta se obtiene con generate_text(), generate_image() o sus variantes generate_*_result() que devuelven metadata completa (uso de tokens, proveedor, modelo utilizado).

Lo más relevante para desarrolladores: no necesitas gestionar credenciales ni construir integraciones específicas por proveedor. Tu plugin funciona con cualquier proveedor que el administrador haya configurado.

Preferencia de modelos y detección de capacidades

Dado que cada sitio WordPress puede tener diferentes proveedores de IA configurados, el AI Client introduce un sistema de preferencia de modelos. Tu plugin puede indicar una lista ordenada de modelos ideales (por ejemplo, Claude Sonnet, Gemini Pro, GPT-5.2), y el sistema usará el primero disponible, cayendo al siguiente modelo compatible si ninguno de la lista está configurado.

Antes de mostrar interfaces de IA al usuario, se recomienda usar los métodos de detección de capacidades: is_supported_for_text_generation(), is_supported_for_image_generation(), etc. Estas comprobaciones son determinísticas (no hacen llamadas a la API) y permiten ocultar o mostrar funcionalidad de IA de forma condicional. Si trabajas con WooCommerce, esto permite activar generación automática de descripciones de producto solo cuando el sitio tenga un proveedor de texto configurado.

Arquitectura de dos capas: PHP SDK + wrapper de WordPress

La implementación interna se divide en dos capas. La primera es el PHP AI Client (wordpress/php-ai-client), un SDK PHP agnóstico que gestiona la comunicación con proveedores, la selección de modelos y la normalización de respuestas. Usa convenciones camelCase y excepciones, y puede ser usado por otros proyectos PHP fuera de WordPress.

La segunda capa es el wrapper de WordPress: la clase WP_AI_Client_Prompt_Builder que adapta el SDK a las convenciones de WordPress (métodos snake_case, retorno de WP_Error en lugar de excepciones, integración con el transporte HTTP de WordPress y el sistema de hooks).

Para desarrolladores de plugins, la recomendación es usar siempre wp_ai_client_prompt() como punto de entrada. Esta función captura las excepciones del SDK subyacente y las convierte en objetos WP_Error estándar.

Diagrama de la arquitectura en capas del WP AI Client de WordPress 7.0: plugin, wrapper de WordPress, PHP AI Client, Connectors API y plugin de proveedor
El recorrido completo de un prompt: tu plugin nunca habla directamente con el proveedor.

Plugins oficiales de proveedores de IA

WordPress Core no incluye ningún proveedor de IA directamente. Los proveedores se implementan como plugins separados, lo que permite iteraciones más rápidas en un ecosistema que evoluciona constantemente. El proyecto WordPress ha desarrollado tres plugins oficiales iniciales:

AI Provider for Anthropic (Claude), AI Provider for Google (Gemini) y AI Provider for OpenAI (GPT). Cualquier desarrollador puede crear plugins de proveedor adicionales registrándose en el registry del PHP AI Client.

Abilities API: IA que actúa dentro de WordPress

La Client-Side Abilities API es quizás el componente con más potencial a medio plazo. No se trata solo de generar contenido: permite que herramientas de IA y automatización interactúen con WordPress desde el navegador. Navegar por el admin, insertar bloques, ejecutar comandos y participar en workflows son acciones que ahora se exponen a través de una interfaz compartida.

Esto abre la puerta a que WordPress se convierta en un entorno donde los agentes de IA operan, no simplemente un lugar donde se pega contenido generado externamente. Para agencias que trabajan con auditorías técnicas y optimización de procesos, las posibilidades de automatización se multiplican.

El MCP Adapter: agentes externos trabajando sobre tu sitio

Junto al AI Client y la Abilities API, la 7.0 trajo un componente del que se habla menos y que a medio plazo puede cambiar más cosas: un MCP Adapter oficial. MCP (Model Context Protocol) es el protocolo que usan los clientes de IA para descubrir y ejecutar herramientas externas, y el adaptador expone las abilities registradas en WordPress como herramientas MCP.

En la práctica eso significa que un agente que corre fuera del sitio —Claude Code, Cursor o Codex, por citar los tres que se mencionaron en el anuncio— puede leer y escribir en un WordPress sin que nadie programe una integración a medida. Donde antes había que montar endpoints REST propios, autenticarlos y documentarlos, ahora basta con registrar la ability y decidir quién puede invocarla.

Esto es potente y es exactamente donde hay que poner el foco de seguridad. Un agente con acceso de escritura a un sitio en producción es, a efectos prácticos, un usuario más con permisos de edición, y hay que tratarlo como tal: credenciales propias, permisos mínimos, registro de lo que hace y posibilidad de revocar el acceso en un clic. Si el sitio es el canal de venta de la empresa, esto entra de lleno en el terreno de la seguridad informática básica de la organización, no en el de las herramientas de productividad.

El plugin oficial de IA: lo que se puede hacer sin escribir código

Para equipos sin desarrollo propio, el punto de entrada no es el AI Client sino el plugin oficial de IA que acompaña a la release. Cubre los casos de uso más repetidos en cualquier sitio de contenidos: generación de títulos, extractos, textos alternativos de imágenes y generación de imágenes.

El alt text automático es, de lejos, el que más rendimiento da por esfuerzo invertido. Un sitio con varios cientos de imágenes sin alt tiene a la vez un problema de accesibilidad y uno de SEO de imágenes, y rellenarlo a mano es el tipo de tarea que nunca sube en la lista de prioridades. Dicho eso, la recomendación es revisar lo generado antes de publicarlo en masa: un alt text que describe literalmente lo que se ve («gráfico con barras azules») es peor que uno que explica qué significa la imagen en el contexto de la página.

Hay un detalle importante de diseño que conviene subrayar: el core no incluye ningún proveedor y no hace ninguna llamada a IA por su cuenta. Mientras nadie configure un conector en Settings > Connectors y mientras ningún código llame explícitamente al AI Client, un WordPress 7.1 no manda nada a ningún modelo. La infraestructura está ahí, pero apagada por defecto. Es la respuesta directa a la parte de la comunidad que leyó «IA en el core» como «mi sitio empieza a enviar datos a terceros».

Control y seguridad: quién puede usar la IA

WordPress 7.0 incluye mecanismos de control granular. El filtro wp_ai_client_prevent_prompt permite bloquear prompts específicos según condiciones (rol del usuario, tipo de petición, etc.). La API JavaScript del lado del cliente requiere por defecto capacidades de administrador, y la recomendación oficial es implementar endpoints REST individuales para cada funcionalidad de IA en lugar de exponer la API genérica.

Para proyectos en producción, esto significa que el equipo técnico mantiene el control total sobre qué funcionalidades de IA están disponibles y para quién.

Cómo preparar un proyecto WordPress para la IA nativa

Si gestionas un sitio en producción y quieres aprovechar esta infraestructura sin sobresaltos, este es el orden que seguimos nosotros:

1. Subir la base técnica antes que nada. PHP 8.3 o superior y una base de datos en versión recomendada. No es un capricho: buena parte de los problemas que se atribuyen a las releases nuevas son en realidad entornos con PHP antiguo y plugins que ya no se mantienen.

2. Inventariar los plugins que vas a tener que vigilar. Antes de actualizar una versión mayor, lista qué plugins tocan el editor, el frontend crítico y el checkout. Esa lista es la que hay que probar en staging, no el sitio entero. Es el mismo criterio que detallamos en nuestra guía para actualizar WordPress 7 en una empresa.

3. Decidir el proveedor antes de instalar el conector. Y decidirlo por criterios de negocio: dónde se procesan los datos, qué dice el contrato sobre uso para entrenamiento, qué coste por millón de tokens y qué modelos ofrece. Instalar los tres conectores «por probar» significa tres superficies de credenciales que mantener.

4. Restringir capacidades desde el primer día. El filtro wp_ai_client_prevent_prompt y endpoints REST específicos por funcionalidad, en lugar de exponer la API genérica. Un editor no necesita poder lanzar cualquier prompt: necesita poder generar el extracto de su propio post.

5. Registrar y revisar. Guardar qué funcionalidad se usó, por quién, con qué proveedor y cuántos tokens consumió. Sin esto no hay forma de contestar a la pregunta que acaba llegando siempre: «¿por qué nos ha subido la factura?».

Costes y gobierno: quién paga los tokens

Hay una consecuencia económica que no estaba en el modelo mental de WordPress hasta ahora. Un plugin clásico se instala y funciona; un plugin que llama a un modelo tiene coste marginal por uso. Si la generación de descripciones de producto está disponible para cinco personas del equipo de catálogo y cada una la usa cien veces al día, eso es una partida nueva en el presupuesto mensual.

Tres medidas sencillas evitan sorpresas. La primera es poner límites de gasto en el panel del proveedor, no solo en WordPress: es la única barrera que no depende de que el código haga bien su trabajo. La segunda es cachear resultados cuando la entrada es la misma: regenerar diez veces el mismo extracto porque alguien guarda el post diez veces es puro desperdicio. La tercera es elegir el modelo por tarea: un alt text no necesita el modelo más capaz del catálogo, y la diferencia de precio entre el modelo grande y el pequeño para esa tarea concreta es de un orden de magnitud.

En cuanto al gobierno, el patrón que mejor funciona es el mismo que para cualquier otra integración sensible: una persona responsable de las credenciales, una política escrita de qué datos pueden salir del sitio y una revisión periódica de qué funcionalidades siguen en uso. Si la empresa va camino de una certificación ISO 27001, estas tres cosas van a ser requisito documentado, así que mejor hacerlas desde el principio que reconstruirlas en la fase de auditoría.

Y una recomendación transversal: antes de automatizar un proceso con IA, escribe qué debe hacer exactamente. Es la diferencia entre una funcionalidad útil y una demo. El método que usamos para eso está en nuestra guía de cómo definir requerimientos de software con IA, y aplica igual a un flujo interno que a un desarrollo para cliente. Para los flujos que viven fuera de WordPress, un orquestador como n8n sigue siendo la pieza que cose todo lo demás.

Qué implica esto para tu negocio

La integración de IA en el core de WordPress no es un experimento: es una declaración de intención sobre el futuro del CMS. Para empresas que usan WordPress como base de su plataforma digital, las implicaciones son claras: generación automatizada de contenido y metadatos, optimización de imágenes con alt text automático, flujos de trabajo inteligentes que van más allá de la publicación manual, y una infraestructura preparada para integrar agentes de IA en los procesos internos.

En Keliam ayudamos a empresas y startups a aprovechar estas nuevas capacidades. Ya sea para integrar IA en tu e-commerce, automatizar procesos en tu plataforma o simplemente actualizar tu WordPress de forma segura, nuestro equipo está preparado.

Preguntas frecuentes

¿WordPress envía datos a proveedores de IA si no configuro nada?

No. El core no incluye ningún proveedor y no hace llamadas a modelos por su cuenta. Hace falta instalar un plugin de proveedor, configurar sus credenciales en Settings > Connectors y que algún código llame explícitamente al AI Client.

¿Puedo cambiar de proveedor sin tocar mi plugin?

Sí, y es el punto principal del diseño. Tu plugin llama a wp_ai_client_prompt() y declara qué capacidad necesita; quién la atiende lo decide la configuración del sitio. Cambiar de proveedor es cambiar de conector, no reescribir la integración.

¿Qué versión de PHP necesito?

El mínimo de WordPress 7.0 y 7.1 es PHP 7.4, pero la recomendación oficial es PHP 8.3 o superior. Para cualquier proyecto en producción con IA, 8.3 es el punto de partida razonable.

¿Ya existe la edición colaborativa en tiempo real?

No. Se desarrolló para la 7.0 y se retiró antes de la publicación por rendimiento y carga de servidor, y no entró en la 7.1. El plan es distribuirla primero como feature plugin, sin fecha anunciada.

¿Merece la pena actualizar ya o esperar a la 7.2?

Si estás en una versión que ya no recibe soporte activo, no hay debate: actualizar es la opción segura. Si estás en la 7.1.2, lo sensato es preparar el entorno para la 7.2 (prevista para el 10 de diciembre de 2026) y probarla en staging con la lista de plugins críticos antes de subirla a producción.

🚀 ¿Quieres integrar IA en tu proyecto WordPress?

En Keliam combinamos experiencia en desarrollo WordPress con conocimiento en inteligencia artificial. Te ayudamos a aprovechar el nuevo AI Client, automatizar procesos y mantener tu plataforma al día.

Solicita tu consulta gratuita →

Scroll al inicio