Módulo 1: Genai In Production Vs A Notebook
4. La frontera con AI Engineering, dicha en voz alta
Descripción
La lección 3 presentó extract-shipment-manifest-fields por su nombre, y dejó una pregunta abierta a propósito: ¿qué significa "construir" esa función, en el contexto de esta guía? La respuesta importa más de lo que parece, porque esta guía y el ecosistema AI Engineering —el que precede a este en el grafo de NIEVA— podrían, sin esta lección, terminar enseñando lo mismo dos veces, con nombres distintos. Esta lección existe para que eso no pase: fija, con una cita textual del diseño del propio ecosistema, exactamente dónde termina el trabajo de esta guía y dónde empieza el de AI Engineering — y lo hace en la lección 4, no al cierre de la guía, precisamente para que ninguna de las siguientes veintiocho lecciones tenga la tentación de cruzarla sin darse cuenta.
Conexión con el módulo
Las lecciones 1 a 3 construyeron el contexto: qué se hereda, por qué "funciona" no es "listo para producción", y cuál es el problema real que motiva esta guía. Esta lección responde la pregunta que ese contexto deja abierta: si extract-shipment-manifest-fields va a invocar un modelo, ¿quién decide qué le dice al modelo? La lección 5, inmediatamente después, vuelve a terreno concreto — el inventario real de lo que ya existe en andes-cargo-infra/ — con esta frontera ya instalada como criterio de lectura para el resto de la guía.
Analogía: el manual de operaciones del restaurante, no el recetario
Retoma el restaurante de la lección 2. Un restaurante que funciona necesita dos documentos completamente distintos, escritos por dos personas distintas, con dos habilidades distintas. El recetario — qué ingredientes lleva cada plato, en qué orden, con qué técnica — lo escribe alguien que sabe cocinar: un chef, con años de práctica en sabor, textura, presentación. El manual de operaciones — a qué temperatura se refrigera cada ingrediente, cuántas porciones puede servir la cocina por hora sin que la calidad se caiga, qué pasa si un proveedor no entrega a tiempo, cuánto cuesta cada plato servido y cómo se factura — lo escribe alguien completamente distinto: quien opera el restaurante como negocio. Ninguno de los dos roles necesita las habilidades del otro para hacer bien el suyo. Un gerente de operaciones excelente no necesita saber por qué una reducción de vino funciona con carne roja; un chef excelente no necesita saber cómo se negocia un contrato de suministro. Esta guía es el manual de operaciones. AI Engineering es el recetario. El prompt que hace que extract-shipment-manifest-fields extraiga bien los campos de un manifiesto es la receta — y esta guía la usa, mínima y honesta, sin pretender escribirla mejor de lo que necesita.
La cita, textual, del diseño del ecosistema
src/paths/aws-cloud-ecosystem/STRATEGY.md, la investigación de mercado que sostiene el diseño de todo este ecosistema, fija la posición de esta guía en el grafo completo de NIEVA con una frase que vale la pena leer despacio:
"Esto encaja con la posición del ecosistema en el grafo: viene después de AI Engineering. El alumno llega sabiendo construir sistemas de IA. Aquí aprende a operarlos en AWS."
Y, más adelante, en la lista de razones de fondo que justifican el diseño completo del ecosistema:
"Continuidad desde AI Engineering: el alumno llega sabiendo construir sistemas de IA. No repite fundamentos: aprende a operarlos."
Dos frases, la misma idea repetida por precisión, no por descuido: construir y operar son dos habilidades distintas, enseñadas por dos ecosistemas distintos, en un orden específico (BACKEND → AI ENGINEERING → AWS CLOUD). El ecosistema AI Engineering —que este diseño asume completo, como prerequisito, desde su primera lección— ya te enseñó a escribir un prompt efectivo, a diseñar una cadena de razonamiento, qué es RAG, qué es un agente, cómo evaluar la calidad semántica de una respuesta. Esta guía toma eso como dado. No lo repite, no lo simplifica, no lo vuelve a explicar con otro ejemplo. Lo asume, exactamente como asume que ya sabes qué es un resource de Terraform.
Hay una tercera cita, del mismo documento, que explica por qué esta distinción importa tanto para el mercado, no solo para la estructura pedagógica de este ecosistema:
"La escasez de talento en desarrollo de Gen AI en producción es severa. Los ingenieros que pueden demostrar que construyen, despliegan y operan aplicaciones de IA generativa reales —no solo hablar de IA— están obteniendo primas de mercado significativas."
El hueco de mercado que esta guía existe para llenar no es "sabe usar un LLM" — eso ya lo cubre AI Engineering, y el mercado ya tiene señal de sobra sobre esa habilidad. El hueco es "sabe operar un LLM en producción, con presupuesto, guardrails y observabilidad reales" — una habilidad distinta, escasa, y es exactamente la que estas ocho lecciones y los siete módulos siguientes construyen.
La frontera, en una tabla, con el módulo exacto donde se aplica
| Esta guía SÍ construye | Esta guía NO construye — es AI Engineering |
|---|---|
La infraestructura que corre extract-shipment-manifest-fields (Lambda, rol IAM, permisos) — M3 | El prompt que hace la extracción en sí — ya lo sabes hacer |
| El guardrail gestionado de Bedrock, declarado como código — M4 | Prompt engineering avanzado, técnicas de guardrail a nivel de aplicación |
| Un guardrail propio como defensa en profundidad (scrubber de PII, validador de esquema) — M4 | RAG, bases de conocimiento, embeddings, recuperación semántica |
Mínimo privilegio de IAM para bedrock:InvokeModel — M3, M5 | Agentes, function calling, orquestación de razonamiento multi-paso |
| El modelo de costo por token, la calculadora propia — M2, M6 | Evaluación semántica de calidad de una respuesta ("¿esta extracción es buena?") |
| El security gate y el cost gate, extendidos al Terraform nuevo — M5, M6 | Técnicas de reducción de alucinaciones a nivel de aplicación |
| SLI/SLO de una carga de IA: escalamiento, latencia, tasa de bloqueo — M7 | Fine-tuning, entrenamiento o ajuste de un modelo propio |
| El arnés de smoke test — estructura de comparación, no la métrica de calidad — M7 | La métrica de calidad semántica que ese arnés compararía en producción real |
Fíjate en el patrón de la columna izquierda: cada elemento es una pregunta sobre cómo corre el sistema en producción — quién puede invocarlo, cuánto cuesta, qué lo protege, qué lo observa. Cada elemento de la columna derecha es una pregunta sobre qué le dice uno al modelo y qué tan bien responde. Esa es la línea, y se mantiene sin excepción durante el resto de esta guía.
Por qué el prompt de esta guía es mínimo, y por qué eso es intencional
Cuando extract-shipment-manifest-fields aparezca con código real, en el M3 y el M4, el prompt que usa para extraer shipmentId/originCountry/destinationCountry/carrier/weightKg de un texto libre va a ser corto, directo, y — a propósito — no una pieza de ingeniería de prompt pulida. No vas a ver técnicas de few-shot, ni cadenas de razonamiento, ni una estructura de mensajes de sistema elaborada. Esto no es descuido: es la misma disciplina que sostiene toda la guía. Si el prompt fuera el centro de atención de una lección, esta guía estaría, sin darse cuenta, reescribiendo AI Engineering con otro nombre. El punto de cada lección de aquí en adelante nunca es qué le dice el sistema al modelo — es cómo esa llamada corre en producción: con qué rol, bajo qué guardrail, con qué presupuesto, observada con qué métrica.
Esto tiene una consecuencia práctica que vale la pena anticipar: cada vez que una lección de esta guía roce la tentación de profundizar en prompting, la respuesta correcta no es explicarlo mejor — es nombrarlo, y seguir. Vas a ver esa disciplina aplicada, en voz alta, varias veces a lo largo de esta guía, empezando por la propia lección 5 del M7 ("Qué es un eval en producción, y por qué no es un test unitario"), que traza esta misma frontera para la evaluación de calidad.
Lo que pasa si esta frontera se cruza sin darse cuenta
Vale la pena nombrar el riesgo concreto, no solo la regla abstracta. Si esta guía profundizara en prompt engineering, terminaría enseñando una versión más débil de lo que AI Engineering ya enseña a fondo — porque el foco de este ecosistema, deliberadamente, está en otro lado. Y si AI Engineering, en algún punto de su propio temario, empezara a explicar cómo se declara un aws_bedrock_guardrail en Terraform, terminaría enseñando una versión más débil de lo que esta guía enseña a fondo. Ninguno de los dos ecosistemas gana repitiendo al otro con menos profundidad — cada uno gana siendo la fuente definitiva de su propia mitad del problema, y remitiendo con precisión a la otra guía cuando la pregunta cruza la línea. Es exactamente el mismo principio de "hereda sin repetir" que ya viste en la lección 1 aplicado hacia atrás, en el tiempo, hacia AI Engineering, en vez de hacia las siete guías de AWS.
Errores comunes
Esperar que el M3/M4 enseñen a escribir un prompt mejor (de expectativa). Qué pasa: alguien llega al M4 esperando una lección sobre técnicas de prompting para mejorar la extracción. Cómo detectarlo: si tu pregunta después del M4 sigue siendo "¿cómo hago que el modelo extraiga mejor los campos?". Cómo corregirlo: esa pregunta es, literalmente, territorio de AI Engineering — el curso que este diseño asume completo. El M4 de esta guía enseña qué guardrail rodea esa llamada, no cómo mejorar la llamada en sí. Si la respuesta a esa pregunta no te resulta obvia con lo que ya sabes de AI Engineering, es la señal exacta de que ese prerequisito, para ti, todavía no está firme.
Pensar que "no construye el prompt" significa "no le importa la calidad de la extracción" (de alcance). Qué pasa: alguien concluye que a esta guía no le interesa si extract-shipment-manifest-fields funciona bien. Cómo detectarlo: si tu resumen es "esta guía es puro DevOps, sin ninguna preocupación por si el sistema hace lo que promete". Cómo corregirlo: el M4.6 (validador de esquema de salida) y el M7.6 (el arnés de smoke test) sí verifican que la salida tenga la forma correcta, con código real, ejecutado. Lo que esta guía no hace es evaluar la calidad semántica de esa salida —¿el modelo entendió bien el matiz de este texto específico?—, que es una pregunta distinta, y la que sí es territorio de AI Engineering. Forma correcta (esta guía) y calidad semántica (AI Engineering) son dos capas de verificación distintas, ambas necesarias, ninguna sustituto de la otra.
Confundir "el prompt es mínimo" con "el prompt no importa" (de lectura apurada). Qué pasa: alguien lee que el prompt de esta guía es "mínimo, no pulido" y concluye que cualquier texto vago serviría igual. Cómo detectarlo: si tu conclusión es "entonces no importa qué le digo al modelo". Cómo corregirlo: mínimo no significa descuidado — significa suficiente para el caso real de Andes Cargo, sin la profundidad adicional que un caso de producción con más riesgo semántico exigiría, y sin duplicar contenido que otro ecosistema ya cubre a fondo. El prompt que vas a ver en el M3/M4 hace su trabajo; simplemente no es el objeto de estudio de ninguna lección.
Ejercicios
Ejercicio 1 — Clasifica cinco preguntas reales en la columna correcta. Sin mirar la tabla de esta lección, clasifica cada una de estas cinco preguntas como "esta guía" o "AI Engineering": (a) ¿qué rol de IAM puede invocar el modelo?; (b) ¿cómo estructuro el prompt para que el modelo ignore instrucciones ocultas en el texto de entrada?; (c) ¿cuánto cuesta procesar diez mil manifiestos al mes?; (d) ¿cómo mido si la extracción capturó el matiz correcto de un texto ambiguo?; (e) ¿qué guardrail gestionado bloquea información sensible antes de que salga del modelo?
Ver solución
(a) Esta guía — M3/M5, mínimo privilegio de IAM. (b) AI Engineering — es una técnica de prompt engineering orientada a resistir prompt injection a nivel de aplicación, no infraestructura (nota: el M4 de esta guía sí declara el guardrail gestionado que detecta ataques de prompt, pero estructurar el prompt mismo para resistirlos es la mitad que corresponde a AI Engineering). (c) Esta guía — M2/M6, el modelo de costo por token. (d) AI Engineering — evaluación semántica de calidad, explícitamente fuera de esta guía (M7.5 lo nombra sin construirlo). (e) Esta guía — M4, el guardrail gestionado declarado como código. Si clasificaste correctamente al menos cuatro de cinco, tienes clara la frontera de esta lección.
Ejercicio 2 — Explica, con la analogía de esta lección, por qué ninguno de los dos ecosistemas "gana" repitiendo al otro. Un compañero pregunta por qué esta guía simplemente no incluye un módulo completo de prompt engineering, "ya que de todas formas construye el sistema completo". Respóndele con la lógica de la analogía del restaurante.
Ver solución
Una respuesta completa suena, más o menos, así: "Porque el manual de operaciones de un restaurante y su recetario resuelven problemas distintos, escritos por gente con habilidades distintas — meter el recetario dentro del manual de operaciones no hace que el restaurante funcione mejor, solo hace que el manual sea más largo y menos enfocado en lo que un gerente de operaciones necesita resolver de verdad. Si esta guía agregara un módulo de prompt engineering, terminaría enseñando una versión más superficial de algo que AI Engineering ya enseña a fondo, con más tiempo y más ejemplos dedicados exclusivamente a eso. El alumno sale mejor preparado teniendo dos fuentes profundas y bien delimitadas que una sola fuente superficial que intenta cubrir todo."
Ejercicio 3 — Predice qué pasaría si esta guía no fijara esta frontera en la lección 4. Basándote en cómo están escritas las lecciones 1 a 3, ¿qué riesgo concreto corre el resto de esta guía si esta frontera se declarara recién en el M8, al cierre?
Ver solución
El riesgo concreto es que, sin la frontera fijada temprano, cada lección de los módulos M2 a M7 que menciona extract-shipment-manifest-fields tendría la tentación natural de "completar el ejemplo" profundizando un poco más en el prompt, en la estructura de la extracción, o en cómo mejorar la calidad de la respuesta — cada una de esas pequeñas desviaciones, sumadas a lo largo de siete módulos, terminarían convirtiendo esta guía en una versión diluida de un curso de AI Engineering, exactamente el resultado que el diseño de este ecosistema existe para evitar. Fijar la frontera en la lección 4, antes de que exista una sola línea de código del M3, le da a cada lección siguiente un criterio de corte inmediato: si la pregunta es sobre el prompt en sí, se nombra y se enlaza; si es sobre cómo corre en producción, se construye.
Resumen y siguiente paso
En esta lección fijaste, con citas textuales de src/paths/aws-cloud-ecosystem/STRATEGY.md, la frontera exacta entre esta guía y el ecosistema AI Engineering: esta guía opera —infraestructura, guardrails, costo, observabilidad—; AI Engineering construye —el prompt, RAG, agentes, evaluación semántica—. Viste la tabla completa de qué corresponde a cada lado, con el módulo exacto donde se aplica en esta guía, y por qué el prompt de extract-shipment-manifest-fields, cuando aparezca con código real, va a ser deliberadamente mínimo, no pulido.
Antes de avanzar deberías poder: citar, de memoria o cerca, la frase central de STRATEGY.md sobre por qué esta guía "opera, no repite fundamentos"; clasificar una pregunta nueva sobre extract-shipment-manifest-fields como "esta guía" o "AI Engineering" sin dudar; y explicar por qué un prompt mínimo es una decisión de diseño, no una limitación.
La lección 5 vuelve a terreno ejecutable: el inventario real de lo que ya existe en andes-cargo-infra/, con awslocal events list-rules, lambda list-functions e iam list-roles contra la infraestructura heredada — el punto de partida literal sobre el que se construyen los siete módulos siguientes.
Recursos
src/paths/aws-cloud-ecosystem/STRATEGY.md— la fuente completa de las tres citas de esta lección: la posición en el grafo, la continuidad desde AI Engineering, y el hallazgo de escasez de talento en Gen AI operado en producción.genai-on-aws-production-guide/DISENO.md, sección "Qué enseña esta guía (y qué NO)" — el detalle completo, módulo por módulo, de la frontera que esta lección resume.- El ecosistema AI Engineering (NIEVA) — el prerequisito completo que esta guía asume, nunca vuelve a explicar: prompting, function calling, RAG, agentes, evaluación semántica de calidad.