Una política de uso aceptable de la IA es un documento interno que define qué pueden y qué no pueden hacer los empleados con sistemas de inteligencia artificial: quién decide, con qué datos, sobre qué procesos y bajo qué supervisión. No es una declaración ética. Es el documento operativo que responde a tres preguntas que tu equipo se hace cada día: ¿puedo subir este dato a ChatGPT?, ¿puedo conectar este agente IA al Drive corporativo?, ¿puedo dejar que un sistema automatizado decida si aprueba o rechaza esta solicitud?

El núcleo mínimo: 5 secciones y un sistema semáforo

Después de leer veintitantas políticas reales —desde la de la AEPD hasta las de Iberdrola, Prisa o Técnicas Reunidas— hay cinco secciones que aparecen en todas las que funcionan: objetivo y alcance, clasificación de uso (sistema semáforo), reglas generales, régimen de incumplimiento, marco normativo. El núcleo entra en una sola página. La plantilla que acompaña este artículo trae 17 escenarios concretos clasificados en verde, amarillo y rojo, alineados con NIST AI RMF, ISO/IEC 42001 y EU AI Act.

Tres reglas para construir el sistema semáforo

Primero: cada categoría se define por escenario, no por herramienta. La misma herramienta puede estar en verde, ámbar o rojo según los datos que maneje. Segundo: el ámbar tiene que tener un responsable con nombre y un SLA. "Requiere aprobación" sin decir quién la da en cuánto tiempo es lo mismo que no tener proceso. Tercero: el rojo se nombra explícitamente. "No se puede usar IA para evaluar candidatos sin intervención humana en la decisión final" es concreto, verificable y sancionable. "Usos que vulneren la normativa" no lo es.

Los 6 errores que veo cuando reviso una política IA ajena

De las políticas que he leído este semestre, aparecen estos seis errores con regularidad de manual: confundir principios con reglas, listar herramientas en lugar de criterios, no diferenciar uso individual del corporativo, silencio sobre los agentes IA autónomos, olvidarse del shadow AI que ya está dentro, y aprobación una vez con olvido. Si tu política tiene tres o más, está rota.

Cómo desplegarla en 30 días

Semana 1: mapa del uso real (logs + encuesta anónima). Semana 2: borrador con input de los cuatro perfiles. Semana 3: validación cruzada uno a uno, no en comité. Semana 4: aprobación, comunicación y formación de 15 minutos por equipo. Si el día treinta no tienes la política publicada y el 70% del personal formado, el problema no es la política. Es la organización.

La pregunta para tu próximo comité: ¿cuántas herramientas de IA tienes ahora mismo en uso real, y cuántas pasaron por tu proceso de evaluación de proveedor? Si las dos cifras no coinciden —y no van a coincidir— ya sabes cuál es la primera línea de tu inventario.

Leer el artículo completo en enriquemaza.com

El equipo de Halcyon hizo la ingeniería inversa y publicó el hallazgo: el binario regenera localmente un nuevo par de claves RSA en cada ejecución, cifra los archivos con esa clave y descarta inmediatamente la privada. No hay clave maestra, no hay servidor C2 que la custodie, no hay forma de recuperar nada. Halcyon atribuye con confianza moderada el desarrollo del malware a tooling asistido por IA: un error de criptografía elemental que solo se comete cuando nadie sabía lo que estaba pidiendo, y nadie revisó lo que el modelo entregó.

Y ahí está el punto. El vibe coding —construir software describiéndolo a un agente IA, sin escribir prácticamente código— no es peligroso porque genere código malo. El código humano también lo es. Es peligroso porque rompe a la vez las tres capas que históricamente contenían el riesgo: la velocidad supera la revisión, la ignorancia elimina el juicio y la autonomía cierra el ciclo sin humano en el loop. El triángulo mortal.

Por qué el modelo AppSec clásico ya no aplica

