1. Introducción: Entender Las Limitaciones
Los modelos de lenguaje grandes (LLMs) son herramientas poderosas. Pero son estadísticas disfrazadas de inteligencia. No "entienden" como lo hace un humano. Predicen la palabra más probable basada en patrones de entrenamiento.
Esto genera 6 limitaciones críticas que afectan directamente cuándo (y cuándo no) puedes confiar en lo que un LLM produce.
Este artículo no te vende que "la IA es peligrosa". Te enseña a ver dónde falla y cómo construir defensas prácticas alrededor de esos fallos.
2. Alucinaciones: Cuando la IA Inventa Hechos
¿Qué es?
El LLM genera información que parece real, está bien escrita y es coherente, pero no existe. No la inventó a propósito. Solo predijo las palabras que "sonaban correctas" sin verificar si eran verdaderas.
Ejemplo real
Respuesta del LLM: "El método `validateEmail()` toma un string de email y retorna un boolean. Si es válido, devuelve true. Si no, false. También verifica MX records y dominio."
Cómo Mitigarlo
- Verifica siempre la fuente. Si es código, trata de ejecutarlo. Si es un hecho, búscalo en documentación oficial.
- Pide referencias. Pregunta: "¿De dónde sacaste esto?" Un LLM honesto dirá "No tengo una fuente verificada".
- Usa RAG (Retrieval-Augmented Generation). Dale al LLM acceso a documentación oficial en tiempo real. Si no está en esa documentación, no puede inventarlo.
- Establece límites claros. Si preguntas sobre algo fuera de su conocimiento, que diga "No sé" en lugar de adivinar.
Patrón defensivo
3. Sesgos: Prejuicios en Los Datos de Entrenamiento
¿Qué es?
Si los datos con los que entrenaron al LLM contenían sesgos (raciales, de género, económicos, etc.), el modelo los aprenderá y reproduceará. Una pregunta aparentemente neutral puede generar respuestas que reflejan esos prejuicios.
Ejemplo real
Resultado: El modelo genera principalmente nombres masculinos, con una proporción desproporcionada de nombres anglófonos.
Cómo Mitigarlo
- Audita outputs generados. Si el LLM genera listas, clasificaciones o recomendaciones, verifica si hay patrones discriminatorios.
- Usa prompts inclusivos. Pregunta: "Genera 5 nombres de personas de diferentes orígenes, géneros y backgrounds".
- Implementa validación estadística. Para features críticas (hiring, credit scoring, etc.), mide disparidad de impacto. ¿El modelo favorece a un grupo sobre otro?
- Diversifica tus datos internos. Si alimentas el LLM con datos propios (RAG), asegúrate de que sean representativos.
Patrón defensivo
4. Inconsistencia: Respuestas Contradictorias
¿Qué es?
Haces la misma pregunta dos veces y obtienes respuestas que se contradicen. O el modelo toma una decisión hoy que contradice su propia lógica de ayer.
Ejemplo real
Cómo Mitigarlo
- No confíes en una sola respuesta. Para decisiones críticas, haz la pregunta 2-3 veces (en sesiones diferentes si es posible) y verifica consistencia.
- Establece reglas explícitas. Si hay un patrón correcto que el modelo debe seguir, docúmentalo en el prompt: "Siempre sigue la guía de estilo X".
- Usa temperatura baja para tareas determinísticas. Si necesitas consistencia (código, análisis), reduce temperature a 0-0.3. Esto hace al modelo más predecible.
- Cachea decisiones críticas. La primera respuesta coherente debería ser "la verdad" para tu aplicación. No vuelvas a preguntar lo mismo esperando una respuesta diferente.
Patrón defensivo
5. Plagio Involuntario: Reproducción Sin Cita
¿Qué es?
El LLM fue entrenado con millones de documentos. Si un pasaje aparece suficientemente similar a su entrenamiento (especialmente si era famoso o fue usado mucho), puede reproducirlo casi verbatim sin citar.
Ejemplo real
Output: [párrafos que coinciden casi exactamente con un artículo famoso de Martin Fowler, sin cita]
Cómo Mitigarlo
- Usa herramientas de plagio. Copilot, ChatGPT, etc. generan contenido para publicar. Si es contenido de marca, pasalo por un detector de plagio (Turnitin, Grammarly, etc.).
- Diversifica fuentes. Si pides al LLM que resuma X tema, pídele que lo haga desde múltiples perspectivas o que cite sus fuentes.
- Cita siempre. Si el contenido fue generado por IA, decláralo: "Generado con ayuda de [modelo] en [fecha]".
- Reescribe y parafrasea. El output del LLM es un punto de partida, no el producto final. Añade tu voz, reorganiza, cuestiona.
Patrón defensivo
6. Falta de Razonamiento Lógico
¿Qué es?
Los LLMs predicen la siguiente palabra basándose en estadística, no en lógica. Esto significa que tareas que requieren razonamiento profundo (matemáticas complejas, lógica formal, cadenas de inferencia) a menudo fallan.
Ejemplo real
Respuesta típica del LLM: "No necesariamente, depende de los valores específicos."
Cómo Mitigarlo
- No uses LLMs para lógica pura. Para cálculos, algoritmos o demostraciones formales, usa herramientas determinísticas (Python, lenguajes lógicos).
- Pide pasos intermedios. Chain-of-Thought (CoT) ayuda. Pregunta: "Explica tu razonamiento paso a paso" o "Muéstrame cómo llegaste a esa respuesta".
- Valida outputs programáticamente. Si el LLM genera código, ejecútalo. Si genera una fórmula, pruébala con casos conocidos.
- Combina enfoques. Usa IA para creatividad y síntesis. Usa programación para lógica. Lo mejor de ambos mundos.
Patrón defensivo
7. Opacidad: La Caja Negra
¿Qué es?
Ni siquiera los desarrolladores de OpenAI, Anthropic o Google pueden explicar exactamente por qué su modelo generó una respuesta específica. Es una caja negra. Millones de parámetros, arquitecturas complejas, y black box predictions.
Por Qué Importa
Si algo falla (error grave, sesgo detectado, información falsa), no puedes depurar. No puedes decir "arreglemos el parámetro X". Solo puedes intentar cambiar el prompt.
Cómo Convivir Con Esto
- Asume que es una caja negra. No esperes transparencia. Diseña alrededor de eso.
- Log everything. Guarda prompts, respuestas, contexto y resultados. Si hay un problema, puedes retroceder y entender el patrón.
- Usa modelos interpretables cuando sea posible. Para features críticas, considera modelos más pequeños y transparentes en lugar de megamodelos.
- Implementa auditoría externa. Equipos humanos independientes revisan outputs del modelo regularmente buscando patrones de error.
- Documenta límites claros. "Este modelo se usa para X. No debe usarse para Y porque es una caja negra".
Patrón defensivo
8. Framework Defensivo Integral
No es "use IA responsablemente". Es:
Asume Lo Peor
Valida Output
Documenta Límites
Implementa Guardrails
Audita Regularmente
Comunica Transparencia
9. Checklist de Validación Antes de Producción
✅ Regla de Oro
10. Recomendaciones Especiales para CLI Users
Si trabajas principalmente desde terminal sin ver el frontend constantemente, corres riesgos únicos. No ves el output en tiempo real. Confías más en lo que dice la terminal. Los fallos pueden ser más críticos.
A. Alucinaciones — La Mayor Amenaza en CLI
Es fácil ejecutar código alucinado sin verificar primero. No hay UI para "revisar antes de publicar".
# PATRÓN DEFENSIVO: Revisa antes de ejecutar
claude "Genera un script que limpia logs viejos"
# → Pides que genere código
cat /tmp/cleanup.sh
# → Revisas ANTES de ejecutar
bash -n /tmp/cleanup.sh
# → Validas sintaxis sin ejecutar
bash /tmp/cleanup.sh
# → Finalmente ejecutas
Regla: NUNCA ejecutes directamente sin revisar con `cat` primero.
B. Inconsistencia — Cachea Decisiones Críticas
Corrés Claude en dos sesiones diferentes y obtienes respuestas inconsistentes. La solución: una vez que generas algo correcto, guárdalo.
# Solución: Mantén un CLAUDE.md con reglas vinculantes
cat > CLAUDE.md << 'EOF'
## Code Style (BINDING)
- Use snake_case for variables
- 2-space indentation in YAML
- Always validate input before processing
- Error messages: "ERROR: [what] [how to fix]"
EOF
# Una vez que Claude genera algo correcto, guárdalo:
cp /tmp/generate-uuid.py lib/generate-uuid.py
# No vuelvas a pedir lo mismo, reutiliza
C. Opacidad — Logguea Todo
Si algo falla sin logs, no puedes debuggear. Logging exhaustivo es tu único salvavidas cuando todo es una caja negra.
# Patrón: Logging defensivo
mkdir -p ~/.claude/history
echo "$(date): $PROMPT" >> ~/.claude/history/prompts.log
# Antes de ejecutar, logguea qué esperas:
cat > /tmp/execute.log << 'EOF'
[$(date)]
COMMAND: $generated_script
EXPECTED: Should create backup at /backups/db-$(date).sql
VALIDATION: Check file size > 1MB
EOF
# Después de ejecutar:
if command_success; then
echo "✓ SUCCESS" >> /tmp/execute.log
else
echo "✗ FAILED: $?" >> /tmp/execute.log
fi
D. No Uses Claude para Lógica Pura
Si generas un cálculo sin verificar, ejecutas y das números errados a tu equipo. Valida siempre con datos de prueba.
# MAL: Ejecutar sin verificar
claude "Calculate 95th percentile" | bash
# BIEN: Verificar primero
claude "Generate Python script to calculate 95th percentile" > analyze.py
# Test con datos conocidos:
python analyze.py << 'EOF'
[1,2,3,4,5,6,7,8,9,10]
EOF
# ✓ Debería dar ~9.5
# Recién entonces, datos reales:
python analyze.py < production_data.txt
E. Pre-Execution Checklist (Obligatorio)
Antes de ejecutar CUALQUIER código generado:
Si alguno es "No": Pídele a Claude nuevamente o debuggea primero.
F. Wrapper Script Defensivo
Considera crear un wrapper que refuerce buenas prácticas:
#!/bin/bash
# File: ~/.local/bin/claude-safe
# Usa: claude-safe "tu prompt aquí"
PROMPT="$@"
TEMP="/tmp/claude-$(date +%s).txt"
claude "$PROMPT" > "$TEMP"
# Si es destructivo, pide confirmación
if grep -qE "(rm|truncate|drop|delete)" "$TEMP"; then
echo "⚠️ DESTRUCTIVE OP DETECTED"
read -p "Proceed? (yes/no): " ok
[[ "$ok" == "yes" ]] || exit 1
fi
# Log everything
echo "[$(date)] PROMPT: $PROMPT" >> ~/.claude/audit.log
echo "[$(date)] OUTPUT:" >> ~/.claude/audit.log
cat "$TEMP" >> ~/.claude/audit.log
# Revisa antes de ejecutar
less "$TEMP"
G. Las 3 Cosas Más Importantes
Nunca ejecutes sin revisar
Logguea todo
Valida con datos de prueba
💡 Final
11. Cómo Afectan en el Área del Testing
El testing es donde las limitaciones de los LLMs son más críticas. No es solo que generen código. Es que generan criterios de validación, casos de prueba, y estrategias que afectan directamente la calidad del producto.
A. Alucinaciones en Test Case Generation
El LLM genera test cases que parecen válidos pero prueban comportamientos que no existen o que no son críticos.
Ejemplo real: Performance Testing
Output del LLM: Script k6 que simula 10,000 usuarios concurrentes con piense time de 2 segundos entre requests.
Cómo mitigarlo en Testing:
- Define criterios explícitamente. No pidas "test cases de checkout". Pide: "Test cases para validar que checkout completa en menos de 2s con 50 usuarios concurrentes, considerando pago fallido en 5% de transacciones".
- Valida contra requisitos. Antes de ejecutar un test, verifica que mapee directamente a un requisito funcional o SLA documentado.
- Ejecuta en paralelo con manual testing. No confíes solo en lo que genera Claude. Corre tus propios casos en paralelo las primeras veces.
B. Sesgos en Criterios de Aceptación
El LLM puede generar criterios de aceptación que favorecen ciertos escenarios y discriminan otros sin que te des cuenta.
Ejemplo real: E2E Testing
Output: Tests solo con emails simples (john@example.com). No contempla: subdominios (user+tag@example.co.uk), caracteres especiales, o pruebas de accesibilidad.
Cómo mitigarlo en Testing:
- Pide casos edge case explícitamente. "Incluye test cases para: emails con dominio + (gmail), caracteres acentuados, contraseñas con emojis, intentos de SQL injection".
- Diversifica inputs en tests de datos. No uses solo happy path. Test con datos reales: caracteres unicode, valores null, strings vacías, números límite.
- Audita cobertura por grupo. Si generas test data con nombres, verifica que no haya sesgo de género/origen (ej: todos masculinos, todos anglófonos).
C. Inconsistencia en Test Data y Fixtures
El LLM genera test data que varía entre sesiones. Un test pasa hoy, falla mañana, aunque no cambió el código.
Ejemplo real: Data-Driven Testing
Resultado: Test expectations no son reproducibles.
Cómo mitigarlo en Testing:
- Guarda test data en archivos versionados. No pidas a Claude que genere datos cada vez. Genera una vez, commitea, reutiliza.
- Usa seeds explícitos. Si usas generadores (Faker, Factory Bot), fija la seed: `faker.seed(42)`.
- Documenta baseline. "Test X espera P95 < 250ms porque fue validado contra datos reales del 2026-04-01".
D. Falta de Razonamiento Lógico en Cobertura
El LLM puede generar test cases sin entender qué combinación de estados es imposible o redundante.
Ejemplo real: State Machine Testing
LLM genera test: "Orden en estado completed → cancelarla". Pero lógicamente, si un orden está completado, no se puede cancelar.
Cómo mitigarlo en Testing:
- Mapea estados explícitamente. Dale al LLM una matriz de transiciones válidas antes de pedir tests.
- Pide tests de "no debe permitir". No solo happy path. Prompt: "Genera 10 test cases de transiciones INVÁLIDAS".
- Valida reglas de negocio programáticamente. El LLM genera tests, pero tu suite de testing valida que respetan las reglas.
E. Opacidad en Test Automation Frameworks
El LLM genera un script de Selenium/Playwright que "funciona" pero no sabes por qué. Si falla, no puedes debuggear.
Ejemplo real: UI Automation
Test pasa en tu máquina. En CI/CD falla porque el DOM es diferente.
Cómo mitigarlo en Testing:
- Generá selectores, pero valida con el DOM real. Pedir al LLM que genere XPath, pero ejecuta un `document.evaluate()` para confirmar que existe.
- Logguea cada acción. Test que falla sin logs es indebuggeable. Agrega: `console.log("Clicking: " + selector)` antes de cada click.
- Usa Page Object Model. No dejes que Claude genere selectores dispersos. Define un POM, y pedí que genere tests que lo usan.
F. Plagio Involuntario en Test Frameworks
El LLM copia patrones de testing frameworks famosos sin citar. Esto puede traer problemas de licencia si usas código que reprodujo sin permiso.
Cómo mitigarlo en Testing:
- Documenta origen de test helpers. Si Claude generó un helper, documenta: "Generated with Claude, based on Jest patterns".
- Cita frameworks. Tu test suite usa Playwright, k6, pytest, etc. Decláralo en tu README.
G. Checklist de Validación Para Testing
Antes de usar test cases/scripts generados por IA:
Si alguno es "No": Corrige antes de mergear.
H. La Regla de Oro para Testing con IA
"Un test generado por IA que pasó una vez no es un test válido."
✅ Best Practice en Testing + IA