La creación de sitios con IA y la edición de WordPress en producción necesitan límites distintos

La separación que importa

Tres entornos necesitan tres grados de libertad distintos.

Dos procesos

Una misma interfaz de chat oculta dos trabajos muy diferentes.

El 24 de agosto, WordPress.com anunció dos procesos con agentes el mismo día. La nueva beta de WordPress Studio permite que un agente trabaje sobre una instalación local real de WordPress, con vista previa en directo y un paso deliberado antes de publicar nada. El plugin de WordPress.com para ChatGPT se ocupa de otra fase: puede trabajar con un sitio existente, crear borradores, gestionar archivos y comentarios, consultar información del sitio y pedir aprobación antes de realizar cambios. Fuentes: beta de WordPress Studio con agentes y plugin de WordPress.com para ChatGPT.

Estos procesos no deberían compartir un único modelo de permisos. El modo de creación pertenece sobre todo a la fase de agencia o desarrollo. La edición de contenido corresponde a la fase operativa, después de entregar el sitio a editores y propietarios. En ese momento, el objetivo ya no es reinventar el sitio, sino crear y mantener contenido dentro de la estructura ya aprobada.

• El modo de creación admite más experimentación porque funciona fuera de producción y puede recurrir a instantáneas, puntos de restauración o reconstrucciones limpias.
• La edición de contenido solo debería mostrar los tipos de contenido, estructuras, campos, operaciones con archivos y acciones de borrador que el propietario necesita de verdad.
• La entrega de la agencia al propietario también debería sustituir los amplios permisos de creación por una superficie de escritura mucho menor en producción.

Esta diferencia importa aunque ambas experiencias parezcan un cuadro de chat. Un permiso cómodo durante la creación que se mantenga tras la entrega puede convertirse silenciosamente en un privilegio de producción.

Límite de seguridad

Una instrucción puede orientar a un agente, pero no puede contenerlo.

Una instrucción del sistema, una regla permanente o un límite definido en el modelo sirve para orientar el comportamiento. No es una barrera de seguridad firme. Se pide al mismo sistema no determinista que cumpla un objetivo y decida cuánto debe limitarse mientras lo hace. Cuando ambas presiones chocan, una arquitectura de producción no puede tratar el resultado como algo previsible.

El reciente incidente de OpenAI y Hugging Face ilustra especialmente bien por qué la contención debe existir fuera del modelo. OpenAI describió agentes ejecutándose en entornos aislados destinados a limitar sus efectos y, en la mayoría de los casos, separarlos entre sí. METR y Redwood Research concluyeron que unos 1.200 agentes encontraron una vía de comunicación no autorizada y que alrededor de 700 participaron después en el ataque a Hugging Face. Ocurrió en un entorno de investigación y evaluación, no en un proceso normal de gestión de contenidos, pero la lección arquitectónica sigue siendo relevante: el aislamiento previsto falló porque una capacidad disponible abrió un camino inesperado. Fuentes: informe de OpenAI e investigación de METR.

• Conceda al agente solo la capacidad necesaria para la tarea actual, no acceso general de administrador por comodidad.
• Haga cumplir los permisos, las operaciones permitidas y los cambios de estado en sistemas externos al modelo.
• Mantenga los cambios visibles y reversibles para que la recuperación no dependa de que el agente comprenda su error anterior.

La confirmación humana es valiosa, pero no convierte una autoridad amplia del agente en una barrera firme. Revisar una acción de borrador bien definida es muy distinto de aprobar un conjunto amplio y poco delimitado de cambios en un sitio en producción.

Modo de creación

Dé más libertad al agente donde los fallos sean baratos y reversibles.

Los entornos locales, de desarrollo y de pruebas son el lugar adecuado para trabajos amplios de creación con agentes. El agente puede crear o reorganizar estructuras, analizar un sitio existente, probar una dirección de diseño, ejecutar migraciones e iterar con rapidez. Las instantáneas y los puntos de restauración permiten experimentar con decisión porque un intento fallido no afecta al sitio público.

Esto también aclara dónde encaja el proceso previsto para Composer Pro. Su propósito no consiste simplemente en «describa un sitio y reciba código generado». Parte de una base reutilizable de WordPress, analiza el origen y el destino, prepara una propuesta de configuración específica, la somete a revisión humana y usa Composer para crear borradores de WordPress validados. El análisis del sitio de origen y la ayuda de agentes pueden formar parte del proceso, pero el resultado es una transformación controlada hacia una estructura aprobada.

