Adopción de la IA: por qué un buen producto no basta

Hay un momento concreto en los proyectos de IA: la solución funciona. Las pruebas pasan, la calidad se considera aceptable, se abre el acceso a los equipos. Técnicamente el trabajo está hecho. Unas semanas después, el proceso de negocio se parece exactamente a lo que era antes, con una herramienta más en el navegador.

Esta guía trata de lo que ocurre después de la puesta en producción. No es un artículo genérico de gestión del cambio: los sistemas de IA plantean dificultades de adopción propias. Sus resultados son probabilísticos, sus errores suelen ser plausibles, el papel de la persona se desplaza y los usuarios deben aprender algo poco intuitivo: cuándo no conviene usarlos.

Desplegado no es usado

La primera confusión que conviene deshacer es la de los estados. Un sistema puede estar desplegado sin usarse. Puede usarse sin usarse bien. Puede usarse bien por unas pocas personas sin formar parte del trabajo del equipo. Estas cuatro situaciones exigen acciones distintas, y confundirlas lleva a responder a un problema de organización mejorando el modelo.

1. 1

   Desplegado

   disponible

   El sistema es accesible, la autenticación funciona, los permisos están definidos. Es un estado técnico y no dice nada del uso.

2. 2

   Usado

   abierto

   Hay personas que lo utilizan. Puede seguir siendo exploratorio, puntual o limitado a unos pocos curiosos.

3. 3

   Bien usado

   competente

   Se utiliza en los casos donde aporta algo, se verifica lo que hay que verificar y se sabe cuándo parar.

4. 4

   Integrado en el trabajo

   proceso

   El proceso se ha redefinido en torno al nuevo reparto de tareas: el sistema deja de ser una opción al lado del trabajo y pasa a formar parte de él.

Ninguna cifra genérica de adopción sitúa un proyecto en esa escala. Lo que importa es saber en qué estado se está realmente, caso de uso por caso de uso.

Partir del trabajo real, no de la herramienta

Antes de hablar de formación, comunicación o acompañamiento, hay que describir el trabajo tal y como se hace. Esa descripción suele faltar en los proyectos de IA, porque una demo convincente hizo pensar que la necesidad ya estaba entendida.

• El proceso actual, incluidas las etapas informales que nadie documenta.
• Las personas implicadas, su carga, su experiencia, su margen de maniobra.
• Las decisiones que se toman y el momento en que se vuelven irreversibles.
• Las fricciones reales, que no siempre son las que ve la dirección.
• La información que se usa de verdad y la que está disponible pero se ignora.
• Las excepciones, que a menudo representan una parte importante del trabajo.
• La responsabilidad: quién responde del resultado, ante quién y con qué consecuencias.
• El riesgo: cuánto cuesta un error y a quién le cuesta.

Mientras eso no se haga, decir «añadimos un copiloto» no describe una transformación: describe una suma. No dice qué etapa desaparece, cuál cambia de naturaleza ni qué verificación se vuelve necesaria.

Definir el nuevo reparto humano / IA

La adopción exige explicitar un reparto de tareas que, si no, se instala por defecto y de forma incoherente entre usuarios. Seis preguntas bastan para fijar el marco.

• Qué propone el sistema: sugerencia, borrador, clasificación, extracción, hipótesis.
• Qué puede ejecutar por sí solo y dentro de qué límites estrictos.
• Qué verifica siempre una persona y qué se revisa solo por muestreo.
• Qué decide la persona, sin que la propuesta tenga valor de recomendación oficial.
• Cuándo escalar: fuera de ámbito, caso sensible, desacuerdo con el sistema, duda.
• Quién sigue siendo responsable de la decisión y de sus consecuencias, con nombre.

El human-in-the-loop no es una garantía por sí mismo. Quien debe validar rápido propuestas mayoritariamente correctas acaba validando también las incorrectas. La pregunta útil no es «¿hay una persona?» sino «¿esa persona tiene tiempo, información y mandato para decir que no?».

Construir una confianza calibrada

Los sistemas de IA fallan de una manera particular: sus errores se parecen a sus aciertos. Un resultado incorrecto puede estar bien redactado, ser coherente y resultar convincente. Por eso la calibración importa más que el nivel de confianza.

• Confianza excesiva: se acepta sin revisar, también donde el error sale caro.
• Desconfianza sistemática: se rehace todo y la herramienta se convierte en carga.
• Confianza calibrada: se sabe en qué tareas el sistema es sólido, en cuáles no, y se ajusta la verificación.

Ayudan tres palancas, y ninguna basta por separado. La experiencia repetida en casos cuya respuesta ya se conoce; reglas de uso explícitas que delimitan el ámbito; y la visibilidad de los límites, es decir, la capacidad del producto de mostrar de dónde viene un resultado, qué no ha tenido en cuenta o cuándo trabaja fuera de su terreno habitual.

