AI Engineering: principios desde producción | Cleon

La mayoría de los proyectos de IA mueren en el mismo lugar: la brecha entre una demo que dejó a todos impresionados en la sala y un sistema que corre el lunes a la mañana, sobre data real, a volumen real, sin un humano cuidándolo. El modelo nunca fue la parte difícil. La parte difícil es la ingeniería alrededor — el retrieval, las tools, la evaluación, los guardrails, el monitoreo, y los humanos que tienen que confiar en el output lo suficiente como para actuar sobre él.

Estos son los principios que Cleon aplica cuando construimos un sistema de IA — ya sea que el agente corra sobre Agentforce dentro de Salesforce, o sobre LangGraph y la Claude API por fuera. Esas herramientas son instrumentos complementarios que componemos según el problema, no bandos rivales entre los que elegir. Cada principio de abajo está anclado en trabajo de implementación, no en slides de keynote — una síntesis de dónde la guía oficial acierta, dónde la comunidad de práctica la corrigió, y dónde nuestra propia experiencia de producción se aparta de ambas.

El hilo conductor: un sistema de IA está fundamentado, evaluado, gobernado y shipeado — o es una demo. Todo lo de acá está al servicio de cruzar esa brecha.

Los principios

1. Una demo no es un producto — el gap es la ingeniería.

Una buena demo prueba que el modelo puede hacer la cosa una vez. Producción pregunta si la hace de forma confiable cada vez, con inputs que nadie scripteó, lo suficientemente barato como para que valga la pena correrlo. Son preguntas distintas, y la distancia entre ellas es donde vive el laburo de verdad.

Tratá la demo como el arranque del proyecto, no el final. En el momento en que alguien dice "shipealo", recién empieza el estimado real — data prep, evals, manejo de errores, monitoreo, y el rollout a los humanos que tienen que cambiar cómo trabajan.

2. Fundamentá antes de generar.

Un prompt ingenioso sobre cero retrieval es una adivinanza confiada. Lo que hace que una respuesta sea verdadera es fundamentarla en tu data — retrievers de Agentforce sobre el perfil de Data 360, o un pipeline de RAG externo sobre tus documentos. El modelo aporta la fluidez; el grounding aporta los hechos.

3. Si no lo podés evaluar, no lo podés shipear.

"Se veía bien en tres intentos" no es un test — es una sensación. Un set de evaluación es la diferencia entre mejorar un sistema y adivinarle. Sin él, cada cambio de prompt es una moneda al aire que no podés puntuar, y cada regresión shipea en silencio.

Armá el eval set desde las fallas reales a medida que aparecen. Los primeros diez casos que te mordieron en testing valen más que cien sintéticos, porque codifican las formas en que tu problema realmente se rompe.

4. El modelo es la parte fácil; el sistema es el laburo.

Cambiar a un modelo más fuerte es una tarde. Construir el retrieval, las tools, el manejo de estado, los guardrails, los caminos de fallback y la observabilidad alrededor es el trimestre. Presupuestá en consecuencia — el ítem del modelo es el más chico de la lista.

Por eso también "esperá al próximo modelo" rara vez es la respuesta. Un mejor modelo hace que un sistema bien diseñado sea mejor; no rescata a uno que no tiene evals, ni grounding, ni guardrails.

5. Cada tool que el agente puede llamar es un blast radius — gobernalo.

En el momento en que un agente puede actuar — mandar un mensaje, actualizar un registro, mover plata — el riesgo cambia de "respuesta equivocada" a "acción equivocada". Dale a cada tool el scope más angosto que haga el trabajo, validá cada argumento antes de que corra, hacela idempotente donde puedas, y poné un kill switch en cualquier cosa con consecuencias.

6. Costo y latencia son features.

Un sistema de IA que produce la respuesta correcta demasiado lento, o demasiado caro como para correrlo al tamaño real de la audiencia, no resolvió el problema. Los presupuestos de tokens, los step caps, el caching, y la decisión de tier de modelo (un modelo chico para la llamada de rutina, uno grande solo donde se lo gana) son decisiones de diseño, no afterthoughts para colgar cuando llega la factura.

