Deployar a producción: el camino seguro de un eval que pasa al tráfico vivo
El eval está verde — ¿y ahora cómo lo lanzás de verdad sin aprender por las malas que verde offline no es verde en producción? Seis pasos que llevan un cambio de prompt, model o agente de un test que pasa al tráfico vivo con una vuelta atrás: construir y testear en un entorno aislado (Agentforce DX mueve metadata de agentes entre scratch orgs, sandboxes y prod; off-platform, un entorno de staging), pasar el gate de eval antes del merge, versionar el cambio para saber exactamente qué se lanzó, hacer un rollout gradual detrás de un canary en vez de dar vuelta el 100 por ciento de una, tener un rollback de un paso listo, y monitorear sobre tráfico vivo después — porque la degradación silenciosa que un set congelado no puede ver la caza el eval online y el tracing. El hilo: el deployment no es la línea de llegada. Es donde la evaluación y la observabilidad empiezan a hacer su trabajo de verdad.
El eval pasó. El instinto es lanzar — y lanzar directo de una corrida offline verde al 100 por ciento de producción es justamente cómo un cambio que parecía seguro se vuelve el incidente que nadie vio venir. Un eval que pasa es necesario, no suficiente: prueba que el cambio es al menos tan bueno como el anterior sobre los casos que congelaste, y producción es la distribución que no congelaste (qué es production readiness). El deployment seguro es la ingeniería entre "el test está verde" y "el tráfico real está encima" — y todo el punto de esa ingeniería es que cada paso tiene una vuelta atrás, así que el peor caso es una recuperación rápida en vez de un parche hacia adelante mientras el sistema está roto frente a los clientes.
Esta es una how-to de proceso: un camino numerado de un eval que pasa al tráfico vivo, cada paso lo que hacés y por qué importa. Nada de esto depende del toolkit. Producción y gobernanza es una disciplina sobre dos superficies, compuesta por dónde corre el sistema (principio 7): en Salesforce, los cambios de Agentforce se mueven a través de Agentforce DX con el camino de release de la plataforma, los sandboxes, y el Einstein Trust Layer gobernando el lado del lenguaje por construcción; off-platform, la Claude API más tu propia infraestructura significa que construís el entorno de staging, el gate, el versionado, el canary y el rollback vos mismo. Los pasos de abajo son los mismos en ambas superficies; solo cambia quién los construye.
El camino de deploy seguro
1. Construir y testear en un entorno aislado
Nunca escribas ni cambies un sistema de IA directo contra producción. El primer movimiento es un entorno donde un error no cuesta nada — donde podés romper el prompt, cablear mal una tool, o lanzar una config de model mala y lo único que mira sos vos, no un cliente. La brecha demo-a-prod (gotcha 9 de producción) vive justamente en los cambios que "parecían bien" contra el único input que probaste; un entorno aislado es donde probás los inputs que no están bien antes de que lleguen al tráfico.
En Salesforce, para esto está Agentforce DX. "Provee comandos de CLI y una extensión de VS Code para crear, previsualizar y testear agentes fuera de Agentforce Studio, y para mover metadata de agentes entre tu proyecto DX y tus scratch orgs, sandboxes y production orgs" — así que desarrollás en una scratch org o sandbox, mantenés tu control de versiones como "la fuente de verdad", y promovés la misma metadata hacia arriba a producción a través de un camino que la plataforma maneja. Off-platform, el equivalente es un entorno de staging que espeja producción — mismo model, mismo retrieval, mismas tools apuntadas a datos no productivos — para que lo que testeás sea lo que lanzás. La pregunta que responde este paso: ¿hay algún lado donde puedas equivocarte con un cambio sin que sea un cliente el que se entera? Si la respuesta es "solo en producción", todavía no tenés un proceso de deploy.
2. Pasar el gate de eval
El eval set congelado corre como un chequeo pre-deploy, pre-merge — y la regla es binaria: se vence o se mantiene el baseline, o el cambio no se lanza. Este es el gate que toda la disciplina de evaluación existe para alimentar; "evaluá cada cambio" es la oración a la que apunta cada Style Guide de este catálogo, y acá es donde muerde para un deploy. Un cambio que baja un caso por debajo del baseline se bloquea en el gate, no se descubre en producción — esa es la diferencia entre un test rojo y una queja de un cliente.
La mecánica: mantené el set fijo, puntuá la versión nueva contra él, y compará con el último baseline conocido-bueno. Una caída bloquea el merge; un empate o una ganancia lo libera. En Salesforce, Agentforce Testing Center corre casos contra el agente antes del release; off-platform, la corrida de eval está cableada al merge para que el cambio no pueda aterrizar sin un puntaje verde (mirá el Style Guide de evaluación para qué medir y cómo, y eval datasets and metrics para el set mismo). La pregunta: ¿"está listo" está respaldado por una corrida puntuada sobre los casos difíciles — o por un pase offline verde sobre el camino feliz y una esperanza sobre el resto? Un eval que no gatea el merge es documentación; un eval cableado al merge es lo que frena la regresión silenciosa.
3. Versionar el cambio
Lo que sea que se lanza — el prompt, la versión del model, la config del agente, las definiciones de tools — está versionado, así que sabés exactamente qué salió y podés compararlo contra lo que vino antes. Un cambio que no podés nombrar es un cambio al que no podés volver ni del que podés alejarte, y un sistema de IA tiene más partes móviles que un deploy de código: un edit de prompt de una palabra, un salto de versión de model y un cambio de retriever pueden cada uno mover el comportamiento a través de toda la distribución de inputs, y si se lanzaron juntos sin versionar no podés decir cuál movió el número.
En Salesforce, Agentforce DX trata tu control de versiones como la fuente de verdad para la metadata del agente — "periódicamente registrá la metadata nueva y actualizada en tu VCS, como GitHub" — así que cada versión del agente es un artefacto rastreado y diffeable. Off-platform, versionás el prompt, la config del model y el schema de tools en control de fuente igual que versionás código, etiquetado para que un estado dado de producción mapee a un commit conocido. Esto es lo que hace significativa la comparación antes-versus-después del paso 2 y posible el rollback del paso 5: solo podés volver a la última versión conocida-buena si sabés con precisión cuál era. La pregunta: si alguien preguntara "¿qué exactamente está corriendo en producción ahora mismo?", ¿podrías apuntar a una versión — o estarías reconstruyéndola desde la memoria?
4. Hacer un rollout gradual
Un cambio que pasó el gate igual va a una porción del tráfico primero, no a todos de una. Un canary — una fracción chica de requests reales ruteada a la versión nueva mientras el resto se queda en la vieja — convierte el radio de daño de un cambio malo de "todos los usuarios" en "un par por ciento de los usuarios, brevemente". El eval offline es una muestra curada; el canary es el primer contacto con la distribución que no curaste, y es donde una regresión que el set congelado no pudo representar aparece mientras todavía es barato revertirla.
Mirá el canary sobre señales vivas, no sobre fe: los puntajes del eval online y el tracing corriendo sobre el tráfico del canary, más las métricas operativas — latencia, tasa de error, costo por llamada (costo y latencia). Si la porción mantiene el baseline y las métricas siguen sanas, ampliala; si se degrada, hacés rollback habiendo afectado una fracción en vez de toda producción. En Salesforce, escalonás el rollout a través de los controles de release de la plataforma; off-platform, construís el split de tráfico y las métricas por versión vos mismo. La pregunta: cuando este cambio se ponga vivo, ¿llega a una porción que estás mirando primero — o al 100 por ciento del tráfico en el momento en que mergea?
5. Tener un rollback listo
Antes de que el rollout se amplíe, hay una vuelta atrás de un paso a la última versión conocida-buena — lista, con dueño, y testeada antes de necesitarla. Este es el arreglo directo de la trampa de "deployar sin rollback" (gotcha 7 de producción): si tu única recuperación de un cambio malo es escribir y lanzar un parche hacia adelante, la degradación corre por el largo de ese parche mientras producción está rota. Un rollback que podés tirar en un movimiento convierte un deploy malo de un incidente en un no-evento.
Lo que "un paso" requiere es el versionado del paso 3: el prompt anterior, la config del model y la metadata del agente están retenidos y son promovibles, así que revertir es seleccionar la última versión buena, no reconstruirla. En Salesforce, la metadata anterior del agente vive en control de versiones y se redeploya a través de Agentforce DX; off-platform, la versión anterior se queda a un switch de distancia — un giro de config, no un cambio de código y un deploy. Testeá el rollback antes del lanzamiento de la misma forma que testearías un kill switch (gotcha 10 de producción) — un rollback que nunca ejercitaste es un rollback en el que confiás a fe en el peor momento posible. La pregunta: si el cambio que recién lanzaste resulta malo, ¿podés poner de vuelta la última versión buena en un movimiento — o la recuperación es un parche hacia adelante a las corridas?
6. Monitorear después
El deployment no es el final de la evaluación — es donde empieza la mitad online. Un eval set congelado es, por construcción, ciego a la deriva que no contiene: un cambio en lo que los usuarios piden, un cambio del proveedor del model debajo tuyo, un edge case que el set nunca tuvo. El eval online y el tracing sobre tráfico vivo es lo que caza la degradación silenciosa que el set congelado no puede ver — el mismo stream de traces que sirve como audit trail y los datos que un humano revisa cuando es responsable de un resultado.
La mecánica: seguí puntuando una muestra del tráfico vivo contra tus criterios después de que el rollout se complete, mirá las métricas operativas, y devolvé las fallas de producción al eval set para que el próximo cambio que las reintroduciría dispare un caso rojo en el paso 2 en vez de una queja en el campo. Ese loop — producción saca a la luz una falla, la falla se vuelve un caso congelado, el gate la caza la próxima vez — es lo que mantiene honesto al eval set mientras la distribución sigue moviéndose. En Salesforce, Agentforce Observability exporta los traces de producción y los puntajes de métricas; off-platform, corrés el puntaje online y el pipeline de traces. La pregunta: después de que este cambio esté del todo vivo, ¿hay algo mirando el tráfico que el eval offline no pudo representar — o el monitoreo paró en la corrida verde pre-deploy?
Una checklist pre- y post-deploy
Los seis pasos como un gate que podés repasar antes y después de que un cambio salga:
| Etapa | Chequeo | Si falla |
|---|---|---|
| Antes | Construido y testeado en un entorno aislado (scratch org / sandbox / staging), nunca contra prod | Pará — conseguí primero un entorno donde un error no cuesta nada |
| Antes | Eval set puntuado contra el cambio; baseline vencido o mantenido | Bloqueado — el cambio no mergea hasta que el puntaje se recupere |
| Antes | La versión exacta de prompt / model / config está etiquetada y rastreada | Pará — un cambio sin versionar no puede revertirse ni alejarse |
| Antes | El camino de rollback existe, tiene dueño, y fue testeado | Pará — un rollback que nunca ejercitaste es fe, no un plan |
| Rollout | El cambio llega a una porción canary primero, mirada sobre eval online + métricas | Pará — nunca vayas directo al 100 por ciento del tráfico |
| Después | Eval online + tracing corriendo sobre tráfico vivo; las fallas vuelven al set | Pará — sin eso la degradación silenciosa se lanza sin verse |
La checklist es la forma operativa del hilo: cada fila es un paso que tiene una vuelta atrás, y la columna de la derecha es lo que "sin vuelta atrás" habría costado.
El hilo
El deployment no es la línea de llegada — es donde la evaluación y la observabilidad empiezan a hacer su trabajo de verdad. La corrida offline verde le gana a un cambio el derecho a ir a una porción del tráfico detrás de un rollback, no el derecho a ir a todos; el gate de eval prueba que el cambio es seguro contra los casos que tenés, el canary lo testea contra los casos que no, el rollback es el cinturón de seguridad para cuando el canary se equivoca, y el monitor online es lo que nota la degradación lenta que ningún chequeo pre-deploy podría. El model era la parte fácil, y hasta el eval era solo la mitad del trabajo — la otra mitad es la disciplina de lanzarlo de manera que cuando esté mal, y un sistema no determinista eventualmente lo estará, el peor caso sea un revert rápido y un caso congelado nuevo en vez de un incidente de cara al cliente sin vuelta atrás. Lanzá detrás de un gate, hacé un rollout gradual, tené lista la vuelta atrás, y mirá lo que no pudiste testear.
Si tu equipo lanza IA a producción con un paso que a este camino le falta, escribí a hello@wearecleon.com — lo agregamos, con crédito.
Related
- Qué es production readiness — las seis dimensiones que este camino de deploy operacionaliza
- Gotchas de producción — la trampa de deployar-sin-rollback (7) y la brecha demo-a-prod (9) que estos pasos cierran
- Costo y latencia — las métricas operativas que el canary y el monitor post-deploy miran
- PII y gobernanza — el audit trail que el stream de traces post-deploy también es
- Human-in-the-loop y accountability — quién es dueño de la decisión de rollback y lee los traces vivos
- Style Guide de producción — la vara que un cambio supera antes de lanzarse
- Style Guide de evaluación — el gate de "evaluá cada cambio" que invoca el paso 2
- Eval datasets and metrics — el set congelado contra el que el gate puntúa y al que vuelven las fallas
- Tracing y monitoring — el eval online y el stream de traces de los que dependen los pasos 4 y 6
- Agentforce agents — Agentforce DX, el Trust Layer, y el camino de release de la plataforma en detalle
- Principios de AI Engineering — un demo no es un producto (1), si no podés evaluarlo no podés lanzarlo (3), el no-determinismo necesita un gate (8), trazá todo (11)
Reference: