Aakash Gupta escribió algo esta semana que llevo años pensando pero nunca había articulado con esta claridad: “The prompt is temporary. The eval is permanent.” — El prompt es temporal. La evaluación es permanente.

Su argumento: todos los equipos de IA están volcando recursos en la capa que cambia cada pocos meses — prompts, cableado de agentes, orquestación — y subinvirtiendo en la capa que se acumula para siempre. Cada vez que sale un modelo nuevo, te toca reescribir los prompts. Si cambia el framework, hay que adaptar la arquitectura. Lo mismo con las nuevas ventanas de contexto o los formatos de tool-calling: cualquier cambio en la capa del modelo te obliga a modificar el trabajo previo.

Nada de eso reinicia tu eval.

En 25 años construyendo software empresarial, he visto este patrón exacto tres veces. Primero fue el fine-tuning — las empresas gastaron cientos de miles para compensar limitaciones de modelo que desaparecieron al año siguiente. Después fueron los pipelines de RAG — sistemas de recuperación meticulosamente construidos que las ventanas de 1M de tokens hicieron innecesarios de un día para otro. Ahora es el prompt engineering y el cableado de agentes. Cada ola parecía permanente. Cada una se depreció.

La pregunta es si tu empresa está construyendo lo que se deprecia o lo que se acumula.

El cableado de tu agente no es tu ventaja competitiva

Ankur Goyal, fundador y CEO de Braintrust — la plataforma de evals detrás de Vercel, Replit, Ramp, Zapier, Notion y Airtable, valuada en $800M — lo dijo sin rodeos: “Si crees que la forma en que conectaste tu agente hoy es tu diferenciador, es muy probable que fracases. Ese cableado va a cambiar en un par de meses.”

Acabamos de verlo pasar. Los equipos que perfeccionaron sus prompts de chain-of-thought para GPT-4 tuvieron que descartarlos al cambiar a Claude. Otros invirtieron meses construyendo pipelines de RAG y las ventanas de contexto masivas resolvieron el problema sin ellos. Hasta la lógica de tool-calling se reescribe cada vez que evoluciona el framework.

El playbook que tu equipo perfeccionó hace seis meses ya no aplica para el modelo actual. Y el próximo modelo va a invalidar lo que construyas para reemplazarlo.

Los clientes de Goyal — empresas que usan IA a escala de producción — descubrieron algo diferente. Las que invirtieron en entender qué necesitan realmente sus usuarios y codificaron eso como datos, puntajes y flujos de evaluación encontraron que esa inversión sobrevivía cada cambio de modelo. El dataset de entradas reales que construyeron a principio de año seguía probando las cosas correctas seis meses después. La función de scoring que escribieron para medir precisión seguía midiendo precisión sin importar si estaban ejecutando GPT-5 Nano o Claude Opus.

A diferencia de todo lo demás, el eval gana valor cada vez que lo usas. Lo que rodea al modelo se puede reemplazar en cualquier momento.

12.8 experimentos al día (y por qué cero es el problema)

Según la data operativa de Goyal con miles de equipos de IA, las empresas que construyen productos que realmente funcionan ejecutan alrededor de 12.8 experimentos de eval por día.

La mayoría de empresas B2B con las que converso ejecutan cero.

Cero de verdad. No tienen medición sistemática de si los resultados de su IA son correctos, les falta un estándar que defina qué es “suficientemente bueno,” y tampoco guardan un historial para comparar rendimiento de un mes al siguiente.

La diferencia se acumula rápido. Una empresa ejecutando un eval por día acumula 90 data points en un trimestre — 90 criterios de negocio codificados sobre cómo se ve un resultado correcto para sus procesos específicos. Una empresa ejecutando cero acumula nada. Tres trimestres después, la primera tiene 270 casos de prueba. La segunda sigue en cero.

Esto conecta directamente con la investigación de Anthropic sobre curvas de aprendizaje. Su Economic Index encontró que los usuarios experimentados de IA iteran el 28.2% de las veces, mientras que los nuevos iteran mucho menos. Los evals son cómo institucionalizas esa iteración a nivel de empresa. En vez de depender de unos pocos power users que saben cuándo cuestionar los resultados de la IA, construyes un sistema que prueba cada resultado contra un estándar que todo el equipo definió.

Tener unos cuantos power users que saben cuándo cuestionar al modelo ayuda. Pero sistematizar ese conocimiento en un proceso que pruebe cada resultado es la única forma de escalarlo a nivel de empresa.

Los prompts se deprecian. Los evals se acumulan.

El ciclo de depreciación

