Conectores de IA en WordPress 7: cómo configurarlos y controlar el coste

La primera pregunta que nos llega de un cliente cuando actualiza a WordPress 7.0 «Armstrong» es casi siempre la misma: «¿dónde está el botón de la IA?». La expectativa, alimentada por meses de titulares, es que al entrar en el editor aparecerá algo parecido a un asistente que redacta el post, ilustra la ficha de producto y reescribe el meta description mientras el equipo de marketing se toma un café. Esa expectativa se rompe en los primeros treinta segundos de uso, y conviene romperla antes: WordPress 7 no trae un generador de contenido. Trae fontanería.

Lo que llega en la versión publicada el 20 de mayo de 2026 es infraestructura: un panel centralizado de credenciales para conectores de IA en Ajustes > Conectores, la Abilities API y un adaptador MCP. Traducido a lenguaje de quien administra el sitio: WordPress ahora sabe hablar con proveedores de modelos de lenguaje de forma estandarizada, y sabe exponer capacidades propias para que un agente externo las invoque. Ni una cosa ni la otra escribe nada por sí sola. Son cañerías por las que otros harán pasar agua, y la factura del agua la pagas tú, porque el modelo es que consumes tu propia clave API y la abonas por uso al proveedor.

Ese matiz cambia por completo la conversación. Deja de ser una novedad de producto y pasa a ser una decisión de arquitectura, de presupuesto y de gobierno de accesos: quién puede invocar un modelo desde tu backend, qué contenido sale de tu servidor, quién paga el consumo y qué pasa el día que una integración mal configurada dispara el gasto o filtra un borrador confidencial. Este artículo va de eso. Si buscas el detalle de la capa de código y del SDK, lo tienes desarrollado en nuestro análisis de cómo funciona el WP AI Client y la IA nativa de WordPress 7.0; y si lo que necesitas es el plan completo de actualización, empieza por la guía para actualizar a WordPress 7 en una empresa. Aquí nos quedamos en el panel de administración.

1. Qué es realmente la infraestructura de IA de WordPress 7 (y qué no es)

Empecemos por lo que no es, porque ahorra discusiones. WordPress 7.0 no incluye ningún modelo de lenguaje. No hospeda inferencia, no tiene una cuota gratuita, no viene con créditos de bienvenida y no sustituye a los plugins comerciales de generación de contenido que quizá ya estés pagando. Tampoco hay una interfaz en el editor que diga «generar artículo». Quien te venda lo contrario está describiendo un plugin de terceros, no el core.

Lo que sí hay son tres piezas que encajan entre sí. La primera es el panel de conectores de IA: un lugar único en el administrador donde se guardan las credenciales de los proveedores de IA que decidas usar. La segunda es la Abilities API, un registro estandarizado en el que el core, los plugins y los temas declaran capacidades invocables —»crear un borrador», «leer los pedidos de esta semana», «actualizar el texto alternativo de una imagen»— con su descripción, sus parámetros y, crucialmente, el permiso que exige cada una. La tercera es el adaptador MCP, que expone ese registro de capacidades a agentes externos mediante un protocolo común.

Puestas en fila, la lectura es clara: WordPress se está preparando para ser tanto cliente de la IA (el sitio pide cosas a un modelo) como servidor de la IA (un modelo pide cosas al sitio). La segunda dirección es la que debería quitarte el sueño, y volveremos sobre ella. La primera es la que dominará el uso real durante los próximos meses.

Por qué el core se ha metido en esto

Hasta ahora, cada plugin que quería usar IA implementaba su propio cliente HTTP, su propio almacenamiento de la clave, su propio manejo de errores y su propia lógica de reintentos. Si tenías tres plugins con funciones de IA, tenías tres claves distintas guardadas en tres sitios distintos, con tres niveles de calidad de código distintos. Ninguno te decía cuánto estabas gastando ni desde qué punto del sitio se invocaba el modelo.

