Durante los últimos años, gran parte de la conversación sobre inteligencia artificial y ciberseguridad se concentró en una pregunta bastante cómoda:

¿Cómo puede la IA ayudarnos a defender mejor nuestras organizaciones?

SOC más rápidos. Detección más precisa. Análisis automatizado. Respuesta ante incidentes. Generación de código. Automatización de tareas.

Pero en 2026 la pregunta empieza a cambiar.

Y es bastante menos cómoda:

¿Quién está protegiendo a la IA que ya opera dentro de nuestra organización?

La diferencia parece semántica, pero no lo es.

Los copilotos y agentes de IA están dejando de ser herramientas que simplemente responden preguntas o resumen información. Cada vez más, pueden consultar bases de datos, escribir y ejecutar código, acceder a documentos, modificar configuraciones, interactuar con aplicaciones empresariales y tomar decisiones que desencadenan acciones reales.

NIST ya identifica precisamente esta característica —la capacidad de los agentes para interactuar con datos, herramientas y aplicaciones y actuar de manera autónoma— como una fuente de nuevos desafíos de seguridad que requieren adaptar los controles tradicionales.

Y aquí aparece el problema:

un agente que puede actuar necesita ser protegido como cualquier otra identidad con privilegios dentro de la organización.

Pero con una diferencia importante.

Un usuario puede tardar minutos en cometer un error.

Un agente puede hacerlo en segundos.

EL PERÍMETRO CAMBIÓ

Durante décadas pensamos el perímetro de seguridad de una organización alrededor de elementos relativamente conocidos:

• usuarios;
• dispositivos;
• servidores;
• aplicaciones;
• redes;
• datos.

Por eso construimos firewalls, antivirus, EDR, DLP, IAM, SIEM y SOC.

Pero ahora apareció otro actor:

el agente de inteligencia artificial.

Y no es simplemente otra aplicación.

Un agente puede interpretar lenguaje natural, recibir información de fuentes externas, combinar ese contexto con información interna, utilizar herramientas y ejecutar acciones.

Eso cambia radicalmente el modelo de amenaza.

Imaginemos un agente encargado de apoyar al área financiera.

Tiene acceso a correos, documentos, ERP y determinados procesos de aprobación.

Un atacante no necesariamente necesita vulnerar directamente el ERP.

Puede intentar manipular la información que el agente consume.

Si consigue que el agente interprete una instrucción maliciosa como parte legítima de su contexto, el problema deja de ser un mensaje incorrecto.

Ahora tenemos una identidad con permisos ejecutando una decisión equivocada.

Y eso es bastante más serio.

1. PROJECT INJECTION: LA NUEVA FRONTERA DE ATAQUE

La inyección de prompts se ha convertido en uno de los problemas centrales de seguridad para los sistemas basados en IA.

Cisco la ha descrito directamente como “la nueva SQL injection”, precisamente porque explota una característica estructural de los modelos: la dificultad para distinguir de manera completamente confiable entre instrucciones legítimas y contenido que simplemente debería ser tratado como datos.

El problema se vuelve especialmente delicado cuando hablamos de inyección indirecta.

Un agente puede recibir información desde:

• Un correo electrónico;
• Una página web;
• Un documento PDF;
• Un repositorio de código;
• Un sistema de tickets;
• Una base documental;
• Una herramienta externa.

Ese contenido puede contener instrucciones diseñadas para cambiar el comportamiento del agente.

Y el agente puede no saber que esas instrucciones son maliciosas.

EL ATACANTE NO NECESITA CONVENCER AL USUARIO. NECESITA CONVENCER AL AGENTE.

La investigación publicada por NIST durante 2026 confirma que el agent hijacking, o secuestro de agentes mediante inyección indirecta, puede producir acciones no deseadas como la extracción de información sensible o la ejecución de código.

Y existe otro detalle particularmente incómodo: la persistencia.

En una evaluación publicada por Anthropic sobre agentes de coding, la tasa de éxito de ataques de inyección indirecta fue de 4,7% con un intento, 33,6% con diez intentos y 63% cuando el atacante podía realizar cien intentos.

La lectura importante no es solamente el 4,7%.

Es esta:

un atacante persistente cambia las probabilidades.

Por eso una defensa que funciona razonablemente bien ante un único intento puede resultar insuficiente frente a un adversario que puede probar, adaptar y volver a intentar.

2. LA FUGA DE INFORMACIÓN YA NO NECESITA UN ATACANTE SOFISTICADO

Existe otra amenaza mucho más cotidiana.

La propia IA puede convertirse en una vía de exposición de información.

El ejemplo clásico es sencillo:

Un empleado recibe un contrato confidencial y decide utilizar una herramienta pública de IA para resumirlo.

No necesariamente existe una intención maliciosa.

No hay malware.

No hay explotación de una vulnerabilidad.

No hay un atacante detrás del teclado.

Simplemente existe una persona intentando trabajar más rápido.

El problema es que la organización puede no saber:

• Qué información se está enviando;
• A qué modelo;
• Bajo qué condiciones;
• Dónde queda almacenada;
• Quién puede acceder posteriormente;
• Qué políticas aplican sobre esos datos.

Ahora llevemos el mismo escenario a un agente.

El agente no necesita que un empleado copie y pegue manualmente el documento.

Puede acceder automáticamente a información de clientes, contratos, correos o sistemas internos.

Y puede mover esa información entre diferentes servicios.

La velocidad de la automatización transforma un problema puntual en un problema potencialmente masivo.

3. SHADOW AI: CUANDO LA ORGANIZACIÓN DESCUBRE LA IA DESPUÉS DE QUE YA ESTÁ FUNCIONANDO

Las organizaciones ya aprendieron una lección con el Shadow IT.

Los usuarios adoptan herramientas antes de que las políticas alcancen a regularlas.

Con la inteligencia artificial está ocurriendo algo similar.

Chatbots, asistentes de programación, extensiones de navegador, herramientas de transcripción, servicios de generación de contenido y agentes especializados pueden incorporarse al trabajo diario sin pasar necesariamente por un proceso formal de seguridad.

Eso crea un problema de visibilidad.

No se puede proteger aquello que la organización no sabe que existe.

Pero existe una segunda dimensión todavía más importante:

¿Qué permisos tiene esa IA?

