AI ENGINEERING / PRODUCCIÓN Y GOBERNANZA
Producción y gobernanza
Shipear y operar IA: costo, latencia, guardrails, PII y seguridad, human-in-the-loop, accountability, y deployment. La brecha entre una demo y una IA que corre el lunes a la mañana.
Fundamento · 2
Nota de producción
Gotchas de producción: lo que la demo nunca te mostró
Una demo prueba que un sistema de IA puede funcionar una vez. Producción prueba que funciona el lunes a la mañana, bajo carga, con los inputs que nadie guionó, cuando la factura de tokens es real y el agente puede borrar cosas. La brecha entre las dos es donde se rompen los sistemas de IA — no en capacidad, sino en el techo de costo que nadie puso, la latencia que nadie presupuestó, la inyección de prompt que nadie filtró, la PII que se fue a un tercero, la acción irreversible sin paso de aprobación, y el kill switch que no existía cuando hizo falta. Diez gotchas que separan una demo de un sistema que podés correr, cada uno con la trampa, el arreglo, y la pregunta a contestar antes de lanzar.
Marco de decisión
Style Guide de producción: la compuerta que una IA pasa antes de correr sin supervisión
Las reglas con opinión que Cleon aplica antes de que un sistema de IA corra sobre tráfico real — la compuerta pre-ship como una checklist binaria (techo de costo, fallback de latencia, guardrail de entrada, PII enmascarada, un humano en las acciones irreversibles, el audit trail prendido, un rollback listo, la compuerta de eval pasada), y la matriz en-plataforma-versus-construirlo que dice qué te dan Agentforce y el Einstein Trust Layer por construcción versus qué armás off-platform, dimensión por dimensión. El documento de disciplina que convierte los gotchas de producción en reglas y los principios de production readiness en una checklist: una fila sin cumplir bloquea el ship. Y como esta es la última página del catálogo de AI Engineering, ata las cinco subcategorías — agentes, grounding, prompting, evaluación, producción — en el único arco que toda la disciplina recorre.
Referencia · 5
Referencia
¿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.
Referencia
Costo y latencia: las palancas, en orden de fuerza
Una demo corre una vez y la factura es error de redondeo; el mismo sistema a volumen de producción convierte el costo y la latencia en líneas que alguien tiene que responder. Esta página es el tablero de palancas, ordenado por fuerza. La selección de modelo es la palanca más grande sobre ambos — Haiku, Sonnet u Opus es la primera decisión, y una tabla real muestra para qué sirve cada uno. Después el prompt caching (hasta 90 por ciento de ahorro sobre un prefix reusado, hasta 80 por ciento más rápido), el batch processing (cerca del 50 por ciento de ahorro, asíncrono, la mayoría de los batches en menos de una hora), max_tokens como tope duro de salida y guarda contra runaways, y el streaming — que no baja el costo pero corta la latencia percibida. Debajo de todo: un presupuesto de tokens y la Usage and Cost API, porque no podés sostener un techo que no medís. Estas son las palancas off-platform de la Claude API; Agentforce abstrae algunas, pero la disciplina es idéntica.
Referencia
Guardrails de entrada y salida: la capa de seguridad alrededor de un agente shipeado
Un modelo que puede actuar es un modelo que puede ser atacado, y un modelo que responde libremente es un modelo que puede equivocarse en voz alta. Los guardrails son la capa de seguridad de dos lados que envolvés alrededor: los guardrails de entrada filtran lo que llega al modelo, los de salida filtran lo que sale. Las cuatro amenazas y sus mitigaciones como matriz — jailbreak / prompt injection directa (el usuario es el adversario), prompt injection indirecta (el adversario se esconde dentro del contenido recuperado), alucinación, y output tóxico — cada una mapeada a la defensa con nombre de Anthropic. Claude es inherentemente resiliente pero fortalecés los guardrails por cumplimiento de los Términos de Servicio; el pre-screen de inocuidad con Haiku; tratar el contenido recuperado como dato, no como instrucciones; el permiso de no-sé y el grounding por-cita-primero para la alucinación; el screening de output para la toxicidad. Y el Einstein Trust Layer como el mismo trabajo hecho por construcción cuando el agente vive en Agentforce — detección y scoring de toxicidad en cada respuesta — con el equivalente off-platform que construís vos mismo.
Referencia
PII y gobernanza de datos: masking, retención, y el audit trail
En el momento en que un sistema de IA llega a un modelo, la data del cliente deja tu límite y aterriza adentro de un proveedor tercero. La gobernanza es la disciplina que acota lo que esa exposición te cuesta: masking de datos para que la PII nunca llegue al proveedor en claro, una garantía de retención cero para que lo que sí llega no quede guardado, y un audit trail para que puedas probar después qué pasó. El Einstein Trust Layer te da los tres por construcción para un agente en Agentforce — masking por entidad nombrada, acuerdos de retención cero con los proveedores de LLM, scoring de toxicidad, y un registro de auditoría con timestamp del prompt original, los scores de seguridad, y la respuesta original. Off-platform armás los mismos tres controles vos mismo: enmascarar antes de la llamada, firmar un acuerdo de retención cero con el proveedor, escribir tu propio audit log. Sin 'vs' — el mismo trabajo de gobernanza, por construcción en Agentforce o armado a mano off-platform. Y un matiz real por-feature: no toda feature de la API es elegible para retención cero (la Message Batches API de Anthropic no lo es), así que la garantía se chequea por feature, no se asume para el proveedor. El audit trail es lo que lee un auditor, y es el mismo registro de runtime que captura la observabilidad.
Referencia
Human-in-the-loop y accountability: quién responde cuando el agente actúa
Un agente autónomo va a terminar tomando una acción que no debería — la pregunta que responde producción es si hubo un humano en el loop antes de que lo hiciera, y quién es dueño del resultado después. La regla que dimensiona la compuerta: el costo de una acción autónoma equivocada fija la vara para exigir aprobación. Las cinco situaciones que exigen un humano en el loop como una tabla de decisión real — acción irreversible, baja confianza del modelo, alto radio de impacto, decisión sensible o atada a compliance, y una acción fuera del alcance verificado — cada una mapeada al porqué y a la compuerta que requiere. Escalamiento: el agente le pasa al humano el contexto completo de la conversación y la decisión del humano queda registrada. Verificación antes de una acción sensible: un paso de verificación gatea la acción — verificá al cliente antes del reembolso — atado a la disciplina de tools. Y la accountability como hilo conductor: una persona es dueña del resultado, no el modelo; el trace es el registro que prueba qué pasó. Compuesto según dónde corre el sistema — Agentforce trae el escalamiento y la verificación de fábrica y registra la interacción; fuera de plataforma construís el paso de aprobación y el log vos. Misma disciplina, decidida por dónde vive el sistema.