DE PILOTO
A PRODUCCIÓN

IA latinoamericana que funciona, escala y resiste.

Mg. Ing. Sebastián Vargas Yáñez

PRESIDENTE · COMUNIDAD IA LATAM

LinkedIn

Construimos conocimiento para que Latinoamérica también construya el futuro

Bienvenidas y bienvenidos a la primera edición de LATAMIA. Esta revista nace para transformar lo que ocurre cada día en nuestra comunidad —charlas, investigación, experiencias, pruebas, errores y aprendizajes— en conocimiento que pueda permanecer, circular y ser reutilizado en toda la región.

Latinoamérica no necesita limitarse a observar la revolución de la inteligencia artificial. Tenemos talento, instituciones, empresas, investigadores, estudiantes y comunidades capaces de diseñar soluciones desde nuestro propio contexto y con nuestros propios desafíos.

Por eso este número habla de producción, agentes, seguridad, gobernanza, soberanía e ingeniería. No buscamos presentar la IA como una promesa abstracta, sino mostrar cómo se construyen sistemas que funcionan, escalan, resisten y pueden ser auditados.

Gracias a cada autora, autor, speaker, voluntario y miembro de Comunidad IA LATAM que aporta conocimiento abierto. Esta publicación existe porque hay una comunidad que decidió compartir antes que guardar.

Tamara López Leyton

VICEPRESIDENTA · COMUNIDAD IA LATAM

LinkedIn

Una revista para conectar talento, experiencias y una mirada propia desde LATAM

Cada avance tecnológico adquiere verdadero valor cuando puede ser comprendido, cuestionado y aplicado por las personas. LATAMIA busca precisamente eso: acercar experiencias concretas, investigación, buenas prácticas y perspectivas diversas a quienes están construyendo inteligencia artificial en nuestra región.

Esta edición reúne voces técnicas, académicas, institucionales y comunitarias. Algunas muestran sistemas que ya están operando; otras explican dónde fallan, cómo se protegen o qué límites debemos reconocer antes de automatizar decisiones importantes.

También queremos que esta revista sea un punto de encuentro. Que un estudiante encuentre una ruta; que un profesional descubra un enfoque; que una organización identifique una práctica que puede adoptar; y que una investigadora o investigador encuentre nuevas preguntas.

Gracias por abrir estas páginas y formar parte de una comunidad que crece compartiendo conocimiento, conectando personas y creando oportunidades para Latinoamérica.

Un modelo de lenguaje solo hace una cosa: procesar texto y generar texto. Todo lo demás —leer archivos, ejecutar herramientas, decidir cuándo parar, coordinar a otros— lo aporta lo que envuelve al modelo. Cristián Rojas Arredondo, chair del Consejo de Desarrollo e IA de Comunidad IA LATAM, resume esa idea en una fórmula: A = ⟨M, H⟩, un agente es un modelo más su arnés. A partir de ahí construye una progresión de cinco capas —prompt, contexto, arnés, bucle y grafo— donde cada una existe porque resuelve un límite concreto de la anterior. La clase culmina en algo poco habitual en una charla divulgativa: un argumento de convergencia. Auditar el repositorio completo en cada ronda de remediación diverge por construcción; fijar el universo de hallazgos una sola vez y podarlo garantiza que el proceso termine. Este artículo recorre las cinco capas y explica por qué esa distinción decide si tu agente arregla el proyecto o da vueltas en círculos.

1. Un agente es control, no solo generación

La confusión más extendida sobre los agentes es tratarlos como un modelo más listo. No lo son. La diferencia no está en la calidad de la generación, sino en la capacidad de operar: observar, decidir, actuar sobre archivos y sistemas reales, comprobar el resultado y volver a intentarlo.

Rojas ordena cuatro conceptos que suelen usarse indistintamente y no son lo mismo. Un LLM es el modelo de lenguaje. Un arnés (harness) es el entorno de ejecución y operación. Un agente es la unidad de operación y control que resulta de juntar ambos. Y un sistema multiagente es un conjunto de agentes coordinados.

El modelo aporta el juicio; el arnés aporta las manos, la memoria y los límites.

