IA AGÉNTICA:
DEL DISEÑO AL CONTROL
Agentes · Skills · Gobernanza
actúan y deben poder ser controlados
De piloto a producción, de un agente a muchos.
Capacidades instalables, y su cadena de riesgo.
Identidad, trazabilidad y control humano.
Del diseño
al control
La inteligencia artificial está entrando en una nueva etapa. Ya no hablamos únicamente de sistemas capaces de generar contenido, sino de agentes que pueden planificar, utilizar herramientas, interactuar con otros sistemas y ejecutar acciones con distintos niveles de autonomía.
Ese cambio amplía las posibilidades de aplicación de la IA, pero también modifica las preguntas que organizaciones, desarrolladores y equipos responsables deben hacerse. Cuando un sistema puede actuar, ya no basta con evaluar la calidad de sus respuestas. Importa también saber a qué información accede, qué permisos posee, qué herramientas utiliza, cómo se relaciona con otros agentes y quién conserva la capacidad de supervisar sus decisiones.
Esta segunda edición de LATAMIA aborda precisamente ese tránsito: del diseño al control.
Los artículos recorren distintas capas de un mismo desafío. Desde las condiciones necesarias para llevar agentes a producción y la arquitectura de sistemas multiagente, hasta la seguridad de las skills, la trazabilidad de decisiones distribuidas y los mecanismos de gobernanza que permiten establecer límites frente a sistemas cada vez más autónomos.
¿Cómo diseñamos sistemas capaces de actuar sin perder la capacidad humana y organizacional de comprenderlos, supervisarlos y controlarlos?
Contenido
Cinco artículos técnicos sobre agentes, skills y gobernanza. Haz clic en cualquier título para ir directamente a la página.
Strategic AI Framework
Arquitectura y gobernanza
SkillSpector, NVIDIA
La genealogía de una decisión
Identidad, privilegios y supervisión
Por qué tu agente de IA no llega a producción
El salto del piloto a producción no es un problema tecnológico: es un problema organizacional.
EJECUTIVO
El 80 % de las organizaciones en América Latina ya usa inteligencia artificial, pero solo el 15 % la adopta de forma sostenible y con valor real. La tesis de Yoko Pérez es incómoda para los equipos técnicos: el salto del piloto a producción no es un problema tecnológico, es un problema organizacional. El agente puede estar impecablemente construido y aun así no llegar nunca a producción — porque no estaba alineado con la estrategia, porque nadie entendió el problema de fondo, porque no hubo gestión del cambio, o porque faltó gobierno.
de las organizaciones en América Latina ya usa inteligencia artificial
la adopta de forma sostenible y con valor real (Gartner)
1. La historia que se repite
Empieza bien. Un equipo construye un agente de IA, técnicamente sólido, con la convicción de que va a cambiar el negocio. Pero cuando llega el momento de lanzarlo, la organización empieza a hacer preguntas que nadie hizo antes: ¿para qué lo vamos a usar? ¿reduce costos? ¿ayuda a operaciones? Y ahí aparece el primer problema: como resume Pérez, estaba fantásticamente hecho, pero no era hacia donde la empresa iba.
Al probarlo, aparece el segundo: no era lo que los usuarios esperaban. No se entendió a fondo el problema, ni al usuario, ni el contexto; buena parte del diseño se hizo sobre suposiciones. «Sin descubrimiento y sin diseño, la solución —aunque sea muy bonita— puede estar resolviendo el problema equivocado, y de forma equivocada.»
El tercero llega al liberar: el piloto funcionaba con un grupo acotado, pero el resto no lo adopta. No hubo preparación, ni comunicación, ni formación, ni acompañamiento. La respuesta del equipo es predecible: «sigo haciendo las cosas como las hago; no quiero cambiar». Y el cuarto cierra el círculo: se lanzó sin revisar seguridad ni datos sensibles, sin políticas claras, sin saber quién decide ni ante quién se responde cuando algo falla, con sesgos que producen decisiones injustas. Sin gobernanza, seguridad ni ética no hay confianza; y sin confianza no hay adopción.
Usar IA no es lo mismo que adoptar IA. Adoptar IA es convertirla en una capacidad de la organización.
2. El error de diagnóstico
Cuando un agente no llega a producción, el instinto es señalar el último tramo: la idea, la prueba de concepto, la demo, el piloto… y el salto a producción. Ahí parece morir el proyecto. Pero, como plantea Pérez, el problema empezó mucho antes: en decisiones tomadas antes de escribir una línea de código.
La pregunta correcta, entonces, no es «¿cómo construimos el agente?» sino «¿estamos construyendo el camino para que realmente genere valor?». Ese camino tiene cinco tramos: estrategia de IA, entendimiento del problema, alineación con el negocio, diseño de la solución, y gobierno, gestión del cambio y métricas para escalar con seguridad.
Dónde puede aportar valor y hacia dónde vamos.
Con datos y descubrimiento real: ¿es frecuente e importante?
Lo más brillante para nosotros puede no ser hacia donde va la empresa.
Atacar la causa raíz, no emular lo que ya hacemos.
Gestión del cambio y métricas para escalar con seguridad.
No es un proceso lineal ni una secuencia obligatoria: se dibuja así para que sea fácil de leer, pero cada organización entra por donde su etapa lo pide, porque las organizaciones no adoptan IA siguiendo una única ruta: construyen capacidades mediante aprendizaje, adaptación y evolución continuos. Las dos capas transversales no son decorativas: sin ellas, todo lo demás «se sostiene en un hilo».
3. Cuánto cuesta quedarse en el piloto
Tres casos reales de la región, anonimizados.
Pero el dinero es la parte fácil de contar. Lo que no aparece en el balance es más caro: tiempo perdido de equipos completos, confianza erosionada, equipos desmotivados, riesgo reputacional y, sobre todo, oportunidades perdidas: mientras tu agente no escalaba, la competencia sí lo hizo.
4. El Strategic AI Framework
Marco abierto y gratuito publicado por la autora, con herramientas incluidas para cada pregunta.
5. Medir antes de construir
El AI Maturity Radar evalúa seis pilares, cada uno puntuado de 1 a 5:
6. Los ocho dilemas estratégicos
7. Conclusiones
Si tu agente no llegó a producción, probablemente el problema no estuvo en el modelo: estuvo en las decisiones que se tomaron —o no se tomaron— antes de construirlo. El costo de quedarse en el piloto se paga en confianza, y esa moneda es la más difícil de recuperar. Medir antes de construir evita invertir diez meses en algo que la organización todavía no puede sostener. Para la región, si el 80 % ya usa IA y solo el 15 % la adopta bien, hay un 65 % de organizaciones a un paso de generar valor real — y ese paso no exige más presupuesto de cómputo, sino estrategia, gobierno y gestión del cambio.
CEO y fundadora de Akunia Global (México), embajadora de la Comunidad IA LATAM. Autora del Strategic AI Framework.
Orquestación multiagente: por qué el 40 % de estos proyectos morirá antes de 2028
El cuello de botella de la IA agéntica en 2026 no es el modelo: es el diseño y es el gobierno.
EJECUTIVO
Gartner proyecta que el 40 % de los proyectos de IA agéntica será cancelado antes de que termine 2028, por costos que escalan, valor de negocio poco claro y controles de riesgo insuficientes. Masís recorre la anatomía completa de la orquestación multiagente para llegar a una conclusión que combina ingeniería y derecho: la confiabilidad de una cadena de agentes se multiplica, no se promedia, y ningún reparto de la ejecución reparte la responsabilidad jurídica.
de los proyectos de IA agéntica se cancelará antes de finalizar 2027 (Gartner)
empresas realmente «agénticas», de los miles que se anuncian como tales
definición canónica de agente, de Wooldridge y Jennings
1. El punto de partida
En su comunicado del 25 de junio de 2025, Gartner estimó que más del 40 % de los proyectos de IA agéntica se cancelará antes de finalizar 2027. De los miles de empresas que se anuncian como «agénticas», la firma calcula que apenas unas 130 lo son realmente.
La formulación canónica de agente es de Wooldridge y Jennings (1995): un sistema situado en un entorno con cuatro propiedades: autonomía, reactividad, proactividad y habilidad social. Un sistema multiagente es un conjunto de estos agentes resolviendo un problema que ninguno resolvería solo.
El campo tiene más de cuarenta años: Contract Net (Reid G. Smith, 1980) formalizó la negociación entre nodos; Marvin Minsky propuso la mente como agentes simples coordinados en Society of Mind (1986); Wooldridge y Jennings fijaron la teoría en 1995. Lo que cambió en 2023 no fue la arquitectura, sino el sustrato: el modelo de lenguaje se convirtió en el motor de razonamiento.
Opera sin intervención directa.
Percibe y responde al entorno.
Toma iniciativa por un objetivo.
Interactúa con otros agentes o personas.
2. Anatomía: cinco piezas y cinco patrones
Todo sistema orquestado tiene cinco componentes. Si a tu proyecto le falta memoria o protocolo, no tienes un sistema multiagente: tienes varias llamadas a un modelo.
Descompone el objetivo, asigna trabajo y sintetiza el resultado.
Ejecutan una tarea acotada con su propia ventana de contexto.
Persiste el plan y los hallazgos más allá del contexto.
Dan acceso al mundo real.
Define cómo se descubren, hablan y autentican entre sí.
La inteligencia se puede repartir. La escritura no.
3. La evidencia: la ganancia y su precio
En la evaluación interna de Anthropic, un sistema con agente líder y subagentes en paralelo superó en 90,2 % al mismo modelo trabajando solo, en consultas de exploración amplia. Pero un agente único consume unas cuatro veces más tokens que un chat; un sistema multiagente, unas quince veces, y el consumo de tokens explica por sí solo el 80 % de la variación de desempeño.
Diez pasos que aciertan el 95 % de las veces dan 0,95¹⁰ ≈ 60 % de confiabilidad extremo a extremo. El diseño correcto no maximiza el número de agentes: minimiza el número de pasos que pueden fallar sin ser verificados.
El 12 de junio de 2025 Cognition publicó su tesis: no construyan sistemas multiagente. Al día siguiente, Anthropic publicó cómo construyó el suyo y por qué funciona. La síntesis de 2026 es el consenso práctico: orquestador con contexto continuo, subagentes efímeros de solo lectura, y nada de enjambres escribiendo en paralelo.
4. Dónde se rompe: catorce formas de fallar
El estudio MAST (UC Berkeley) analizó más de 1.600 trazas de ejecución en siete frameworks y clasificó los fallos en catorce modos, en tres categorías: especificación y diseño (la más frecuente), desalineación entre agentes, y verificación y terminación (la más cara de descubrir). Su conclusión: la mayoría de los fallos proviene del diseño del sistema, no de la capacidad del modelo. Cambiar de modelo no los arregla.
5. Gobernanza: quién responde cuando falla
Un sistema sin un único responsable técnico sigue teniendo un único responsable jurídico. Imputación distribuida: la responsabilidad se reparte según control efectivo y deber de cuidado. Trazabilidad probatoria: sin registro de qué agente decidió qué, no hay defensa posible. Deber de supervisión: la autonomía delegada no traslada el deber de vigilancia. La pregunta que resuelve un incidente no es cuál agente falló, sino quién tenía el deber de evitarlo.
El marco ya existe: ISO/IEC 42001 (sistema de gestión de IA, certificable), el NIST AI RMF (gobernar, mapear, medir, gestionar) y el Reglamento Europeo de IA, con efecto extraterritorial. ISO/IEC 42001 no otorga presunción de conformidad frente al reglamento europeo; la norma armonizada en preparación es la prEN 18286.
Transparencia art. 50 (ya en vigor)
Nuevas prohibiciones y transparencia
Alto riesgo, anexo III
Alto riesgo en productos regulados
6. Antes de dar permiso de escritura
Seis condiciones. Deben cumplirse las seis.
7. Noventa días, tres tramos
Inventariar agentes operando, con qué permisos y a nombre de quién.
Orquestador y subagentes de solo lectura, midiendo costo y verificación.
Política de permisos, responsable nombrado, decidir con datos.
8. Conclusiones
La orquestación es una decisión de costo, no de moda. La confiabilidad se multiplica, no se promedia. Y la arquitectura reparte la ejecución, pero el derecho no reparte la responsabilidad: si nadie tiene nombre y apellido asignado al sistema, el sistema no tiene dueño.
Abogada, MBA. Fundadora de Techsecure AI y Masís Alliance, 22 años en HP, IBM, Microsoft. Embajadora de Comunidad IA LATAM en Costa Rica.
¿Qué trae esta receta? Auditar las skills de tu agente antes de instalarlas
Una skill no es solo texto: trae código, y el código se ejecuta con los permisos de tu agente.
EJECUTIVO
Las skills convirtieron a los agentes de IA en algo extensible: cualquiera puede escribir un procedimiento y compartirlo. El problema es que una skill no es solo texto — trae código, y el código se ejecuta con los permisos de tu agente. Un estudio sobre más de 31.000 skills encontró que el 26,1 % tiene al menos una vulnerabilidad y el 5,2 % patrones de alta severidad. Arredondo presenta las cuatro categorías de amenaza y SkillSpector, la herramienta abierta de NVIDIA que audita una skill antes de instalarla.
skills analizadas de 42.447 relevadas
tiene al menos una vulnerabilidad
con patrones de alta severidad
1. Qué es una skill, y por qué no es lo mismo que MCP o RAG
Una skill es un procedimiento repetible que vive en un archivo SKILL.md con tres partes: metadatos, procedimiento y scripts. Y ahí está el punto que da origen a toda la charla: las skills no solo agregan conocimiento — integran capacidades, instrucciones y código al sistema. La vulnerabilidad aparece en el código.
Además, es 2,12 veces más probable encontrar vulnerabilidades en este contexto que en código convencional — una brecha que sigue creciendo a medida que el ecosistema se expande. La cadena que va del problema al daño tiene cuatro eslabones: se instala una skill sin auditar → el agente la ejecuta con sus herramientas → expone claves o documentos → daño reputacional o financiero.
2. Cuatro categorías de amenaza, cuatro casos reales
Caso ClawHub, enero de 2026: la campaña «ClawHavoc» colocó 335 skills maliciosas en un marketplace, disfrazadas de herramientas populares, con el ladrón de credenciales Atomic Stealer. Una sola acumuló unas 7.000 descargas antes de ser detectada.
Inyección de prompts, agentes rebeldes. Caso: texto invisible en una demanda laboral instruía a la IA del tribunal a revisar el caso superficialmente — primera sanción judicial mundial por inyección de prompts.
Ejecución dinámica u ofuscada. Caso: paquetes npm con nombres tipográficamente similares a herramientas legítimas, con gusano que robaba llaves SSH y claves de nube.
Exfiltración, permisos excesivos. Caso EchoLeak: una instrucción oculta en un documento hacía que el asistente corporativo filtrara datos sin clic de la víctima.
Dependencias vulnerables. Caso: paquetes troyanizados que robaban credenciales de las tres grandes nubes, con mecanismo de borrado del equipo.
Sobre todo esto opera «los 30 segundos para decidir»: muchas instalaciones piden aceptar o rechazar de inmediato, y bajo esa presión es fácil instalar sin revisar.
3. SkillSpector: auditar antes de instalar
Herramienta de código abierto de NVIDIA que inspecciona una skill y produce un reporte con puntaje de 0 a 100. Analiza contra 68 patrones en 17 categorías, en cuatro pasos: patrones textuales → análisis AST → flujo de datos → dependencias (consultando OSV.dev).
Las dos filas del medio son la lección: una skill que declara una cosa y hace otra pasa casi desapercibida en modo estático, y se revela crítica al comparar declaración contra comportamiento.
4. De auditoría manual a guardarraíl automático
El salto que propone la charla es exponer la misma herramienta por Model Context Protocol, de modo que otro agente la invoque automáticamente y bloquee la instalación según el veredicto. Si el código cambia, la huella cambia y el escaneo se repite: es auditoría continua, no un evento único.
5. Conclusiones
Las skills no solo dan conocimiento: integran código, y el código puede fallar o dañar. Un puntaje no es garantía: es una guía para decidir dónde mirar primero. Auditar antes de instalar toma minutos; recuperarse de una filtración, no.
«La tecnología centrada en el humano es aquella que nos permite tomar decisiones informadas, conscientes y voluntarias.»
CEO de Chimera, ciberseguridad de IA y robótica. Miembro del LEIND, Universidad de Santiago de Chile.
¿Puede una empresa olvidar por qué toma sus decisiones?
Qué ocurre cuando las decisiones de varios agentes se encadenan hasta producir una decisión que nadie tomó por completo.
¿Podría una empresa llegar a un punto en que ya no sepa por qué toma determinadas decisiones? A primera vista parece difícil: nunca habíamos tenido tanta capacidad para registrar lo que ocurre dentro de una organización. Pero existe una posibilidad menos evidente: que ocurra exactamente lo contrario.
A medida que entregamos a distintos agentes la capacidad de observar, decidir y actuar, una decisión puede dejar de ocurrir en un único lugar. Lo que decide un agente modifica el contexto del siguiente. La organización sigue tomando decisiones, posiblemente mejores y más rápidas, pero la razón que las produjo empieza a quedar repartida entre sistemas.
A las 9:17 de un martes cualquiera, un agente decide subir el precio de un producto. El cambio está dentro de los márgenes autorizados; nadie recibe una alerta. Catorce minutos y cinco decisiones después, ninguna reunión se había convocado — y dos días después los resultados eran buenos.
Durante la reunión comercial alguien mira el dashboard y pregunta: —¿Por qué subimos el precio? El equipo retrocede por la cadena hasta encontrarse, de forma absurda, nuevamente con pricing. No hay errores. Cada agente actuó dentro de sus permisos. Saben exactamente qué ocurrió. Lo que no pueden explicar con la misma facilidad es por qué la empresa decidió hacerlo. Y la decisión fue buena.
1. ¿Quién tomó la decisión?
Durante años, automatizar significó conseguir que una máquina ejecutara una decisión definida previamente por alguien. La decisión tenía un origen reconocible. La IA agéntica modifica esa relación: cuando varios agentes participan de un mismo proceso, las decisiones de unos pasan a formar parte del contexto sobre el que deciden otros.
Pricing ejecutó el cambio de precio, pero reaccionó a información que otro sistema había modificado. Cada agente tomó una decisión local razonable, y ninguna de ellas, por separado, contiene la explicación completa del resultado. Nadie tomó aquella decisión tal como finalmente ocurrió. La empresa sí.
Decisión huérfana: una decisión organizacional que emerge de varias decisiones agénticas legítimas, pero cuya racionalidad completa no pertenece a ninguno de los actores que participaron en ella.
2. El sistema pasó la auditoría
¿Qué hizo el sistema? Tenemos respuesta. ¿Quién ejecutó cada acción? También. ¿Estaba autorizado? Sí. ¿Funcionó? Sí. ¿Por qué la organización terminó tomando esa decisión? Ahí la respuesta empieza a complicarse. Trazabilidad y comprensión suelen aparecer muy cerca cuando hablamos de control, pero no son equivalentes: los registros conservan acontecimientos, comprender una decisión exige reconstruir las relaciones entre ellos.
3. El problema puede estar entre los agentes
En el ejemplo no encontraríamos el problema inspeccionando mejor al agente de pricing, ni a inventario ni a compras. El fenómeno está entre ellos: demanda cambia un forecast, inventario lo interpreta, pricing cambia un precio, marketing modifica una promoción, y esa promoción vuelve a afectar demanda. Cada paso puede tener sentido localmente, y aun así la razón del resultado puede quedar distribuida por todo el sistema.
Pricing busca proteger margen, inventario reducir quiebres de stock, marketing maximizar conversión, compras optimizar costos. No hay nada extraño en esos objetivos: el problema aparece cuando interactúan y compiten.
4. Del log a la genealogía
La genealogía de una decisión reconstruye qué evidencias, objetivos y decisiones previas hicieron posible una decisión posterior. Un log permite preguntar qué ocurrió antes; la genealogía debería permitir reconstruir por qué aquello que ocurrió antes terminó produciendo esta decisión y no otra. No se trata de pedirle a cada agente que escriba un ensayo justificando sus acciones: lo que interesa conservar es la estructura relevante: evidencia, objetivos, dependencias, cambios y consecuencias.
5. El humano necesita algo más que la última palabra
Una respuesta frecuente frente al riesgo de automatizar decisiones es mantener a una persona dentro del circuito. Pero imaginemos a la persona que recibe la alerta después de que veinte agentes hayan tomado cientos de decisiones relacionadas durante las últimas seis horas: técnicamente sigue teniendo la última palabra, pero en la práctica acaba de recibir un problema cuya historia no vivió.
En 1983, Lisanne Bainbridge describió una de las ironías de la automatización: cuanto más se automatiza una operación normal, más puede dependerse del humano precisamente en las situaciones anormales para las que está menos preparado. Por eso devolver una decisión a una persona no garantiza, por sí mismo, control humano. Hay que devolver también contexto.
6. ¿Qué auditaremos mañana?
A medida que los agentes pasen de ejecutar tareas a participar en decisiones conectadas, tendremos que ampliar aquello que entendemos por control. La unidad de control deja de ser solamente el agente: empieza a ser también la decisión que circula entre ellos. Quizás las organizaciones terminen auditando la genealogía de sus decisiones con la misma naturalidad con que hoy auditan procesos, transacciones o modelos.
Consumer Behavior Specialist · Decision Intelligence · IA aplicada · Humanización de datos.
De la IA generativa a la IA agéntica: el nuevo desafío de seguridad y gobernanza para las organizaciones
El futuro de la IA no estará definido únicamente por lo que pueda hacer, sino por nuestra capacidad para gobernar aquello que le permitimos.
EJECUTIVO
La IA está evolucionando de sistemas orientados a generar contenido hacia sistemas capaces de planificar tareas, utilizar herramientas y ejecutar acciones. Esta transición plantea nuevas consideraciones para la seguridad y la gobernanza, particularmente en materia de identidad, privilegios, supervisión y control. Una adopción sostenible requiere establecer límites, controlar los accesos, mantener trazabilidad y garantizar una supervisión humana efectiva.
de las organizaciones ya usa IA agéntica (451 Research)
se encuentra en etapa de prueba de concepto
agentes desplegados en promedio por organización
1. Introducción
En su estudio The State of Agentic AI Adoption in Organizations, Lehmann (2026) muestra que el 43 % de las organizaciones participantes ya utiliza este tipo de tecnología, mientras que otro 30 % se encuentra en etapa de prueba de concepto. Cuando un sistema deja de limitarse a proporcionar una respuesta y adquiere capacidad para actuar, surgen nuevas preguntas: ¿qué información puede consultar?, ¿qué permisos tiene?, ¿qué decisiones puede ejecutar sin intervención humana? y, sobre todo, ¿quién supervisa esas acciones?
2. La adopción está acelerándose
El estudio reporta un promedio de 19,2 agentes desplegados por organización, entre aquellas que ya utilizan o prueban esta tecnología. Además, las organizaciones contemplan incorporar, en promedio, otros 19,4 agentes durante los siguientes 12 meses. La escala de la adopción convierte la gobernanza de estos sistemas en un componente cada vez más relevante de la seguridad organizacional.
Agentes actuales desplegados por organización
En etapa de prueba de concepto (PoC)
Nuevos agentes previstos en 12 meses
3. La autonomía introduce un nuevo problema de identidad
Un agente que consulta información, utiliza herramientas o ejecuta acciones dentro de una organización necesita algún mecanismo que permita identificarlo y determinar qué está autorizado a hacer. Esto se relaciona con el crecimiento de las identidades no humanas (NHI), que ya representan un desafío en visibilidad, auditoría y asignación de permisos, como advierte Kennedy (2025), de 451 Research. El reto principal no consiste únicamente en proporcionar una identidad al agente, sino en definir y limitar su autoridad.
Leo et al. (2026) señalan que los sistemas agénticos presentan superficies de ataque y modos de fallo diferentes de los sistemas tradicionales, mientras que los controles de seguridad existentes todavía resultan insuficientes. El OWASP Top 10 for Agentic Applications incluye ASI03 – Identity & Privilege Abuse entre los principales riesgos identificados.
4. La seguridad de la IA enfrenta una brecha de capacidades
37 % la considera una capacidad importante · 35 % dice que está inadecuadamente cubierta
35 % la considera una capacidad importante · 36 % dice que está inadecuadamente cubierta
Reconocer una capacidad como necesaria no significa contar con ella: los profesionales de seguridad necesitan pasar de ejecutar tareas manualmente a supervisar, evaluar y establecer los límites dentro de los cuales la automatización puede operar de manera segura.
5. El factor humano y organizacional
La aplicación del principio de mínimo privilegio es la defensa crítica para mitigar el alcance de un agente en caso de error o manipulación externa.
¿Quién define qué puede tocar el agente?
¿Quién firma antes de ejecutar una acción?
¿Quién puede frenar al sistema?
¿Quién asume las consecuencias?
La autonomía puede ampliarse, pero debe hacerlo acompañada de identidad, límites, trazabilidad y supervisión — ninguna de las cuatro capas sustituye a las otras.
6. ¿Qué deberían hacer las organizaciones?
No se trata de impedir la utilización de agentes, sino de establecer las condiciones bajo las cuales pueden operar. La aplicación del principio de mínimo privilegio permite limitar el alcance de una acción en caso de error o manipulación. La trazabilidad constituye otro componente fundamental: las organizaciones necesitan conocer qué agente ejecutó una acción, con qué identidad, qué información utilizó y cuál fue el resultado.
7. Conclusiones
El verdadero indicador de preparación organizacional no es el ritmo de adopción de la IA agéntica, sino la capacidad institucional para mantener el control sobre sistemas a los que cada vez se confían mayores niveles de autonomía de acción.
«Gobernar agentes autónomos exige fortalecer nuestra capacidad de responder ante lo imprevisto.»
«La autonomía puede automatizar la eficiencia, pero la responsabilidad nunca se delega.»
Consultor de TI y ciberseguridad en UBIQRA · embajador para México y miembro del Consejo de Gobernanza y Marco Normativo de IA en Comunidad IA LATAM.
Autores de la edición
Cinco voces técnicas firman los artículos de este número.
Las personas detrás de esta edición
Créditos editoriales de Comunidad IA LATAM.
Ingeniero informático, consultor de ciberseguridad, asesor tecnológico del Departamento de Terapia Ocupacional y editor de la Revista Chilena de Terapia Ocupacional (ReChTO) de la Facultad de Medicina de la Universidad de Chile.
Periodista y especialista en comunicación digital. Líder de Revista IA LATAM, con formación en inteligencia artificial y Vibe Coding Seguro.
Fundador y presidente de Comunidad IA LATAM. Impulsa la revista como infraestructura de conocimiento abierto en español para toda América.
Vicepresidenta de Comunidad IA LATAM. Acompaña la conducción de la comunidad y el fin social del proyecto editorial: conectar talento y educar en español.