Del piloto a producción: llevar la IA al uso diario

Casi todas las organizaciones que conocemos han tenido un piloto de IA. Muy pocas lo tienen en uso diario. El piloto impresionó en una reunión, unos pocos entusiastas lo probaron durante un mes y luego se detuvo en silencio. El modelo rara vez fue el problema. Lo que faltaba era todo lo que lo rodeaba: un responsable, una forma de medir la calidad, una conexión con los sistemas reales y un plan para las personas que debían usarlo.

Este artículo explica cómo llevamos un trabajo de IA desde un piloto prometedor hasta un sistema que funciona cada día. Se basa en nuestro trabajo de ejecución, incluido un asistente empresarial que hoy usan más de 2.000 personas. Es disciplina de entrega corriente, aplicada a una tecnología fácil de mostrar y más difícil de confiar.

Por qué se estancan la mayoría de pilotos

• Sin responsable. El piloto pertenecía a un equipo de innovación o a un proveedor. Nadie del negocio respondía del resultado una vez terminada la demo.
• Sin evaluación. No había una forma acordada de saber si las respuestas eran correctas, así que cada debate sobre la calidad se convertía en una cuestión de opinión.
• Sin integración. Vivía en una pestaña aparte, con una copia de los datos, al margen de las herramientas y los permisos que la gente realmente usa.
• Sin gestión del cambio. Se mostró la herramienta una vez a las personas y se esperaba que cambiaran su forma de trabajar. La mayoría no lo hizo.

Cuando revisamos un piloto que no prosperó, los motivos son casi siempre los mismos cuatro. Ninguno se resuelve con un modelo mejor.

Define el éxito antes de construir

Antes de empezar cualquier desarrollo, acordamos por escrito tres cosas con el responsable del negocio. Primero, la tarea: qué decisión o qué parte del trabajo apoya el sistema, y para quién. Segundo, la medida: uno o dos números que deben mover, como el tiempo para responder a una consulta de cliente, la proporción de solicitudes resueltas sin escalar o las horas dedicadas a un informe semanal. Tercero, el umbral: qué nivel de calidad debe alcanzar el sistema antes de que lo vean usuarios reales, y qué nivel de error es aceptable para esta tarea.

Un asistente de redacción que ahorra tiempo en los primeros borradores puede tolerar alguna respuesta floja, porque una persona siempre lo revisa. Un sistema que responde a preguntas de políticas para el personal no puede inventar una norma.

También nombramos al responsable en esta etapa. Una persona del negocio responde del resultado, firma las publicaciones y decide cuándo el sistema está listo. Sin esa persona, un piloto no tiene camino hacia la producción.

Si no sabes decir cómo sabrás que el sistema ha empeorado, no estás listo para cambiarlo.

Conjuntos de evaluación y puntos de control de calidad

Lo más útil que puede construir un equipo es un conjunto de evaluación: una colección de preguntas o tareas reales, tomadas de las personas que usarán el sistema, cada una con una respuesta correcta conocida o una descripción clara de lo que debe contener una buena respuesta. Solemos empezar con unos cien casos y ampliamos el conjunto a medida que aparecen nuevos modos de fallo. Debe incluir los casos incómodos: peticiones ambiguas, preguntas fuera de alcance, documentos que se contradicen y peticiones que el sistema debe rechazar.

El conjunto de evaluación convierte la calidad en algo medible. Cada cambio, ya sea un nuevo prompt, una nueva fuente de datos o una nueva versión del modelo, se ejecuta contra él antes de publicarse. Si la precisión baja, el cambio no sale. Esa es la puerta de calidad.

La puntuación puede combinar comprobaciones automáticas con revisión humana. Las comprobaciones automáticas funcionan bien con el formato, las citas y si la respuesta usó la fuente correcta. Las personas siguen siendo mejores para juzgar el tono, la utilidad y los errores sutiles. Una revisión semanal breve de conversaciones reales con expertos en la materia mantiene el conjunto honesto.

Integración, permisos y datos

Un piloto construido con una exportación limpia de documentos se comportará de forma distinta con los datos reales. Los sistemas de producción tienen duplicados, versiones desactualizadas, archivos escaneados y huecos. Construimos sobre las fuentes reales desde el principio, para que los problemas aparezcan cuando aún son baratos de corregir.

