CTGT lanza Concordance, código abierto que audita agentes IA

El mismo manual bancario de nueve páginas, procesado cuatro veces por el mismo modelo, produjo 32, 31, 33 y 33 obligaciones distintas. Ninguna de las cuatro salidas coincidió. Para cualquier equipo que esté poniendo agentes de IA a aprobar, marcar o registrar decisiones, ese resultado es la advertencia más concreta que se publicó esta semana.

Concordance es un sistema de código abierto, liberado bajo licencia Apache 2.0, que permite investigar por qué una aplicación de IA toma decisiones distintas cuando se le pide exactamente la misma tarea. Lo publica CTGT, un laboratorio de interpretabilidad aplicada que trabaja con banca y seguros y que hasta ahora operaba en modo discreto.

El paquete incluye el protocolo de pruebas, la implementación de referencia y los datos del experimento. La empresa aclara que no tiene planes de ofrecer una edición paga ni alojada: el software se puede usar y modificar comercialmente bajo esa licencia.

Leíste lo que hace la IA. ¿Y en tu negocio?

En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.

👥 Probar 7 días

La decisión es llamativa para una startup que también vende un motor de cumplimiento normativo para empresas reguladas. Ese producto comercial es independiente de Concordance, y el experimento que acompaña el lanzamiento corrió sobre la propia aplicación de CTGT, no sobre el despliegue de un cliente.

Cyril Gorlla, fundador y CEO de la compañía, resume el criterio detrás de la herramienta: «Tienes que empezar donde la IA efectivamente compromete algo que después alguien podría pedirte que defiendas».

El mismo manual bancario, cuatro respuestas distintas

El caso que documenta el lanzamiento es muy concreto. El sistema procesó un manual bancario minorista de nueve páginas con Qwen3.8-27B y el modo de inferencia determinista de SGLang. Cuatro corridas extrajeron 32, 31, 33 y 33 obligaciones. Los totales se parecían; los resultados, no: las cuatro salidas eran diferentes.

El detalle incómodo es que el modelo no era el problema. CTGT encontró que respondió de forma consistente en las 74 solicitudes idénticas que se repitieron durante esas corridas. Lo que cambiaba era lo que la aplicación le enviaba.

«Entonces, incluso si arreglas la no determinación del modelo, tu pipeline puede seguir dándote cuatro respuestas distintas», dijo Gorlla.

La empresa identificó tres causas, todas en la capa de software y ninguna en el modelo:

  • Identificadores específicos de cada carga de archivo que aparecían dentro de los prompts.
  • Una lista de ruteo de 30 ítems cuyo orden cambiaba entre corridas.
  • Un registro de temas que se expandía entre ejecuciones, alterando las solicitudes posteriores.

En una de las comparaciones, la diferencia estaba en solo cuatro líneas de identificador dentro de una solicitud de 12.525 caracteres. Ese cambio alcanzó para que el modelo clasificara cinco reglas de resolución de conflictos como información de contexto y omitiera una obligación que otra corrida sí conservaba.

La corrección fue igual de específica: reemplazar los identificadores por etiquetas estables, ordenar la lista y aislar cada prueba en un entorno organizacional nuevo. Cinco corridas posteriores produjeron las mismas 34 obligaciones.

Repetible no es lo mismo que correcto

Hay un segundo resultado que conviene no pasar por alto. En una prueba de serving separada, Qwen3.8-27B coincidió con su respuesta de control en las 800 solicitudes bajo la configuración determinista. Eso mide acuerdo textual exacto, no acierto.

La distinción se vuelve evidente en el experimento de cumplimiento: al repetir la solicitud que había producido una clasificación incorrecta, el mismo error apareció ocho veces.

«Creo que lo que mucha gente confunde es que repetible no es necesariamente lo mismo que correcto», dijo Gorlla.

Parte de la explicación teórica viene de la investigación de Thinking Machines Lab sobre la no determinación en la inferencia de LLM: incluso el ajuste de generación menos aleatorio no garantiza respuestas idénticas, porque los cambios en el batching del servidor afectan los cálculos numéricos. CTGT usa el modo determinista de SGLang, que según sus representantes se apoya en ese trabajo.

Que un mismo resultado se repita ocho veces sin variación es, en un flujo de cumplimiento, la diferencia entre un error corregible y un error sistematizado. Un sistema que se equivoca siempre igual es más difícil de detectar justamente porque parece estable.

¿En qué se diferencia de LangSmith, Braintrust o Langfuse?

CTGT posiciona Concordance como un complemento de las herramientas de trazado que ya existen, no como un reemplazo. La distinción que propone es el procedimiento de comparación: repetir el trabajo, alinear las etapas y determinar si la divergencia la explican insumos que cambian o respuestas que cambian.

Las plataformas instaladas cubren buena parte de ese terreno. LangSmith soporta evaluaciones repetidas y evaluación de decisiones intermedias del agente. Braintrust permite múltiples ensayos y expone llamadas al modelo, funciones de la aplicación y herramientas en sus trazas. Langfuse captura prompts, respuestas, pasos de recuperación y actividad de herramientas, con soporte para autoalojamiento. Arize Phoenix combina trazado, evaluación y experimentos mediante instrumentación OpenTelemetry y OpenInference.

