NUTRISYNCBuilders Hub
🏠 🛠

🤖 Propuesta 32 · AI Enablement

Epic N — dónde la IA da valor en NutriSync, con qué stack (coste mínimo, muy escalable) y en qué orden · para el roadmap de negocio y tecnológico · nada de esto toca el camino crítico del 8-oct (Plan-Lanzamiento-8Oct.html) · 1-ago-2026 · v2 (9-ago): + capacidades de VISIÓN para el Epic P · vision capabilities added (ES/EN addendum, §3b)

1 · Resumen ejecutivo

NutriSync ya tiene la materia prima que hace útil a la IA: un motor de contenido estructurado (content-i18n, 14 idiomas), datos longitudinales por usuaria (ciclos, síntomas, comidas, movimiento, CAS/CSS) y una arquitectura serverless donde enchufar inferencia sin servidores nuevos. La propuesta: usar IA en cuatro frentes — diálogo (recoger inputs conversando, no rellenando formularios), análisis (patrones personales narrados en lenguaje humano), recomendación (catálogo + preferencias vía búsqueda semántica) y operaciones (triage de feedback y contenido para founders) — con una arquitectura de tres niveles de coste que mantiene el gasto marginal cercano a cero para el 90% del valor.

La tesis de negocio: la capa personal de IA es el argumento natural del tier premium (conecta con Epic L / Doc 29): gratis = inteligencia compartida por segmento; premium = tu analista personal. Y la capa de operaciones devuelve horas de founders desde la semana uno.

2 · Principios (los no negociables)

1 · Coste marginal ≈ 0 por diseño. Todo lo que pueda generarse UNA vez y servirse a muchas (insights por fase×objetivo×idioma) se pre-genera y cachea en Supabase — igual que hoy servimos el catálogo. La inferencia por usuaria queda para donde de verdad personaliza, con presupuesto por usuaria y caché diaria.

2 · Privacidad primero. Los prompts nunca llevan PII (ni nombre, ni email, ni ciudad): viajan datos pseudonimizados (fase, día, agregados de logs). Procesamiento en región UE con DPA firmado. Consentimiento explícito y separado para funciones de IA (encaja con nuestra capa de consentimiento existente) — datos de salud = Art. 9 RGPD, el abogado revisa el addendum (mismo flujo que G4 del plan).

3 · Nunca diagnóstico. La IA narra patrones y sugiere hábitos del catálogo aprobado; jamás diagnostica ni prescribe. Guardrails de temas + disclaimer de salud + escalada a "consulta a un profesional" (coherente con el Aviso de Salud y con la Propuesta 31: tono de cuidado).

4 · Con las manos en el catálogo. Las recomendaciones se anclan (RAG) en NUESTRO contenido validado por Pilar — la IA elige y explica, no inventa consejos de salud. Human-in-the-loop para todo contenido nuevo.

5 · Proveedor intercambiable. Un router propio con registro de modelos en base de datos: cambiar de proveedor o modelo = 1 fila, 0 deploys. Cero lock-in.

3 · Stack tecnológico — coste mínimo, muy escalable

Arquitectura (sobre lo que ya tenemos — 0 infraestructura nueva)

App / PWA / WebUI + streaming Edge Function ai-routerDeno · auth + límites + logging API LLM (región UE)modelo pequeño por defecto
Supabase Postgrescaché de insights · presupuestos · consentimiento pgvector (ya incluido)embeddings del catálogo + FAQ pg_cron / Edge scheduledbatch nocturno de insights

La clave: toda inferencia pasa por Edge Functions (las claves API viven en secrets, jamás en el cliente — misma regla que ya cumplimos con service_role), y toda respuesta cacheable se guarda en Postgres. El streaming al móvil va por SSE desde la función. No hay servidores, colas ni vector-DBs externos que operar: pgvector y pg_cron ya vienen con Supabase.

Los tres niveles de coste (así escala sin sustos)