NIST está trabajando específicamente en este problema: cómo identificar, autorizar, auditar y establecer mecanismos de responsabilidad para agentes de software y agentes de IA.

La pregunta que deberíamos hacerle a un agente no es solamente:

“¿Qué modelo utiliza?”

También deberíamos preguntar:

“¿Qué puede hacer ese modelo cuando se equivoca?”

Porque un agente con acceso a información sensible y capacidad de ejecutar acciones puede convertirse, en la práctica, en una nueva identidad privilegiada.

EL PROBLEMA CON CONFIAR SOLAMENTE CON CONTROLES TRADICIONALES

Aquí aparece una de las principales confusiones.

No significa que el firewall haya dejado de ser útil.

Tampoco que un SIEM, un EDR o un DLP tradicional sean inútiles.

El problema es diferente:

fueron diseñados para resolver problemas distintos.

• Un firewall puede controlar comunicaciones.
• Un EDR puede detectar comportamientos sospechosos en un endpoint.
• Un DLP puede identificar determinados patrones de información sensible.
• Un SIEM puede correlacionar eventos.

Pero ninguno de ellos, por sí solo, necesariamente entiende la intención que existe detrás de una interacción entre: usuario → agente → modelo → contexto → herramienta → acción.

Ese es el nuevo recorrido que debemos proteger.

Y NIST coincide en algo fundamental: los principios tradicionales de ciberseguridad siguen siendo relevantes, pero necesitan ser adaptados para responder a los riesgos específicos de los agentes.

ENTONCES, ¿QUÉ DEBERÍA PROTEGER UNA ORGANIZACIÓN?

La respuesta no es comprar “otro firewall”.

La respuesta es construir una nueva capa de control alrededor de la IA.

Podemos pensarla en cuatro niveles.

Capa 1 — Control de las acciones del agente

El agente no debería tener libertad absoluta para ejecutar cualquier acción que su modelo considere apropiada.

Las acciones críticas necesitan controles previos.

Por ejemplo:

Permitir.

La acción es coherente con la política y el contexto.

Advertir.

La acción puede ser legítima, pero requiere una revisión adicional.

Bloquear.

La acción excede las capacidades permitidas para ese agente.

Esta lógica funciona como un circuit breaker.

No intenta predecir perfectamente todo lo que hará la IA.

Busca algo mucho más práctico: limitar qué puede hacer cuando se equivoca.

Y eso es fundamental porque no podemos asumir que un modelo será infalible frente a un atacante determinado.

De hecho, NIST publicó en 2026 investigación que refuerza la necesidad de un enfoque continuo de evaluación y actualización, en lugar de asumir que un conjunto fijo de controles será suficiente frente a ataques adaptativos.

Capa 2 — El agente debe tener identidad y privilegios

Si una persona tiene acceso privilegiado a sistemas críticos, esperamos que tenga:

• Identidad;
• Autenticación;
• Permisos definidos;
• Privilegio mínimo;
• Trazabilidad;
• Controles de acceso;
• Monitoreo.

¿Por qué debería ser diferente para un agente?

No debería.

Cada agente debe tener una identidad claramente definida y permisos específicos.

No debería poder acceder a todo “porque quizás algún día lo necesite”.

No debería reutilizar credenciales personales.

No debería tener acceso permanente a sistemas críticos.

Y, especialmente:

Si no permitirías que un usuario ejecute esa acción como administrador, probablemente tampoco deberías permitir que un agente la ejecute sin controles.

La discusión sobre identidad y autorización de agentes ya está siendo abordada formalmente por NIST, incluyendo identificación, autorización, auditoría y no repudio.

Capa 3 — Gobernanza, DLP y control del Shadow AI

La organización necesita saber qué IA utiliza.

Pero también necesita saber: qué información entra y qué información sale.

Eso significa establecer políticas para:

• Herramientas autorizadas;
• Modelos aprobados;
• Información que puede procesarse;
• Información que nunca debe salir;
• Agentes permitidos;
• Integraciones autorizadas;
• Almacenamiento de información;
• Uso de datos sensibles.

Aquí el DLP sigue siendo relevante, pero debe evolucionar.

Ya no basta con proteger archivos almacenados.

Hay que considerar también:

prompts, respuestas, contexto, documentos recuperados, herramientas utilizadas y acciones ejecutadas por agentes.

Y existe una dimensión adicional:

La procedencia del modelo importa.

No basta con saber que una aplicación “usa IA”.

La organización debería conocer qué modelo utiliza, quién lo desarrolla, qué proveedores participan en la cadena y qué componentes intervienen en el procesamiento.

La cadena de suministro de IA también es parte de la superficie de ataque.

Capa 4 — Red Teaming para IA

Hay una regla bastante simple en ciberseguridad: si no lo pruebas tú, eventualmente alguien más lo probará.

Eso también aplica a los agentes.

El red-teaming de IA busca precisamente poner a prueba el comportamiento del sistema antes de que lo haga un adversario.

La evaluación debería intentar responder preguntas como:

• ¿Puede un agente ser manipulado por contenido externo?
• ¿Puede acceder a información que no necesita?
• ¿Puede ejecutar herramientas fuera de su propósito?
• ¿Puede modificar sistemas críticos?
• ¿Puede revelar información sensible?
• ¿Puede mantener una acción peligrosa después de recibir nueva información?
• ¿Qué ocurre cuando recibe instrucciones contradictorias?
• ¿Qué pasa cuando un atacante insiste?

NIST ha impulsado durante 2026 evaluaciones y ejercicios de red-teaming específicamente orientados a la seguridad de agentes, justamente porque las pruebas tradicionales no capturan completamente este nuevo escenario.

NO SE TRATA DE DETENER LA IA

Este punto es importante.

La respuesta no debería ser: “Entonces no usemos agentes.”

Eso sería equivalente a decir que, como existen vulnerabilidades en las aplicaciones, dejemos de utilizar software.

El objetivo es otro:

Permitir autonomía, pero con límites.

Una organización puede utilizar agentes para automatizar procesos.

Puede permitirles consultar información.

Puede conectarlos a herramientas.

Puede permitirles tomar decisiones.

Pero debe establecer claramente: qué pueden hacer, qué nunca pueden hacer y qué acciones necesitan supervisión.

La autonomía sin control no es innovación.

Es simplemente delegación de riesgo a una máquina.

UNA HOJA DE RUTA PRÁCTICA

