Crea un Asistente de IA Sin Código: El Flujo de Trabajo Completo

Hace seis meses, probablemente pensabas que construir un asistente de IA significaba contratar a un ingeniero de ML y pasar tres meses en infraestructura. Eso ya no es cierto. El panorama de los asistentes de IA sin código ha madurado hasta el punto en que un fundador solitario, un gerente de producto o un líder de operaciones puede implementar un asistente de nivel de producción que maneja trabajo real de clientes, ¡todo sin tocar una terminal!

El truco: saber qué herramienta usar para cada trabajo es más difícil que nunca. Zapier, Make, Bubble, la API de Claude (en contextos sin código como Retool), Firebase y una docena más afirman hacer lo mismo. No lo hacen. He construido asistentes de IA en cinco pilas tecnológicas diferentes en AlgoVesta, he visto dos fallar por completo y he visto tres escalar para manejar miles de interacciones diarias. La diferencia entre los fracasos y los éxitos no fue la herramienta, sino la comprensión del compromiso real entre la facilidad de uso, la personalización, el costo y la confiabilidad.

Esta es una guía completa para construir un asistente de IA para tu negocio en 2025. No es una reseña de herramientas. Es un flujo de trabajo real.

Lo que “Asistente de IA” Realmente Significa en un Contexto Sin Código

Antes de elegir una herramienta, define qué estás construyendo realmente. “Asistente de IA” es lo suficientemente amplio como para ser inútil. Un asistente que responde preguntas frecuentes no tiene casi nada en común con un asistente que dirige tickets de soporte al cliente, que no tiene casi nada en común con un asistente que genera informes personalizados.

Para este artículo, nos centramos en asistentes que:

• Toman entradas de un cliente, usuario o parte interesada interna
• Procesan esa entrada a través de un LLM (Claude, GPT-4o o similar)
• Acceden a datos externos (tu base de datos, CRM, base de conocimientos o API)
• Devuelven una salida relevante (respuesta, acción o decisión)
• Registran interacciones para cumplimiento o depuración

Esa es la mayoría de los casos de uso comerciales reales. Los bots de preguntas frecuentes entran aquí. La automatización del soporte al cliente también. La calificación de leads también. La búsqueda de documentos internos también.

Lo que esto no cubre: agentes completamente autónomos que toman decisiones sin revisión humana, o flujos de trabajo complejos de varios pasos que requieren lógica de ramificación a través de docenas de condiciones. Esos necesitan código personalizado o plataformas de nivel empresarial (Salesforce Einstein, flujos de trabajo de HubSpot a escala, etc.).

Los Tres Enfoques Arquitectónicos (y Cuándo Funciona Cada Uno)

Cada asistente de IA sin código cae en uno de tres patrones. Tu elección aquí determina qué herramientas funcionarán realmente para ti.

Patrón 1: LLM + Contexto + Respuesta Directa

El patrón más simple. El usuario envía una pregunta o solicitud → tu sistema recupera el contexto relevante (de una base de conocimientos, base de datos o API) → envías la entrada del usuario + contexto a un LLM → devuelves la respuesta del LLM directamente.

Cuándo usar esto: Automatización de preguntas frecuentes, búsqueda de documentación, soporte al cliente para preguntas sencillas, recomendaciones de contenido, calificación básica de leads.

Ejemplo: Bot de preguntas frecuentes de soporte al cliente

Usuario pregunta: “¿Puedo actualizar mi plan Básico a mitad de mes?”

Pasos del sistema:

1. Busca en tu base de conocimientos documentos sobre actualizaciones de planes
2. Recupera los 2 o 3 artículos más relevantes
3. Envía a Claude: “Basándote en este contexto, responde a la pregunta del cliente: ¿Puedo actualizar mi plan Básico a mitad de mes?” + los artículos recuperados
4. Devuelve la respuesta de Claude al usuario

Esto es RAG (Generación Aumentada por Recuperación) en su forma más simple. El término suena complejo. El patrón es trivial.