Una formación que no se limita a la interfaz

Formar en «cómo usar la herramienta» supone que la dificultad es la interfaz. En los sistemas de IA la dificultad es el criterio: decidir si ese resultado, en ese contexto, puede usarse tal cual.

• Capacidades: qué hace bien el sistema, sobre qué contenidos y en qué ámbito.
• Límites: qué no sabe, qué ignora, qué no ve.
• Casos adecuados y casos a evitar, con ejemplos del propio negocio.
• Verificación: qué releer, cómo contrastar, qué fuente prevalece.
• Confidencialidad: qué puede enviarse al sistema y qué no.
• Escalado: a quién acudir cuando el caso sale del marco.
• Feedback: cómo señalar un error para que sirva de algo.

No existe un formato universal. Una sesión única rara vez funciona: entender los límites se construye sobre casos encontrados y, por tanto, con el tiempo.

Observar la adopción sin inventar indicadores

Muchos proyectos montan un cuadro de mando de uso antes de decidir qué quieren observar. El número de consultas no dice si el trabajo se hace mejor ni si el sistema se usa donde es pertinente. En lugar de un KPI estándar, es más honesto quedarse con categorías de observación y elegir las que tienen sentido para el caso de uso.

• Uso: quién lo usa, en qué casos y en qué etapa del proceso.
• Calidad del trabajo producido, valorada por quienes responden de él.
• Errores: naturaleza, frecuencia relativa y gravedad.
• Correcciones humanas: lo que siempre se rehace después del sistema.
• Rodeos: qué hacen los usuarios por su cuenta y por qué.
• Abandono: quién probó y dejó de usarlo, y qué lo provocó.
• Comprensión: si los usuarios saben decir cuándo no usarlo.
• Tiempo o esfuerzo, cuando la medición es realmente posible sin reconstruirla artificialmente.
• Efectos inesperados, incluidos los de profesiones vecinas y etapas posteriores.

La señal correcta depende del caso de uso: en una ayuda a la redacción, un párrafo que siempre se reescribe informa más que el volumen de uso; en una ayuda a la decisión, la frecuencia de desacuerdos justificados cuenta más que la tasa de aceptación.

Caso pedagógico: un copiloto de síntesis documental

El escenario siguiente es ficticio y pedagógico. No describe ninguna organización real ni contiene datos medidos.

Un equipo pone a disposición un copiloto que prepara una primera síntesis a partir de documentos internos. El sistema funciona: las síntesis son legibles y en general fieles. El acceso se abre a todo el departamento.

Por qué desplegar no basta

Aparecen enseguida dos comportamientos opuestos. Unos reutilizan la síntesis casi tal cual, incluso en expedientes sensibles donde una omisión tiene consecuencias. Otros no la usan, porque no saben si los documentos más recientes están cubiertos y prefieren no asumir el riesgo. Ninguna reacción es irracional: falta información compartida sobre el ámbito del sistema.

Qué hay que clarificar

• La síntesis es un borrador de trabajo, nunca un documento enviable tal cual.
• Quien lo envía sigue siendo responsable del contenido, incluido lo que no ha leído.
• Se listan los documentos cubiertos y también los que no lo están.
• Los expedientes de categoría sensible siguen el procedimiento existente, sin copiloto.

Qué errores observar

Tres familias merecen atención: las omisiones, más difíciles de detectar que un error factual; las afirmaciones plausibles que no están en las fuentes; y los casos en que el sistema procesa con seguridad un documento que no debería haber procesado, por ejemplo una versión obsoleta.

Cómo recoger el feedback

Un aviso útil es el que cuesta poco a quien lo hace. Un botón que abre un formulario largo no se usará. Un aviso en un clic, junto con la revisión periódica de unos pocos casos reales con dos o tres usuarios, suele aportar más información que una encuesta de satisfacción.

Cómo ajustar

No todos los ajustes son técnicos. Restringir el ámbito a una categoría de documentos, mostrar la fecha de la fuente, añadir una revisión cruzada en expedientes sensibles o retirar directamente un caso de uso mal servido: son decisiones de organización tanto como de producto, y a menudo hacen más por la adopción que cambiar de modelo.

Qué dice esto de un perfil

Saber llevar una solución de IA al trabajo real es una competencia distinta de saber construirla. Se demuestra con decisiones: un ámbito restringido a propósito, una responsabilidad clarificada, un caso de uso abandonado tras observarlo. Ese tipo de rastro, más que una lista de herramientas, es lo que hace legible un perfil en estos temas.

• Adopción
• Human-in-the-loop
• Cultura de IA