Última revisión: junio de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen C1000-180. Lee de arriba a abajo o salta a una sección.
Nuevo asistente; eligiendo el paradigma de autoría.
Construir con el editor de Acciones, no con la habilidad Dialog heredada. Las Acciones modelan conversaciones orientadas a tareas como pasos, condiciones y variables sin gestionar un árbol de nodos.
Por qué: Las Acciones son el modelo de autoría actual y recomendado de IBM; Dialog es heredado y más difícil de mantener. Los exámenes profesionales asumen un diseño con Acciones primero.
Decidir cómo dividir un dominio de soporte grande en unidades.
Definir una acción por cada objetivo discreto del usuario (restablecer contraseña, verificar saldo, reservar cita). Mantener las acciones con un único propósito y reutilizables.
Por qué: Las acciones de ámbito estrecho y orientadas a tareas son más fáciles de probar, analizar y mejorar que los flujos monolíticos que intentan manejar todo.
La entrada del usuario podría desencadenar varias acciones similares.
Habilitar la desambiguación para que el asistente presente un menú aclaratorio de acciones candidatas en lugar de adivinar.
Por qué: La desambiguación reduce los errores de acción incorrecta y revela la intención real del usuario, mejorando la tasa de finalización.
El asistente no entiende al usuario después de repetidos intentos.
Diseñar una ruta de "Ninguna acción coincide" / cualquier otra cosa con una respuesta aclaratoria y, después de N fallos, una escalada a un agente humano.
Por qué: Un fallback definido previene bucles sin salida y protege el CSAT; la falta de coincidencia no detectada es una de las principales causas de abandono.
La conversación excede la competencia del asistente o el usuario está frustrado.
Añadir un paso de conectar con el agente que transfiera a un servicio de atención al cliente (por ejemplo, Zendesk, Genesys, Salesforce) con el contexto de la conversación adjunto.
Por qué: Pasar la transcripción y las variables recopiladas al agente evita obligar al usuario a repetirse.
Los interesados quieren una voz de marca consistente en todas las respuestas.
Definir una persona y una guía de tono de antemano; redactar el texto de respuesta de manera consistente y reutilizar variaciones para evitar repeticiones robóticas.
Por qué: Un tono consistente genera confianza; mezclar frases formales e informales en las acciones resulta inconexo.
Un detalle requerido es ambiguo o falta en la frase del usuario.
Hacer una pregunta aclaratoria dirigida a través de un slot en lugar de asumir un valor predeterminado.
Por qué: La confirmación explícita de parámetros de alto riesgo (cantidad, cuenta, fecha) previene acciones incorrectas costosas.
Diseñar un nuevo flujo con muchos casos límite.
Crear primero el "camino feliz" de principio a fin, luego añadir la validación, las digresiones y las ramas de error.
Por qué: Construir casos límite antes del flujo principal lleva a acciones excesivamente diseñadas y difíciles de probar.
La acción necesita varias piezas de información antes de poder completarse.
Recopilar cada valor en su propio paso como un slot; el asistente solicitará los que aún no se hayan proporcionado y omitirá los ya suministrados.
Por qué: El llenado de slots basado en pasos maneja entradas desordenadas y multivalor sin ramificaciones manuales.
Un valor debe persistir después de que la acción actual termine.
Almacenarlo en una variable de sesión, no en una variable de paso/acción. Las variables de acción tienen un alcance limitado a la acción; las variables de sesión viven durante toda la conversación.
Por qué: Elegir el ámbito incorrecto es un error clásico: el valor desaparece cuando la acción se completa o no se comparte entre acciones.
Un paso pide al usuario que elija de un conjunto conocido y fijo.
Usar un tipo de respuesta de "opciones" con opciones definidas en lugar de texto libre, y mapear cada opción a un valor.
Por qué: Las opciones restringen la entrada, eliminan la ambigüedad de análisis y se renderizan como botones en los canales compatibles.
Un valor recopilado (correo electrónico, fecha, cantidad) puede estar mal formado.
Añadir una condición de validación en el paso; si es inválida, mantener al usuario en el paso con una indicación correctiva.
Por qué: La validación en el momento de la captura evita pasar datos incorrectos a las extensiones y a los pasos posteriores.
Los pasos posteriores solo deben ejecutarse para ciertos usuarios o valores.
Establecer condiciones de paso en variables ya recopiladas para que los pasos se omitan cuando su condición sea falsa.
Por qué: Las condiciones expresan ramificaciones sin duplicar acciones; el editor las evalúa de arriba abajo.
Múltiples acciones necesitan el mismo subflujo (por ejemplo, verificar identidad).
Factorizar la lógica compartida en una subacción y llamarla desde cada acción padre.
Por qué: Las subacciones mantienen la lógica de verificación DRY y consistente; duplicar pasos se desfasa.
El usuario hace una pregunta no relacionada a mitad del flujo ("¿cuáles son sus horarios?").
Permitir la digresión para que el asistente responda la pregunta secundaria y luego regrese a la acción interrumpida.
Por qué: Bloquear las digresiones impone un script rígido que frustra a los usuarios con solicitudes secundarias legítimas.
Necesidad de calcular o transformar un valor dentro de un paso.
Usar el lenguaje de expresiones integrado (por ejemplo, funciones de cadena y matemáticas en variables) en el paso o la respuesta.
Por qué: Las transformaciones ligeras pertenecen a las expresiones; recurrir a un webhook para matemáticas triviales es excesivo.
Una acción de seguimiento necesita un valor que el usuario dio anteriormente.
Referenciar la variable de sesión existente en lugar de volver a solicitarla.
Por qué: Volver a preguntar por datos conocidos se siente como un error; llevar el contexto hacia adelante es una característica distintiva de un buen flujo.
Un flujo debe detenerse o saltar a otra acción bajo una condición.
Usar "terminar la acción" o una transición de "ir a un paso en otra acción" para controlar el flujo explícitamente.
Por qué: Las transiciones explícitas evitan el paso inesperado al siguiente paso después de una condición terminal.
El asistente debe llamar a una API REST documentada para obtener datos en tiempo real.
Importar la especificación OpenAPI de la API como una extensión personalizada, luego añadir un paso de "llamar a una extensión" que mapee variables a parámetros.
Por qué: Las extensiones personalizadas son la forma soportada y sin código de llamar a APIs externas desde un paso con entradas/salidas tipadas.
Elegir entre un webhook y una extensión personalizada.
Usar una extensión personalizada para llamar a una API externa desde un paso específico; usar un webhook (pre/post-mensaje) para ejecutar lógica en cada mensaje o transformar toda la carga útil.
Por qué: Los webhooks se disparan globalmente por mensaje; las extensiones tienen un ámbito y un mapeo de parámetros por paso. Elegir el incorrecto es una trampa común en los exámenes.
La API de destino requiere autenticación.
Configurar la autenticación (clave API, OAuth, básica) al añadir la extensión personalizada; almacenar los secretos en la configuración de la extensión, no en el texto del diálogo.
Por qué: Incrustar credenciales en variables o respuestas las filtra en registros y transcripciones.
Una llamada a una extensión devuelve un error o excede el tiempo de espera.
Ramificar según la respuesta/estado de la extensión en el siguiente paso y mostrar un mensaje de fallback o una ruta de reintento.
Por qué: Los fallos de extensión no manejados dejan al usuario atascado; siempre diseñar la ruta de no-200.
Necesidad de enriquecer o redactar cada mensaje antes de procesarlo o enviarlo.
Usar un webhook de pre-mensaje para preprocesar la entrada entrante y un webhook de post-mensaje para transformar la respuesta antes de la entrega.
Por qué: Los webhooks pre/post centralizan las preocupaciones transversales (enmascaramiento de PII, registro) sin necesidad de editar cada acción.
Los usuarios hacen preguntas abiertas que pueden ser respondidas a partir de un corpus de documentos.
Habilitar la búsqueda conversacional (RAG): recuperar pasajes de una integración de búsqueda y hacer que un modelo fundacional de watsonx.ai genere una respuesta fundamentada con citas.
Por qué: La búsqueda conversacional cubre la cola larga de preguntas que no se pueden crear como acciones discretas.
Elegir el almacén de recuperación detrás de la búsqueda conversacional.
Conectar watsonx Discovery / Elasticsearch (u otra integración de búsqueda soportada) como índice para la recuperación.
Por qué: La calidad del fundamento depende del índice de recuperación; un corpus no indexado o mal fragmentado devuelve pasajes débiles.
La búsqueda conversacional no encuentra pasajes relevantes.
Configurar la respuesta de "sin resultados de búsqueda" para que el asistente diga que no lo sabe en lugar de alucinar, y ofrecer escalada.
Por qué: Una ruta definida para "sin resultados" es lo que mantiene a un asistente RAG honesto y fundamentado.
El cumplimiento requiere que las respuestas generativas sean rastreables.
Habilitar las citas de origen para que las respuestas generadas muestren los documentos de los que se extrajeron.
Por qué: Las citas permiten a los usuarios verificar las respuestas y satisfacer la auditabilidad en industrias reguladas.
Ajustar la calidad y el coste de las respuestas generativas.
Seleccionar el modelo fundacional de watsonx.ai (por ejemplo, un modelo Granite) para la búsqueda conversacional y ajustar la configuración de generación para el caso de uso.
Por qué: La elección del modelo y los parámetros equilibra la calidad de la respuesta, la latencia y el coste; los valores predeterminados no siempre son óptimos.
Decidir si una consulta es manejada por una acción o por la búsqueda.
Dirigir tareas transaccionales y parametrizadas a acciones; dirigir preguntas informativas abiertas a la búsqueda conversacional.
Por qué: Forzar preguntas tipo FAQ en acciones rígidas, o transacciones en RAG, degrada la experiencia.
El asistente debe responder llamadas telefónicas entrantes.
Usar la integración de teléfono/voz (pasarela de voz sobre SIP) para conectar un proveedor de telefonía, con STT para la entrada y TTS para las respuestas.
Por qué: La pasarela de voz conecta la telefonía SIP con el asistente; sin ella no hay canal telefónico.
Las respuestas habladas suenan mal o no reconocen correctamente al llamante.
Ajustar el modelo/idioma de voz a texto y la voz de texto a voz en la configuración de la integración telefónica.
Por qué: Las voces/modelos predeterminados pueden no coincidir con el idioma o el vocabulario del dominio, lo que perjudica el reconocimiento y la claridad.
Un flujo diseñado para chat funciona mal en voz.
Adaptar los flujos de voz: evitar botones/listas largas, mantener las indicaciones cortas y confirmar los valores hablados explícitamente.
Por qué: La voz no puede renderizar una interfaz de usuario rica; los flujos optimizados para texto con menús se rompen cuando se leen en voz alta.
Llegar a los usuarios a través de SMS / mensajería de texto.
Configurar la integración de SMS (teléfono/texto); diseñar para respuestas de texto plano sin elementos enriquecidos.
Por qué: SMS elimina los tipos de respuesta enriquecidos; las respuestas deben degradarse elegantemente a texto.
El chat web debe mostrar imágenes, tarjetas o botones.
Usar tipos de respuesta enriquecidos (imagen, opciones, tarjeta) en la acción; el canal renderiza los tipos compatibles y, de lo contrario, recurre a un fallback.
Por qué: Las respuestas enriquecidas mejoran la experiencia de usuario web, pero deben tener un fallback de texto plano sensato para voz/SMS.
Medir si el asistente realmente está ayudando.
Usar el panel de Análisis para rastrear la tasa de finalización, la cobertura y las entradas reconocidas vs. no reconocidas a lo largo del tiempo.
Por qué: Las métricas de vanidad como el recuento de sesiones no reflejan el éxito de la tarea; la finalización y la cobertura sí.
Buscar por qué los usuarios abandonan un flujo.
Leer registros/transcripciones de conversaciones, filtrar por acción e identificar los pasos de abandono y las frecuentes "no coincidencias".
Por qué: Las transcripciones reales revelan las brechas que las métricas agregadas solo insinúan.
Las sugerencias de desambiguación suelen estar en el orden incorrecto.
Habilitar el autoaprendizaje para que el asistente reordene las sugerencias basándose en la opción que los usuarios realmente eligen.
Por qué: El autoaprendizaje mejora la relevancia a partir de selecciones reales sin necesidad de reentrenamiento manual.
Muchas entradas caen en "ninguna acción coincide".
Extraer entradas no reconocidas de los análisis, agruparlas y crear nuevas acciones o añadir ejemplos a las existentes.
Por qué: Las brechas de cobertura son la mejora de mayor impacto; son las consultas en las que estás fallando por completo.
Una solicitud válida no está activando su acción de forma fiable.
Añadir frases de usuarios reales como ejemplos de entrenamiento al paso de esa acción para mejorar el reconocimiento.
Por qué: El reconocimiento se fortalece con ejemplos representativos extraídos de los registros, no con frases inventadas.
Validar que un cambio mejoró los resultados.
Realizar un cambio a la vez, publicar y comparar la finalización/cobertura antes y después durante un período significativo.
Por qué: Cambiar muchas cosas a la vez hace imposible atribuir el movimiento de las métricas.
Los autores editan mientras los usuarios finales interactúan con el asistente.
Autorizar en el entorno de borrador; los usuarios hablan con el entorno en vivo. Publicar una versión de borrador a vivo cuando esté lista.
Por qué: La división entre borrador y vivo permite iterar de forma segura sin exponer trabajo a medio terminar a producción.
Un conjunto de cambios probado está listo para producción.
Crear una versión (instantánea) y publicarla en el entorno en vivo; las versiones anteriores permanecen disponibles para reversión.
Por qué: El versionado proporciona un historial auditable y una reversión rápida si una versión retrocede.
Borrador y vivo deben apuntar a diferentes endpoints de back-end (prueba vs. producción).
Establecer la configuración de extensión/integración específica del entorno para que cada entorno apunte a los sistemas correctos.
Por qué: Compartir un mismo endpoint entre entornos conlleva el riesgo de que el tráfico de prueba afecte a los sistemas de producción.
Desplegar el asistente en chat web, teléfono, Slack y WhatsApp.
Añadir y configurar cada integración de canal en el entorno de destino; los canales se adjuntan por entorno.
Por qué: Un canal habilitado solo en borrador no atenderá a los usuarios de producción hasta que se configure en vivo.
Diferentes miembros del equipo necesitan diferentes niveles de acceso.
Usar IBM Cloud IAM para asignar acceso basado en roles (por ejemplo, espectador, editor, operador, administrador) en el servicio o grupo de recursos de watsonx Assistant.
Por qué: El acceso de menor privilegio a través de roles de IAM es la forma soportada de controlar quién puede autorizar vs. operar.
Organizar servicios y límites de acceso entre equipos o proyectos.
Colocar el servicio del asistente en un grupo de recursos y limitar las políticas de acceso de IAM a ese grupo.
Por qué: Los grupos de recursos proporcionan límites claros de facturación y acceso; las cuentas planas se vuelven inmanejables a escala.
Una aplicación externa necesita llamar al asistente a través de una API.
Generar credenciales de servicio / una clave API y la URL del asistente, y llamar a la API de tiempo de ejecución v2 con ellas.
Por qué: El acceso programático utiliza credenciales con alcance; reutilizar inicios de sesión personales es inseguro y no está soportado.
Las reglas de residencia de datos o de "air-gap" prohíben la nube pública.
Implementar watsonx Assistant en Cloud Pak for Data (on-premise o nube privada) en lugar de IBM Cloud SaaS.
Por qué: Las industrias reguladas a menudo requieren on-premise/CP4D para el aislamiento de datos y el cumplimiento.
Elegir un plan para un despliegue en producción con alto volumen.
Seleccionar el plan de servicio apropiado (por ejemplo, Plus/Enterprise) para el volumen, las características y el SLA requeridos.
Por qué: Los planes Lite/de prueba limitan el uso y carecen de características de producción; dimensionar correctamente el plan antes del lanzamiento.
Datos sensibles aparecen en conversaciones y registros.
Usar aislamiento de datos, redacción de registros/enmascaramiento de PII (por ejemplo, a través de webhooks) y configurar la retención de registros/ajustes de seguridad.
Por qué: La PII sin enmascarar en las transcripciones es una responsabilidad de cumplimiento; enmascarar en la ingesta y controlar la retención.