NivelQuéCoste marginal por usuariaQuién lo recibe
N1 · Batch compartidoInsights por segmento (4 fases × objetivos × 14 idiomas) pre-generados cada noche y cacheados — como el motor diario actual≈ 0 € (coste fijo total <1 €/día)Todas (free)
N2 · Personal cacheado1 análisis personal/día máx. (patrones de SUS logs), modelo pequeño, se guarda y sirve~0,001-0,003 €/díaPremium (y piloto)
N3 · InteractivoChat/check-in conversacional con presupuesto mensual de tokens por usuaria~0,05-0,15 €/mes con topePremium

Con 10.000 usuarias y mezcla realista: <100 €/mes de inferencia. El tope por usuaria hace el coste lineal y predecible — entra en el ARPU del Doc 29 con margen de sobra.

Elección de modelo/proveedor

Criterios: endpoint en UE + DPA · calidad multilingüe real (14 idiomas incl. co-oficiales) · coste clase "small" (0,1-1 €/millón tokens entrada) · políticas que permitan contenido de salud/bienestar · salida estructurada fiable (JSON) para extraer logs del diálogo. Los modelos pequeños de los tres grandes (Anthropic Haiku, OpenAI mini, Google Flash) cumplen; los open-weights vía proveedor UE son el plan B de coste. Recomendación operativa: empezar con UNO (el que mejor DPA/UE nos firme) y decidirlo en D12 — el router hace que la elección sea reversible en minutos. Evaluación con un golden-set propio (50 casos × idioma clave) antes de encender nada de cara a usuarias.

Los tres candidatos LLM, en detalle (adenda 2-ago)

Claude Haiku (Anthropic)GPT mini (OpenAI)Gemini Flash (Google)
CarácterFiel a instrucciones, tono muy controlable, JSON fiableEl barato ubicuo del ecosistema; function-calling maduroPrecio/velocidad agresivos, contexto 1M, multimodal
Fortaleza para NutriSyncTono de salud con voz de marca + extracción precisa (caso A)Coste mínimo por token; Azure UE muy rodadoBatch masivo baratísimo (insights N1); Vertex UE nativo
Debilidad para NutriSyncAlgo más caro en gama pequeñaVerborrea/tono genérico — más prompt-workFiltros que históricamente se disparan con contenido menstrual/salud
UE/DPABedrock/Vertex región UE + DPAAzure OpenAI UEVertex AI UE
14 idiomas (incl. cooficiales)Bueno, correcto en cooficialesBueno en grandes, flojo en minoritariosBueno en grandes, irregular en minoritarios

Sesgo declarado: este análisis lo escribe un modelo de Anthropic — por eso D12 se decide con DPA/UE + golden-set en nuestros idiomas y contenido, no con opiniones.

3b · Adenda v2 (9-ago) — Visión · Vision (Epic P · Meal Photo AI)

ES — El Epic P (doc 39: foto de la comida → borrador → dato estructurado) añade la segunda modalidad al stack: visión. Mismo régimen que el texto, sin excepciones:
  • Todo pasa por el ai-router: el proveedor de visión es una fila en el registro de modelos, reversible en minutos. Puede ser DISTINTO del proveedor de texto.
  • Propuesta operativa: gpt-5.6-luna (visión, Responses API, salida JSON estricta por json_schema) para el volumen; gpt-5.6-terra como reintento cuando la confianza baja de 0,65 o el plato es mixto; si sigue dudoso, UNA pregunta simple a la usuaria. Alternativas evaluables con el mismo golden-set: visión de Claude y Gemini.
  • La IA identifica, la base calcula: la visión devuelve alimentos + gramos estimados + confianza; los macros salen SIEMPRE de canonical_foods (USDA sembrado · EuroFIR pendiente) de forma determinista. Jamás calorías inventadas por el modelo.
  • Cero PII, versión visión: al proveedor viaja SOLO la imagen (1024px, sin EXIF ni localización) — nunca identidad, ciclo ni historial. Región UE/DPA igual que el texto (D12).
  • Golden-set de fotos: las correcciones reales de las usuarias (meal_edits) son los casos de evaluación etiquetados — el mejor banco de pruebas posible, gratis.
  • Coste: N2/N3 con presupuesto por usuaria en BD y degradación (reintento Terra solo bajo umbral). El tope hace el coste lineal, como todo el epic.
