Integración de IA en la empresa: del caso de uso a un piloto controlado

En una empresa chica, un proyecto de IA puede fracasar sin hacer ruido: se compra una herramienta, algunas personas la prueban, nadie sabe decir si sirvió y de a poco se deja de usar. Un piloto controlado evita eso. Elegís un proceso, lo medís antes de tocarlo, ponés la IA a trabajar sobre él con una persona que revisa cada resultado y decidís de antemano qué resultado te haría frenar. Esta guía recorre cada paso.

Empezá por un problema que se pueda medir

Elegí un proceso frecuente, molesto y acotado. Los buenos candidatos tienen algunas cosas en común: el mismo tipo de entrada llega muchas veces por semana, alguien le dedica tiempo real y un error se detecta antes de llegar a un cliente. Ordenar los correos entrantes, redactar primeras respuestas, sacar campos de facturas de proveedores y resumir notas de llamadas en un CRM son casos típicos.

Antes de cambiar nada, registrá una línea de base durante dos a cuatro semanas:

• Volumen: cuántos casos por semana
• Tiempo: minutos por caso, medidos sobre una muestra y no estimados a ojo
• Calidad: cada cuánto hay que rehacer o corregir el trabajo, y qué tipos de errores aparecen
• Tiempo de respuesta: desde que llega hasta que está terminado
• Costo de un error: qué pasa cuando se escapa uno

Sin línea de base, el piloto termina en opiniones. Con una, termina en una comparación.

Automatización, RPA o IA: la herramienta correcta para cada paso

Estos términos se usan como si fueran lo mismo, y no lo son.

La automatización basada en reglas y la automatización robótica de procesos (RPA) siguen pasos fijos. Microsoft describe los flujos de escritorio de Power Automate como su capacidad de RPA para tareas repetitivas y basadas en reglas, que trabaja con las aplicaciones a través de elementos de la interfaz, imágenes o coordenadas de pantalla. Ante la misma entrada, la RPA hace siempre lo mismo. Se rompe cuando cambia la pantalla o el formato de la entrada, pero no inventa nada.

La IA, en el sentido que hoy le da la mayoría de las empresas, es un modelo de lenguaje que lee entradas no estructuradas y produce texto o una clasificación. Maneja una variedad que las reglas no pueden cubrir, como correos escritos de cien maneras distintas. Su resultado cambia de una ejecución a otra y puede estar equivocado con total seguridad.

La mayoría de los procesos reales necesitan una combinación: automatización común para que los datos entren y salgan, y un paso de IA para la parte que requiere criterio. Si ningún paso de tu proceso requiere criterio, no necesitás IA para ese proceso.

Revisá si los datos están listos

Para el paso de IA, preguntate:

• ¿Tenés entre 30 y 100 ejemplos anteriores con el resultado correcto, para usar como set de prueba?
• ¿El paso de IA puede obtener el contexto que necesita (la ficha del cliente, la política, la lista de precios) sin tener acceso amplio a todo?
• ¿La entrada contiene datos personales o confidenciales, y las condiciones de tu proveedor permiten ese uso?
• ¿La información de origen está actualizada? Un paso de IA que redacta a partir de una lista de precios vieja produce presupuestos viejos, solo que más rápido.

Si no podés armar un set de prueba, el proceso no está listo para un piloto. Resolvé eso primero.

Diseñá el piloto

Mantené los límites bien acotados:

1. Un proceso, un equipo, un período fijo, por ejemplo de cuatro a ocho semanas.
2. Cada resultado de la IA lo revisa una persona con nombre y apellido antes de que vaya a cualquier lado. Quien revisa aprueba, edita o rechaza, y el sistema registra cuál de las tres.
3. Un registro simple por caso: entrada, resultado de la IA, acción de quien revisó, tiempo dedicado a la revisión.
4. Un plan de respaldo: si el paso de IA falla o se apaga, el trabajo vuelve al proceso anterior sin perder datos.

El registro de revisión cumple dos funciones. Protege a los clientes durante el piloto y es tu principal fuente de datos para evaluar.

Evaluá antes y durante

Pasá tu set de prueba por el paso de IA antes de que arranque el piloto, y de nuevo después de cada cambio en las instrucciones, las fuentes o el modelo. La guía de evaluación de OpenAI lo dice sin vueltas: "Evaluate early and often" (evaluá temprano y seguido). Recomienda fijar primero criterios de éxito claros, probar con una mezcla de casos típicos, casos límite y casos adversos, y calibrar cualquier corrección automática contra el criterio de una persona.

Para una empresa chica, eso se traduce en:

• Escribí los criterios de aprobación antes de ver resultados: qué cuenta como correcto y qué porcentaje tiene que aprobar.
• Incluí los casos difíciles: entradas incompletas, clientes enojados, pedidos poco comunes, otros idiomas.
• Corregí junto con la persona que hoy hace el trabajo.
• Seguí la tasa de edición de quien revisa durante el piloto. Si los revisores reescriben la mayoría de los resultados, el ahorro de tiempo no es real.

Contá todos los costos

Hacé la lista de categorías de costo incluso antes de tener números: suscripciones de software o uso de API medido, tiempo de desarrollo y configuración, tiempo de revisión durante y después del piloto, mantenimiento cuando cambian las instrucciones o los documentos de origen, y el tiempo que alguien dedica a vigilar la calidad. Medí el uso real durante el piloto en lugar de confiar en la estimación de un proveedor. Compará el total contra la línea de base, no contra la versión optimista del proceso.

Gestioná los riesgos que podés nombrar

El AI Risk Management Framework del NIST es un marco voluntario, publicado en enero de 2023 y actualmente en revisión. Organiza el trabajo en cuatro funciones: gobernar, mapear, medir y gestionar. Para un piloto, eso significa que alguien es responsable de la decisión, que dejaste por escrito dónde el paso de IA podría causar daño, que lo estás midiendo y que tenés una respuesta prevista para cuando algo sale mal.

Riesgos típicos para dejar por escrito: respuestas equivocadas enviadas a clientes, datos personales enviados a un proveedor sin una base para hacerlo, personas del equipo que confían de más en los resultados una vez que parecen confiables, y dependencia de una función del proveedor que cambia.

Definí de antemano cuándo frenar

Antes de que arranque el piloto, acordá por escrito qué lo termina antes de tiempo, o qué lo termina en la fecha de revisión sin escalarlo. Por ejemplo:

• La precisión sobre el set de prueba sigue por debajo del umbral acordado después de dos rondas de correcciones
• El tiempo de revisión por caso no es menor que el tiempo por caso de la línea de base
• Aparece un tipo de error grave, como un precio equivocado o una filtración de datos privados, aunque sea una sola vez
• El equipo deja de usarlo

Al final hay tres resultados posibles: escalarlo con los mismos controles de revisión, extender el piloto con una corrección concreta, o frenar. Frenar con un motivo claro es un buen resultado. Sale menos que un año con una herramienta en la que nadie confía.

Dónde entra automotif

Esto es integración de IA: ponemos un paso de IA dentro de las herramientas que tu equipo ya usa, con una persona que aprueba antes de que salga algo, y dejamos armados el registro y el set de prueba para que puedas juzgar el resultado por tu cuenta. Para definir un piloto sobre uno de tus procesos, reservá una llamada gratis de 30 a 60 minutos.

Fuentes

• AI Risk Management Framework (NIST)
• Evaluation best practices (OpenAI API documentation)
• Introducción a flujos de escritorio - Power Automate (Microsoft Learn)