El core no resuelve el problema de la IA. Resuelve el problema de la fragmentación, que es exactamente el tipo de cosa que un gestor de contenidos debe estandarizar. Es el mismo movimiento que en su día llevó a unificar el envío de correo, las peticiones HTTP o la gestión de cron: no aporta funcionalidad de usuario final, aporta un punto único donde auditar, limitar y depurar.

2. Ajustes > Conectores: el panel de conectores de IA frente al caos anterior

El panel de conectores de IA es, en apariencia, poca cosa: una pantalla donde eliges proveedor, pegas una clave y guardas. Su valor está en lo que elimina, no en lo que añade.

Antes de WordPress 7, la clave de OpenAI de un cliente típico vivía repartida en el campo de opciones de un plugin de SEO, en el de un plugin de generación de imágenes y quizá en una constante del wp-config.php que alguien puso hace un año y nadie recuerda. Cada uno la guardaba a su manera: unos cifrada, otros en texto plano en wp_options, alguno con autoload activado para que se cargara en cada petición. Rotar esa clave tras una salida del equipo significaba buscar en el pajar. Revocarla de golpe rompía funciones que nadie había documentado.

Con el panel centralizado, la credencial se registra una vez y los consumidores la piden al core. El día que quieras rotarla, la cambias en un sitio. El día que un desarrollador externo entre a trabajar, sabes exactamente qué está expuesto. Y cuando algo falle, tienes un único punto donde mirar en lugar de tres implementaciones ajenas.

Esto no es magia y conviene decirlo: los plugins deben adaptarse para consumir el conector del core en lugar de su propio campo. Durante bastante tiempo convivirán ambos modelos, y lo normal es que en un sitio real encuentres el conector configurado y, a la vez, un plugin viejo que sigue guardando su clave por su cuenta. Parte del trabajo de mantenimiento en los próximos meses será precisamente ese inventario: localizar todas las claves dispersas, migrar lo que se pueda al panel y revocar el resto.

Qué comprobar antes de introducir la primera clave

Nuestra recomendación operativa es no tocar el panel de conectores hasta tener resueltas tres cosas. Una, que el sitio está en HTTPS de extremo a extremo, incluido el administrador, porque vas a pegar un secreto en un formulario. Dos, que el acceso al backend está protegido con doble factor para los perfiles con capacidad de administración, porque quien entre en tu escritorio entra en tu presupuesto de IA. Y tres, que sabes qué rol tendrá permiso para usar los conectores, decisión que abordamos más adelante y que no debería tomarse improvisando.

3. Configurar un proveedor paso a paso

WordPress 7 contempla de serie tres proveedores: OpenAI, Google Gemini y Anthropic Claude. La palabra «de serie» engaña un poco, porque no vienen instalados: para cada uno necesitas añadir el plugin proveedor específico desde WordPress.org. El core define el contrato; el plugin implementa la conversación concreta con esa API.

El flujo, en orden

1. Crea la cuenta y la clave en el proveedor. En los tres casos necesitas una cuenta de plataforma de desarrollador con método de pago asociado, que no es lo mismo que una suscripción de consumo al chat. Es un error frecuente: pagar la suscripción mensual del asistente conversacional no te da acceso de API.
2. Genera una clave dedicada a este sitio. Una clave por proyecto, nunca una compartida entre clientes o entornos. Si el proveedor permite nombrar las claves, ponles el dominio. Cuando dentro de ocho meses veas un consumo raro, agradecerás poder atribuirlo.
3. Instala el plugin proveedor desde el repositorio oficial. Revisa que sea el publicado por el equipo correspondiente y no un clon con nombre parecido: los repositorios de plugins son terreno abonado para la suplantación cuando una funcionalidad se pone de moda.
4. Introduce la clave en Ajustes > Conectores y guarda. El panel valida la credencial contra el proveedor.
5. Comprueba que la llamada de prueba funciona antes de habilitar nada más. Si el servidor tiene restricciones de salida —firewall, proxy corporativo, hosting que bloquea peticiones salientes— este es el momento en que lo descubres.

