Curso Completo — Data Engineer + ML/DS para el Mercado Chino de Ecommerce 2026

Complemento y cierre del syllabus. Contiene el detalle semana a semana (objetivos medibles, lecturas, ejercicios, entregables, criterios de aprobación), las especificaciones completas de los proyectos de portafolio, las fuentes externas para los huecos que InfoQ no cubre, y el plan de lectura integrado. Fecha: 2026-09-04.

---

PARTE A — Metodología, evaluación y reglas del curso

A.1 Perfil de entrada (prerequisitos)

• SQL sólido (window functions, CTEs, optimización de queries).
• Python de producción (tipado, testing, pandas/polars, una librería de DL opcional).
• Un pipeline ETL/ELT real desplegado o al menos diseñado.
• Un modelo de ML entrenado y evaluado (aunque sea toy).
• Git + CI básico (GitHub Actions o similar).

A.2 Reglas de trabajo

1. Todo entregable corre (repo con README, tests y comandos reproducibles). Nada “en teoría”.
2. Toda decisión se documenta como ADR (Architecture Decision Record) corto: contexto → opciones → decisión → consecuencias. (Inspirado en “Panel: Taking Architecture out of the Echo Chamber”.)
3. Cada semana cierra con una demo de 10 min (lo que corre) + un “unresolved question” que queda abierto.
4. Escala primero en datos, luego en modelos. El syllabus prioriza la capa de datos porque es donde el 90% de los proyectos de ecommerce fallan (ver Wenjie Zi, “Why Most ML Projects Fail to Reach Production”).

A.3 Evaluación por semana (para saber si “aprobaste”)

• Completo (✓✓): entregable corre end-to-end + 1 ADR + demo.
• Parcial (✓): entregable corre pero faltó documentación o un criterio.
• Insuficiente (✗): no corre. No avances de semana sin resolverlo: los módulos son acumulativos.

A.4 Criterio de “curso completo”

• 16 semanas con entregables ✓ o ✓✓.
• Portafolio: 3 proyectos end-to-end integrados + capstone.
• Documento de estrategia (1–2 páginas) + plan de operaciones.
• Análisis de cumplimiento PIPL/MLPS del sistema.

---

PARTE B — Syllabus semana a semana (16 semanas)

Módulo 1 — Data Engineering para ML (S1–S3)

Semana 1 — Ingesta y pipelines de eventos a escala

Objetivos medibles (al cierre debes poder):

• Modelar un flujo de eventos de ecommerce (page_view, search, add_to_cart, purchase, refund) con un esquema versionado (Avro/Protobuf + schema registry).
• Justificar batch vs. incremental vs. streaming para cada tabla destino.
• Explicar qué resuelve CDC y qué es un Write-Ahead Intent Log.
• Medir lag de un pipeline (offset lag y “time in queue”) y definir un SLA de frescura.

Lecturas InfoQ:

• “Write-Ahead Intent Log: a Foundation for Efficient CDC at Scale” — Vinay Chella (jun 2026).
• “Beyond Offset Lag: Computing Time in Queue for Apache Hudi Data Lake Pipelines at Petabyte Scale” — Srikanth Mamidala (ago 2026).

Lecturas externas (gap):

• RocketMQ vs. Kafka: documentación oficial Apache RocketMQ + casos de Alibaba (mensajería transaccional).
• Introducción a Apache Hudi/Iceberg: guías oficiales (tablas snapshot + incremental, time travel).

Ejercicio: levantar un broker (Kafka en Docker o Redpanda), publicar eventos sintéticos con un generador, consumirlos y escribirlos como tabla con soporte de _commit_time.

Entregable (Proyecto 1, parte 1): pipeline que ingiere eventos → valida esquema → escribe en data lake con snapshot + incremental. Incluye: 1 ADR (elección de formato y tabla), métrica de lag en un dashboard mínimo, test de schema enforcement (un evento malformado debe rechazarse).

Criterio de aprobación: pipeline corre con 1M eventos sintéticos; lag visible; evento inválido rechazado con error claro.

