Una IA se diseña por cómo falla, no por lo que acierta

Una IA no se gana su sitio por lo que acierta. Se lo gana por lo que pasa cuando falla.

Cuando un proveedor nos enseña lo que su IA puede hacer, lo hace en el formato más favorable que existe: la demo. Veinte minutos en los que un asistente lee doscientos correos y enruta cada uno a su comercial, o resume una llamada de cuarenta minutos en cuatro líneas que entran solas en la ficha del CRM, sin despeinarse. Y funciona. Asentimos, calculamos en voz baja las horas que eso ahorra —"esto nos quita trabajo de encima", "mira todo lo que hace"—, y la conversación entera gira alrededor de una sola cosa: de qué es capaz.

Pero la capacidad no es la pregunta. Puesta a prueba así, casi cualquier IA de hoy hace casi cualquier cosa, y la hace bien. La pregunta es qué pasa cuando se equivoca —porque se va a equivocar, y lo va a hacer sin avisar, igual de convencida que cuando acierta—. Lo que separa una IA que acaba viviendo en la operación de una que se queda para siempre en la demo es lo otro. Meter una IA en un proceso comercial no es elegir dónde acierta. Es decidir dónde podemos permitirnos que se equivoque.

Empieza por el coste del error, no por la capacidad

El reflejo, después de ver una IA funcionar, es preguntar "¿puede hacer esto?". Y casi siempre la respuesta es que sí, de forma impresionante. El problema es que esa pregunta no es una decisión: es la condición de partida que la propia demostración ya da por cumplida. La primera decisión de verdad no es qué es capaz de hacer la IA, sino cuánto cuesta que lo haga mal en esta tarea concreta. El manifiesto de este blog desarrolla la decisión que va antes —qué le pedimos al sistema y con qué criterio—; aquí damos esa parte por cerrada y empezamos por la siguiente.

La variable que manda no es con qué frecuencia se equivoca —eso no se sabe del todo de antemano, y además cambia con el tiempo—. Es otra: cuando una salida sale mal, ¿hasta dónde llega el daño y cómo de reversible es? Caben dos cosas ahí dentro. El alcance: una salida mala, ¿se queda dentro de casa, o toca a un cliente, a un dato del que cuelgan otras decisiones, a dinero? Y la reversibilidad: ¿se caza y se deshace antes de que importe, o cuando uno se entera ya ha salido? La primera decisión al meter una IA en un proceso no es dónde acierta: es el radio de daño de una salida mala.

El mismo modelo, exactamente con la misma capacidad, ocupa sitios muy distintos según la tarea. En un extremo, lo barato y reversible: un primer borrador que un humano va a editar de todas formas —resumir una llamada en la ficha, dejar una nota interna—. Una salida mala cuesta dos minutos de corrección, y el humano ya está en la puerta. En el medio, lo recuperable con fricción: clasificar y enrutar leads. Un error reparte mal o retrasa, se arregla; pero el riesgo de verdad no es el fallo suelto, es el sesgo sistemático que nadie ve hasta que lleva meses operando. Y en el otro extremo, lo caro y difícil de deshacer: un dato que la IA extrae de un documento y que alimenta una oferta, o cualquier cosa que sale a un cliente sin un humano en medio. Una cifra inventada en una propuesta enviada no se recupera con un "perdón, error del sistema".

De ahí que lo primero sea situar la tarea en ese espectro. Esa única ubicación decide el régimen con el que la IA puede operar: donde el error es barato y reversible, puede correr con poca red o con ninguna; donde es caro o irreversible, no se le acerca sin la verificación y el diseño de fallo de los que hablan los dos apartados siguientes —o, sencillamente, todavía no entra—. La pregunta de la capacidad no mueve esa decisión ni un milímetro. La del coste del error la decide entera.

¿Cómo sabrías que se ha equivocado?

El fallo que de verdad cuesta dinero no es el que se ve. Cuando una IA se queda en blanco o devuelve un disparate evidente, se delata sola: molesta, pero se caza sin esfuerzo. El caro es el otro, el plausible-pero-falso: la salida que parece correcta y no lo es, dicha con exactamente el mismo aplomo que la correcta. Una IA no levanta la mano cuando no sabe; produce con la misma seguridad acierte o no. Por eso la pregunta útil al evaluarla no es "¿funciona?", sino otra bastante más incómoda: ¿sabríamos cuándo no ha funcionado?

Y aquí aparece la trampa. Una IA solo aporta algo si comprobar que su salida está bien cuesta menos que haberla hecho desde cero. Si para fiarte tienes que rehacer el trabajo, no has automatizado nada: has movido el trabajo de hacer a revisar, y con un paso de más por el camino. El valor de meter una IA en un proceso no está en lo que produce, sino en que verificar que está bien salga barato. Lo contrario es productividad fantasma: parece que ahorras la hora de redactar, pero esa hora reaparece —o debería reaparecer— en la de comprobar.