Ese último punto merece énfasis. En entornos gestionados con políticas estrictas, las peticiones HTTP salientes desde PHP están filtradas por lista blanca. Si tu hosting es de ese tipo, tendrás que autorizar explícitamente los dominios de la API antes de que nada funcione, y el mensaje de error que verás será genérico y poco útil.

Qué proveedor elegir

No hay una respuesta universal y desconfía de quien la dé. Sí hay criterios prácticos que aplicamos en proyectos de cliente. El primero es dónde se procesan los datos: si trabajas con contenido sujeto a restricciones de tratamiento, la ubicación de la inferencia y las condiciones contractuales del proveedor pesan más que cualquier comparativa de calidad. El segundo es la existencia de una modalidad empresarial con compromiso de no entrenamiento sobre tus datos, que suele requerir un plan específico. El tercero, mucho más prosaico, es cuál de los tres tiene ya tu departamento financiero dado de alta, porque abrir un proveedor nuevo implica contrato, factura y alguien que lo apruebe.

En cuanto a modelos, la regla que seguimos es usar el más pequeño que resuelva la tarea. Generar un texto alternativo para una imagen de catálogo no requiere el modelo insignia del proveedor; requiere uno rápido y barato. La diferencia de coste entre gamas de modelos dentro de un mismo proveedor es de órdenes de magnitud, no de porcentajes, y en tareas masivas y repetitivas eso decide si el proyecto es viable o absurdo.

El plugin experimental «AI»: para qué sirve de verdad

El equipo de WordPress publica además un plugin experimental llamado simplemente «AI». Genera extractos, textos alternativos, imágenes destacadas y títulos. Es la demostración de que los conectores de IA funcionan, y es útil exactamente para eso.

Nuestra postura de agencia es clara: no lo pongas en producción. Es una pieza de pruebas, sin compromiso de estabilidad ni de continuidad de la interfaz, y su propósito declarado es que la comunidad valide la capa de conectores con casos reales. Instálalo en staging, genera veinte alt text, mira la calidad del resultado, mira el consumo que ha provocado en el panel del proveedor y saca conclusiones. Eso es un experimento bien hecho. Activarlo en el sitio que factura y dejar que un editor lo use a diario no lo es.

Dicho lo cual, ese experimento te da un dato valiosísimo antes de invertir en nada: cuánto cuesta realmente tu caso de uso. Es la forma más barata de responder a la pregunta del siguiente apartado.

4. El coste real: pagas tu propia clave, por uso

Aquí es donde más proyectos se tuercen, porque la palabra «incluido en el core» se confunde con «gratis». Lo repetimos: el core aporta la fontanería, el consumo lo facturas tú directamente al proveedor.

Cómo funciona la facturación por tokens, sin misticismo

Los proveedores cobran por token, que es la unidad en que los modelos trocean el texto. Un token equivale aproximadamente a un fragmento de palabra; en español, una palabra corriente suele consumir algo más de un token, y los tecnicismos y nombres propios se parten en varios. Para estimar por lo alto, es razonable pensar en unos pocos tokens por cada palabra que entra y sale.

Se factura en dos direcciones. Los tokens de entrada son todo lo que envías: la instrucción del sistema, el contexto que adjuntas y el contenido a procesar. Los tokens de salida son lo que el modelo devuelve. La salida se cobra bastante más cara que la entrada, y esa asimetría es la que explica por qué una tarea aparentemente pequeña puede salir cara si pides respuestas largas.

La consecuencia práctica es contraintuitiva para quien viene del mundo de las licencias: no pagas por instalar la función, pagas cada vez que alguien la usa. Un plugin que cuesta ciento cincuenta euros al año tiene un coste conocido. Una función de IA en el editor tiene un coste que depende de cuánta gente la use, con qué frecuencia y con qué disciplina. Ese cambio de modelo mental es el que hay que trasladar a dirección antes de aprobar nada.

