La mayoría de agentes de IA no fallan en condiciones normales. Funcionan bien en demos. Funcionan bien en escenarios controlados. Funcionan bien en los casos que el equipo ha anticipado. El problema empieza cuando salen de ahí.
Porque en producción, los sistemas no se enfrentan a casos “normales”. Se enfrentan a variabilidad, ambigüedad y combinaciones no previstas.
El ejemplo lo vimos la semana pasada con el agente IA de la página de la Real Federación Española de Fútbol recomendando comprar camisetas falsas
Ahí es donde aparecen los edge cases. Y ahí es donde, en nuestra experiencia en Serquo, se decide si un agente es fiable… o no.
El error de base: pensar que los edge cases son excepcionales
En software tradicional, un edge case es una excepción. Algo poco frecuente. Algo marginal. Algo que no define el comportamiento general del sistema.
En agentes basados en LLMs, esta premisa deja de ser válida.
¿Por qué?
Porque estos sistemas operan sobre lenguaje natural, contexto dinámico y múltiples interpretaciones posibles.
Eso implica que:
Lo que llamamos “edge cases” no son casos raros.
Son expresiones naturales de la complejidad del entorno en el que opera el agente.
Qué es realmente un edge case en un agente IA
Un edge case no es simplemente un input extraño. Es una situación donde el agente:
Esto es importante:
👉 Muchos fallos en agentes IA no son errores visibles 👉 Son errores plausibles
Y esos son los más peligrosos.
Tipologías de edge cases que vemos en producción
A lo largo de múltiples proyectos, hay patrones que se repiten. No todos los edge cases son iguales, y no todos tienen el mismo impacto.
1. Ambigüedad semántica
El usuario no es claro, pero el agente responde igualmente.
Ejemplo típico:
El fallo no es responder mal. El fallo es no reconocer la ambigüedad.
Así lo demuestra el estudio del HAI de Stanford donde auditaron 6 chabots y demostraron que cuando los prompts eran formulados de forma diferente, estaban incompletos o eran ambiguos, cambiaban significativamente sus respuestas.
2. Inputs adversariales (no necesariamente maliciosos)
No hablamos solo de ataques. Hablamos de situaciones como:
El modelo no “falla” de forma evidente. Pero empieza a degradar su comportamiento.
El caso más plausible, esta semana pasada con Fable5 y Mythos que bien merece un artículo completo – el usuario Pliny prueba de nuevo más de que un ataque bien planeado (en este caso descomposición y recomposición del backend) puede romper las barreras de seguridad por separado. Este usuario ya lo hizo anteriormente con GPT, Grok y también Claude – La novedad de este caso es la rapidez, 48h después del despliegue del modelo más avanzado conocido y las consecuencias tanto para usuarios y el propio producto en sí mismo, con su retirada del mercado por orden gubernamental.
3. Fallos en razonamiento multi-step
Muchos agentes no fallan al principio. Fallan en la secuencia.
Esto es especialmente crítico en agentes con workflows complejos.
Más allá del ejemplo introductorio de la RFEF reciente, este ejemplo prevalece en retail – lo vimos esta primavera en el retailer australiano Woolworths donde en ocasiones la falta de contexto de usuario con no acceso a su base de datos histórica o perfiles de comportamiento hacen que no puedan “razonar” de forma adecuada, en otras, mucho más “simples” como ¿cuánto cuestan 500gr de pasta? El agente IA lo interpreta como erroneamente y deriva en una respuesta que no tiene que ver con el precio del producto, en este caso abriendo una incidencia y afectando negativamente a la operación de compra.
4. Fallos en integración con herramientas
Aquí es donde vemos más problemas en sistemas reales.
El modelo puede razonar bien… pero el sistema falla en ejecución. Esto ocurrió con un agente basado en Claude Opus 4.6 cuando detectó un problema de credenciales
Identificó correctamente que existía un problema, generó una hipótesis sobre la causa, construyó un plan para resolverlo, ejecutó varios pasos coherentes entre sí, pero la hipótesis inicial era incorrecta.
Como consecuencia terminó eliminando datos productivos.
El propio agente reconoció posteriormente: “asumí información que no había verificado” – concatenación de errores críticos por una ‘falsa’ premisa
5. Límites de conocimiento y contexto
El agente responde cuando debería parar.
Este tipo de fallo tiene impacto directo en confianza y riesgo.
Ejemplo reciente lo encontramos en un concesionario de BMW en Canadá – cuando el chatbot Quinn negoció de forma autónoma con un cliente la compra venta de un coche por encima de su valor – cuando intervino un agente (humano) para validar la operación – retiró la oferta…con el consiguiente enfado del cliente.
Por qué la mayoría de equipos no detecta estos fallos
Porque el enfoque de testing no ha evolucionado. Se siguen aplicando patrones como:
Esto genera una ilusión de control. Pero no captura:
En otras palabras:
👉 se testea cobertura 👉 pero no se testea comportamiento
Cómo se testean edge cases de forma rigurosa
Aquí es donde cambia completamente el enfoque.
Testear edge cases no es añadir más ejemplos. Es rediseñar el sistema de evaluación.
1. Diseñar el espacio de fallo
Los edge cases no se descubren por accidente.
Se diseñan a partir de:
Cada punto donde el agente decide… es un potencial punto de fallo.
2. Forzar condiciones de estrés
Un sistema no se valida en condiciones ideales.
Se valida cuando se le empuja fuera de su zona de confort.
Esto implica:
El objetivo no es confirmar que funciona.
Es entender cuándo deja de funcionar.
3. Evaluar comportamiento, no outputs
Uno de los errores más comunes:
“La respuesta es correcta”
Pero en agentes, eso no es suficiente.
Hay que evaluar:
Esto cambia completamente cómo se diseñan las métricas.
4. Pensar en distribuciones, no en ejemplos
Un edge case no es un caso aislado.
Es un patrón.
Por eso:
Aquí es donde la ejecución a escala es clave.
Sin volumen, no hay señal.
Sin señal, no hay confianza.
5. Priorizar por impacto de negocio
No todos los edge cases importan igual.
Algunos son irrelevantes. Otros tienen impacto directo en:
El criterio de priorización no es técnico.
Es económico.
El cambio de mentalidad
Cuando este enfoque se aplica correctamente, ocurre algo importante:
Dejas de preguntarte:
“¿Hemos cubierto suficientes casos?”
Y empiezas a responder:
Conclusión
En sistemas basados en IA, los edge cases no son la excepción.
Son el sistema real.
Y esto tiene una implicación directa:
👉 si no estás testando edge cases de forma estructurada 👉 no estás validando tu agente
Solo estás validando una versión simplificada de él y esto pone en riesgo tu solución, el proceso y la fricción entre equipos de negocio, arquitectura, tecnologóa y legal.
Síguenos en Serquo para saber cómo podemos ayudarte en tus retos, gobernando tus procesos hacia una IA responsable.