Imagina que tienes una encuesta de producto que necesitas para aprender sobre el rendimiento de una nueva funcionalidad. Hay una pregunta de satisfacción, una respuesta abierta donde las personas explican por qué pusieron esa nota y algunas columnas de contexto: segmento, país, plan, antigüedad como cliente.
Subes el CSV a una herramienta de IA como ChatGPT, Gemini o Claude y haces una pregunta bastante razonable:
¿Cuáles son los principales temas que aparecen en estas respuestas?
En unos segundos aparece una respuesta ordenada. Temas principales, ejemplos, quizá algunas recomendaciones. La síntesis suena bien. Tiene categorías limpias. Usa un lenguaje profesional. Incluso puede parecer más clara que esa primera lectura humana, un poco desprolija, donde todavía estás tratando de entender qué hay en el material.
El problema es que todavía no sabemos si eso fue un análisis.
Sabemos que recibimos una respuesta. Lo que no siempre sabemos es qué ocurrió antes de esa respuesta.
Ahí quedan varias cosas fuera de vista: si el sistema leyó todo el archivo, si calculó frecuencias reales o sólo estimó recurrencias, si trabajó con respuestas completas o con fragmentos, si las categorías salieron del material o de una clasificación demasiado rápida. También queda una duda más importante: qué ejemplos sostienen cada tema y qué parte del material quedó fuera.
Y cuando usamos IA para investigar, esa diferencia importa, porque una respuesta convincente no es lo mismo que un análisis confiable.
El problema no es usar IA para analizar
No saco de esto la conclusión de que la IA debería quedar fuera de los procesos de investigación. Sería absurdo, porque puede ayudar mucho y hasta permitir que ocurra una investigación que de otro modo sería inviable.
En una encuesta grande, la IA puede acelerar una parte real del trabajo: leer respuestas abiertas, ordenar comentarios dispersos, sugerir categorías iniciales, comparar segmentos o devolver preguntas mejores para volver al material. Todo eso puede ser valioso, sobre todo cuando el volumen hace inviable una primera revisión manual completa.
La salida no es volver al análisis manual por principio. Tampoco es aceptar cualquier síntesis porque suena razonable.
Lo que conviene revisar es algo más básico: seguimos tratando el análisis como si fuera una sola tarea.
Cuando alguien dice “analiza esta encuesta”, en realidad está mezclando varias operaciones distintas. Algunas son computacionales. Otras son interpretativas. Otras son metodológicas. Otras son decisiones de producto.
Limpiar una columna, contar menciones, agrupar respuestas parecidas, interpretar una tensión y decidir qué debería hacer el equipo pertenecen al mismo proceso, pero no tienen el mismo peso. Algunas operaciones organizan el material. Otras empiezan a producir significado. Otras ya empujan decisiones.
Cuando todo eso queda dentro de una única respuesta generada por el modelo, el proceso parece más simple, pero también se vuelve más difícil de discutir.
Contar no es interpretar
Un dataset mixto suele pedir distintos tipos de trabajo.
Si hay preguntas cerradas, tiene sentido calcular frecuencias, porcentajes, cruces, distribución por segmento, diferencias entre grupos. Ahí el modelo de lenguaje no debería inventar aritmética (que no se le da bien). Lo razonable es usar una herramienta, un script o una operación determinística que deje claro qué se contó y sobre qué base.
Si hay respuestas abiertas, entra otra capa. Ya no se trata sólo de contar. Hay lenguaje, matices, contradicciones, frustraciones, expectativas y contexto. Ahí un modelo puede ser útil para proponer agrupaciones semánticas, detectar temas posibles o mostrar tensiones que conviene revisar.
En el análisis de entrevistas con IA, esta separación es especialmente importante: el modelo puede ayudar a ordenar señales, pero no debería reemplazar la validación del hallazgo ni borrar el criterio de research.
Pero incluso ahí hay que separar niveles.
Una frecuencia no es un patrón. Un patrón no es un hallazgo. Un hallazgo no es una recomendación y tampoco un insight.
La frecuencia dice que algo aparece muchas veces. El patrón sugiere una relación o recurrencia con sentido. El hallazgo interpreta por qué eso importa dentro del problema investigado. La recomendación traduce esa interpretación en una decisión posible.
Cuando esas capas se mezclan, la IA puede devolver una narrativa muy prolija. Pero esa prolijidad puede ocultar una fragilidad: no sabemos qué parte está basada en datos, qué parte es interpretación y qué parte es inferencia excesiva.
La trazabilidad se diseña antes del resultado
Muchas veces hablamos de trazabilidad como si fuera algo que se agrega al final: citas, ejemplos, referencias, un disclaimer.
Pero en investigación con IA, la trazabilidad no debería ser maquillaje posterior. Debería estar diseñada en el flujo.
Un flujo más confiable no empieza con “dame los insights principales”. Empieza con preguntas menos cómodas:
- ¿El sistema leyó todo el archivo? Tiene 200 filas, ¿las recibiste todas?
- ¿Qué columnas está usando?
- ¿Qué operaciones deben ser cálculo y no interpretación?
- ¿Qué respuestas sostienen cada categoría?
- ¿Qué ejemplos contradicen la categoría propuesta?
- ¿Qué agrupaciones fueron sugeridas por el modelo y cuáles fueron validadas por una persona?
- ¿Qué conclusiones tienen evidencia suficiente y cuáles son hipótesis?
Estas preguntas no vuelven el trabajo menos creativo. Lo vuelven más responsable y, sobre todo, más conversable dentro de un equipo.
El criterio no compite con la IA. El criterio decide qué parte del proceso puede delegarse, bajo qué condiciones y con qué forma de verificación.
La caja negra no siempre avisa que falló
Hay además una complicación técnica que conviene mirar sin convertirla en el centro de la pieza.
A veces una IA puede trabajar con un documento parcial. Un archivo grande puede quedar truncado por límites de contexto. Una herramienta puede leer una muestra y no el dataset completo. Un modelo puede producir un conteo que suena plausible aunque no haya ejecutado ningún cálculo real. Una síntesis puede estar basada en una parte del material y aun así sonar completa.
Ojo que ese tipo de corte en un archivo subido a una IA ocurre y sin aviso. Y las consecuencias pueden ser serias justamente porque el output no siempre revela el problema.
La respuesta puede tener estructura, seguridad y buen tono. Puede usar palabras como “principalmente”, “la mayoría”, “aparece con frecuencia” o “los usuarios tienden a”. Pero si no sabemos qué datos fueron efectivamente procesados, esas frases tienen menos peso del que aparentan.
Este no es un argumento contra usar modelos, sino un argumento contra usar modelos como si fueran todo el proceso. Ya lo he planteado desde producto: un producto con IA no es un modelo con una interfaz encima.
Un flujo completo puede combinar capacidades distintas: el modelo interpreta lenguaje, una herramienta calcula, un script verifica cobertura y una persona decide qué cuenta como evidencia. Pero esa combinación no aparece sola; alguien tiene que diseñarla.
El trabajo profesional se mueve hacia el flujo
Durante mucho tiempo, usar IA en investigación se presentó como una cuestión de prompts. Si el resultado no era bueno, había que pedir mejor, dar más contexto o formular una instrucción más precisa.
Eso sigue importando. Pero para cierto tipo de trabajo se queda corto.
Cuando el trabajo se vuelve recurrente, sensible o conectado con decisiones de producto, el problema deja de ser sólo cómo pedir. Empieza a ser cómo diseñar el proceso.
En ese punto hay que decidir qué parte del trabajo será cálculo, cuál será interpretación, qué necesita validación humana, qué conviene conservar como evidencia y qué output todavía debe tratarse como señal preliminar antes de convertirse en hallazgo.
Ahí tiene sentido hablar de agentes, skills y recursos persistentes. No como moda técnica, ni como una capa de automatización por encima de cualquier cosa, sino como una forma de encapsular criterio.
Un skill puede definir pasos, como por ejemplo la verificación de un proceso. En ciertas herramientas, un agente puede operar sobre archivos y usar herramientas externas. Un flujo puede separar tareas que antes quedaban mezcladas en una conversación. Un recurso persistente puede evitar que el criterio dependa de recordar el prompt correcto cada vez.
Pero la idea de fondo no es “usa agentes”.
La idea de fondo es más simple y más exigente: si el análisis importa, el proceso que lo produce también importa.
Investigar con IA exige más criterio, no menos
La promesa cómoda de la IA es que puedes subir un archivo y recibir una respuesta.
La promesa profesional debería ser otra: puedes diseñar un flujo donde cada parte del análisis tenga un peso más claro.
En un flujo mejor diseñado, el cálculo no se disfraza de interpretación, la evidencia puede revisarse, las limitaciones aparecen antes de la recomendación y las decisiones no salen de una síntesis elegante, sino de una cadena que el equipo puede discutir.
Eso no hace que investigar con IA sea menos útil. Al contrario.
Lo vuelve más confiable. También vuelve más visible dónde todavía no hay suficiente evidencia.
Cuando producir análisis se vuelve más barato, justificar cómo se produjo se vuelve más importante. Ése me parece uno de los cambios profesionales más relevantes para diseño y research: el valor ya no está sólo en obtener una respuesta rápida, sino en saber diseñar las condiciones para que esa respuesta pueda convertirse en evidencia.
El punto, entonces, no es si la IA puede analizar una encuesta: es qué parte del análisis estás dispuesto a tratar como evidencia.
