La ingeniería de calidad es el 80% del despliegue de agentes de IA

Estamos construyendo sistemas autónomos de IA que operan funciones de negocio completas. No copilots. No chatbots. Sistemas que ejecutan backlogs de investigación de 37 tareas, toman decisiones de enrutamiento y operan con presupuestos de $20/día sin un humano vigilando. La parte que más tarda no es construir esos sistemas. Es hacer que dejen de producir basura.

La ingeniería de calidad de agentes de IA consume aproximadamente el 80% de nuestro tiempo de deployment. La lógica del agente, el diseño de prompts, la plomeria de integraciones — todo eso es el 20% fácil. El resto del calendario se va en construir sistemas que detecten cuando un agente ha producido algo inútil y eviten que se trate como trabajo real.

Así se ve en la práctica.

Las tres reescrituras

Nuestro daemon de investigación legal es un sistema de 10 agentes corriendo como aplicación Flask en un VPS de DigitalOcean. Maneja un backlog de tareas de investigación legal para un venture de legal tech ecuatoriano. 10 agentes, 4 configuraciones de equipo, ciclos de sprint autónomos, tope de presupuesto de $20/día. Vamos por la tercera versión mayor de la capa de calidad. Cada reescritura ocurrió porque descubrimos una nueva categoría de falla que la versión anterior no atrapaba.

Versión 1: Sin gates de calidad. Apuntamos 10 agentes a un backlog de investigación y los dejamos correr. El output era técnicamente fluido y sustantivamente inútil. Los agentes producian análisis legales de 2,000 palabras con terminología correcta organizada en patrones sin sentido. Un agente escribio un “análisis de mercado” detallado que era en realidad una reformulación de sus propias instrucciones, rellenado con observaciones genericas sobre el sector de legal tech. No podíamos distinguir esto de trabajo real escaneando el output rápidamente. Se leía bien. No decía nada.

Versión 2: Validación básica de output. Agregamos chequeos para las fallas obvias: respuestas vacias, rechazos explícitos (“Cómo IA, no puedo…”), texto placeholder. Esto atrapo el 20% inferior de basura pero introdujo un nuevo problema. Empezamos a llamarle “basura sofisticada”: outputs que pasaban chequeos superficiales pero no contenian información real. Un agente producía un análisis competitivo bien formateado con encabezados, bullet points y cifras porcentuales, donde cada porcentaje era inventado y cada nombre de empresa era real pero las afirmaciones sobre ellas eran fabricadas.

Versión 3: Control de calidad de tres capas. Esto es lo que corre en producción ahora. Atrapa la basura sofisticada que la versión 2 dejaba pasar.

Cada reescritura agregó aproximadamente una semana de tiempo de desarrollo. El esfuerzo total de ingeniería de calidad en este único sistema excede el tiempo invertido en la lógica de agentes, la capa de integración y la infraestructura de deployment combinados.

50+ patrones de detección de basura

La primera capa de nuestro sistema de calidad es detección de basura basada en patrones. Mantenemos una lista de 50+ patrones de strings que indican que el agente fallo en producir output útil. Cada patrón fue agregado después de una falla específica en producción. Ninguno fue predicho por adelantado.

Los patrones caen en seis categorías.

Meta-comentario. El agente describe lo que haría en lugar de hacerlo. Patrones incluyen: “let me search,” “I will now proceed,” “below is the plan for executing,” “I’ll attempt to,” “I need to search.” Son particularmente comunes cuando los agentes corren en modo solo-síntesis (sin acceso a herramientas en vivo) y no han sido instruidos con suficiente firmeza para trabajar desde el contexto en lugar de solicitar acciones externas.

Resultados de búsqueda vacíos. El agente reporta no encontrar nada y presenta ese reporte como su entregable. Patrones: “no results found,” “could not find,” “unable to find,” “search returned no,” “no data available,” “returned 0 results.” Vemos esto cuando los agentes reciben instrucción de investigar un tema pero la ventana de contexto no contiene material relevante.

Rechazos y límites de capacidad. El agente se niega a hacer el trabajo. Patrones: “as an AI,” “as a language model,” “I cannot access,” “outside my capabilities,” “I’m unable to.” Estas son las fallas más obvias pero aun representan aproximadamente el 10% de los outputs bloqueados.

