La IA de WordPress desató una polémica por el consentimiento que los proveedores de hostin

WordPress 7.0 introdujo la IA en el núcleo del CMS por primera vez en mayo, pero la elección de diseño más importante quizá fue lo que no hizo: activar nada automáticamente. Los propietarios de sitios deben conectar un proveedor y habilitar la IA por sí mismos, de modo que una actualización rutinaria deja el sitio funcionando exactamente como antes.

Ese enfoque de activación estableció un límite claro. La plataforma entregó la infraestructura, pero dejó la decisión en manos de la persona que posee el sitio. Según el autor, cofundador de Flashcloud, esa prudencia importó tanto como la propia función.

En cuestión de días, SiteGround tomó un camino distinto. El host gestionado de WordPress preinstaló y activó su propio producto de IA para los clientes, lo estableció como el conector predeterminado y ofreció uso gratuito para fomentar su adopción. Su contador de instalaciones activas superó el millón casi de inmediato, lo que significa que muchos clientes se encontraron con nuevo software ya ejecutándose en sus sitios sin haberlo activado.

El autor se cuida de no presentar esto como una mala conducta. SiteGround se describe como un operador de buena reputación, y el producto en sí como una ingeniería sólida más que un simple intento de venta adicional. La lógica es sencilla: la configuración nativa de IA puede ser complicada, y preinstalarla elimina fricciones.

Por qué se produjo la reacción

La reacción, sostiene el artículo, no fue principalmente contra la IA. Muchos de los críticos ya usan herramientas de IA con regularidad. El problema real fue el consentimiento.

Recomendado

La IA empresarial necesita garantías, no un enfoque de mejor esfuerzo

Una función puede ser útil y aun así parecer incorrecta si llega sin permiso. "Puedes desactivarla" no es lo mismo que estar de acuerdo, porque traslada la carga de notar, entender y deshacer el cambio al cliente. Una opción de configuración con un clic ofrecería la misma conveniencia sin quitar la decisión a los propietarios del sitio.

Esa distinción también separa dos tipos de intervención por parte de los proveedores de hosting:

• Cambios defensivos, como parchear vulnerabilidades o bloquear tráfico malicioso
• Cambios de producto, como instalar y activar nuevas funciones

El primero protege al cliente y a la plataforma. El segundo altera lo que es el sitio web.

Dónde deberían trazar la línea los proveedores de hosting

El argumento central del artículo es simple: los proveedores de hosting deberían mantener libremente la plataforma, pero solo cambiar el producto con un claro sí por parte del cliente. Eso no significa crear trabajo extra. Las nuevas herramientas pueden permanecer desactivadas por defecto mientras siguen siendo fáciles de habilitar, y los proveedores pueden ofrecer a los clientes multisitio controles centralizados en lugar de obligarles a revisar cada sitio individualmente.

También importa un aviso previo claro, especialmente cuando incluye una forma sencilla de optar por no usarlo. Sin eso, incluso una decisión de producto común puede convertirse en un problema de confianza.

A medida que la IA se convierta en una capa por defecto en toda la web, el autor sostiene que las empresas de hosting seguirán enfrentando la misma tensión: la opción más conveniente para el operador no siempre será la correcta para el cliente. Las empresas que mantengan ese límite intacto estarán protegiendo aquello por lo que los clientes realmente pagan: la confianza de que nada en su sitio cambia a menos que ellos lo hayan elegido, o a menos que el proveedor intervenga para protegerlo.