El cuello de botella que nadie nombra en los equipos de research

Vamos a hacer un ejercicio de visualización de un salario de trabajo. Llevas semanas en campo. Has hecho entrevistas, has analizado patrones y has triangulado fuentes. El trabajo de investigación, en sentido estricto, ha terminado. Y entonces empieza la otra parte: una que normalmente no aparece en los planes de proyecto, que nadie mide habitualmente y que consume más tiempo del que cualquier responsable de research estaría dispuesto a admitir en voz alta.

Reducir el tiempo entre la conclusión de una investigación con usuarios y la entrega del readout es uno de los retos más subestimados en equipos de research corporativos. Y la inteligencia artificial generativa, bien aplicada, es hoy la palanca más potente que tenemos sobre la mesa o en la caja de herramientas para atacarlo.

Uno, que va acumulando experiencia, lo ha visto repetirse en clientes grandes. No en equipos sin recursos ni criterio, sino en equipos maduros, con researchers experimentados que trabajan con procesos definidos. El problema no está tanto en saber investigar sino en lo que sucede después.

Por qué el tiempo de síntesis importa más de lo que parece

Hay una creencia extendida de que el valor del research reside sobre todo en el trabajo de campo: el guión de las entrevistas, la selección de los participantes, el diseño del estímulo en su caso, o la ejecución de los tests con usuarios. Todo eso es importante, muy importante, y hacerlo bien marca la diferencia entre datos y evidencia. Pero el valor no se materializa hasta que los hallazgos llegan a quien tiene que tomar decisiones.

Ahí está el problema. Entre el cierre del trabajo de campo y la entrega del informe puede pasar una semana, diez días, dos semanas. En proyectos con múltiples estudios en paralelo, ese retraso se convierte en un problema estructural. Los hallazgos envejecen. El contexto cambia. Las decisiones que podrían haberse tomado con datos se toman sin ellos, porque los datos llegan tarde.

Nadie lo llama cuello de botella porque, de alguna manera, forma parte del paisaje. Es algo así como un coste asumido, una fricción invisible que se da por inevitable.

Aunque hay algo que hay que decir cuanto antes: no lo es.

Dónde se pierde el tiempo, exactamente

Cuando mapeo el proceso de trabajo con equipos de research, el desglose suele sorprender. La transcripción de las sesiones, la organización del material bruto, la estructuración de notas en una plantilla común, la primera pasada de codificación o la elaboración del primer borrador del informe… Cada tarea por separado parece razonable. Sin embargo la vista en conjunto, representa una proporción desproporcionada del tiempo total del proyecto. Y ahí duele un poco más, especialmente con la escala.

En equipos que trabajan con restricciones de compliance, la situación se complica aún más. Quien ha trabajado con según qué clientes, sabe que muchas organizaciones no permiten el uso de herramientas externas de diversa naturaleza y propósito, entre ellas las de transcripción automática. El procesamiento de datos de usuarios queda restringido a herramientas aprobadas internamente, que a menudo no están optimizadas para este tipo de trabajo. El resultado al final es un investigador senior dedicando horas a tareas que no requieren su nivel de expertise.

Ese es el diagnóstico real: no es que los researchers sean lentos. Es que están haciendo cosas que no deberían estar haciendo ellos.

Qué puede hacer la IA generativa aquí, y qué no

Cuando hablo de inteligencia artificial generativa aplicada a ResearchOps, no estoy hablando de sustituir el criterio del investigador. Eso sería un error de concepto, y además no funciona. Los investigadores con experiencia tienen una sensibilidad metodológica que los modelos de lenguaje no replican: saben cuándo un dato es ruido, cuándo una respuesta está mediada por el sesgo de deseabilidad social o cuándo el patrón que parece sobresaliente es en realidad un artefacto del diseño del estudio.

De lo que estoy hablando es de otra cosa: usar la IA generativa para comprimir el tiempo que transcurre entre tener los datos y tener un primer borrador estructurado sobre el que trabajar.

