Agentes IA en WordPress: qué decidir antes de dejar que un agente toque un sistema de folios

Los agentes IA en WordPress pasaron de experimento a función del núcleo en pocos meses. Conectar uno ya es fácil. Decidir qué puede hacer ese agente dentro de tu sitio sigue siendo difícil, y es la parte que casi nadie escribe.

Llego a este tema desde un sistema real: un plugin de WordPress que gestionó un pool de 80,000 folios en producción, con verificación de comprobantes por OCR + LLM. Ese sistema no usó agentes. Usó un pipeline. Y esa diferencia es justo el punto de partida.

Este artículo es lo que decidiría antes de dejar que un agente toque un sistema así: qué exponer, qué nunca exponer y cómo dejar rastro de todo. El código es ilustrativo, no el del cliente.

Pipeline o agente: la decisión que va primero

El sistema de Panini Fan Zone FWC 2026 verificaba comprobantes en dos pasos fijos. Tesseract extraía el texto de la imagen. Después un modelo LLaMA 3.3 70B, servido por Groq, validaba ese texto contra las reglas de la promoción.

El orden lo decidía el código. Un cron cada 2 minutos tomaba los pendientes, los pasaba por OCR y por el modelo, y guardaba el resultado. El LLM resolvía un paso; no elegía cuál seguía.

Un agente funciona al revés. Le das herramientas, por ejemplo «consultar folio», «marcar como válido» o «enviar correo», y el modelo decide cuál llamar, en qué orden y con qué datos.

Eso cambia el modelo de riesgo:

• En un pipeline, el peor caso de un error del modelo es una clasificación equivocada. Tus reglas pueden detectarla.
• En un agente, el peor caso es una acción equivocada: cambiar un estado, borrar un registro o escribirle a un participante.
• En un agente, la entrada también es un vector. Si el agente lee el texto de un comprobante, ese texto puede traer instrucciones escritas para manipularlo.

Por eso la primera pregunta no es qué plataforma de agentes usar. Es si el problema necesita un agente. Para verificar comprobantes con reglas claras, un pipeline es más barato, más predecible y más fácil de auditar.

Un agente tiene sentido alrededor del sistema: para que el equipo de soporte pregunte en lenguaje natural por el estado de un folio, para resumir incidencias o para preparar reportes. Ahí la flexibilidad vale la pena, siempre que las herramientas estén bien acotadas.

Integración de agentes IA en WordPress

WordPress está agregando piezas para que los agentes descubran y usen las capacidades de un sitio, con APIs que describen qué puede hacer cada plugin y un puente hacia el protocolo MCP. Es un buen avance, pero no cambia la regla de fondo.

Sea cual sea el conector, al final el agente llama a algo dentro de tu sitio con los permisos de un usuario. La seguridad depende de qué expones y con qué permisos, no del protocolo. La REST API de WordPress ya trae todo lo necesario para hacerlo bien.

Empieza con herramientas de solo lectura

La primera herramienta debe responder preguntas sin cambiar nada. Consultar el estado de un folio es el ejemplo perfecto: útil para soporte y sin efectos secundarios.

add_action( 'rest_api_init', function () {
    register_rest_route( 'folios/v1', '/estado/(?P<folio>[A-Z0-9-]{6,20})', [
        'methods'             => 'GET',
        // Una capability propia: el usuario del agente no es administrador.
        'permission_callback' => fn () => current_user_can( 'folios_consultar' ),
        'callback'            => function ( WP_REST_Request $req ) {
            $estado = folios_estado( $req['folio'] ); // solo lectura
            // Nunca devuelvas datos personales: el agente no los necesita.
            return [ 'folio' => $req['folio'], 'estado' => $estado ];
        },
    ] );
} );

Tres decisiones hacen segura esta ruta:

• La expresión regular valida el folio antes de tocar la base. Lo que no tiene forma de folio ni siquiera llega al callback.
• permission_callback revisa una capability dedicada. No manage_options ni «cualquier usuario con sesión». El rol del agente tiene esa capability y nada más.
• La respuesta trae lo mínimo. El estado del folio, sí. El nombre, el correo o la imagen del comprobante, no.

Nunca dejes permission_callback en __return_true para una ruta que consulta datos de negocio. Es la forma más rápida de convertir una herramienta de soporte en una fuga.