Modelá el costo contra el volumen real antes de construir, no después. Un costo por llamada que es trivial en una demo se convierte en todo el business case a un millón de llamadas por mes.

7. Componé el toolkit al problema.

Agentforce cuando el trabajo vive en el modelo de seguridad de Salesforce y necesita acciones gobernadas y auditables sobre data de clientes. LangGraph y la Claude API cuando el trabajo es off-platform, necesita un control loop propio, o abarca modelos y sistemas que Salesforce no alcanza. MCP cuando querés que tools y data interoperen entre ellos. Son instrumentos complementarios; la habilidad está en elegirlos y combinarlos según el problema, no en jurarle lealtad a uno.

La decisión de qué superficie para qué trabajo — Agentforce, Einstein, o un modelo externo dentro de Marketing Cloud — es su propio framework; ver el Style Guide de IA de Marketing Cloud.

8. Lo no determinístico necesita un gate humano donde es customer-facing.

El mismo input puede producir un output distinto mañana. Eso está bien para un borrador, es peligroso para cualquier cosa que un cliente vea sin revisar. Poné un paso de validación y un valor de fallback en cada generación, y un gate de aprobación humana en cualquier cosa abierta que llega a una persona.

Nunca dejes que una falla del modelo se renderice como un blanco, un string de error, o una alucinación frente a un cliente. Un fallback determinístico y aburrido le gana a una respuesta equivocada y emocionante siempre.

9. Siempre hay un humano accountable por lo que hace la IA.

La IA no mueve la accountability al modelo. Alguien es dueño de cada output: lo puede explicar, defender, y responder por él cuando está mal. Diseñá el sistema para que esa persona exista, sepa que es ella, y tenga los controles (revisión, override, kill switch) para actuar.

"El modelo decidió" no es una respuesta aceptable a "por qué pasó esto", y construir como si lo fuera es cómo terminás con un incidente sin dueño.

10. El contexto es un presupuesto, no un balde.

Meter todo lo que tenés en el prompt no hace al modelo más inteligente — pasado un punto lo hace peor, porque la señal que necesitás se ahoga en el contexto que agregaste "por las dudas". Curá lo que el modelo ve: los chunks recuperados correctos, el historial relevante, las instrucciones que importan para este paso.

Más contexto es un costo en tokens, latencia y calidad de razonamiento. Gastalo donde se gana el lugar.

11. Trazá todo — no podés debuggear lo que no podés reproducir.

Cuando un agente hace loop, llama a la tool equivocada, o se pone peor en silencio, la primera pregunta es "qué pasó realmente", y solo la podés responder si capturaste el trace. Logueá los inputs, el contexto recuperado, las llamadas a tools y sus resultados, y el output final de cada corrida. La observabilidad es la precondición para arreglar una degradación silenciosa — y las degradaciones silenciosas son la norma, no la excepción, en sistemas construidos sobre un modelo en movimiento.

12. Arrancá desde el problema, no desde el modelo.

La pregunta interesante nunca es "¿puede el modelo hacer esto?". Es "¿es esta la forma más barata de que un negocio haga esto, una vez que sumás data prep, monitoreo, y los humanos que lo usan?". Un montón de cosas que un modelo puede hacer no valen la pena hacerlas con uno. Arrancá desde un problema que valga la pena resolver y un valor que justifique el costo; agarrá la IA cuando es genuinamente la mejor herramienta, no porque es la emocionante.

Cierre

Estos no son reglas para memorizar; son el músculo que construís después de que los mismos proyectos de IA mueren de la misma forma en el mismo gap. Son una síntesis — la guía oficial donde aguanta, las correcciones ganadas a los golpes por la comunidad donde los docs son optimistas, y la experiencia de producción de Cleon donde ambas dejan huecos.

Si ves una violación de cualquiera de ellos en nuestro trabajo, escribí a hello@wearecleon.com — lo arreglamos y lo decimos.