«No tenemos datos suficientes»: por qué casi siempre sí

Introducción

Es la objeción más repetida en la primera conversación, y casi siempre llega con un tono de disculpa: nosotros no tenemos datos suficientes para esto, somos una empresa pequeña, no tenemos un histórico ordenado, lo nuestro está todo en carpetas y en la cabeza de tres personas.

La objeción es razonable y, en su forma habitual, está mal planteada. No porque la empresa se equivoque sobre lo que tiene, sino porque la palabra "datos" se está usando para tres cosas distintas, y de esas tres solo una es difícil de conseguir. Resulta que es la que casi nunca hace falta.

Este artículo separa las tres, explica cuál se necesita para qué, y señala dónde suele estar lo que una empresa cree no tener.

Tres cosas distintas que llamamos datos

Cuando alguien dice que necesita datos para un proyecto de inteligencia artificial puede estar refiriéndose a tres necesidades que no se parecen en nada.

Datos para entrenar. Miles de ejemplos con su resultado correcto, usados para construir un modelo desde cero o para especializarlo. Es lo que la gente imagina cuando oye la palabra, y es lo caro.

Datos para contextualizar. La documentación, los procedimientos, el histórico y las particularidades de la empresa, que el sistema consulta en el momento de responder. No sirven para entrenar nada: sirven para que el sistema sepa cómo se hacen las cosas aquí.

Datos para evaluar. Un conjunto pequeño de casos reales con la respuesta correcta anotada, que permite comprobar si el sistema funciona. Son pocos y son imprescindibles.

La confusión entre la primera y las otras dos es la que produce la objeción, y también la que lleva a algunos proyectos a empezar por un ejercicio de recopilación masiva de datos que no hacía ninguna falta.

Entrenar: la parte que casi nunca se necesita

Aquí está el malentendido de fondo, y tiene una explicación histórica sencilla.

Durante años, aplicar inteligencia artificial a un problema significaba literalmente entrenar un modelo para ese problema. Si una empresa quería clasificar sus facturas, había que reunir miles de facturas etiquetadas y entrenar con ellas. Sin ese material no había proyecto, y de ahí viene, con razón, la idea de que esto es cosa de organizaciones con mucho histórico ordenado.

Lo que cambió esa situación fue la constatación de que un modelo suficientemente grande y entrenado de forma general puede resolver tareas nuevas a partir de unos pocos ejemplos incluidos en la propia petición, sin ningún reentrenamiento. El trabajo que estableció ese resultado lo evaluó sobre más de dos docenas de conjuntos de tareas de procesamiento de lenguaje y mostró que el modelo se adaptaba a problemas que no había visto durante su entrenamiento, guiándose únicamente por lo que se le explicaba en el momento (Brown et al., 2020).

La consecuencia práctica para una empresa pequeña es considerable: para la mayoría de las tareas que quiere automatizar, no hay nada que entrenar. Leer una factura, distinguir una reclamación de una consulta, extraer un vencimiento, resumir una llamada o redactar un borrador son tareas que el modelo ya sabe hacer al llegar. Lo que no sabe es cómo se hacen las cosas en esa empresa concreta, y eso no se resuelve entrenando sino explicando.

Sigue habiendo casos en que especializar un modelo compensa: volúmenes muy altos con una tarea muy repetitiva y acotada, o un vocabulario técnico muy particular. Pero es la excepción, llega después de haber comprobado que lo sencillo no basta, y desde luego no es el punto de partida.

Contextualizar: aquí sí, y es lo que ya tienes

Lo que sí determina si un sistema resulta útil es el acceso al conocimiento propio de la empresa: las condiciones de cada tipo de cliente, los criterios que se aplican, los procedimientos, las excepciones habituales, el histórico de casos parecidos.

Esto no requiere estar ordenado en una base de datos. Requiere estar accesible y ser correcto. Un conjunto de documentos, unos manuales internos, el archivo de correos de un buzón, las condiciones contractuales: todo eso es material aprovechable tal como está. La forma de usarlo se explica en el artículo sobre cómo funciona una base documental consultable, y lo que hay que hacer para dejarlo utilizable, en el de cómo preparar los datos.

El punto importante es que casi ninguna empresa carece de este material. Lo que suele ocurrir es que está repartido, que parte vive en la cabeza de alguien y que nadie lo ha escrito nunca. Y esto último merece un matiz, porque es donde aparece el trabajo real: si un criterio no está escrito en ningún sitio, no es que falten datos, es que falta una decisión. Escribirla cuesta una tarde y suele mejorar el proceso aunque el proyecto no siga adelante.

Evaluar: pocos, pero imprescindibles

La tercera necesidad es la que menos volumen exige y la única que no tiene sustituto.

Para saber si un sistema funciona hacen falta casos reales con la respuesta correcta anotada. No miles: entre cincuenta y doscientos, elegidos con criterio, incluyendo los raros y los que salieron mal. Es lo que convierte una discusión de impresiones en una comprobación, y es lo que permite después cambiar de modelo o de proveedor sabiendo si se gana o se pierde.

Este conjunto no se puede pedir prestado ni comprar hecho, porque su valor está precisamente en que refleja los casos de esa empresa. Y es, con diferencia, el activo más duradero de todo el proyecto: sobrevive a los modelos, a las herramientas y a los proveedores.

Si una empresa solo pudiera dedicar unas horas a preparar algo antes de empezar, debería dedicarlas a esto.