Un usuario y una contraseña solo para el agente

El agente debe autenticarse como un usuario propio, con un rol creado para él. Las contraseñas de aplicación de WordPress son ideales: se revocan una por una y no sirven para iniciar sesión en el panel.

# ⚠️ Producción: respalda la base de datos antes de dar acceso a un agente.
wp db export "respaldo-$(date +%F).sql"

# Usuario propio para el agente: si algo sale mal, se revoca sin tocar a nadie.
wp user create agente-folios "$CORREO_AGENTE" --role=agente_folios

# Contraseña de aplicación: revocable y separada de la de inicio de sesión.
wp user application-password create agente-folios "agente-lectura" --porcelain

# Prueba: la lectura responde; una ruta sin la capability debe dar 401 o 403.
curl -s -u "agente-folios:$APP_PASS" https://tu-sitio.example/wp-json/folios/v1/estado/FZ-000123

El rol agente_folios se registra en el plugin con add_role y solo lleva las capabilities de consulta. Si el agente se comporta mal, revocas su contraseña y el resto del sitio sigue igual.

Escritura: propuestas, no acciones

Tarde o temprano alguien va a pedir que el agente también pueda «arreglar» cosas. La respuesta segura es que el agente proponga y una persona apruebe.

register_rest_route( 'folios/v1', '/propuestas', [
    'methods'             => 'POST',
    'permission_callback' => fn () => current_user_can( 'folios_proponer' ),
    'callback'            => function ( WP_REST_Request $req ) {
        global $wpdb;
        // El agente no cambia el folio: deja una propuesta que aprueba una persona.
        $wpdb->insert( "{$wpdb->prefix}folios_propuestas", [ 'folio' => sanitize_text_field( $req['folio'] ),
            'accion' => sanitize_key( $req['accion'] ), 'autor' => get_current_user_id(), 'estado' => 'pendiente' ] );
        return new WP_REST_Response( [ 'id' => $wpdb->insert_id ], 202 ); // 202: aceptado, no ejecutado
    },
] );

El código 202 comunica exactamente lo que pasó: la solicitud se aceptó, pero no se ejecutó. La acción real ocurre cuando alguien con permisos la aprueba desde el panel, y ese paso usa la misma validación que usaría una persona.

Este patrón tiene una ventaja extra: la tabla de propuestas es, también, el registro de lo que el agente intentó hacer.

Límites y auditoría desde el primer día

Un agente puede entrar en un ciclo y llamar la misma herramienta cientos de veces en un minuto. Eso debe chocar con un límite, no con tu base de datos.

• Límite de llamadas por usuario. Un contador por minuto, guardado en un transient o en caché de objetos, que responda 429 al pasarse.
• Registro de cada llamada. Quién, qué ruta, con qué parámetros, cuándo y con qué resultado. Sin ese registro, un incidente es imposible de reconstruir.
• Revocación probada. Antes de conectar, prueba que revocar la contraseña de aplicación corta el acceso al instante.

llms.txt: qué es y qué NO es

Alrededor de los agentes en WordPress circula una confusión que vale la pena aclarar. llms.txt no es una configuración para procesar documentos, ni un archivo que ayude a un pipeline de OCR o LLM a leer comprobantes.

Es un archivo de texto en Markdown, en la raíz del sitio, que le explica a un modelo de lenguaje qué contiene tu sitio y dónde está lo importante. Su público son los asistentes y agentes que leen la web, no tu backend.

Este mismo sitio publica uno en /llms.txt. Una estructura de ejemplo se ve así:

# Samuel Torres — ingeniero de software y cloud

> Backend a medida, servidores Linux y automatización con IA en Ciudad de México.

