Todos los miedos que escucho sobre la IA se reducen a una sola pregunta, y no es técnica: ¿quién firma?

En la misma reunión, el mismo cliente me dice dos cosas que se contradicen. Primero: “necesitamos automatizar esto, vamos tarde”. Diez minutos después, cuando le muestro que sí se puede: “pero si esto se equivoca, nos matan”.

No son dos objeciones. Es una sola, mal formulada.

Los dos miedos llegan juntos

El patrón se repite reunión tras reunión. Llegan con la decisión ya tomada, saben que tienen que estar usando IA este año. Lo que no tienen es la frase que viene después: para qué.

Y cuando les muestras algo que efectivamente funciona, la sala se pone incómoda.

Ahí aparecen los dos miedos, siempre en este orden:

• Miedo al reemplazo: si la máquina hace esto, ¿yo qué hago acá?
• Miedo al error: si la máquina se equivoca, ¿quién se da cuenta?

El primero dice que la IA funciona demasiado bien. El segundo dice que no funciona lo suficiente. Salen de la misma boca, en la misma conversación, separados por un café.

La reacción típica de la industria es tratar esto como resistencia al cambio. Un problema de change management que se arregla con un mail de Recursos Humanos y dos capacitaciones.

Es una pregunta de diseño que nadie contestó, no resistencia al cambio.

He mostrado flujos que convierten dos días de trabajo manual en cuatro minutos y la reacción siempre es la misma. Un silencio raro, la sala entera masticando la pregunta que nadie quiere hacer en voz alta.

La IA no firma

En cualquier proceso que tenga consecuencias, alguien firma. No hablo de una firma legal necesariamente. Hablo de que existe una persona que responde cuando el resultado está mal y que tiene la autoridad para frenar la máquina.

El modelo no firma.

Puede proponer, clasificar, redactar, resumir y decidir dentro del rango que tú le definas. Lo que no puede es dar la cara. No lo puedes sentar frente a un cliente enojado ni hacerlo rendir cuentas en un comité. La tarea se transfiere. La responsabilidad no.

Proceso manual → Persona decide → Persona firma
Proceso con IA → Modelo propone → ¿...?

Ese casillero vacío es donde mueren los proyectos. Los que he visto caerse no murieron por el modelo ni porque les faltara un fine-tuning. Murieron porque nadie definió qué pasaba cuando el sistema se equivocara.

Cuando esa pregunta se contesta temprano, el miedo al error se desinfla solo. El fantasma pasa a ser un requisito del sistema.

El presupuesto de error

El miedo al error trae una trampa escondida: compara a la IA contra un cero que no existe.

Nadie mide cuánto se equivoca hoy el proceso hecho a mano. Se asume perfecto porque el error humano está repartido, se corrige de callado y nunca aparece en un reporte. Pero está ahí. Facturas mal tipeadas, un dato que alguien copió con un dígito de más y nadie notó hasta el cierre de mes.

En SRE existe el concepto de error budget: cuánta falla puede tolerar un sistema antes de que el negocio lo sienta. No se persigue el 100% de disponibilidad porque es carísimo y nadie lo necesita. Se define cuánto se puede fallar y se administra ese margen.

Trae el mismo lente a la automatización:

• ¿Cuántas veces al mes se equivoca hoy este proceso, hecho por personas?
• ¿Cuánto cuesta cada error, en plata y en confianza?
• ¿Cuánto tarda alguien en detectarlo hoy?

Si no puedes responder eso del proceso manual, la discusión sobre la precisión del modelo es puro ruido. Estás comparando un número medido contra una fantasía.

El punto no es si el modelo la caga se equivoca. El punto es si tu proceso está diseñado para absorber ese error cuando ocurra, porque hoy también ocurre.

El mandato vacío

La otra mitad del problema no tiene nada que ver con el miedo. Es que no saben para qué.

Cuando le pregunto a un cliente qué proceso le duele y me responde “queremos IA”, no tengo un proyecto. Tengo un presupuesto buscando dónde morir.

Es el mismo error de diseñar para un millón de usuarios que no existen, con otro disfraz. Una solución saliendo a buscar un problema, con la ventaja política de que este año la palabra suena bien en una junta de accionistas.

Para elegir el primer caso de uso hay cuatro filtros, y tienen que pasar los cuatro:

• Volumen alto: si el proceso corre dos veces al mes, no muevas un dedo. El ahorro no paga la mantención.
• Riesgo acotado: que el peor escenario sea “hay que rehacerlo”, no “perdimos la licitación”.
• Error verificable rápido: alguien tiene que poder mirar el output y decir “esto está mal” sin abrir tres sistemas.
• Dueño con nombre: una persona que firma el resultado y tiene autoridad para apagar el flujo.

Aplica los cuatro filtros y siempre te va a quedar el mismo tipo de proceso: el aburrido. Clasificar correos, cuadrar documentos, extraer datos de PDFs que llegan en catorce formatos distintos, redactar la primera versión de algo que alguien iba a revisar de todas formas.

Nada de eso queda bien en una presentación al directorio. Todo eso ahorra plata desde la primera semana. Es la innovación aburrida otra vez, ahora con modelos.

El dueño cambia de silla

Queda el otro miedo, el del reemplazo.

Ese no se arregla con comunicados. Un mail que promete que nadie va a perder su trabajo no cambia nada de lo que la persona está viendo con sus propios ojos. El miedo cambia con una decisión concreta: quién es el dueño del proceso automatizado.

Si el que hacía la pega a mano es el que ahora define las reglas, revisa las excepciones, aprueba el output y decide cuándo el flujo se apaga, no lo reemplazaste. Le entregaste una herramienta y le subiste el techo.

Si la automatización bajó por arriba, sin avisar, y la persona se enteró el día que su tarea desapareció del sistema, no importa lo que diga el mail. Ya sabe lo que pasó.

He visto el mismo flujo, técnicamente idéntico, adoptado con entusiasmo en un equipo y saboteado de callado en otro. La diferencia no estuvo en el modelo ni en la interfaz. Estuvo en quién lo construyó con quién.

El trabajo no desaparece, se corre hacia arriba. De ejecutar la tarea a definir el criterio, revisar lo raro y responder por el resultado. No todos quieren ese trabajo. Eso se conversa de frente, con nombre y fecha, en vez de esconderlo detrás de una diapositiva que dice “potenciamos a nuestros equipos”.

La parte fácil siempre fue escribir el código. Ahora es más fácil todavía. Lo que la IA no te resuelve es el criterio para saber qué merecía existir.

Firma o no empieces

Cuando un cliente me dice que quiere IA, la conversación arranca por el proceso que duele, por cuánto error tolera hoy y por quién va a poner el nombre cuando el sistema se equivoque. El modelo viene después.

Si esas tres respuestas existen, la implementación es la parte simple. Si no existen, ninguna arquitectura te salva.

El modelo propone. Alguien firma. Ese alguien es el trabajo.