No es necesario implementar toda esta arquitectura de un día para otro.

Un enfoque razonable puede comenzar con tres fases.

01 — Descubrir

Primero hay que saber qué existe.

Inventariar:

• Herramientas de IA;
• Modelos utilizados;
• Agentes;
• Integraciones;
• Fuentes de datos;
• Permisos;
• Credenciales;
• Información procesada.

Incluyendo aquello que nunca pasó por el área de TI.

Shadow AI también forma parte del inventario de riesgo.

02 — Contener

Una vez que sabemos qué existe, podemos comenzar a gobernarlo.

Definir:

• Política de uso de IA;
• Herramientas autorizadas;
• Clasificación de información;
• Privilegios mínimos;
• Controles de acceso;
• Reglas de DLP;
• Supervisión de acciones críticas.

Esta etapa puede generar una reducción significativa del riesgo sin requerir una transformación tecnológica completa.

03 — Validar

Finalmente, hay que asumir que los controles también pueden fallar.

Por eso necesitamos pruebas periódicas.

Red teaming.

Simulación de ataques.

Evaluación de agentes.

Revisión de permisos.

Monitoreo continuo.

Y actualización de controles.

Porque una arquitectura de seguridad para IA que se prueba una vez y luego se abandona probablemente terminará siendo tan obsoleta como la amenaza que intentaba detener.

LA PREGUNTA QUE DEBERÍA LLEGAR AL DIRECTORIO

Hasta hace poco, la conversación sobre IA podía parecer exclusivamente tecnológica.

Ya no.

Cuando un agente puede acceder a información financiera, modificar infraestructura, consultar bases de datos, escribir código o ejecutar procesos de negocio, estamos hablando de riesgo operacional, reputacional, regulatorio y estratégico.

Por eso la pregunta para un directorio no debería ser:

“¿Estamos usando inteligencia artificial?”

Probablemente la respuesta ya sea sí.

La pregunta debería ser:

“¿Sabemos qué puede hacer nuestra IA, con qué información, con qué permisos y qué sucede si toma una decisión equivocada?”

Y existe una pregunta todavía más incómoda:

“¿Quién vigila a nuestros agentes cuando nosotros no estamos mirando?”

EL NUEVO PERÍMETRO NO ES UNA CAJA. ES UNA DECISIÓN.

La seguridad de la IA no consiste únicamente en proteger el modelo.

Consiste en proteger todo lo que ocurre alrededor del modelo.

Los datos que recibe.

Las instrucciones que interpreta.

Las herramientas que utiliza.

Las identidades que emplea.

Los sistemas a los que accede.

Las decisiones que toma.

Y las acciones que ejecuta.

El firewall tradicional seguirá teniendo su lugar.

El SOC seguirá teniendo su lugar.

El EDR, el DLP, el IAM y el resto de la arquitectura de ciberseguridad también.

Pero el perímetro se está expandiendo.

Porque ahora tenemos sistemas capaces de interpretar información y actuar sobre el mundo digital.

Y cuando el software empieza a tomar decisiones, proteger la red ya no es suficiente. También hay que proteger la decisión.

En CompuNetGroup entendemos este desafío como una evolución natural de la ciberseguridad gestionada: descubrir el uso real de IA, identificar Shadow AI, controlar privilegios, establecer políticas de gobierno, proteger los flujos de información y someter a los agentes a pruebas de seguridad antes de que un atacante lo haga por nosotros.

Porque la pregunta ya no es si la inteligencia artificial va a entrar en las organizaciones.

Ya entró.

La pregunta es si entró con los controles adecuados.

¿QUIERES SABER QUÉ TAN EXPUESTA ESTÁ TU ORGANIZACIÓN FRENTE AL USO DE IA?

Conversemos sobre cómo identificar tus agentes, evaluar sus permisos, descubrir Shadow AI y construir una estrategia de seguridad para la nueva generación de sistemas autónomos.

CompuNetGroup — Seguridad Digital Gestionada

Durante años, cuando hablábamos de ciberseguridad, la conversación solía centrarse en una pregunta bastante concreta: ¿cómo evitamos que entren?

Firewalls, antivirus, sistemas de detección, controles de acceso, monitoreo, respaldos y una larga lista de tecnologías forman parte de la respuesta.

Pero el escenario actual nos obliga a plantearnos una pregunta diferente:

¿Qué pasa con nuestra organización si, a pesar de todas esas medidas, ocurre un incidente?

Porque una cosa es prevenir un ataque y otra muy distinta es estar preparado para continuar operando cuando ese ataque consigue afectar nuestro entorno.

Ahí aparece un concepto que está tomando cada vez más importancia: la ciber resiliencia.

LA SEGURIDAD NO TERMINA CUANDO OCURRE EL INCIDENTE

Ninguna organización puede asumir que está completamente fuera de riesgo.

Puede tener tecnología de primer nivel, controles correctamente configurados y equipos especializados. Aun así, existen vulnerabilidades, errores humanos, credenciales comprometidas, amenazas internas, ataques dirigidos y nuevas técnicas que aparecen constantemente.

Por eso, una estrategia de seguridad madura no debería medirse solamente por su capacidad de bloquear amenazas.

También debería preguntarse:

• ¿Podemos detectar rápidamente que algo está ocurriendo?
• ¿Sabemos qué sistemas están siendo afectados?
• ¿Tenemos procedimientos claros para responder?
• ¿Podemos contener el incidente antes de que se expanda?
• ¿Sabemos cómo recuperar nuestros servicios críticos?
• ¿Tenemos identificadas las prioridades del negocio?
• ¿Podemos continuar operando mientras resolvemos el problema?

La resiliencia comienza precisamente ahí.

No se trata de asumir que nunca tendremos un incidente. Se trata de estar preparados para cuando ocurra.

DE LA PREVENCIÓN A LA CAPACIDAD DE RESPUESTA

Uno de los principales cambios que estamos viendo en las organizaciones es el paso desde una lógica exclusivamente preventiva hacia una estrategia mucho más integral.

La prevención sigue siendo fundamental. Pero ya no es suficiente.

Una organización resiliente necesita trabajar en varias dimensiones al mismo tiempo:

1. Anticipar

Conocer los riesgos antes de que se conviertan en problemas.

Esto implica identificar vulnerabilidades, evaluar la exposición de los activos críticos, entender las amenazas que pueden afectar al negocio y revisar constantemente los controles existentes.

2. Detectar

El tiempo es uno de los factores más importantes durante un incidente.

Mientras más tarde una organización en identificar una actividad maliciosa, mayor puede ser su impacto.

Por eso, el monitoreo continuo y la capacidad de detectar comportamientos anómalos son componentes esenciales de una estrategia de ciber resiliencia.

3. Responder

Detectar un incidente es solo el comienzo.

También es necesario saber qué hacer después.

¿Quién toma las decisiones? ¿Qué sistemas deben aislarse? ¿Qué servicios tienen prioridad? ¿A quién se debe informar? ¿Cómo se coordina la respuesta?

La tecnología puede ayudar enormemente, pero una respuesta efectiva también necesita personas, procesos y responsabilidades claramente definidos.

4. Recuperar

La recuperación no consiste simplemente en volver a encender los sistemas.

Se trata de recuperar los servicios necesarios para que la organización pueda volver a funcionar de manera segura y controlada.

Aquí los respaldos, los planes de continuidad, la infraestructura adecuada y las pruebas periódicas adquieren un papel fundamental.

5. Aprender

Cada incidente debería convertirse en una fuente de información.

¿Qué ocurrió?
¿Por qué ocurrió?
¿Qué controles funcionaron?
¿Cuáles fallaron?
¿Qué deberíamos cambiar?

Una organización resiliente no solamente se recupera de un incidente.

También aprende de él y mejora su capacidad para enfrentar el siguiente.

LA TECNOLOGÍA ES IMPORTANTE. PERO NO ES SUFICIENTE.

Desde nuestra experiencia en infraestructura y redes, vemos frecuentemente que las organizaciones cuentan con múltiples soluciones de seguridad.

El problema aparece cuando esas soluciones funcionan como elementos aislados.

Un firewall por sí solo no construye resiliencia.

Un antivirus por sí solo tampoco.

Un sistema de monitoreo, una plataforma de respaldos o una herramienta de gestión de vulnerabilidades tampoco.

La verdadera capacidad aparece cuando tecnología, personas y procesos trabajan como un sistema.

Eso significa tener visibilidad sobre el entorno, conocer los activos críticos, establecer controles, monitorear continuamente, contar con procedimientos de respuesta y, sobre todo, entender cómo cada componente impacta directamente en la operación del negocio.

Porque detrás de cada servidor, aplicación, usuario o dispositivo existe algo mucho más importante:

una operación que necesita seguir funcionando.

LA CONTINUIDAD DEL NEGOCIO ES PARTE DE LA SEGURIDAD.

Un incidente de ciberseguridad no afecta solamente al área de TI.

Puede detener ventas, afectar la atención de clientes, interrumpir procesos productivos, retrasar operaciones logísticas, comprometer información sensible o incluso generar impactos regulatorios y reputacionales.

Por eso, hablar de ciber resiliencia implica necesariamente hablar de negocio.

La pregunta deja de ser solamente:

"¿Cómo protegemos nuestros sistemas?"

Y pasa a ser:

"¿Cómo aseguramos que nuestra organización pueda seguir funcionando cuando nuestros sistemas están bajo presión?"

Ese cambio de perspectiva es fundamental.

RESILIENCIA NO SIGNIFICA TENER MÁS HERRAMIENTAS.

Existe una tentación bastante común en ciberseguridad: pensar que aumentar la cantidad de herramientas automáticamente aumenta el nivel de protección.

No necesariamente.

Una organización puede tener muchas tecnologías implementadas y, aun así, desconocer qué ocurriría durante un incidente real.

La madurez está en otro lugar.

Está en saber qué proteger, por qué protegerlo, cómo monitorearlo, cómo responder y cómo recuperarlo.

Y, especialmente, en probar que todo eso funciona antes de necesitarlo.

Los planes que nunca se prueban son solamente documentos.

Los respaldos que nunca se restauran son solamente una promesa.

Y los procedimientos que nadie conoce difícilmente podrán funcionar cuando exista presión real.

UNA ORGANIZACIÓN RESILIENTE NO ES UNA ORGANIZACIÓN INVULNERABLE.

Quizás esta sea la idea más importante.

La ciber resiliencia no busca prometer algo imposible.

No existe una organización completamente inmune frente al riesgo.

Lo que sí podemos construir es una organización más preparada, más consciente y con mayor capacidad de respuesta.

Una organización que detecta antes.

Que responde mejor.

Que recupera más rápido.

Y que aprende después de cada incidente.

Ese es el verdadero objetivo de una estrategia de ciber resiliencia.

Porque en un mundo donde la tecnología está cada vez más integrada al negocio, proteger la operación ya no significa solamente evitar que algo ocurra. También significa estar preparados para seguir adelante cuando ocurra.

¿QUÉ TAN PREPARADA ESTÁ TU ORGANIZACIÓN?

La ciber resiliencia comienza entendiendo dónde están realmente las principales exposiciones.

En CompuNet trabajamos junto a las organizaciones para evaluar sus riesgos, fortalecer sus capacidades de protección y desarrollar estrategias que integren seguridad, infraestructura, monitoreo, respuesta y continuidad operacional.

Porque el objetivo final no es simplemente tener más seguridad.

Es tener una organización capaz de seguir funcionando.

LA INTELIGENCIA ARTIFICIAL ESTÁ CAMBIANDO LA FORMA DE PROGRAMAR... PERO TAMBIÉN ESTA CAMBIANDO LOS RIESGOS

La inteligencia artificial generativa está transformando el desarrollo de software a una velocidad nunca antes vista. Herramientas como ChatGPT, GitHub Copilot, Claude o Gemini permiten generar código en segundos, reduciendo tiempos de desarrollo y facilitando la creación de aplicaciones.

Sin embargo, junto con estos beneficios ha surgido una nueva tendencia conocida como Vibe Coding, una metodología que privilegia la rapidez por sobre el diseño estructurado del software.

¿El problema?

Cuando el código generado por IA llega a producción sin controles de calidad ni procesos de DevSecOps, las organizaciones pueden enfrentar vulnerabilidades críticas, aplicaciones difíciles de mantener y mayores riesgos de ciberseguridad.

En este artículo analizamos qué es el Vibe Coding, cuáles son sus principales riesgos y cómo las empresas pueden aprovechar la IA sin comprometer la seguridad de sus aplicaciones.