Una precisión de vocabulario que la propia clase se detiene a hacer, porque genera confusión: «arnés» aparece en dos niveles. Como paraguas de runtime —todo lo que envuelve al modelo y lo hace actuar— y como una capa concreta dentro de la progresión didáctica. Es el mismo sistema mirado desde dos alturas: el todo y la pieza.

2. La progresión: cada capa resuelve un límite

Lo que hace valiosa esta clase no es el catálogo de conceptos, sino el hilo que los une. Cada capa no se agrega porque sí: aparece cuando la anterior se queda corta.

3. Prompt: la primera capa de control

La clase demuestra el salto con un ejemplo mínimo y muy reconocible: una función de login que concatena usuario y contraseña dentro de una consulta SQL. Preguntar «¿está bien esta función?» produce lo que cabe esperar: «parece funcionar; podrías validar los campos y usar nombres más claros». Un resultado pobre para un prompt pobre.

Cambiar la instrucción por «eres un auditor de seguridad senior; revisa esta función, razona línea por línea, señala las vulnerabilidades ordenadas por severidad y propón el fix de cada una» devuelve otra cosa: crítico por inyección SQL con la corrección parametrizada, alto por comparación de contraseña en texto plano con la recomendación de hashear, medio por ausencia de manejo de error. Mismo modelo, mismo código, resultado incomparable.

De ahí la anatomía que propone la clase para un prompt de auditoría: rol (quién eres), tarea (qué buscas), cadena de razonamiento (analiza módulo por módulo antes de listar), ejemplo (ubicación, severidad, causa, fix) y formato de salida estructurado, por ejemplo JSON con archivo, severidad, categoría y descripción. El formato no es cosmética: es lo que permite que la salida alimente al siguiente paso.

4. Contexto: lo que el modelo ve cuando piensa

Un prompt perfectamente estructurado puede fallar igual. Peor: puede alucinar una respuesta creíble y falsa. La razón es que el prompt define el trabajo, pero no la información con la cual trabajar.

Rojas define contexto como la entrada completa que el modelo ve en el momento de iniciar la inferencia: las instrucciones, los archivos, los estándares y convenciones, los hallazgos de auditorías previas y los resultados de las herramientas. Y luego hace la pregunta que hay que hacerse: ¿más contexto es siempre mejor? No, porque el presupuesto de atención es finito.

La clase separa dos naturalezas que conviene no mezclar. Transitorio: el prompt y el archivo actual; se arma en cada llamada al modelo. Persistente: la guía de estilo, el repositorio accesible vía herramientas, los hallazgos acumulados, el reporte; sobrevive entre pasos y entre sesiones.

Esa distinción tiene una consecuencia económica directa que Rojas señala en la grabación: si el trabajo de una sesión queda en memoria, la sesión siguiente no necesita reconstruir todo el contexto desde cero, lo que reduce el consumo de tokens y el tiempo de ejecución.

5. Arnés: darle manos al modelo

Un contexto bien compuesto aumenta la precisión y reduce las alucinaciones, pero el modelo sigue sin poder tocar nada. El arnés es la capa que convierte juicio en operación. Sus componentes, según la clase: inventario de herramientas y enrutamiento —qué puede hacer y cómo se decide qué usar—; gestor de contexto y almacén de estado —qué recuerda y dónde lo guarda—; restricciones de seguridad —qué tiene prohibido, con independencia de lo que decida el modelo—; observabilidad y ganchos de ciclo de vida —qué queda registrado y dónde se puede intervenir—; y el bucle agéntico, el motor que repite observar, decidir, actuar.

La memoria merece un párrafo aparte porque cumple dos funciones a la vez: permite aprender de los éxitos y de los fracasos, y evita regenerar contexto que ya se produjo antes.

6. Bucle: ciclos que saben parar

Aquí aparece el problema más sutil de toda la clase, y conviene leerlo despacio. El bucle de un arnés observa, decide, actúa, vuelve a observar y repite hasta cumplir una condición de término. Pero si esa condición la define el propio arnés, nada garantiza que cuando reporta éxito haya cumplido de verdad el objetivo sin producir daños ni regresiones en otros puntos del repositorio. Es el equivalente agéntico de dejar que el examinado corrija su propia prueba.

Rojas cuenta en la grabación un caso que cualquiera que haya trabajado con agentes de código reconoce: estar editando un archivo y que el agente, a mitad del proceso, se dé cuenta de que cometió un error. Que lo detecte es bueno. Que sea él mismo quien certifique que ya está resuelto es el problema.

De ahí que la ingeniería de bucles consista en diseñar procesos reproducibles y autoverificables, con condiciones de parada definidas por quien diseña el bucle y no por quien lo ejecuta.

7. Grafo: descomponer para poder terminar

Un solo agente choca con dos muros: los límites de su ventana de contexto y el sesgo autoinducido —seguir por el camino que él mismo eligió—. La ingeniería de grafos responde descomponiendo la tarea compleja en tareas menores, paralelizables y delegables. El patrón que la clase desarrolla es fan-out / fan-in, ejemplificado sobre una auditoría de repositorio.

En el DAG de hallazgos, una arista a → b significa «a contribuye a b» o «a causa b». Las causas raíz quedan arriba y los efectos compuestos abajo. Y aquí aparece la idea más práctica de toda la clase: la severidad local de un hallazgo no basta para priorizarlo.

La priorización tiene dos dimensiones y no una: el número de causas determina la accionabilidad —cuándo se puede tocar algo— y la zona de impacto determina la prioridad —cuánto rinde tocarlo—.

Una dependencia de severidad baja se remedia primero cuando su zona de impacto contiene un hallazgo crítico. Impacto real = (máxima severidad en la zona, tamaño de la zona).

8. La trampa de la divergencia

Este es el aporte que distingue a esta clase de una introducción cualquiera a los agentes, y es un argumento de terminación, no una buena práctica.

Re-auditar todo el repositorio en cada ronda de remediación redefine el universo de hallazgos, y por lo tanto diverge por construcción. Cada auditoría global destapa cosas nuevas, ignora otras y reordena la prioridad, de modo que la ronda n+1 no trabaja sobre el residuo de la ronda n. No existe función de potencial monótona: nada garantiza que el proceso termine.

Es un fallo que se siente en el cuerpo cuando se sufre: el agente lleva horas trabajando, cada ronda encuentra hallazgos, se corrigen, y la cuenta de pendientes nunca baja. Parece falta de capacidad y es un defecto de diseño del bucle externo.

La corrección tiene cuatro piezas. Universo fijo: el DAG se construye una sola vez, con una auditoría profunda. Poda monótona: cada ronda solo tacha nodos resueltos o los deja pendientes de reintento por regresión; nunca agrega nodos nuevos. Función de potencial: el número de nodos sin tachar solo puede bajar, y ese es el argumento de convergencia. Parada inequívoca: se detiene cuando el DAG se agota, cuando se acaba el presupuesto o cuando la verificación certifica.

El orden de trabajo también queda determinado: primero una restricción dura —las causas antes que los efectos, avanzando por la frontera del grafo—, luego el desempate por impacto y, finalmente, verificación acotada y poda. Solo cuando el universo se agota se ejecuta una nueva auditoría global que construye un DAG nuevo. El ciclo externo existe, pero no se dispara en cada ronda.

Tres ideas para llevarse. La primera: el poder de un agente no está en el modelo sino en lo que lo envuelve. Cambiar de modelo mejora el juicio; cambiar el arnés cambia lo que el sistema es capaz de hacer y, sobre todo, lo que tiene prohibido hacer.

La segunda: quien define la condición de término define si el trabajo está hecho. Un bucle que se autoevalúa reporta éxito con la misma confianza con la que alucina, y por eso la verificación tiene que venir de fuera del bucle.

La tercera, y la más útil para quien ya está orquestando agentes: la convergencia se diseña. Si el proceso vuelve a mirar el mundo entero en cada iteración, no está avanzando, está reiniciándose con otro nombre.

La IA ya está en producción, y la pregunta dejó de ser si adoptarla. El problema es otro: los pilotos escalan a producción sin marcos de control, mientras las políticas no evolucionan al mismo ritmo que la tecnología. El resultado son sistemas que influyen en decisiones de negocio sin registro de razonamiento, sin protocolo cuando fallan y sin la documentación que exige la regulación. Alberto Barrera propone no crear un silo paralelo de «gobernanza de IA», sino incorporarla al sistema de gestión que la organización ya opera: su marco ADG (Adopt · Defend · Govern) ordena la práctica en tres pilares con doce controles mínimos, y se apoya en la estructura armonizada que comparten ISO/IEC 42001, 27001, 22301 y 27035. La consecuencia práctica es alentadora: quien ya tiene un sistema de gestión certificado tiene construida gran parte del camino.

