Crea un Asistente de IA Funcional Sin Código. Aquí Tienes la Pila Tecnológica

Hace tres meses, un equipo de marketing de 7 personas en una empresa SaaS de tamaño medio construyó un asistente de IA para atención al cliente en dos semanas. Sin ingenieros. Sin código personalizado. Utilizaron Make (anteriormente Integromat) para la orquestación, Claude para la inteligencia y Zapier para el enrutamiento de datos. Manejó el 40% del volumen de soporte. La configuración costó menos de $200/mes en herramientas.

No empezaron así. Primer intento: ChatGPT envuelto en una interfaz web que alquilaron. Alucinó con las políticas de la empresa, se contradijo y hizo promesas que el equipo no podía cumplir. Segundo intento: un bot de soporte listo para usar que costaba $1,500/mes y no podía manejar el 30% de sus patrones de tickets.

La diferencia entre los enfoques fallidos y el que funcionó no fue la inteligencia, sino la estructura. Un asistente de IA no es solo un modelo que responde preguntas. Es un sistema que recupera el contexto correcto, formatea las respuestas para tus usuarios y transfiere a humanos en el momento exacto.

Este pilar te guiará a través de la construcción de ese sistema. No es teoría. No es «la IA está transformando el soporte». Son herramientas reales sin código. Patrones de flujo de trabajo reales. Dónde fallan. Cuándo actualizar. Qué hacen mal la mayoría de los equipos.

Lo que Realmente Necesita Hacer Tu Asistente de IA

Antes de elegir herramientas, define el alcance. La mayoría de los asistentes de IA empresariales fallan porque se les pide hacer demasiado sin suficiente estructura.

Empieza aquí: anota las 10 preguntas o casos de uso principales de los clientes que tu asistente manejaría. No «responder cualquier cosa sobre nuestro producto». Específico. «Los clientes preguntan por el estado del reembolso» o «los clientes necesitan restablecer su clave API».

Para cada caso de uso, define tres cosas:

• Entrada requerida: ¿Qué información necesita el asistente para responder correctamente? (Ejemplo: ID de cuenta del cliente, historial de compras pasadas, tickets de soporte actuales)
• Conocimiento requerido: ¿Qué contexto necesita el modelo? (Ejemplo: tu página de precios, documento de política de reembolso, documentación de la API)
• Acción de salida: ¿Qué debería suceder a continuación? (Ejemplo: devolver el estado del reembolso, crear un ticket de soporte, enviar un correo electrónico de confirmación)

Este inventario fuerza la claridad. Muchos equipos se dan cuenta a mitad de camino de que sus 3 casos de uso principales requieren acceso a sistemas internos (CRM, base de datos de facturación, plataforma de ticketing) que aún no han conectado. Mejor saberlo ahora.

A continuación, define los límites del alcance. Estas son las preguntas que tu asistente no debería responder:

• Cualquier cosa que requiera juicios de valor (negociaciones de precios, manejo de excepciones)
• Solicitudes de datos sensibles (información de otros clientes, registros financieros)
• Solicitudes fuera de tu dominio (asesoramiento fiscal, legal, recomendaciones de productos de la competencia)

Escribe un prompt del sistema que diga explícitamente «Si el usuario pregunta sobre [X], rechaza y explica por qué. Ofrece escalar a un humano». Esta única práctica reduce las tasas de alucinación en un 30-50% en implementaciones reales porque el modelo tiene límites claros.

La Pila Tecnológica Sin Código Que Realmente Funciona

Hay cientos de plataformas de asistentes de IA. La mayoría son caras ($500–$2,000/mes), opacas sobre cómo funcionan y rígidas en cuanto a personalización.

Una alternativa funcional: componer una pila a partir de herramientas especializadas. Cada herramienta hace una cosa bien. Las conectas.

