Los cuatro jinetes del DELETE
Hay errores de código que rompen una pantalla, y errores de datos que rompen una empresa. La diferencia: los primeros se ven y se arreglan; los segundos a veces no tienen arreglo. Los cuatro patrones de este OA han borrado bases de datos reales de startups, agencias y tiendas —todos construidos con IA, todos precedidos de un «¿qué puede pasar?». Ninguno requiere maldad: solo confianza sin protocolo.
[La anatomía del desastre]
Esta actividad interactiva ('Explicacion visual') requiere el motor completo de Lumbre. El contenido estatico se muestra arriba; para la experiencia interactiva, visita la version online de este objeto.
Por qué la IA los comete (y por qué no es su culpa)
| Error | Qué le pasó al modelo | Qué faltó del lado humano |
|---|---|---|
| DELETE sin WHERE | la petición fue «limpiar los datos de prueba»; el modelo priorizó la acción sobre la conservación | criterio de listo con límite explícito: «solo los 12 registros de la tabla _test, muéstrame cuáles antes» |
| Correr sin copia | el script que pidió «ejecutar» era suyo y parecía correcto | el protocolo no delegable: copia ANTES de ejecutar (M11), sin excepción por urgencia |
| Fix en producción | no hay noción de entorno: «la base» es una para el modelo | exigir entorno de prueba con copia de datos y solo aplicar ahí el fix verificado |
| Domino | ve la tabla, no ve quién la lee: las dependencias están en código que no abrió | preguntar antes de borrar «quién lee esto» es pregunta de humano: la respuesta cambia la definición de «huérfano» |
El protocolo anti-letal (pégalo en tu maestro)
PROTOCOLO PARA CUALQUIER OPERACION QUE PUEDA BORRAR O MODIFICAR DATOS EN MASIVA:\n\n1. ENUMERAR: muestra las filas afectadas con su COUNT y una muestra de 10. Si el numero\n no coincide exactamente con mi expectativa, PARO aqui.\n2. RESPALDO: copia de la base (o de las tablas afectadas) verificada antes de ejecutar.\n Sin evidencia de copia restaurable, no hay ejecucion. Sin excepciones por urgencia.\n3. ENTORNO: se ensaya en copia con datos reales. La produccion solo ve el paso 5.\n4. REVERSA: cada paso destructive tiene su paso de vuelta escrito. Si no lo hay, el\n paso se divide hasta que lo haya o se jubila en vez de borrarse (M17-OA03).\n5. EN PRODUCCION: ejecuta UN paso, detente, muestra verificacion, espera mi ok.\n\nY antes de cualquier "limpieza": ¿quien lee estos datos? Reporta dependencias.\nLo historico nunca es basura: es sentencia de los reportes viejos.Para reforzar
Migraciones, respaldos y evitar el SQL injection
El respaldo como ritual previo a cualquier cambio estructural: la misma cultura del paso 2.
Prueba
La IA te entrega un script «para limpiar los 12 registros de prueba». La primera revisión es: ¿aplica el protocolo? ¿Qué verificas ANTES de dejarlo correr?
Borrar registros «huérfanos» —los que no tienen relación activa— es siempre seguro porque nada los usa.
Detecta la confianza letal
Cinco escenas de alumnos con la IA y sus bases. Señala la que termina en pérdida de datos irrecuperable:
- Pidió el borrado masivo con el protocolo: enumerar, copia, ensayo, reversa, paso a paso.
- Antes de borrar, preguntó quién lee la tabla y descubrió tres reportes que la usaban.
- Ejecutó el «fix rápido» de la IA directo en producción «porque es solo un UPDATE chiquito».
- Hizo la limpieza en la copia de la base, verificó, y luego planificó la de producción.
Identifica la linea con error.
Escribe el protocolo anti-letal como sección fija de tu documento maestro, y aplica su pregunta de dependencias hoy a un dato que «ya no sirve» en tu proyecto (o en uno ficticio): ¿quién lo lee? Si la respuesta es «no sé», acabas de encontrar por qué el protocolo existe.