IA o reglas fijas para clasificar solicitudes internas: cómo decidir

Una persona pide acceso a una carpeta de proyecto por el canal habitual. Otra escribe: «Necesito los documentos para cerrar la entrega, pero no sé si me falta permiso o si todavía no se han publicado». Ambas solicitudes podrían acabar en el mismo equipo, pero no contienen la misma información. Si el sistema las clasifica mal, alguien tendrá que reenviarlas, pedir contexto y recuperar tiempo perdido.

Para un equipo de servicios profesionales, clasificar solicitudes internas no consiste solo en poner etiquetas. La clasificación suele determinar quién recibe el trabajo, qué información se solicita y qué puede hacerse después. Elegir entre IA y reglas fijas exige mirar el contenido de las peticiones, el coste de equivocarse y el grado de control que necesita el proceso.

Primero, definir qué decisión se quiere automatizar

«Clasificar» puede significar identificar un tema, asignar un responsable, marcar una urgencia o autorizar una acción. Conviene separarlos. Un sistema puede sugerir que una petición trata sobre permisos sin concederlos automáticamente. Del mismo modo, detectar una posible urgencia no equivale a saltarse el orden de aprobación.

Antes de elegir tecnología, dibuja el recorrido de una solicitud: por dónde entra, qué datos necesita, quién puede resolverla y qué ocurre si está incompleta o se envía al equipo equivocado. Si dos departamentos discrepan habitualmente sobre quién es responsable, la clasificación automática no resolverá por sí sola esa falta de acuerdo. Hace falta definir la propiedad del flujo y una vía de escalado.

También merece la pena comprobar si el problema está en la entrada. Un formulario breve con campos bien elegidos puede eliminar gran parte de la ambigüedad sin interpretar lenguaje libre. La pregunta no es «¿podemos usar IA?», sino «¿qué información falta para tomar una decisión fiable?».

Cuándo bastan las reglas fijas

Las reglas son una buena opción cuando las categorías son estables y pueden expresarse mediante datos verificables. Por ejemplo: si una solicitud lleva el tipo «acceso a proyecto», identifica el proyecto y procede de una persona autorizada a pedirlo, puede enviarse al equipo responsable para su revisión. Cada condición se puede explicar, probar y modificar.

Este enfoque ofrece previsibilidad. El mismo conjunto de campos produce el mismo resultado, lo que facilita investigar un error. También permite detener el flujo cuando falta un dato obligatorio. Su límite aparece cuando las personas describen el mismo problema de muchas maneras, eligen categorías incorrectas o plantean varias necesidades en un único mensaje. Añadir excepciones para cada frase nueva puede volver las reglas difíciles de mantener.

No hay que confundir enrutamiento con ejecución. Una regla que deriva una petición a un equipo tiene consecuencias distintas de otra que cambia permisos o modifica un registro. Cuanto más sensible sea la acción posterior, más importante es separar la clasificación de la aprobación.

Cuándo aporta valor la IA

Un modelo de lenguaje puede resultar útil si las solicitudes llegan como correos, mensajes o descripciones abiertas. Puede identificar el asunto probable, resumir la petición y señalar qué información falta. En el ejemplo inicial, podría detectar que hay dos hipótesis —permiso o publicación pendiente— y pedir una aclaración en lugar de escoger una categoría con aparente seguridad.

Esa flexibilidad no convierte sus respuestas en hechos. Una frase ambigua, una referencia a otro proyecto o un documento adjunto fuera de contexto pueden llevar a una clasificación errónea. Por eso conviene limitar las categorías posibles, proporcionar definiciones claras y permitir una salida como «no estoy seguro». Si el sistema no puede justificar su propuesta con la información recibida, debe pedir más datos o pasarla a una persona.

La IA es menos apropiada para aplicar condiciones exactas ya disponibles como campos estructurados: comprobar un código de proyecto, respetar una lista de responsables o ejecutar una política de acceso. Esas decisiones deben quedar en reglas y sistemas autorizados. Tampoco debería convertir una interpretación del texto en una aprobación automática cuando intervienen permisos, datos sensibles o compromisos con un cliente.

Un enfoque combinado, con límites visibles

Muchas operaciones necesitan ambos enfoques. Un formulario recoge proyecto, tipo de petición y plazo solicitado. Las reglas comprueban campos obligatorios y determinan qué acciones están permitidas. Solo si la descripción libre añade complejidad, la IA propone una categoría, un resumen o una pregunta de aclaración. La decisión se registra y, en los casos definidos como sensibles o inciertos, una persona la confirma.

Para que esto funcione, hay que diseñar el recorrido de las excepciones. ¿A quién llega una solicitud sin categoría clara? ¿Puede el destinatario corregir la etiqueta sin perder el mensaje original? ¿Qué ocurre cuando una petición mezcla acceso a archivos y cambios en una entrega? Una interfaz que permite dividirla en dos tareas puede ser más útil que obligar al clasificador a escoger una sola.

También importa qué datos puede leer cada componente. La clasificación no justifica dar acceso indiscriminado a conversaciones o documentos. Limita los datos utilizados, respeta los permisos existentes y registra qué información sustentó una propuesta, quién la corrigió y qué acción se ejecutó. Así, revisar un fallo no depende de reconstruirlo de memoria.

Medir los errores antes de ampliar el alcance

Empieza con una muestra de solicitudes reales revisada por las personas que conocen el trabajo. Define las categorías y acuerda cuál habría sido el destino correcto de cada caso; reserva ejemplos distintos para comprobar los cambios posteriores. Si el desacuerdo entre revisores es frecuente, aclara el proceso antes de exigir precisión al sistema.

No midas solo cuántas etiquetas coinciden. Observa qué solicitudes se enviaron al equipo equivocado, cuáles necesitaron reasignación, cuántas quedaron sin resolver por falta de contexto y cuánto trabajo supuso corregirlas. Distingue los errores leves de los que podrían exponer información, retrasar una aprobación importante o activar una acción indebida. Revisa también si el sistema reconoce la incertidumbre cuando corresponde: derivar un caso dudoso puede ser preferible a clasificarlo mal con confianza.

Una prueba inicial puede limitarse a proponer categorías sin ejecutar cambios. Compara sus propuestas con las decisiones humanas, examina los desacuerdos y ajusta formularios, reglas o instrucciones según la causa. Solo después tiene sentido automatizar los casos repetibles de bajo riesgo y mantener controles para el resto.

Elegir entre IA y reglas para clasificar solicitudes no es una competición entre tecnologías: es una decisión sobre datos, excepciones y responsabilidad. Si quieres revisar un flujo concreto y definir qué conviene automatizar, Cibercoding puede ayudarte a acotar el primer paso.