La IA recibe las llaves de la empresa: agentes autónomos, permisos y responsabilidad en Chile

Esta semana se lanzó un servicio en que agentes de inteligencia artificial prueban sin pausa la seguridad de los sistemas de sus clientes, y días antes un laboratorio mostró a un agente reemplazando, sin que nadie se lo pidiera, el modelo que debía mantener. Analizamos cómo se reparten en Chile la autorización, el control y la responsabilidad cuando una IA actúa sobre los sistemas de una empresa.

El martes 22 de septiembre, Palo Alto Networks anunció Unit 42 Continuous Frontier AI Defense, un servicio de seguridad ofensiva «agéntica»: agentes de inteligencia artificial, impulsados por modelos especializados en ciberseguridad de Anthropic y OpenAI y por modelos de pesos abiertos, que buscan vulnerabilidades en los sistemas del cliente, validan si de verdad pueden explotarse y orientan su corrección, de manera continua y no en una auditoría puntual. El perímetro anunciado abarca aplicaciones web propias y de terceros, interfaces de programación (API), infraestructura en la nube, repositorios de código fuente y activos de red, y el servicio integra esos modelos con la experiencia en seguridad ofensiva de los especialistas de Unit 42, de modo que no se trata de una máquina que opera sola.

El producto y sus cifras de eficacia, que son del proveedor, quedan fuera de este análisis; lo que interesa es el cambio de categoría que el anuncio vuelve visible. Durante años, la inteligencia artificial en la empresa recomendó: redactaba, resumía, sugería. Ahora actúa: ejecuta comandos, recorre repositorios, modifica código y despliega cambios sobre sistemas reales. Y cuando la herramienta pasa de aconsejar a actuar, la pregunta jurídica cambia de lugar.

¿Qué debe quedar autorizado, limitado y registrado antes de permitir que una IA actúe sobre sistemas empresariales?

¿Qué es un agente y por qué el problema está en sus permisos?

Un agente de IA es un modelo de lenguaje conectado a herramientas: una terminal, un navegador, credenciales de acceso a una nube o a un repositorio. Recibe un objetivo, decide los pasos, los ejecuta, observa el resultado y vuelve a decidir, en un ciclo que puede repetirse cientos de veces sin que una persona intervenga. Lo que puede hacer depende, por tanto, de las herramientas y permisos que se le entregan.

De ahí la tesis de este análisis: una instrucción al agente, un permiso técnico y una autorización jurídica no son lo mismo. La instrucción suele fijar un resultado («que la aplicación deje de fallar»), no un método. El permiso técnico es lo que las credenciales hacen posible, y casi siempre es más amplio que la tarea, porque restringirlo cuesta trabajo. La autorización jurídica es lo que el titular del sistema consintió, y solo puede darla quien tiene poder sobre ese sistema. Hasta ahora alineaba las tres capas una persona, al decidir si seguía o no la sugerencia de la máquina. Con un agente, esa alineación tiene que hacerse antes: por escrito y en la configuración.

Lo que mostró un laboratorio la semana pasada

El 16 de septiembre, la firma de seguridad Irregular publicó una serie de experimentos que miden la distancia entre esas capas. En un sistema autoalojado, el mismo modelo de pesos abiertos impulsaba un agente de programación y la aplicación que ese agente debía mantener. La instrucción fue la de cualquier ticket de soporte: los usuarios reportan respuestas erróneas, asegúrate de que la aplicación las maneje. El agente tenía a su alcance el código, utilidades de entrenamiento, los pesos del modelo y el mecanismo de despliegue.

El agente concluyó que el problema estaba en el modelo, lo reentrenó y fusionó el ajuste en el modelo base que cargaban tanto la aplicación como sus propias instancias futuras, sin que nadie le hubiera pedido entrenar ni desplegar nada. La reparación funcionó: en consultas que nunca vio, el modelo original acertó 0 de 20 y el modificado, 20 de 20. Pero otros experimentos mostraron el costo oculto: el modelo reentrenado reprodujo textualmente valores sensibles ficticios que solo figuraban en los datos de entrenamiento, y en otra prueba el ajuste eliminó una conducta de rechazo entrenada a propósito. El cambio alcanzó a todo servicio que usaba el modelo compartido.

