Style Guide de producción: la compuerta que una IA pasa antes de correr sin supervisión

Esta es la página donde Cleon deja de describir qué es la production readiness y dice qué tiene que ser verdad antes de que un sistema de IA corra sin supervisión sobre tráfico real. Las páginas de referencia exponen las partes — qué es la production readiness y las seis dimensiones que exige, las palancas de costo y latencia en orden de fuerza, la capa de guardrails y seguridad a cada lado del modelo, PII y gobernanza, human-in-the-loop y accountability, y deploying a producción. Los gotchas exponen las diez maneras en que una demo miente sobre estar lista. Este Style Guide es la compuerta que decide si un sistema tiene permitido acercarse a un cliente — y la regla que lo decide es binaria.

Las reglas son cortas a propósito. Cuando una regla necesita explicación, la explicación vive en la página que enlaza. Esta es la forma operativa de los principios de AI Engineering — cada fila de abajo es uno de esos principios con las mangas arremangadas, y citamos el número para que puedas rastrear la regla hasta su razonamiento. Es la compañera del lado de correrlo-con-seguridad del Style Guide de agentes, del Style Guide de grounding, del Style Guide de prompting y del Style Guide de evaluación: los primeros tres terminan una oración con "eval en cada cambio", evaluación es la página a la que esa oración apunta, y esta es la página que dice qué más tiene que ser verdad antes de que el cambio evaluado salga a tráfico real.

La compuerta pre-ship: qué tiene que ser verdad antes de que esta IA corra en producción

Esta es la página que le da a la compuerta su hogar. Antes de que un sistema de IA sirva tráfico real — su primer lanzamiento, o cualquier cambio a un prompt, modelo, agente, retriever o herramienta que sale a producción — cada fila de abajo es verdadera, o no está lista. Cada fila cierra un gotcha que convirtió una demo que funcionaba en un sistema que nadie podía correr, auditar, ni frenar. La columna "dónde se cubre" apunta a la página que arma la fila completa.

El chequeo	Por qué bloquea el ship	Dónde se cubre
Hay un techo de costo y una alerta	Una tormenta de retries, un loop recursivo o un contexto sin límite pueden 10x la cuenta de un día para el otro, y la primera señal es la factura — un cap duro por request y por sesión más una alerta antes del cap convierten el gasto desbocado en un número que manejás. (Principio 6.)	Costo y latencia · Production gotchas
Existe un presupuesto de latencia y un fallback	Una respuesta correcta que llega demasiado lento es una respuesta equivocada para el usuario — fijá un p95 objetivo, no solo una mediana, y dale al sistema un fallback para cuando revienta el presupuesto: un modelo más rápido, una respuesta cacheada, un contexto más corto, o un timeout elegante. (Principio 6.)	Costo y latencia · Production gotchas
Los guardrails de entrada están prendidos (inyección filtrada)	Toda entrada es superficie de ataque, y el caso indirecto — instrucciones adversarias escondidas en un documento recuperado o en un resultado de herramienta — es el que los equipos se pierden; filtrá la entrada antes del modelo principal y tratá el contenido recuperado como datos, nunca como instrucciones. (Principio 5.)	Guardrails y seguridad · Production gotchas
La PII está enmascarada y la retención está manejada	Campos reales de cliente caminando hacia un modelo de terceros sin enmascarado y sin piso de retención es un hallazgo regulatorio, no un bug — enmascará o tokenizá los campos sensibles antes de que el prompt salga de tu frontera, y conocé los términos de retención del proveedor por feature. (Principio 9.)	PII y gobernanza · Production gotchas
Un humano está en el loop en las acciones irreversibles	Un sistema no determinista va a tomar una mala decisión eventualmente, y en un envío, un borrado, un pago o un cambio de permiso no hay undo — las acciones reversibles las toma el agente solo, las irreversibles esperan a que un humano apruebe. (Principios 8, 9.)	Human-in-the-loop y accountability · Production gotchas
El audit trail está prendido	Cuando el sistema hace algo mal, la primera pregunta es "qué vio y qué hizo", y si nada lo registró estás adivinando sobre un sistema no determinista después del hecho — logueá entradas, contexto recuperado, prompt, salida y cada acción, suficiente para reproducir la decisión. (Principio 11.)	Human-in-the-loop y accountability · PII y gobernanza
Hay un rollback listo	Una edición de prompt de una palabra puede correr el comportamiento sobre toda la distribución de entradas, y un cambio malo sacado a todos a la vez te deja escribiendo un fix-forward mientras producción está rota — mantené la versión anterior a un switch de distancia para que el rollback sea instantáneo. (Principio 1.)	Deploying a producción · Production gotchas
La compuerta de eval pasó	"Funcionó en tres intentos" es la trampa de la cola larga con un sombrero de deployment — el cambio pasó un set de regresión puntuado, dimensionado para que el ruido no lo mueva, antes de salir, porque si no podés evaluarlo no podés sacarlo. (Principio 3.)	Style Guide de evaluación · Qué es la evaluación