1. El problema: pilotos sin dueño, sin control, sin evidencia

La charla parte de una tensión que reconoce cualquiera que trabaje en una organización mediana o grande: la velocidad de adopción —los pilotos llegan a producción rápido— contra la brecha de gobernanza, porque las políticas y los controles no acompañan ese ritmo. Y esa brecha se manifiesta en tres síntomas concretos.

Decisiones no trazables. Los sistemas influyen en el negocio sin registro del razonamiento ni posibilidad de auditoría. Incidentes sin protocolo. No existe un proceso definido de detección ni de comunicación cuando el modelo falla. No conformidad regulatoria. La ausencia de documentación expone a incumplimiento del reglamento europeo de IA y de normativas sectoriales.

La tesis: la IA no debe crecer como un silo paralelo. Debe incorporarse como una capacidad gobernada dentro del sistema de gestión que ya opera en la organización. Esa decisión —integrar en vez de duplicar— es lo que separa un programa sostenible de una carpeta de políticas que nadie aplica.

2. El marco ADG: tres pilares, doce controles

ADG estructura la gobernanza de IA en tres verbos que corresponden a tres momentos distintos del trabajo.

Adopt se despliega en tres pasos hacia el despliegue: selección de casos de uso con criterios de valor, viabilidad técnica y evaluación inicial de riesgo; arquitectura y despliegue con diseño documentado, entornos controlados y gestión de versiones; y DevSecOps para IA, integrando seguridad y calidad en la tubería de desarrollo. La premisa: cada sistema de IA en producción debe tener un dueño claro, un propósito justificado y controles de calidad verificables.

Defend nombra las amenazas propias de esta tecnología —inyección de prompts (manipular entradas para alterar el comportamiento), envenenamiento de datos (contaminar el entrenamiento para degradar la fiabilidad) y riesgos agénticos (comportamientos imprevistos en sistemas autónomos con acceso a APIs externas)— y las contramedidas: red-teaming con pruebas adversariales y guardarraíles en tiempo de ejecución.

Govern introduce la pieza organizacional que suele faltar: un Consejo de Gobernanza de IA, órgano que media entre la velocidad de adopción y los requerimientos de control, define derechos de decisión y aprueba el despliegue de sistemas de alto riesgo. Se apoya en tres palancas: la política de IA (principios, límites de uso aceptable y clasificación de sistemas por nivel de riesgo), los derechos de decisión (quién aprueba el despliegue, quién supervisa en producción, quién escala incidentes) y la evidencia auditable (registros, evaluaciones de impacto y trazabilidad completa).

Aquí está el aporte más práctico de la charla, y el que ahorra más dinero. Las normas ISO comparten una estructura de alto nivel —el Anexo SL—: mismo esqueleto de cláusulas (contexto, liderazgo, planificación, operación, evaluación, mejora) para todos los sistemas de gestión. Eso significa que no hay que construir un sistema nuevo: hay que extender el que existe.

ISO/IEC 42001 queda como núcleo de la gestión de IA: reutiliza del sistema integrado el contexto organizacional, el liderazgo, la competencia, la comunicación, la documentación y la auditoría interna; y añade lo específico —ciclo de vida del sistema de IA, evaluación de impacto, controles de su Anexo A y uso responsable—.

Una organización que ya tiene 27001 o 22301 activos tiene construida gran parte del sistema. El esfuerzo incremental para llegar a 42001 es acotado y medible, un argumento decisivo para presentar el proyecto ante un comité que ya invirtió en certificaciones.

4. Los controles del Anexo A, y cómo se mapean a ADG

Los dominios de control que introduce 42001 cubren políticas de IA (principios y límites de uso aceptable), organización y roles (responsabilidades de desarrollo y supervisión), evaluación de impactos (consecuencias para individuos, grupos y sociedad), datos para la IA (calidad e integridad en entrenamiento y operación), uso responsable (equidad, transparencia, explicabilidad y supervisión humana) y terceros y clientes (cadena de suministro y obligaciones contractuales).

