WordPress como sistema operativo de la web agéntica. ¿Quién paga los tokens?
Automattic anunció el 21 de abril de 2026 en el artículo WordPress as the Operating System of the Agentic Web que WordPress es el sistema operativo de la web agéntica. El texto de James Grierson, responsable de expansión global de la empresa, enumera 8 puntos fuertes y 6 puntos débiles de este papel. Falta una pregunta. Quién cubre el coste de los tokens de IA en el lado del usuario final. Esta brecha decide quién recibirá la primera factura inesperada cuando se publique WordPress 7.0.
«WordPress’s foundational principles position it uniquely to become the operating system of the agentic web.»
James Grierson, Automattic, 21 de abril de 2026
Llamar al 43 por ciento de la web «operating system» del futuro agéntico es una afirmación rotunda. Omitir quién paga el uso de IA que circula por ese sistema es una omisión igual de rotunda.
Lo que Automattic anunció realmente el 21 de abril de 2026
Automattic posiciona a WordPress como base de la web agéntica por tres razones. Código abierto, un ecosistema de 61 000 plugins gratuitos y APIs estandarizadas. James Grierson cita las propias estadísticas de Automattic, en concreto una cuota del 43 por ciento de todos los sitios web y más del 60 por ciento del mercado de CMS. La cifra de 90 000 plugins incluye los marketplaces comerciales.
Lista completa de pros y contras del artículo
Automattic enumera 8 fortalezas de WordPress como plataforma para agentes de IA. Un ecosistema masivo y probado. Transparencia del código abierto. Código revisado por pares y estándares comunitarios. Seguridad basada en transparencia. REST API y conectividad MCP. Extensibilidad comercial vía WooCommerce. Arquitectura de hooks y filtros. Décadas de documentación.
La lista de 6 debilidades es igual de concreta. Código heredado y deuda técnica. Calidad inconsistente de los plugins. Plugins abandonados e inseguros. Sobrecarga de rendimiento. Complejidad del sistema de hooks para agentes. Percepción de PHP y reducción del cauce de nuevos desarrolladores. Fragmentación entre entornos de hosting.
Lo que falta en el artículo
En el artículo de Grierson la palabra token no aparece ni una sola vez. No hay sección sobre la propiedad de la clave API. No hay modelo de facturación. No hay escenario en el que un agente agote la cuota planificada a mitad de semana. La omisión deriva de la perspectiva del autor. El artículo procede de una empresa que vende hosting y módulos de IA en paquete. Un operador autoalojado tiene otras prioridades.
Una segunda omisión afecta al registro de las acciones que ejecuta el agente. Cada escritura por MCP modifica el estado de la base de datos y exige una entrada de auditoría aparte, algo que el artículo no aborda. Una tercera omisión es la política de privacidad, que decide qué datos de un artículo o comentario salen del servidor y llegan al proveedor de IA. Estas tres omisiones separan una visión de un producto listo para desplegar.
Model Context Protocol y Abilities API en la práctica
Model Context Protocol es un estándar que permite a los agentes de IA conectarse con sistemas externos. Automattic desplegó MCP en WordPress.com en dos fases. Lectura primero, escritura después. WordPress autoalojado alcanza la misma capacidad mediante la Abilities API y WordPress MCP Adapter.
Solo lectura en octubre de 2025, escritura en marzo de 2026
WordPress.com habilitó MCP en modo de solo lectura en octubre de 2025. El soporte completo para operaciones de escritura entró en producción en marzo de 2026. Desde ese momento un agente puede crear un artículo, publicarlo, añadir un comentario y gestionar medios mediante lenguaje natural. Cada operación genera un coste en el lado del modelo que la ejecuta.
La consecuencia práctica es simple. Activar un único plugin que dialoga con un agente convierte cada edición de artículo en una solicitud al proveedor externo de IA. La factura llega allí donde resida la clave API.
Qué cambia la Abilities API en la versión autoalojada
La Abilities API combinada con WordPress MCP Adapter permite a los autores de plugins exponer funcionalidades existentes como herramientas para agentes. El adaptador tiende un puente entre las capacidades del plugin y la especificación MCP. El autor de un plugin existente añade unas pocas líneas de configuración. El agente accede a esa funcionalidad.
Este atajo reduce la barrera de entrada, por lo que el número de plugins con funcionalidades de IA en el repositorio WordPress.org crece más rápido que el número de auditorías de seguridad de esos plugins. WPPoland observa este patrón desde marzo de 2026 entre los clientes inscritos en el programa mantenimiento WordPress.
El papel de WordPress Playground para los agentes
WordPress Playground arranca una instancia completa de WordPress en el navegador en segundos. Automattic posiciona esta herramienta como entorno aislado para agentes. El agente prueba un cambio en Playground, y solo la acción confirmada llega a producción. La construcción reduce el riesgo de daños en los datos por alucinaciones del modelo. No cambia quién paga los tokens consumidos.
La brecha en la visión, es decir, quién paga los tokens
Russell Heimlich, desarrollador WordPress con 20 años en el ecosistema, planteó esta cuestión públicamente en WordPress AI Features Are Coming. Nobody Is Talking About What They’ll Cost Your Users, publicado el 24 de abril de 2026. Heimlich, conocido en la comunidad por el alias russellenvy, señala que Automattic no menciona en ningún momento los costes de IA en su visión agéntica. El argumento es práctico. Cuando un plugin se instala solo, pide al usuario conectar una cuenta en un proveedor de IA y abre después un campo de chat en el panel, el usuario no sabe que cada mensaje cuesta dinero.
El argumento de Russell Heimlich
Heimlich describe su propio caso de trabajo con modelos de IA. Utiliza una suscripción mensual con el proveedor del modelo Claude y agota el límite semanal a pesar de optimizaciones avanzadas de prompt y flujo de trabajo. De ello extrae una conclusión concreta. Una persona sin experiencia con modelos de lenguaje, por ejemplo un blogger gastronómico que acaba de levantar un sitio e instalar un plugin popular con IA, agotará la cuota más rápido y sin un mensaje de error claro sobre la causa.
«Every interaction between an AI agent and a WordPress site costs tokens.»
«Every single one of those exchanges burns tokens. Real money. Her money. And she has no idea.»
Russell Heimlich, russellenvy.com, 24 de abril de 2026
Un segundo argumento de Heimlich se refiere a la responsabilidad sobre la experiencia del usuario. Un plugin que introduce una funcionalidad de IA sin un mensaje legible sobre costes traslada la carga de educar al usuario al operador del sitio y, de manera indirecta, a la agencia. Un tercer argumento aborda la reputación de la marca WordPress. La primera oleada de descontento tras facturas inesperadas repercute en todo el ecosistema, con independencia de que el origen del problema sea un único plugin.
Tres modelos de propiedad de la clave API y sus consecuencias
En la práctica predominan 3 modelos para facturar tokens de IA en plugins WordPress.
Bring-your-own-key. El cliente crea una cuenta en el proveedor de IA, genera una clave y la pega en el panel del plugin. Los costes van directamente al cliente. El autor del plugin no actúa como intermediario. El modelo es contablemente transparente y exige que el cliente entienda cómo funciona la cuota de tokens del proveedor.
Suscripción gestionada por el autor del plugin. El plugin cobra al cliente una cuota mensual fija y liquida directamente con el proveedor de IA. El riesgo de uso indebido recae sobre el autor del plugin, que equilibra la tarifa con el consumo real. El modelo es cómodo para el usuario final y arriesgado para el operador del plugin.
Cuota compartida con límite mensual. Todos los clientes del plugin comparten una sola cuota. Tras agotarse, la cuota se renueva al mes siguiente o se amplía en un paquete superior. El modelo simplifica el mensaje al usuario e introduce un nuevo efecto, a saber, el vecino que consume mis tokens.
El escenario del blogger gastronómico de TikTok
Heimlich describió este escenario en primer lugar. Un blogger viral monta un sitio WordPress, instala un plugin con IA, recorre el asistente. El asistente pide conectar una cuenta de Claude, ChatGPT o Gemini. El blogger conecta la cuenta porque la instrucción lo indica. A continuación trata el campo de IA como un chat común. Dos días después la cuota semanal desaparece. El plugin muestra un loader vacío sin mensaje. El blogger culpa a WordPress. Cada parte de esta historia se repite hoy en clientes reales.
Qué significa para los propietarios de sitios WordPress antes del lanzamiento de 7.0
El lanzamiento de WordPress 7.0 se acerca con rapidez. La versión Release Candidate 2 se publicó el 26 de marzo de 2026 en wordpress.org. La fecha de disponibilidad general no está oficialmente confirmada en las comunicaciones del proyecto. Independientemente de la fecha exacta, la infraestructura MCP en el lado autoalojado madura en paralelo. Un operador debe ejecutar 3 movimientos antes de la primera oleada de actualizaciones de plugins con IA dentro.
Auditoría de los plugins instalados respecto a IA
Revisa cada plugin instalado contra 3 informaciones. Si la hoja de ruta del producto incluye un componente de IA en la próxima versión. Si el autor del plugin ha publicado un modelo de facturación de tokens. Si existe la opción de desactivar las funcionalidades de IA sin perder el resto de las capacidades del plugin. Los plugins sin estas respuestas exigen monitorizar el changelog entre actualizaciones.
En la práctica 3 categorías de plugins introducen funcionalidades de IA con mayor rapidez. Plugins de SEO, como Yoast SEO y Rank Math, donde el generador de meta descripciones recurre a un modelo de lenguaje. Plugins de calendarios y eventos, como The Events Calendar, donde un agente genera descripciones de series recurrentes de eventos. Plugins de comercio y CRM, donde un asistente de IA propone descripciones de productos y respuestas a consultas de clientes. Cada una de estas 3 categorías tiene un perfil distinto de consumo de tokens, porque la longitud de un único prompt difiere.
Una auditoría completa se combina sin fricciones con una auditoría de seguridad WordPress cada seis meses. WPPoland realiza la auditoría como parte del programa de mantenimiento y, desde marzo de 2026, añade un mapa de funcionalidades de IA en los plugins instalados.
Preguntas a los proveedores de plugins
Tres preguntas al autor del plugin antes de activar el modo IA suenan concretas. Primera, dónde reside la clave API y quién la paga. Segunda, qué mensaje recibe el usuario cuando se agota la cuota de tokens. Tercera, si cada acción que ejecuta el agente queda registrada de forma que pueda reconstruirse el historial. Los autores de plugins serios responden en un día. La ausencia de respuesta es por sí misma una respuesta.
Configurar el comportamiento por defecto cuando faltan tokens
Configura el plugin para que la falta de tokens degrade la funcionalidad en lugar de bloquear el panel. Tres ajustes resuelven el 80 por ciento de los problemas. Un mensaje textual sobre la causa del error en lugar de un loader vacío. Una copia local de la última respuesta exitosa visible como placeholder. La posibilidad de desactivar el módulo de IA desde un perfil de editor sin tocar código.
Qué deben hacer los autores de plugins
Los autores de plugins cargan con mayor responsabilidad que los operadores de sitios porque modelan la primera experiencia del usuario final con un agente de IA. Tres principios de diseño reducen el número de clientes sorprendidos tras la primera factura.
Mensaje de coste antes de la primera petición
La primera petición a un agente la antecede siempre un mensaje. El plugin muestra qué acción se va a ejecutar, cuántos tokens se consumirán de manera aproximada y qué cuenta de IA se cargará. El mensaje aparece una vez y su ausencia cuesta la confianza del usuario en la primera sorpresa. El patrón está consagrado en herramientas populares para desarrolladores, como GitHub Copilot o Cursor.
Modo de degradación en lugar del loader vacío
El modo de degradación gestiona 4 estados de la cuota de tokens. Acceso completo. Aviso de saldo bajo. Modo de solo lectura, donde el agente lee datos pero no genera contenido. Modo desactivado. Cada estado tiene su propio mensaje al usuario. Un loader vacío no es un estado aceptable porque un usuario sin contexto lo interpreta como caída general de la plataforma.
Bring-your-own-key vs. suscripción vs. cuota compartida
La elección del modelo de facturación afecta a 3 áreas a la vez, a saber, el mensaje de instalación, el panel de configuración y el procedimiento de respuesta a incidentes. Bring-your-own-key requiere un onboarding cuidadoso del cliente. La suscripción exige negociar volumen con el proveedor de IA por parte del autor del plugin. La cuota compartida exige supervisar usos indebidos. El autor del plugin documenta la elección del modelo en la documentación de usuario, no solo en la política de privacidad.
Cómo debe preparar la agencia a sus clientes
Una agencia que mantiene varios sitios de clientes tiene 3 puntos que alinear con cada cliente antes del lanzamiento de WordPress 7.0. Una cláusula contractual sobre servicios de IA. Un régimen de actualizaciones de plugins. La comunicación de un incidente tras superar un límite de tokens.
Cláusula contractual sobre servicios externos de IA
La cláusula consta de 4 frases. El cliente cubre los costes de tokens en proveedores externos de IA de manera directa. La agencia informa al cliente de cada nueva funcionalidad de IA en plugins mantenidos antes de la activación. El cliente autoriza la activación por escrito. La agencia monitoriza el consumo y reporta anomalías en un plazo de 48 horas. El patrón nace de la experiencia consolidada de WPPoland con clientes empresariales, donde los costes externos inesperados deterioran la relación con mayor rapidez.
La cláusula describe además un procedimiento de emergencia en 2 pasos. Primero, pausa automática de las peticiones del agente tras superar un umbral acordado con el cliente. Segundo, contacto de la agencia con el cliente en modo de trabajo, esto es, correo electrónico y teléfono dentro del horario laboral del cliente. Un umbral indefinido significa, en la práctica, que la primera información sobre el exceso llega al cliente en la factura del proveedor de IA, lo cual es la causa más frecuente de pérdida de confianza en el primer trimestre de colaboración.
Régimen de actualizaciones, es decir, manual, automático o tras revisión
El cliente elige 1 de 3 regímenes de actualización de plugins. Actualizaciones manuales en las que la agencia despliega una nueva versión tras pruebas. Actualizaciones automáticas con un informe diario de cambios. Actualizaciones tras revisión, en las que la agencia bloquea la introducción de funcionalidades nuevas hasta la aprobación del cliente. El régimen tras revisión protege mejor al cliente durante el periodo de introducción de funcionalidades de IA en los plugins.
Qué incluir en el briefing para un proyecto nuevo
El briefing de un proyecto nuevo contempla 4 preguntas adicionales respecto a un briefing de 2024. Primera, si el cliente acepta la presencia de funcionalidades de IA en el panel editorial. Segunda, quién será propietario de las claves API en proveedores de IA. Tercera, qué presupuesto mensual destina el cliente a tokens. Cuarta, qué escenarios de usuario no deben generar peticiones al agente. Estas 4 preguntas responden a los huecos que Automattic no cerró en su visión.
Tras estas decisiones un proyecto puede usar con seguridad la infraestructura MCP, la Abilities API y el ecosistema de plugins. El operador conoce los costes. El autor del plugin conoce las limitaciones. El agente de IA tiene fronteras claramente definidas. El resto de fortalezas de WordPress, como el código abierto y la documentación amplia, funcionan sin cambios.
WPPoland mantiene esta conversación con cada cliente desde marzo de 2026. El mapa completo de prácticas se describe en detalle en cómo hacer visible tu sitio para la IA y los LLMs y en resumen estratégico LLMO. La visibilidad para agentes es un tema aparte, pero el fundamento es el mismo, a saber, comprender dónde empieza y dónde termina la responsabilidad sobre el coste de una consulta.
Preguntas frecuentes
¿Cada nuevo plugin de WordPress incluirá funcionalidades de IA tras el lanzamiento de 7.0?
No. Una funcionalidad de IA en un plugin requiere una decisión de su autor, integración con un proveedor y una documentación separada de facturación. El lanzamiento de WordPress 7.0 simplifica esa integración mediante la Abilities API y no obliga a nadie a añadir IA. El ciclo de lanzamiento de cada plugin decide.
¿Cómo reconocer que un plugin acaba de consumir mis tokens?
Revisa el panel de facturación del proveedor de IA al que el plugin está conectado. Anthropic, OpenAI y Google AI exponen historial de consumo por clave API. Un plugin que cumpla los estándares de registro emite su propio informe de consumo en el panel. La ausencia de tal informe es una señal de alerta.
¿Una clave API propia es más segura que una suscripción dentro del plugin?
La seguridad depende de dos factores, a saber, la higiene de almacenamiento de la clave y el procedimiento de respuesta a un uso indebido. Bring-your-own-key da al cliente control total sobre la rotación de la clave y visibilidad del consumo. El modelo de suscripción libera al cliente de esa obligación y exige confianza en el autor del plugin. La elección depende de la competencia técnica del equipo del cliente.
¿Qué hacer cuando el plugin muestra un loader vacío sin mensaje de error?
Revierte el último cambio en el panel, revisa la consola del navegador en las herramientas para desarrolladores y consulta el log de errores PHP del servidor. Un loader vacío suele significar que la cuota de tokens está agotada o que la autorización de la clave ha fallado. A continuación contacta con el autor del plugin, ya que la falta de mensaje de error es un fallo del producto, no de la configuración.
¿WordPress 7.0 ya tiene una fecha oficial de lanzamiento?
La versión Release Candidate 2 se publicó el 26 de marzo de 2026 en wordpress.org. La fecha de disponibilidad general no está confirmada oficialmente en las comunicaciones del proyecto en el momento de redactar este texto. La fuente fiable es la página wordpress.org/news, donde aparece cada candidata sucesiva y la versión final.
