El 18 de agosto salió WordPress AI 1.3.0, un día antes de WordPress 7.1, y casi nadie lo celebró con fuegos artificiales. En mi feed apareció enterrado entre el editor iframado y las fotos del WordCamp. Eso no es casualidad: el plugin lleva un tono deliberadamente aburrido, como si quisieran que lo instalaras sin pensar demasiado. Traducción de contenidos en el editor, generación de slugs, conectores actualizados… Suena a mejoras menores. Hasta que llegas al experimento Custom Abilities y entiendes por qué lo han empaquetado así.
La idea oficial es razonable. Hasta ahora, cinco habilidades concretas —ai/get-post-details, ai/get-post-terms, core/read-settings, core/read-users y core/read-content— dejan de registrarse solas. Tienes que activarlas en Ajustes > AI > Experiments. Apagadas por defecto. Nombradas. Auditables. Perfecto para una presentación de seguridad. El problema es que ese interruptor no cierra una puerta: la abre.
Porque lo que viene en la hoja de ruta no es leer posts: es escribir, borrar y gestionar tu sitio desde fuera. En las notas del equipo AI de WordPress ya se habla de un conjunto CRUD —core/content-query, core/content-create, core/content-update, core/content-delete— apuntando a WordPress 7.2 en diciembre. Hoy te piden permiso para leer usuarios y ajustes; mañana el agente que conectes con Cursor, Claude Code o el conector que moda lleve esta semana tendrá manos. Y la pregunta incómoda es quién las controla cuando el toggle está en ON y el registro de auditoría lo miras una vez al trimestre.
Lo irónico es que las funciones que sí verás en el día a día —traducir párrafos sin salir del editor, proponer slugs— son las que te hacen confiar en el plugin. Son útiles. De verdad. Si mantienes un blog bilingüe o gestionas varios sitios de clientes, ahorran tiempo. Pero funcionan igual con Custom Abilities desactivado. No necesitas darle a la IA una radiografía de tu instalación para que te proponga un slug decente. El empaquetado me recuerda a cuando un hosting te regala SSL gratis y en la letra pequeña mete renovaciones automáticas de servicios que no pediste: el regalo real no es el certificado, es la relación comercial.
Y aquí entra WordPress 7.1, que amplió la Abilities API para que cualquier agente descubra qué puede hacer tu sitio de forma legible por máquina. Suena progresista. Suena inevitable. También suena a que estamos normalizando que un CMS exponga capacidades administrativas como endpoints para terceros. En hosting compartido, donde el mismo cliente que no actualiza Contact Form 7 en seis meses es quien instalará el plugin AI porque «viene recomendado», me parece una bomba de relojería mal etiquetada.
No digo que el equipo de WordPress no piense en seguridad. El propio release 1.3.0 menciona hardening y accesibilidad. Pero la narrativa pública es «tú decides» cuando la arquitectura empuja hacia más integración, no menos. Los conectores de Anthropic, Google, Ollama y OpenAI se actualizaron la misma semana. La presión del mercado es clara: si tu CMS no habla con agentes, pierdes relevancia frente a Shopify, que lleva meses vendiendo escaparates agénticos con un toggle. WordPress responde con prudencia de laboratorio y ambición de producción. Las dos cosas a la vez no encajan del todo.
En mi experiencia con clientes pymes, el riesgo no es que alguien hackee la API de OpenAI. Es que alguien active experimentos en producción para probar una traducción, deje el sitio así tres meses y conecte un asistente externo sin revisar scopes. core/read-users no es un detalle técnico: es la lista de cuentas, roles, correos. core/read-settings puede incluir pistas sobre plugins, URLs, configuraciones que no querrías en un prompt que acaba en un log de terceros. Y cuando llegue el CRUD completo, el daño potencial deja de ser filtración para convertirse en manipulación.
Tampoco veo alternativa fácil si quieres seguir en el ecosistema WordPress. Ignorar el plugin no te immuniza: la Abilities API ya vive en core. Lo sensato es tratar Custom Abilities como un permiso de administrador, no como un experimento divertido. Documentar quién lo activó, revisar qué conectores tienen acceso, separar entornos de staging donde sí puedes jugar. Y ser escéptico con la promesa de que «está apagado por defecto» cuando el producto entero está diseñado para que lo enciendas poco a poco.
El plugin ronda 40.000 instalaciones activas. No es masivo todavía, pero tampoco es un experimento de laboratorio. Cada instalación es un sitio que puede convertirse en nodo de una red de agentes sin que el propietario lo haya interiorizado. Me gustaría ver más transparencia sobre qué registra exactamente la auditoría, quién puede ver esos logs en un multisite y qué pasa cuando un conector heredado asume que las abilities siguen registradas automáticamente —porque el release avisa de que integraciones antiguas deben reactivar el toggle manualmente. Eso huele a sitios rotos o, peor, a sitios « arreglados» activando todo sin leer.
WordPress AI 1.3.0 no es el villano de la película. Es el primer capítulo escrito con calma, en voz baja, mientras en el índice ya figura el final con agentes editando contenido por ti. Si gestionas webs de terceros, el interruptor de Custom Abilities no es una preferencia estética: es una línea de responsabilidad civil esperando a cruzarse con un prompt mal escrito.
Si mañana un cliente te pide activar Custom Abilities para probar traducciones automáticas, pero se niega a pagar una revisión de seguridad de los conectores IA que ya tiene instalados, le darías tú mismo al interruptor o le dirías que primero auditen quién puede leer usuarios y ajustes del sitio?