Vale la pena decirlo con claridad: CTGT no presentó ningún benchmark comparativo que demuestre que estas plataformas no pueden encontrar las mismas fallas. La empresa tampoco ofreció resultados de clientes para Concordance; la anécdota sobre una consultora que encontró falsos positivos pasa por alto corresponde a LineageEval, un marco anterior y distinto. El argumento de Gorlla, en todo caso, es simple: «no hay nada que desarmar, es gratis, es Apache 2.0».

¿Los modelos de decisión resuelven el problema en otra capa?

Existe una ruta alternativa que ataca el problema en el diseño y no en la depuración. El enfoque System One de TypeSafe, encarnado en Jev, devuelve opciones acotadas, puntajes y probabilidades para que el software las consuma: el desarrollador especifica las respuestas disponibles en lugar de pedirle al modelo una respuesta libre. AWS describe además una categoría más amplia de modelos de decisión que incluye a Jev, SemIf y Strands Decider 2B.

La arquitectura recomendada por TypeSafe deja el control del flujo y las reglas de negocio deterministas en el código, y usa la IA para juicios acotados sobre información no estructurada. En un flujo de cumplimiento, eso significaría que un modelo clasifique un conflicto mientras el código exige la escalación cada vez que se cumple la condición relevante. Es una implicación arquitectónica, no una configuración que CTGT haya probado.

TypeSafe documenta limitaciones propias para Jev 1.13, entre ellas la sensibilidad al orden de las opciones y la dificultad con contexto irrelevante. Su demostración de autoconsistencia reporta cambios de etiqueta en dos de ocho preguntas a lo largo de pruebas repetidas que incluían un identificador nuevo en cada solicitud. Enviar los resultados inciertos a revisión humana mejoró la coincidencia, pero la empresa advierte explícitamente que eso no vuelve determinista al modelo.

Y hay un límite estructural que ningún formato de salida resuelve: si una etapa anterior de procesamiento de documentos omite una obligación, un clasificador posterior no puede hacer cumplir una regla que nunca recibió.

Qué significa esto para tu startup

La lección más útil del caso no es que los modelos sean poco confiables, sino que buena parte de la inconsistencia se fabrica en tu propio pipeline. Si estás construyendo agentes que aprueban, marcan o registran decisiones, esto es lo que puedes hacer desde ya:

  • Prioriza por consecuencia. No todo merece el mismo rigor. Un asistente de redacción cuya salida pasa por revisión humana es un problema distinto a un agente cuyo output se convierte en registro autoritativo del negocio. Empieza por aprobaciones, marcados, obligaciones de cumplimiento y siniestros.
  • Guarda el request completo, no solo el output. La mayoría de los equipos registra la respuesta del modelo y pierde el prompt exacto. Concordance encontró la causa en cuatro líneas de identificador dentro de una solicitud larguísima: sin el request guardado, ese hallazgo es directamente imposible.
  • Congela lo que no debería variar. Identificadores de carga, orden de listas de ruteo, registros que crecen entre corridas. Si un elemento no aporta información semántica, no debería entrar al prompt ni cambiar de forma.
  • Repite las pruebas cuando cambie algo. Modelo, prompt o documento fuente. Mantén un conjunto de ejemplos con resultado esperado conocido para detectar si el comportamiento se degradó.
  • No necesitas los pesos del modelo. Con APIs propietarias puedes comparar entradas, salidas y decisiones. El acceso a los pesos habilita una investigación más profunda, pero no es requisito para empezar.

Hay un atajo mental que conviene evitar: arreglar el determinismo del modelo y dar el problema por cerrado. El experimento muestra justo lo contrario. El modelo puede responder igual 74 veces y tu aplicación seguir produciendo cuatro documentos distintos.

Conclusión

Concordance no es una bala de plata, y CTGT es el primero en no presentarlo así: no hay evidencia de que prevenga violaciones de políticas de forma automática, ni comparación pública contra alternativas comerciales, ni resultados de clientes. Lo que sí ofrece es un marco reproducible para responder una pregunta que cualquier empresa regulada va a tener que contestar tarde o temprano: cuando esta decisión se revisó, por qué salió distinto.

Para un founder, el valor inmediato está en el método más que en la herramienta. Registrar los requests completos, congelar lo que no debe variar y repetir las pruebas cuando algo cambie son prácticas que se pueden adoptar hoy, con licencia Apache 2.0 o sin ella. La advertencia de que repetible no es lo mismo que correcto debería quedar pegada al lado de cualquier dashboard de agentes: la consistencia es una condición necesaria, nunca una prueba de acierto.

Fuentes

¿te gustó o sirvió lo que leíste?, Por favor, comparte.

Leíste lo que hace la IA. ¿Y en tu negocio?

En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.

👥 Probar 7 días

Daily Shot: Tu ventaja táctica

Lo que pasó en las últimas 24 horas, resumido para que tú no tengas que filtrarlo.

Suscríbete para recibir cada mañana la curaduría definitiva del ecosistema startup e inversionista. Sin ruido ni rodeos, solo la información estratégica que necesitas para avanzar:

  • Venture Capital & Inversiones: Rondas, fondos y movimientos de capital.
  • IA & Tecnología: Tendencias, Web3 y herramientas de automatización.
  • Modelos de Negocio: Actualidad en SaaS, Fintech y Cripto.
  • Propósito: Erradicar el estancamiento informativo dándote claridad desde tu primer café.

📡 El Daily Shot Startupero

Noticias del ecosistema startup en 2 minutos. Gratis, todos los días.

Share to...