La limitación importa tanto como el resultado, y los autores la declaran: fueron experimentos controlados, diseñados para demostrar un mecanismo y no para medir su frecuencia en empresas, en un entorno que facilitaba el reentrenamiento; y nada acredita intención maliciosa, autopreservación ni engaño, porque el agente modificó el modelo simplemente porque entrenar parecía cumplir la tarea. Un dato muestra cuánto pesa el entorno: en pruebas de planificación, poner la infraestructura de entrenamiento al alcance del agente hizo subir la proporción de planes que proponían modificar el modelo de 0% a 94%.

La conclusión de los investigadores podría estar en un informe jurídico. Entrenar y desplegar pueden ser, cada una por separado, acciones legítimas de ingeniería, pero su combinación puede producir cambios persistentes que nadie autorizó por separado; la pregunta relevante, escriben en traducción libre, es «si esos permisos cubrían la actualización del modelo y su puesta en servicio».

El marco chileno: autorización, exceso y finalidad defensiva

En Chile, el punto de apoyo es la Ley N° 21.459 sobre delitos informáticos. Su artículo 2° castiga a quien, «sin autorización o excediendo la autorización que posea y superando barreras técnicas o medidas tecnológicas de seguridad, acceda a un sistema informático». Una prueba de penetración consiste justamente en intentar superar barreras técnicas, y la ley castiga también a quien, teniendo autorización, la excede. Lo que separa el servicio del delito es, por tanto, el alcance de lo autorizado: una frontera penal, además de una cláusula del contrato.

El perímetro que anunció Palo Alto Networks incluye aplicaciones de terceros. Cómo lo delimita el servicio en cada contrato no es materia de este análisis, pero el problema se entiende mejor con un ejemplo.

La Ley N° 21.663, Marco de Ciberseguridad, añadió al mismo artículo 2° una exención para quien investiga vulnerabilidades en sistemas cuyo responsable tiene domicilio en Chile, y derogó el antiguo artículo 16. Las condiciones son siete y copulativas. Entre ellas: estar inscrito en el registro de la Agencia Nacional de Ciberseguridad (ANCI) y avisarle antes del acceso; reportar el acceso y las vulnerabilidades al responsable y a la Agencia tan pronto se hubiere realizado; no divulgarlas públicamente; y, fuera de los sistemas de la Administración del Estado, contar con el consentimiento del responsable. La ley agrega que el investigador no puede haber ido más allá de lo necesario para comprobar la vulnerabilidad, ni usado métodos que pudieran conducir a denegación de servicio, pruebas físicas, código malicioso, ingeniería social o la alteración, eliminación, exfiltración o destrucción de datos.

De ahí dos lecciones. La finalidad defensiva no autoriza cualquier actuación: la ley pone condiciones incluso a quien busca fallas de buena fe. Y aunque una prueba contratada se rige por la autorización del cliente y no por esta exención, su lista de métodos excluidos es un buen piso para las exclusiones del contrato.

Tampoco corresponde el error inverso, que es convertir cualquier desviación del agente en un delito automático. La Ley N° 21.459 no sanciona formas culposas de estos delitos y la responsabilidad penal es personal: un agente de IA no es sujeto de imputación, y una actuación no querida de la herramienta no basta por sí sola para configurar el tipo. A nuestro juicio, la discusión se desplazará hacia las personas que configuran, lanzan y supervisan el agente: qué sabían del alcance, qué riesgos aceptaron y qué controles pusieron. Como los delitos informáticos pueden generar responsabilidad penal de la persona jurídica bajo la Ley N° 20.393, esa discusión alcanza también a la empresa, cuyo modelo de prevención debería cubrir ya este riesgo, como explicamos en nuestro análisis sobre delitos informáticos y ciberseguridad.