Durante quince años el modelo era predecible: el desarrollador escribía, otro revisaba, los tests pasaban y el pipeline desplegaba. Tres filtros en serie. El vibe coding no respeta ninguno. Plataformas como Lovable, Base44, Replit, Netlify o Cursor en modo agente permiten que alguien sin formación técnica describa una aplicación y la tenga desplegada en minutos. RedAccess escaneó internet a principios de mayo de 2026 y encontró aproximadamente 380.000 aplicaciones vibe-coded públicamente accesibles. Alrededor de 5.000 filtraban datos sensibles: historiales médicos, estrategias comerciales, conversaciones internas con clientes.

Vértice 1: velocidad

Los desarrolladores que usan asistentes IA producen commits a 3-4 veces la tasa de sus pares sin IA, pero introducen hallazgos de seguridad a 10 veces esa tasa (Apiiro). La Cloud Security Alliance cuenta los CVEs atribuidos a herramientas IA: 6 en enero, 15 en febrero, 35 en marzo. Solo marzo superó la suma de todo 2025. Mientras tanto, el 62% de los profesionales senior de seguridad declara no poder mantener el ritmo, y el 66% pasa más del 50% de su tiempo en validación manual.

Vértice 2: ignorancia

Una parte importante de quien usa vibe coding no detectaría una vulnerabilidad si la tuviera delante. Moltbook lo ilustró en febrero: 1,5M tokens API, 35K emails, 4.060 mensajes privados expuestos por una clave pública Supabase en el bundle del cliente. El fundador declaró no haber escrito una sola línea de código. Lovable / Khan: 16 vulnerabilidades, 18.697 registros expuestos en una sola app, UC Berkeley, UC Davis y K-12 incluidos. El 78% de los CISOs señala la exposición de secretos como riesgo número uno del coding IA.

Vértice 3: autonomía

Microsoft publicó el 7 de mayo de 2026 dos CVEs en su propio framework Semantic Kernel (CVE-2026-26030 e CVE-2026-25592) que permiten que un prompt malicioso escale a ejecución de código. La cita textual del informe es de las que tienen la mala costumbre de ser ciertas: "Your LLM is not a security boundary. The tools you expose define your attacker's affected scope." DryRun Security testó los tres agentes principales: 87% de pull requests con al menos una vulnerabilidad. Meta vivió en directo cómo un agente IA interno otorgó acceso no autorizado a sistemas durante dos horas.

El cierre del triángulo

Los tres ejes no son independientes: se refuerzan. La velocidad fuerza al pipeline a saltar revisiones. La ignorancia llena el código de cosas que la revisión habría cazado. La autonomía permite que ese código ejecute decisiones sin humano en el loop. El resultado es Sicarii: código IA defectuoso aplicado a un dominio crítico —criptografía— que produce daño irreversible, incluso al propio atacante.

Plan de acción CISO: 6 pasos para esta semana

1. Inventario de stack vibe-coding interno (logs DNS, proxy, SaaS).
2. Política explícita de qué puede y qué no puede generar la IA.
3. SAST/DAST + secrets scanning obligatorios en pipeline post-IA.
4. Agentes IA en least-privilege con auditoría de las tools expuestas.
5. Trazas completas: prompt, output, revisor humano, decisión final.
6. Cultura: el vibe coding NO exime de revisión.

La pregunta para tu próximo comité: ¿cuántas aplicaciones internas construidas con herramientas tipo Lovable, Base44 o Cursor agent corren ahora mismo en producción tocando datos sensibles, y cuántas pasaron por code review? Si las dos cifras no coinciden —y no van a coincidir— ya tienes el primer trabajo del lunes.

Artículo completo con fuentes verificadas y FAQ extendido en enriquemaza.com.

Por primera vez documentada, un actor de crimen cibernético desarrolló un exploit zero-day con ayuda de inteligencia artificial y lo metió en producción. La vulnerabilidad: un bypass de autenticación de dos factores en una popular herramienta de administración web open source. El plan: usarlo en un evento de explotación masiva. Google lo cortó antes de que ocurriera y coordinó la divulgación responsable con el vendor afectado.