Semana 2 — Warehousing, feature stores y point-in-time joins

Objetivos medibles:

• Diferenciar warehouse vs. lake vs. feature store y cuándo usar cada uno en ML.
• Implementar un point-in-time correct join (evitar leakage en features de comportamiento).
• Definir features de usuario, producto y contexto con su caducidad (staleness).
• Configurar una feature store (Feast o Tecton; DIY sobre Redis+Postgres como fallback).

Lecturas InfoQ:

• “Architecting the Data Layer for AI Agents” — Fabiane Nardo (sección: data products y contratos).
• eMag Agentic AI Architecture (Adi Polak) — memory/knowledge como capas.

Lecturas externas:

• Documentación de Feast: OnDemandFeatureView, offline/online store, point-in-time join.
• Paper sobre feature leakage en recomendación (búsqueda “data leakage recommender systems”).

Ejercicio: construir dos features que cambian en el tiempo (ej. “total gastado últimos 30 días”, “categoría más vista esta semana”) y verificar que el join point-in-time no use datos futuros.

Entregable (Proyecto 2, parte 1): feature store con ≥8 features (usuario/producto/contexto) servidas online (baja latencia) y materializadas offline (entrenamiento). Incluye: definición de entidades, timestamps, staleness SLAs por feature, y un test de point-in-time correctness.

Criterio: el join offline reconstruye exactamente el estado online en un timestamp dado (sin leakage).

Semana 3 — Calidad de datos, observabilidad y data contracts

Objetivos medibles:

• Implementar ≥5 reglas de calidad (valores faltantes, rango, distribución, volumen, unicidad).
• Generar lineage de datos → features → modelo (documentado o con herramienta).
• Definir un “data contract” entre productor y consumidor con su SLA.

Lecturas InfoQ:

• AI-Assisted Engineering (PDF), semanas 2–4: “sensor suite”, drift/health sensors, background cleanup agents.
• eMag Architecture as a Socio-Technical Craft — “Architectural Decay Loop: Fitness Functions as Guardrails” (Aretini et al.).

Lecturas externas:

• Great Expectations o Soda: expectativas declarativas y validación en CI.

Ejercicio: inyectar anomalías sintéticas (pico de eventos, distribución rota, nulos) y verificar que las reglas las detectan.

Entregable: suite de sensores ejecutada en el pipeline (CI) con alertas; documentar cómo cada regla protege la calidad de las features que alimentan el feature store.

Criterio: las 3 anomalías inyectadas son detectadas y alertadas.

---

Módulo 2 — MLOps en Producción (S4–S6)

Semana 4 — Recomendación y ranking a escala

Objetivos medibles:

• Entrenar un modelo de ranking (LightGBM o two-tower) sobre interacciones sintéticas.
• Calcular métricas offline: Precision@K, Recall@K, NDCG@K, y una métrica de negocio proxy (conversión simulada).
• Servir inferencia con latencia p95 < 50ms.

Lecturas InfoQ:

• DoorDash “From Models to Agents” (Sudeep Das) — two-tower asimétrico, semantic IDs (RQ-VAE).
• Noticia: “Swiggy Uses 350+ Features and Multi-Task MLP to Predict Customer Lifetime Value”.

Lecturas externas:

• RecSys/KDD papers de Alibaba (GNN para recomendación), AliRec.
• Guía de dos-tower / learning-to-rank (LightGBM ranker).

Ejercicio: construir features → entrenar ranker → comparar un baseline (popularidad) vs. modelo, con las 3 métricas offline.

Entregable (Proyecto 3, parte 1): servicio de recomendación consumiendo del feature store, con A/B o eval offline. Incluye: endpoint de serving, reporte de métricas, 1 ADR (batch vs. online serving).

Criterio: modelo supera al baseline de popularidad en NDCG@10; latencia p95 < 50ms.

Semana 5 — MLOps: versionado, CI/CD, despliegue y rollback

Objetivos medibles:

• Versionar datos + código + modelo + config (DVC + MLflow/W&B).
• Implementar un pipeline de entrenamiento reproducible (un comando reentrena desde cero).
• Desplegar con canary y plan de rollback documentado.