Estimar un caso típico: el alt text de un catálogo

Supongamos el escenario más común que nos piden: una tienda con varios miles de imágenes de producto sin texto alternativo, y la idea de generarlos automáticamente. El razonamiento de estimación, sin inventar precios, sería este.

Cada imagen implica una llamada. La entrada incluye la imagen o su descripción contextual más una instrucción breve; la salida es una frase de quince o veinte palabras. Es decir, entrada moderada y salida muy pequeña: el perfil más barato que existe. Multiplicado por unos miles de elementos, hablamos de un gasto puntual que en la mayoría de catálogos medianos se mueve en el orden de unas pocas decenas de euros con un modelo económico, y que puede multiplicarse por diez o más si alguien decide usar el modelo insignia «porque da mejores resultados». La forma de saberlo con certeza es la del apartado anterior: procesa cincuenta imágenes, mira el consumo facturado, extrapola. Nunca al revés.

El caso de los resúmenes es distinto y más caro por unidad. Ahí la entrada es el artículo completo —potencialmente miles de tokens— y la salida un párrafo. Si además el resumen se regenera cada vez que se guarda el post, y el post se guarda quince veces durante la edición, has multiplicado el coste por quince sin darte cuenta. Ese detalle, el de cuándo se dispara la llamada, importa más que el precio unitario.

Cómo poner límites de verdad

La contención del gasto no se hace en WordPress, se hace en el proveedor y en el diseño de la integración. Cuatro medidas que aplicamos siempre:

• Límite de gasto duro en la cuenta del proveedor. Todos permiten fijar un tope mensual y alertas por umbral. Configúralo antes de pegar la clave en ningún sitio. Es la única red de seguridad que no depende de tu código.
• Clave por entorno. Staging y producción nunca comparten credencial. Un bucle accidental en pruebas no debe consumir el presupuesto del sitio real.
• Cachear e idempotencia. Si el contenido no ha cambiado, no vuelvas a llamar al modelo. Guardar el resultado y comprobar un hash del origen antes de regenerar elimina la mayor parte del gasto repetido.
• Procesamiento en lotes con cola. Para tareas masivas, encolar y procesar de forma controlada permite parar en seco si el consumo se desvía, algo imposible si lanzaste cuatro mil peticiones de golpe.

Y una consideración de rendimiento que suele olvidarse: cada llamada síncrona a una API externa desde el guardado de un post añade su latencia al tiempo de respuesta del administrador. Si la integración bloquea el save_post, has convertido una publicación de medio segundo en una de varios segundos, con el riesgo de agotar el tiempo máximo de ejecución de PHP. Las llamadas a modelos deberían ser asíncronas prácticamente siempre.

5. Seguridad y control de acceso

Centralizar la clave reduce la superficie de exposición, pero no la elimina: la concentra. Y una superficie concentrada exige una política explícita sobre quién puede tocarla.

Quién puede invocar la IA

La respuesta por defecto —quien tenga capacidad de administración— es insuficiente en cuanto el equipo pasa de tres personas. En una redacción con ocho editores, si todos pueden lanzar generaciones sin control, el gasto es imprevisible y la trazabilidad, nula. La pregunta correcta no es «¿quién es administrador?» sino «¿quién necesita esta función para su trabajo diario y quién debería pedirla?».

Lo razonable es separar dos permisos distintos: configurar el conector (que debería quedar restringido a un puñado de personas, idealmente las mismas que gestionan el hosting) y consumir el conector (que puede ser más amplio, pero acotado a roles concretos y a funciones concretas). El error clásico es dar por hecho que ambos van juntos.

Añade el problema de las cuentas heredadas. Casi todos los sitios que auditamos tienen usuarios administradores que ya no trabajan allí, colaboradores externos de una migración de hace tres años y alguna cuenta de servicio con contraseña compartida. Antes de WordPress 7 eso era un riesgo de contenido; ahora también es un riesgo económico. Si nunca has hecho esa limpieza, es buen momento: lo tratamos con detalle en nuestra guía de seguridad de WordPress para empresas.

