1. Elegir una tarea que puedas evaluar
Busca una actividad repetitiva con entradas reconocibles y una salida comprobable: clasificar solicitudes, preparar un borrador de respuesta o extraer campos de documentos. Descarta como primer piloto los procesos donde un error pueda producir pagos, compromisos comerciales o decisiones difíciles de revertir. La primera versión debe permitir aprender sin trasladar toda la responsabilidad al sistema.
Escribe el proceso actual con su entrada, responsable, salida y excepciones. Si una regla sencilla resuelve la tarea de forma consistente, quizá no necesitas IA. Reserva el modelo para la parte que requiere interpretar lenguaje o documentos y conserva reglas explícitas para fechas, importes, permisos y estados. Así resulta más fácil entender qué falló y corregirlo.
2. Acordar datos, límites y responsables
El AI Risk Management Framework de NIST ofrece un marco voluntario para gestionar riesgos de los sistemas de IA durante su diseño, uso y evaluación. Para un piloto, la traducción práctica es concreta: dejar por escrito propósito, responsables, límites y criterios de revisión. [1]
Haz un mapa de los datos que entran, dónde se procesan, quién puede consultarlos y cuánto tiempo se conservan. Empieza con ejemplos sintéticos o preparados para pruebas, sin secretos ni información personal innecesaria. Verifica las condiciones del proveedor elegido para tu cuenta y contrato concretos; no supongas que todos los productos aplican el mismo tratamiento de datos.
3. Diseñar un flujo con una salida segura
Ejemplo hipotético: llegan correos con solicitudes de soporte. La IA propone una categoría y un borrador; una persona comprueba ambos y decide si enviarlo. El sistema registra la propuesta, la corrección y el tiempo empleado. En esta fase no borra correos, no modifica contratos y no escribe directamente sobre datos de producción. La revisión humana es una etapa definida del proceso.
Establece qué sucede cuando falta información, hay un formato inesperado o la petición queda fuera del alcance. Una buena salida puede ser “requiere revisión”, acompañada del motivo. Evita obligar al modelo a producir una respuesta concluyente en todos los casos. Las reglas de aceptación deben validarse en el código o la aplicación que ejecuta el flujo, no depender solo de lo que diga el modelo.
4. Tratar los documentos como datos
OWASP describe la inyección indirecta de instrucciones como un riesgo cuando contenido externo, por ejemplo un archivo o una web, altera el comportamiento de un modelo. Recuperar documentos con RAG no elimina por sí mismo ese riesgo. [2]
Por eso conviene separar lo que el sistema puede hacer de lo que encuentra en un correo. Da a las integraciones únicamente los permisos necesarios y mantén las credenciales fuera del contenido enviado al modelo. Si el piloto solo prepara borradores, no necesita permiso para enviarlos. Pide confirmación a una persona antes de acciones con consecuencias y registra quién las aprobó.
5. Medir con ejemplos representativos
Prepara un conjunto de casos habituales y excepciones antes de empezar. Incluye información incompleta, duplicados, ambigüedades e idiomas reales del negocio. Conserva una respuesta esperada o un criterio de evaluación por caso. Separa los ejemplos utilizados para ajustar el flujo de aquellos que emplearás para comprobarlo; así no confundes adaptación con calidad general.
Mide tiempo total, incluida la revisión, errores aceptados, correcciones y coste por tarea. Compara con el proceso anterior sobre casos equivalentes. Un borrador rápido puede no ahorrar trabajo si revisarlo lleva más tiempo que redactarlo. Define de antemano el nivel de calidad aceptable y quién decide si el piloto pasa, se ajusta o se detiene; no prometas un porcentaje de ahorro sin medirlo.
6. Ampliar solo lo que ya has comprobado
Empieza con pocas personas y un volumen limitado. Documenta cómo detener el flujo, volver al proceso manual y revisar trabajos pendientes sin ejecutarlos dos veces. Cada cambio de modelo, instrucciones o integración puede alterar resultados: guarda versiones y repite una evaluación proporcionada antes de ampliar permisos o volumen.
Para equipos en Barcelona o distribuidos internacionalmente, prueba cada idioma que realmente utilizarán y acuerda horarios de soporte interno. El resultado del piloto debe ser una decisión argumentada: continuar, modificar el alcance o abandonar la idea. Una automatización útil es la que el equipo puede supervisar, mantener y explicar después de la demostración inicial.