EN — Epic P (doc 39: meal photo → draft → structured data) adds the second modality to the stack: vision. Same regime as text, no exceptions:
  • Everything goes through the ai-router: the vision provider is one row in the model registry, reversible in minutes — and it may DIFFER from the text provider.
  • Operating proposal: gpt-5.6-luna (vision, Responses API, strict JSON via json_schema) for volume; gpt-5.6-terra retry when confidence drops below 0.65 or the dish is mixed; if still uncertain, ONE simple question to the user. Claude and Gemini vision remain evaluable with the same golden-set.
  • The AI identifies, the database calculates: vision returns foods + estimated grams + confidence; macros ALWAYS come deterministically from canonical_foods (USDA seeded · EuroFIR pending). Never model-invented calories.
  • Zero PII, vision edition: only the image travels to the provider (1024px, EXIF and location stripped) — never identity, cycle or history. EU region/DPA same as text (D12).
  • Photo golden-set: real user corrections (meal_edits) are the labelled evaluation cases — the best possible test bench, for free.
  • Cost: N2/N3 with per-user budget in the database and graceful degradation (Terra retry only below threshold). The cap keeps cost linear, like the rest of the epic.

Lo que NO metemos (y cuándo sí) — Neo4j, orquestadores y familia

Neo4j / grafos: hoy no — nuestros datos son relacionales/temporales con saltos de 1-2 relaciones (Postgres + pgvector los cubren). Disparador para reabrir: features sociales/comunidad con grafo de relaciones, o un grafo de conocimiento nutricional donde las preguntas dominantes sean multi-salto (>3). Primer paso lean incluso entonces: tabla de aristas en Postgres. Horizonte: 2027 o nunca.

ContextForge / LangChain / orquestadores de contexto: hoy no — el router propio + pgvector + caché ES la orquestación para AI-0/1/2, y la memoria de la usuaria son sus datos estructurados (mejores que cualquier vector de conversación). Disparador: AI-3 (copiloto multi-turno con >3 herramientas y estado largo) o multi-proveedor simultáneo con políticas complejas; incluso entonces, primero tabla conversations + registro de tools propio.

La excepción probable: Langfuse auto-alojado (observabilidad/evals de LLM) en AI-2, si el volumen de evaluación supera la tabla de telemetría. Es la única pieza del ecosistema AI con papeletas de ganarse el sitio pronto.

Regla de la casa (CLAUDE.md): cada pieza entra con un dolor real que resuelve — el stack son 4 proveedores y 0 servidores, y eso es un feature.

4 · Mapa de casos de uso — dónde da valor

