Tu agente no es peor. Tu setup sí.

Esta semana, siete personas distintas me dijeron alguna versión de la misma frase:

“Pásale esto a tu agente, el tuyo responde mejor que el mío.”

Mismo modelo. Distinto resultado. Y ninguna de esas siete personas —todas técnicas, varias muy buenas— sabía explicar por qué.

Yo tampoco. Sospechaba del contexto, del system prompt, de la máquina donde corre. Pero era corazonada, no diagnóstico. Y la diferencia entre esas dos cosas es exactamente de lo que trata este artículo.

El comentario que me hizo buscar en serio

La cosa quedó dando vueltas hasta que, en una comunidad de IA de LATAM, alguien lo dijo mejor que yo:

“Aunque todos usemos la misma herramienta, según qué tan técnica sea la persona, el resultado cambia.”

Eso ya no era mi corazonada: era la corazonada de otra persona, llegando por su cuenta al mismo lugar. Cuando dos personas tropiezan con el mismo patrón por separado, deja de ser anécdota y empieza a ser síntoma.

Y los síntomas se diagnostican. No se opinan.

Volver a los orígenes

Antes de dedicarme a esto yo hacía análisis de procesos. Y hay algo que en la industria se resolvió hace setenta años y que en IA seguimos haciendo mal.

Cuando en una fábrica salía mal una pieza, nadie decía “la máquina es mala”. Eso no es un diagnóstico, es una queja. Lo que hacían era dibujar una espina de pescado: poner el defecto en la cabeza y remontar hacia atrás por familias de causas, hasta encontrar cuál falló.

Lo inventó Kaoru Ishikawa. Y acá va el primer dato que me sorprendió, porque circula mal por todo internet: no lo creó en 1943, como repiten cientos de blogs. Lo cuenta él mismo en el volumen conmemorativo de JUSE: lo concibió alrededor de 1950-51, lo usó primero solo en un aula, y recién lo llevó a planta en 1952, en la Fukiai Plant de Kawasaki Steel. En 1943 Ishikawa ni siquiera hacía control de calidad: era ingeniero de licuefacción de carbón, y llegó a la estadística recién en 1948. Kawasaki Steel, además, no existía con ese nombre hasta 1950.

El apodo tampoco es suyo. “Espina de pescado” se lo pusieron los operarios de una planta en Aizu-Wakamatsu. Y cuando Ishikawa vio que solo dibujaban las espinas grandes, les explicó que también hacían falta las chicas usando a Godzilla de ejemplo, que estaba de moda.

Cuento esto porque es el punto entero del método: el diagnóstico lo hace quien está en la planta, no quien mira desde afuera. Nosotros somos los operarios.

Las 6M de la IA

Adapté las seis categorías clásicas —que la ASQ documenta como las 6M— a las causas por las que un agente falla en producción:

Máquina — el modelo y su infraestructura. Cambió la versión y nadie lo notó. La herramienta devolvió timeout y el agente siguió como si nada. La temperatura está alta donde debería ser determinista.

Materia prima — el contexto y los datos que entran. Dato mal formado, retrieval sin evidencia útil, esquema roto en la ingesta. El agente no falla: improvisa. Y el system prompt también es materia prima, aunque casi nadie lo trate así.

Método — cómo está construido el agente. Acá va un caso de hace unas horas. Le pedí a un modelo tope de gama que aplicara formato APA a una bibliografía. APA obliga a rellenar autor, fecha exacta, número de volumen. Cuando el modelo no encontró el volumen en la fuente, lo inventó para “completar” la cita en vez de dejarlo vacío.

El detonante no fue el modelo. Fue cómo se lo pedí: un formato rígido, sin una regla que dijera “si el campo no está, omítelo”. La fuente y el contenido de fondo eran correctos; lo que se torció fueron los campos exactos.

Y fíjate que ese caso cruza dos espinas: el hueco lo pone Materia prima (la fuente no tenía el dato), pero quien falla es Método (no había regla para manejar la ausencia). Se arregla en el punto que controlas.

Mano de obra — quién lo opera, y qué tan bien. La misma herramienta en dos manos da dos resultados. Y cuando el agente debía decir “no sé, que lo revise una persona”, prefirió inventar.

Medición — cómo sabes si el resultado es bueno. Sin evals no es que no falle: es que no te enteras. Yo mismo usé un juez LLM para rankear los temas de mis piezas y tuve que tirar los puntajes a la basura: el juez se prefería a sí mismo. El instrumento me estaba mintiendo, y solo me di cuenta porque fui a mirarlo.

Medio ambiente — lo que rodea al agente y a quien lo opera. El proveedor saca una versión nueva y tu agente sigue igual. Anda en dev y falla en prod. Trabajas solo, sin nadie que te diga “eso ya lo intenté y no anda”.

Fui a ver si alguien ya lo había hecho

Acá es donde el artículo se pone incómodo, y donde creo que está lo único que vale la pena leer.

