De un correo entrante a un caso resuelto: diseña un flujo de IA controlado

1. Delimita el caso antes de elegir la IA

Un flujo de clasificación y derivación convierte una solicitud recibida —por ejemplo, un correo— en un caso organizado y dirigido a una cola o sistema de destino. La IA puede ayudar a interpretar texto libre, pero no debe ser el punto de partida ni decidir por defecto qué acciones ejecutar. Primero delimita qué mensajes entran, qué resultado debe producir el proceso y qué situaciones quedan fuera.

Especifica el disparador con precisión: una carpeta concreta, una dirección de recepción o un conjunto de criterios verificables. La documentación de Power Automate describe desencadenadores de correo que pueden filtrar por propiedades como carpeta, remitente, destinatario, presencia de adjuntos y asunto. Esto permite reducir entradas irrelevantes antes de procesarlas, aunque esos filtros no sustituyen la validación del contenido ni determinan por sí solos una categoría semántica.

Define el resultado operativo en términos observables. Por ejemplo: crear un caso en una cola de soporte con una categoría permitida, el identificador del mensaje y una referencia al contenido original. No prometas que el sistema resolverá la solicitud si el alcance solo contempla clasificarla y derivarla. Una clasificación es una propuesta o un dato del flujo; no equivale a resolver el problema del remitente.

También conviene fijar exclusiones explícitas. Un primer flujo podría dejar fuera mensajes con adjuntos que requieren revisión especializada, solicitudes legales, datos sensibles no autorizados para el procesamiento o mensajes que no sean solicitudes de servicio. En esos casos, el comportamiento seguro es conservar el mensaje y enviarlo a revisión, no forzar una categoría parecida.

Antes de escribir instrucciones para un modelo, registra quién es responsable del proceso, quién mantiene las categorías, quién autoriza cambios y quién atiende la cola de revisión. El equipo debe poder explicar qué ocurre cuando el sistema no entiende una solicitud, no solo qué ocurre en el caso normal.

2. Asigna cada decisión a reglas, modelo, persona o sistema

No todas las etapas necesitan IA. Usa reglas deterministas cuando el criterio sea explícito y estable: aceptar solo una carpeta, comprobar que el remitente existe o detectar si falta un identificador obligatorio. Una regla produce el mismo resultado ante la misma entrada y es más fácil de probar. No uses un modelo para decidir algo que puede expresarse como una comprobación exacta.

Reserva el modelo para una tarea acotada de interpretación, como proponer una categoría a partir del texto de una solicitud. Limita sus opciones a una lista cerrada y pide una salida estructurada que la integración pueda validar. El modelo no debe poder inventar destinos, permisos o acciones. La documentación conceptual de flujos de IA describe la clasificación de tickets entrantes como un posible uso, pero no demuestra la exactitud de una implementación concreta: esa debe medirse en las pruebas del equipo.

La persona revisora debe ocuparse de las excepciones que el sistema no pueda clasificar con seguridad: solicitudes ambiguas, categorías solapadas, entradas incompletas, mensajes fuera de alcance o fallos de validación. La revisión no es un trámite opcional, sino una ruta definida con una cola, un responsable y una acción posterior identificables.

El sistema de destino ejecuta acciones operativas, como crear un caso o agregar información a uno existente. Separa la sugerencia de clasificación de la acción que modifica el sistema. Primero valida la propuesta; después aplica la acción autorizada. No permitas que el texto de un correo entrante decida cambiar el comportamiento del flujo, ampliar sus permisos o elegir una acción no incluida en el contrato.

Una distribución prudente de responsabilidades puede resumirse así: reglas para filtrar y validar, modelo para proponer una categoría, persona para resolver excepciones y sistema para guardar o derivar únicamente resultados aprobados. Esa separación ayuda a localizar errores y evita que una predicción se convierta directamente en una acción irreversible.

3. Diseña un contrato de datos con abstención

El contrato de datos define qué información entra, qué resultado se acepta y qué debe hacer la integración cuando algo falta o no cumple las reglas. Es una frontera técnica entre el modelo y el sistema de destino. Sin ella, una respuesta plausible en lenguaje natural puede confundirse con un resultado válido, aunque contenga campos imprevistos o una categoría inexistente.

Para una prueba inicial, podrías exigir un identificador de solicitud, el texto pertinente, una categoría de una lista cerrada y un estado de revisión. Añade un campo de justificación breve solo si ayuda a la supervisión; evita copiar más contenido personal del necesario. Distingue claramente entre un valor desconocido, un campo ausente y un error de validación: no son equivalentes y no deben convertirse silenciosamente en una categoría predeterminada.

La abstención es un resultado válido del flujo. Establécela si la entrada es ambigua, está incompleta, no pertenece al alcance o no puede clasificarse con suficiente confianza según un criterio que el equipo haya definido y probado. No presentes un umbral genérico como garantía. El valor adecuado depende del coste de un enrutamiento incorrecto y debe calibrarse con ejemplos representativos.