En una empresa típica, el equipo invierte un par de meses en diseñar una biblioteca de prompts cuidadosa — prueban edge cases, documentan patrones, sienten que construyeron algo valioso. Después se actualiza el modelo y la mitad de esos prompts ya no sirve porque el modelo funciona diferente. Unos meses más, llega una nueva generación de IA donde el modelo razona mejor por sí solo, y resulta que aquel chain-of-thought que diseñaron con tanto cuidado ahora estorba. Reescriben desde cero. Después cambia un formato de API o un framework, y a recablear todo otra vez.

La depreciación en IA no es gradual. Es un ciclo frustrante de reinicios que se sienten productivos mientras ocurren. Tu equipo está siempre ocupado, siempre entregando cambios. Pero si miras para atrás, el trabajo del primer trimestre ya no existe cuando llega el verano.

Escribí sobre este patrón en el contexto de inversiones en IA con fecha de vencimiento. El filtro 10x aplica a la perfección aquí: si el próximo modelo es diez veces mejor, ¿tu biblioteca de prompts todavía tiene sentido? Generalmente no. ¿Tu suite de evals? Siempre — porque el eval mide el resultado, no la técnica usada para producirlo.

El ciclo de acumulación

Un eval es un artefacto de naturaleza diferente. Cuando un analista de contratos en tu empresa escribe: “Un contrato correctamente clasificado debe incluir el nombre de la contraparte, la fecha efectiva, el valor total y la jurisdicción aplicable — y la jurisdicción debe coincidir con el estado de registro de la entidad firmante,” ese criterio no vence cuando cambias de modelo.

Ese estándar te va a servir igual para evaluar GPT-4, Claude Opus o cualquier modelo que salga el próximo trimestre. El eval te dice al instante: ¿el nuevo modelo lo hizo bien, o falló en el match de jurisdicción? Los modelos y las técnicas siguen evolucionando, pero tu línea base permanece intacta.

Con el tiempo, tu suite de evals se convierte en algo más valioso que un test harness. Se convierte en el registro institucional de qué significa “bueno” para cada proceso asistido por IA en tu empresa. Los nuevos miembros del equipo no tienen que hacer ingeniería inversa de lo que el modelo debería producir — leen los evals. Las migraciones de modelo toman días en vez de meses porque ya sabes qué probar. Cada nuevo data point de producción hace la suite más inteligente.

El eval que escribiste hace seis meses sigue funcionando hoy. A estas alturas tiene 200 casos de prueba más detrás y la confianza de tu equipo en el sistema es sustancialmente mayor. Ese retorno no lo consigues reescribiendo prompts cada trimestre.

Cómo se ve un sistema de evals en la práctica

Si tu empresa no tiene un sistema de evals hoy, aquí hay un modelo de madurez práctico. No necesitas empezar en el Nivel 3. Necesitas empezar en el Nivel 1 y dejar de pretender que el Nivel 0 es aceptable.

Nivel 0: “Se ve bien”

Aquí es donde está la mayoría de las empresas. Un humano lee el resultado de la IA, asiente, lo aprueba. No hay registro de por qué se consideró bueno. No hay forma de comparar el resultado de hoy con el del mes pasado. No hay forma de probar el modelo del próximo trimestre contra el estándar de hoy.

“Se ve bien” no es un estándar de calidad — es la ausencia de uno. Está bien para una demo de hackathon. Es peligroso para un proceso que afecta ingresos, cumplimiento regulatorio o experiencia del cliente.

Nivel 1: Datasets de referencia (Golden Datasets)

Recopila 50-100 ejemplos de entradas y salidas correctas de un proceso real del negocio. Clasificaciones de contratos, resoluciones de tickets de soporte, decisiones de scoring de leads — elige el proceso donde la IA ya se usa o está por usarse.

Este es tu primer activo que se acumula. Ejecuta tu configuración actual de IA contra él. Registra los puntajes. Cuando salga el siguiente modelo, ejecútalo de nuevo. Ahora tienes una respuesta factual, respaldada por números, a la pregunta “¿la actualización ayudó o perjudicó?” en vez de “parece que está bien.”

Construir esto toma días, no meses. Los datos ya existen en tu operación — son las decisiones que tu equipo ha estado tomando manualmente. Solo estás escribiéndolas en un formato que una máquina puede puntuar.

Nivel 2: Pipelines automatizados

Cada cambio de prompt, intercambio de modelo o modificación de contexto dispara una ejecución contra el dataset dorado. Las regresiones se detectan antes de llegar a producción. Aquí es donde 12.8 experimentos al día se vuelve posible — porque los experimentos están automatizados, no son manuales.

En este nivel, también puedes empezar a hacer A/B testing. Ejecuta las mismas entradas a través de dos configuraciones diferentes, puntúa ambas, elige la ganadora. Así es como los cambios de prompt pasan de “probemos esto a ver qué pasa” a “esta configuración puntúa 4% más alto en nuestro dataset.”

Nivel 3: Evals como conocimiento organizacional