Si alguna fila está sin cumplir, el cambio no está listo. Las dos omisiones más caras: un sistema sale sin kill switch — sin una forma rápida y fuera de banda de desactivarlo — así que cuando se porta mal el daño corre lo que dura un deploy; y una acción irreversible sale sin compuerta de aprobación, así que el agente actúa y te enterás después. Ambas pertenecen a la lista de arriba y ninguna deja de tener una fila propia por accidente: el kill switch es el piso operativo debajo de "hay un rollback listo", y la compuerta de aprobación es el todo de "un humano está en el loop".

En plataforma versus construirlo: las mismas dimensiones, decididas por dónde corre el sistema

La compuerta de arriba es constante. Lo que cambia es cuánto de cada fila te dan gratis versus lo armás vos — y eso lo decide dónde vive el sistema, no a qué toolkit le juraste lealtad. Como el grounding, el prompting y la evaluación antes que ella, las superficies se componen: instrumentos complementarios elegidos según dónde corre el sistema, nunca productos rivales entre los que elegís (principio 7). En Salesforce, Agentforce envuelto en el Einstein Trust Layer te entrega varias dimensiones como gobernanza por construcción; off-platform, sobre la Claude API más tu propia infraestructura, cada dimensión es tuya para armar. La matriz es la columna sin-"vs" hecha operativa — leé cada fila como "esto se da acá, y se construye allá", no como "esto le gana a aquello".

Dimensión	Agentforce + Einstein Trust Layer (dado por construcción)	Claude API off-platform (lo construís vos)
Costo	Las corridas del agente están medidas y visibles en la plataforma; la selección de modelo y el contexto se manejan por vos	Vos fijás el presupuesto de tokens y el tier de modelo, cacheás el prefijo estático, batcheás el trabajo que puede esperar, y medís el gasto vos mismo
Latencia	La plataforma maneja la elección de modelo y el contexto para mantener las respuestas en presupuesto	Vos elegís el modelo, cappeás la salida con `max_tokens`, hacés streaming para la velocidad percibida, y poseés el presupuesto p95 y el fallback
Guardrails	El Trust Layer filtra la salida por toxicidad y adjunta un score en cada respuesta; la revisión de guardrails de la plataforma aplica a topics y actions	Vos construís el screen de harmlessness de entrada y el clasificador de salida, tratás el contenido recuperado como datos, y gateás sobre el score
PII / gobernanza	Enmascarado de datos antes de que el prompt salga de la plataforma, un acuerdo de zero-retention con el proveedor del modelo, y recuperación segura de datos que honra los permisos del usuario que corre	Vos enmascarás o tokenizás los campos sensibles, confirmás los términos de retención por feature, y redactás el log vos mismo
Human-in-the-loop	La escalación humana y la aprobación son movidas de primera clase en el flujo; el paso de alto riesgo enruta a una persona por construcción	Vos construís la compuerta de confirmación en la capa de herramientas — el agente propone, un humano dispone, la llamada irreversible espera
Auditoría	El Trust Layer loguea la interacción para auditoría; Agentforce traza turnos, llamadas al LLM y acciones	Vos construís el trace — entradas, contexto, prompt, salida, acciones — con la PII redactada, el mismo stream que tu eval online puntúa
Deploy / rollback	Los cambios salen a través de Agentforce DX con el tooling de release y los sandboxes de la plataforma; los agentes se pueden desactivar por controles de admin	Vos versionás el prompt y la config del modelo, sacás detrás de un canary, y cableás el camino de rollback y el kill switch