¿ QUÉ ES EL VIBE CODING?

El término Vibe Coding fue popularizado por Andrej Karpathy durante 2025 para describir una nueva forma de desarrollar software utilizando asistentes de inteligencia artificial.

En lugar de diseñar una arquitectura completa desde el inicio, el desarrollador conversa con la IA, solicita fragmentos de código, realiza pequeños ajustes y continúa iterando mientras "todo parece funcionar".

En otras palabras:

Se construye primero y se piensa después.

Esta metodología puede ser extremadamente útil para:

• Prototipos rápidos
• Pruebas de concepto (PoC)
• Automatizaciones internas
• MVPs (Minimum Viable Products)

El problema aparece cuando ese mismo código termina formando parte de aplicaciones críticas para el negocio.

LA IA ACELERA EL DESARROLLO... PERO TAMBIÉN MULTIPLICA LOS RIESGOS

Diversos estudios durante 2025 muestran que la IA realmente aumenta la productividad.

El informe State of Developer Ecosystem 2025 de JetBrains indica que cerca del 90% de los desarrolladores ahorra al menos una hora semanal utilizando asistentes de IA y aproximadamente un 20% ahorra ocho horas o más.

Sin embargo, la velocidad tiene un costo.

Cuando no existen procesos de revisión técnica, el código generado suele presentar problemas de:

• Arquitectura
• Escalabilidad
• Seguridad
• Mantenibilidad

RIESGO Nº1: APLICACIONES QUE NO ESCALAN

El código generado mediante IA suele resolver el problema inmediato, pero rara vez considera cómo evolucionará el sistema dentro de seis meses o dos años.

Es frecuente encontrar:

• lógica de negocio mezclada con acceso a datos;
• ausencia de patrones de diseño;
• componentes altamente acoplados;
• arquitectura definida por accidente y no por planificación.

Mientras un prototipo puede funcionar perfectamente durante una demostración, una aplicación empresarial necesita soportar miles de usuarios, cambios continuos y nuevas funcionalidades.

Ahí es donde comienzan los problemas.

RIESGO Nº2: VULNERABILIDADES DE SEGURIDAD EN APLICACIONES DESARROLLADAS CON IA

Desde la perspectiva de la ciberseguridad, este es probablemente el riesgo más importante.

Diversas investigaciones publicadas durante 2025 muestran resultados preocupantes.

Entre los principales hallazgos destacan:

• desarrolladores asistidos por IA generan código entre 3 y 4 veces más rápido, pero producen cerca de 10 veces más hallazgos de seguridad;
• aproximadamente 45% del código generado por IA contiene debilidades de seguridad;
• estudios académicos encontraron una mayor presencia de vulnerabilidades críticas respecto del código desarrollado manualmente;
• análisis sobre aplicaciones construidas mediante Vibe Coding detectaron ausencia de protecciones básicas como CSRF, cabeceras de seguridad y validaciones de entrada.

En producción, los riesgos continúan creciendo.

Miles de aplicaciones analizadas presentaban:

• vulnerabilidades críticas;
• credenciales expuestas;
• configuraciones inseguras;
• errores fácilmente explotables.

VULNERABILIDADES MÁS COMUNES DEL CÓDIGO GENERADO POR IA

Las fallas que aparecen con mayor frecuencia incluyen:

SQL Injection

Consultas SQL construidas sin sanitización adecuada que permiten acceder o modificar bases de datos.

Credenciales hardcodeadas

Contraseñas, API Keys o tokens almacenados directamente dentro del código fuente.

Validación insuficiente de entradas

Datos ingresados por los usuarios que no son correctamente validados antes de procesarse.

Autenticación genérica

Mecanismos de login que funcionan técnicamente, pero no consideran los riesgos reales del negocio.

RIESGO Nº3: EL EFECTO "CÓDIGO ESPAGUETI"

Cuando la IA genera código mediante múltiples iteraciones, es común que se acumulen pequeñas modificaciones sin una refactorización adecuada.

Con el tiempo aparecen:

• funciones excesivamente largas;
• duplicación de lógica;
• dependencias innecesarias;
• código difícil de comprender incluso para quien lo desarrolló.

El informe State of Software Delivery 2025 de Harness muestra que 67% de los desarrolladores dedica actualmente más tiempo a depurar código generado por IA que antes de utilizar estas herramientas.

Este problema también impacta la respuesta frente a incidentes de seguridad.

Mientras más complejo resulta entender una aplicación, más lenta será la investigación de una brecha.

CÓMO REDUCIR LOS RIESGOS DEL VIBE CODING

La respuesta no consiste en dejar de utilizar inteligencia artificial.

La clave está en incorporar controles de seguridad dentro del ciclo de desarrollo.

Algunas buenas prácticas incluyen:

Revisión obligatoria de código

Todo código generado por IA debería ser revisado por desarrolladores con experiencia antes de llegar a producción.

Integrar DevSecOps

La seguridad debe incorporarse desde las primeras etapas del desarrollo mediante procesos automáticos.

Implementar SAST

Las herramientas de Static Application Security Testing (SAST) permiten detectar vulnerabilidades antes del despliegue.

Analizar dependencias

El uso de Software Composition Analysis (SCA) ayuda a identificar bibliotecas vulnerables o paquetes inexistentes generados por IA (slopsquatting).

Definir la arquitectura antes de generar código

La IA debe seguir una arquitectura previamente diseñada, no improvisarla.

Automatizar pruebas

Las pruebas automatizadas permiten validar rápidamente que nuevas modificaciones no introduzcan errores ni vulnerabilidades.

Realizar auditorías periódicas

Especialmente cuando existen aplicaciones desarrolladas rápidamente mediante asistentes de IA.

DevSecOps: LA PIEZA QUE FALTA

El crecimiento del desarrollo asistido por IA está impulsando la adopción de modelos donde la seguridad forma parte del proceso desde el primer día.

En lugar de corregir vulnerabilidades al finalizar el proyecto, las organizaciones están integrando:

• análisis estático de código;
• escaneo automático de dependencias;
• revisión continua de secretos;
• validación de configuraciones;
• pruebas de seguridad automatizadas.

Este enfoque permite mantener la velocidad del desarrollo sin sacrificar la protección de la información.

CONCLUSIÓN

El Vibe Coding llegó para quedarse.