Revisé once marcos de fallas de IA. No leyendo resúmenes: descargando cada PDF y buscando en el texto completo. TRAIL de Patronus, MAST de Berkeley, NIST AI RMF, OWASP Agentic, MCP-Atlas de Scale AI, el Databricks AI Security Framework, las taxonomías del AI Red Team de Microsoft, el AI Incident Database.

Ninguno menciona a Ishikawa. Ni “fishbone”, ni “causa-efecto”, ni “5M”, ni “6M”. Cero.

Pero antes de que eso suene a “descubrí algo”: no descubrí nada. Dos trabajos ya habían aplicado el fishbone a la IA, y son los más viejos de todo el corpus que revisé:

• Feng et al. (2022), en npj Digital Medicine —del grupo Nature— usa un diagrama de Ishikawa con la cabeza puesta en la caída de AUC de un modelo clínico. Es exactamente el gesto.
• Koessler & Schuett (2023), del Centre for the Governance of AI, propone el método fishbone con las 6M para empresas de AGI.

Así que el claim honesto no es “nadie lo hizo”. Es otro, y es peor: el fishbone llegó a la IA en 2022, y cuando llegaron los agentes, el campo lo olvidó. Toda la ola de taxonomías de 2025-2026 no cita a ninguno de los dos. Esto no es un invento. Es una recuperación.

El hueco que sí encontré

Cuando armé la matriz de once documentos contra las seis M, apareció algo que no esperaba. No está en las filas. Está en las columnas.

Acá está completa, ordenada del más reciente al más antiguo. Ningún documento menciona a Ishikawa: cada celda es mapeo mío, por analogía.

✓ la cubre ~ parcial / por analogía · no la cubre ✕ la excluye explícitamente

“Método” está en los once. Ni uno solo lo deja afuera. Es la causa más estudiada de toda la literatura —y por lo tanto la que menos te diferencia si la miras.

“Medio ambiente” está en uno. Diez de once lo ignoran por completo. Y el único que lo nombra es Koessler, que habla de riesgo catastrófico de AGI, no de un agente que se cayó un martes.

Las tres de abajo —Mano de obra, Medición, Medio ambiente— son el eje del operador. Quién lo usa, cómo mide si está bien, con qué comunidad se apoya.

Y hay un detalle que remata el argumento. El diagrama de Feng, el único Ishikawa aplicado a un sistema de IA real que existe en la literatura, tiene cinco ramas: señales fisiológicas, sistema de historia clínica, resultado, medicación, historia de la enfermedad. Ninguna humana. El único fishbone de IA que existe es ciego a quien lo opera.

La objeción que me hago yo

El marco que más me costó fue NIST. Porque si yo dijera “ningún framework cubre Medición ni Mano de obra”, NIST me hunde en dos segundos: tiene una función que se llama literalmente MEASURE, con una subcategoría (MEASURE 2.13) que es medir la medición, y una categoría entera (GOVERN 3) dedicada al personal.

Así que el claim de cobertura es falso y lo abandono. Pero hay uno que sobrevive, y es más preciso: en las 48 páginas del AI RMF, la frase “root cause” aparece cero veces. NIST te dice qué hacer. No te dice por qué falló esto.

Esa es la diferencia entre un marco de gestión y un diagnóstico. Y es la única grieta que reclamo: nadie usa estas categorías como familias causales de las que colgar las causas de una falla concreta.

Entonces, ¿por qué tu agente y el mío no responden igual?

Porque toda la industria mira la máquina, los datos y la arquitectura —y casi nadie mira al operador.

Y no lo digo como opinión. Lo dice el trabajo más riguroso que encontré sobre el tema: MAST, de Berkeley, publicado en NeurIPS 2025. Midieron que con el mismo modelo subyacente, mejorar la especificación de roles sube el desempeño 9,4%, y agregar verificación de objetivo lo sube 15,6%.

Mismo modelo. Distinto setup. Distinto resultado. Medido.

Cuando alguien me dice “tu agente responde mejor”, no está viendo un modelo mejor. Está viendo un contexto curado, un método con guardrails, evals que me avisan cuando algo se rompió, y una comunidad que ya pisó los charcos que yo estoy por pisar.

Nada de eso viene en el modelo. Todo eso lo pone el operador.

Tu agente no es peor. Tu setup sí.

Y la buena noticia es que el setup se arregla. El modelo, no.

Adaptación propia del diagrama de Ishikawa. Las 6M son la taxonomía de ASQ; las “5M” que circulan en internet vienen de lean manufacturing / Toyota, no de Ishikawa. El mapeo de las 6M a las causas de falla de un agente es mío, por analogía: ninguno de los once documentos menciona el método. Y como toda ausencia, la mía tiene límite: no barrí IEEE, ACM ni repositorios en español, así que si alguien ya escribió esto antes, quiero saberlo.

El framework navegable, con la evidencia de cada M: analizodatos.com/6M-IA