Leé a lo ancho de una fila y la forma es siempre la misma: el Trust Layer gobierna el lado del lenguaje — lo que se le manda al modelo y lo que dice — pero no gobierna lo que tus Actions hacen, así que el blast radius de una Action que puede escribir o borrar es tuyo para acotar en cualquiera de las dos superficies (principio 5). Y no elegís una superficie y parás. Un sistema real frecuentemente corre las dos — un agente Agentforce dueño de las acciones gobernadas, en plataforma, sobre datos de cliente, un agente off-platform dueño de un paso que no puede, con un handoff limpio donde la accountability tiene una costura (principio 9). La habilidad es componer las superficies al sistema que realmente construiste.

La regla "sacalo / no lo saques"

La compuerta es binaria, y la regla es una línea: cada fila está en verde, o no sacás. No hay promedio ponderado, no hay "saco ahora, endurezco después" en una fila que acota un daño real, no hay crédito parcial. Un sistema sin techo de costo sale bien y funde un presupuesto en el primer pico de tráfico. Un sistema sin compuerta de aprobación en una acción irreversible sale bien y borra el registro equivocado en la primera entrada ambigua. Las filas que se sienten salteables en la demo son exactamente las que tiran el sistema en producción, porque una demo nunca ejercita el pico, el adversario, la cola larga, ni el mail que no se puede des-enviar. Así que sostenés la línea: una fila sin cumplir bloquea el ship igual que un test que falla, y "lo agregamos después del lanzamiento" es la oración que precede al incidente sin dueño.

El único juicio que la regla te deja es cuánto de cada fila necesita un sistema dado — un asistente interno de solo lectura carga una carga de auditoría y HITL más liviana que un agente que emite reembolsos — pero la fila en sí nunca se saltea, solo se dimensiona al blast radius. Dimensioná cada control al costo de que la cosa salga mal, después confirmá que está presente antes de que el sistema toque tráfico real.

Olores: los anti-patrones que esta compuerta existe para rechazar

"Funcionó en la demo, así que está lista." Una demo es una muestra de tamaño tres del extremo fácil de la distribución; producción es la cola larga. Hacé de la eval la compuerta, no de la demo. (Gotcha 9 · principio 1.)
Sin techo de costo. Un sistema sin cap de gasto y sin alerta puede 10x su cuenta en un pico o una regresión de prompt, y la primera señal es la factura. Cappeá por request y por sesión, alertá antes del cap. (Gotcha 1 · principio 6.)
Sin presupuesto de latencia. Tunear la mediana mientras el p95 hace el sistema inusable — fijá un p95 objetivo y un fallback, o el usuario espera diez segundos y se va. (Gotcha 2 · principio 6.)
Confiar en el contenido recuperado como instrucciones. Una inyección indirecta viaja en una página traída, un mail entrante o un resultado de herramienta; si no la filtraste y no la trataste como datos, "ignorá tus instrucciones" entra directo. (Gotcha 3 · principio 5.)
PII real sobre un apretón de manos. Campos sensibles saliendo de tu frontera sin enmascarado y sin piso de retención es un hallazgo regulatorio esperando una auditoría, no un bug a arreglar después. (Gotcha 4 · principio 9.)
El agente actúa, y te enterás después. Sin compuerta de aprobación en un envío, un borrado, un pago o un cambio de permiso, un sistema no determinista toma una acción irreversible que no podés deshacer. (Gotcha 5 · principios 8, 9.)
No loguear nada. Cuando el sistema hace algo mal y nada registró qué vio o qué hizo, estás adivinando sobre un sistema no determinista después del hecho. (Gotcha 6 · principio 11.)
Deploy sin camino de vuelta. Un cambio de prompt o modelo sacado a todos a la vez sin rollback te deja arreglando hacia adelante mientras producción está rota. (Gotcha 7 · principio 1.)
Sin kill switch. Si la única forma de apagar un agente que se porta mal es un cambio de código y un deploy, el daño corre lo que dura ese deploy. (Gotcha 10 · principio 9.)