Calidad de salida típica: 85–92% de las preguntas respondidas correctamente al primer intento, dependiendo de qué tan bien esté organizada tu base de conocimientos. El 8–15% restante necesita aclaración, involucra casos extremos o requiere un humano.

Patrón 2: LLM + Contexto + Extracción + Acción

El usuario envía una solicitud → el sistema recupera el contexto → lo envías a un LLM con instrucciones explícitas para extraer datos estructurados → el LLM devuelve JSON o campos → tu sistema realiza una acción basada en esa extracción (crear un registro, enviar un correo electrónico, actualizar una base de datos).

Cuándo usar esto: Enrutamiento de tickets, automatización de formularios, entrada de datos en CRM, programación, procesamiento de facturas, cualquier tarea donde necesites que el LLM tome una decisión que desencadene una acción.

Ejemplo: Enrutamiento automático de tickets de soporte

El cliente envía: “Mi integración de API se rompió ayer por la mañana. Estoy recibiendo errores 500 en cada llamada.”

Pasos del sistema:

1. Envía el mensaje a Claude con instrucciones: “Extrae la categoría del problema (facturación, técnico, solicitud de función, cuenta, otro), urgencia (crítica, alta, media, baja) y el producto principal mencionado. Devuelve como JSON.”
2. Claude devuelve: {"category": "technical", "urgency": "critical", "product": "API"}
3. Tu sistema utiliza ese JSON para: Crear un ticket, asignarlo al equipo técnico, establecer la prioridad como crítica, etiquetarlo automáticamente como “API”
4. Envía una confirmación al cliente

Por qué esto importa: No le pides al LLM que realice la acción. Le pides que entienda la entrada lo suficiente como para extraer los campos correctos, y luego tu herramienta sin código utiliza esos campos para desencadenar la lógica comercial real. Aquí es donde vive el 80% de la automatización empresarial.

Calidad de salida típica: 88–96% dependiendo de qué tan bien definidas estén tus categorías. El paso de extracción es más confiable que las respuestas abiertas porque el LLM está limitado a elegir de una lista.

Patrón 3: Flujo de Trabajo LLM de Múltiples Pasos con Retroalimentación

El usuario envía la entrada → el LLM toma una decisión o genera un borrador → el sistema se lo muestra a un humano o espera aprobación → al aprobarse, se ejecuta otro paso del LLM, o un humano se encarga.

Cuándo usar esto: Decisiones de alto riesgo (revisiones de contratos, recomendaciones de contratación, excepciones de políticas), aseguramiento de calidad en respuestas automatizadas, escenarios donde el costo del error es alto.

Ejemplo: Calificación de leads con revisión humana

Un nuevo lead completa un formulario → El primer paso del LLM extrae el tamaño de la empresa, la industria, el presupuesto, el caso de uso → El segundo paso del sistema verifica si el lead cumple con los criterios de tu ICP (perfil de cliente ideal) → Si está calificado, se pone en cola para contacto de ventas; si no, se asigna a una secuencia de nutrición → Un gerente de ventas revisa los casos límite antes de que se descarten.

Calidad de salida típica: 92–98% porque tienes un humano en el bucle, pero el LLM maneja el 70–80% de las decisiones automáticamente.

Comparación de Pilas Tecnológicas: Casos de Uso Específicos

Ahora que sabes qué patrón necesitas, así es como las principales plataformas sin código realmente se comparan. Me enfoco en las herramientas que he usado en producción en AlgoVesta o he probado extensamente, no en una reseña superficial.

Traducción del mundo real: Si estás construyendo un asistente orientado al cliente y necesitas una UI personalizada, Bubble o Retool. Si estás automatizando flujos de trabajo internos y ya usas herramientas SaaS, Make. Si necesitas el mejor rendimiento de LLM y tienes un presupuesto básico de desarrollo web, API de Claude + Vercel (en realidad bajo código, no sin código). Si ya estás en Salesforce, Einstein, pero prepárate para pagar más y obtener menos personalización.