Por qué funciona esta estructura: Cada herramienta es reemplazable. Si Pinecone se vuelve caro, cámbialo por Supabase. Si Make se vuelve limitante, pasa a n8n. No estás atado a las restricciones arbitrarias de un solo proveedor.

Costo total para un sistema funcional que atiende 500-2,000 interacciones de clientes/mes: $80–$250/mes. Esto incluye las llamadas a la API del LLM, la base de conocimiento y la plataforma de orquestación.

Paso a Paso: Construyendo Tu Primer Flujo de Trabajo

Construyamos un ejemplo real: un asistente de soporte al cliente que responde preguntas sobre reembolsos y escala las complejas a humanos.

Paso 1: Define el Flujo de Conversación

Mapea lo que sucede en cada punto:

Usuario envía mensaje
  ↓
Asistente recupera documentos relevantes de la base de conocimiento
  ↓
Asistente genera respuesta
  ↓
¿La respuesta requiere juicio humano?
  → Sí: crear un ticket de soporte + notificar al equipo
  → No: enviar respuesta al usuario

Esto suena obvio. Los equipos se lo saltan y terminan con asistentes que dan medias respuestas o hacen promesas que no pueden cumplir.

Paso 2: Prepara Tu Base de Conocimiento

Reúne los documentos que tu asistente necesita:

• Página de preguntas frecuentes (exportada como markdown o PDF)
• Documento de política de reembolso
• Página de precios
• Documentación del producto
• Problemas o limitaciones conocidos

Súbelos a Pinecone, Weaviate o Supabase Vector. Si nunca lo has hecho: la mayoría de las bases de datos vectoriales tienen tutoriales. El de Pinecone dura 10 minutos.

Prueba la recuperación manualmente. Hazle una pregunta a tu asistente y comprueba si realmente extrajo el documento correcto. Aquí es donde el 40% de las implementaciones de IA sin código fallan: la recuperación es débil, por lo que el asistente inventa cosas.

Paso 3: Escribe el Prompt del Sistema

Aquí es donde se fija el comportamiento. Un prompt vago = respuestas impredecibles. Un prompt estricto = comportamiento consistente.

Prompt del sistema malo:

Eres un asistente de soporte al cliente útil. Responde preguntas sobre nuestros productos y políticas.

Por qué falla: El modelo no tiene límites. Si un cliente pregunta «¿cuál es tu precio comparado con Competidor X?», el modelo podría inventar comparaciones. Si preguntan «¿puedes anular mi plazo de reembolso?», el modelo podría sugerir que es posible.

Prompt del sistema mejorado:

Eres un asistente de soporte al cliente para [Empresa]. Tu trabajo es responder preguntas sobre reembolsos, acceso a cuentas y problemas técnicos.

Instrucciones:
1. Usa ÚNICAMENTE la información de la base de conocimiento a continuación. No uses conocimiento externo.
2. Si el usuario pregunta sobre reembolsos, primero verifica el estado de su cuenta (mediante la consulta al CRM). Infórmale su estado específico.
3. Si el usuario pregunta sobre precios o comparaciones de productos, NO especules. Di: "Nuestros precios dependen de tu caso de uso. Te pondré en contacto con ventas."
4. Si el usuario te pide que anules una política de reembolso o hagas una excepción, rechaza amablemente y escala a [equipo de escalado].
5. Para cada respuesta, incluye una frase explicando qué sucede a continuación (ej. "Crearé un ticket para nuestro equipo" o "Deberías recibir un correo electrónico de confirmación en 2 minutos").

Base de conocimiento:
[inserta tus documentos aquí]

Si no puedes responder una pregunta con la información anterior, di: "No tengo esa información. La escalaré a nuestro equipo." Luego crea un ticket de soporte.

La segunda versión es más larga. También es un 60% más efectiva porque el modelo sabe exactamente qué está dentro y fuera de alcance.

Paso 4: Configura la Orquestación en Make (o Zapier/n8n)

Aquí es donde vive el flujo de trabajo. Este es el patrón real:

Disparador: Nuevo mensaje en Slack (o email, o formulario web)
  ↓
Acción 1: Extraer ID de cliente del mensaje (coincidencia de patrones o consulta)
  ↓
Acción 2: Consultar CRM para obtener datos del cliente (opcional pero potente)
  ↓
Acción 3: Enviar mensaje + contexto del cliente a la API de Claude
  ↓
Acción 4: Analizar respuesta de Claude para el indicador [ESCALAR]
  ↓
Si [ESCALAR]: Crear ticket + notificar al equipo
Si NO [ESCALAR]: Enviar respuesta al cliente

¿Por qué el indicador [ESCALAR]? Porque necesitas una forma para que el modelo diga «esto está fuera de mi alcance». En el prompt del sistema, dile a Claude que incluya [ESCALAR] al principio de su respuesta si necesita un humano. Luego, en Make, busca esa cadena.

Ejemplo:

Claude genera: "[ESCALAR] Este cliente está pidiendo una excepción de reembolso. Ha sido cliente durante 3 años. No estoy autorizado a aprobar excepciones." 

Make ve [ESCALAR], crea un ticket y envía la explicación al equipo de soporte.
El cliente recibe: "He escalado tu solicitud a nuestro equipo. Recibirás respuesta en 2 horas."

Paso 5: Configura una Interfaz Sencilla

No construyas un sitio web todavía. Empieza con lo que tienes:

• Slack: Si tus clientes ya están en un espacio de trabajo de Slack, los formularios nativos de Slack + la integración con Make = listo en una hora.
• Correo electrónico: Configura una dirección de correo de soporte dedicada. Zapier vigila la bandeja de entrada y dispara tu flujo de trabajo.
• Widget de chat web: Incrusta un widget conectado a Slack (Slackmoji, Orion o similar) en tu sitio web. El usuario chatea → va a Slack → tu flujo de trabajo lo maneja.

Los widgets de chat web cuestan $50–$200/mes. La integración nativa de Slack es gratuita. La integración por correo electrónico a través de Zapier es gratuita. Empieza barato, actualiza cuando lo necesites.

Cómo Manejar el Contexto y la Memoria

Una interacción única es fácil. Un asistente real necesita recordar la conversación.

Aquí es donde la mayoría de los enfoques sin código fallan. La solución: almacenar el historial de la conversación en una base de datos.

Patrón:

• Cada vez que un usuario envía un mensaje, guárdalo en una base de datos (Airtable, Supabase, incluso una Hoja de Cálculo de Google).
• Cuando el asistente necesite responder, recupera los últimos 5-10 mensajes de ese usuario.
• Incluye ese historial en la llamada a la API de Claude como contexto de la conversación.
• Guarda la respuesta de Claude en la base de datos.

Esto cuesta casi nada, pero hace que la conversación se sienta continua en lugar de aislada.

Ejemplo de llamada a la API con Make:

POST https://api.anthropic.com/v1/messages
{
  "model": "claude-opus",
  "max_tokens": 1024,
  "system": "[tu prompt del sistema aquí]",
  "messages": [
    {"role": "user", "content": "Perdí mi clave API"},
    {"role": "assistant", "content": "Puedo ayudarte a restablecerla. ¿Has iniciado sesión en tu cuenta?"},
    {"role": "user", "content": "Sí"}
  ]
}

Make puede construir esto automáticamente extrayendo las últimas 10 filas del historial de conversación de tu base de datos. Se tarda 5 minutos en configurar.

Cuándo Este Enfoque Falla

El sin código funciona hasta que deja de hacerlo. Conoce los límites:

Problema 1: Lógica de Datos Compleja

Si tu flujo de trabajo necesita consultar múltiples sistemas, procesar datos condicionalmente y tomar decisiones basadas en lógica de negocio, Make eventualmente se vuelve difícil de manejar. Escribirás 150 pasos y será inmanejable.