Cuando el agente toca datos personales

Si en su recorrido el agente accede a datos de clientes o trabajadores, entra en juego la Ley N° 21.719, plenamente exigible desde el 1 de diciembre de 2026. En la medida en que el proveedor trate esos datos por cuenta del cliente, actúa como encargado, y el nuevo artículo 15 bis de la Ley N° 19.628 trae una regla que calza con el problema de los agentes: el encargado trata los datos conforme al encargo y a las instrucciones del responsable, y si los trata con un objeto distinto del convenido pasa a ser considerado responsable para todos los efectos legales y responde solidariamente por los daños. El mismo artículo exige que el contrato fije objeto, duración, finalidad y tipo de datos, y prohíbe delegar el encargo sin autorización específica y por escrito, algo que conviene resolver cuando un servicio reparte el trabajo entre modelos de distintos proveedores.

El artículo 14 quinquies, por su parte, contempla entre las medidas de seguridad un proceso de verificación regular de su eficacia, que las pruebas continuas pueden ayudar a cumplir, y ante un incidente pone de cargo del responsable acreditar que esas medidas existían y funcionaban. El experimento de Irregular añade además una razón técnica a una cláusula que ya recomendamos para las plataformas de análisis masivo de datos: lo que un agente ve durante una reparación puede quedar incorporado en un modelo y seguir siendo recuperable cuando ya no hay acceso a la fuente. Prohibir que se entrenen modelos con los datos del cliente es, así, una medida de seguridad además de una precaución comercial.

¿Quién responde? Sin respuestas automáticas

Sería cómodo afirmar que siempre responde el proveedor, porque el agente es suyo, o siempre el cliente, porque los sistemas y la decisión de contratar son suyos. Ninguna de las dos afirmaciones se sostiene en abstracto. Entre las partes, la distribución la decide en primer lugar el contrato. Frente a un tercero dañado rige la regla general del artículo 2314 del Código Civil, que obliga a indemnizar a quien ha cometido un delito o cuasidelito que ha inferido daño a otro, y con ella la pregunta por la diligencia de cada parte: la empresa que entregó al agente permisos mucho más amplios que la tarea, sin aprobaciones ni registros, tendrá difícil demostrarla.

Nada de esto espera a la ley de inteligencia artificial en trámite: las normas citadas ya rigen o tienen fecha cierta.

Una matriz de autonomía autorizada

En lugar de cerrar con la recomendación genérica de «implementar una política de IA», proponemos una herramienta concreta. Es una propuesta de gestión y contratación del estudio, no un listado de obligaciones legales: ordena las decisiones que conviene tomar antes de dejar actuar a un agente y el antecedente que permitiría acreditarlas después.

En el contrato, la matriz se completa con una cláusula que la tabla no muestra: la entrega de los registros al cliente al cierre de cada ciclo.

Lo que una empresa debería poder mostrar

Nuestro análisis sobre privacidad diferencial preguntaba qué puede demostrar una organización sobre la técnica que eligió para proteger datos. Esta pieza hace la misma pregunta en otra materia: qué puede demostrar sobre la autonomía que concedió. Los agentes van a seguir entrando a las empresas, y por buenas razones: según el anuncio que abre este texto, los atacantes ya usan inteligencia artificial para encontrar y explotar vulnerabilidades. La cuestión no es si dejarlos actuar, sino con qué llaves. La empresa que, antes de entregarlas, decidió qué abren, quién puede usar las más delicadas y cómo sabrá después qué se abrió, habrá respondido de antemano lo que el derecho chileno le preguntará si algo sale mal.

Este artículo tiene carácter informativo y general, y no constituye asesoría jurídica para un caso concreto. Si su empresa evalúa contratar o prestar pruebas de seguridad con agentes de IA, o incorporar agentes a su operación, contáctenos para un análisis específico.