Cómo analizar entrevistas con IA sin sesgar los hallazgos del research

3 min read

A Sunday on La Grande Jatte
A Sunday on La Grande Jatte—1884” de Georges Seurat dialoga muy bien con este artículo porque convierte una escena completa en una construcción hecha de unidades mínimas. Igual que en el análisis de entrevistas con IA, el problema no es trabajar con fragmentos, sino olvidar que una síntesis sólo vale cuando respetas cómo esos fragmentos se relacionan y en qué momento pueden leerse como conjunto. Georges Seurat, Art Institute of Chicago

Hace unos días me escribió una participante de una edición anterior del curso de IA. Estaba empezando un research en su trabajo, las transcripciones se realizaban automáticamente en Teams y, además, había armado un agente en Copilot para analizar las entrevistas. Quería saber si podía ir subiendo las transcripciones una por una, a medida que terminaba cada conversación, o si eso iba a sesgar los hallazgos y convenía esperar al final.

La pregunta parecía técnica. Casi una duda de configuración. Qué se puede conectar, qué conviene automatizar, en qué momento correr el análisis. Pero no era una pregunta técnica.

Era una pregunta sobre cuándo una ayuda deja de ser ayuda y empieza a empujar el research en una dirección demasiado pronto.

Ése me parece el punto importante acá. No si hoy existe o no existe una herramienta capaz de resumir una entrevista en segundos. Eso ya está bastante resuelto. Lo difícil no es conseguir una lectura rápida del material. Lo difícil es no confundir esa primera lectura con una interpretación suficiente del conjunto.

Porque sí, la IA puede servirte mientras todavía estás entrevistando. Puede ayudarte a ordenar una conversación, detectar temas que aparecen, marcar una frase útil, devolver una tensión que conviene seguir mirando o incluso mostrarte que una pregunta de tu guía no está funcionando como pensabas. Todo eso puede ser valioso mientras el trabajo de campo sigue vivo.

El problema no aparece cuando miras una entrevista temprano. Aparece cuando tratas esa lectura temprana como si ya tuviera el peso de un hallazgo.

Y esa diferencia parece menor, pero no lo es.

Una entrevista sola puede darte señales. Puede darte lenguaje, fricción, hipótesis, incluso una sospecha interesante. Lo que no puede darte todavía es una lectura defendible de lo que está pasando en el research. Para eso necesitas contraste, repetición, excepciones, matices, contexto. Necesitas ver cómo una entrevista conversa con las otras. Necesitas, también, tu propio trabajo de interpretación.

Por eso el punto relevante no es si vas a usar resultados parciales antes o después de completar el research. La pregunta correcta es otra: qué clase de respuesta le estás pidiendo a la herramienta y cuánto peso estás dispuesto a darle.

No pesa lo mismo una cita textual que una agrupación automática. No pesa lo mismo una observación del analista que una síntesis generada por un sistema. No pesa lo mismo una señal parcial que una lectura transversal del conjunto. El problema empieza cuando todo eso se mezcla en un mismo plano y el equipo empieza a tratar como equivalente cosas que no lo son.

Ahí es donde el proceso se vuelve frágil, aunque por fuera se vea cada vez más ordenado.

De hecho, ése es uno de los riesgos más incómodos de trabajar con IA en research: devuelve algo prolijo mucho antes de que el análisis realmente esté maduro. Devuelve una narrativa coherente, un resumen limpio, una estructura que parece razonable. Y esa prolijidad engaña: hace sentir que ya entendiste algo que en realidad recién estás empezando a mirar.

El sesgo, entonces, no viene sólo de que el sistema lea material parcial. Viene de la tentación de empezar a decidir con base en una explicación que todavía no se ganó ese lugar.

Si esa explicación empieza a orientar la siguiente entrevista, a moldear la lectura del equipo o, peor todavía, a alimentar recomendaciones de producto, priorización o definiciones estratégicas, el problema deja de ser metodológico en abstracto. Se vuelve un problema de decisión. El equipo empieza a moverse con seguridad sobre una base todavía débil.

Por eso, si yo tuviera que montar este flujo en un equipo real, no intentaría resolverlo con una respuesta binaria. No diría “espera hasta el final” ni diría “analiza todo en continuo y listo”. Haría algo más incómodo y más útil: diseñaría el proceso para que los outputs parciales sigan siendo parciales.

Guardaría las transcripciones en un mismo repositorio. Haría pasar cada entrevista por una lectura asistida que pueda volver siempre al texto original. Marcaría ese output como lectura preliminar, no como síntesis del research. Dejaría aparte las notas del analista, justamente para no confundir la materia prima con la interpretación. Y recién cuando hubiese suficiente masa crítica pediría una lectura transversal con grounding explícito en el corpus completo.

No porque la IA no pueda producir antes un texto convincente, sino justamente porque puede.

Ése es el punto más peligroso de todo este asunto: la herramienta puede sonar concluyente antes de que tú debieras querer una conclusión.

Y cuando analizar se vuelve más barato, interpretar bien se vuelve más importante, no menos.

Tal vez por eso la señal más útil no sea preguntarte si el sistema ya te entregó algo claro, sino qué efecto produce ese output en tu forma de trabajar. Si te ayuda a mirar mejor el material, probablemente va bien. Si te da ganas de dejar de mirar el material, probablemente ya empezó a empobrecer el research.

Lo interesante de esta pregunta no es sólo cómo usar IA sin sesgar hallazgos. Es que obliga a distinguir algo más incómodo: en muchos equipos el problema nunca fue la velocidad para procesar entrevistas. El problema era que nadie había diseñado con suficiente rigor el momento en que una observación pasa a tener peso de hallazgo. La IA no crea esa fragilidad. La vuelve visible. Y cuando la vuelve visible, también la vuelve más cara.

Recibe un email con cada artículo nuevo.