Un producto de chat con IA que de vez en cuando se salta un elemento de UI obligatorio, formatea mal una lista u omite silenciosamente un paso de confirmación no tiene un problema de modelo. Tiene un problema de arquitectura — el mismo que seguimos encontrando en despliegues empresariales de IA. Qué aspecto tiene un sistema sano y cómo llegar ahí.
Cuando un producto de chat con IA suelta silenciosamente elementos UI, rompe formato u omite confirmaciones, la causa casi siempre es arquitectura, no el modelo. El arreglo: dejar de pedir al modelo emitir la interfaz visible, y que emita sólo directivas UI tipadas que la aplicación renderiza. Los modos de fallo que eran probabilísticos se vuelven estructuralmente imposibles.
Sí. A través de las superficies de producción que hemos auditado, la tasa a la que el modelo deja caer silenciosamente un elemento UI requerido se sitúa típicamente en el rango del 10–25% cuando el modelo es responsable de emitir esa UI como parte de su salida de texto. Mover la responsabilidad de renderizado fuera del modelo hacia directivas de UI tipadas hace el modo de fallo estructuralmente imposible.
Devolver JSON es una táctica. Un contrato de UI tipado es una arquitectura: el modelo emite qué elementos interactivos son apropiados (y sus datos), la aplicación posee cómo se renderizan esos elementos. El frontend puede refrescar su renderizado sin tocar el modelo; el modelo se puede reentrenar sin forzar un rediseño del frontend. Sólo el contrato tiene que permanecer estable.
Para una sola superficie de chat mantenida por un equipo pequeño donde todo el producto es de corta vida, el enfoque markdown-renderiza-todo sale más rápido y está bien. El patrón se gana su sitio cuando la superficie es multi-equipo, multi-plataforma, multi-idioma o crítica para el negocio — donde quiera que la fiabilidad y la longevidad importen.