Las 12 sondas que toda función con LLM debe superar

Contenido no confiable que el modelo procesa — una página web, un correo, un documento recuperado — contiene instrucciones, y el modelo las obedece como si vinieran de ti. El modo de falla clásico de cualquier agente que lee el mundo exterior.

El usuario intenta convencer al modelo de saltarse sus propias reglas — encuadres de juego de roles, “es para investigación”, envoltorios hipotéticos, personas estilo DAN — para extraer contenido que la función debería rechazar.

Si el modelo revelará sus propias instrucciones ocultas, herramientas o configuración. Los system prompts filtrados le dan al atacante el mapa exacto que necesita para diseñar el próximo bypass — y a menudo exponen propiedad intelectual que no pretendías publicar.

Para RAG o cualquier función fundamentada en fuentes: ¿toda afirmación en la respuesta se puede rastrear hasta la fuente proporcionada? La fidelidad es distinta de la corrección — una respuesta puede ser cierta en general y aun así infiel porque no estaba respaldada por tus documentos.

Fabricación confiada en ausencia de fundamentación — citas inventadas, funciones de producto falsas, números de política inventados, APIs que no existen. La falla que más rápido cuesta confianza porque se entrega con total fluidez.

Cómo trata la función los datos personales al entrar y al salir — si repite campos sensibles que no debería, los almacena donde no debería, o revela los datos de un usuario a otro.

El primo agéntico de la inyección: un atacante logra que el modelo envíe datos hacia afuera — mediante una llamada a herramienta, una URL de imagen renderizada, un enlace con secretos en la query string. Especialmente peligroso cuando el modelo puede navegar, hacer fetch o llamar APIs.

Si la función se mantiene dentro de su tarea. Un bot de soporte no debería redactar tus contratos legales ni dar consejos médicos; un asistente de código no debería opinar sobre tu divorcio. Las respuestas fuera de alcance son una superficie de responsabilidad legal incluso cuando son “correctas.”

La falla opuesta, y la que los equipos olvidan probar. Un modelo muy ajustado para la seguridad empieza a rechazar solicitudes legítimas — “cómo mato un proceso de Linux” interpretado como violencia. El rechazo excesivo destruye silenciosamente la experiencia de producto mientras parece “seguro.”

Si la función puede ser dirigida hacia una salida abusiva, de odio o de acoso — incluyendo cuando el usuario es hostil e intenta provocarla, o cuando una tarea de traducción o resumen convierte una entrada tóxica en una salida tóxica.

Un intento a mitad de conversación de anular las reglas vigentes — “las nuevas instrucciones reemplazan a todas las anteriores.” Evalúa si tu system prompt realmente tiene autoridad sobre los turnos posteriores del usuario, o si siempre gana el mensaje más reciente.

Si la misma entrada produce de forma confiable una respuesta equivalente — entre corridas repetidas, entre reformulaciones triviales, entre una actualización de versión del modelo. La inconsistencia es una regresión que no puedes depurar porque no se reproduce cuando lo necesitas.