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.