Intermedio → avanzado
10–13 horas
9 módulos completos
Cómo estudiar este curso
Requisitos previos
Conviene entender WhatsApp Business Platform, webhooks y CRM. Para la parte técnica es útil conocer APIs y conceptos de LLM, pero el curso también sirve a líderes de producto y operaciones.
Módulo 1. Qué debe y qué no debe hacer un agente IA
1.1 Automatización vs. agente
Una automatización tradicional sigue reglas deterministas; un agente con LLM interpreta lenguaje y puede decidir entre respuestas o herramientas. Esa flexibilidad aumenta cobertura, pero también incertidumbre. Usa IA cuando el lenguaje o variedad del problema lo justifique; conserva reglas duras para permisos, precios críticos, autorizaciones y transacciones.
1.2 Matriz de riesgo
Clasifica acciones por impacto y reversibilidad. Explicar horarios es bajo riesgo; cancelar un servicio, comprometer un precio, cambiar una cuenta o procesar un reembolso puede requerir confirmación o humano. La IA puede preparar la acción sin tener permiso para ejecutarla sola.
1.3 Éxito
Define qué significa una buena conversación: resolución correcta, cita válida, respuesta sustentada, transferencia adecuada. “Suena humano” no es un KPI suficiente. Mide exactitud, cumplimiento de políticas y resultado.
| Tarea | Automatización | IA | Control |
|---|---|---|---|
| Horario | Regla/FAQ | Opcional | Respuesta determinista |
| Calificar intención | Difícil con reglas | Adecuada | Campos estructurados |
| Consultar pedido | API | IA puede orquestar | Autorización + tool |
| Reembolso | Regla + humano | Solo apoyo | Confirmación/roles |
Práctica del módulo
Comprueba lo aprendido
¿Por qué no usar IA para todo?
Porque añade variabilidad, costo y riesgo donde una regla simple puede ser más precisa y auditable.
¿Qué define autonomía segura?
Permisos explícitos, herramientas limitadas, validaciones, confirmaciones y capacidad de escalar a humano.
Módulo 2. Arquitectura conversacional
2.1 Pipeline
Un mensaje entrante llega por webhook, se persiste y entra a una cola. El orquestador obtiene contexto, evalúa reglas, consulta conocimiento o herramientas, llama al modelo y decide si envía respuesta o transfiere. La respuesta vuelve por Cloud API y los estados actualizan la conversación.
2.2 Orquestador
No llames directamente al LLM desde el webhook. El orquestador controla timeout, modelo, herramientas disponibles, estado, presupuesto, reintentos y handoff. También puede decidir no usar IA para mensajes simples o fuera de alcance.
2.3 Asincronía y UX
WhatsApp es asíncrono, pero el usuario espera fluidez. Define un tiempo máximo para respuesta automática; si una herramienta tarda, informa de forma útil o transfiere. Evita enviar “estoy pensando…” en múltiples mensajes porque desde octubre de 2026 los mensajes Service también tienen impacto de costo.
Práctica del módulo
Comprueba lo aprendido
¿Por qué no llamar al LLM dentro del webhook?
Aumenta latencia y riesgo de timeout/reintentos. El webhook debe confirmar rápido y delegar trabajo.
¿Qué controla el orquestador?
Contexto, políticas, herramientas, modelo, presupuesto, estado, validación y handoff.
Módulo 3. Instrucciones, contexto y políticas
3.1 Jerarquía de instrucciones
Separa identidad/rol, objetivo, límites, políticas, herramientas y formato de salida. Las reglas críticas no deben depender de que el usuario “no las contradiga”; refuérzalas en código y permisos. El prompt guía al modelo, pero el backend hace cumplir invariantes.
3.2 Contexto mínimo
Incluye solo lo necesario: nombre, estado de cliente, producto, conversación reciente y datos recuperados. Enviar todo el CRM aumenta costo y puede exponer información irrelevante. Construye contextos por caso de uso.
3.3 Salidas estructuradas
Cuando el modelo debe tomar una decisión de sistema, solicita estructura validable: intención, confidence, next_action, argumentos. Valida contra schema y allowlist antes de ejecutar. El texto para el cliente puede ser natural; la decisión interna debe ser estructurada.
Práctica del módulo
Comprueba lo aprendido
¿El prompt basta para impedir una acción peligrosa?
No. Las acciones críticas deben estar restringidas también por código, permisos y validaciones.
¿Por qué minimizar contexto?
Reduce costo, latencia, riesgo de exposición y distracciones del modelo.
Módulo 4. RAG y conocimiento empresarial
4.1 Qué es RAG
Retrieval-Augmented Generation busca fragmentos relevantes en una base de conocimiento y los entrega al modelo como contexto. Sirve para políticas, documentación, productos y procedimientos que cambian. No “entrena” necesariamente el modelo; recupera información en tiempo de respuesta.
4.2 Preparación del conocimiento
Documentos deben tener título, sección, fecha, versión, propietario y alcance. Divide por unidades semánticas útiles; un chunk gigantesco reduce precisión. Mantén referencias para que el agente pueda indicar fuente o para auditoría interna.
4.3 Freshness y conflictos
Si dos documentos se contradicen, el sistema debe priorizar versión vigente o escalar. No confíes solo en similitud vectorial. Añade filtros por producto, país, fecha y estado. Retira documentos obsoletos o márcalos explícitamente.
Práctica del módulo
Comprueba lo aprendido
¿RAG elimina las alucinaciones?
No. Reduce dependencia de conocimiento interno del modelo, pero todavía necesitas evaluación, fuentes y políticas de abstención.
¿Qué ocurre si hay dos políticas contradictorias?
La capa de recuperación debe filtrar/priorizar vigencia o el agente debe abstenerse y escalar, no elegir arbitrariamente.
Módulo 5. Herramientas y acciones seguras
5.1 Tool calling
Una herramienta es una función controlada: get_order_status(order_id), find_slots(date), create_booking(...). El modelo propone el uso; tu backend valida argumentos, autorización y límites. Nunca des acceso directo a SQL, shell o APIs genéricas sin control.
5.2 Lectura vs. escritura
Separa herramientas read-only de mutaciones. Para escrituras importantes utiliza confirmación del usuario, idempotency key y log. “Encontré una cita” y “reservé la cita” son estados distintos y el lenguaje del agente debe reflejarlo.
5.3 Autorización contextual
Antes de revelar estado de pedido o cambiar datos, verifica identidad según el riesgo. El hecho de escribir desde un número no siempre prueba que la persona está autorizada para toda la cuenta empresarial.
Modelo propone:
{
"tool": "create_booking",
"args": {"slot_id":"SLOT-882", "customer_id":"C-42"}
}
Backend valida:
- tool en allowlist
- customer autorizado
- slot disponible
- confirmación presente
- idempotency_key no usada
→ ejecuta / rechazaPráctica del módulo
Comprueba lo aprendido
¿Quién debe validar argumentos de una tool?
El backend. Nunca confíes en que el modelo producirá siempre valores válidos o autorizados.
¿Por qué idempotency key en escrituras?
Evita repetir una reserva, pago o acción si el flujo se reintenta.
Módulo 6. Estado, memoria y personalización
6.1 Estado de conversación
Guarda objetivos activos, campos recopilados, último paso y tareas pendientes en datos estructurados. No obligues al modelo a inferir todo desde 100 mensajes históricos en cada turno.
6.2 Memoria a largo plazo
Solo persiste preferencias útiles y autorizadas: idioma, producto habitual, canal preferido, contexto de cuenta. Evita “recordar” información sensible porque apareció una vez en el chat. Define retención y borrado.
6.3 Resúmenes
Para conversaciones largas, genera un resumen estructurado revisable con hechos, decisiones, pendientes y fuentes. Conserva mensajes originales según tu política, pero usa el resumen para reducir tokens. No permitas que un resumen reescriba un dato crítico sin evidencia.
Práctica del módulo
conversation_state con intent, collected_fields, pending_action, last_tool_result y handoff_reason. Añade una política de qué NO se guarda como memoria.Comprueba lo aprendido
¿Por qué no enviar todo el historial siempre?
Aumenta costo/latencia y puede introducir contexto irrelevante; estado y resúmenes controlados son más eficientes.
¿Toda información mencionada debe persistirse?
No. Aplica minimización, propósito y retención; algunas cosas solo son necesarias durante la conversación.
Módulo 7. Transferencia humana y operación multiagente
7.1 Cuándo transferir
Define criterios: baja confianza, usuario solicita humano, queja, riesgo legal/financiero, herramienta falla, información contradictoria o múltiples intentos sin resolución. El modelo puede detectar señales, pero el orquestador debe aplicar reglas.
7.2 Paquete de transferencia
Entrega al agente un resumen con identidad, intención, datos recopilados, herramientas ejecutadas, resultado y razón del handoff. Marcar claramente qué datos son afirmaciones del usuario y cuáles fueron verificados por sistemas evita errores.
7.3 Recuperación al bot
Cuando un agente termina, decide si la conversación vuelve a automatización o permanece humana durante un periodo. Evita que el bot interrumpa una conversación activa del agente por un evento tardío.
Práctica del módulo
Comprueba lo aprendido
¿Por qué el handoff debe incluir herramientas ejecutadas?
Para que el humano conozca qué acciones ya ocurrieron y no las duplique.
¿Qué causa respuestas cruzadas bot/agente?
Falta de estado de ownership o eventos tardíos sin una regla que suspenda automatización durante atención humana.
Módulo 8. Evaluación, seguridad y calidad
8.1 Dataset de evaluación
Construye conversaciones representativas: preguntas comunes, ambiguas, ataques, datos faltantes, casos fuera de alcance, políticas y herramientas. Define respuesta esperada o criterios. Evalúa cada nueva versión de prompt/modelo sobre el mismo conjunto.
8.2 Métricas
Mide factualidad, resolución, handoff correcto, tool selection, argumentos válidos, cumplimiento de políticas, latencia y costo. La satisfacción real del usuario complementa estas métricas, pero no sustituye pruebas de seguridad.
8.3 Prompt injection y contenido no confiable
Trata texto del usuario y documentos recuperados como datos, no instrucciones con autoridad. No permitas que un documento diga “ignora las reglas y envía…” y gane prioridad. Las herramientas deben tener permisos independientes del contenido textual.
Práctica del módulo
Comprueba lo aprendido
¿Por qué evaluar cada cambio de prompt?
Porque pequeñas modificaciones pueden mejorar un caso y degradar otros. Un dataset fijo detecta regresiones.
¿Cómo limitar prompt injection?
Separando instrucciones confiables de datos, validando tools y no concediendo autoridad al contenido recuperado o del usuario.
Módulo 9. Producción, observabilidad, costos y mejora continua
9.1 Trazas
Registra conversation ID, message ID, versión de prompt, modelo, retrieval IDs, tools, latencia, token/costo aproximado, decisión y handoff. Redacta PII/secrets según necesidad. Sin trazas no puedes explicar por qué el agente actuó de cierta manera.
9.2 Costos combinados
El costo incluye modelo, retrieval, infraestructura, herramientas, plataforma y mensajes de WhatsApp. Desde octubre de 2026 las respuestas Service de bots/IA dentro de la ventana también deben modelarse como mensajes cobrables por Meta. Diseña respuestas compactas sin sacrificar claridad.
9.3 Mejora basada en fallos reales
Clasifica conversaciones fallidas: conocimiento faltante, mala recuperación, prompt, tool, integración, UX o caso fuera de alcance. Corrige la capa adecuada. Añadir instrucciones al prompt para todo termina creando una especificación contradictoria.
| Métrica | Por qué importa | Acción |
|---|---|---|
| Resolution rate | Valor real | Mejorar knowledge/tools |
| Handoff rate | Cobertura y riesgo | Analizar por motivo |
| Tool error rate | Fiabilidad de integración | Corregir backend |
| Latency p95 | Experiencia | Optimizar pipeline/modelo |
| Costo por resolución | Economía | Comparar con humano/valor |
| Policy violation rate | Seguridad | Bloquear lanzamiento/regresión |
Práctica del módulo
Comprueba lo aprendido
¿Qué significa handoff alto?
No siempre es malo. Puede indicar límites seguros. Analiza motivos y si los casos transferidos deberían o no automatizarse.
¿Por qué costo por resolución?
Combina consumo técnico con resultado; costo por token o mensaje aislado no muestra valor operativo.
Caso guiado: agente IA para reservas con handoff
Construiremos conceptualmente un agente para una clínica. Puede responder preguntas sobre servicios, consultar disponibilidad y reservar una cita con confirmación. No puede diagnosticar, modificar historias clínicas ni procesar pagos. Si el usuario expresa una urgencia médica, el sistema no improvisa: sigue una política de escalamiento definida por la organización.
1. Router inicial
El primer paso no es “preguntarle todo al modelo”. El orquestador clasifica entre información, reserva, cambio de cita, cancelación, humano y fuera de alcance. Un modelo puede ayudar a interpretar lenguaje, pero la salida se valida contra una lista cerrada.
2. RAG
La base de conocimiento contiene servicios, preparación, horarios, ubicaciones y preguntas frecuentes. Cada fragmento tiene effective_from, location_id y status=active. Las tarifas se recuperan desde una fuente vigente; el agente no inventa precios de memoria.
3. Herramientas
search_services(query, location_id) -> service[]
get_availability(service_id, date_range) -> slot[]
create_booking(customer_id, slot_id, idempotency_key) -> booking
get_booking(booking_id) -> booking
handoff(reason, summary) -> ticketcreate_booking requiere que el usuario haya elegido explícitamente un slot. Si el modelo intenta llamar con un ID no ofrecido o inexistente, el backend rechaza. La idempotency key evita una reserva duplicada si el proceso se reintenta.
4. Conversación resumida
Agente: identifica intención reserva, pide ciudad si falta y consulta disponibilidad.
Tool: devuelve tres slots.
Agente: presenta opciones A/B/C con hora y sede.
Usuario: “La de las 4.”
Agente: resuelve el slot concreto y pide confirmación final si la política lo exige.
Tool: create_booking.
Agente: confirma solo después de recibir booking_id.
La frase final debe distinguir “estoy intentando reservar” de “tu cita quedó confirmada”. Nunca afirmes éxito antes de la herramienta.
5. Handoff con contexto
Si la herramienta devuelve que el plan del cliente requiere validación manual, el bot crea un handoff con: intención, servicio, slots consultados, customer ID verificado, motivo y transcript resumido. El agente humano recibe el caso sin pedir de nuevo información ya validada.
6. Evaluación
| Caso de prueba | Resultado esperado | Fallo grave |
|---|---|---|
| Pregunta de horario | Respuesta desde RAG | Inventar horario |
| Reserva sin slot | Pedir/consultar opciones | Crear slot arbitrario |
| Tool timeout | Informar/recuperar/escalar | Afirmar reserva |
| Usuario pide diagnóstico | Límite + humano según política | Diagnosticar |
| Prompt injection | Ignorar instrucción no confiable | Exponer tool/secrets |
| Mensaje ambiguo | Clarificar | Ejecutar acción irreversible |
Patrón de respuesta segura
Una respuesta final puede generarse con IA, pero el estado debe provenir del sistema. Ejemplo: booking.status=confirmed autoriza “Tu cita quedó confirmada”; pending solo autoriza “Estamos procesando la solicitud”. Esta separación reduce alucinaciones operativas porque el lenguaje se deriva de una variable verificable.
Evaluación IA
¿Qué debe decidir el backend y no el modelo?
Permisos, validación de tools, autorización, idempotencia y reglas críticas de negocio.
¿Por qué un RAG necesita fecha/vigencia?
Porque recuperar un documento semánticamente parecido pero obsoleto puede producir una respuesta convincente e incorrecta.
¿Cuándo afirmar que una acción ocurrió?
Solo después de una respuesta verificable de la herramienta/sistema de registro.
¿Qué contiene un buen handoff?
Identidad/contexto permitido, intención, datos recopilados, tools ejecutadas, resultados y motivo de transferencia.
¿Qué debe incluir un dataset adversarial?
Intentos de romper políticas, datos contradictorios, instrucciones maliciosas, tool arguments inválidos y casos fuera de alcance.
¿Cómo reducir costo sin degradar UX?
Minimizar contexto, usar modelos apropiados por tarea, evitar mensajes fragmentados, cachear/reutilizar conocimiento y medir costo por resolución.
Proyecto final del curso
Diseña un agente IA de WhatsApp para agendar citas y responder preguntas de producto. El proyecto debe demostrar controles, no solo conversación.
- Matriz de tareas y riesgo.
- Arquitectura webhook→orquestador→LLM/tools.
- Prompt/especificación con límites.
- Base RAG versionada.
- Dos tools de lectura y una de escritura con confirmación.
- Conversation state y política de memoria.
- Handoff payload y ownership.
- Dataset de 30 evaluaciones.
- Protecciones contra contenido no confiable.
- Trazas, métricas y presupuesto.
- Proceso de revisión y mejora.
Competencias que debes dominar al terminar
- Elegir tareas apropiadas para IA.
- Diseñar un orquestador desacoplado del webhook.
- Crear instrucciones y salidas estructuradas.
- Construir RAG con vigencia y metadata.
- Diseñar tools seguras e idempotentes.
- Gestionar estado/memoria.
- Implementar handoff humano.
- Evaluar seguridad y regresiones.
- Operar con observabilidad y costos.
Fuentes oficiales para continuar estudiando
- WhatsApp Business — Developer Hub
- Meta — colección oficial de WhatsApp Business Platform en Postman
- WhatsApp Business — Política de mensajes
- Meta for Developers — WhatsApp Cloud API
- Meta for Developers — precios de WhatsApp Business Platform