Módulo 1: Genai In Production Vs A Notebook
2. Un notebook y un sistema en producción no son el mismo problema
Descripción
cloud-security-and-guardrails-guide abrió con una lección que separó lo que un plan limpio, un apply exitoso y un pipeline en verde confirman de verdad, de lo que un lector apurado asume que confirman — y la conclusión fue que nada de eso confirma que el sistema sea seguro. finops-and-cost-guardrails-guide repitió el ejercicio con la misma disciplina, y llegó a la misma estructura de conclusión para una pregunta distinta: nada de eso confirma que el sistema sea barato. Esta lección hace el mismo ejercicio una tercera vez, con una señal distinta a las dos anteriores — no un pipeline en verde, sino una respuesta correcta en el playground interactivo de Bedrock — y con una pregunta que ninguna de las dos guías anteriores necesitó hacerse, porque ninguna de las dos trabajaba con un componente no determinista: ¿una respuesta que se ve bien, en una consola de prueba, confirma que ese mismo modelo es seguro, barato y confiable corriendo en producción?
La respuesta, otra vez, es no. Y esta vez la razón de fondo es más profunda que en las dos lecciones anteriores: un plan limpio y una respuesta correcta del playground no fallan por el mismo motivo. Un plan limpio no dice nada sobre seguridad o costo porque nunca evaluó esas preguntas — la herramienta hace exactamente lo que promete, solo que promete algo distinto. Una respuesta correcta del playground tiene un problema adicional, propio de esta guía: ni siquiera garantiza que la misma pregunta, mañana, con la misma entrada, produzca la misma respuesta.
Conexión con el módulo
La lección 1 te dio el mapa completo y el compromiso de honestidad de esta guía. Esta lección instala la razón de fondo por la que esa honestidad importa más aquí que en cualquier guía anterior: si "funciona en el playground" ya significara "funciona en producción", el resto de esta guía —costo, guardrails, seguridad, observabilidad— sería un ejercicio decorativo. La lección 3, inmediatamente después, aterriza esta idea abstracta en el problema real y concreto de Andes Cargo: el manifiesto en texto libre que process-shipment-manifest no puede leer.
Analogía: cocinar para ti mismo y abrir un restaurante
Cocinar un plato nuevo para ti mismo, un domingo por la tarde, y decidir abrir un restaurante que sirve ese mismo plato son, en apariencia, la misma tarea: alguien sigue una receta y produce comida. En la práctica son dos problemas casi sin relación. Cocinar para ti mismo exige, sobre todo, que la receta funcione: que el sabor salga bien, que la textura sea la correcta, que el tiempo de cocción esté calibrado. Si algo sale mal, lo comes de todas formas o pides una pizza — el costo del error es tuyo, y termina ahí. Abrir un restaurante con ese mismo plato exige resolver un conjunto de problemas completamente distinto, la mayoría de los cuales no tienen nada que ver con la receta: ¿cuánto cuesta cada porción si el precio del ingrediente principal sube la semana que viene? ¿Qué pasa si un cliente tiene una alergia que el plato no declara? ¿Puede la cocina servir cien porciones en una noche sin que la calidad se caiga en la porción ochenta? ¿Quién revisa que el proveedor de hoy entregó lo mismo que el de la semana pasada? La receta —el plato en sí— es, de las cien decisiones que exige abrir un restaurante, probablemente la más fácil de las cien.
Un modelo de lenguaje respondiendo bien en el playground de Bedrock es la receta que funciona un domingo por la tarde. El resto de esta guía —los ocho módulos completos— es todo lo demás que exige abrir el restaurante: cuánto cuesta por porción servida (M2, M6), qué pasa si alguien intenta hacerle decir algo que no debería (M4), si la infraestructura que lo sirve está declarada y verificada (M3, M5), si puede atender cien solicitudes sin que el costo o la calidad se caigan (M7), y quién es responsable de que siga funcionando así mañana (M8). El plato es lo de menos. Esta guía entera es todo lo demás.
Qué confirma, de verdad, una respuesta correcta en el playground
Cuando escribes un texto de prueba en la consola interactiva de Bedrock y el modelo responde con exactamente los campos que esperabas — shipmentId, originCountry, destinationCountry, weightKg — eso confirma, con certeza razonable, tres cosas: el modelo elegido es capaz, en principio, de extraer ese tipo de información de ese tipo de texto; el prompt que escribiste, para esa entrada específica, produjo la salida esperada; y la cuenta que estás usando tiene acceso habilitado a ese modelo. Eso es todo lo que una respuesta correcta del playground promete. No confirma que la misma llamada, corrida mañana con la misma entrada, produzca exactamente la misma salida — es la naturaleza de un modelo de lenguaje, no un defecto de esta llamada en particular. No confirma que la llamada, corriendo cien veces al día durante un mes, quepa dentro de ningún presupuesto razonable. No confirma que un tercero que descubra el endpoint no pueda manipular el prompt para extraer información que no debería. No confirma que el rol que invoca el modelo tenga permiso acotado a ese modelo específico, en vez de a bedrock:*. El playground evalúa capacidad puntual del modelo — ¿puede este modelo, en principio, hacer esto? —, nunca postura operativa — ¿debería este sistema, en producción, funcionar así?
Qué NO confirma sobre costo
Una respuesta del playground no lleva ninguna etiqueta de precio adjunta, y eso es fácil de olvidar cuando la respuesta llega en segundos, gratis en apariencia. Bedrock cobra por token — de entrada y de salida, por separado, con precios distintos —, no por hora de consola abierta. Una prueba en el playground de diez líneas de texto no anticipa nada sobre el costo de procesar diez mil manifiestos al mes, con textos de longitud variable, algunos de los cuales el modelo podría necesitar reintentar. El M2 completo de esta guía existe porque esta pregunta —¿cuánto cuesta de verdad, a escala?— no tiene respuesta sin declarar, explícitamente, un supuesto de volumen. Ninguna herramienta, ni el playground, ni Infracost, puede adivinarlo.
Qué NO confirma sobre seguridad
Una respuesta correcta en el playground corre con las credenciales de quien está sentado frente a la consola, sin ningún guardrail activo por defecto, sin que nadie haya intentado todavía manipular el prompt con una instrucción oculta, sin que el texto de prueba contenga información sensible real. Ninguna de esas tres condiciones es la que enfrentaría este mismo modelo en producción, recibiendo manifiestos de socios logísticos externos, algunos de los cuales — sin mala intención, o con ella — podrían incluir texto diseñado para que el modelo ignore sus instrucciones originales. El M4 y el M5 de esta guía existen exactamente para esa brecha: un guardrail gestionado declarado como código, un chequeo propio como defensa en profundidad, y mínimo privilegio de IAM acotado al ARN de un modelo específico — ninguno de los tres existe todavía cuando alguien prueba un texto en el playground.
Qué NO confirma sobre confiabilidad
Esta es la pregunta que ninguna guía anterior de este ecosistema necesitó hacerse con esta intensidad, porque ninguna trabajaba con un componente fundamentalmente no determinista. process-shipment-manifest, la función heredada de aws-core-services-guide, produce el mismo resultado para el mismo manifiesto, siempre — es la garantía que sostiene, literalmente, cada bloque "Qué esperar (literal)" de las siete guías anteriores de este ecosistema. Un modelo de lenguaje no ofrece esa garantía: el mismo texto de entrada, en dos llamadas distintas, puede producir una extracción ligeramente distinta, incluso con la temperatura del modelo configurada al mínimo. Una respuesta correcta en el playground, una sola vez, no dice nada sobre la tasa de éxito de esa misma llamada corriendo mil veces. El M7 de esta guía construye el vocabulario —SLI, SLO, error budget— para hablar de esta realidad con precisión en vez de con vaguedad, y la métrica más honesta que esta guía puede ofrecer sin invocar Bedrock de verdad: la tasa de escalamiento del camino determinista al camino probabilístico, un número real, calculable sin ni una sola invocación del modelo.
El inventario honesto: lo que "funciona en el playground" todavía no contestó
| Lo que el playground confirmó | Lo que el playground nunca preguntó |
|---|---|
El modelo puede extraer shipmentId/originCountry/destinationCountry/weightKg de un texto de prueba | ¿Cuánto cuesta procesar diez mil manifiestos reales al mes, con ese mismo modelo? (M2, M6) |
| La cuenta de prueba tiene acceso habilitado al modelo elegido | ¿Qué rol invoca el modelo en producción, y con qué alcance exacto de permiso? (M3, M5) |
| La respuesta, para ese texto específico, tuvo la forma esperada | ¿Qué pasa si el texto de entrada intenta manipular el prompt para que ignore sus instrucciones? (M4) |
| Nadie interrumpió la sesión de prueba con un error | ¿La misma llamada, corrida mil veces, produce una tasa de éxito aceptable? (M7) |
| El texto de prueba no contenía información sensible real | ¿Qué pasa si un manifiesto real trae un número de documento o un teléfono personal? (M4) |
| La respuesta llegó en segundos, sin fricción visible | ¿Cuánto tarda esa misma llamada bajo carga real, y qué SLO es razonable prometer? (M7) |
Seis preguntas, ninguna contestada por "funciona en el playground", cada una con el módulo exacto de esta guía que la resuelve — la misma estructura de tabla que ya viste, con otro contenido, en las dos guías anteriores de este ecosistema.
Por qué esta lección no es una repetición, sino un paso más
Vale la pena decir, con precisión, en qué se diferencia esta lección de sus dos antecesoras, no solo que las imita. cloud-security-and-guardrails-guide M1.2 y finops-and-cost-guardrails-guide M1.3 trabajaban sobre una infraestructura determinista: una vez que Shipments está declarada como PAY_PER_REQUEST y el bucket como privado, esas propiedades no cambian entre una ejecución y la siguiente — el problema, en ambos casos, era que nadie había hecho la pregunta correcta todavía, no que la respuesta cambiara sola con el tiempo. Aquí el problema tiene una capa adicional: incluso si alguien hiciera la pregunta correcta de seguridad, de costo y de confiabilidad sobre una llamada específica al modelo, la respuesta a esa pregunta puede variar de una llamada a la siguiente, porque la salida del modelo mismo no es fija. Es la razón exacta por la que esta guía marca, sin excepción, toda salida de un modelo de Bedrock como "(representativo)" en el momento en que aparece — no por falta de rigor, sino porque presentarla como literal sería, en sí mismo, técnicamente falso.
Errores comunes
Concluir que "el playground no confirma nada" significa "el playground no sirve para nada" (de alcance). Qué pasa: alguien lee esta lección y empieza a desconfiar de probar ideas en el playground como paso de exploración. Cómo detectarlo: si tu reacción es "entonces no debería probar nada ahí". Cómo corregirlo: el playground sigue siendo la forma correcta y rápida de confirmar que un modelo, en principio, puede resolver un tipo de tarea — es exactamente el paso que precede a esta guía, no uno que esta guía reemplace. El punto no es que el playground sea inútil, es que confirma una sola de las seis preguntas de la tabla de arriba, y las otras cinco necesitan el resto de esta guía.
Pensar que "no determinista" significa "impredecible al azar, sin ningún patrón" (de definición). Qué pasa: alguien concluye que, si el modelo no es determinista, entonces cualquier salida es igual de probable que cualquier otra, sin poder razonar sobre ella en absoluto. Cómo detectarlo: si tu conclusión es "entonces no se puede confiar en nada de lo que produce". Cómo corregirlo: no determinista no significa aleatorio sin criterio — significa que la misma entrada puede producir salidas ligeramente distintas, casi siempre dentro de un rango razonable de calidad, no cualquier cosa. Es exactamente por eso que existen guardrails (M4), validación de esquema de salida (M4.6) y un arnés de smoke test (M7.6): herramientas diseñadas específicamente para poner límites razonables alrededor de una salida que varía, no para fingir que no varía.
Buscar, en esta lección, la afirmación de que Bedrock "es peor" que la infraestructura de las guías anteriores (de comparación equivocada). Qué pasa: alguien lee las seis preguntas sin contestar y concluye que Bedrock es una tecnología menos madura o menos confiable que S3 o DynamoDB. Cómo detectarlo: si tu resumen es "Bedrock tiene más problemas que el resto de AWS". Cómo corregirlo: la diferencia no es de calidad del servicio — es de naturaleza del problema. S3 y DynamoDB son deterministas por diseño; un modelo de lenguaje es probabilístico por diseño, con el mismo nivel de madurez de ingeniería detrás. La pregunta correcta nunca fue "¿es bueno Bedrock?" — es "¿qué cambia en cómo opero un sistema cuando una de sus piezas no es determinista?", y esa es, literalmente, la pregunta que el resto de esta guía contesta.
Ejercicios
Ejercicio 1 — Completa la tabla con una séptima fila propia. La tabla de esta lección tiene seis filas. Basándote en lo que ya sabes del caso Andes Cargo, propone una séptima pregunta que "funciona en el playground" tampoco contestó, y que no aparezca en la tabla.
Ver solución
No hay una única respuesta correcta, pero un ejemplo sólido: "¿Qué pasa si el volumen de manifiestos en texto libre crece de golpe —por ejemplo, si un socio logístico grande deja de enviar en formato clave=valor— y el sistema empieza a escalar al LLM mucho más de lo previsto?" — el playground nunca respondió eso porque nunca probó más de una llamada a la vez. Esa pregunta específica la contesta, en parte, el M6 de esta guía (bedrock-budget.rego, el step que detiene un supuesto de volumen desproporcionado antes del apply). Cualquier pregunta razonable sobre comportamiento a escala, no sobre una llamada aislada, cuenta como respuesta válida.
Ejercicio 2 — Explica la diferencia entre "el plan no confirma seguridad" y "el playground no confirma nada" con tus propias palabras. Un colega que ya hizo cloud-security-and-guardrails-guide te dice: "Ya sé que verde no es sinónimo de seguro, esto es lo mismo otra vez". Explícale en qué se diferencia esta lección de esa, más allá del dominio (seguridad contra confiabilidad de IA).
Ver solución
Una respuesta completa suena, más o menos, así: "Un plan limpio no confirma seguridad porque la herramienta nunca evaluó esa pregunta — pero, una vez aplicado, el recurso resultante (un bucket, un rol) tiene una postura de seguridad fija: privado o público, no cambia solo entre un momento y el siguiente. Una respuesta del playground tiene ese mismo problema, más uno adicional: incluso si alguien hiciera la pregunta correcta sobre esa llamada específica, la respuesta puede variar de una llamada a la siguiente, porque el modelo mismo no es determinista. No es solo que 'nadie preguntó todavía' — es que la propiedad que estarías preguntando no es fija en el tiempo del mismo modo que la política de un bucket sí lo es."
Ejercicio 3 — Predice qué módulo de esta guía resuelve cada una de las tres preguntas centrales. Sin mirar la tabla de esta lección, empareja cada una de estas tres preguntas con el módulo de esta guía que la resuelve: (a) ¿cuánto cuesta esto de verdad, a escala?; (b) ¿qué pasa si alguien intenta manipular el prompt?; (c) ¿qué tan seguido falla esta llamada, y qué tan rápido responde?
Ver solución
(a) Costo a escala → M2 (el modelo de costo de Bedrock, con la calculadora propia) y M6 (FinOps para tokens, el presupuesto integrado al gate). (b) Manipulación del prompt → M4 (guardrails de Bedrock y defensa en profundidad, incluida la política de detección de ataques de prompt). (c) Tasa de fallo y latencia → M7 (observabilidad, latencia y evals en producción, con los tres SLI de una carga de IA). Si emparejaste las tres correctamente, tienes clara la estructura completa de esta guía, no solo su primer módulo.
Resumen y siguiente paso
En esta lección separaste lo que una respuesta correcta en el playground de Bedrock confirma —capacidad puntual del modelo, para esa entrada específica— de lo que nunca preguntó: costo a escala, seguridad ante manipulación, confiabilidad bajo carga repetida. Viste el inventario honesto de seis preguntas sin contestar, cada una apuntando al módulo exacto de esta guía que la resuelve. Y viste por qué esta lección, aunque repite la estructura de "verde no es sinónimo de X" de las dos guías anteriores, agrega una capa que ninguna de las dos necesitó: la salida misma del sistema no es fija en el tiempo, así que ni siquiera contestar la pregunta correcta una vez es suficiente.
Antes de avanzar deberías poder: explicar, con la analogía del restaurante, por qué "la receta funciona" es la parte más fácil de operar un modelo en producción; nombrar las seis preguntas del inventario honesto y el módulo que resuelve cada una; y explicar la diferencia de fondo entre "nadie hizo la pregunta todavía" (las dos guías anteriores) y "la respuesta puede variar sola" (esta guía).
La lección 3 aterriza toda esta teoría en el problema real de Andes Cargo: el manifiesto en texto libre que process-shipment-manifest no puede leer, y la decisión de arquitectura que lo resuelve sin convertir al modelo en el camino principal.
Recursos
cloud-security-and-guardrails-guide, Módulo 1, lección 2 (02-green-does-not-mean-secure.md) — la primera iteración de este patrón, sobre seguridad.finops-and-cost-guardrails-guide, Módulo 1, lección 3 (03-green-does-not-mean-cheap.md) — la segunda iteración, sobre costo.- AWS — Amazon Bedrock — la consola de playground referenciada en esta lección, punto de partida conceptual, no el objeto de estudio de esta guía.
src/paths/aws-cloud-ecosystem/STRATEGY.md— el hallazgo de mercado citado en la lección 1: los ingenieros que "operan" aplicaciones de IA reales, no solo las prueban, obtienen primas de mercado significativas.