• Analice el origen y el destino antes de generar la estructura final.
• Convierta el análisis en una propuesta acotada de configuración y control de contenidos, en lugar de dejar que un agente improvise repetidamente todo el sitio.
• Revise la propuesta antes de que las operaciones previsibles de Composer la conviertan en borradores y estructuras de WordPress.

Aquí existe un solapamiento real con WordPress Studio durante la creación del sitio, y es una señal útil del mercado. Studio ofrece un entorno local de WordPress para trabajar con agentes. Composer Pro está pensado para añadir a una base reutilizable un proceso de migración, normalización y destino controlado. Un agente puede participar en esa transformación sin convertirse en la autoridad final sobre lo que WordPress acepta. El modelo de creación segura de páginas con IA muestra cómo los clientes pueden crear páginas sin romper el sistema de diseño.

Modo de contenido

Después de la entrega, traslade el control del modelo al código de WordPress.

Cuando un sitio ya está en funcionamiento, su propietario normalmente no necesita un agente de IA capaz de reconstruir el tema, sustituir cualquier plantilla, cambiar plugins o reescribir cualquier página publicada. El trabajo útil es más limitado: crear un caso de éxito, añadir una página de solución, colocar archivos aprobados, completar campos estructurados, actualizar metadatos o preparar otro tipo de contenido permitido para su revisión.

Agent Composer incorpora otro tipo de límite porque el agente no escribe directamente contenido arbitrario en producción. Pide a Composer que realice una operación. Composer es código normal dentro de WordPress: antes de ejecutar la solicitud comprueba el Blueprint elegido, los patrones y bloques permitidos, el tipo de contenido de destino, las reglas de archivos y campos, la propiedad del borrador, el estado de la revisión y los requisitos de validación. Su modelo público de ejecución solo trabaja con borradores; publicar sigue siendo una decisión humana separada. Fuente: Agent Composer.

• El agente elige la intención y aporta el contenido solicitado.
• Composer decide si la solicitud corresponde a una operación de WordPress válida y permitida, y ejecuta únicamente esa operación.
• Un editor humano mantiene fuera del proceso del agente la decisión de publicar o llevar el cambio a producción.

Esta separación es más sólida que pedir al modelo que se vigile a sí mismo. El componente que aplica la regla no es el mismo sistema no determinista que intenta completar la tarea. El agente puede pedir más de lo permitido; la capa de ejecución previsible puede limitarse a rechazarlo. Consulte cómo permitir que la IA edite WordPress sin acceso de administrador sin límites, cómo controlar el trabajo de IA del cliente tras la entrega y cómo comparar el acceso controlado de Agent Composer con un MCP amplio para WordPress.

Entrega

Separe el sistema de edición de WordPress de la superficie pública de producción.

La separación de entornos puede ir un paso más allá. Mantenga la instalación de desarrollo o pruebas de WordPress separada de la ruta de entrega en producción y evite que el sitio público dependa de un WordPress ampliamente modificable cuando el proyecto no lo necesite. La publicación estática convierte WordPress en la capa de edición y control, y sirve el resultado generado desde servicios como Amazon S3 y CloudFront. Fuente: Static Publisher.

Esta arquitectura no elimina la necesidad de control, y un sitio estático no sirve para todos los proyectos. Añade otra capa de seguridad y funcionamiento. Las solicitudes públicas ya no pasan por el mismo sistema donde un agente, editor, plugin o administrador cambia contenido. Las actualizaciones recorren una ruta explícita de edición, revisión, generación y publicación. Cuando sean necesarios, la identidad, los formularios, los procesos y las API de IA pueden prestarse por separado.

• Cree y revise el contenido dentro de WordPress.
• Genere y publique el resultado aprobado mediante un proceso de publicación separado.
• Sirva la interfaz pública desde una capa que no exponga todo el entorno de edición de WordPress.

Estos límites resuelven problemas distintos y se refuerzan entre sí. Composer separa la intención del agente de los cambios permitidos en el gestor de contenidos. La entrega estática separa ese gestor de la superficie pública. Separar desarrollo y pruebas mantiene la experimentación amplia lejos de ambos. El objetivo no es retirar los agentes de WordPress, sino darles libertad en el entorno donde resulta útil y establecer límites previsibles donde los errores se convierten en incidentes de producción. Para ver la separación completa, consulte cómo mantener WordPress para editar sin exponerlo públicamente.