Datos estructurados vs no estructurados: qué son y en qué se diferencian

El dolor real detrás de esta distinción

Una empresa de retail en Perú, con cerca de cuarenta tiendas, tiene un sistema de punto de venta impecable. Cada venta, cada SKU, cada descuento queda registrado en una tabla, y el equipo comercial arma su reporte semanal en minutos. Pero esa misma empresa recibe miles de mensajes de WhatsApp con quejas de clientes, transcripciones de llamadas al call center, fotos de anaqueles vacíos que envían los supervisores de tienda y correos de proveedores negociando plazos de entrega. Nadie lee eso de forma sistemática. Se archiva, se acumula, y cuando algo se rompe (una queja recurrente, un proveedor que empieza a fallar) el equipo se entera meses después, por el reclamo del cliente, no por la señal que ya estaba en sus propios archivos.

Esto se repite en manufactura, en servicios financieros, en salud. La empresa mide lo que su ERP o su CRM le dejan medir, porque esos sistemas obligan a llenar campos en filas y columnas. Todo lo demás (el contrato firmado, la llamada de reclamo, el acta de auditoría escaneada) queda fuera del tablero de control, aunque ahí está buena parte de la explicación de por qué las cosas fallan. El comité de gerencia discute con datos incompletos y lo llama decisión basada en datos, cuando en realidad ignora la mayoría de lo que la empresa sabe.

El error de fondo no es de tecnología, es de alcance: se ordenó y se digitalizó lo fácil de ordenar, y se dejó fuera lo difícil. Durante años eso fue razonable, porque no existía una manera económica de leer miles de correos o transcribir miles de llamadas. Ese punto de partida cambió, y por eso vale la pena entender bien la diferencia entre estos dos tipos de información antes de decidir qué hacer con cada una.

Qué son, en criterio de negocio

Datos estructurados y datos no estructurados no son una categoría técnica de un área de sistemas: es la forma más simple de describir qué tan fácil es para una máquina, y para una persona, encontrar un valor exacto dentro de la información que la empresa guarda.

Piénsalo por el lado del negocio. Si la pregunta es cuánto facturamos con el cliente X el mes pasado, la respuesta vive en una tabla y cualquier sistema la saca en segundos. Si la pregunta es por qué el cliente X se queja tanto, la respuesta probablemente está repartida entre diez correos, tres llamadas grabadas y un contrato en PDF, y ningún reporte tradicional la va a mostrar sola. Esa es la brecha real entre los dos tipos de datos: no es que uno sea dato bueno y el otro dato malo, es que históricamente solo supimos explotar el primero a gran escala.

La proporción importa, y suele sorprender cuando alguien la calcula por primera vez. En la mayoría de empresas, lo estructurado (ventas, inventario, transacciones, lecturas de un sensor) es una fracción menor de toda la información que se genera. El grueso es correo, documentos, conversaciones, audio, imágenes: datos no estructurados que se acumulan todos los días en cualquier operación, sin que nadie los pida en un formato de fila y columna.

Cómo se ve esto en una misma empresa

Para que la diferencia deje de ser abstracta, conviene mirarla dentro de una misma empresa, no como dos mundos separados que no se cruzan nunca. En cualquier operación de tamaño medio conviven, del lado estructurado:

• El ERP con órdenes de compra, fechas de entrega y montos por proveedor.
• El CRM con el historial de oportunidades, montos cotizados y etapas del embudo comercial.
• El sistema de planta con lecturas de sensores de temperatura o presión, una fila por medición.
• La planilla de recursos humanos con sueldos, cargos y fechas de ingreso.

Y en la misma empresa, sin que nadie lo etiquete formalmente como dato, conviven también:

• Los correos de negociación con proveedores, con condiciones que nunca llegan a escribirse en el ERP.
• Las grabaciones de llamadas del call center, con el motivo real detrás de cada reclamo.
• Los contratos y adendas firmados en PDF, con cláusulas que nadie vuelve a leer hasta que hay un conflicto.
• Las fotos que un supervisor de tienda o de planta envía por WhatsApp para reportar una incidencia.
• Los tickets de soporte escritos en lenguaje libre, sin un campo que capture el matiz real del problema.

La empresa suele creer que solo tiene el primer grupo, el que le muestra el reporte mensual. En realidad tiene ambos, y el segundo grupo, el no estructurado, casi siempre pesa más en volumen, aunque pese menos en la mesa donde se toman las decisiones importantes.

El semiestructurado: ni tabla limpia ni texto libre

Entre los dos extremos hay una franja intermedia que confunde, porque no es ni tabla limpia ni texto libre: el dato semiestructurado. No tiene filas y columnas fijas, pero sí trae etiquetas o una organización interna que un sistema puede aprovechar sin demasiado esfuerzo adicional.

El ejemplo más común dentro de una empresa es el archivo JSON que intercambian dos sistemas, o el registro (log) que genera una aplicación cada vez que un usuario hace algo dentro de ella. Ninguno de los dos calza en una tabla de base de datos tradicional, pero ambos traen una estructura interna reconocible: un campo dentro de ese archivo siempre está en el mismo lugar, una fecha siempre llega con el mismo formato. Un correo electrónico normal, en cambio, no trae esa promesa: cada persona lo redacta distinto, con su propio orden y su propio tono.