Y el mapeo con ADG evita duplicar esfuerzos: políticas y organización son territorio de Govern; recursos y ciclo de vida, de Adopt; los datos se preparan en Adopt y se protegen en Defend; la evaluación de impactos combina el riesgo técnico de Defend con la aprobación de Govern; y la relación con terceros cruza la cadena de suministro (Defend) con lo contractual (Govern).

5. Cuando la IA es función crítica

Una sección breve pero con consecuencias enormes: si un sistema de IA sostiene un proceso crítico, entonces los planes de recuperación deben contemplarlo. Dos estándares dan el respaldo.

ISO 22301 obliga a definir planes de contingencia con fallback manual y objetivos de tiempo y punto de recuperación aplicados al sistema de IA —es decir: qué hacemos, y en cuánto tiempo, cuando el modelo no está disponible—. Y ISO/IEC 27035 establece que los incidentes de IA se gestionan como incidentes de seguridad, con clasificación y aprendizaje estructurado, en lugar de resolverse informalmente en un chat de equipo.

6. La hoja de ruta: de la evaluación a la evidencia

Cuatro pasos, en este orden. El inventario responde una pregunta que casi ninguna organización sabe contestar: cuántos sistemas de IA tiene, con qué dueño y con qué propósito. Después vienen la medición de brechas, la integración y, al final, lo único que un auditor acepta como prueba: la evidencia.

Tres ideas para llevarse. Primero, gobernar no es frenar: el Consejo de Gobernanza existe precisamente para mediar entre la velocidad de adopción y el control, no para bloquear proyectos.

Segundo, integrar es más barato que duplicar: la estructura armonizada convierte una certificación existente en la base del sistema de IA, y ese argumento económico es el que destraba presupuestos.

Tercero, la evidencia es el entregable: sin registros, evaluaciones de impacto y trazabilidad, la gobernanza es una declaración de intenciones —y ante un regulador, una declaración no es una defensa—.

Sistemas trazables, explicables y auditables generan mejores decisiones y confianza; la continuidad garantizada da resiliencia; y la adopción responsable se vuelve una fuente de diferenciación duradera. En una región donde la regulación de IA llega antes que la propia legislación local, tener la casa ordenada deja de ser cumplimiento: es ventaja competitiva.

«La diferencia no está en adoptar IA más rápido, sino en gobernarla mejor.»

La evidencia es el entregable.

Un filtro que busca la palabra secreta en el texto de salida parece una defensa razonable, hasta que alguien pide la misma información en Base64, como lista de Python invertida, como arreglo de números o disfrazada de pregunta sobre geografía. Cristian Balboa recorre siete niveles de un laboratorio de seguridad en IA, y en cada uno cae un tipo distinto de guardarraíl: primero la confianza por defecto, luego los filtros de texto plano, después los que no entienden formatos estructurados, los que no leen números, los que no consideran cadenas invertidas y, finalmente, el que fue derrotado usando su propia regla permisiva como vector. El recorrido es un curso acelerado del OWASP Top 10 para aplicaciones con modelos de lenguaje, con la solución concreta de cada fallo.

Ninguno de estos ataques requiere conocimiento profundo de aprendizaje automático: requieren pensamiento lateral sobre cómo se representa la información.

1. El estándar: OWASP Top 10 para LLM

Antes del laboratorio, el marco. El OWASP Top 10 para aplicaciones con modelos de lenguaje es hoy el estándar mundial para mapear técnicas de ataque en IA: un ranking de las diez vulnerabilidades críticas que todo desarrollo debería considerar.

El laboratorio se concentra en tres de ellas: LLM01 (inyección de prompts, «el rey de los ataques»), LLM02 (manejo inseguro de salidas) y LLM06 (divulgación de información sensible).

2. Siete niveles, siete formas de romper un filtro

El ejercicio es un entorno controlado donde un chatbot custodia una palabra secreta y cada nivel agrega una defensa. La progresión es lo valioso: cada solución revela exactamente qué asumía —de más— el guardarraíl anterior.

Leídos en conjunto, los siete casos cuentan una sola historia: el atacante no rompe el modelo, cambia de formato. La tabla de la página siguiente recorre los siete niveles con la defensa que cada uno exige.