Paso a Paso: Construyendo Tu Primer Asistente

Vamos a repasar la construcción de un asistente de soporte al cliente usando Make + Claude. Esto combina el Patrón 1 + Patrón 2: recuperar contexto, obtener una respuesta, extraer datos de enrutamiento y crear un ticket.

Paso 1: Define Tu Fuente de Entrada

¿Dónde recibe el asistente las solicitudes? Opciones:

• Un formulario en tu sitio web (Typeform, Jotform)
• Correo electrónico (a través de Zapier o Make)
• Un canal de Slack
• Un widget de chat web dedicado
• Tu sistema de helpdesk (Zendesk, Freshdesk, etc.)

Para este ejemplo, asumimos un formulario en tu sitio web. Un cliente completa “¿Cuál es tu problema?” y presiona enviar.

Paso 2: Recuperar Contexto (Búsqueda en Base de Conocimientos)

Necesitas que tu base de conocimientos sea buscable. Opciones:

• Google Docs + una API de búsqueda
• Notion + API de Notion
• Airtable + API de Airtable
• Una herramienta dedicada de base de conocimientos (Slite, GitBook, etc.)

Supongamos que usas Notion. En Make, agrega un paso de búsqueda de Notion que tome la entrada del cliente y devuelva los 3 documentos más relevantes. La integración de Notion de Make maneja esto automáticamente.

Paso 3: Enviar a Claude con el Contexto Recuperado

Aquí está la arquitectura real del prompt:

Eres un asistente de soporte al cliente para [Nombre de la Empresa]. 

Basándote en la siguiente documentación, responde la pregunta del cliente de manera directa y útil.

Documentación:
{retrieved_docs}

Pregunta del cliente: {customer_input}

Si no puedes responder basándote en la documentación, di: "No tengo información sobre eso en nuestra documentación. Permíteme conectarte con un miembro del equipo."

Responde en menos de 3 frases.

En Make, este es un solo paso “Llamar a la API de Claude”. Estás pasando tres variables: {retrieved_docs}, {customer_input}, y un prompt del sistema fijo.

Costo a escala: Claude Sonnet 4 (actual a marzo de 2025) cuesta aproximadamente $0.003 por cada 1K tokens de entrada y $0.015 por cada 1K tokens de salida. Una interacción de soporte típica: ~800 tokens de entrada (mensaje del cliente + extractos de la base de conocimientos), ~150 tokens de salida. Costo por interacción: ~$0.004. Con 1,000 interacciones/mes, eso son ~$4.

Paso 4: Extraer Datos de Enrutamiento (Opcional)

Si quieres que el asistente también enrute el ticket:

Extrae lo siguiente del mensaje del cliente en formato JSON:
{
  "issue_category": "uno de: billing, technical, feature_request, account, other",
  "urgency": "uno de: critical, high, medium, low",
  "product_mentioned": "extrae el nombre del producto o 'general'"
}

Mensaje del cliente: {customer_input}

El LLM devuelve JSON estructurado. Make pasa eso a tu sistema de ticketing (Zendesk, Freshdesk, Hubspot).

Paso 5: Crear un Ticket y Responder

Con los datos extraídos, Make:

• Crea un ticket en tu helpdesk con la categoría, urgencia y etiquetas de producto
• Envía la respuesta de Claude al cliente
• Registra la interacción (entrada del cliente, respuesta de IA, datos de enrutamiento) en una base de datos para referencia futura
• Si la urgencia = “crítica”, envía una alerta a tu equipo de soporte de guardia

Tiempo total de configuración: 2–4 horas si estás familiarizado con Make y la API de tu helpdesk. 6–10 horas si eres nuevo en ambos.

Cuándo (y Por Qué) Falla el No-Code: Fallos Reales y Soluciones

He visto tres asistentes de IA en producción construidos con herramientas sin código fallar por completo. Esto es lo que sucedió y qué hicimos en su lugar.

Fallo 1: El Problema de la Deriva de la Base de Conocimientos

