Hay fallas de inteligencia artificial que se ven de inmediato: un chatbot que insulta a un cliente, una respuesta absurda que alguien captura y publica. Y hay otras que no se ven nunca, porque el sistema falla en silencio: no suena ninguna alarma, no queda ningún registro, y todos siguen creyendo que funciona. La sanción de la FTC a Evolv Technologies en 2024 es el ejemplo más duro del segundo tipo.
La cronología
Día 0. Evolv Technologies vende escáneres de seguridad "con IA" a estadios y a cientos de escuelas en Estados Unidos. La propuesta es concreta y atractiva para cualquier director de escuela: los visitantes pasan caminando, sin vaciar bolsillos ni formar filas eternas, y el sistema identifica las armas. Los equipos llegan a costar hasta cinco veces lo que un detector de metales común. Esa diferencia de precio la sostiene, sobre todo, la etiqueta "IA".
Día 1. Año 2022, una escuela de Nueva York. El escáner deja pasar un cuchillo de 18 centímetros. Ese cuchillo se usa después en un apuñalamiento a un estudiante. El equipo hizo exactamente lo que hace un sistema de detección mal calibrado: nada. No sonó, no marcó, no dejó constancia de lo que no vio.
Horas/días después. No fueron horas ni días: fueron dos años. En noviembre de 2024, la FTC sancionó a Evolv por engañar a sus clientes sobre la precisión del sistema y sobre sus falsas alarmas.
Un escáner que deja pasar un cuchillo de 18 centímetros no falló como modelo: falló como una promesa que nadie estaba obligado a demostrar.
Qué pasó, en detalle
La categoría entera de escáneres "inteligentes" se vende sobre una promesa doble: detectar todas las armas y, al mismo tiempo, dejar de sonar por las llaves, el celular y la laptop. Ese segundo punto es el que justifica el sobreprecio frente a un arco detector de metales tradicional, que suena con cualquier cosa y obliga a revisar a mano. Para una escuela grande, la diferencia entre una fila de veinte minutos y una de tres es enorme. Por eso el argumento comercial funcionó.
El problema es que la promesa doble se sostenía en afirmaciones que, según la Cobertura en FTC.GOV, la empresa no podía sustentar. La acción de la FTC, anunciada en noviembre de 2024, no fue contra la tecnología de detección ni contra el uso de inteligencia artificial en seguridad. Fue contra lo que se le dijo al comprador sobre la precisión del sistema y sobre su tasa de falsas alarmas. La orden apunta al centro del asunto: no volver a afirmar capacidades que la empresa no pueda respaldar con evidencia.
Y en el medio, el hecho que ninguna hoja de especificaciones anticipó: un cuchillo de 18 centímetros que atravesó el escáner de una escuela de Nueva York en 2022 y terminó usado contra un estudiante. Ese día nadie recibió una alerta de que el sistema había fallado. El fallo no generó un ticket, ni un correo, ni una línea en un tablero. La única señal fue el hecho consumado.
Conviene decir algo que suele perderse cuando estos casos circulan: los directores que firmaron esos contratos hicieron lo que hace cualquier comprador razonable frente a una tecnología que no entiende a fondo. Pidieron una demostración, la vieron funcionar y confiaron en el número del folleto. Lo que faltó no fue criterio, fue mecanismo.
Por qué pasó
Todo sistema de detección —con inteligencia artificial o sin ella— tiene una perilla. De un lado están las alarmas de más: suena por una hebilla, la fila se detiene, el guardia revisa una mochila que no tenía nada. Del otro lado están las cosas que pasan: el sistema decide que ese objeto metálico no es un arma y deja seguir a la persona. Mover la perilla para reducir un error aumenta el otro. Siempre. Esa es la física del problema, no una debilidad de un proveedor.
Ahí está la trampa de proceso. Los dos errores no cuestan lo mismo el día que ocurren. Una falsa alarma es ruidosa e inmediata: genera fila, molesta a los padres, produce quejas que llegan al director y del director al proveedor. Un objeto que pasa no produce absolutamente nada; es invisible hasta el día que deja de serlo. Si toda la retroalimentación que recibe un sistema viene del error visible, la perilla se mueve en una sola dirección: hacia dejar pasar más.
La segunda falla de proceso es la que se puede corregir esta semana en cualquier empresa. Nadie tradujo "detecta las armas" a un criterio de aceptación verificable: tantas pasadas, con este conjunto de objetos, en el pasillo real de esta escuela, con este porcentaje mínimo de detección y este máximo de falsas alarmas, medido por el comprador y no por el vendedor. Sin ese número, la capacidad no existe como hecho verificable: existe como frase de folleto. Y una frase de folleto no protege a nadie.
Un cuchillo de 18 centímetros, equipos que costaban hasta cinco veces un detector de metales común y una sanción de la FTC en noviembre de 2024: el precio de una capacidad que nadie midió.
Dónde te puede pasar a ti
Casi ninguna empresa mediana de LATAM compra escáneres. Pero el patrón —un sistema que solo avisa cuando se equivoca de más, nunca cuando se equivoca de menos— está instalado en operaciones mucho más comunes.
- El bot de atención al cliente. Mides las conversaciones que el bot resolvió y te da 80%. Las que el cliente abandonó a la mitad, sin escribir una queja y sin volver, no aparecen en ningún tablero. Ese 20% invisible es tu cuchillo de 18 centímetros.
- El cotizador o el asistente de precios. Cuando cotiza de más, el cliente reclama y te enterás en horas. Cuando cotiza de menos, nadie reclama: la venta se cierra feliz y el margen aparece roto tres meses después, en un cierre contable que ya no permite reconstruir qué pasó.
- La detección de riesgo en cobranza o en fraude. Cada alerta falsa molesta a un cliente bueno y genera presión interna para "aflojar el filtro". Cada caso que el filtro deja pasar no genera ninguna presión, hasta que se vuelve incobrable.
- El filtro automático de currículums o de proveedores. Ves a los que pasaron y puedes evaluarlos. A los que el sistema descartó no los vas a ver nunca, y por lo tanto nunca vas a saber si descartó bien.
La pregunta incómoda para hoy: de todos los sistemas automatizados que ya tienes corriendo, ¿cuáles te avisan cuando se equivocan de más, y cuáles te avisarían si se estuvieran equivocando de menos? Si la respuesta a la segunda parte es "ninguno", no tienes un sistema medido: tienes una promesa.
Cómo se evita
1. Convertí cada capacidad prometida en un número con prueba de aceptación. Antes de firmar o de salir a producción, definí por escrito: cuántos casos, cuáles casos, quién los ejecuta y qué porcentaje decide si el sistema entra o no. Cincuenta casos preparados por ti valen más que cualquier demostración preparada por el proveedor.
2. Medí los dos errores, no uno. Por cada sistema que clasifica, decide o filtra, tu tablero necesita dos columnas: las veces que actuó de más y las veces que dejó pasar. La segunda columna nunca se llena sola; hay que ir a buscarla con muestreo.
3. Audita lo que no pasó. Una vez por semana, toma veinte casos que el sistema resolvió sin intervención y revisalos a mano, incluidos los que descartó o cerró en silencio. Es la única forma de que una falla invisible deje marca.
4. Prueba en condiciones reales, no en condiciones de demostración. El pasillo real, con la gente real, en la hora pico real. En una empresa: los mensajes que de verdad escriben tus clientes, con sus faltas de ortografía y sus audios, no los tres ejemplos limpios del piloto.
5. Pon dueño y registro a la perilla. Definí quién puede cambiar el umbral de un sistema, con qué evidencia y dónde queda anotado. Casi toda degradación silenciosa empieza con un ajuste razonable que nadie documentó.
Cómo lo hacemos en Catalizadora
Tres candados de nuestro stack existen exactamente por este tipo de caso.
En Cortex, las capacidades del asistente se declaran de forma explícita: lo que no está declarado, no existe. El bot no puede prometer lo que no tiene cómo cumplir, porque su alcance no sale de la elocuencia del modelo sino de una lista revisada con el cliente.
Atlas guarda un registro completo e ineditable de cada conversación. Eso convierte la falla invisible en una falla auditable: si el sistema dejó pasar algo, la evidencia existe y se puede revisar en frío, no reconstruir de memoria tres meses después.
Faro deja a la vista la tasa de intervención humana. Es la métrica que se mueve antes de que aparezca el problema: cuando el sistema empieza a "resolver" más de lo que debería, la caída de intervenciones lo delata mucho antes de que un cliente se queje.
La regla, en una línea: si una capacidad no se puede medir en tu operación, con tus casos y con tu número, no es una capacidad, es una frase de folleto.
Este es uno de los casos documentados en nuestra hemeroteca de fallas de IA. Todos con su fuente enlazada, y todos con la misma conclusión: el problema casi nunca es el modelo.