Una distribuidora mediana asiste a una feria del sector y ve la demostración de una plataforma conversacional: un asistente que atiende consultas de clientes con una naturalidad asombrosa. Tres meses después la plataforma está comprada, integrada al sitio web y respondiendo preguntas. Mientras tanto, el verdadero cuello de botella de la empresa sigue intacto: las cotizaciones tardan días porque las excepciones de precios viven en la cabeza del gerente comercial, que las resuelve una por una por WhatsApp.
El caso es de mi libro «Empleado IA», y lo más incómodo no es el error. Es que nadie hizo nada estúpido: cada paso individual parecía razonable. La demo era buena de verdad. La plataforma funciona. El asistente algo aporta. El problema estuvo en el orden: la solución llegó antes que el diagnóstico, y la empresa automatizó la parte más vistosa de su operación dejando sin tocar la parte que sangraba.
Si estás evaluando comprar software de IA, este artículo es la vacuna contra ese orden.
El error que no explota
Conviene no cerrar la historia de la distribuidora con un final limpio, porque las de verdad no lo tienen. Esa empresa sigue pagando la licencia. Cancelar el asistente se siente como admitir un error de tres meses y de un presupuesto ya gastado, así que nadie lo cancela. Las cotizaciones siguen tardando días. Lo más probable es que dentro de un año el asistente siga ahí, ni indispensable ni retirado, y que el cuello de botella siga siendo el mismo.
El costo real de comprar la demo no es un desastre visible. Es una empresa que gastó su presupuesto de transformación y su credibilidad interna en la parte del problema que no dolía. Cuando alguien proponga la siguiente iniciativa de IA, la respuesta será «ya probamos con eso». El dinero se recupera; la credibilidad interna para transformar, mucho más lento.
Y hay una señal tardía que confirma el diagnóstico: la organización empieza a servir a la herramienta que compró para que la sirviera. Integraciones que nadie pidió, procesos paralelos que duplican trabajo, personas trabajando alrededor del sistema en lugar de ser liberadas por él. El libro lo describe como un huésped exigente: hay que alimentarlo con datos, justificarlo en las reuniones, defenderlo del escepticismo.
Por qué una demo engaña a gente inteligente
El capítulo 3 del libro abre con una comparación que todo el que ha contratado personal reconoce. Un candidato llega a la entrevista perfectamente preparado: conoce la historia de la empresa, responde con seguridad, resuelve con elegancia el caso que le presentan. Semanas después, ya dentro del puesto, necesita instrucciones para cada excepción, pierde contexto entre conversaciones y no sabe cuándo detenerse a pedir ayuda. Nada de lo que hizo en la entrevista era falso. Simplemente confundimos una actuación puntual con desempeño recurrente.
La entrevista y la demo comparten la misma asimetría, y nombrarla explica por qué ambas engañan a gente inteligente: «en la entrevista brillan las respuestas; en la operación protegen las dudas». Quien arma una demo selecciona ejemplos limpios, proporciona contexto completo y muestra una ejecución breve donde todo sale bien. La operación real dura todos los días: recibe información incompleta, encuentra excepciones, compite por recursos, afecta clientes y produce consecuencias.
Y si el resultado de la demo es bueno, nosotros hacemos el resto del trabajo: proyectamos sobre el sistema continuidad, criterio ante excepciones y respuesta bajo presión que nadie demostró. La fluidez de la conversación funciona como aval de capacidades que jamás estuvieron en la pantalla.
La pregunta que sí decide
De esa asimetría sale el cambio de pregunta que ordena toda la evaluación. La pregunta equivocada es «¿viste lo que logró?». La que decide es otra: ¿puede sostener ese resultado cuando cambien las condiciones, y podemos administrarlo cuando no lo logre?
Fijate que la pregunta tiene dos mitades y la segunda es la menos obvia. No solo importa si el sistema sostiene el desempeño: importa qué pasa el día que no lo sostiene. El libro es tajante en este punto: un recurso que produce una respuesta convincente en vez de escalar una duda es más peligroso que uno menos brillante pero mejor gobernado, porque el error del primero llega al cliente vestido de seguridad.
Un buen ocupante de un puesto no es quien nunca encuentra una excepción. Es quien sabe actuar dentro de límites cuando la excepción llega.
Las preguntas para el vendor
Con ese criterio, la reunión comercial cambia de guion. En vez de pedir que la demo impresione más, interrogá el puesto que el sistema tendría que ocupar. Estas preguntas salen directamente de los instrumentos del libro:
Sobre la continuidad. ¿Qué pasa entre ejecuciones? ¿El sistema mantiene identidad e historial, o cada sesión arranca de cero? ¿Qué recuerda, quién puede corregir lo que recuerda y cómo se borra lo que debe borrarse?
Sobre las excepciones. ¿Qué hace ante un caso que no entiende: lo escala, lo improvisa o lo entierra? ¿A quién se lo entrega y por qué canal? Pedí ver una demo del fracaso: cómo se ve el sistema cuando no sabe. El vendor que solo puede mostrarte éxitos te está mostrando la mitad que menos importa.
Sobre la autoridad. ¿Qué puede aprobar, modificar, comprometer o gastar, y dónde se configuran esos umbrales? ¿En números o en adjetivos? ¿Qué no puede hacer jamás, por diseño, sin importar cómo se le pida?
Sobre la observabilidad. ¿Podemos reconstruir lo que hizo la semana pasada: acciones, datos consultados, herramientas invocadas, costos? ¿O solo tenemos la palabra del sistema sobre sí mismo?
Sobre el control. ¿Quién puede suspenderlo, en cuánto tiempo, y qué pasa con el trabajo en curso cuando se suspende? ¿Existe un procedimiento para devolverle el trabajo a una persona?
Notá lo que estas preguntas tienen en común: ninguna se responde mirando la fluidez de la conversación. Todas se responden mirando el gobierno del sistema, que es exactamente lo que la demo no muestra. Son, en el fondo, una versión comercial del test que desarrollo en las nueve propiedades de un Empleado IA.
El orden correcto: el diagnóstico antes que la compra
Queda la defensa de fondo, la que evita llegar a la feria en estado de compra. El libro la formula como un ejercicio de resta: tomá la iniciativa que estás considerando y eliminá el nombre de la herramienta. Describí solo el resultado que la organización necesita, la frecuencia con que debe producirse, las consecuencias de hacerlo mal y la persona que responde por él. Leelo sin la marca.
Si el caso pierde sentido cuando desaparece el producto, si lo único que quedaba en pie era «es que esta plataforma es impresionante», estabas defendiendo una tecnología, no resolviendo un problema. La distribuidora del caso habría descubierto en esa media hora lo que le costó tres meses y un presupuesto: que su problema no era atender consultas del sitio web sino sacar las excepciones de precios de la cabeza del gerente comercial.
Una necesidad bien entendida puede admitir distintas soluciones. Una tecnología comprada antes de entender la necesidad suele obligar a deformar el problema para que encaje en ella. Por eso la selección de herramienta debe ser la última decisión, no la primera, y por eso el punto de partida no es un catálogo de plataformas sino el mapa de tu propia operación: la fuerza laboral invisible primero, el diseño del puesto después.
La velocidad de la IA no cambió la naturaleza de este error, que existía mucho antes de las demos conversacionales. Cambió su precio, porque ahora lo equivocado se construye más rápido que nunca.
Construir rápido lo equivocado no es progreso. Es desperdicio acelerado.
Preguntas frecuentes
Por una asimetría estructural: la demo dura minutos, ocurre en condiciones favorables y muestra el camino donde todo sale bien, mientras que la operación real dura todos los días, recibe información incompleta, encuentra excepciones y produce consecuencias. Quien arma la demo selecciona ejemplos limpios y proporciona contexto completo; y si el resultado es bueno, el comprador hace el resto del trabajo, proyectando sobre el sistema continuidad y criterio que nadie demostró. Es la misma trampa del candidato brillante en la entrevista que luego no sabe cuándo pedir ayuda: nada era falso, pero se confundió una actuación puntual con desempeño recurrente.
Preguntas de gobierno, no de capacidad. ¿El sistema mantiene identidad e historial entre ejecuciones, y quién gobierna esa memoria? ¿Qué hace con una excepción que no entiende: la escala, la improvisa o la entierra, y a quién se la entrega? ¿Qué puede aprobar o gastar, con umbrales en números y no en adjetivos, y qué no puede hacer jamás? ¿Se puede reconstruir lo que hizo la semana pasada, con datos, herramientas y costos? ¿Quién puede suspenderlo y cómo se devuelve el trabajo a una persona? Y pedí explícitamente la demo del fracaso: cómo se comporta el sistema cuando no sabe. Ninguna de estas respuestas está en la fluidez de la conversación.
Casi nunca un desastre visible. En el caso de la distribuidora del libro, el asistente comprado en la feria quedó atendiendo consultas (algo aporta, así que nadie lo cancela) mientras el cuello de botella real, las cotizaciones que tardan días, siguió intacto. El costo real fue triple: el presupuesto de transformación gastado en la parte del problema que no dolía, la credibilidad interna quemada para la siguiente iniciativa de IA, y un sistema convertido en huésped exigente al que hay que alimentar con datos y defender en las reuniones. Las decisiones malas rara vez explotan. Casi siempre se quedan.
Invirtiendo el orden: diagnóstico antes que compra. Primero hacé el ejercicio de resta: describí la iniciativa sin el nombre de la herramienta, solo con el resultado necesario, su frecuencia, las consecuencias de hacerlo mal y la persona que responde. Si el caso no se sostiene sin la marca, no hay problema real que resolver todavía. Segundo, cambiá la pregunta de evaluación: no «¿viste lo que logró?» sino «¿puede sostenerlo cuando cambien las condiciones, y podemos administrarlo cuando no lo logre?». Tercero, interrogá el gobierno del sistema (memoria, excepciones, autoridad, observabilidad, suspensión) en vez de su elocuencia. La herramienta se elige de último; el trabajo se diseña primero.
Antes de evaluar cualquier plataforma, hacé el inventario de tu fuerza laboral invisible y aprendé a distinguir qué es un Empleado IA de lo que solo lo aparenta.
¿Querés el método completo? Leé Empleado IA. Para consultoría ejecutiva en IA o conferencias y talleres.
Profundizar
¿Querés llevar tu equipo al siguiente cinturón?
Reservá una llamada de descubrimiento o explorá el libro completo.