Dónde están los datos que crees que no tienes

Cuando una empresa afirma que no tiene datos, casi siempre significa que no tiene una base de datos. Son cosas distintas, y estos son los sitios donde suele estar lo que hace falta.

El correo. Es el archivo más completo que tiene la mayoría de las pymes. Contiene consultas reales, respuestas reales y el criterio aplicado en cada caso, que es exactamente lo que se necesita para explicar cómo se trabaja.

Los documentos ya emitidos. Presupuestos, informes, contratos, respuestas tipo. Muestran el formato, el tono y los criterios en uso mejor que cualquier manual.

Las hojas de cálculo departamentales. Suelen contener el histórico real y las reglas de negocio, incrustadas en fórmulas que nadie ha documentado.

El sistema de gestión. Aunque no permita extraer informes cómodamente, los datos están dentro. Cuando el problema es de acceso y no de existencia, hay salidas, y las tratamos en cómo automatizar cuando el ERP no tiene API.

Las personas. El criterio de quien lleva quince años haciendo esa tarea es un dato, aunque no esté escrito. Una conversación de una hora bien conducida produce material utilizable.

Cuándo de verdad no hay suficiente

Conviene decir también en qué casos la objeción es correcta, porque los hay y fingir lo contrario sería vender humo.

Cuando la tarea depende de un histórico que no existe. Predecir qué clientes van a marcharse requiere saber qué clientes se marcharon y qué hacían antes. Si nadie lo registró, no hay forma de suplirlo, y el proyecto correcto es empezar a registrarlo.

Cuando el criterio no es estable. Si tres personas resuelven el mismo caso de tres maneras distintas y ninguna es incorrecta, no hay una respuesta correcta que enseñar. Antes de automatizar hay que decidir cuál es.

Cuando el volumen no justifica nada. Si una tarea ocurre cuatro veces al mes, probablemente no merece un proyecto por bien que salga.

Cuando lo que hay está mal. Un histórico con errores sistemáticos es peor que no tener nada, porque enseña a repetir el error con más rapidez.

La trampa de los datos sintéticos

Ante la falta de material, aparece de vez en cuando la propuesta de generar datos artificiales con un modelo para cubrir el hueco. Es una técnica legítima en contextos concretos y conviene conocer su riesgo antes de aceptarla.

Un trabajo publicado en Nature mostró que entrenar modelos de forma indiscriminada con contenido generado por otros modelos produce defectos irreversibles, y describió con precisión el mecanismo: lo primero que se pierde son las colas de la distribución original, es decir, los casos poco frecuentes (Shumailov et al., 2024).

Merece la pena detenerse en esa frase, porque es exactamente lo contrario de lo que una empresa necesita. Los casos poco frecuentes son los que consumen el tiempo de las personas y los que motivan el proyecto. Un material sintético tenderá a reproducir bien lo típico, que es justo lo que ya funcionaba, y a borrar lo excepcional, que es donde estaba el problema.

Como material de apoyo para completar variaciones de algo que ya se tiene, puede servir. Como sustituto de los casos reales para evaluar, no.

Errores frecuentes

Aplazar el proyecto hasta tener los datos ordenados. El orden llega antes trabajando sobre un proceso concreto que emprendiendo una limpieza general que nunca termina.

Empezar por un proyecto de datos. Recopilar, migrar y estructurarlo todo antes de saber para qué produce meses de trabajo sin resultado y suele acabar recopilando lo que no era.

Confundir cantidad con utilidad. Doscientos casos bien elegidos, con sus rarezas, valen más que veinte mil registros homogéneos del caso fácil.

Usar los mismos casos para mejorar y para juzgar. Si el sistema se ajusta contra el conjunto de evaluación, la nota deja de medir nada. Conviene reservar una parte intacta.

Descartar el conocimiento no escrito. La mayor parte del criterio de una pyme está sin documentar, y eso lo convierte en trabajo pendiente, no en material inexistente.

Conclusión

La frase "no tenemos datos suficientes" suele significar "no tenemos un histórico estructurado y etiquetado", que era el requisito de una generación tecnológica anterior y hoy solo hace falta en casos concretos.

Lo que se necesita para empezar es bastante más modesto: la documentación que ya existe aunque esté desordenada, los criterios que se aplican aunque haya que escribirlos por primera vez, y unas decenas de casos reales con la respuesta correcta anotada.

Eso lo tiene prácticamente cualquier empresa en funcionamiento, porque es lo que produce simplemente por trabajar. Y si hay que empezar por algún sitio, el orden más rentable es el inverso al que sugiere la intuición: primero los casos de evaluación, después el contexto, y el entrenamiento probablemente nunca.

Referencias

Brown, T. B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J., Dhariwal, P., Neelakantan, A., Shyam, P., Sastry, G., Askell, A., Agarwal, S., Herbert-Voss, A., Krueger, G., Henighan, T., Child, R., Ramesh, A., Ziegler, D. M., Wu, J., Winter, C., … Amodei, D. (2020). Language models are few-shot learners. En Advances in Neural Information Processing Systems 33 (pp. 1877-1901). https://arxiv.org/abs/2005.14165

Shumailov, I., Shumaylov, Z., Zhao, Y., Papernot, N., Anderson, R., & Gal, Y. (2024). AI models collapse when trained on recursively generated data. Nature, 631, 755-759. https://doi.org/10.1038/s41586-024-07566-y