Qué datos salen de tu servidor

Esta es la parte que más incomoda en las reuniones y la que más importa. Cuando una función de IA procesa un contenido, ese contenido viaja a un tercero. No es una metáfora: sale de tu infraestructura, atraviesa Internet y se procesa en servidores que no controlas.

Con un post público de blog, el impacto es bajo. Con el borrador de una nota de prensa bajo embargo, con la ficha de un producto no anunciado, con los comentarios internos de una revisión editorial o con los datos de un pedido de WooCommerce, la conversación es otra. Un resumen automático de tickets de soporte, por ejemplo, puede estar enviando nombres, correos y direcciones a un proveedor externo sin que nadie lo haya evaluado.

Implicaciones de RGPD

Si el contenido enviado incluye datos personales, el proveedor de IA es un encargado del tratamiento y necesitas el contrato correspondiente, con sus garantías de transferencia internacional si el procesamiento ocurre fuera del Espacio Económico Europeo. También debe reflejarse en el registro de actividades de tratamiento y, según el caso, en la información que das a los interesados.

Dos cautelas adicionales que solemos recomendar. La primera es verificar el compromiso de no entrenamiento sobre los datos enviados por API, que en varios proveedores existe pero depende del plan contratado; asumirlo sin comprobarlo es un error caro. La segunda es la retención: aunque no se entrene con ellos, los datos pueden conservarse un tiempo por motivos de abuso y seguridad, y ese periodo debe encajar con tu política.

La conclusión operativa es sencilla de enunciar y trabajosa de aplicar: define qué tipos de contenido pueden pasar por un conector y cuáles no, y déjalo escrito antes de que alguien lo decida por su cuenta un viernes por la tarde.

Por qué centralizar reduce la exposición

Frente al modelo anterior de una clave por plugin, el panel de conectores de IA del core mejora en cuatro frentes concretos. Reduce el número de copias del secreto, que es la métrica que de verdad importa en la gestión de credenciales. Unifica la calidad de la implementación, en lugar de depender del criterio de cada autor de plugin. Permite rotar en un solo gesto, lo que hace que rotar deje de ser un proyecto y pase a ser una tarea. Y da un punto único de auditoría, que es lo que necesitas cuando alguien pregunta qué se está usando y desde dónde.

No resuelve, en cambio, el problema de fondo: si un atacante consigue acceso de administrador, tiene la clave y tiene la factura. Todo lo que ya sabías sobre endurecer el acceso al escritorio de WordPress sigue aplicando, y ahora con una consecuencia económica añadida. Los controles habituales —doble factor, limitación de intentos, revisión de roles, actualizaciones al día— son la base sobre la que esto se sostiene, tal y como detallamos en la guía técnica para proteger una web WordPress.

6. Abilities API y adaptador MCP: cuando el agente entra en tu casa

Hasta aquí hemos hablado de WordPress llamando a un modelo. Ahora invierte la dirección: un agente externo —un asistente de escritorio, una automatización, una herramienta de un proveedor— se conecta a tu sitio y ejecuta acciones dentro de él. Eso es lo que habilita el adaptador MCP sobre la Abilities API.

La Abilities API es un registro donde cada capacidad se declara con nombre, descripción, esquema de parámetros y comprobación de permisos. El adaptador MCP traduce ese registro a un protocolo que los agentes entienden. El resultado, cuando está bien montado, es que puedes pedirle a un agente «revisa los productos sin descripción y prepárame borradores» y el agente sabrá qué llamadas hacer.

El resultado, cuando está mal montado, es un canal por el que un tercero ejecuta acciones con capacidades de tu sitio. Y a diferencia de una API REST tradicional, aquí quien decide qué llamada hacer no es un desarrollador que escribió el código, sino un modelo que interpreta una instrucción en lenguaje natural. Esa diferencia lo cambia todo desde el punto de vista de seguridad.

