El 26 de junio, el WordPress AI Team presentó en Slack el repositorio php-ai-client: un SDK agnóstico de proveedor para conectar PHP con modelos de lenguaje, más una capa específica de WordPress con endpoints REST y gestión de claves API. Suena sensato. Suena ordenado. Suena exactamente lo contrario de lo que llevo viendo en proyectos reales desde que SiteGround, Pressable y medio ecosistema empezaron a enchufar IA por su cuenta.
Yo no cuestiono que haga falta una capa común. Cuestiono el timing y quién va a pagar la factura de la fragmentación que ya existe.
En la misma conversación del equipo —documentada en el resumen del chat del 26 de junio— Felix Arntz explicó que el SDK será extensible y neutral respecto al vendor. Bien. Pero en el mismo hilo hablaron de si incluir los tres grandes proveedores (OpenAI, Anthropic, Google) en ramas separadas, de proxies de hosting que empaquetan créditos de IA, de amazee.ai colaborando con agencias, y de que la adopción por parte de los hostings es «clave» para el éxito del proyecto. Léelo con calma: no están diseñando una herramienta para el desarrollador independiente; están diseñando infraestructura para que tu proveedor de hosting te venda IA como add-on.
Plugin-first otra vez, problema de siempre
Desde principios de junio, el roadmap oficial del equipo deja claro que no habrá integración inmediata en Core. Todo irá como Canonical Plugin o Feature Plugin: AI Services, MCP Adapter, Abilities API, un showcase para demostrarlo. Es el mismo playbook que usó Performance Lab, y funcionó para métricas web. Pero la IA no es Web Vitals. Cada plugin que toca contenido, permisos y llamadas externas es un vector de fuga de datos, de costes impredecibles y de dependencia de un tercero que puede cambiar precios mañana.
En el post del 5 de junio, James LePage y el resto del equipo venden la idea con elegancia: evitar fragmentación, coordinar innovación, iterar rápido. Me parece sincero. Lo que no me cuadra es que, mientras ellos debaten monorepo versus repos separados en GitHub, tu cliente ya tiene tres plugins distintos que «escriben con IA», cada uno con su propia clave API, su propio panel de facturación y cero interoperabilidad. El SDK llegará cuando esa maraña ya esté instalada en producción.
El Developer Blog de WordPress lo resume con optimismo: no hay planes de meter LLMs en Core; habrá plugins canónicos que abstraen APIs. Traducción para quien mantiene webs: vas a seguir actualizando plugins, pero ahora con la etiqueta «oficial». No es poco. Tampoco arregla el desorden actual.
Los proxies de hosting: comodidad con letra pequeña
Lo más revelador del chat del 26 de junio no es el código; es la conversación sobre proxy providers. Jason Adams detalló el caso de uso: el hosting empaqueta créditos de IA, monitoriza el uso y enruta las peticiones. Isotropic y Arntz hablaron de registrar proveedores en el host versus proxy puro. Dan from amazee.ai confirmó intención de ser proveedor y colaborar con agencias WordPress.
¿Te suena? Es el mismo guion de SiteGround AI Connector activado por defecto, de Pressable MCP gestionando tu servidor desde el chat, de todo lo que ya hemos comentado aquí. El WordPress AI Team no está inventando un modelo nuevo: está estandarizando el que los hostings ya están imponiendo. La diferencia es que ahora tendrás una API bonita detrás del mismo candado.
Arntz mencionó el proceso de OEmbed como precedente para decidir qué proveedores entran. En teoría, transparencia. En la práctica, OEmbed tardó años en ser medianamente usable y sigue generando quejas de privacidad. ¿Vamos a repetir eso con modelos que procesan datos de clientes, facturas, formularios de contacto y borradores de posts?
Lo que falta en el discurso
En ningún sitio del roadmap oficial he visto números sobre coste para una pyme española que publica 20 entradas al mes. No hay guía clara sobre retención de datos cuando enrutas un prompt por el proxy de tu hosting. No hay posición explícita sobre el AI Act europeo —que entra en vigor el 2 de agosto para obligaciones de transparencia en sistemas de IA de propósito general— aplicada a plugins canónicos que llaman a OpenAI desde un servidor en EE.UU.
Sí hay entusiasmo por REST API specs en el repo del SDK, paridad con GraphQL, agentes MCP. Todo muy 2026. Pero si gestionas webs de clínicas, despachos o tiendas WooCommerce, lo que necesitas no es otro endpoint: necesitas saber si el texto que genera el plugin puede usarse comercialmente, dónde se almacena el prompt y quién responde si mañana Anthropic cambia sus términos.
El equipo admite que no habrá merge a Core a corto plazo. Bien, al menos son honestos. Malo para quien esperaba que WordPress marcara un mínimo de gobernanza antes de que la mitad del directorio de plugins fuera «AI-powered».
¿Entonces qué haces tú ahora?
No te digo que ignores el php-ai-client. Cuando salga estable, probablemente sea la forma menos dolorosa de integrar IA en un plugin propio. Pero tampoco apagues los plugins que ya tienes esperando al salvador canónico: el desorden ya está en tu wp-admin.
Lo que haría yo hoy: inventario de qué plugin llama a qué API, con qué clave y qué datos envía. Política interna de no pegar datos personales en prompts hasta tener DPA firmado con el proveedor —da igual si pasa por OpenAI directo o por el proxy de tu hosting. Y mucho cuidado con activar conectores IA «gratis» incluidos en el plan de hosting: el SDK oficial está diseñado precisamente para facilitar ese modelo de negocio.
El WordPress AI Team está construyendo cimientos serios. El problema es que la casa ya tiene muebles metidos en medio del solar, y nadie ha dicho quién los saca.
Si mañana tu hosting te ofreciera migrar todos tus plugins de IA al conector oficial php-ai-client a cambio de centralizar facturación y logs en su panel —sin garantías escritas sobre retención de datos en la UE—, ¿firmarías el trato o preferirías seguir con tres plugins caóticos pero bajo tu propia clave API?