#Caso de usoValorNivel costeFase
ACheck-in conversacional — "¿cómo estás hoy?" en lenguaje libre; la IA extrae síntomas/ánimo/energía/comidas a datos estructurados (salida JSON → mismas tablas de logs de hoy). El formulario queda como alternativa, no como peaje.Más datos y mejores (el activo nº1 del producto) + usabilidad radicalN3AI-2
BInsight diario narrado — el motor actual elige QUÉ decir (recs por segmento); la IA lo convierte en UN párrafo cálido y contextual por fase×objetivo×idioma, pre-generadoEl "para mí" que diferencia de un listado; retención diariaN1AI-1
CAnálisis de patrones personal — SQL calcula (correlaciones logs↔ciclo sobre cycle_records de la Propuesta 31); la IA narra: "tus migrañas aparecen los días 24-26 en 3 de tus últimos 4 ciclos". Alimenta la pantalla Trends (sinergia directa con Epic M)El momento "wow" — nadie más se lo dice; driver premium nº1N2AI-2
DRecomendación semántica — embeddings del catálogo (pgvector): "algo vegetal, rápido y rico en hierro" → platos del catálogo filtrados por alérgenos/dieta/faseRecomendaciones que respetan el diseño de Pilar, explicadasN2AI-2
EGuía de uso in-app — "¿cómo registro mi período?" respondido sobre NUESTRA documentación (RAG de la guía/FAQ), con deep-link a la pantallaMenos fricción, menos tickets a contact@N1/N3AI-1
FMensajes de estado inteligentes — los copys de gracia/deriva/rebaseline (Prop. 31) con matiz de contexto, dentro del registro de notificacionesComunicación que no suena a plantillaN1AI-1/M-3
GOPS · Triage de feedback — en el hub: clustering y etiquetado automático del feedback del piloto (tema, severidad, screen), resumen semanal para foundersHoras de founders devueltas desde la semana 1; cero exposición a usuariasinternoAI-0
HOPS · Contenido y traducciones — asistente en el hub Translations: primera pasada de los 12 idiomas + QA de coherencia (hoy lo hacemos a mano fuera)La pasada de revisores ×12 idiomas deja de ser cuello de botellainternoAI-0
ISeñales de cuidado — detección de valores fuera de patrón sostenidos (ya definidos en Prop. 31) con mensaje empático y derivación a profesional. IA solo REDACTA; la regla la decide SQLConfianza y responsabilidad — nunca diagnósticoN1AI-2

5 · Cuatro journeys concretos

J1 · El check-in de María (caso A, premium) — Notificación de la tarde → abre chat: "¿Cómo ha ido el día?" → María: "agotada, me ha dolido la cabeza toda la tarde y he picoteado fatal" → la IA extrae {energía: baja, síntoma: cefalea, nutrición: picoteo} → confirma en un tap → se guardan como logs normales (mismas tablas, mismo CAS).
"Anotado: energía baja, dolor de cabeza y picoteo 💾 Vas por el día 24 — la fase lútea tardía suele pedir más magnesio; ¿te dejo dos cenas del catálogo que ayudan?"
J2 · "¿Por qué estoy tan cansada?" (caso C, premium) — María lo pregunta en Trends → SQL trae sus 4 ciclos + logs de energía → la IA narra el patrón real y enlaza 2 recomendaciones del catálogo.
"En tus últimos 3 ciclos, tu energía baja de forma consistente los días 22-26 (ahora vas por el 24). No es casualidad: es tu patrón lúteo. Te va mejor cuando cenas antes de las 21h (lo hiciste 6 de los 9 días buenos)."
J3 · Pilar y el feedback del piloto (caso G, interno) — Lunes, hub → Feedback: 47 mensajes de la semana ya vienen agrupados: "12 · onboarding-idioma · P2", "8 · calendario-visual · P1"… con resumen de 5 líneas y los 3 quotes más representativos por cluster. Pilar valida etiquetas en 10 minutos en vez de leer 47 mensajes.
J4 · La usuaria perdida (caso E, free) — "¿dónde cambio mi duración de ciclo?" → respuesta anclada en la guía + botón que abre Cycle & Health directamente. Un ticket menos; una usuaria que no abandona.

6 · Plan de implementación (fases AI-0 → AI-3)

AI-0 · Ops interno (sprints 12-13, agosto — SIN tocar el camino crítico)ai-router Edge Function + registro de modelos + tabla de presupuestos/telemetría · triage de feedback en hub (caso G) · asistente de traducciones (caso H) · golden-set de evaluación v1. Riesgo cero (nada de cara a usuarias), valor inmediato para el piloto de septiembre.
AI-1 · Inteligencia compartida (post-lanzamiento, oct-nov) — insights diarios narrados por segmento ×14 idiomas (batch nocturno, caso B) · guía de uso RAG (caso E) · copys de estado (caso F) · addendum de consentimiento IA publicado (abogado). KPI gate: coste fijo <30 €/mes y CTR del insight >25%.
AI-2 · Personal premium (nov-dic, con Epic L en producción) — análisis de patrones narrado en Trends (caso C) · check-in conversacional (caso A) · recomendación semántica (caso D) · señales de cuidado (caso I). Es EL contenido del tier premium: se lanza junto a la oferta de pago.
AI-3 · Copiloto (2027) — Nutri proactivo multi-turno, predicciones con banda de confianza, integración con wearables (health_signal ya existe). Se decide con datos de AI-1/2.
Dependencias: AI-0 no depende de nadie (arranca ya) · AI-1 depende del addendum legal de consentimiento · AI-2 depende de Epic L (pagos) y de cycle_records (Epic M-1) · Todo depende de D12 (proveedor).

