Agentes de IA que corrigen código: el riesgo escondido

Imagina que contratas a alguien para cambiar la cerradura de la puerta. La persona la cambia, la prueba, funciona. Solo que en el proceso dejó la ventana del fondo sin trabar. Y nadie fue a mirar la ventana, porque el pedido era sobre la puerta. Algo así pasó en Snowflake, una empresa de datos que factura miles de millones: un agente de IA corrigió una falla de seguridad y, en la misma jugada, creó el camino para invadir el Jira interno de la compañía.

El detalle que duele es que la corrección la hizo una herramienta buena, respetada, usada por mucha gente seria. Copilot Autofix, de GitHub, sugiere parches automáticos para vulnerabilidades encontradas en el código. Alguien revisó por encima, aprobó, hizo el merge. El equipo siguió adelante creyendo que estaba resuelto. Investigadores de Wiz encontraron el hueco después.

Qué salió mal exactamente

El objetivo era un script de automatización del repositorio, de esas rutinas que corren solas cuando alguien abre un pull request o comenta en un issue. Es código que casi nadie lee con cariño. No tiene pantalla, no tiene cliente mirando, solo hace el trabajo aburrido de conectar cosas.

La falla original era conocida: datos que venían de afuera entraban directo al script. La IA generó una corrección que trataba el caso específico señalado en la alerta. Bonito. Solo que el script siguió aceptando entrada no confiable por otro camino, y ese camino tenía acceso a las credenciales que la automatización usa para hablar con Jira. Resultado: quien supiera escribir el comentario correcto en un lugar público podía hacer que el robot de Snowflake trabajara para él ahí adentro.

Fíjate en la mecánica, porque se repite en contextos que no se parecen en nada a la programación:

• La IA respondió exactamente la pregunta que le hicieron.
• La pregunta era demasiado estrecha.
• Nadie revisó el entorno, porque la alerta se había puesto en verde.

La alerta verde es el villano silencioso de esta historia. Un problema abierto molesta, genera reuniones, alguien lo reclama. Un problema marcado como resuelto desaparece del radar para siempre.

Por qué esto le importa a quien no escribe código

Puedes estar pensando que esto es asunto del equipo de ingeniería. No lo es. Cambia "script de CI/CD" por cualquier automatización que corre en tu negocio hoy.

El agente que responde el correo del cliente. El robot que saca el pedido de WhatsApp y lo carga en el ERP. La rutina que lee la factura y la registra en finanzas. La IA que filtra currículums y mueve al candidato de etapa. Todos tienen la misma anatomía: reciben datos de afuera, tienen alguna credencial guardada, y actúan sin que nadie mire.

Ya vi un caso menor con la misma cara. Una automatización de atención que creaba tickets a partir del formulario del sitio. Alguien descubrió que se podía escribir en el campo "asunto" un texto que la IA leía como instrucción y no como contenido. El ticket se convertía en una consulta a la base de clientes, y la respuesta volvía a la persona en el correo de confirmación. Nadie había invadido nada. La puerta estaba abierta por diseño, y la IA fue demasiado educada para desconfiar.

La automatización no se equivoca poco. Se equivoca rápido y en silencio.

El punto ciego es la IA revisando a la propia IA

Aquí va mi opinión fuerte del artículo: el patrón más peligroso que se está expandiendo en 2026 es la IA aprobando el trabajo de la IA.

El flujo se volvió común. Un agente escribe. Otro agente revisa. Un tercero corre las pruebas que escribió el primero. En el papel parece rigor. En la práctica, los tres comparten el mismo punto ciego, porque leyeron el problema desde el mismo encuadre. Es como pedirle a tres personas que revisen la suma de la cuenta cuando el error está en la carta.

Y hay un efecto psicológico de la mano. Cuando el texto del parche llega bien escrito, con explicación clara y justificación convincente, el humano revisa menos. Un pull request de IA parece más confiable que uno de un pasante, incluso cuando es peor. La confianza generada por buena redacción es la cosa más barata que existe hoy.