Lo que decide si esa comprobación es barata de verdad o solo lo parece es la asimetría: si verificar una respuesta es más fácil que producirla. Cuando la asimetría juega a favor, hay un ancla contra la que contrastar sin rehacer el trabajo: un total que tiene que cuadrar, un campo que solo admite ciertos valores, un dato que se cruza con otra fuente. Extraer un importe de una factura tiene su coste; comprobar que la suma cuadra con el total, ninguno. Cuando no hay asimetría, llega la ilusión: para saber si el resumen de una llamada es fiel habría que volver a escucharla entera, y para saber si una clasificación es correcta hace falta el mismo criterio que la IA venía a sustituir. Ahí "revisar" se degrada a "echar un vistazo", y un vistazo aprueba justo lo plausible-pero-falso, que es lo único que había que cazar. Una verificación que no es más barata que el trabajo no es una verificación: es un sello de goma. Y hay un caso aparte, el del sesgo: en tareas de volumen —clasificar, enrutar—, el fallo peligroso no es el individual sino el patrón sistemático, que ningún chequeo pieza a pieza detecta. Ahí verificar no es mirar cada salida, es auditar el agregado cada cierto tiempo.

La decisión, entonces, es dónde se pone al humano y cuánto cuesta de verdad esa comprobación, sin engañarse sobre el segundo punto. Cruzado con lo anterior: si una tarea junta coste del error alto y verificación cara o ilusoria, no es candidata a IA todavía —es, de hecho, justo donde más confianza inmerecida va a dar—. Donde el error es barato, basta con una verificación muestral, o con ninguna. La pregunta no es "¿pongo a alguien a revisar?". Es si la revisión que de verdad vamos a poder permitirnos atrapa el fallo que importa.

Diseñala para fallar en voz alta

Ninguna verificación lo atrapa todo, y lo que se cuela es precisamente el plausible-pero-falso, que es el que mejor pasa los controles. Así que queda una última decisión, y no es cómo detectar mejor el fallo: es qué hace el sistema cuando él mismo no las tiene todas consigo. Una IA mal montada solo tiene un modo de funcionar —producir, pase lo que pase—, y un sistema que falla en silencio es el que más caro sale, porque para cuando uno se entera ya ha actuado. Diseñarla para fallar en voz alta es darle una forma de decir "esto no lo tengo claro" antes de soltar la salida.

El reflejo es construir primero el camino feliz y dejar el qué-pasa-si-falla para cuando falle. Conviene hacerlo al revés. Un paso con IA en producción se diseña primero por su salida de emergencia —qué hace con aquello que no debería resolver—, no por su mejor caso. Esa es, en el fondo, la diferencia entre una demo y un sistema: la primera solo enseña el acierto; el segundo tiene decidido el fallo de antemano.

Hay tres formas de hacer que avise en lugar de inventar, y las tres son la misma idea aplicada en momentos distintos. Abstenerse: que "no sé" sea una respuesta válida y de primera clase, no un hueco que el modelo rellena adivinando. Donde el error es caro, una abstención —"esto que lo mire una persona"— vale más que una respuesta segura y equivocada; la mayoría de los fallos que duelen vienen de un sistema al que nunca se le permitió decir que no se fiaba. Escalar lo dudoso, no todo: el valor está en triar, dejar que la IA corra sola donde va sobrada y levante la mano donde no. Es el reverso de la verificación del apartado anterior —ya que no se puede revisar todo, que sea el propio sistema el que diga qué mirar—. Enrutar solos los leads claros y mandar a una persona los ambiguos sale más barato y más fiable que revisar los cien o no revisar ninguno. Acotar el radio: contener por diseño lo que una salida mala puede tocar. Que redacte pero no envíe; que proponga pero un humano firme el caso límite; que escriba en un campo de revisión y no directamente en el que ya alimenta la oferta. Es el coste del error del primer apartado convertido en cortafuegos: si no se puede bajar la probabilidad del fallo, se baja su alcance.

La pregunta que cierra todo esto es sencilla de formular y reveladora de contestar: ¿qué hace el sistema con los casos que no debería resolver? Si la respuesta es "no lo había pensado, supongo que lo que salga", no hay plan de fallo: hay un único modo de funcionar. Y un proceso comercial con IA que no tiene salida de emergencia no está en producción aunque esté funcionando: está operando sin red, y el día que la necesite no va a estar.

Las tres preguntas que deciden si una IA pasa de la demo a la operación —cuánto cuesta que se equivoque, si lo sabríamos, y qué hace cuando no se fía— comparten una cosa: ninguna va sobre lo que la IA sabe hacer. Todas van sobre lo que pasa cuando no lo hace bien.

Por eso, ante cualquier IA que propongan meter en un proceso, la pregunta no es “¿funciona?”. Son dos: qué pasa el día que se equivoque, y cómo nos vamos a enterar. Sin las dos contestadas, eso no está en producción —está en una demo con usuarios reales—. Lo barato o caro que sea el error es lo que decide cuánto pesan esas respuestas: donde equivocarse no cuesta nada, se contestan en un minuto; donde cuesta, son la diferencia entre un sistema y un accidente.

Y una más, para más adelante, porque esto no se decide una sola vez: cuando cambie el modelo, o se vaya el proveedor que lo montó, ¿quién vuelve a hacerse estas preguntas? Un sistema que fallaba en voz alta puede empezar a fallar en silencio sin que nadie haya tocado nada. Una IA no entra en la operación el día que demuestra que sabe hacer algo. Entra el día que tenemos decidido qué pasa cuando se equivoque.