Consultoría y transformación: impulsar la adopción de la IA sin ser experto técnico

Cuando una organización decide utilizar IA, la pregunta que llega a consultoría y a los equipos de transformación rara vez es técnica. Suena más bien así: por dónde empezar, sobre qué, con quién y cómo sabremos si funciona. Responderla no exige entrenar un modelo. Exige conectar un problema de negocio, una restricción organizativa y una capacidad tecnológica cuyos límites se comprenden.

Esta guía se dirige a perfiles de consultoría, transformación, gestión del cambio y análisis de negocio que acompañan estos proyectos sin ser ingenieros. No defiende que haya que convertirse en AI Engineer. Describe qué conviene entender, qué conviene preguntar y qué conviene organizar para que un proyecto de IA produzca algo más que una demostración lograda.

Empezar por un problema, no por una tecnología

Muchos proyectos arrancan con una intención formulada al revés: queremos IA en este ámbito. El papel de la consultoría es convertir esa intención en un problema observable, con un antes y un después que los equipos afectados puedan reconocer.

• ¿Qué trabajo se hace hoy en realidad, incluidos los pasos informales que nadie documenta?
• ¿Quién lo hace, con qué carga, qué experiencia y qué margen de criterio?
• ¿Qué resulta caro: el tiempo, la espera, la variabilidad de calidad, rehacer errores?
• ¿Qué decisiones se toman en ese proceso y cuándo dejan de ser reversibles?
• ¿Qué parte del volumen son excepciones fuera del caso nominal?
• ¿Qué ocurre cuando el resultado es erróneo: quién lo ve, quién lo corrige, quién responde?

Un problema que no puede describirse sin usar la palabra IA probablemente aún no es un problema: es un deseo de solución.

Convertir una ambición en un caso de uso utilizable

Un caso de uso utilizable se resume en unos pocos elementos explícitos. Mientras falten, las conversaciones con el equipo técnico siguen siendo vagas y las decisiones se toman por intuición.

1. 1

   Nombrar la tarea, no el dominio

   encuadre

   Ayudar a atención al cliente no es una tarea. Redactar un borrador de respuesta a partir del historial del cliente y de la base de conocimiento sí lo es: tiene entrada, salida y destinatario.

2. 2

   Describir la entrada disponible

   datos

   Qué información existe realmente, en qué formato, con qué calidad, con qué permisos de acceso y qué zonas sensibles. Una capacidad impresionante sobre datos que la organización no puede usar no sirve de nada.

3. 3

   Definir qué es un buen resultado

   calidad

   Quién juzga, con qué criterios y con ejemplos de salidas aceptables e inaceptables. Sin eso, la evaluación se reduce a una impresión compartida en una reunión.

4. 4

   Situar a la persona

   responsabilidad

   Qué propone el sistema, qué verifica alguien, qué puede salir sin revisión y qué no saldrá nunca sin ella en este contexto.

Preguntas útiles para los equipos técnicos

No hace falta saber construir un sistema para interrogarlo con utilidad. Unas pocas preguntas sacan a la luz las dependencias reales, y son legítimas viniendo de un perfil no técnico.

• ¿En qué fuentes se apoya la respuesta y qué pasa cuando la información no existe?
• ¿Cómo se reconoce una salida dudosa y qué está previsto en ese momento?
• ¿Qué habéis medido, sobre qué muestra, y ese conjunto de pruebas se parece al trabajo real?
• ¿Qué datos salen del perímetro de la organización y durante cuánto tiempo?
• ¿Qué se rompe si el volumen crece o si el proceso cambia dentro de seis meses?
• ¿Qué parte habrá que mantener y quién lo hará?

Una buena pregunta de encuadre no busca dejar en evidencia a nadie: hace visible una hipótesis implícita antes de que se convierta en una dependencia costosa.

Demostración, piloto y uso desplegable

Confundir estos tres estados es una de las causas más habituales de fracaso, porque el entusiasmo de una demostración se convierte en un compromiso de despliegue sin que se haya comprobado nada por el camino.

Un escenario ilustrativo

El escenario siguiente es ficticio: sirve únicamente para mostrar una secuencia de decisiones, no para describir a un cliente ni un resultado observado.

Una dirección jurídica quiere usar IA en los contratos con proveedores. El encuadre revela que el dolor real no es redactar, sino revisar cláusulas no estándar en contratos recibidos en PDF, a menudo a final de trimestre. El caso de uso pasa a ser: señalar desviaciones respecto a una biblioteca de cláusulas de referencia y presentarlas a un jurista, sin concluir nunca sobre el cumplimiento.

Ese desplazamiento cambia todo lo demás: la entrada queda identificada, el criterio de calidad pasa a ser que ninguna desviación relevante quede sin señalar, la decisión sigue siendo jurídica y el piloto puede ejecutarse sobre contratos ya tratados cuyo desenlace se conoce. La conversación con el equipo técnico deja de girar en torno a los modelos y pasa a hablar de exhaustividad, trazabilidad de fuentes y ergonomía de la revisión.

Organizar la responsabilidad humana y la adopción

Hacer explícita la responsabilidad

Un sistema probabilístico no asume responsabilidad. Conviene escribir quién verifica qué, en qué momento, con qué nivel de control según el riesgo y quién responde del resultado que sale al exterior. Ese documento es un entregable de consultoría en sí mismo, a menudo más útil que otra presentación de encuadre.

Acompañar a las personas usuarias en los límites

La formación más útil no trata de la interfaz, sino de las situaciones en las que el sistema no ayuda: casos fuera de alcance, información ausente, salidas verosímiles pero falsas. Quien sabe nombrar dos o tres de esas situaciones desarrolla una confianza calibrada, que es el objetivo real.

• Prever una vía de escalado cuando un resultado parece dudoso.
• Tratar los rodeos y atajos como información sobre el proceso, no como una falta.
• Observar lo que la gente hace de verdad más que lo que declara en un taller.
• Aceptar reducir el alcance de uso cuando la observación lo justifica.

Cuestionar sin pretender saber construir

La postura más sólida consiste en asumir la frontera: no diseñas el sistema, respondes de que lo que se construya resuelva un problema real en una organización capaz de sostenerlo. Eso exige entender el vocabulario, los órdenes de magnitud y las contrapartidas, no implementarlos.

Consultoría e ingeniería no se oponen: fracasan juntas cuando nadie conecta el trabajo real, la solución técnica y la responsabilidad de la decisión.

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