Valida la salida antes de usarla. Comprueba que estén presentes los campos obligatorios, que los tipos sean correctos, que la categoría pertenezca a la lista vigente y que el estado de revisión corresponda a la política. Si cualquier condición falla, no envíes el caso a una cola operativa como si estuviera aprobado: conserva la solicitud y deriva el problema a revisión o a una cola de errores.

Trata todo texto recibido como datos, no como instrucciones de control. Un correo puede incluir frases que intenten modificar la tarea o pedir acciones distintas. La integración debe limitarse a extraer y clasificar conforme al contrato establecido; el contenido del mensaje nunca debe ampliar las capacidades disponibles para el flujo.

4. Construye una ruta segura de ejecución

Diseña la secuencia como pasos pequeños y observables: recibir el correo, identificarlo, comprobar que entra en el alcance, preparar los datos, solicitar una categoría, validar la respuesta, revisar excepciones, derivar el caso y registrar el resultado. Cada paso debe tener una condición de éxito y una ruta de error. Si una etapa falla, la solicitud debe seguir siendo localizable y no desaparecer por quedar a medio procesar.

Usa filtros en el desencadenador cuando reduzcan ejecuciones innecesarias. La documentación de Microsoft indica que las propiedades del correo pueden evaluarse en el propio desencadenador y advierte que comprobarlas después como una condición puede consumir ejecuciones aunque no se cumpla el filtro. Esto es un detalle específico de Power Automate y de sus cuotas; no debe trasladarse automáticamente a otras plataformas.

Antes de crear un caso, comprueba si la solicitud ya fue procesada. Usa un identificador estable del mensaje o una clave de idempotencia acordada con el sistema de destino. La guía disponible sobre desencadenadores de correo no documenta un mecanismo completo de idempotencia; por ello, esta protección debe verificarse en la integración elegida, no asumirse por el mero hecho de usar un flujo automatizado.

Concede a la integración solo los permisos necesarios para sus tareas. Si puede leer mensajes y crear casos, evita otorgarle además permisos para borrar correos, administrar usuarios o cambiar categorías sin una necesidad demostrada. Cuando la plataforma lo permita, separa la identidad que lee el correo de la que escribe en la cola, y documenta quién puede modificar conexiones y credenciales.

Registra identificadores y decisiones que permitan reconstruir el recorrido: recepción, versión de categorías, resultado validado, derivación, error y revisión humana. Define qué datos no deben almacenarse, quién consulta los registros y cuánto tiempo se conservan, de acuerdo con las políticas aplicables. No conviertas el registro en una copia indiscriminada de todo el buzón.

Diseña la operación para fallos parciales. Si el sistema de destino no responde, conserva el caso pendiente y registra el error. Si la creación se reintenta, evita duplicados. Si el sistema no puede confirmar si la acción se completó, no repitas a ciegas: consulta el estado por el identificador de solicitud o envía el caso a conciliación manual.

5. Prueba casos normales, incompletos y ambiguos

Una prueba útil no consiste en enviar un solo correo y comprobar que aparece un caso. Prepara un conjunto de mensajes ficticios que cubra tanto rutas esperadas como excepciones. No uses datos personales reales para validar el comportamiento inicial si puedes usar ejemplos sintéticos; asegúrate de que los textos de prueba no disparen conexiones o acciones fuera del entorno controlado.

Incluye solicitudes completas de categorías distintas, mensajes sin un campo requerido, correos con categorías que se solapan, mensajes fuera de alcance y respuestas mal formadas del modelo. Añade también fallos de integración: destino no disponible, demora, rechazo de permisos y reintento después de un resultado incierto. Para cada caso, escribe de antemano el resultado esperado, la cola y el registro que debería quedar.

Evalúa hechos observables, no impresiones sobre la calidad del texto. Comprueba que el mensaje correcto llega al destino previsto, que se conservan sus identificadores, que las entradas ambiguas se abstienen o se revisan y que los fallos no hacen desaparecer la solicitud. Si el modelo propone una clasificación incorrecta, mide cuántas veces ocurre en el conjunto de prueba y revisa el coste de cada tipo de error.

El conjunto de prueba debe reflejar las categorías y el lenguaje que realmente recibe el equipo, dentro de los límites de privacidad y acceso. Si las categorías cambian, vuelve a ejecutar las pruebas pertinentes. No afirmes una tasa de eficacia antes de medirla en el contexto propio; los ejemplos de una guía general o de un proveedor no sustituyen esos resultados.

Mantén una ruta de comparación con el proceso manual al comienzo del despliegue. Esa comparación ayuda a detectar diferencias entre la propuesta del modelo y la decisión de quien revisa. Define quién puede corregir el caso y cómo se registra la corrección, para que el equipo pueda distinguir un error de clasificación de un fallo de integración.

6. Integra con revisión humana y permisos mínimos

La cola de revisión debe ser un destino definido, no una etiqueta vaga. Determina quién la atiende, con qué plazo operativo, qué información necesita y cómo comunica una corrección. Si nadie es responsable de revisar excepciones, la abstención solo traslada el problema y puede crear una acumulación invisible.