Por qué exige una política de permisos seria

Tres riesgos concretos, ninguno teórico. El primero es la inyección indirecta de instrucciones: si el agente lee contenido del propio sitio —un comentario, un formulario recibido, la descripción de un producto enviada por un proveedor— ese contenido puede incluir texto diseñado para que el modelo lo interprete como una orden. El agente no distingue de forma fiable entre «datos que estoy leyendo» e «instrucciones que debo obedecer».

El segundo es la amplificación de permisos. Si la credencial con la que opera el agente tiene capacidades de administrador, cualquier desviación en su comportamiento se ejecuta con esas capacidades. Un agente debería operar siempre con el mínimo privilegio necesario para su tarea, con un usuario dedicado y no con la cuenta de una persona.

El tercero es la falta de trazabilidad. Si tres personas usan agentes conectados al mismo sitio y todos entran con la misma credencial, cuando algo se publique mal no habrá forma de saber quién lo originó. Un usuario por agente, registro de acciones activado y revisión periódica.

Nuestra recomendación para 2026 es conservadora: habilita el adaptador MCP solo si tienes un caso de uso concreto que lo justifique, empieza con capacidades de solo lectura, y no permitas acciones de escritura sin un paso de aprobación humana. La tentación de dar acceso completo «para probar» es fuerte y es exactamente el escenario que acaba mal. Esta cautela, por cierto, es la misma que llevó a retirar la colaboración en tiempo real de la 7.0 el 8 de mayo de 2026 por superficie de ataque, condiciones de carrera y carga de servidor: el proyecto está siendo prudente con lo que expone, y conviene serlo también en la configuración.

7. Casos de uso que sí rentan, y cuáles no

Después de bastantes conversaciones con clientes sobre esto, hemos llegado a un criterio bastante simple para separar el grano de la paja: renta cuando la tarea es repetitiva, verificable y de bajo riesgo editorial. No renta cuando exige criterio, contexto de negocio o responsabilidad sobre lo publicado.

Lo que funciona

Textos alternativos de imágenes. El caso más claro con diferencia. Es una tarea que nadie quiere hacer, que afecta directamente a la accesibilidad, que se verifica de un vistazo y donde un resultado mediocre sigue siendo mejor que el vacío actual. En catálogos grandes, es la primera automatización que recomendamos.

Extractos y meta descripciones. Con revisión humana rápida. El modelo produce un punto de partida decente a partir de un texto que ya existe, que es un trabajo de síntesis, no de creación.

Normalización de contenido heredado. Fichas de producto importadas de un ERP con formato inconsistente, categorías mal etiquetadas, títulos con mayúsculas erráticas. Tareas mecánicas sobre volumen alto donde la alternativa es un becario aburrido.

Clasificación y etiquetado. Asignar categorías a un archivo de mil entradas, detectar contenido duplicado, agrupar por temática. La salida es corta —una etiqueta— y por tanto barata.

Lo que no

Escribir los artículos del blog. No por purismo, sino por resultado: el contenido genérico no posiciona ni convierte, y el tiempo de edición para dejarlo publicable suele superar al de escribirlo bien desde el principio. Si tu diferencial es el conocimiento técnico, delegarlo en un modelo es renunciar a él.

Traducciones de contenido legal o comercial sensible. Condiciones de venta, política de privacidad, especificaciones técnicas con implicaciones de garantía. El coste de un error no lo cubre el ahorro.

Respuestas automáticas a clientes sin supervisión. Especialmente en comercio electrónico, donde una respuesta incorrecta sobre plazos, stock o devoluciones genera una reclamación real.

Cualquier cosa que se dispare en cada carga de página. Ni por coste ni por rendimiento. Si estás pensando en personalizar contenido con IA en tiempo real para cada visitante, haz primero el cálculo de llamadas mensuales; la cifra suele terminar la discusión. Sobre este equilibrio entre funcionalidad y peso de página hablamos también al analizar los cambios en bloques y medios de WordPress 7 y su impacto en rendimiento.