La inteligencia artificial seguirá acelerando el desarrollo de software y democratizando la programación.

Sin embargo, confiar ciegamente en el código generado por IA puede traducirse en aplicaciones vulnerables, difíciles de mantener y costosas de operar.

Las organizaciones que combinen la productividad de la IA con procesos maduros de DevSecOps, revisión de código y pruebas de seguridad serán las que obtengan una verdadera ventaja competitiva.

En CompuNet creemos que la inteligencia artificial debe acelerar el desarrollo, no aumentar la superficie de ataque.

Si tu organización está incorporando IA para desarrollar software, es el momento de asegurar que cada línea de código llegue a producción con los controles adecuados.

La Inteligencia Artificial está cambiando la forma en que trabajamos. Hoy existen asistentes capaces de revisar correos, abrir documentos, consultar calendarios e incluso ejecutar tareas completas desde el navegador. Sin embargo, mientras más privilegios otorgamos a estos agentes, mayor es el impacto que puede tener una vulnerabilidad.

Esta semana, investigadores de Manifold Security revelaron una falla en la extensión Claude for Chrome de Anthropic que podría permitir que otras extensiones maliciosas del navegador desencadenen acciones autorizadas por el usuario, accediendo potencialmente a información de Gmail, Google Docs y Google Calendar. La investigación fue difundida por The Hacker News y vuelve a poner sobre la mesa una realidad que muchas organizaciones aún subestiman: la seguridad de la IA no depende únicamente del modelo, sino también de todo el ecosistema que lo rodea.

¿QUÉ OCURRIÓ?

La vulnerabilidad no permite que cualquier sitio web tome el control de Claude. El escenario requiere que exista previamente otra extensión del navegador con permisos para interactuar con claude.ai.

El problema identificado por los investigadores consiste en que Claude acepta ciertos eventos simulados como si hubieran sido realizados por un usuario real. Aprovechando ese comportamiento, una extensión maliciosa podría iniciar algunas de las tareas predefinidas que Claude tiene disponibles, como:

• Leer correos de Gmail.
• Acceder al documento más reciente de Google Docs y sus comentarios.
• Revisar el calendario del usuario.

En el modo de funcionamiento predeterminado ("Ask before acting"), Claude aún solicita confirmación antes de ejecutar estas acciones. Sin embargo, quienes habilitaron el modo "Act without asking" podrían quedar expuestos a una ejecución automática sin esa validación adicional. 

NO ES UN PROBLEMA DEL MODELO DE IA

Uno de los aspectos más interesantes de esta investigación es que el problema no está en Claude como modelo de lenguaje.

Los investigadores comprobaron que la vulnerabilidad se reproduce independientemente del modelo utilizado (Opus, Sonnet o Fable). El punto débil se encuentra en la extensión del navegador y en la forma en que administra los permisos y la interacción con otras extensiones instaladas. 

Esto es importante porque muchas organizaciones centran su evaluación de riesgos únicamente en la IA, cuando en realidad deben analizar:

• Navegadores.
• Extensiones instaladas.
• Permisos concedidos.
• Integraciones con aplicaciones corporativas.
• Gestión de identidades.
• Configuración de privilegios.

UN RECORDATORIO PARA TODAS LAS EMPRESAS

Cada vez más soluciones de IA funcionan como agentes digitales capaces de actuar en representación del usuario.

Cuando una IA puede:

• enviar correos,
• consultar documentos,
• acceder a aplicaciones SaaS,
• modificar información,
• automatizar procesos,

ya no estamos hablando solamente de productividad. Estamos hablando de una cuenta privilegiada que debe administrarse con los mismos estándares que cualquier identidad crítica dentro de una organización.

Este caso demuestra precisamente eso.

La superficie de ataque ya no termina en el correo electrónico o el endpoint. Hoy también incluye los asistentes inteligentes que utilizamos diariamente.

¿QUÉ DEBERÍAN HACER LAS ORGANIZACIONES?

Más allá de esperar una actualización del fabricante, existen buenas prácticas que ayudan a reducir el riesgo:

• Mantener únicamente las extensiones estrictamente necesarias en los navegadores corporativos.
• Revisar periódicamente los permisos otorgados a cada extensión.
• Evitar habilitar modos de automatización total cuando no sean indispensables.
• Aplicar políticas de mínimo privilegio para herramientas de IA.
• Supervisar el uso de asistentes inteligentes dentro del entorno corporativo.
• Incorporar la IA dentro de las evaluaciones de riesgo y de los programas de gestión de vulnerabilidades.

La adopción de IA debe ir acompañada de controles de gobierno y seguridad, del mismo modo que ocurre con cualquier otra tecnología empresarial.

LA IA TAMBIÉN NECESITA UNA ESTRATEGIA DE CIBERSEGURIDAD

Hace algunos años el foco estaba puesto en proteger servidores, estaciones de trabajo y aplicaciones web.

Hoy la conversación cambió.

Los agentes inteligentes comienzan a tener acceso a nuestros correos, documentos, repositorios de código, plataformas SaaS e incluso a procesos completos del negocio.

Eso significa que la seguridad ya no puede limitarse al modelo de IA. Debe abarcar todo el ecosistema que le permite operar.

La productividad que ofrecen estas herramientas es enorme, pero también lo es la responsabilidad de implementarlas bajo un enfoque de Zero Trust, gestión de identidades, monitoreo continuo y control de privilegios.

Porque, al final del día, una IA con acceso a toda la información de una organización merece el mismo nivel de protección que cualquier administrador del sistema.

Acerca del autor

Héctor Maldonado es Líder de Marketing de CompuNet, especialista en comunicación estratégica de ciberseguridad y transformación digital. Desde CompuNet News comparte análisis sobre amenazas emergentes, tendencias tecnológicas y mejores prácticas para ayudar a las organizaciones a fortalecer su postura de seguridad frente a un panorama digital en constante evolución.

Durante años protegimos las empresas como si fueran un castillo: construimos murallas cada vez más altas, instalamos puertas robustas y controlamos quién podía entrar. Mientras todo el trabajo ocurría dentro de la oficina, esa estrategia tenía sentido.

Pero el mundo cambió.

Hoy los colaboradores trabajan desde sus hogares, aeropuertos, cafeterías o incluso desde otro país. Las aplicaciones ya no viven únicamente en el datacenter corporativo, sino también en nubes públicas y privadas. Los proveedores necesitan acceder a sistemas específicos y los dispositivos personales forman parte del día a día.