3. El patrón detrás de los siete niveles

Leídos en conjunto, los siete casos cuentan una sola historia: cada guardarraíl asume un formato, y el atacante simplemente cambia de formato. Texto plano, codificación, estructura de datos, números, orden invertido, dominio semántico permitido.

De ahí se desprende el principio de diseño más útil del ejercicio: un filtro que solo mira la superficie del texto siempre va un paso atrás. La defensa robusta necesita normalizar la salida —decodificar, deserializar, ordenar, traducir— antes de evaluarla, y considerar que el secreto puede aparecer fragmentado o transformado.

4. Conclusiones

Las dos ideas con que cierra Balboa. El atacante es creativo: tiene tiempo y pensamiento lateral para buscar un escape donde el diseñador vio una pared, y cada intento fallido le enseña algo para el siguiente.

Y por eso la seguridad ofensiva en IA es indispensable: aprender estos ataques es lo que permite diseñar sistemas más robustos. Conocer el ataque es el primer paso de la defensa, y equipos rojos y azules trabajando juntos son los que fortalecen el sistema.

Para quien esté empezando en seguridad de IA, este recorrido es probablemente el mejor punto de entrada que existe: gratuito, práctico, sin riesgo real y con la teoría del OWASP anclada en cada nivel. Y para quien ya construye productos con modelos de lenguaje, es una lista de verificación incómoda: ¿tu filtro de salida sobreviviría al nivel 3?

«Funciona en mi máquina» describe con precisión el estado de casi todo lo que genera un agente: rápido, validado solo para el camino feliz, con riesgos que nadie miró. Rudy Pinochet cierra el primer curso de la Academia con la frase que ordena la clase: publicar es un acto de responsabilidad. Y propone tres instrumentos para ejercerla. Primero, meter la verificación dentro del bucle —pruebas, linters y verificadores de tipos como sensores que devuelven el error exacto al agente para que se corrija a sí mismo—. Segundo, un checklist de diez controles antes de cada publicación, automatizado en el pipeline y con capacidad de bloquear el despliegue. Tercero, los hábitos que hacen sostenible lo anterior.

Un prototipo generado con IA es rápido de producir, valida solo el camino feliz y arrastra riesgos de seguridad que nadie ha mirado. Lo que la separa de producción no es esfuerzo: es método.

1. La verificación como sensor del bucle

La idea central de la clase es un cambio de lugar, no de herramienta. Las pruebas no van al final, después de que el agente terminó: van dentro del ciclo, funcionando como sensores que evalúan cada iteración.

Tres tipos de sensor cubren lo esencial. Las pruebas automatizadas, unitarias y de integración, validan el comportamiento esperado y los casos límite. Los linters de seguridad detectan malas prácticas y vulnerabilidades conocidas en tiempo real. Los verificadores de tipos —TypeScript o equivalentes— aseguran contratos de datos estrictos. Juntos forman la red que atrapa errores y alucinaciones antes de que lleguen a producción.

La clave: el agente no recibe una opinión sobre su código, recibe un hecho verificable. La integración con el agente sigue cuatro movimientos: identificar las funciones críticas del sistema (autenticación, pagos), especificar pidiéndole que escriba las pruebas a partir de la spec, ejecutar esas pruebas localmente en cada iteración y validar —no aceptar el código hasta que todas pasen en verde—.

Las pruebas automatizadas son, en palabras de la clase, el contrato ejecutable entre el desarrollador y la IA.

Los sensores automáticos no cubren la lógica de negocio. Tres preguntas antes de aprobar cualquier cambio: vectores de entrada —¿qué pasa si envío datos maliciosos?—, flujo de negocio —¿qué pasa si me salto un paso?— y control de acceso —¿qué pasa si pido datos de otro usuario?—.

2. El abismo entre desarrollo y producción

La segunda parte de la clase es la más concreta y la que más sorprende a quien nunca ha operado un servicio. El arnés de desarrollo y el de producción no son el mismo entorno con más usuarios: son mundos distintos. Lo que es suficiente en desarrollo es negligente en producción.

HTTPS y nada más. Los servicios deben exponer exclusivamente endpoints cifrados, y usar HSTS para forzar conexiones seguras siempre. En producción, HTTP plano equivale a transmitir credenciales, claves y tokens en texto claro.