Lecturas InfoQ:

• “Powering the Future: Building Your GenAI Infrastructure Stack” — Merrin Kurian (Intuit): experiment tracking, gobernanza.
• Minibook AI-Assisted Development 2025 — “Architecting Agentic MLOps: A2A + MCP” (Kapoor et al.).
• “Building Evals for AI Adoption” — Mallika Rao: concepto de “evaluation debt”.

Ejercicio: entrenar dos versiones de un modelo, una degradada; verificar que un “performance gate” bloquea el despliegue de la degradada y activa rollback.

Entregable: pipeline MLOps completo (entrenamiento → eval gate → registro → despliegue canary → rollback). Incluye: gates de calidad y de fairness, lineage modelo→datos→features.

Criterio: reentrenar es un solo comando; el gate bloquea modelo degradado; rollback funciona en <5 min.

Semana 6 — Evaluación multicapa (5 capas)

Objetivos medibles:

• Implementar las 5 capas de evaluación de Mallika Rao: (1) estadística, (2) sistema, (3) comportamiento usuario, (4) impacto negocio, (5) equidad/sesgo.
• Detectar degradación en cualquier capa con una alerta.
• Medir sesgo de popularidad/precio en el recomendador.

Lecturas InfoQ:

• “Building Evals for AI Adoption: from Principles to Practice” — Mallika Rao (may 2026).

Entregable: dashboard de evaluación multicapa en vivo + alertas + documentación de cómo métricas de negocio/sesgo informan reentrenamiento. Incluye una métrica de sesgo concreta (ej. distribución de popularidad por categoría, o disparidad de precio).

Criterio: cada capa tiene una métrica, un umbral y una alerta; el sesgo detectado está cuantificado y mitigado (re-ranking o re-weighting).

---

Módulo 3 — IA Generativa, RAG y Agents (S7–S10)

Semana 7 — RAG y context engineering

Objetivos medibles:

• Indexar un catálogo de productos (título, descripción, atributos, reseñas) en una vector DB (Milvus/Qdrant/Faiss).
• Elegir y justificar una estrategia de chunking y de re-ranking.
• Responder consultas en lenguaje natural con fuentes citadas y diálogo multi-turno.

Lecturas InfoQ:

• “Beyond Prompting: Context Engineering for Production-Grade AI” — Ricardo Ferreira (Redis, token limits, semantic caching, cost control).
• “Architecting the Data Layer for AI Agents” — Fabiane Nardo (semantic ontologies, tool selection).
• eMag Agentic AI Architecture — Adi Polak (ephemeral vs. durable context).

Lecturas externas:

• Milvus/Zilliz docs (muy usado en China).
• RAG evaluation: faithfulness / relevance / utility.

Ejercicio: medir calidad de respuestas con LLM-as-a-judge sobre un set de 30 preguntas etiquetadas.

Entregable (Proyecto 4, parte 1): motor de búsqueda semántica + chatbot con citas y follow-ups. Incluye: pipeline de chunking, evaluación con LLM-as-judge, cache semántico para control de costos.

Criterio: ≥80% de respuestas fieles (faithful) y relevantes en el set de prueba; citas correctas.

Semana 8 — Agents de operaciones (soporte)

Objetivos medibles:

• Diseñar un tool inventory para un agente de soporte (consultar pedido, verificar stock, iniciar devolución, crear ticket).
• Enumerar ≥5 fail modes y su “escape hatch” (escalar a humano).
• Evaluar el agente con un rubric (no solo “se ve bien”).

Lecturas InfoQ:

• “What I Learned Building Multi-Agent Systems from Scratch” — Paulo Arruda (Shopify).
• AI Engineering (PDF) semana 3: agent design, escape hatches, failure containment.

Ejercicio: simular 5 escenarios de fallo (tool error, loop, salida runaway) y verificar que el agente escapa a humano o se detiene.

Entregable (Proyecto 4, parte 2): agente de soporte con tool inventory, límites de autonomía documentados, y evaluación con AST-based LLM grading (Bonnie Xu, Kepler).