No estoy diciendo que abandones las herramientas. Uso agentes de IA todos los días y me ahorran horas reales. Estoy diciendo que la revisión tiene que venir de un ángulo distinto al que generó el cambio.

Cómo usar agentes de IA sin este tipo de sorpresa

Lo que funciona no es complicado, es aburrido. Y lo aburrido es justamente lo que la gente se salta.

Separa quién puede actuar de quién solo puede hablar. Si un agente lee pedidos de clientes, no debería tener la misma credencial que crea usuarios en el sistema. Dos cuentas, dos niveles. Eso resuelve la mitad de los incidentes que existen.

Da el menor permiso posible, no el más cómodo. La automatización de Snowflake tenía acceso amplio a Jira porque un día fue más fácil así. Casi toda credencial demasiado amplia empezó como un ahorro de tiempo en una tarde apurada.

Trata la entrada externa como sospechosa, siempre. Comentario de usuario, formulario, correo, mensaje de WhatsApp, nombre de archivo. Nada de eso es instrucción. Es contenido. Si tu automatización no hace esa distinción, va a obedecer al primer extraño educado que aparezca.

Pide el contexto, no solo la corrección. Cuando un agente propone un cambio, la pregunta útil no es "¿esto lo resuelve?". Es "¿qué más toca este archivo, y qué pasa a permitir este cambio que antes no permitía?".

Pon un humano en el punto del dinero y del dato sensible. No en todo. En transferencias, alta de proveedores, envíos masivos, borrados. El resto puede correr solo.

Revisa lo que ya está en verde. Una vez por trimestre, abre lo que fue marcado como resuelto por automatización y míralo de nuevo. Es la auditoría más barata que existe y nadie la hace.

El tamaño correcto de la desconfianza

Nada de esto significa miedo. Significa calibración.

Snowflake no es una empresa descuidada. Tiene equipo de seguridad, tiene proceso, tiene buenas herramientas. Aun así, un parche automático generó una puerta nueva. Si pasa ahí, pasa en tu operación de 20 personas, con la diferencia de que allá alguien lo encontró antes de que se volviera una mala noticia.

La forma sana de pensar en un agente de IA es como un empleado nuevo, rápido, incansable y literal. Va a hacer exactamente lo que le pediste, a tiempo, sin quejarse. Y es justamente por eso que el cuidado tiene que estar en el pedido y en el límite de acceso, no en la esperanza de que use el sentido común. El sentido común es lo único que no tiene.

La automatización bien hecha no es la que hace más cosas sola. Es la que sabe dónde parar y llamar a alguien.

Si estás montando automatizaciones con IA en tu negocio y quieres que alguien mire el diseño antes de que se convierta en problema, echa un vistazo a cómo trabajo. Media hora de conversación suele ahorrar bastante dolor de cabeza después.

Un agente de IA de Snowflake corrigió una falla de seguridad y, en el mismo commit, abrió la puerta para invadir el Jira interno de la empresa.

El parche estaba bien. El problema es que la pregunta era demasiado estrecha.

La alerta se puso en verde, nadie miró alrededor, y un problema marcado como resuelto desaparece del radar para siempre.

Esto no es asunto solo del equipo de ingeniería. Cambia "script de CI/CD" por el robot que lee tu WhatsApp y carga pedidos en el ERP. Misma anatomía: recibe datos de afuera, guarda credenciales, actúa sin que nadie mire.

El patrón más peligroso de 2026 es la IA aprobando el trabajo de la IA. Tres agentes revisando la suma cuando el error está en la carta.

Un agente de IA es como un empleado nuevo, rápido y literal. El sentido común es lo único que no tiene, así que el cuidado tiene que estar en el pedido y en el límite de acceso.

Si estás montando automatizaciones con IA en tu negocio, vale la pena revisar el diseño antes de que se convierta en problema. Escríbeme.

#InteligenciaArtificial #Automatizacion #SeguridadDeLaInformacion #Tecnologia #Negocios