Confusión de herramientas y funciones. El agente intenta invocar herramientas que no existen en su contexto de ejecución actual. Patrones: “function call,” “tool_call,” “function_call,” “```tool_code.” Esto ocurre cuando ejecutamos agentes con tools=[] (modo solo-síntesis) y los datos de entrenamiento del agente sobreescriben sus instrucciones.

Planificación sin acción. El agente produce un plan para trabajo futuro en lugar de output real. Patrones: “the next step would be,” “the following steps should,” “we would need to,” “this would involve.” Esta es la categoría más comun. Los agentes caen por default en planificación cuando están inciertos.

Quejas de permisos. El agente explica que carece de permisos para completar la tarea. Patrones: “I need write permissions,” “what I would accomplish,” “what I would deliver,” “given the constraints,” “if I had access.” Vemos estos cuando los agentes encuentran una tarea que interpretan como requiriendo acceso a sistema de archivos o API que no tienen.

La función de detección es directa: cualquier output menor a 50 caracteres es automáticamente basura. Para todo lo demás, convertir el texto a minusculas y verificar coincidencias de substrings contra la lista de patrones. Si cualquier patrón coincide, el output se rechaza.

def _is_garbage_output(text: str) -> bool:
    if not text or len(text.strip()) < 50:
        return True
    lower = text.lower()
    return any(p in lower for p in GARBAGE_PATTERNS)

Esto atrapa aproximadamente el 30% de outputs malos. El 70% restante de las fallas de calidad es basura sofisticada que requiere el sistema de scoring.

Scoring de contenido: 0.0 a 1.0

Cada output que pasa la capa de detección de basura recibe un puntaje en escala de 0.0 a 1.0. Cualquier cosa debajo de 0.4 se rechaza. El algoritmo de scoring es deliberadamente simple porque necesitamos que sea predecible y debuggeable.

Puntaje base: 0.3. Cualquier contenido que existe y tiene más de 30 palabras comienza en 0.3. Debajo de 30 palabras, el puntaje es 0.1 sin importar el contenido.

Bono por conteo de palabras: hasta +0.2. Contenido con 100+ palabras recibe +0.1. Contenido con 300+ palabras recibe otro +0.1. Esto premia output sustantivo sin requerir una longitud específica.

Marcadores de sustancia: hasta +0.3. Verificamos seis tipos de contenido concreto: montos en dólares ($[\d,.]+), porcentajes (\d+%), URLs (https?://), fechas (\d{4}[-/]\d{2}), formato de tabla (|...|), y encabezados estructurados (^#{1,3}\s). Cada marcador encontrado suma 0.05, con tope en 0.3. Esto premia outputs que contienen información específica y verificable en lugar de prosa abstracta.

Penalización por planificación: -0.15. Si el output contiene 3 o más frases de planificación (“we should,” “the plan is,” “recommend that we,” “steps to take,” “action items include”), recibe penalización. Un output lleno de recomendaciones sobre que hacer después es menos valioso que un output que hace el trabajo.

La función de scoring devuelve tanto el puntaje numérico como un string de razón legible por humanos. Cuando un output se rechaza, el log muestra exactamente por que: “too short (28 words)” o “planning-heavy (4 phrases)” o “baseline” (significando que paso el umbral de 0.4 solo por conteo de palabras y marcadores de sustancia).

El umbral de 0.4 fue calibrado empíricamente. Calificamos 200 outputs historicos a mano, marcando cada uno como “útil” o “basura.” 0.4 produjo la mejor separación. Debajo de 0.35, estábamos rechazando algunos outputs cortos pero útiles. Encima de 0.45, estábamos aceptando algo de basura sofisticada.

En nuestro motor de producción de contenido, estamos probando un sistema de scoring más agresivo para artículos de blog. Ese verifica especificidad (números, montos en dólares, fechas), compliance de anti-patrones de IA (vocabulario prohibido, punchlines con em-dash, juxtaposición innecesaria), optimización de keywords, consistencia de voz y accionabilidad. Los artículos se califican en un compuesto ponderado y se rechazan debajo de 0.7. Hemos tenido artículos que fallan solo en el chequeo de compliance anti-IA, lo cual dispara una pasada de revisión con instrucciones explicitas sobre que corregir.

El tope de reintentos

Ambas capas alimentan un mecanismo de reintentos. Cuando un output falla calidad (ya sea detección de basura o scoring debajo de 0.4), la tarea vuelve a estado “pending” y se intenta de nuevo en el siguiente ciclo de sprint. Pero los reintentos tienen tope de 3. Después de 3 outputs basura para la misma tarea, la tarea queda permanentemente bloqueada y marcada para revisión humana.

Este es el mecanismo de protección de presupuesto. Sin el tope de reintentos, el sistema gastaría llamadas de API ilimitadas en tareas que fundamentalmente no puede completar. Hemos visto tareas fallar 3 veces porque la ventana de contexto carecia del material fuente necesario, porque la descripción de la tarea era ambigua, o porque la tarea requeria datos en tiempo real que el sistema no podia acceder en modo solo-síntesis.

De las 37 tareas en nuestro backlog de investigación legal, 33 se completaron exitosamente. Las 4 que se bloquearon estaban todas en la categoría de financiamiento, esperando timelines de grants externos. Ninguna de las 4 fue bloqueada por fallas de gate de calidad. Pero hemos visto otros deployments donde 15-20% de las tareas alcanzan el tope de reintentos. El porcentaje depende de que tan bien las tareas del backlog coinciden con las capacidades reales del agente.

Separación de roles

El segundo sistema de calidad que operamos en producción es estructural: el agente que escribe nunca puede ser el agente que revisa.

Aprendimos esto de nuestros research systems. Operamos 6 agentes en tres areas de investigación (economía latinoamericana, gobernanza de IA, IA y crypto) con 16 skills personalizados y un pipeline de control de calidad de 4 gates. Los gates corren en secuencia estricta: verificación de fuentes, chequeo de voz, revisión adversarial, aprobación de publicación. Cada gate es propiedad de un agente diferente.

El research-analyst escribe borradores. El source-reviewer verifica cada cita por precisión, relevancia, frescura de datos y compliance de formato. El quality-controller ejecuta revisiones adversariales, auditorias de voz y toma la decisión final de publicación. Estos tres roles se despliegan como instancias de agente separadas con system prompts separados, memoria separada y acceso a herramientas separado.

Cuando desplegamos el research system por primera vez, el mismo agente escribía análisis y los revisaba. El agente aprobaba su propio trabajo cada vez. Las revisiones eran un parrafo de elogios seguido de “aprobado para publicación.” Atrapamos esto después de que un artículo mal referenciado paso por el pipeline con citas fabricadas que el agente que escribio describió como “verificadas” en su propia revisión.

La separación se aplica a nivel de pipeline. Las instrucciones del source-reviewer dicen explícitamente: “Tu revisas fuentes. No escribes borradores.” Las instrucciones del quality-controller empiezan con: “Nunca produces contenido de investigación original. Lo pruebas, lo rompes y decides si se pública.” Cuando un borrador necesita reescritura, el quality-controller lo devuelve al research-analyst con instrucciones especificas. El quality-controller identifica problemas. No los arregla.

Esto refleja como funcionan los departamentos de investigación que funcionan bien. La persona que escribe el reporte no firma su propio fact-checking. La diferencia es que con agentes de IA, la tentación de colapsar estos roles es más fuerte porque es “la misma tecnología.” La tecnología no importa. La estructura de incentivos importa. Un revisor que produjo el trabajo original tiene toda razón para aprobarlo.

El pipeline de calidad de 4 gates

Para nuestros research systems, el pipeline de calidad tiene cuatro gates secuenciales. Una falla de gate detiene el pipeline. El contenido no puede saltar gates ni pasarlos fuera de orden.

Gate 1: Verificación de fuentes. Cada cita usa formato de hyperlink inline. Cada URL se busca y confirma activa. Cada estadistica se rastrea a una fuente de Nivel 1-3 (legislación primaria, investigación peer-reviewed, o reportes institucionales). No quedan tags de [CITATION-NEEDED] ni [NEEDS-VERIFICATION]. El agente source-reviewer ejecuta este gate usando WebFetch para verificar cada URL y WebSearch para buscar datos más recientes.

Gate 2: Chequeo de voz. Puntaje de autenticidad de 4 o más en cinco dimensiones: variación de longitud de parrafo, variación de longitud de oración, uniformidad de template, especificidad y toma de posición. Cero vocabulario prohibido. Cero tells estructurales de IA. Mantenemos una lista de anti-patrones: punchlines con em-dash, juxtaposición innecesaria “no X, sino Y”, tríadas con tercer item escalatorio, parrafos abstractos sin detalle concreto, hedging bland (“vale la pena notar,” “interesantemente”), lenguaje sensorial falso (“solución robusta,” “plataforma seamless”), y callbacks forzados. El chequeo de voz ejecuta scans programáticos (Grep contra la lista prohibida) y evaluación basada en LLM para los patrones más sutiles.

Gate 3: Revisión adversarial. El quality-controller ejecuta una pasada de red team en cinco dimensiones: precisión factual, coherencia lógica, sesgo de selección, scope creep y contraargumentos steelman. Para cada afirmación mayor, el agente escribe el contraargumento más fuerte que puede encontrar, respaldado por fuentes reales (no objeciones hipotéticas). Luego ejecuta un pre-mortem: “Si esta investigación esta equivocada en 2 años, las razones más probables son…” Cada desafío debe ser abordado en el texto o documentado en la sección de limitaciones.

Gate 4: Publicación. Los gates 1-3 pasan. El formato coincide con el template de output. Los metadatos están completos. La entrada de catálogo esta preparada. Se agregan tags de relevancia cross-equipo para que los hallazgos sean descubribles por otras areas de investigación.

El sistema de 4 gates agrega 2-3x el tiempo por documento comparado con un flujo de escribir-y-publicar. Consideramos esto el costo de no publicar basura. Nuestra investigación cubre temas relevantes para política pública donde una cita fabricada puede desacreditar meses de trabajo.

Lista de anti-patrones vs. instrucciones positivas

Un hallazgo contraintuitivo de construir estos sistemas: las instrucciones negativas funcionan mejor que las positivas.

Decirle a un agente “escribe naturalmente” produce output genérico. Decirle a un agente “no uses punchlines con em-dash, no uses juxtaposición innecesaria, no uses tríadas con tercer item escalatorio, no uses frases de hedging bland incluyendo ‘vale la pena notar’ e ‘interesantemente’” produce escritura mediblemente mejor. El agente necesita ejemplos concretos de que evitar.

Lo mismo aplica a la detección de basura. Decirle a un agente “produce output sustantivo” no previene respuestas en modo planificación. Listar 50 patrones específicos que constituyen basura si. Cada patrón en nuestra lista existe porque un agente produjo exactamente esa falla en producción.

Mantenemos una lista de “palabras prohibidas” para nuestro motor de contenido con 19 entradas: “leveraging synergies,” “disrupting,” “delve,” “utilize,” “game-changer,” “paradigm shift,” “move the needle,” “cutting-edge,” “state-of-the-art,” “revolutionary,” entre otras. También mantenemos patrones regex para anti-patrones de IA: punchlines con em-dash seguidos de revelaciones dramaticas, tríadas con tercer item escalatorio, frases de hedging bland. Los artículos que coinciden con cualquier patrón se marcan para revisión.

El overhead de mantener estas listas es modesto. Agregamos 2-3 patrones nuevos por semana al descubrir nuevos modos de falla. El ROI es alto porque cada patrón previene una clase de falla en lugar de una sola instancia.

Lo que esto cuesta

La capa de ingeniería de calidad agrega aproximadamente 35-40% al costo de API de un deployment. Para el daemon legal corriendo a $20/día máximo, los chequeos de calidad (detección de basura + scoring de contenido + ciclos de reintento) representan aproximadamente $7-8 de ese presupuesto. Los agentes quality-controller y source-reviewer en nuestro research system consumen aproximadamente el 30% del total de tokens.

Consideramos esto un buen tradeoff. La alternativa es publicar basura, que cuesta más en retrabajo, reputación y confianza del cliente que el gasto de API en prevención.

El costo humano es más significativo. La ingeniería de calidad es el 80% del calendario de desarrollo para un nuevo deployment. Para el daemon legal, eso significo 3 reescrituras completas de la capa de calidad en las primeras 2 semanas de operación. Para el research system, significo 7 días de un sprint de construcción de 10 días dedicados a documentos de estándares, gates de calidad, separación de agentes y testing. Para el motor de contenido, significo construir un sistema de scoring con 5 dimensiones ponderadas y un pipeline de revisión antes de escribir un solo artículo.

Si tu consultora de IA te muestra un demo y lo llama deployment, busca otra consultora. El demo es el primer 20%. La ingeniería de calidad que lo hace seguro para operar sin supervisión es el otro 80%.

---

Synaptic convierte empresas en organizaciones AI-native. Empezamos donde termina el demo. synaptic.so