Criterio: maneja 3 flujos completos (estado de pedido, devolución, escalado) sin alucinar; los 5 fail modes tienen escape hatch verificado.

Semana 9 — Sistemas multi-agente y agents de datos

Objetivos medibles:

• Diseñar un sistema de 2–3 agents para análisis de datos (explorar → detectar anomalías → proponer features).
• Aplicar un framework de coordinación (CoALA / jerarquía) y justificar por qué no es un solo agente.
• Evaluar la calidad de las sugerencias del agente.

Lecturas InfoQ:

• “Why Agentic Compute is the Missing Layer” — Arun Joseph (ephemeral agents, ADL).
• “Data-Aware AI Agents at OpenAI” — Bonnie Xu (Kepler, 600PB).
• “Agentic Fitness Functions” — Hemant Kumar Mahato et al. (ago 2026).

Entregable (Proyecto 4, parte 3): agente de análisis que explora un dataset de ecommerce, reporta anomalías (ej. categoría con conversión cayendo, stock creciente) y propone features, con evidencia.

Criterio: ≥1 anomalía real detectada con evidencia reproducible; ≥1 feature propuesta integrable al feature store; evaluación de calidad documentada.

Semana 10 — Plataforma interna de IA/ML

Objetivos medibles:

• Decidir qué se centraliza (model registry, feature store, inference gateway, guardrails) vs. qué es federado.
• Diseñar routing de workloads (latencia-crítico vs. no-crítico) y políticas de cost control.
• Diseñar la capa de datos para agents vía MCP + semantic models.

Lecturas InfoQ:

• “The AI Gateway: Scaling Centralized Inference across Decentralized Teams” — Meryem Arik (may 2026).
• “Architecting the Data Layer for AI Agents” — Fabiane Nardo (MCP, semantic models).
• “Powering the Future” — Merrin Kurian (fixed/flexible/free, self-serve).

Entregable: diagrama de arquitectura de la plataforma + políticas de routing/cost + jerarquía de agents + 2 ADRs (centralización vs. federación; gateway vs. directo).

Criterio: el diagrama identifica dueños, contratos y SLAs de cada pieza; cost control tiene caps y rate limits explícitos.

---

Módulo 4 — Seguridad, Privacidad, Gobernanza (S11–S13)

Semana 11 — Privacidad y protección de datos (PIPL/DSL/MLPS)

Objetivos medibles:

• Mapear todos los flujos de datos sensibles del sistema (usuario, pedido, comportamiento, financiero).
• Aplicar minimización, pseudonimización y consent management en ≥1 flujo.
• Enumerar las obligaciones PIPL/DSL/MLPS aplicables y las lagunas.

Lecturas InfoQ:

• AI Security & Privacy Engineering (PDF) semanas 1–2: sensitive data flows, LINDDUN.

Lecturas externas (gap crítico):

• PIPL (Personal Information Protection Law of China) — texto oficial CAC + resúmenes de firmas legales (Hunton Andrews Kurth, Morrison & Foerster, Bird & Bird).
• DSL (Data Security Law) — clasificación de datos.
• MLPS 2.0 (GB/T 22239-2019) — niveles de protección de redes; obligaciones por nivel.
• Casos de implementación: whitepapers de Alibaba Cloud / JD Cloud sobre data localization y compliance.

Ejercicio: aplicar pseudonimización a la tabla de usuarios del feature store y verificar que las features siguen siendo útiles (re-join correcto).

Entregable: diagrama de flujos de datos sensibles + matriz de cumplimiento (obligación → control → estado) + 1 control implementado.

Criterio: ≥1 control real funcionando (pseudonimización o gate de consentimiento); matriz de cumplimiento con lagunas explícitas.

Semana 12 — Threat modeling, red teaming y guardrails

Objetivos medibles:

• Aplicar LINDDUN o STRIDE al sistema (≥5 amenazas priorizadas).
• Ejecutar red teaming sobre el chatbot (prompt injection, jailbreak, extracción de datos de otros usuarios).
• Implementar guardrails (sanitización de input, filtro de output, sandbox).

