Por qué los proyectos con AI no fracasan por la tecnología
Por qué los proyectos con AI no fracasan por la tecnología
Un caso práctico para equipos B2B SaaS: cómo los mismos datos producen productos completamente distintos según las decisiones de arquitectura tomadas antes de escribir código.
La mayoría de los proyectos con AI no fracasan porque el modelo esté mal, el framework esté mal, o el engineer tomó malas decisiones en la implementación. La mayoría de los proyectos con AI fracasan porque nadie diseñó qué tenía que hacer el sistema, qué necesitan los usuarios de él, qué tiene que responder el agente, qué decisiones de arquitectura está tomando, antes de que se escribiera la primera línea de código.
Eso suena abstracto. Te lo hago concreto.
Voy a usar un ejemplo B2C para explicar, un asistente mobile hipotético de Starbucks. Sé que no es B2B SaaS, pero el ejemplo es más visual y fácil de seguir. Al final del post te muestro explícitamente cómo los mismos principios se aplican a los productos B2B SaaS en los que mis lectores trabajan. Tené paciencia.
El Setup
Imaginá que estás construyendo un asistente con AI dentro de la app mobile de Starbucks. El asistente ayuda al cliente a decidir qué pedir, dónde retirarlo, cómo maximizar las stars en el programa de fidelidad, y responde preguntas sobre productos y customizaciones.
Tenés acceso a un dominio rico: catálogo de 200+ productos con tamaños y precios, customizaciones (leches, syrups, foam, niveles de hielo), tablas de alérgenos, información nutricional, inventario en tiempo real por sucursal, ubicaciones y horarios de tiendas, historial de pedidos del cliente, las reglas del programa de rewards. Datos abundantes. Oportunidad clara.
Ahora imaginá una consulta real, del tipo que un usuario podría escribir al asistente:
"Hola, soy intolerante a la lactosa, voy a la sucursal de Palermo después del trabajo, ¿qué me recomendás que sume stars extra esta semana y no tarde mucho en prepararse?"
Esta pregunta cruza seis fuentes de datos: catálogo de productos, tablas de alérgenos, inventario de tiendas, promociones semanales, tiempos de preparación, e historial del cliente. También tiene priorización implícita: sin lactosa es restricción dura, la tienda está fija, stars extra y prep time son preferencias ordenadas en algún orden.
Cómo el asistente AI maneja esta consulta no es decisión de modelo. Es decisión de arquitectura. Y la decisión de arquitectura determina si el cliente confía en el asistente o vuelve a tipear en el buscador.
Camino A: RAG Tradicional
La mayoría de los equipos lo aborda de la misma forma. Vector-embeben toda la base de productos, el PDF de reglas de rewards, las promos semanales, las tablas de alérgenos. Cuando el usuario hace la pregunta, el AI:
- Trae los top-K chunks semánticamente similares a "sin lactosa Palermo stars extra rápido prep"
- Lee los chunks
- Sintetiza una respuesta
Lo que pasa en la práctica:
El retrieval devuelve fragmentos. Un chunk describiendo el latte de leche de almendra menciona "sin lactosa" pero no dice si está disponible en Palermo hoy. Un chunk del PDF de reglas de rewards menciona "stars extra" pero es de una promo de hace tres meses. Un chunk del manual de operaciones menciona horarios de Palermo pero no inventario en tiempo real.
El AI sintetiza una respuesta: "Te recomiendo el latte de leche de almendra, es sin lactosa y suma stars extra esta semana."
Esa respuesta puede estar mal en dos de tres afirmaciones. El latte de almendra puede no estar disponible en Palermo hoy (agotado, común). La afirmación de "stars extra esta semana" vino de un PDF de promo viejo. Solo la parte de sin lactosa está verificada.
El cliente lee la respuesta, abre la app para agregarlo al carrito, y descubre que no está disponible en su sucursal. Confianza rota en 30 segundos.
La implementación técnica funcionó. El modelo respondió. El retrieval corrió. Pero el sistema falló.
Camino B: Knowledge Engine (Basado en Artefactos)
Ahora considerá un enfoque arquitectónico distinto. En lugar de dejar que el AI busque sobre datos crudos en query time, vos pre-computás artefactos estructurados antes. Para cada producto, creás un objeto tipado que ya cruza las seis fuentes de datos:
interface ProductCard {
sku: string
nombre: string
categoria: string
tamaños: { tamaño: string; precio: number; calorias: number; cafeina: number; azucar: number }[]
alergenos: string[]
sin_lactosa: boolean
customizaciones_disponibles: string[]
productos_similares: string[]
tags: string[] // dulce, refrescante, energizante, ...
tiempo_prep_segundos: number
rating_promedio: number
}
interface StoreSnapshot {
store_id: string
nombre: string
ubicacion: { lat: number; lng: number }
horarios_hoy: { apertura: string; cierre: string }
skus_activos: string[] // actualizado cada 60-120s
agotados: string[]
espera_actual_minutos: number
}
interface CustomerProfile {
user_id: string
tier: string
balance_stars: number
stars_proximo_reward: number
usuales: string[]
dietary_flags: string[]
tiendas_favoritas: string[]
ofertas_activas: string[]
}
interface ActivePromotion {
promo_id: string
nombre: string
reglas_elegibilidad: Record<string, unknown>
stars_bonus: number
ventana_validez: { desde: string; hasta: string }
}
Cada artefacto tiene una refresh policy definida. ProductCard se actualiza semanalmente cuando cambia el catálogo. StoreSnapshot cada 60-120 segundos para inventario. CustomerProfile después de cada transacción.
Ahora cuando el cliente hace la pregunta, el AI no hace búsqueda abierta. Corre una query tipada contra los artefactos:
{
"ask": "Recomendá hasta 3 bebidas dulces, sin lactosa, bajo 200 cal,
disponibles en la tienda más cercana al usuario, priorizando
stars extra esta semana y prep time corto",
"filter": {
"user_id": "cliente_123",
"producto.sin_lactosa": true,
"producto.tags.contains": "dulce",
"producto.calorías_tamaño_recomendado": { "<=": 200 },
"tienda.proximidad_usuario_metros": { "<=": 2000 },
"tienda.skus_activos.contains": "{producto.sku}",
"promoción.activa_esta_semana": true
},
"shape": [{
"nombre": "string",
"tamaño_recomendado": "string",
"calorías": "number",
"precio_usd": "number",
"store_id": "string",
"pickup_estimado_minutos": "number",
"stars_extra_esta_semana": "number"
}],
"control": { "max_latency_ms": 600 }
}
El sistema devuelve una lista tipada de 3 bebidas. Cada una verificada contra las seis fuentes de datos. Cada una disponible en la tienda más cercana real de este cliente, hoy, con las stars y prep time reales.
El cliente lee la respuesta, abre la app, la bebida está disponible, las stars coinciden con lo prometido. Confianza ganada.
Qué es Realmente Distinto Entre los Dos Caminos
Notá las diferencias arquitectónicas. No son preferencias técnicas, son decisiones sobre qué tiene que hacer el sistema.
En Camino A: el AI hace retrieval y razonamiento en query time. El cliente espera mientras el sistema busca, lee chunks, sintetiza. La latencia es impredecible. La precisión depende de qué encontró el embedding. El sistema puede afirmar con confianza cosas que después resultan incorrectas.
En Camino B: el trabajo de estructura pasa en build time. Los artefactos se computan una vez y se refrescan según schedule. La query es un contrato tipado, qué pidió el cliente, en qué forma, con qué restricciones, dentro de qué budget. El modelo solo compone la respuesta. No puede inventar hechos porque no hay nada que inventar.
La diferencia no es "el Camino B es mejor". Es que los dos caminos optimizan para cosas distintas. El Camino A optimiza para flexibilidad, el AI puede responder preguntas que no anticipaste. El Camino B optimiza para confianza, el AI solo puede responder con datos verificados, pero responde de forma confiable.
Para un asistente mobile de Starbucks, donde los clientes hacen preguntas predecibles y necesitan respuestas correctas rápido, gana el Camino B. Para un asistente de research abierto donde los usuarios preguntan cosas impredecibles y toleran fallos ocasionales, podría ganar el Camino A.
El punto no es cuál camino es mejor en abstracto. El punto es que esto es decisión de diseño, no decisión técnica. Y tiene que tomarse antes de escribir código, por alguien que entiende tanto qué necesitan los usuarios como qué produce cada patrón técnico.
Cómo se Traslada Esto a B2B SaaS
Ahora trasladá esto a tu producto B2B SaaS. Reemplazá "clientes de Starbucks" por "tus usuarios". Reemplazá "bebidas y stars" por lo que tu producto haga, gestionar leads, hacer tracking de proyectos, procesar tickets, revisar contratos, lo que sea.
Estás agregando AI a tu producto. Tal vez un asistente dentro del dashboard. Tal vez un sistema de recomendación. Tal vez una automatización que pre-completa tareas basándose en contexto. Lo que sea, enfrentás la misma bifurcación:
Camino A, Retrieval abierto sobre tus datos: Embebés tu dominio (registros de clientes, historial, configuraciones, base de conocimiento), y dejás que el AI busque en query time. Rápido de lanzar. Flexible. Precisión probabilística.
Camino B, Artefactos estructurados de tu dominio: Pre-computás las entidades sobre las que el AI necesita razonar. Definís su forma, sus relaciones, sus refresh policies. Definís qué queries el AI puede hacer contra ellas. Más lento de diseñar al principio. Más confiable en producción. Precisión predecible.
Para la mayoría de casos B2B SaaS, donde los usuarios están haciendo su trabajo real, necesitan respuestas correctas rápido, y la confianza se degrada rápido cuando el AI inventa cosas, gana el Camino B. Pero casi ningún equipo arranca por ahí.
¿Por qué? Porque lanzar el Camino A es más fácil. Hay un ecosistema entero de tutoriales, frameworks, y soluciones copy-paste para "embebé tus datos, hacé RAG, lanzá un chatbot". Construir el Camino B requiere realmente entender tu dominio, diseñar artefactos, definir refresh policies, decidir qué queries soportar. Eso no es trabajo de framework. Es trabajo de diseño.
El Punto Más Profundo
Cuando leas "el proyecto AI fracasó por cosa técnica", mirá más cerca. La mayoría de las veces, la cosa técnica fue downstream de una decisión arquitectónica que se tomó implícitamente, por default, por quien estaba escribiendo código.
- ¿El AI debería buscar sobre chunks o consultar artefactos estructurados? Decisión arquitectónica, tomada implícitamente cuando alguien eligió un tutorial.
- ¿El AI debería citar sus fuentes o solo sintetizar? Decisión arquitectónica, frecuentemente saltada.
- ¿La respuesta debería ser un objeto tipado o lenguaje natural? Decisión arquitectónica, defaulted a lenguaje natural porque es más rápido de demostrar.
- ¿Debería haber criterios de evaluación que el sistema tiene que cumplir? Decisión arquitectónica, frecuentemente diferida a "después del lanzamiento".
Cada una de estas es una decisión de UX vestida de decisión técnica. Y cada una determina si tus usuarios confían en el AI lo suficiente para realmente usarlo.
Qué Hacer al Respecto
Si estás construyendo features con AI en B2B SaaS, antes del próximo sprint:
- Escribí las 5-10 preguntas más importantes que tus usuarios le van a hacer al AI. Sé específico. Preguntas reales, no use cases abstractos.
- Para cada una, escribí cómo se ve la respuesta correcta, qué campos, qué formato, qué sería inaceptable que esté mal.
- Identificá las fuentes de datos de las que depende cada respuesta correcta.
- Decidí explícitamente: ¿voy a dejar que el AI busque sobre esas fuentes en query time (Camino A), o voy a pre-computar artefactos estructurados que el AI pueda consultar de forma confiable (Camino B)?
Los pasos 1-3 son el eval set que la mayoría de los equipos saltan. El paso 4 es la decisión arquitectónica que la mayoría de los equipos toma implícitamente.
Hacer este trabajo no toma mucho, una tarde focalizada con la gente correcta produce un borrador. Saltarlo produce un feature de AI que se lanza, no se adopta, y se vuelve el ejemplo al que todos referencian como "esa cosa de AI que no funcionó".
La tecnología no va a hacer fracasar tu proyecto. Las decisiones tomadas antes de la tecnología sí.
Si estás construyendo o auditando un feature con AI en tu producto B2B SaaS y querés pensar estas decisiones antes, o después, de comprometerte con un approach, ese es el trabajo que hago. Hablemos →