Los permisos importan tanto como los datos. Un asistente solo debe mostrar a las personas lo que ya tienen permitido ver. Eso implica respetar las reglas de acceso de cada sistema de origen, transmitir la identidad del usuario en cada petición y filtrar los resultados antes de que lleguen al modelo. Es mucho más fácil diseñarlo desde el principio que añadirlo después.

Por último, el sistema debe estar donde la gente ya trabaja: su herramienta de chat, su correo, su sistema de gestión de casos o su intranet. Un asistente que exige un nuevo acceso y un hábito nuevo acabará olvidado.

Seguridad y privacidad desde el diseño

Dónde se tratan los datos, cuánto tiempo se conservan, quién puede leer los registros y qué proveedores de modelos intervienen son decisiones de diseño. Las cerramos con los equipos de seguridad, legal y protección de datos en las primeras semanas, no en la aprobación final. Para trabajos sensibles, puede significar ejecutar los modelos dentro de la nube de la propia organización o en sus propios servidores.

También planificamos el uso indebido y los errores. Eso incluye limitar las acciones que el sistema puede ejecutar por su cuenta, probarlo frente a intentos de anular sus instrucciones y registrar suficiente detalle para investigar una incidencia. El Marco de Gestión de Riesgos de IA del NIST y, en Europa, el EU AI Act ofrecen una estructura útil para estas conversaciones.

Adopción: formación, embajadores internos y retroalimentación

La adopción es un programa de trabajo, no un correo de lanzamiento. La formación breve y específica por rol muestra a las personas en qué es buena el sistema, dónde flaquea y cómo comprobar sus respuestas.

Los embajadores marcan la mayor diferencia. En cada equipo identificamos a una o dos personas que usan el sistema desde el principio, ayudan a los compañeros y devuelven los problemas.

El feedback debe ser fácil y visible. Un simple pulgar arriba o abajo con un comentario opcional, revisado cada semana, da al equipo un flujo constante de casos reales. Cuando la gente ve que su comentario se corrige, sigue dándolo.

Funcionamiento en producción

Una vez en producción, supervisamos el uso, los tiempos de respuesta y las tasas de error, y también las señales de calidad: puntuaciones de feedback, tasas de escalado y la proporción de respuestas con una fuente válida. Una caída en cualquiera de ellas se trata como incidencia.

El coste necesita una gestión activa. El uso crece cuando un sistema resulta útil, y los costes lo siguen. Guardar en caché las respuestas habituales, enviar las peticiones sencillas a modelos más pequeños y fijar presupuestos por equipo lo mantiene previsible.

Los modelos cambian. Los proveedores publican nuevas versiones y retiran las antiguas. Con un conjunto de evaluación establecido, una actualización del modelo se convierte en un cambio rutinario: se ejecuta el conjunto, se comparan los resultados, se revisan las diferencias y se publica si se cumple la puerta de calidad. Sin uno, cada actualización es un riesgo.

Lista de comprobación para producción

1. Nombra al responsable y la métricaUna persona responsable en la empresa, la tarea que respalda el sistema y la cifra que debe mover.
2. Acuerda el umbral de calidadDefine qué nivel de calidad debe alcanzar antes de que lo vean los usuarios reales, y qué tipos de error son inaceptables para esta tarea.
3. Construir el conjunto de evaluaciónRecoger casos reales con respuestas correctas conocidas, incluidos los casos incómodos y fuera de alcance, y evaluar cada versión frente a ellos.
4. Conectar con sistemas realesUsa las fuentes de datos de producción, respeta los permisos existentes y coloca el sistema dentro de las herramientas que la gente ya utiliza.
5. Resuelve seguridad y privacidadAcuerda con las personas adecuadas la ubicación de los datos, la conservación, el registro y los proveedores de modelos antes de que la construcción esté muy avanzada.
6. Planificar la adopciónFormación por rol, un referente en cada equipo y un ciclo de retroalimentación que se revisa cada semana.
7. Poner en marcha las operacionesMonitorización de la calidad y de la disponibilidad, control de costes, una vía de gestión de incidencias y un proceso rutinario para las actualizaciones de modelos.

Preguntas frecuentes

Nada de esto es vistoso. Es la diferencia entre una demo que impresiona en una sala y un sistema del que la gente depende cada día.