7 · Riesgos y guardrails

⚠ Datos de salud a un tercero → pseudonimización estricta en el router (allowlist de campos: fase, día, agregados — nunca identidad), región UE, DPA, consentimiento separado y revocable, y modo degradado sin IA para quien no consienta.
⚠ Alucinaciones en consejos → recomendaciones SOLO del catálogo (RAG con cita interna); si no hay match, la IA lo dice y ofrece el genérico de fase. Temperatura baja + salida estructurada + tests del golden-set en CI.
⚠ Coste desbocado → presupuesto por usuaria en BD (el router corta y degrada a caché), telemetría de coste por función en la Consola Admin, alertas.
⚠ Tono fuera de marca → guía de voz NutriSync en el system prompt (la voz de Lucía/Pilar), evaluada por founders en el golden-set — mismo circuito que los copys de la Propuesta 31.

8 · Decisiones para founders

PreguntaOpciones
D12Proveedor LLM primario de TEXTO + proveedor de VISIÓN (Epic P) — pueden ser distintos; ambos reversibles vía router · Primary TEXT provider + VISION provider — may differ; both reversible via the routerA · El grande con mejor DPA/endpoint UE que firmemos primero (recomendada) · B · Open-weights vía proveedor UE (más barato, más QA nuestro) · C · Dual desde el día 1 (más coste de eval)
D13Consentimiento de IAA · Opt-in explícito con pantalla propia (recomendada — salud manda) · B · Incluido en el consentimiento general con toggle en Settings
D14Papel comercial de la IAA · Free = compartido (N1), Premium = personal (N2/N3) (recomendada — driver claro del Doc 29) · B · Todo premium · C · Todo free durante 2027 (coste asumido como marketing)

Como siempre: "D12-A, D13-A, D14-A" por WhatsApp vale. D12 conviene decidirla en agosto para que AI-0 arranque con el proveedor definitivo.

9 · KPIs del epic

💶 Coste IA / usuaria activa / mes (objetivo <0,05 € free · <0,20 € premium) 📈 CTR del insight diario 🗣 % de check-ins por chat vs formulario 📊 Logs por usuaria/semana (antes vs después del caso A) 🎯 Conversión free→premium atribuida a IA (D14) 🎧 % consultas de soporte desviadas (caso E) ⏱ Horas de founders/semana en triage (caso G, antes vs después)
✅ Resumen en una frase — La IA de NutriSync no es un chatbot pegado encima: es (1) recoger datos conversando, (2) contarle a cada usuaria SU patrón con su voz, (3) recomendar solo desde el catálogo de Pilar, y (4) devolverle horas al equipo — sobre la arquitectura serverless que ya tenemos, con coste marginal cercano a cero por diseño, proveedor intercambiable y la salud siempre por delante. AI-0 puede arrancar el sprint 12 sin rozar el 8-oct.

10 · Referencias

Plan-Lanzamiento-8Oct.html — camino crítico que este epic NO toca · Doc 29 / decisiones-pagos — tier premium donde encaja AI-2 · Propuesta-31 — cycle_records y estados que alimentan el análisis (caso C) y los copys (caso F) · content-i18n (motor diario 14 idiomas) — la base del batch N1 · NutriSync-Architecture-Deployment.html — arquitectura serverless de partida · NutriSync-Backlog.html — se registra como Epic N en el próximo pase de docs
NutriSync · Propuesta 32 · AI Enablement (Epic N) · 1 de agosto de 2026 · para leer con calma y decidir D12-D14