El zero-day no era un fallo de memoria ni una inyección clásica. Era un fallo semántico de lógica: el desarrollador hardcodeó una suposición de confianza que volvía la verificación 2FA bypasseable bajo condiciones específicas. Justo el tipo de fallo que ningún SAST tradicional encuentra y que un LLM identifica leyendo intención.

Esto cambia el escalón de amenazas — y lo hace esta semana

John Hultquist, jefe de análisis de GTIG: "Está aquí. La era de la explotación de vulnerabilidades con IA ya está aquí." El informe enmarca el hito así: el LLM ya no es un asesor pasivo, sino un participante activo en la cadena ofensiva, capaz de orquestar conjuntos de herramientas complejos y tomar decisiones tácticas a velocidad máquina.

Anatomía del exploit: cómo se sabe que lo escribió una IA

Los marcadores forenses son los típicos de salida de modelo de lenguaje contaminada con datos de entrenamiento: docstrings demasiado bien escritos, CVSS score alucinado, formato Pythónico de manual, una clase ANSI color llamada _C. Ninguno concluyente por sí solo; en conjunto producen una huella reconocible.

Por qué tu SAST no va a ver esto

El fallo es un "dormant logic error": parece funcionalmente correcto a cualquier scanner pero está estratégicamente roto desde el punto de vista de seguridad. El modelo lee la intención del desarrollador, no busca patrones de memoria. Los LLMs van a encontrar fallos que ya están en tu código esperando.

El zoo completo: APTs, malware con IA y supply chain

GTIG documenta cinco grupos estado-nación con TTPs distintos (UNC2814, APT45, APT27, UNC5673, UNC6201), cinco familias de malware con LLM embebido (PROMPTFLUX, HONESTCUE, CANFAIL, LONGSTREAM, PROMPTSPY), y una campaña de supply chain de TeamPCP que comprometió Trivy, Checkmarx, LiteLLM y BerriAI en marzo 2026.

PROMPTSPY es el caso más sofisticado: backdoor Android que serializa la UI del dispositivo en XML, la envía a Gemini, recibe coordenadas y simula gestos físicos en pantalla. Captura PINs biométricos. Si intentas desinstalarlo, renderiza un overlay invisible sobre el botón "Uninstall".

Big Sleep y CodeMender: Google jugando en el mismo campo

Google también está en el otro lado del tablero. Big Sleep ya encontró su primera vulnerabilidad real en producción. CodeMender parchea automáticamente vulnerabilidades críticas usando Gemini sin intervención humana inmediata. Si los atacantes usan LLMs a velocidad máquina, los defensores tienen que jugar al mismo juego.

Mi opinión como CISO — lo que cambia desde hoy

Tres cosas incómodas. Primera: el repositorio público wooyun-legacy con 85.000 casos de vulnerabilidades chinas se está integrando como plugin de Claude Code por actores ofensivos. Segunda: el tráfico API de Gemini, hoy por hoy, no se diferencia del developer de marketing usando ChatGPT. Tercera: yo tampoco tengo resuelto cómo distinguir el developer cumplidor del comprometido sin abrir un problema GDPR de proporciones bíblicas.

Plan de acción — 7 cosas para hacer esta semana en tu SOC

1. Inventario forzado de uso interno de IA por developers.
2. Auditar dependencias open source con énfasis en gateways IA.
3. Detección de prompt injection y RCE en frameworks agénticos.
4. Caza de patrones código generado por LLM en pull requests nuevos.
5. Hardening de cuentas premium LLM corporativas.
6. Bloqueo de aggregators y gateways LLM sospechosos en proxy.
7. Revisar OAuth grants a SaaS de IA en tu tenant.

La pregunta para tu próximo comité: ¿cuántas integraciones IA tienes ahora mismo en producción de las que no sabes quién las usa, qué dependencias tienen y qué clave API gobierna su acceso? Si la respuesta es "no lo sé", ya tienes la primera tarea del lunes.

Leer el artículo completo en enriquemaza.com