Lecturas InfoQ:

• AI Security & Privacy Engineering (PDF) semanas 2–3.
• “Securing MCP in Production: Defense-in-Depth beyond the Gateway” — Nik Kale (jul 2026).

Lecturas externas:

• OWASP Top 10 for LLM Applications.
• Guardrail models open-weight (referencias por nombre, sin deep-links fabricados).

Ejercicio: 10 ataques al chatbot; documentar éxito/parcial/fallo de cada uno.

Entregable: reporte de red teaming (ataques, mitigaciones, limitaciones restantes) + guardrails desplegados.

Criterio: ≥5 ataques intentados; los de extracción de datos sensibles bloqueados; reporte con limitaciones honestas.

Semana 13 — Observabilidad de seguridad y gobernanza

Objetivos medibles:

• Instrumentar señales de seguridad (injection detectado, output bloqueado, acceso anómalo) y de privacidad (volumen procesado, consentimientos).
• Construir paneles de auditoría.
• Definir roles/responsabilidades y proceso de auditoría periódica.

Lecturas InfoQ:

• AI Security & Privacy Engineering (PDF) semana 4 (observabilidad, Arize Phoenix).
• Noticias: “Multi-Agent AI for Production Security Operations” (MTTR −40%), “Virtual panel: Security in the Machine Age”.

Entregable: extensión del dashboard de evaluación (S6) con señales de seguridad/privacidad + plan de gobernanza (quién audita qué, cada cuánto).

Criterio: señales visibles en dashboard; plan de gobernanza con dueños y cadencia.

---

Módulo 5 — Liderazgo, Estrategia, Ética (S14–S16)

Semana 14 — Estrategia técnica para IA/ML en ecommerce

Objetivos medibles:

• Redactar una estrategia de 1–2 páginas: problema de negocio → opciones → trade-off → señales tempranas de error → hitos.
• Identificar qué supuestos del stack actual rompe el “AI pace of change”.

Lecturas InfoQ:

• Engineering Leadership (PDF) semana 2: technical strategy socio-técnica.
• “An Evolutionary Architecture Pattern for Managing AI’s Pace of Change” — Joe Price et al. (jul 2026).
• “Agentic AI Architecture Framework for Enterprises” — Natarajan + Ponnusamy.

Entregable: documento de estrategia + 2 ADRs de arquitectura.

Criterio: estrategia tiene early-warning metrics accionables y un “kill switch” claro (cuándo abandonar).

Semana 15 — Medición, accountability y operaciones

Objetivos medibles:

• Clasificar KPIs en participation/knowledge/behavior/outcomes (sin caer en Goodhart).
• Definir KPIs de negocio (no solo de modelo): conversión, revenue lift, CSAT, tasa de resolución por el agente.
• Escribir un plan de incident response para recomendación/chatbot.

Lecturas InfoQ:

• Engineering Leadership (PDF) semana 4: Goodhart’s law, sampling cualitativo.
• “Leadership in AI-Assisted Engineering” — Justin Reock (Cobra Effect en métricas).
• “The Ironies of A²I²” — J. Paul Reed (erosión de skills manuales).
• “AI Operational Excellence” — AI Engineering (PDF) semana 5.

Entregable: sistema de medición (KPIs + señales de operaciones + plan de incident response + cadencia de revisión con sampling cualitativo).

Criterio: cada KPI tiene dueño, umbral y acción; incident response con roles y runbook.

Semana 16 — Ética, sesgos, responsabilidad + Capstone

Objetivos medibles:

• Documentar sesgos identificados (popularidad, precio, contenido) y sus mitigaciones.
• Definir supervisión humana y límites de autonomía de agents.
• Integrar TODO en un capstone presentable.

Lecturas InfoQ:

• “The Next Generation of AI Products” — Hilary Mason (human considerations, mentalidad probabilística).
• AI Engineering (PDF) semana 5: capstone.

