Tener razón no te da permiso para entrar.

Dentro del expediente

Detectar algo extraño en una herramienta no convierte su infraestructura en tu laboratorio. Y sospechar una vulnerabilidad no convierte una acusación pública en un hecho demostrado.

Mi regla editorial sería clara. Crítica dura a prácticas verificables, sin acceder a datos ajenos ni convertir una publicación en instrucciones para atacar a un tercero. La intención de mejorar el sector no sustituye el permiso.

Antes de probar

Trabajaría en sistemas propios, en entornos expresamente autorizados o dentro de programas con un alcance definido que cubra la prueba concreta. Guardaría ese alcance con sus condiciones. Si una acción no está cubierta, no la trataría como permitida por defecto.

Preferiría datos inventados y una demostración mínima suficiente. Si aparece información real inesperada, pararía. Después buscaría el canal adecuado para notificarlo sin difundir nada.

Antes de escribir

Separaría los hechos observados de las hipótesis. Una respuesta incorrecta de un asistente no demuestra por sí sola una brecha. Una captura de pantalla tampoco explica la configuración ni el alcance real de lo que ocurrió.

Documentaría la versión y el entorno de la observación, con sus límites. No redactaría un titular sobre «todos los clientes expuestos» si lo único comprobado es una anomalía en un caso de prueba. Cuando faltan datos, el texto tiene que decirlo.

Antes de publicar

Consideraría una comunicación privada al responsable y una oportunidad razonable de comprobar y corregir, minimizando los detalles que faciliten la explotación. La forma y los plazos deben ajustarse al caso y a las obligaciones aplicables; este texto no crea una autorización ni una política legal universal.

Revisaría también el conflicto de interés. Si desarrollo herramientas que compiten con las que analizo, el lector debe saberlo. Eso no invalida automáticamente la crítica, pero esconderlo empeora la confianza.

Cuando el fallo es tuyo, reconstruir sin excusas

La otra mitad de este oficio llega el día que el problema aparece en tu propia casa. Ahí la tentación es doble, minimizar mientras no se sabe nada, o culpar a la herramienta porque resulta cómodo. Las dos salidas dejan al despacho sin la única cosa que después importa, que es un relato defendible de lo que pasó.

Yo empezaría por separar lo confirmado de lo que sigue en el aire, y lo dejaría escrito con esa etiqueta. Después reconstruiría la secuencia. Qué versión estaba en uso, qué entrada se trató como fiable, qué acciones pudo ejecutar el sistema por su cuenta y qué permisos tenía cada actor en ese momento. Sin esa reconstrucción, cualquier medida posterior es una intuición con presupuesto.

Las preguntas que dejan un incidente cerrado de verdad

Qué control falló y cuál habría limitado el daño si hubiera existido. Qué evidencia se conservó y cuál se perdió, que suele ser la parte incómoda. Y qué habría hecho falta para detectarlo antes, no para haberlo evitado en un mundo perfecto.

Conviene resistirse a la conclusión elegante. Un informe que termina en «se ha reforzado la supervisión» sin decir qué se puede hacer ahora que antes no se podía hacer, describe una intención. Cuando hay datos personales de por medio, además, la valoración deja de ser interna y entra en el terreno de obligaciones concretas que conviene mirar con la guía del organismo competente delante Fuente primaria ↗.

La atribución también tiene límites

Decir «lo hizo la IA» es tan pobre como decir «fue un error humano». Un sistema con agencia amplia y controles débiles reparte la responsabilidad entre quien lo configuró y quien no puso límites a lo que podía ejecutar, y ese patrón está descrito con detalle en la literatura de seguridad de agentes Fuente primaria ↗.

Escribir la atribución con sus límites tiene una ventaja práctica, porque obliga a mirar el permiso concreto que hizo posible el daño. Que casi siempre estaba ahí desde el principio, concedido por comodidad y jamás revisado después.

La rectificación forma parte del trabajo

Conservaría una nota de cambios cuando aparezca evidencia nueva. Corregir una afirmación distingue a quien observa de quien necesita tener siempre razón, y no supone perder ninguna pelea. Y aplica igual a lo que publicas sobre otros que a lo que cuentas sobre lo tuyo.

La crítica puede ser brutal. La forma de conseguir la prueba, no.

Lo que me preguntan cuando cierro el portátil.

¿Se puede probar por tu cuenta la seguridad de una herramienta de IA?

En sistemas propios o en entornos con autorización expresa, sí. En infraestructura ajena, no, porque detectar algo raro no convierte el servicio de otro en un laboratorio. Si no hay un alcance escrito que cubra la prueba concreta, conviene tratarla como no permitida.

¿Qué hago si encuentro un fallo en un producto que uso?

Documentar la versión y el entorno, junto con lo observado, usando datos inventados si es posible. Después, comunicarlo en privado al responsable y darle margen razonable para comprobarlo. Publicar el detalle explotable antes de eso convierte un aviso en un problema para terceros.

¿Qué debería contener una reconstrucción de incidente?

Qué se sabe y qué sigue sin confirmarse, qué permisos existían, qué entrada se trató como fiable y qué acción pudo ejecutarse. Y sobre todo, qué evidencia falta. Un relato que no distingue lo comprobado de lo supuesto no sirve para decidir nada.

El expediente detrás del artículo.

Principios de protección de datos ↗Agencia Española de Protección de Datos · Guía
Orientación institucionalLLM06:2025 · Agencia excesiva ↗OWASP GenAI Security Project · 2025
Guía técnica de riesgos

Fuentes consultadas el 10 de septiembre de 2026. Las recomendaciones y ejemplos son elaboración editorial y no se atribuyen íntegramente a estas fuentes. Comprueba versión y ámbito antes de aplicar una norma.

Divulgación general. Ninguna herramienta de esta web certifica la revisión, seguridad o conformidad de un proceso.