Esto implica cosas concretas. Estoy hablando, por ejemplo de transcripción automática de sesiones dentro del entorno aprobado por la organización. Estoy hablando de poder tener una síntesis preliminar de notas de campo siguiendo una estructura predefinida. Por supuesto, también me estoy refiriendo a la detección de patrones recurrentes en un corpus de entrevistas. Cabe mencionar que también meto en este saco la generación de un primer esqueleto del informe a partir de los hallazgos codificados. Ninguna de estas tareas requiere necesaria e imperiosamente del juicio del investigador. Todas ellas consumen su tiempo.

La clave está en identificar de manera muy precisa qué parte del proceso de síntesis es mecánica y qué parte es analítica. La IA puede asumir la primera. La segunda sigue siendo territorio del investigador.

El error que cometen los equipos al intentarlo sin método

He visto dos formas de fracasar en esto. La primera es el entusiasmo sin estructura: alguien del equipo empieza a usar ChatGPT para resumir entrevistas, los resultados son inconsistentes, aparecen alucinaciones menores que nadie detecta porque nadie ha definido cómo verificarlas, y al cabo de tres meses el experimento se abandona con la conclusión de que la IA no es fiable para research. La segunda es la parálisis por perfección: el equipo espera a tener una solución corporativa que esté aprobada, integrada, validada y formada. Lo que pasa es que nunca termina de llegar. En ambos casos, estamos ante un callejón sin salida.

Lo que funciona es una tercera vía: un piloto acotado y controlado, con un proceso bien definido, sobre un estudio real, con una línea base medida antes de empezar. Eso requiere tres cosas previas que rara vez se hacen:

• Mapear el proceso end-to-end con suficiente detalle para saber dónde se pierde el tiempo de verdad.
• Establecer una métrica de tiempo de reporte que sea comparable antes y después.
• Acordar con el equipo de legal o de compliance qué herramientas pueden utilizarse y en qué condiciones.

Sin ese trabajo previo, cualquier intervención de IA en el proceso de research es un experimento sin control y un cierto tufillo de brindis al sol. Con él, es un proyecto con resultados medibles.

La medición como argumento interno

Hay una dimensión de esto que no es técnica sino que es política, en el sentido organizativo de la palabra. Los responsables de research en grandes empresas necesitan justificar la inversión en herramientas y procesos ante direcciones que no siempre entienden el trabajo de investigación. Decir que la IA nos va a ahorrar tiempo no es suficiente. Hace falta un número. Nos puede gustar más o menos, pero es así. Al menos es así hasta la fecha.

Cuando establecemos una línea base de tiempo de reporte antes de sugerir e introducir cambios, y luego medimos el mismo indicador después del piloto, tenemos algo mucho más valioso que una intuición: tenemos un argumento. Si el tiempo medio entre cierre de campo y entrega de readout baja de doce días a siete, eso es una conversación diferente con tu director de producto o con el equipo de tecnología.

La métrica no es el objetivo. Es el lenguaje que permite que el objetivo sea tomado en serio.

Por dónde empezar si lideras un equipo de research en una organización grande

Mi recomendación práctica, basada en lo que he visto funcionar, es la siguiente: empieza por medir antes de actuar. Dedica una o dos semanas a mapear el proceso real, no el proceso teórico que está, en el mejor de los casos, en la wiki. Habla con dos o tres researchers sobre cómo distribuyen su tiempo entre campo, síntesis y entrega. Identifica las tareas que más tiempo consumen y que menos criterio experto requieren. Ese diagnóstico, por sí sólo, ya tiene valor.

A partir de ahí:

• Selecciona una o dos etapas del proceso donde la IA generativa pueda intervenir sin comprometer la integridad metodológica.
• Diseña un flujo concreto, con prompts estructurados y verificación humana de los outputs.
• Pruébalo en un estudio real.
• Mide.

En realidad, no necesitamos una gran transformación que le dé la vuelta a todo. Necesitamos una prueba de concepto bien ejecutada que produzca datos suficientes para decidir si escalar.

Foto de portada de Jonathan Borba en Unsplash.