Empieza en modo de observación cuando sea viable: el sistema propone categorías y una persona confirma cada derivación. Compara propuestas y decisiones humanas antes de ampliar la automatización. Decide de antemano qué evidencia justifica activar la creación automática de casos y quién puede autorizar ese cambio. Este planteamiento no implica que el modelo ya tenga una eficacia conocida; permite medirla en el proceso real.

Configura permisos para que el flujo haga únicamente lo necesario. Revisa las conexiones utilizadas, el acceso a buzones y la capacidad para crear o modificar casos. Las instrucciones disponibles de Power Automate requieren conexiones a los servicios utilizados para ejecutar los ejemplos, pero no especifican un modelo universal de permisos mínimos para todos los entornos. La configuración debe revisarse en la plataforma y organización concretas.

Separa los permisos de lectura, escritura y administración cuando sea posible. Limita quién puede cambiar las categorías, las reglas de derivación, las credenciales y el prompt de clasificación. Si un cambio modifica el destino o el alcance, requiere pruebas y autorización antes de publicarse.

Asegúrate de que la persona revisora pueda ver la información necesaria sin recibir más datos de los que requiere. Define cómo se tratan los mensajes sensibles, cómo se accede al original y qué datos se exponen en notificaciones o registros. Las decisiones de conservación y acceso dependen de las políticas de la organización; no se deducen de que una automatización funcione.

7. Define supervisión, incidencias y reversión

Antes del lanzamiento, define indicadores que describan el funcionamiento, sin presentarlos como una promesa de eficacia: volumen recibido, proporción enviada a revisión, errores de validación, derivaciones duplicadas, fallos del destino, reintentos y correcciones humanas. Para valorar la clasificación, compara la propuesta con una decisión revisada y registra cómo se calcula el resultado.

Acordad límites operativos para pausar el flujo. Por ejemplo, un aumento inesperado de errores, una cola de revisión que supera su capacidad o un cambio no autorizado de categorías puede justificar desactivar la acción automática. Los umbrales deben ajustarse a la carga y al riesgo del proceso; no existe un valor universal sustentado por la documentación disponible.

La reversión debe permitir volver al proceso manual sin perder solicitudes pendientes. Conserva una lista de mensajes procesados y pendientes, documenta cómo se desactiva el flujo y evita que la reanudación reprocesse sin control los correos ya tratados. Prueba la pausa y la vuelta a operación antes del lanzamiento, no durante una incidencia real.

Registra cambios en categorías, prompts, reglas, permisos y conectores con responsable y fecha. Después de cada cambio sustancial, vuelve a ejecutar casos de prueba que cubran rutas normales, abstenciones, errores y duplicados. Si la plataforma de destino o el desencadenador cambia, revisa también las conexiones y los permisos.

Una implementación controlada no termina al guardar el flujo. Requiere que operaciones y tecnología sepan detectar fallos, atender excepciones, corregir casos y detener la automatización. El criterio de éxito es que cada solicitud sea trazable y llegue a una ruta válida, incluso cuando la IA no pueda decidir.

8. Recorrido completo con datos ficticios

Imagina que el buzón recibe el mensaje msg-1042 en la carpeta «Solicitudes». El asunto es «No puedo acceder» y el cuerpo dice: «Desde esta mañana no puedo iniciar sesión. ¿Podrían ayudarme?». El filtro confirma que el mensaje llegó a la carpeta vigilada. La integración conserva el identificador y prepara únicamente el asunto y el texto necesarios para clasificar.

El modelo devuelve la categoría «acceso», que está en la lista permitida, junto con el estado «lista_para_derivar». La validación confirma que los campos están presentes y que la categoría tiene un destino configurado. El sistema consulta si msg-1042 ya tiene un caso asociado. Como no lo encuentra, crea un caso ficticio con la referencia del correo y registra la decisión.

Ahora cambia el mensaje a: «No funciona. Es urgente». Si no hay suficiente contexto para distinguir entre un problema de acceso, una interrupción general u otra incidencia, el flujo no debe adivinar. Devuelve una abstención y envía el mensaje a la cola de revisión, conservando su identificador. La persona revisora puede pedir información adicional o asignar la categoría correcta conforme al procedimiento.

Por último, simula una categoría no permitida o una caída del sistema de destino. La primera debe detenerse en la validación; la segunda debe dejar una solicitud pendiente, con un error y una forma de reintentar o conciliar el estado. En ninguno de los dos casos el mensaje debe perderse ni convertirse silenciosamente en una derivación válida.

Este recorrido permite revisar la frontera entre interpretación y acción: el modelo propone, las reglas validan, la persona resuelve excepciones y el sistema ejecuta la acción autorizada. Repite las pruebas con los casos relevantes del proceso antes de pasar de un entorno de prueba a un uso operativo. No extrapoles el resultado de unos pocos ejemplos a todos los mensajes que la organización recibirá.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.