El criterio de agencia, resumido en una pregunta

Antes de aprobar una integración de IA en un sitio de cliente preguntamos siempre lo mismo: si el modelo devuelve algo incorrecto y se publica sin que nadie lo revise, ¿qué pasa? Si la respuesta es «una imagen tiene un alt text mejorable», adelante. Si la respuesta es «un cliente lee un plazo de entrega equivocado», el caso de uso necesita un humano en medio, y entonces hay que recalcular si sigue ahorrando tiempo.

Conclusión

WordPress 7 no te resuelve la creación de contenido. Te da un panel de credenciales, un registro de capacidades y un adaptador de protocolo, y te deja a ti la decisión de qué hacer con ello, con quién y a qué precio. Es una novedad de infraestructura, y las novedades de infraestructura no se miden por lo que hacen el primer día sino por lo que permiten construir encima durante los siguientes años.

Para quien administra un sitio en producción, la actitud sensata durante los próximos meses es la de siempre con las funcionalidades nuevas: probar en staging, medir el consumo real antes de comprometerse, activar solo lo que tiene un caso de uso identificado y dejar por escrito quién puede usar qué. La parte de IA es la que llama la atención; la parte de gobierno de accesos y control de gasto es la que determinará si esto sale bien o acaba en una factura sorpresa y un incidente de datos.

Y si tu sitio todavía no está en la 7.0, el orden correcto es primero la actualización bien planificada y después los conectores de IA. Nunca las dos cosas la misma tarde.

Preguntas frecuentes

¿WordPress 7 incluye inteligencia artificial gratis?

No. El core incluye la infraestructura para conectar con proveedores de IA, pero el procesamiento lo hace un tercero al que pagas por uso con tu propia clave de API. No hay cuota incluida ni créditos de bienvenida por parte de WordPress.

¿Necesito instalar algo además de actualizar a WordPress 7?

Sí. Los proveedores de serie —OpenAI, Google Gemini y Anthropic Claude— requieren instalar su plugin proveedor específico desde WordPress.org. El panel de Ajustes > Conectores por sí solo no habla con ninguna API.

¿Puedo usar el plugin «AI» oficial en producción?

No lo recomendamos. Es un plugin experimental del equipo de WordPress pensado para validar la infraestructura: genera extractos, textos alternativos, imágenes destacadas y títulos, pero sin compromiso de estabilidad. Úsalo en staging para medir calidad y consumo.

¿Cuánto cuesta generar el alt text de un catálogo entero?

Depende del número de imágenes y sobre todo del modelo elegido, con diferencias de órdenes de magnitud entre las gamas de un mismo proveedor. Al ser una tarea de salida muy corta, es de los usos más baratos que existen. La única estimación fiable es procesar una muestra pequeña, mirar el consumo facturado y extrapolar.

¿Enviar contenido a un proveedor de IA afecta al RGPD?

Si ese contenido contiene datos personales, sí: el proveedor actúa como encargado del tratamiento y necesitas el contrato correspondiente, sus garantías de transferencia internacional cuando aplique y el reflejo en tu registro de actividades. Conviene además verificar las condiciones de entrenamiento y retención del plan que tengas contratado.

¿Qué es el adaptador MCP y debería activarlo?

Es la pieza que expone las capacidades registradas en la Abilities API para que agentes externos las invoquen. Actívalo solo si tienes un caso de uso concreto, empezando por capacidades de solo lectura, con un usuario dedicado de permisos mínimos y aprobación humana para cualquier acción de escritura.

¿Sustituye esto a los plugins de IA que ya pago?

No de forma automática. Lo que hace el core es estandarizar dónde vive la credencial y cómo se invoca al proveedor; los plugins deben adaptarse para consumir el conector. Durante un tiempo convivirán ambos modelos, y parte del trabajo de mantenimiento será inventariar las claves dispersas y migrarlas.