## Casos
- [Panini Fan Zone](https://samueltorres.dev/casos/panini-fan-zone/): 80,000 folios con verificación OCR + LLM.

## Servicios
- [Automatización con IA](https://samueltorres.dev/servicios/automatizacion-con-ia/): pipelines de OCR y LLM.

## Opcional
- [Blog](https://samueltorres.dev/blog/): artículos técnicos.

Lo que llms.txt sí hace:

• Da contexto curado. En lugar de que el modelo adivine leyendo menús y pies de página, le entregas un resumen con enlaces.
• Prioriza. Las secciones de arriba son lo esencial; la sección «Opcional» es lo que se puede omitir si falta espacio.

Lo que no hace:

• No controla el rastreo. Para eso sigue existiendo robots.txt.
• No protege nada. Es público por definición. Nunca listes ahí rutas internas, endpoints de la API ni nada que no quieras ver en una respuesta de un chatbot.
• No reemplaza la REST API. Describe tu contenido; no le da herramientas a un agente.

En un sistema de folios, entonces, llms.txt solo describe la parte pública: qué es la promoción, cómo participar y dónde están las bases. El procesamiento de comprobantes vive en el backend, lejos de ese archivo.

Mejorando el procesamiento de folios (con o sin agente)

Si la meta es procesar mejor los folios, la mayor parte de la mejora no viene de un agente. Viene de endurecer el pipeline. Esto es lo que más rinde:

• Las reglas del negocio viven en código y en la base de datos. El modelo propone si un comprobante cumple; las restricciones únicas y las validaciones deciden. En el módulo de registro de ese proyecto, un índice único compuesto por actividad fue lo que impidió registros dobles.
• Filtra antes de llamar al modelo. Si el OCR devolvió texto vacío, rechaza ahí. Cada llamada evitada es costo y latencia que no pagas.
• Trata el texto del comprobante como dato, nunca como instrucción. Pásalo al modelo delimitado y con la tarea fija. Si alguna vez un agente lo lee, esta regla se vuelve crítica.
• Pide salida estructurada y valídala. Campos fijos, tipos fijos. Lo que no cumpla el formato se marca para revisión.
• Prueba la concurrencia. La suite de ese proyecto incluyó una prueba con 50 workers simultáneos contra la misma ruta para confirmar que solo un registro ganara cada cupo.

Con ese pipeline sólido, un agente de soporte encima es un complemento útil: responde preguntas sobre folios usando la herramienta de solo lectura, y deja propuestas cuando algo necesita corrección.

El orden importa. Primero un sistema determinista que funcione sin IA en el bucle de decisión. Después, si aporta, un agente que lo consulte con permisos mínimos.

Lo que NO debes hacer

• Conectar el agente con un usuario administrador. Es lo más rápido para la demo y lo más peligroso en producción. El agente hereda todo lo que ese usuario puede hacer, incluido instalar plugins.
• Darle escritura directa sobre datos de negocio. Cambiar estados de folios, borrar registros o enviar correos sin aprobación humana convierte cada error del modelo en un incidente.
• Dejar que el agente lea entrada de usuarios sin aislarla. El texto de un comprobante o de un formulario puede traer instrucciones. Si el agente tiene herramientas de escritura y lee ese texto, alguien de fuera puede intentar dirigirlo.

El siguiente paso

Integrar agentes IA en WordPress no es un problema de conectores. Es un problema de permisos: qué herramientas existen, quién las puede usar, qué se registra y qué requiere una persona.

Si tu equipo quiere conectar agentes a un WordPress con datos de negocio, endurecer un pipeline de OCR + LLM o auditar qué expone hoy su REST API, en Conqr Digital Agency diseñamos arquitecturas que escalan. Revisemos tu caso.

El sistema de folios que inspiró este artículo está documentado en el caso de Panini Fan Zone. Y si buscas automatizar procesos con IA, revisa el servicio de automatización con IA.

Preguntas frecuentes

¿Qué diferencia hay entre un pipeline con LLM y un agente de IA?

En un pipeline, tu código decide el orden de los pasos y el modelo solo resuelve uno de ellos. En un agente, el modelo decide qué herramienta llamar y con qué datos. El agente es más flexible, pero cada herramienta que le das es una puerta que puede abrir.

¿Cómo conecto un agente de IA a WordPress de forma segura?

Con un usuario propio y un rol mínimo, una contraseña de aplicación revocable, rutas de la REST API con permission_callback y una capability dedicada, y un registro de cada llamada. Empieza solo con lectura.

¿Para qué sirve llms.txt en WordPress?

Es un archivo en la raíz del sitio que resume, en Markdown, qué contiene el sitio y dónde está lo importante, para que un modelo de lenguaje lo lea mejor. No controla el rastreo ni procesa documentos.