Solución: Mueve la lógica a un backend ligero (Node.js, Python, incluso una Google Cloud Function). Mantén Make simple: deja que Make orqueste, deja que el código maneje la lógica.

Problema 2: Latencia de Respuesta

Si tus clientes necesitan respuestas en menos de 2 segundos, los flujos de trabajo sin código (que encadenan múltiples llamadas a la API) podrían agotar el tiempo de espera. Con más de 500 usuarios concurrentes, la latencia se vuelve crítica.

Solución: Pasa a una plataforma especializada (como Voiceflow, Langchain o un backend personalizado). O optimiza implacablemente: almacena en caché las consultas a la base de conocimiento, precalcula embeddings, usa un LLM más rápido (Mistral 7B en lugar de Claude).

Problema 3: Límites de Ventana de Contexto

Claude Opus tiene 200K tokens de contexto. GPT-4o tiene 128K. Mistral 7B tiene 32K. Si tus conversaciones se vuelven largas o tu base de conocimiento es enorme, alcanzarás los límites.

Solución: Implementa una recuperación más inteligente. En lugar de volcar toda tu base de conocimiento en cada solicitud, consulta tu base de datos vectorial para obtener los 3-5 documentos más relevantes. Esto mantiene bajos los tokens y las respuestas rápidas.

Problema 4: Cumplimiento y Manejo de Datos

Si tus clientes están en industrias reguladas (finanzas, salud, legal), las políticas de manejo de datos de Make y Zapier podrían no cumplir con los requisitos de cumplimiento. Podrías necesitar infraestructura personalizada con residencia de datos garantizada.

Solución: Usa herramientas autoalojadas (n8n, bases de datos vectoriales de código abierto) o pasa a un backend que controles por completo.

Comparando Modelos para Tareas de Asistente

No todos los LLM son igualmente efectivos para asistentes empresariales. Esto es lo que realmente importa:

Qué elegir: Para la mayoría de los asistentes empresariales (soporte, calificación de ventas, conocimiento interno), Claude Sonnet 4 es el punto óptimo. Mejor seguimiento de instrucciones que GPT-4o, más barato que Opus, y la ventana de contexto de 200K significa que puedes incluir conversaciones completas más bases de conocimiento grandes.

Mistral se vuelve competitivo si manejas un alto volumen (10K+ interacciones/mes) y puedes tolerar tasas de alucinación ligeramente más altas. La diferencia de costo ($2/mes en 1K llamadas) importa a escala.

Evita Llama 3 para asistentes a menos que lo ejecutes localmente y el costo sea la prioridad absoluta. La ventana de contexto más pequeña y la mayor tasa de alucinación hacen que sea más difícil implementar barreras de seguridad.

Fallos Comunes y Cómo Evitarlos

Hemos construido y depurado suficientes sistemas de este tipo para saber dónde suelen fallar.

Fallo 1: La Base de Conocimiento Está Desactualizada

Actualizas tu página de precios. Tu asistente no lo sabe durante tres días porque nadie recordó volver a subir los documentos a Pinecone.

Solución: Configura la sincronización automática de documentos. Si tus documentos viven en Notion, usa la API de Notion + Make para extraer automáticamente las actualizaciones. Si están en un CMS, el mismo patrón. Una vez por semana, vuelve a incrustar y actualiza tu base de datos vectorial. Make hace esto en 10 pasos.

Fallo 2: El Asistente Responde Preguntas Que No Debería

Un cliente pregunta «¿puedes enviarme el precio de mi competidor?» El asistente alucina un sitio web y precios de la competencia.

Solución: Sé agresivo con los límites del prompt del sistema. Enumera categorías de preguntas específicas que el asistente NO debe responder. Agrega un filtro de recuperación: si la consulta coincide con ciertas palabras clave («competidor», «otra empresa», «alternativa a»), no consultes la base de conocimiento. Escala inmediatamente.