Entregable final (Capstone): sistema integrado (pipeline + feature store + recomendador con MLOps/eval + chatbot RAG + agente de soporte + análisis de datos) con:

• Arquitectura completa documentada.
• Evaluación multicapa.
• Plan de seguridad/privacidad/cumplimiento.
• Plan de operaciones y medición.
• Documentación de sesgos y mitigaciones.
• Un “unresolved architectural question” (formato de cierre InfoQ).

Criterio: presentación de 20 min + discusión de 30 min; el sistema completo corre de punta a punta.

---

PARTE C — Especificaciones de proyectos de portafolio

Proyecto 1 — Pipeline de eventos de ecommerce + calidad de datos

• Alcance: ingesta (Kafka/RocketMQ) → validación de esquema → data lake (Hudi/Iceberg) → tablas snapshot+incremental → suite de calidad (Great Expectations/Soda) → lag dashboard.
• Dataset: sintético (generador de eventos; ~1M+ eventos), o público (ej. RetailRocket, Tmall/JD datasets si son accesibles).
• Entregables: repo + README reproducible + 1 ADR + tests + dashboard.
• Competencias demostradas: ingesta a escala, CDC, data contracts, observabilidad de datos.

Proyecto 2 — Feature store + recomendador + MLOps + evaluación

• Alcance: feature store (Feast/Tecton/DIY) → ranker (LightGBM/two-tower) → training pipeline (DVC+MLflow) → serving (<50ms p95) → canary+rollback → evaluación 5 capas.
• Entregables: endpoint de serving, reporte offline/online, gates de calidad/fairness, dashboard multicapa.
• Competencias: MLOps, evaluación, sesgo, feature engineering.

Proyecto 3 — RAG search + chatbot + agente de soporte + agente de análisis

• Alcance: vector DB (Milvus/Qdrant) → RAG con citas y multi-turno → agente de soporte (tools + escape hatches) → agente de análisis (anomalías + propuestas de features).
• Entregables: búsqueda semántica, chatbot evaluado (LLM-as-judge + AST grading), reporte de red teaming, guardrails.
• Competencias: RAG/context engineering, agents, seguridad, evaluación de agents.

Proyecto 4 — Privacidad, seguridad y gobernanza (transversal)

• Alcance: mapeo de flujos sensibles → matriz PIPL/DSL/MLPS → pseudonimización/consent → threat modeling → red teaming → observabilidad de seguridad → plan de gobernanza.
• Entregables: diagrama de flujos, matriz de cumplimiento, reporte de red teaming, dashboard de seguridad.
• Competencias: cumplimiento regulatorio chino, seguridad de IA, gobernanza.

Proyecto 5 — Estrategia + operaciones + capstone

• Alcance: estrategia técnica → KPIs de negocio → plan de incident response → integración total → presentación.
• Entregables: doc de estrategia, sistema de medición, runbooks, capstone (20min+30min).

---

PARTE D — Fuentes externas (huecos que InfoQ no cubre)

D.1 Regulación china (PIPL, DSL, MLPS)

• PIPL (Personal Information Protection Law of China, vigente nov 2021): texto oficial en el sitio del CAC (Cyberspace Administration of China); resúmenes prácticos de firmas legales internacionales (Hunton Andrews Kurth, Morrison & Foerster, Bird & Bird, DigiChina).
• DSL (Data Security Law, vigente sep 2021): clasificación de datos y obligaciones de protección.
• MLPS 2.0 (Multi-Level Protection Scheme, GB/T 22239-2019): niveles de protección de redes y obligaciones técnicas por nivel.
• Data localization: requisitos de almacenamiento local para datos personales en operaciones dentro de China.
• Casos de implementación: whitepapers/documentación de Alibaba Cloud, JD Cloud, Tencent Cloud sobre compliance y residencia de datos.

D.2 Infra y modelos locales

