Responsable de implantación de IA — tareas, una a una

Decidir qué probar primero

La entrada que manda no es conocer las herramientas, es conocer esta empresa: qué paso es de verdad el cuello de botella, a quién le mueven los números si cambia, y quién se va a enfadar. Esa información en su mayor parte no está escrita en ninguna parte, así que no se puede recuperar — hay que recogerla andando por ahí y preguntando.

Difícil de automatizar no es lo mismo que duradero. Todo este puesto existe porque hay una transición en marcha; cuando las herramientas se vuelvan corrientes como se volvieron las hojas de cálculo, elegir qué automatizar pasará a ser parte de dirigir una función en vez de una función propia. La seguridad de aquí es la seguridad de un andamio.

Comprobarlo sobre el trabajo real de esta empresa

Las herramientas de evaluación se han vuelto de verdad buenas y buena parte de la puntuación puede correr sola. Lo que no se automatiza es decidir qué cuenta como correcto para esta empresa, que es un criterio de negocio disfrazado de técnico — dos empresas que hacen la misma tarea pueden tener umbrales distintos para el mismo error.

Una buena evaluación te dice que la herramienta funciona sobre los casos que se te ocurrió reunir. No dice nada sobre los casos que no se le ocurrieron a nadie, y ahí es donde viven los fallos caros — así que aprobar es una razón para empezar a vigilar, no para dejar de hacerlo.

Enchufarlo a lo que ya hay

Escribir el código de integración es una de las cosas que estas herramientas hacen mejor, así que construir salió mucho más barato. Saber cuál de los cuatro sistemas tiene la versión buena de un registro, y qué campo miente en silencio, no — ese conocimiento vive en gente que lleva años en la empresa.

Que integrar sea barato es la razón de que se multipliquen los pilotos y de que la mayoría siga siendo pilotos. Poder conectar una herramienta en una tarde no establece que nadie haya cambiado cómo trabaja, y las dos cosas se reportan como el mismo hito.

Decidir qué puede hacer sin supervisión

Esto es un reparto de responsabilidad, no una tarea de configuración. Decidir que una herramienta puede comprometer a la empresa con un precio, una fecha o una disculpa es una decisión sobre quién responde por ello — y un sistema no puede autorizarse a sí mismo su propia autoridad.

Que los límites sean trabajo humano no significa que lleguen a escribirse. En la mayoría de las empresas a nadie le han dado esta tarea, así que la frontera se resuelve por defecto — por quien configuró la herramienta — y ese valor por defecto es invisible hasta que sale algo que no debería haber salido.

Conseguir que la gente lo use de verdad

La adopción falla por razones que la gente no pone en una encuesta: hace que alguien parezca más lento, quita la parte del trabajo que le gustaba, está un clic más lejos de donde ya están. Averiguar eso exige confianza, y actuar sobre ello exige autoridad para cambiar el proceso.

Es la tarea con más probabilidad de recortarse, porque es lenta y no produce ninguna pieza que enseñar. Una empresa que compra las herramientas y se la salta consigue el coste de las licencias y el piloto, y reporta las dos cosas como progreso.

Estar ahí cuando se equivoca

Toda marcha atrás pública que registra este sitio tiene esta forma: el fallo técnico era recuperable y el hueco de responsabilidad no. Alguien tiene que responder por el resultado delante de un cliente o de un regulador, y responder es lo único que no puede delegarse en el sistema que lo causó.

Cargar con la culpa no es lo mismo que tener la autoridad. Este puesto responde a menudo por decisiones que no puede anular — el presupuesto, el proveedor, el plazo los fijaron en otra parte — y esa combinación es la razón más habitual por la que la gente lo deja.