¿Qué es production readiness? La brecha entre una demo que funciona y una IA que corre el lunes
Production readiness es la disciplina de cerrar la brecha entre una demo que funcionó en la sala y una IA que corre sin supervisión sobre tráfico real. Principio 1: una demo no es un producto — la demo nunca ve la cola larga, el input adversario, el costo a un millón de llamadas, ni la acción irreversible. Las seis dimensiones que producción exige, cada una como un qué-significa y un qué-falla-si-la-salteás: costo, latencia, seguridad y guardrails, gobernanza, confiabilidad, accountability. La columna que compone el resto de esta subcategoría según dónde corre el sistema — Agentforce más el Einstein Trust Layer, donde la gobernanza viene de fábrica, y el stack fuera de plataforma, donde construís cada dimensión vos — con la disciplina de evaluación como la compuerta de deployment. Esta página es el mapa; cada dimensión recibe su propia página.
Una demo responde una pregunta: ¿puede el sistema hacer la cosa, una vez, sobre un input que vos elegiste, en una sala donde no hay nada en juego? Producción responde otra distinta: ¿sigue haciendo la cosa sobre los inputs que no elegiste, al volumen que no podés controlar, cuando una respuesta equivocada cuesta plata o una acción equivocada no se puede deshacer? Casi todo proyecto de IA que muere, muere en el espacio entre esas dos preguntas — el modelo funcionó en la demo, y después nadie construyó la ingeniería que una demo nunca te obliga a construir. Este es el principio 1: una demo no es un producto, y la brecha es la ingeniería. Production readiness es la disciplina de cerrar esa brecha a propósito, antes de que un usuario real encuentre el borde que vos no encontraste.
La razón por la que una demo miente es que nunca se cruza con las cuatro cosas con las que producción se cruza todos los días. Nunca se cruza con la cola larga — el usuario número mil que formula el pedido de una forma que tu puñado de casos de prueba nunca probó. Nunca se cruza con el input adversario — la persona que intenta hacer que el sistema diga o haga algo que no debería. Nunca se cruza con el costo a escala — un precio por llamada que es un error de redondeo en una demo y todo el business case a un millón de llamadas por mes (principio 6). Y nunca se cruza con la acción irreversible — la demo lee; producción escribe, reembolsa, borra, y envía, y no podés des-enviar un email a un cliente. El mapa de abajo es el conjunto de dimensiones que convierten "funcionó una vez" en "corre sin supervisión", y la columna que dice dónde se construye cada una.
Las dimensiones de production readiness
Un sistema está listo para producción cuando cada una de estas está respondida a propósito, no dejada al azar. Cada una es una disciplina con su propia página en esta subcategoría; acá está la versión de una línea de qué significa cada una y la falla específica que te pega si la salteás.
| Dimensión | Qué significa | La falla si la salteás |
|---|---|---|
| Costo | Conocer el precio por llamada y el total a volumen real — token budgets, la elección de tier de modelo, cachear el contexto repetido. | La cuenta que era trivial en la demo se vuelve todo el business case a escala, y al sistema lo matan por economía, no por calidad. |
| Latencia | La respuesta llega lo bastante rápido como para ser útil — elección de modelo, largo del prompt y del output, streaming para que el usuario vea una respuesta formándose. | Una respuesta correcta que llega demasiado lento es una respuesta equivocada para el usuario; abandona, o el timeout salta más arriba. |
| Seguridad / guardrails | Límites sobre lo que el sistema puede decir y hacer — chequeos de input y output, límites de alcance, un camino de rechazo para lo que queda afuera. | El input adversario consigue la respuesta que estaba buscando, o el sistema actúa con seguridad sobre un pedido que debería haber rechazado. |
| Gobernanza | PII manejada de forma lícita, la interacción registrada, el compliance demostrable — masking, reglas de retención, el audit trail. | Data del cliente se filtra a un lugar donde no debería, y cuando un auditor o un regulador pregunta qué pasó, no tenés registro para mostrar. |
| Confiabilidad | El sistema se mantiene en pie bajo condiciones reales — rate limits respetados, un fallback cuando el modelo está caído, un rollback cuando una release es mala. | Un parpadeo del proveedor o un deploy malo tira abajo la feature sin camino de vuelta, y la caída es visible para todos los usuarios a la vez. |
| Accountability | Un humano es dueño del resultado — una compuerta human-in-the-loop donde es de cara al cliente, y un trace de cada corrida (principios 8, 9, 11). | El sistema hace algo mal sin supervisión, nadie es responsable, y no hay reproducción para reconstruir cómo pasó. |
Estas no son un menú para elegir. Un sistema serio responde las seis, porque la que salteás es la que lo tira abajo — y la que salteás es casi siempre la que una demo te dejó ignorar. El resto de esta subcategoría es una página por dimensión: costo y latencia juntos (hacen trade-off entre sí), guardrails y seguridad, PII y gobernanza, human-in-the-loop y accountability, y deployment a producción para la mecánica de confiabilidad de sacar una release y traerla de vuelta. (Esas hermanas están saliendo junto a esta página; nombradas acá, linkeadas una vez que salgan.)
La columna: dos superficies, compuestas por dónde corre el sistema
Production readiness no es un solo conjunto de herramientas. Como grounding, prompting y evaluación antes que ella, las superficies se componen — son instrumentos complementarios que un ingeniero elige según dónde corre el sistema, nunca productos rivales para elegir entre ellos (principio 7). Las seis dimensiones de arriba son constantes; lo que cambia es cuánto de cada una te llega gratis versus cuánto construís vos, y eso lo decide dónde vive el sistema.
- Agentforce y el Einstein Trust Layer — cuando el agente corre en Agentforce dentro del modelo de seguridad de Salesforce, varias dimensiones llegan como gobernanza de fábrica. El Einstein Trust Layer se sienta entre el agente y el modelo y cubre un set bien establecido de controles: recuperación segura de datos que honra los permisos del usuario que corre, data masking para que la PII no quede expuesta al proveedor del modelo, zero data retention para que los prompts y las respuestas no se guarden ni se usen para entrenar un modelo externo, toxicity scoring sobre el output generado, y un audit trail de la interacción. El deployment va por el camino de release de la plataforma, y el escalamiento humano — pasarle la conversación a una persona — es una jugada de primera clase. Igual seguís siendo dueño de las dimensiones que el Trust Layer no gobierna: gobierna el lado del lenguaje, no lo que tus Actions hacen, así que el radio de impacto de una Action que puede escribir o borrar sigue siendo tuyo para acotar (principio 5).
- El stack fuera de plataforma — cuando el sistema corre fuera de plataforma, sobre la Claude API y tu propia infraestructura, cada dimensión es tuya para construir. Vos fijás el presupuesto de costo y el tier de modelo, vos reducís la latencia con elección de modelo y streaming, vos escribís los guardrails y los caminos de rechazo, vos enmascarás la PII y mantenés el audit log, vos manejás los rate limits y construís el fallback y el rollback, y vos cableás la compuerta humana y el trace. Nada es gratis — pero nada es fijo tampoco, que es exactamente por qué fuera de plataforma es la superficie correcta cuando el trabajo necesita un control flow, un modelo, o una política que la plataforma no te da.
No elegís uno y le jurás lealtad. Un sistema real corre los dos seguido — un agente Agentforce dueño de las acciones gobernadas, en plataforma, sobre data del cliente, y un agente fuera de plataforma dueño de un paso que no puede, con un handoff limpio donde la accountability tiene una costura (principio 9). El oficio es componer las superficies al sistema que realmente construiste, que es la misma lógica de composición del toolkit que recorre los principios de AI Engineering.
La evaluación es la compuerta de deployment
La dimensión que decide si un cambio es seguro de shipear es la evaluación — y en un sistema de producción no es un chequeo de una sola vez, es la compuerta que pasa cada release. La eval offline prueba que una versión nueva es al menos tan buena como la anterior antes de que ningún usuario la vea; la eval online vigila el tráfico real por la degradación silenciosa después de que sale. Production readiness es para lo que la evaluación hace de compuerta: el eval set es donde probás que el guardrail aguanta contra el input adversario, que el costo se mantuvo dentro del presupuesto, que la latencia es aceptable, y que la acción irreversible solo se dispara cuando debe. Una release sin compuerta de eval es la trampa del vibe-check a escala de producción — estás shipeando sobre la impresión de que nada se rompió, sin una medición que lo diga (principio 3: si no lo podés evaluar, no lo podés shipear).
A dónde ir después
Desde acá, la subcategoría construye hacia afuera, una dimensión por página, desde el mapa que esta página expuso. Costo y latencia es el par de economía-y-velocidad — la decisión de tier de modelo, los token budgets, el caching, el streaming. Guardrails y seguridad son los límites de input y output y el camino de rechazo. PII y gobernanza es el manejo lícito, la retención, y el audit trail. Human-in-the-loop y accountability es la compuerta y el trace que ponen a una persona a cargo de lo que el sistema hizo. Y deployment a producción es la mecánica de release — rate limits, fallback, rollback, el camino de salida y de vuelta. La vara que un sistema pasa antes de salir es el Style Guide de Producción. (Esas hermanas están saliendo junto a esta página; nombradas acá, linkeadas una vez que salgan.)
Producción es donde se cobra el resto de este catálogo. Un agente es tan bueno como las dimensiones que lo mantienen seguro de correr sin supervisión; el grounding, el prompting, y la evaluación apuntan todos a un sistema que de verdad podés shipear y operar. El modelo nunca fue la parte difícil. Esta es la parte que decide si corre el lunes.
Related
- Principios de AI Engineering — una demo no es un producto (1), costo y latencia son features (6), goberná el radio de impacto de cada tool (5), un humano es accountable (9), traceá todo (11)
- Qué es un agente — el sistema que production readiness existe para volver seguro de correr sin supervisión
- Agentes de Agentforce — el Einstein Trust Layer en detalle, y la disciplina de Actions que el Trust Layer no cubre
- Qué es evaluación — la compuerta de deployment que pasa cada release de producción
- Tracing y monitoreo — el trace del que depende la accountability y que lee la evaluación online
- Qué es grounding — una respuesta de producción es tan buena como los hechos que tiene debajo
- Qué es context engineering — el presupuesto de contexto que maneja tanto el costo como la latencia en producción
- Style Guide de IA de Marketing Cloud — la decisión de qué-superficie-para-qué-trabajo, una capa hacia afuera
- Style Guide de producción — la compuerta pre-ship en la que se vuelven estas dimensiones
- Human-in-the-loop y accountability — la dimensión de accountability, en detalle
Reference: