IA aplicada · Septiembre 2026
Lo que de verdad pienso de los productos con IA.
Opiniones de alguien que opera sistemas automáticos en producción y recibe la llamada cuando fallan.
Construyo con estos sistemas todos los días y opero una flota sin supervisión para negocios pequeños. Ese punto de vista produce opiniones que no encajan en ninguno de los dos bandos disponibles, así que aquí van sin adorno.
El modelo ya es la parte fácil.
La capacidad dejó de ser la restricción para casi todos los productos. Casi cualquier cosa que un negocio pequeño necesita de una función con IA ya está al alcance de un modelo general competente.
Lo que no está resuelto, y nadie puede comprarlo, son cuatro preguntas:
- Qué hace el sistema cuando no está seguro.
- A quién le pasa el caso.
- Qué tiene prohibido decir.
- Cómo se entera alguien cuando sale mal.
Eso es trabajo de producto, no de machine learning. Los equipos que lo tratan como un problema de modelo publican demos. Los que lo tratan como un problema de diseño de comportamiento publican cosas que la gente sigue usando.
“Correcto” es una decisión que alguien tiene que tomar.
Toda función con IA asume una definición de buen comportamiento. Si no la escribiste tú, el modelo eligió una por ti a partir de la forma general de internet.
Ese valor por defecto es amable, complaciente y seguro de sí mismo. Tres propiedades activamente peligrosas en un producto donde equivocarse le cuesta dinero o tiempo a una persona.
En un sistema que construí, casi todo el trabajo fue definir las negativas: qué cuenta como pregunta ya contestada, qué cuenta como alguien diciendo que no, qué no debe volver a mencionar jamás. Las respuestas eran lo directo. Los límites eran el producto.
La confianza es una propiedad de interfaz, y la publicamos mal.
Lo que me parece objetable en casi todos los productos con IA no es que se equivoquen. Toda herramienta se equivoca.
Es que suenan igual de fluidos cuando aciertan y cuando no. Un experto humano señala su incertidumbre todo el tiempo, con matices, tono y pausas, y nosotros calibramos contra esas señales sin darnos cuenta.
Quita esa señal y habrás construido algo que le pasa el riesgo al usuario mientras suena como si le estuviera haciendo un favor.
Un sistema que dice “no estoy seguro, por esto, y quien sabría es esta persona” es mejor producto que uno que acierta un poco más seguido y nunca titubea.
La autonomía se gana por etapas, no se concede en el lanzamiento.
No creo que a la automatización haya que darle las llaves el primer día. Y no creo que eso sea prudencia: creo que es mejor experiencia.
- Déjala observar.
- Déjala proponer en un sitio seguro.
- Déjala hacer una parte acotada del trabajo, con alguien cerca.
- Sólo entonces, déjala actuar sola.
Y aun así, deja un camino claro de vuelta a una persona.
Los usuarios le dan a un sistema automático mucha más responsabilidad de la que uno esperaría, siempre que primero les haya mostrado su trabajo. Lo que no perdonan es enterarse de golpe de cuánta autoridad ya tenía.
Casi todo el monitoreo de IA es decorado.
Esta es la lección que más me costó. Tenía tableros llenos de verde sobre sistemas que no producían nada.
Trabajos que escribían archivos vacíos. Una compuerta que ninguna salida podía aprobar. Un monitor anotando un cero seguro de sí mismo donde la respuesta honesta era “no hay dato”. Todas las verificaciones pasaban, y todas medían si el proceso corrió, no si pasó algo.
Así que sostengo dos reglas. Un control que no puedes hacer fallar a propósito es decorado, no verificación. Y publicado no es funcionando: una persona real obteniendo un resultado real del otro lado sí lo es, y nada por debajo cuenta, por muy verde que esté la tubería.
Dónde aterrizo
No me preocupa que la IA sea demasiado capaz para los productos en que la metemos. Me preocupa que sea demasiado segura, demasiado entusiasta y demasiado mal supervisada dentro de productos donde alguien le está confiando algo que le importa. Todas esas son decisiones de diseño. Podemos tomarlas mejor.