Identidad de verdad. En desarrollo es habitual el token en duro y la cuenta de administrador por defecto. En producción hacen falta JWT firmados o sesiones con cookies HTTP-only, validación en el backend de si el usuario tiene permiso sobre ese recurso concreto, re-autenticación para acciones sensibles y soporte de MFA.

Errores que no cuenten de más. Un stack trace revela la estructura interna de la aplicación. Al cliente le corresponde un mensaje genérico y un código HTTP correcto; el detalle técnico va al log interno, sanitizado.

Límites de consumo. Es el riesgo Unrestricted Resource Consumption del OWASP API Security Top 10 (API4:2023): sin límites, alguien puede agotar CPU, memoria o presupuesto. Un endpoint sin límites es un cheque en blanco.

Resiliencia. La infraestructura falla: bases de datos caen, redes se desconectan, servidores se reinician. Diseñar para el fallo significa reintentos con backoff exponencial, circuit breakers y respaldos automatizados.

Dependencias vivas. El análisis de composición (SCA) detecta CVE conocidos en las librerías, y el pipeline debe detener el despliegue si aparece una vulnerabilidad crítica. El mantenimiento no termina con el despliegue.

4. Los hábitos: gobernanza personal

La última parte de la clase es la que decide si todo lo anterior sobrevive al segundo mes. La seguridad como evento aislado —una auditoría antes del lanzamiento— produce correcciones masivas y dolorosas y depende de la memoria de alguien. Como hábito diario, es parte del flujo.

Reutilizar el contexto. Un archivo de reglas persistentes en la raíz del repositorio —AGENT.md o equivalente— mantiene las políticas globales y evita los mismos antipatrones; es la memoria institucional del equipo.

Mantener lo que ya funciona. Herramientas como Dependabot o Renovate abren las actualizaciones automáticamente, y la suite de pruebas confirma que no rompen nada. El código seguro de hoy puede ser vulnerable mañana.

Revisar en pequeño. Detectar una alucinación en cincuenta líneas es factible; en quinientas, es una ilusión.

No relajar el arnés. La tentación aparece con la misma excusa —«es solo un prototipo»— y consiste en desactivar linters o ignorar pruebas que fallan. La regla no admite matices: si no pasa las pruebas, no se despliega.

Saber cuándo llamar a alguien. En pagos, criptografía o autenticación central, la revisión humana experta no es opcional. La IA no reemplaza a un profesional de seguridad: lo libera para concentrarse en lo complejo.

La clase cierra recapitulando el trío que sostiene todo el curso. La spec define el qué: el contrato, las restricciones y los criterios de aceptación. El bucle define el cómo: iteración continua en pasos pequeños. El arnés aporta la validación: sensores que verifican en tiempo real.

Tres ideas para llevarse. Primera: la verificación va dentro del bucle, no después. Segunda: el checklist debe poder bloquear, porque una lista de buenas intenciones que no detiene nada no es un control. Tercera: publicar es un acto de responsabilidad, y esa responsabilidad se ejerce con hábitos, no con esfuerzos heroicos la noche antes del lanzamiento.

El pentesting tradicional no escala: la cobertura está limitada por la cantidad de pentesters disponibles frente a los activos por asegurar, y buena parte del trabajo —reconocimiento, fuzzing, correlación de hallazgos— es repetitivo. La inteligencia artificial ataca justamente esa capa: el 67% de los equipos de red team ya usa al menos una herramienta de IA (contra 18% en 2023) y el tiempo de generación de reportes cae un 35% en pruebas de alcance medio. Este artículo recorre el ciclo completo y el ecosistema real de herramientas, y cierra con lo que importa cuando la herramienta ya está sobre la mesa: scope estricto, trazabilidad, humano en el loop y validación manual de todo hallazgo crítico.

1. El pentest clásico y su techo

Un test de penetración simula ataques reales para encontrar vulnerabilidades antes que lo haga un atacante, con la misma creatividad pero con permiso y con el objetivo de mejorar el sistema. Su metodología clásica sigue siete fases: planificación, reconocimiento, escaneo, enumeración, explotación, post-explotación y reporte.