Lo que sucedió: Construimos un asistente de preguntas frecuentes en Make + Claude usando Notion como base de conocimientos. Durante el primer mes, la precisión fue del 87%. Al tercer mes, cayó al 61%. El problema: nuestro equipo de producto actualizó la documentación en Notion, pero esas actualizaciones no se reflejaron en las respuestas del asistente.

Causa raíz: La integración de Notion de Make busca documentos, pero la API de búsqueda de Notion no siempre devuelve la última versión de un documento si se ha actualizado recientemente. Hay un retraso de 12 a 24 horas.

La solución: Cambiar a una herramienta dedicada de base de conocimientos (usamos GitBook) con búsqueda en tiempo real garantizada. Alternativamente, implementar un trabajo de sincronización semanal que exporte tus documentos de Notion a una base de datos y busque en esa base de datos en su lugar.

Fallo 2: La Explosión del Presupuesto de Tokens

Lo que sucedió: Construimos un asistente interno para nuestro equipo de trading usando Retool + Claude Opus. Funcionó maravillosamente pero costaba $1.80 por consulta. A escala (nuestro equipo realiza ~300 consultas/día), eso son $540/día o $162,000/año.

Causa raíz: Estábamos usando Claude Opus para todas las consultas, incluso las simples que podían ser manejadas por Sonnet. No estábamos indicando al LLM que fuera conciso; algunas respuestas eran de 2,000 tokens cuando 300 habrían sido suficientes.

La solución: Implementar un sistema escalonado. Dirigir consultas simples a Sonnet (más barato, más rápido). Dirigir consultas complejas a Opus. Agregar una instrucción “sé conciso” a cada prompt. El costo se redujo a $0.14 por consulta.

Fallo 3: La Trampa de la Alucinación de Contexto

Lo que sucedió: Construimos un asistente de calificación de leads que extraía el tamaño del acuerdo de los formularios de admisión de clientes. Claude extraía con confianza tamaños de acuerdo que no existían en el formulario. Ejemplo: un cliente escribió “somos una pequeña agencia” y el asistente extrajo “deal_size: $500,000” (alucinado).

Causa raíz: El prompt no decía explícitamente “extrae solo la información presente en el formulario”. El LLM infería basándose en el tamaño de la empresa y otro contexto, y luego presentaba la inferencia como un hecho.

La solución: Cambiar el prompt a: “Extrae el tamaño del acuerdo SÓLO si se indica explícitamente en el formulario. Si no se indica, devuelve null.” Prueba el prompt con 20 ejemplos reales antes de implementarlo. Agrega un paso de revisión humana para todos los valores extraídos en la primera semana.

El Marco de Decisión: Eligiendo Tu Herramienta

Usa este marco para elegir la herramienta adecuada sin perder tiempo en demostraciones.

Hazte estas preguntas en orden:

1. ¿Está orientado al cliente o es interno? Si está orientado al cliente, necesitas una herramienta con buena UI (Bubble, Retool, una construcción personalizada). Si es interno, Make o Zapier está bien.
2. ¿Ya usas una plataforma específica? Si ya estás en Salesforce, prueba Einstein primero. Si ya usas Make, quédate en Make. Cambiar de herramienta para una función pequeña cuesta más que la herramienta en sí.
3. ¿Cuán compleja es la lógica? Si son 2–3 pasos, Zapier. Si son 5–10 pasos, Make. Si son más de 10 pasos o requiere código personalizado, constrúyelo (Vercel + API de Claude).
4. ¿Cuánto cuesta el fracaso? Si un error podría costarte un cliente, necesitas revisión humana (Patrón 3). Si solo es una respuesta incorrecta de preguntas frecuentes, puedes manejar el Patrón 1.
5. ¿Cuál es tu presupuesto? Zapier y Make son los más baratos para empezar ($10–$50/mes). Retool está en el rango medio ($600+). Las construcciones personalizadas tienen un alto costo inicial pero un bajo costo por consulta a escala.

Árbol de decisión:

• Herramienta interna, flujo de trabajo simple → Make o Retool
• Orientado al cliente, simple, bajo riesgo → Bubble o Make
• Orientado al cliente, alto riesgo → Constrúyelo (Vercel + API de Claude)
• Integración CRM → Salesforce Einstein o Make conectado a tu CRM
• No estoy seguro, quiero probar → Make (menor fricción)

La Realidad de la Seguridad y el Cumplimiento

Antes de implementar, entiende qué sucede con tus datos.

Datos en tránsito: Cuando envías datos del cliente a Claude o GPT-4o, Anthropic y OpenAI los ven (a menos que uses Claude con retención cero de datos, lo que requiere un plan empresarial). Esto está bien para consultas no sensibles. Para PII o datos financieros, ya sea: (a) usa un LLM local (Mistral 7B, Llama 3, etc. en tu propia infraestructura), o (b) implementa enmascaramiento de datos (elimina nombres, correos electrónicos, etc. antes de enviarlos al LLM).

Datos en reposo: Si estás registrando interacciones en Make o Retool, se almacenan en la base de datos de esa herramienta. Los servidores de Make cumplen con GDPR. Los de Retool también. Pero verifica sus políticas específicas de residencia de datos si operas en la UE o bajo otras regulaciones.

Enfoque práctico: Para asistentes de soporte al cliente en preguntas públicas, envía los datos directamente a Claude. Para datos sensibles (información de salud, registros financieros, datos de empleados), enmascáralos antes de enviarlos o usa un modelo implementado localmente.

Tus Primeros 30 Días: Qué Construir Realmente

No empieces construyendo el asistente de tus sueños. Comienza eligiendo un flujo de trabajo pequeño y específico y lánzalo.

Día 1–2: Elige tu caso de uso

Elige algo que:

• Maneje 50+ solicitudes repetitivas al mes (necesitas suficiente volumen para medir el impacto)
• Tenga una métrica de éxito clara (por ejemplo, “% de solicitudes respondidas sin escalada humana”)
• Sea lo suficientemente bajo riesgo como para que una tasa de error del 10% no cause daño

Ejemplo: Preguntas frecuentes de clientes sobre tus preguntas más comunes. O enrutamiento de solicitudes internas (informes de gastos, solicitudes de tiempo libre, etc.).

Día 3–5: Construye un prototipo

Usa Make o Bubble. No pienses demasiado en ello. Comienza con el Patrón 1 (LLM + contexto) y mide la precisión en 20 ejemplos reales.

Día 6–14: Prueba con usuarios reales

Implementa el asistente para el 10% de tu audiencia. Mide:

• Precisión de la respuesta (¿dio la IA la respuesta correcta?)
• Tasa de escalada (% de solicitudes que necesitaron revisión humana)
• Tasa de resolución (% de solicitudes completamente resueltas por la IA)
• Satisfacción del usuario (calificación de 1–5)

Día 15–30: Itera

Si la precisión está por debajo del 75%, audita los fallos. ¿Es un problema de la base de conocimientos? ¿Un problema de prompt? ¿Un problema del modelo? Arregla una cosa a la vez, prueba de nuevo. Si la precisión está por encima del 85%, escala al 100% de los usuarios. Luego construye el siguiente flujo de trabajo.

Costo en esta fase: $0–$200 dependiendo de la herramienta y cuántas consultas ejecutes. Los costos de la API de LLM son mínimos para pruebas.

Lo Único que Debes Hacer Hoy

Elige las 20 preguntas principales de clientes que tu equipo respondió este mes. Cópialas en una hoja de cálculo. Junto a cada una, anota cuánto tiempo tomó responder. Si el tiempo total excede las 5 horas, tienes tu primer caso de uso de asistente. Crea una cuenta de Make o Bubble hoy (ambas tienen niveles gratuitos) y dedica 90 minutos a construir un prototipo que responda 5 de esas 20 preguntas. Aún no necesitas una precisión perfecta, solo necesitas pruebas de que la idea funciona. Si lo hace, has encontrado algo que vale la pena escalar.