Fallo 3: Las Conversaciones se Confunden o Entran en Bucle

Las conversaciones de varios turnos fallan porque el historial de conversación no se está pasando correctamente a la API.

Solución: Registra cada llamada a la API. En Make o Zapier, agrega un paso que registre lo que estás enviando a Claude. Cada solicitud. Cada respuesta. Cuando las cosas fallan, revisa los registros. Por lo general, verás que el historial de conversación está vacío o mal formado.

Fallo 4: Las Escalaciones No Funcionan

El equipo de soporte nunca ve las solicitudes escaladas. Los clientes nunca reciben la notificación de que un humano se está haciendo cargo.

Solución: Prueba la ruta de escalada antes del lanzamiento. Crea una conversación de prueba que active [ESCALAR]. Verifica que (1) se crea un ticket, (2) se notifica al equipo correcto, (3) se le dice al cliente qué esperar. Haz esto 10 veces. La mayoría de los fallos están en la lógica de notificación, no en el asistente en sí.

Tu Plan de Implementación de 30 Días

No intentes construir el sistema perfecto desde el primer día. Lanza algo pequeño e itera.

Semana 1: Planificación y Configuración

• Define tus 5 casos de uso principales (30 min)
• Escribe los límites del alcance (30 min)
• Reúne los documentos de la base de conocimiento (2 horas)
• Regístrate en Pinecone, Make/Zapier, API de Claude (1 hora)

Semana 2: Base de Conocimiento y Prompt del Sistema

• Sube los documentos a Pinecone (1 hora)
• Prueba la recuperación manualmente (1 hora)
• Escribe e itera sobre el prompt del sistema (2 horas)
• Prueba el prompt del sistema contra tus 5 casos de uso (2 horas)

Semana 3: Orquestación y Pruebas

• Construye el flujo de trabajo de Make (4–6 horas)
• Conecta a tu interfaz (Slack o correo electrónico) (2 horas)
• Prueba 20 conversaciones manualmente (2 horas)
• Depura fallos (2 horas)

Semana 4: Refinamiento y Lanzamiento

• Revisa todos los fallos de la semana 3 (1 hora)
• Actualiza el prompt del sistema y la base de conocimiento (2 horas)
• Configura el monitoreo (registros, seguimiento de escalado) (2 horas)
• Lanza a un grupo de usuarios limitado (1 hora)
• Itera basándote en los comentarios (continuo)

Total: ~25 horas de trabajo enfocado. Puedes dividir esto entre 4 personas y terminar en una semana. O una persona durante un mes.

Qué hacer primero, hoy: Anota tus 5 preguntas de soporte principales. No temas generales. Preguntas específicas. Luego, para cada una, anota qué datos necesitaría el asistente para responderla correctamente. Este ejercicio de 30 minutos aclara más que una semana de planificación genérica.

Cuándo Actualizar Más Allá del Sin Código

Has construido un MVP. Está manejando el 30% de tu volumen de soporte. ¿Y ahora qué?

Actualiza a un backend personalizado cuando:

• Tus flujos de trabajo superen los 80 pasos en Make (se vuelven inmanejables)
• Necesitas tiempos de respuesta inferiores a 1 segundo de forma consistente (el sin código añade latencia)
• Estás gastando $500+/mes en herramientas de orquestación
• Tus requisitos de cumplimiento exigen residencia de datos que no puedes garantizar con herramientas SaaS
• Necesitas integrarte con sistemas que Make no soporta

En ese momento, pasa a Langchain (Python o TypeScript), despliega en tu propia infraestructura o en Replit/Modal, y construye a partir de ahí. Ya has demostrado el concepto. Ahora estás optimizando.

Pero he aquí la cuestión: el 80% de las empresas no necesitan esa actualización. El sin código funciona. Es más barato, más rápido de implementar y mantenible por no ingenieros. Úsalo a menos que tengas una razón específica para no hacerlo.