Un PDF, un asistente de IA y 4,090 ataques por semana: cuando la IA tiene las llaves de la empresa.
Imagina que el empleado más rápido de tu empresa lee todos los correos, consulta todas las carpetas, prepara pagos y nunca pregunta por qué. Ahora imagina que obedece cualquier instrucción que aparezca en un documento, incluso si la escribió un desconocido en letra blanca sobre fondo blanco.
Esa es la preocupación detrás de una cifra difundida el 6 de noviembre de 2026: las empresas colombianas reciben en promedio 4,090 ciberataques por semana, según Check Point Research, lo que ubica al país en el segundo lugar de América Latina, detrás de Brasil (4,118) y por encima de México (3,548). Su distribuidor CLM sostiene que la integración acelerada de herramientas de IA amplió la exposición en bases de datos, correo electrónico e identidades de acceso.
Una precisión necesaria: la cifra mide intentos de ataque por organización, no incidentes exitosos, y corresponde a datos de abril de 2026 que la prensa ha recirculado. El vínculo con la adopción de IA es una interpretación de CLM, no un hallazgo probado por Check Point. Lo que sí está documentado es que los ataques crecen: las organizaciones latinoamericanas reciben en promedio 3,364 por semana, 20% más que hace un año, frente a un promedio mundial de 2,201 en abril. Y la IA agrega superficies nuevas que conviene entender.
La historia: un martes cualquiera
Escenario ilustrativo, no corresponde a un caso real. Combina técnicas ya documentadas.
Una distribuidora mediana integró en septiembre un asistente de IA a su correo, su carpeta de proveedores y su sistema de cuentas por pagar. Leía facturas, las resumía y preparaba pagos para aprobación. En tres semanas el equipo financiero lo adoptó con entusiasmo.
Un martes llega la factura de un proveedor habitual, en PDF, desde una dirección casi idéntica a la real. Dentro del archivo, en texto blanco sobre fondo blanco, hay instrucciones que ningún humano ve: cambiar la cuenta bancaria del proveedor y enviar la lista completa de proveedores a una dirección externa.
El asistente procesa el documento, no distingue entre contenido y orden, y cumple. Prepara el pago a la nueva cuenta y envía nombres, identificaciones fiscales y datos bancarios de cientos de proveedores. El resumen dice que la factura se procesó sin novedades. El viernes, el lote se aprueba.
Nueve días después, el proveedor real llama por un pago que nunca recibió. El dinero quizá no se recupere, la lista ya servirá para nuevos fraudes contra esos proveedores, y la empresa enfrenta una auditoría y la obligación de notificar según la normativa de protección de datos aplicable. La pregunta más difícil llega de la gerencia: ¿por qué un documento recibido por correo pudo mover dinero?
Por qué no es ciencia ficción
Este ataque se llama inyección de instrucciones indirecta y OWASP lo ubica como el riesgo número uno en aplicaciones con modelos de lenguaje. En junio de 2025, investigadores de Aim Security divulgaron EchoLeak (CVE-2025-32711), una vulnerabilidad en Microsoft 365 Copilot en la que un solo correo con instrucciones ocultas podía provocar la salida de datos sin ningún clic. En agosto de 2026, PromptArmor demostró que texto oculto en PDFs podía manipular al asistente Rovo de Atlassian para filtrar tickets de Jira y documentos de Confluence. Y Palo Alto Networks Unit 42 documentó doce casos detectados contra agentes de IA en entornos reales. Los antivirus y cortafuegos tradicionales sirven de poco, porque el ataque viaja en lenguaje natural, no en código.
Cómo se evita y se combate
El escenario no depende de una sola falla sino de una cadena, y cada eslabón se puede romper. El asistente tenía acceso a demasiado: la regla es dar a cada agente solo los permisos que su tarea exige, como a cualquier identidad. Los documentos externos se trataban como confiables: conviene filtrarlos y mantenerlos separados de las instrucciones. El cambio de cuenta bancaria no tuvo verificación: las acciones de alto impacto requieren doble control humano por un canal distinto al correo. Nadie sabía qué había hecho el asistente: cada consulta y acción debe quedar registrada para auditoría. Y los datos salieron sin alerta: hace falta clasificar la información sensible y monitorear sus salidas.
Las tres decisiones que propone CLM encajan con esta lectura: definir qué datos puede analizar la IA, gestionar identidades y permisos de integración, y tener monitoreo y respuesta a incidentes desde el diseño. Se suma un punto práctico: acordar con los empleados qué herramientas externas de IA pueden usar, porque pegar datos financieros en un servicio no aprobado es otra vía de fuga.
¿Qué hacer diferente?
Inventariar dónde ya hay IA conectada a datos, con sus sistemas y permisos. Reducir permisos antes de ampliar casos de uso: un agente que lee no necesita poder pagar. Probar el sistema con documentos hostiles, por ejemplo PDFs con instrucciones ocultas, para ver qué tan expuesto está.
Conclusión
Los 4,090 ataques semanales no son una sentencia contra la IA ni prueba de que adoptarla multiplique los incidentes. Son un recordatorio de que cada integración que da acceso a datos, identidades y acciones requiere el mismo rigor que cualquier sistema crítico. La diferencia con el software tradicional es que aquí la entrada puede convertirse en instrucción, y por eso el control del acceso y de los datos pesa más que nunca.
Supuesto que, de ser falso, invalidaría esta lectura: que los asistentes de IA de la organización operen con permisos amplios sobre datos y acciones. Si ya funcionan con acceso mínimo, doble control y trazabilidad, el riesgo se reduce considerablemente. La pregunta para cada comité directivo: ¿sabemos con certeza qué puede hacer cada asistente de IA en nuestra empresa y quién respondería si algo sale mal?





Comentarios