El techo aparece en el volumen. Un reconocimiento extenso para un solo cliente puede tomar dos o tres días según el alcance: OSINT a mano, búsquedas dispersas en pestañas del navegador, correlación manual de subdominios y filtraciones. Multiplíquelo por la cantidad de clientes y activos de una organización moderna y el problema queda claro: la cobertura está limitada por cuántos pentesters hay disponibles, no por cuántos sistemas hay que asegurar.

2. Qué cambia con IA, fase por fase

Reconocimiento. El OSINT pasa a estar impulsado por modelos de lenguaje que resumen en minutos lo que tomaba horas: correlación automática de subdominios, filtraciones y huellas digitales. Más importante que la velocidad: los modelos clasifican los activos por exposición y criticidad de negocio.

Fuzzing inteligente. En vez de diccionarios estáticos, los modelos generativos crean variantes de entrada diseñadas para maximizar la probabilidad de encontrar comportamientos inesperados: entrada base → mutación guiada por IA → ejecución → análisis de respuesta → refinamiento del payload.

Explotación asistida por agentes. Agentes autónomos que encadenan comandos e interpretan salidas de nmap, Burp o Metasploit; generación de payloads adaptados a la versión del objetivo; y orquestación, donde un agente central coordina varias utilidades. Advertencia práctica: un pentest completo consume muchísimos tokens, y sin scope bien delimitado el agente puede generar payloads contra lo que no corresponde.

3. El ecosistema real de herramientas

La parte más valiosa de la charla es el inventario de lo que ya está en producción, con su nivel de madurez, no como catálogo publicitario. Casas subraya el paralelismo histórico: pentesting general y Web3 evolucionaron casi al mismo ritmo —de los analizadores estáticos y PentestGPT en 2023, a los primeros agentes encadenando CLI en 2024, a los frameworks validados en 2025, hasta el ecosistema multiagente en producción de 2026— y hoy están convergiendo.

Cuatro bloques: fuentes de datos → orquestador o agente de IA → validación humana → reporte y remediación. La IA acelera cada bloque; el humano es el que no se automatiza.

5. Adopción segura: la parte que casi nadie lee

Un camino de cuatro pasos para organizaciones que recién parten: piloto controlado (IA solo en reconocimiento, sobre un activo no crítico); métricas y validación (comparar hallazgos de IA contra los manuales); ampliar con supervisión (escaneo y priorización con aprobación humana por paso); e integración continua (IA en el pipeline DevSecOps, con auditoría permanente).

Y seis reglas de higiene: definir un scope estricto antes de activar cualquier agente autónomo; mantener un humano en el loop para explotación de alto impacto; registrar y auditar cada decisión de la IA; validar manualmente los hallazgos críticos; reentrenar los modelos con nuevas TTPs y CVEs; y establecer límites de scope y rate-limit técnico para cada agente.

6. El laboratorio: auditar un contrato con IA

La charla cierra con un ejercicio reproducible: tomar contratos vulnerables de práctica, subirlos al motor de Hashlock, revisar los hallazgos y validarlos a mano. En la demostración, el escáner marca una vulnerabilidad crítica: la función initializer del contrato es pública y carece del modificador correspondiente, así que puede llamarse múltiples veces. Un atacante puede reinvocarla para reasignarse la variable de propietario, obteniendo control total —incluidos los derechos de actualización y la capacidad de drenar fondos—. Al desplegar el proxy y llamar a initializer en transacciones separadas se abre además una condición de carrera: quien llegue primero se convierte en propietario.

Tres ideas para llevarse. La IA acelera, no reemplaza: comprime reconocimiento, escaneo y priorización, pero el juicio del pentester sigue siendo lo que convierte datos en hallazgos.

Todo PoC se valida a mano: un payload o un hallazgo generado por un agente se confirma manualmente antes de llegar al cliente. Reportar un falso positivo cuesta más credibilidad que la que ahorra la automatización.

Y se empieza pequeño y con gobernanza: piloto acotado, medición de falsos positivos, escalamiento con auditoría y humano en el loop. Para la región, el mensaje es alentador: las herramientas inventariadas son en su mayoría abiertas o freemium. La barrera ya no es el presupuesto: es el criterio, y ese se entrena practicando.

La IA acelera; no reemplaza el juicio del pentester.

Todo PoC se valida a mano.

Conocimiento abierto para Latinoamérica.