El fin de la clasificación obligatoria

Estás delante de un formulario con un dropdown obligatorio: “Tipo de actividad”. Las opciones son: “Desarrollo, Soporte, Comercial, Gestión, Otros” Tu mañana ha sido una llamada con un cliente donde discutisteis un bug, explorasteis una posible ampliación del proyecto y acabasteis hablando de cómo va el sector, así que ninguna opción encaja y todas encajan a la vez.

A veces el problema es que nadie pensó bien ese dropdown. Alguien lo puso ahí porque “había que clasificar” y eligió cinco categorías que le parecieron razonables. Pero otras veces sí lo pensaron, y el problema es que la realidad simplemente no cabe en cinco opciones y un “Otros” (siempre hay un Otros que nadie lee). Llevamos décadas construyendo sistemas que asumen que sabemos, en el momento de registrar algo, qué preguntas vamos a necesitar responder después y que podemos comprimir un contexto complejo en una taxonomía simple sin perder nada importante. No es así.

El problema no es el dropdown

El dropdown es solo el síntoma. El problema de fondo es que estos sistemas te obligan a clasificar antes de actuar, a decidir qué tipo de cosa es algo antes de saber realmente qué es. Un ticket que abres pidiendo prioridad, componente afectado y tipo de incidencia antes de que hayas investigado qué pasa. Un CRM que te exige etapa del funnel y probabilidad de cierre cuando apenas has cruzado un email con el contacto; una herramienta de gestión que necesita saber a qué proyecto imputar una reunión donde se habló de tres proyectos distintos.

El denominador común es el mismo: te piden que tomes decisiones de clasificación en un momento en que no tienes la información necesaria para tomarlas bien, asumiendo además que esa clasificación va a ser útil para análisis que todavía no sabes cuáles serán.

De la sintaxis a la semántica

Durante décadas, la única forma que tenían los sistemas de “entender” información era a través de la estructura. Si querías que un programa encontrara algo tenías que decirle exactamente dónde buscar y cómo estaba formateado: campos en una base de datos, etiquetas XML, expresiones regulares (¡ay! ese Regex ;) para extraer patrones de texto. La comprensión era puramente sintáctica, el sistema no entendía qué significaba la información, solo dónde estaba y qué forma tenía.

Por eso necesitábamos los dropdowns. Por eso necesitábamos que la gente clasificara su trabajo en categorías predefinidas. Era la única manera de que el sistema pudiera hacer algo útil con esa información después, de contarla, agruparla o filtrarla. Sin estructura explícita no había análisis posible y estructurar después era carísimo (cuando no directamente imposible).

Eso ya no es así, ha cambiado. Los modelos de lenguaje tienen comprensión semántica: entienden qué significa un texto, no solo qué forma tiene. Pueden leer un email, una transcripción de reunión o unas notas sueltas y extraer información que antes requería o bien un humano dedicado o bien expresiones regulares imposibles de mantener. Lo que hace cinco años era ciencia ficción hoy es una llamada a una API.

El contexto es el nuevo oro

A los modelos de IA les pasa lo mismo que a nosotros: pueden ser muy listos pero sin contexto se pierden en generalidades. Pregúntale a un LLM qué hacer con un cliente difícil y te dará consejos genéricos de manual. Dale acceso al historial de conversaciones, a las propuestas anteriores, a las notas de las reuniones, y la respuesta será radicalmente distinta. No porque el modelo sea más inteligente, sino porque tiene con qué trabajar.

Y es que la vida es exactamente eso, un contexto continuo con datos semánticos que extraer y relacionar. Tu trabajo no son tareas discretas que encajan en categorías limpias, es un flujo de conversaciones, decisiones, documentos y reuniones donde todo está conectado con todo. El problema de los sistemas tradicionales es que te obligaban a romper ese flujo en trozos clasificables perdiendo por el camino las conexiones que le daban sentido.

Ahora podemos hacer algo distinto. Podemos capturar el contexto tal como es, sin forzarlo a encajar en estructuras predefinidas, y dejar que el sistema extraiga lo que necesite cuando lo necesite. No estructurar para poder buscar después, sino capturar para poder entender después.

Qué estructurar y qué no

Esto no significa que la estructura haya muerto, significa que cambia su función. Hay cosas que sigue teniendo sentido estructurar porque son objetivas, estables y de bajo coste cognitivo: quién participó en algo, cuándo ocurrió, a qué proyecto o cliente está vinculado, qué artefactos se generaron (un documento, una reunión, un commit). Son datos que puedes registrar sin tomar decisiones interpretativas, casi sin pensar. De hecho, gran parte de todos esos datos ya los puede extraer el sistema sin necesidad de preguntarte.

Lo que ya no tiene sentido forzar es todo lo demás: el porcentaje de dedicación a cada tarea, la clasificación fina del tipo de trabajo, el impacto en negocio “en el momento”. Esas son preguntas que solo se pueden responder bien a posteriori, con perspectiva, y cuya respuesta además cambia según para qué la necesites. Obligar a la gente a contestarlas en tiempo real es pedirles que inventen datos, y eso es exactamente lo que hacen.

La tesis es simple: la base de datos no debe explicar el trabajo, debe permitir reconstruirlo. Guarda el contexto, las conexiones, los artefactos. Deja la interpretación para después.

Los sistemas que vienen

Imagina un sistema que, en lugar de presentarte un formulario con veinte campos obligatorios, simplemente te deja trabajar. Guardas un documento, registras una reunión, escribes unas notas. El sistema captura el contexto: quién, cuándo, qué artefactos, y el contenido tal cual es.

Cuando necesita algo que no puede inferir, te pregunta, pero solo cuando tiene sentido hacerlo y solo lo que realmente necesita saber. No un interrogatorio preventivo por si acaso alguien algún día quiere un informe, sino una conversación puntual cuando surge la necesidad. Y cuando llega el momento del análisis, en lugar de limitarte a los informes que alguien predefinió hace tres años, puedes preguntar lo que necesites: cómo se distribuyó el esfuerzo del equipo el último trimestre, qué proyectos están consumiendo más tiempo del previsto, dónde hay patrones de problemas recurrentes. El sistema interpreta el contexto que ha ido acumulando y construye la respuesta sobre la marcha, adaptada a la pregunta concreta que estás haciendo ahora.

El dropdown no desaparece del todo, simplemente deja de ser obligatorio, deja de ser preventivo, deja de ser la única forma de crear información utilizable.

Llevamos décadas mintiendo a nuestros sistemas de gestión, inventando porcentajes que sumen cien y eligiendo categorías que simplifican hasta deformar, porque no había otra forma de alimentarlos. Ahora sí la hay. La pregunta es cuánto tardaremos en dejar de pedirle a la gente que rellene formularios que ya no necesitamos.