Tu suite de evals es ahora el registro definitivo de cómo se ve “bueno” para cada proceso asistido por IA. Los nuevos miembros del equipo estudian los evals para entender qué debería producir el sistema. Los product managers referencian los puntajes cuando deciden qué procesos expandir. Las migraciones de modelo son decisiones de procurement, no proyectos de ingeniería — porque los criterios de aceptación ya existen.

Esto es lo que Goyal quiere decir con acumulación. Las empresas en el Nivel 3 no le temen a los cambios de modelo. Los celebran — porque cada actualización es una oportunidad de re-evaluar contra evals existentes y encontrar mejoras automáticamente.

Sin evals, la complacencia del modelo es invisible

Hay una conexión directa entre la madurez de evals y tu capacidad de detectar cuando la IA te da la razón sin merecerlo.

El benchmark SycEval de Stanford midió una tasa de sycophancy (complacencia) del 58% en los modelos de IA líderes. Más de la mitad de las veces, el modelo concuerda con lo que el usuario cree — sea o no correcto. En ~15% de las interacciones, el modelo confirma activamente una respuesta equivocada.

Escribí sobre este problema en detalle en el post sobre complacencia de IA y decisiones empresariales. La versión corta: si tu equipo usa IA para evaluaciones de proveedores, revisiones de arquitectura o recomendaciones estratégicas, esos resultados cargan un sesgo de confirmación incorporado que nadie nota.

Si no tienes evals, detectar esto es casi imposible. La IA dice “tu análisis se ve correcto,” todos concuerdan, y la decisión avanza. Nadie cuestiona porque el resultado suena seguro y coincide con lo que el equipo ya creía.

Con evals, hay una línea base objetiva. La clasificación de contrato está bien o mal — no importa qué tan seguro sonó el modelo. La comparación de proveedores incluye los data points requeridos o no los incluye. Ese “sí” complaciente del modelo se estrella contra un “no” objetivo y medible. Es lo más cercano a un antídoto contra una máquina de confirmar.

Qué construimos en IQ Source

Vi este mismo modo de falla durante el boom de ERP en los 2000, y otra vez durante la corrida a la nube una década después. Hoy estamos cometiendo el mismo error con IA: gastando fuerte en tecnología sin definir cómo se ve el éxito antes de que el proyecto arranque.

El resultado siempre es el mismo. Una empresa presenta un piloto de IA a la junta, todos asienten, el proyecto avanza, y seis meses después nadie puede probar que el resultado de la IA es mejor que lo que el equipo hacía manualmente. No porque la IA no sea mejor — sino porque nadie escribió qué significaba “mejor” en términos medibles antes de que el piloto comenzara.

Eso es un problema de evals, aunque nadie lo haya llamado así en su momento.

Gartner estimó que el 30% de los proyectos de IA generativa serían abandonados después del proof of concept. Ese número tiene todo el sentido cuando lo ves a través del lente de evals: sin criterios de éxito no hay forma de probar que el piloto funciona, sin prueba no hay confianza ejecutiva para escalar.

En IQ Source, cada proyecto empieza con lo que ahora llamamos la pregunta del eval: “¿Cómo se ve un resultado correcto para este proceso, y cómo lo medimos?” Esto debe hacerse antes de siquiera pensar en herramientas, proveedores o arquitectura. Si nadie puede responder eso con una definición concreta y verificable, el proyecto todavía no está listo para producción — sigue siendo una demo. Y nunca he visto una demo convertirse en un activo que se acumula por sí sola.

Nuestro enfoque trabaja en tres fases. Primera: definir qué significa “bueno” — no en un slide deck, sino como un dataset dorado con ejemplos puntuados. Segunda: seleccionar herramientas y configuraciones que puntúen más alto contra ese dataset. Tercera: medir continuamente, agregando ejemplos de producción a la suite de evals para que se vuelva más precisa cada mes.

Cuando sale un modelo nuevo, las empresas que construyeron así ejecutan sus evals, comparan puntajes y toman una decisión respaldada por datos en pocos días. El resto vuelve al “probemos a ver cómo se siente” — que es exactamente donde estaban hace un año.

---

Si tu empresa usa IA para algún proceso de negocio y no tiene una forma de puntuar el resultado, estás operando con “se ve bien.” Eso funcionaba cuando la IA era un proyecto secundario. No funciona cuando toca ingresos.

Envíanos un proceso asistido por IA — qué entra, qué sale, y cómo tu equipo decide hoy si el resultado es aceptable. Te damos un puntaje de preparación para evals en la escala Nivel 0-3 descrita arriba y te mostramos cómo deberían verse los primeros 10 casos de prueba. Sin pitch de ventas, solo un reporte de preparación de una página.

Obtener mi puntaje de preparación para evals