En este escenario, la gran pregunta es inevitable:

¿Tiene sentido seguir confiando en una única puerta de entrada?

La respuesta es precisamente el origen de ZTNA (Zero Trust Network Access).

DEL ACCESO A LA RED, AL ACCESO A LA APLICACIÓN

Imagina que tu empresa es un edificio lleno de oficinas, salas de reuniones y archivos confidenciales.

Durante mucho tiempo la seguridad funcionó igual que la recepción de ese edificio.

Mostrabas tu credencial una sola vez.

Entrabas.

Y desde ese momento podías recorrer prácticamente todos los pasillos.

Así funciona una VPN tradicional.

El problema aparece cuando alguien consigue robar una credencial o comprometer un equipo autorizado. Una vez dentro, el atacante puede desplazarse por la red buscando otros servidores, aplicaciones o información crítica.

En ciberseguridad esto se conoce como movimiento lateral, una de las principales técnicas utilizadas por ransomware y grupos de amenazas avanzadas.

ZTNA rompe completamente este paradigma.

NUNCA CONFÍES, VERIFICA SIEMPRE

La filosofía Zero Trust es sencilla de entender, pero poderosa en su implementación:

Nunca confíes de forma automática. Verifica cada solicitud de acceso.

En lugar de asumir que un usuario es confiable porque ya inició sesión, ZTNA vuelve a validar constantemente distintos factores:

• Identidad del usuario.
• Estado del dispositivo.
• Ubicación.
• Nivel de riesgo.
• Contexto de la conexión.
• Comportamiento observado.

Este proceso recibe el nombre de verificación continua de identidad y postura del dispositivo.

No importa que el usuario haya sido autenticado hace cinco minutos.

Cada nuevo acceso vuelve a evaluarse.

LA PUERTA CORRECTA, Y NADA MÁS

Una buena analogía consiste en imaginar un conserje que acompaña personalmente a cada visitante.

No le entrega las llaves del edificio completo.

Simplemente abre la puerta exacta que necesita.

Después vuelve a cerrarla.

Ese es el principio del mínimo privilegio (Least Privilege Access).

Cada usuario únicamente puede acceder a las aplicaciones necesarias para realizar su trabajo.

Nada más.

Y aquí aparece una diferencia muy importante respecto de una VPN tradicional.

Con ZTNA, las aplicaciones a las que un usuario no tiene autorización simplemente no existen para él.

No aparecen.

No pueden escanearse.

No responden.

Esta característica suele conocerse como infraestructura invisible o Dark Infrastructure, reduciendo considerablemente la superficie de ataque.

¿POR QUÉ ZTNA SE VOLVIÓ TAN IMPORTANTE?

Hace apenas unos años la mayoría de las empresas tenía una infraestructura relativamente sencilla.

Hoy la realidad es completamente distinta.

Las organizaciones conviven con:

• Trabajo híbrido.
• Teletrabajo.
• Servicios SaaS.
• Aplicaciones en múltiples nubes.
• Accesos de terceros.
• Equipos BYOD (Bring Your Own Device).
• Usuarios distribuidos geográficamente.

Las viejas murallas dejaron de proteger aquello que ya no vive dentro de ellas.

Por eso ZTNA se convirtió en uno de los pilares de arquitecturas modernas como SASE (Secure Access Service Edge), donde conectividad y seguridad trabajan de forma integrada para proteger usuarios, dispositivos y aplicaciones sin importar dónde se encuentren.

DOS PILARES TÉCNICOS QUE HACEN LA DIFERENCIA

Microsegmentación

En lugar de tener una red completamente abierta, ZTNA divide la infraestructura en pequeños compartimentos.

Si un incidente ocurre en un segmento, el resto permanece aislado.

El atacante pierde la posibilidad de desplazarse libremente entre servidores y aplicaciones.

Asunción de brecha

Otro principio fundamental del modelo Zero Trust consiste en aceptar una realidad incómoda:

Es posible que un atacante ya esté dentro.

Por eso toda la arquitectura se diseña pensando en limitar el impacto.

No se busca únicamente evitar el ingreso.

También se busca impedir que un incidente pequeño se transforme en una crisis mayor.

BENEFICIOS PARA LA ORGANIZACIÓN

Implementar ZTNA ofrece ventajas concretas tanto para los equipos de TI como para el negocio:

• Reduce significativamente la superficie de ataque.
• Minimiza el movimiento lateral.
• Protege el acceso remoto de colaboradores y terceros.
• Oculta aplicaciones críticas frente a usuarios no autorizados.
• Mejora el control sobre identidades y dispositivos.
• Se adapta naturalmente a entornos híbridos y multinube.
• Disminuye el riesgo asociado al robo de credenciales.

Además, los usuarios continúan trabajando de forma sencilla, sin tener que conectarse permanentemente a una VPN tradicional para acceder a cada recurso.

ZTNA NO ES UN PRODUCTO, ES UNA ESTRATEGIA

Es importante entender que Zero Trust Network Access no consiste simplemente en instalar una nueva plataforma.

Su éxito depende de varios componentes trabajando en conjunto:

• Gestión de identidades (IAM).
• Autenticación Multifactor (MFA).
• Políticas de acceso basadas en riesgo.
• Inventario de dispositivos.
• Evaluación continua de postura de seguridad.
• Monitoreo permanente.

Por esa razón, muchas organizaciones realizan la transición de manera gradual, migrando aplicación por aplicación desde el modelo VPN hacia un esquema Zero Trust.

LA SEGURIDAD YA NO DEPENDE DE LAS MURALLAS

Durante muchos años protegimos redes.

Hoy debemos proteger identidades, aplicaciones y datos.

ZTNA representa ese cambio de paradigma.

Ya no importa desde dónde trabaja una persona.

Lo importante es verificar constantemente quién es, qué dispositivo utiliza, qué necesita hacer y si realmente debería tener acceso.

Porque en el escenario actual, confiar únicamente en una muralla puede ser suficiente… hasta el día en que alguien consiga atravesarla.

Y cuando eso ocurra, la diferencia entre contener un incidente o enfrentar una crisis dependerá de cuánto confíe tu organización en la verificación continua y no en la confianza implícita.

CONCLUSIÓN