Para efectos prácticos de negocio no hace falta memorizar la etiqueta técnica. Lo que importa es esto: lo semiestructurado suele ser más barato de aprovechar que lo puramente no estructurado, porque ya trae parte del orden puesto de fábrica. Si tu empresa genera este tipo de datos, por ejemplo registros de un sistema web o intercambios entre aplicaciones, esa es fruta más baja que morder antes de meterse con el correo o la llamada grabada.

Por qué esta distinción volvió a importar

El motivo por el que esta distinción volvió a importar en los últimos años es simple: hasta hace poco, una empresa solo podía explotar de forma masiva sus datos estructurados. El reporte, el tablero de control, el modelo estadístico, todo eso corría sobre tablas. Lo no estructurado se guardaba por si acaso, pero nadie tenía una forma económica de leerlo a escala.

La IA generativa cambia ese punto exacto. Por primera vez existe una tecnología capaz de leer miles de correos, contratos, transcripciones de llamadas o tickets de soporte y extraer de ahí una respuesta o un patrón, sin que alguien tenga que digitar cada dato en una tabla a mano. Eso explica buena parte del interés reciente por la IA dentro de las empresas: no es que de pronto los datos estructurados dejen de importar, es que se volvió posible explotar también el otro tipo de información, el que llevaba años acumulado sin uso ni revisión.

Técnicamente, esto funciona convirtiendo el texto, el audio transcrito o la imagen en una representación numérica que se puede comparar y buscar, algo que la guía sobre embeddings de este mismo Centro explica con más detalle. Para el negocio, lo relevante no es el mecanismo sino la consecuencia: información que antes solo servía de archivo histórico ahora puede responder preguntas concretas, y eso obliga a revisar qué se está dejando fuera del radar de decisión.

Qué necesita la empresa antes de lanzarse

Antes de lanzarse a usar IA sobre los datos no estructurados, hay un orden que conviene respetar, porque saltárselo es la forma más común de gastar presupuesto sin ver un resultado.

• Saber qué se guarda y dónde: la mayoría de empresas no tiene un inventario real de sus correos, contratos y grabaciones, solo intuye que existen.
• Un lugar donde centralizar ese volumen sin duplicarlo ni perderlo, sea un data lake para lo crudo o un data warehouse para lo ya trabajado.
• Reglas claras de quién puede ver qué, porque el dato no estructurado suele traer más información sensible (nombres, montos, diagnósticos) que una tabla limpia.
• Un mínimo de calidad de datos: si los correos están duplicados, mal archivados o incompletos, la IA hereda ese desorden, no lo arregla.
• Un proceso de negocio dueño de esa información, no solo un proyecto de tecnología: alguien que realmente use la respuesta que sale de ahí.

Sin esa base, el proyecto se queda en demostración y nunca llega a producción. La guía sobre ingeniería de datos y la de calidad de datos de este mismo Centro de Conocimiento entran más a fondo en cómo construir esa base; acá basta con dejar claro que explotar datos no estructurados no empieza en el modelo de IA, empieza en el orden previo que la empresa le pone a su información.

Mi criterio

Cuándo invertir en esto y cuándo no

No toda empresa necesita empezar a explotar sus datos no estructurados ya mismo. Depende de dónde está realmente el dolor y de si existe una base mínima para sostener el esfuerzo.

Señales de que ya conviene invertir en leer los datos no estructurados

• El equipo repite la misma pregunta de negocio y la respuesta no está en ningún reporte, solo dispersa en correos o llamadas.
• Hay un volumen alto de documentos, tickets o conversaciones que hoy solo alguien lee cuando hay tiempo, o directamente no se leen.
• Existe un problema recurrente (reclamos, fallas de proveedor, rotación) y nadie puede explicar la causa con los datos estructurados que ya tiene.
• El equipo de datos ya ordenó lo estructurado, tiene un data warehouse o algo parecido, y busca el siguiente salto de valor.
• Hay una persona o área dueña de la decisión que se tomaría con esa información, no solo curiosidad técnica de un área de sistemas.

Señales de que todavía no es prioridad

• La empresa ni siquiera tiene ordenados sus datos estructurados básicos: ventas, inventario, clientes.
• Nadie puede nombrar la pregunta de negocio concreta que se respondería leyendo esos correos o documentos.
• No hay una política mínima de quién puede acceder a la información sensible que traen esos documentos.
• El volumen de datos no estructurados es bajo o poco relevante para el problema que se quiere resolver primero.
• El interés viene de que la competencia ya usa IA, no de un dolor identificado dentro de la propia operación.

Cierre

El orden no cambia por el tipo de dato: primero el dolor, la pregunta que la empresa no puede responder; después el proceso, quién decide con esa respuesta y cuándo; después el dato, estructurado, no estructurado o los dos, según dónde viva la respuesta; y al final la herramienta que lee ese dato. Cuando el orden se invierte, y se empieza comprando una plataforma para procesar documentos con IA, el resultado casi siempre es una demostración cara que nadie vuelve a abrir después de la primera semana.

La diferencia entre datos estructurados y no estructurados dejó de ser una curiosidad técnica el día en que apareció una tecnología capaz de leer el segundo grupo a escala. Pero esa capacidad nueva no reemplaza la disciplina vieja: hace falta saber qué se guarda, para qué se necesita y quién es dueño de la decisión, antes de apuntarle un modelo encima. La empresa que entienda esto primero le va a sacar más valor a lo que ya tiene guardado que la que corra a comprar la herramienta de moda.