La primera vez que un cliente me pidió “poner IA” en su WordPress pensé lo mismo que piensa casi todo el mundo al principio: conecto una API, saco un widget de chat y listo. Sobre el papel parecía sencillo. En la práctica, en cuanto empiezas a hacer números, revisar respuestas y pensar en privacidad, la conversación cambia bastante.
Lo que yo buscaba no era un chatbot espectacular para una demo de dos minutos. Buscaba algo que una pyme pudiera usar de verdad en su web sin convertir cada conversación en una factura variable, sin depender por completo de un tercero y sin meter un riesgo innecesario en temas como GDPR, contenidos sensibles o respuestas comerciales que tienen que estar bajo control.
Por eso este artículo no va de prometer una “super IA” para WordPress. Va de explicar, de forma práctica, cómo crear un chatbot IA en WordPress sin pagar tokens por uso, qué probé yo antes de llegar a esa conclusión y por qué, en muchos proyectos reales, la solución más útil no es la más llamativa.
Cómo empecé a investigar chatbots IA para WordPress
Durante bastante tiempo me fueron llegando peticiones muy parecidas. No importaba si era una web corporativa, una academia o una tienda pequeña con WooCommerce. La frase venía a ser la misma: “queremos atender mejor las preguntas repetidas”, “queremos filtrar mejor leads”, “queremos automatizar una parte del soporte” o directamente “queremos un chatbot con IA”.
La idea inicial suele ir por el camino obvio: conectar una API generativa, pasar cada pregunta a un modelo externo y devolver la respuesta en tiempo real. Yo también empecé por ahí, porque técnicamente es el camino más rápido para montar una prueba. En una tarde puedes tener un prototipo que parece bastante convincente.
El problema es que una cosa es montar una demo y otra muy distinta es desplegar una solución que luego haya que mantener en producción para una pyme que quiere previsibilidad, control y margen.
Los problemas que me encontré con APIs de pago y coste por tokens
El primer choque fue el económico. Cuando el proveedor te cobra por tokens, el coste ya no depende de la instalación del sistema, sino del volumen de conversaciones, de la longitud de cada pregunta, de la longitud de cada respuesta y de cuántas pruebas haces ajustando prompts o contexto.
Eso, para una startup con presupuesto y un producto muy orientado a IA, puede ser asumible. Para una pyme o una agencia WordPress que da soporte a varios clientes, muchas veces es incómodo desde el minuto uno. El cliente quiere saber cuánto le va a costar al mes. Y la respuesta honesta, con modelos de pago por uso, muchas veces es: “depende”.
En más de una prueba me pasó algo muy típico: el bot respondía razonablemente bien, pero para mantener calidad había que enviar cada vez más contexto. Más contexto significaba más tokens. Más tokens significaban menos previsibilidad. Y cuando haces números a escala de varias webs, el modelo deja de verse tan bonito.
No es solo el precio. También está el tiempo de supervisión. Un chatbot generativo puede responder con soltura, pero eso no significa que la respuesta sea la correcta para ese negocio concreto. En WordPress esto importa mucho. Una academia no quiere que el bot improvise políticas de matrícula. Una tienda no quiere que el bot invente plazos de entrega. Una empresa de servicios no quiere que el bot redacte condiciones comerciales que nadie ha aprobado.
El punto delicado: GDPR, privacidad y dependencia de terceros
La segunda fricción fue jurídica y arquitectónica. En cuanto una web empieza a enviar conversaciones a servicios externos, toca revisar qué datos viajan, dónde se procesan, qué retención existe y cómo encaja eso en el stack real del cliente. En proyectos pequeños esto suele pasarse por alto al principio, pero cuando la web ya está en producción y alguien pregunta por GDPR, aparece el problema.
No digo que no se pueda hacer. Digo que deja de ser una integración trivial. Y además introduces otra capa de dependencia: si cambia la política del proveedor, si suben precios, si limitan uso o si una integración deja de funcionar, el chatbot entero se resiente.
A mí ese tipo de dependencia me incomoda bastante cuando el problema a resolver es relativamente simple. Si lo único que quiero automatizar es responder bien a preguntas frecuentes, redirigir a la página correcta o captar un lead con contexto, no siempre quiero montar una arquitectura que dependa de un modelo externo en cada interacción.
La conclusión técnica que me cambió el enfoque
Hubo un momento en el que dejé de hacerme la pregunta equivocada. En vez de pensar “¿cómo consigo que el bot genere respuestas cada vez más humanas?”, empecé a preguntarme “¿qué necesita realmente resolver esta web?”.
Y la respuesta, en muchísimos casos, era bastante menos épica y bastante más útil:
- entender qué quiere decir el usuario,
- clasificar esa intención correctamente,
- responder con una salida controlada,
- enlazar a una página ya validada,
- o derivar a una persona cuando toca.
Ese cambio parece pequeño, pero técnicamente lo cambia todo. Porque entender lenguaje natural no es lo mismo que generar texto libre. Y para la mayoría de pymes, la primera parte es muchísimo más valiosa que la segunda.
Qué alternativas fui probando antes de llegar a un modelo más sensato
No llegué a esto por teoría. Fui probando caminos distintos porque quería ver qué aguantaba mejor en proyectos WordPress reales.
1. Intents clásicos
El enfoque por intents fue el primero que realmente me pareció mantenible. El usuario puede escribir “¿cuánto cuesta?”, “¿tenéis precios?”, “quiero saber la tarifa” o “¿qué plan me recomendáis?”. La redacción cambia, pero la intención suele ser la misma: precio.
Cuando trabajas así, el problema deja de ser “inventar una respuesta brillante” y pasa a ser “identificar bien la intención y devolver la respuesta correcta”. En WordPress esto encaja muy bien, porque puedes hacer que la salida sea una respuesta corta, un enlace a precios, una página de servicio o un formulario de contacto.
2. NLP ligero para clasificar mensajes
Después fui afinando con motores de NLP pensados para clasificar texto, no para redactar contenido completo. Ahí la sensación fue mucho mejor. Menos coste variable, menos sorpresas y más control. Cuando el objetivo es soporte básico, FAQs o filtrado comercial, esta capa suele ser suficiente.
Además, desde el punto de vista de mantenimiento, es mucho más agradecida. Si ves que un bot falla con la intención “horarios”, no reescribes medio sistema: añades ejemplos mejores, ajustas entrenamiento y listo.
3. Búsqueda semántica
También probé enfoques de búsqueda semántica para localizar el bloque de contenido más cercano a la consulta del usuario. Esto tiene bastante sentido cuando el sitio ya tiene documentación o FAQs razonablemente bien estructuradas. No siempre necesitas que el bot “sepa” responder. Muchas veces basta con que sepa encontrar bien la respuesta que ya existe.
La búsqueda semántica me parece muy útil cuando el volumen de contenido es alto, pero tiene una condición importante: si la base de contenidos está desordenada, el chatbot no va a arreglar ese problema por arte de magia. Primero hay que ordenar la casa.
4. Plataformas como Wit.ai
Una de las plataformas con las que más cómodo me sentí para este tipo de enfoque fue Wit.ai. No porque sea perfecta, sino porque para un caso de uso basado en intents, entidades y clasificación de mensajes, encaja bastante mejor que una API de texto generativo puro.
Con Wit.ai pude entrenar intenciones reales, probar frases de usuarios normales y conectar la lógica con WordPress sin caer en el bucle de “más prompt, más contexto, más coste”. Si quieres montar esa parte técnica paso a paso, ya dejé una guía específica sobre cómo conectar Wit.ai con WordPress.
Lo que entendí al trabajar con pymes: no necesitan una IA infinita
Esta fue probablemente la lección más útil de todas. La mayoría de pymes no necesitan un chatbot que filosofe, redacte como un comercial senior ni responda preguntas abiertas sobre cualquier tema. Necesitan resolver con claridad unas cuantas situaciones muy concretas:
- horarios, cobertura, servicios o tarifas base,
- dudas repetidas de preventa,
- preguntas frecuentes de soporte,
- captación de leads con un mínimo filtro previo,
- derivación rápida a la página o formulario adecuado.
Cuando entiendes eso, el chatbot deja de ser un juguete y empieza a parecer una pieza de UX y de negocio. Y entonces ya no te obsesionas con que “parezca ChatGPT”, sino con que sea útil, controlable y rentable.
Cómo crear un chatbot IA en WordPress sin pagar tokens por uso
Si hoy tuviera que montarlo desde cero para una web WordPress, este sería mi enfoque.
1. Empiezo por las preguntas reales, no por la API
Suena básico, pero aquí es donde más se falla. Yo empezaría revisando emails, formularios, chats antiguos, llamadas resumidas, consultas por WhatsApp o tickets de soporte. Quiero ver cómo pregunta la gente de verdad.
Un ejemplo muy típico en una pyme de servicios sería algo así:
- “¿trabajáis en mi ciudad?”
- “¿cuánto cuesta más o menos?”
- “¿puedo pedir una demo?”
- “¿en cuánto tiempo lo tenéis?”
Con 20 o 30 preguntas reales ya puedes detectar patrones bastante claros.
2. Agrupo por intención y no por frase exacta
Aquí suelo crear una estructura mínima de intents: precio, horarios, servicios, demo, contacto, soporte, envios, devoluciones o lo que toque según el proyecto.
Esto parece muy simple, y precisamente por eso funciona. Si el usuario escribe diez formas distintas de pedir lo mismo, quiero que el sistema las interprete dentro del mismo grupo.
3. Entreno el NLP con lenguaje real
No usaría frases artificiales. Usaría expresiones tal y como las escribe la gente. Errores, abreviaturas, dudas a medias y lenguaje coloquial incluidos. Cuanto más real es el entrenamiento, menos falla luego el chatbot en producción.
Si te interesa acelerar ese paso, en WitflowAI tengo también un pack base de intents para chatbot WordPress que sirve bastante bien como punto de partida para MVPs.
4. Respondo desde WordPress con contenido controlado
Esta parte para mí es clave. La salida del chatbot no debería depender de que un modelo improvise. Debería salir de una lógica clara dentro del propio WordPress:
- respuesta breve revisada,
- enlace a una página concreta,
- CTA a demo o contacto,
- o paso siguiente definido por negocio.
Por ejemplo, si detecto intención de precio, prefiero devolver una respuesta corta y llevar al usuario a precios antes que generar tres párrafos ambiguos en el chat.
5. Diseño bien el fallback
Un chatbot bueno no es el que responde siempre. Es el que sabe cuándo no debe arriesgarse. Si la intención no está clara, prefiero que haga una de estas cosas:
- pedir al usuario que reformule,
- mostrar opciones rápidas,
- enlazar a documentación,
- o derivar a contacto o demo.
Ese punto reduce muchísimo el ruido y evita respuestas que quedan “bonitas” pero no ayudan.
Comparativa real: chatbot por tokens frente a chatbot controlado
| Enfoque | Ventajas | Inconvenientes |
|---|---|---|
| API generativa con pago por tokens | Arranque rápido, lenguaje natural muy flexible, respuestas abiertas | Coste variable, menos control, más dependencia externa, más revisión |
| Intents + NLP + respuestas controladas | Coste previsible, mejor control, más sencillo para pymes y agencias | Menos útil para conversaciones muy abiertas o razonamiento complejo |
| Búsqueda semántica sobre contenido del sitio | Muy buena cuando ya hay documentación útil, aprovecha contenido existente | Depende mucho de la calidad y estructura de la base de contenidos |
Casos en los que este enfoque funciona especialmente bien
En mi experiencia, un chatbot WordPress sin pago por tokens encaja muy bien en estos escenarios:
- Webs corporativas que reciben siempre las mismas preguntas sobre servicios, cobertura o contacto.
- Academias con dudas repetidas sobre precios, horarios, modalidad o matrícula.
- WooCommerce con preguntas frecuentes de envíos, devoluciones, stock o plazos.
- Agencias WordPress que necesitan paquetizar el servicio sin convertir el coste mensual en una incógnita.
De hecho, para agencias me parece uno de los encajes más claros. Puedes vender instalación, entrenamiento inicial, optimización y mantenimiento con bastante más tranquilidad que si cada cliente depende de un consumo imprevisible. Ese enfoque es exactamente el que explico en la sección de plugins IA para agencias WordPress.
Cuándo no lo recomendaría
No vendería este enfoque como solución universal. Si necesitas conversaciones muy abiertas, razonamiento complejo, respuestas muy dinámicas o síntesis de información cambiante en tiempo real, un sistema controlado por intents puede quedarse corto.
Y tampoco intentaría solucionar con chatbot un problema de base documental. Si el sitio no tiene bien explicados sus servicios, precios, procesos o FAQs, el chatbot solo va a heredar ese desorden.
Por qué acabé desarrollando mi propio plugin para WordPress
Después de muchas pruebas llegué a una conclusión bastante simple: el problema no era solo técnico, era también de producto. Hacía falta una forma de llevar este enfoque a WordPress sin montar cada vez una integración distinta, sin depender de veinte piezas sueltas y sin obligar al cliente a entender NLP, intents o flujos internos para poder usarlo.
De ahí salió WitflowAI. No como un “plugin mágico” que promete resolverlo todo, sino como el resultado lógico de todo ese trabajo previo: probar APIs de pago, pelearme con costes por tokens, revisar límites de GDPR, afinar flujos por intents y ver qué encaja de verdad en webs pequeñas y medianas.
Dentro de ese trabajo, uno de los primeros enfoques que empaqueté fue el de un AI Chatbot para WordPress sin cuotas mensuales: una forma más práctica de resolver soporte y captación básica desde WordPress, con control sobre respuestas y sin necesidad de pagar por uso en cada conversación.
La idea nunca fue hacer “más IA” por hacerla. La idea fue simplificar la parte útil y quitar fricción en la parte absurda.
Mi recomendación honesta
Si estás valorando poner un chatbot IA en WordPress, yo no empezaría preguntando qué modelo está de moda. Empezaría preguntando qué conversaciones quieres automatizar y cuánto control necesitas sobre lo que se responde.
Si el patrón principal de tu web son preguntas repetidas, soporte básico, FAQs, derivaciones o captación de leads, seguramente puedes montar algo útil sin pagar tokens por uso. Y, en muchos casos, te va a funcionar mejor que una solución generativa más cara y más difícil de gobernar.
Conclusión
Después de probar varias opciones, mi sensación como desarrollador WordPress es bastante clara: para muchas pymes, la mejor IA no es la que más impresiona en una demo, sino la que reduce trabajo real sin disparar costes ni complicar la arquitectura.
Por eso sigo prefiriendo un enfoque basado en intents, NLP útil, búsqueda cuando aporta valor y respuestas controladas desde WordPress. Es más sobrio, sí. Pero también más honesto, más mantenible y más rentable.
Si quieres ver ese enfoque ya aterrizado en WordPress, puedes echar un vistazo a WitflowAI y probar la versión gratuita para validar si encaja con tu proyecto antes de complicarte más de la cuenta.
Preguntas frecuentes
¿Se puede tener un chatbot IA en WordPress sin pagar tokens por uso?
Sí. Si el enfoque se basa en detectar intenciones, clasificar bien el mensaje y responder con lógica controlada desde WordPress, no necesitas pagar por cada conversación como ocurre con muchas APIs generativas.
¿Entonces un chatbot por intents es mejor que un LLM?
No en todos los casos. Es mejor cuando el problema real son preguntas repetidas, FAQs, soporte básico o derivación comercial. Si necesitas razonamiento abierto o generación compleja, seguramente no será suficiente por sí solo.
¿Wit.ai sigue teniendo sentido para WordPress?
Sí, especialmente cuando quieres clasificar intenciones y entidades sin montar una arquitectura pesada. Para proyectos WordPress pequeños y medianos sigue siendo una opción práctica para crear un chatbot útil y controlado.
¿Este enfoque encaja para agencias?
Mucho. De hecho, una de sus mayores ventajas es que permite presupuestar mejor, mantener margen y desplegar una solución repetible en varias webs WordPress sin depender de un gasto variable por uso.