• Mensajería/streaming: Apache RocketMQ (origen Alibaba), Apache Pulsar.
• Bases de datos: PolarDB (Alibaba, PostgreSQL-compatible), Lindorm (multi-model), AliGraph (grafo).
• Vector DBs: Milvus / Zilliz Cloud (origen China), también Faiss/Qdrant.
• LLMs chinos: Qwen (Alibaba), DeepSeek, GLM/ChatGLM (Zhipu AI), Yi (01.AI).
• GPUs: restricciones de exportación de hardware avanzado a China; Huawei Ascend (NPU) y alternativas locales; impacto en entrenamiento/serving.

D.3 Técnicas de recomendación del mercado chino

• Alibaba: GNN para recomendación, AliRec, session-based recommendation.
• JD: multi-task learning para predicción conjunta de CTR/conversión.
• PDD: señales de social commerce.
• Temas transversales: sesgo de popularidad en catálogo masivo, cold-start de nuevos SKUs, feedback loops en millones de productos.
• Fuentes: papers de KDD, RecSys, CIKM con autores de Alibaba/JD/PDD; blogs de ingeniería en chino (Alibaba Tech, JD Tech, Meituan Tech).

D.4 Mandarín técnico

• Lectura de documentación técnica en chino (blogs de ingeniería citados arriba).
• Comunicación técnica en mandarín para equipos que operan en China.

D.5 Ética/responsabilidad en marco regulatorio chino

• Cómo se estructura la gobernanza de IA en empresas chinas (seguridad/privacidad/ethics).
• Interpretación de responsabilidad de sistemas de IA bajo el marco regulatorio chino.

---

PARTE E — Plan de lectura integrado (prioridad)

Prioridad alta (leer antes de construir):

1. DoorDash “From Models to Agents” — Sudeep Das → S4, S8, S9
2. “Architecting the Data Layer for AI Agents” — Fabiane Nardo → S3, S7, S10
3. “What I Learned Building Multi-Agent Systems” — Paulo Arruda (offset 53+) → S8, S9
4. “Why Agentic Compute is the Missing Layer” — Arun Joseph → S10
5. AI Engineering (PDF) semanas 2, 3, 5 → S7, S8, S15
6. “The Next Generation of AI Products” — Hilary Mason → S16
7. “Beyond Prompting: Context Engineering” — Ricardo Ferreira → S7

Prioridad media (según tema):

• “Powering the Future” — Merrin Kurian → S10
• “Building Evals for AI Adoption” — Mallika Rao → S6
• “Netflix Commerce Architecture” — Kasia Trapszo → S14
• AI-Assisted Engineering (PDF) semanas 1, 2, 4 → S1, S3
• AI Security & Privacy (PDF) semanas 1–5 → S11–S13
• Engineering Leadership (PDF) semanas 1, 2, 4 → S14, S15

Prioridad baja (consultar):

• eMags (Agentic AI Architecture, Socio-Technical Craft, AI-Assisted Dev)
• “Write-Ahead Intent Log”, “Beyond Offset Lag” (Hudi) → S1
• “Securing MCP in Production”, “Designing AI Platforms for Reliability”, “Leadership in AI-Assisted Engineering”
• Noticias del feed + podcasts

---

PARTE F — Cierre y guía de retoma (para la siguiente sesión)

Estado del curso: completo (16 semanas con objetivos, lecturas, ejercicios, entregables y criterios).

Qué falta para “terminar” (no del curso, sino del trabajo del usuario):

• Elegir stack concreto por proyecto (open-source vs. cloud managed).
• Generar el dataset sintético y arrancar el Proyecto 1 (Semana 1).
• Extraer los transcripts pendientes de InfoQ (bloqueo de crawler; usar navegador — Chrome falló al arrancar en esta sesión).
• Investigar a fondo las fuentes externas de la Parte D (regulación, infra china, recsys).

Próximas acciones sugeridas (elegir una):

1. Bootstrappear el Proyecto 1 (repo, generador de eventos, broker Docker, pipeline mínimo).
2. Armar un plan de ejecución con stack concreto y estimación de horas por semana.
3. Investigar fuentes específicas de PIPL/MLPS/infra china con búsqueda focalizada.

---

Sin secretos. Fuentes de InfoQ son públicas; fuentes externas referenciadas por nombre/organización para evitar deep-links fabricados.