El modelo Zero Trust Network Access (ZTNA) redefine la forma en que las organizaciones protegen sus recursos digitales. En lugar de otorgar acceso amplio tras una única autenticación, valida continuamente la identidad, el dispositivo y el contexto de cada conexión, reduciendo riesgos como el movimiento lateral y adaptándose a entornos híbridos y multinube.

En CompuNet, ayudamos a las organizaciones a evolucionar hacia arquitecturas de acceso seguro, integrando soluciones Zero Trust, SASE, gestión de identidades y estrategias de ciberseguridad que protegen el negocio sin afectar la productividad.

Porque hoy, la mejor defensa ya no consiste en construir murallas más altas, sino en verificar cada acceso, en cada momento y para cada recurso.

Cuando hablamos de ciberseguridad, muchas organizaciones siguen creyendo que contratar un seguro cibernético es suficiente para estar protegidas frente a un ataque.

La realidad es bastante distinta.

Un ciberseguro puede ayudar a reducir el impacto económico de un incidente, pero no evita que ocurra. Tampoco reemplaza las medidas preventivas que hoy exigen tanto las aseguradoras como las nuevas regulaciones en Chile.

En otras palabras, el seguro financiero comienza donde termina la ciberseguridad.

Y entender esa diferencia puede marcar el futuro de una organización.

EL CRECIMIENTO DEL SEGURO CIBERNÉTICO EN CHILE

Los ciberataques continúan aumentando en frecuencia y sofisticación.

Ransomware, robo de credenciales, phishing dirigido, fraude mediante inteligencia artificial y filtraciones de datos se han convertido en riesgos cotidianos para empresas de todos los tamaños.

Como consecuencia, cada vez más organizaciones están evaluando contratar un seguro cibernético para proteger su continuidad operacional.

Sin embargo, antes de hacerlo conviene responder una pregunta:

¿QUÉ CUBRE UN SEGURO CIBERNÉTICO?

Aunque cada aseguradora establece condiciones particulares, normalmente las pólizas incluyen coberturas como:

Continuidad operacional

Compensación por pérdidas derivadas de la interrupción del negocio.

Restauración tecnológica

Recuperación de servidores, aplicaciones, bases de datos y estaciones de trabajo.

Gestión de incidentes

Acceso a especialistas en:

• Respuesta a incidentes
• Informática forense
• Comunicación de crisis
• Asesoría legal

Responsabilidad frente a terceros

Cobertura por reclamaciones derivadas de filtraciones de datos personales.

Extorsión digital

Algunas pólizas consideran gastos relacionados con incidentes de ransomware y negociaciones especializadas.

EL ERROR QUE MUCHAS EMPRESAS DESCUBREN DEMASIADO TARDE

Una póliza puede indicar una cobertura de cientos de miles de dólares.

Pero eso no significa que todas las situaciones estén cubiertas.

Cada componente posee sublímites específicos.

Por ejemplo:

• Recuperación tecnológica
• Lucro cesante
• Defensa jurídica
• Restauración de datos

Cada uno tiene un monto máximo independiente.

Revisar estos detalles puede evitar falsas expectativas durante un incidente.

HOY LAS ASEGURADORAS TAMBIÉN EVALÚAN TU NIVEL DE CIBERSEGURIDAD

Hace algunos años bastaba completar un formulario.

Hoy las aseguradoras quieren evidencias.

Entre los controles más solicitados encontramos:

✔ Autenticación Multifactor (MFA)

✔ Gestión de Accesos Privilegiados (PAM)

✔ Copias de respaldo Air-Gapped

✔ Gestión continua de vulnerabilidades

✔ Aplicación oportuna de parches

✔ Gestión de identidades

✔ Segmentación de redes

✔ Arquitectura Zero Trust

Una empresa que demuestra madurez en estos controles suele acceder a mejores condiciones de aseguramiento.

LA LEY 21.719 CAMBIA EL ESCENARIO

La nueva Ley de Protección de Datos Personales (Ley 21.719) aumenta significativamente las responsabilidades de las organizaciones respecto del tratamiento de información.

Si ocurre una brecha de seguridad, ya no basta con recuperar la operación.

También existen obligaciones legales, reputacionales y regulatorias.

Por eso el seguro debe entenderse como una herramienta financiera complementaria y no como una estrategia de protección.

LA INTELIGENCIA ARTIFICIAL TAMBIÉN LLEGÓ AL FRAUDE

Los ataques mediante deepfake, Fraude del CEO, vishing y phishing impulsado por IA ya forman parte del panorama actual.

Algunas aseguradoras comienzan a incorporar coberturas específicas para estos riesgos.

Sin embargo, las condiciones cambian constantemente.

Por ello es indispensable revisar cuidadosamente las exclusiones antes de contratar.

EL MEJOR SEGURO SIGUE SIENDO PREVENIR

Las organizaciones más resilientes no son aquellas que poseen la póliza más costosa.

Son aquellas que invierten primero en prevención.

Implementar:

• MFA
• PAM
• Zero Trust
• Monitoreo continuo
• Backups aislados
• Gestión de vulnerabilidades

reduce considerablemente la probabilidad de sufrir un incidente y, al mismo tiempo, mejora las condiciones para acceder a un seguro.

La prevención continúa siendo la inversión más rentable.

TRES PREGUNTAS ANTES DE CONTRATAR UN CIBERSEGURO

Antes de firmar una póliza, pregúntate:

• ¿Nuestra empresa cumple los controles mínimos que exigen hoy las aseguradoras?
• ¿Conocemos realmente las exclusiones y sublímites del contrato?
• ¿Tenemos un plan para responder a un incidente incluso si el seguro no cubre todos los costos?

Responder estas preguntas permitirá tomar una decisión mucho más informada.

CONCLUSIÓN

El crecimiento del mercado de seguros cibernéticos en Chile demuestra que las organizaciones son cada vez más conscientes de los riesgos digitales.

Sin embargo, ninguna póliza reemplaza una estrategia sólida de ciberseguridad.

El seguro ayuda a recuperarse.

La ciberseguridad ayuda a evitar el incidente.

En CompuNet trabajamos junto a nuestros clientes para fortalecer su postura de seguridad mediante soluciones de prevención, monitoreo, protección de identidades, gestión de accesos privilegiados y respuesta ante incidentes, ayudándolos a construir organizaciones más resilientes antes de que el seguro tenga que entrar en acción.