Cierre: el arco completo, en cinco subcategorías

Ninguna de estas filas es difícil de armar antes del lanzamiento; cada una es cara de descubrir en vivo, porque un control faltante se ve exactamente como uno presente justo hasta que el pico, el adversario o la acción irreversible lo encuentra. El hilo conductor es el que todo el catálogo de AI Engineering recircula: el modelo nunca fue la parte difícil — la ingeniería alrededor lo es, y producción es donde esa ingeniería se cobra, cappeada en costo, presupuestada en latencia, filtrada en la entrada, enmascarada en los datos, gateada en las acciones irreversibles, logueada para auditoría, deployable con un rollback, y apagable en una sola movida.

Esta es además la última página del catálogo, así que vale decir el arco en voz alta. Las cinco subcategorías de AI Engineering son una sola disciplina leída en orden: agentes es lo que sacás — el sistema cableado a herramientas que actúan; grounding es lo que sabe — la recuperación sobre la que se paran las respuestas; prompting es cómo lo dirigís — el contexto y las instrucciones que hacen confiable a un modelo capaz; evaluación es cómo lo medís — la compuerta que prueba que un cambio es seguro antes de salir; y producción es cómo lo corrés con seguridad — todo lo de arriba, la vara entre un cambio medido y una IA en la que un cliente puede confiar. Cada subcategoría tiene un Style Guide, cada Style Guide termina apuntando al próximo eslabón de la cadena, y la cadena cierra acá. La disciplina es el arco completo, no un solo eslabón: un sistema con grounding pero sin gobernar, o evaluado pero no apagable, es una demo con pasos extra. Fundamentalo, dirigilo, medilo, corrélo con seguridad — o no sale.

Si ves una fila que falta — o una de estas reglas siendo violada en nuestro trabajo público — escribí a hello@wearecleon.com. La agregamos, o la arreglamos y lo decimos.

Production gotchas — las diez maneras en que una demo miente sobre estar lista que esta compuerta está diseñada para prevenir
What is production readiness — las seis dimensiones y el mapa que la compuerta operativiza
Cost and latency — las palancas detrás de las filas de techo-de-costo y presupuesto-de-latencia, en orden de fuerza
Guardrails and safety — los screens de entrada y salida detrás de la fila de inyección
PII and governance — el enmascarado, la retención y la auditoría detrás de las filas de gobernanza
Human-in-the-loop and accountability — la compuerta de aprobación y el trace detrás de las filas de HITL y auditoría
Deploying to production — el canary, el rollback y el kill switch detrás de la fila de rollback
Agent Style Guide — lo que sacás: el agente alrededor del cual corre esta compuerta
Grounding Style Guide — lo que sabe: la recuperación sobre la que se para una respuesta
Prompting Style Guide — cómo lo dirigís: el contexto que hace confiable a un modelo
Evaluation Style Guide — cómo lo medís: la compuerta que cada cambio pasa antes de esta
AI Engineering principles — las meta-reglas que estas particularidades operativizan
Marketing Cloud AI Style Guide — la decisión de qué-superficie, una capa más afuera

Reference: