🩺 El bisturí no firma la cirugía
Un agente con herramientas necesita límites operativos
Un equipo conecta un agente a su repositorio, a la base de datos y al tablero ejecutivo. La demo tarda minutos, corrige un campo, abre un cambio y deja a todos con la sensación de haber visto el futuro. Falta una pregunta antes del aplauso.
Usar un agente no es lo mismo que gobernarlo cuando puede tocar código, datos, APIs, infraestructura, reportes y procesos de negocio.
La mano sigue siendo responsable.
Un agente deja de ser un asistente pasivo cuando puede ejecutar pasos, llamar herramientas, modificar archivos, consultar bases, abrir solicitudes, actualizar tableros o disparar pipelines. En una empresa colombiana eso puede sonar muy atractivo para acelerar soporte, analítica, migraciones o gobierno de datos. También puede convertirse en un riesgo operativo si se le entregan permisos sin límites, trazabilidad ni plan de reversa.
NIST publicó en 2024 el perfil de IA generativa para su AI Risk Management Framework. El documento no trata la IA como truco de productividad, sino como sistema que debe ser diseñado, evaluado, gobernado y monitoreado durante su ciclo de vida. Esa mirada importa porque un agente no solo produce texto. Produce acciones encadenadas con efectos acumulados.
OWASP llevó el punto a seguridad aplicada. En su Top 10 para aplicaciones con LLM de 2025, el riesgo de agencia excesiva aparece cuando un sistema recibe demasiada funcionalidad, demasiados permisos o demasiada autonomía. La definición es sencilla y fuerte. El daño no depende solo de que el modelo alucine. También puede venir de una instrucción ambigua, una inyección de prompt, una herramienta comprometida o una cadena de agentes que amplifica el error.
AWS, en su guía prescriptiva de seguridad para IA agéntica, mapea ese riesgo a controles concretos como delimitar el alcance del agente, hacer modelado de amenazas, aplicar autenticación adaptativa, restringir operaciones contra sistemas sensibles, monitorear comportamiento y tener apagado de emergencia para escenarios de alto riesgo. El asunto ya no cabe en prompt engineering. Entra en arquitectura, seguridad y operación.
Pensemos en un quirófano. Un bisturí muy preciso no decide dónde cortar, cuánto cortar ni cuándo detenerse. El cirujano responde por diagnóstico, consentimiento, esterilidad, equipo, monitoreo, sangrado, cierre y recuperación. En tecnología, un agente poderoso es ese bisturí. Puede acelerar una intervención, pero no firma la cirugía.
Gobernar agentes significa definir qué puede hacer, sobre qué sistemas, con qué permisos, bajo qué evidencia, con qué supervisión humana y con qué mecanismo de reversa. Permiso es la autorización concreta para ejecutar una acción. Trazabilidad es poder reconstruir qué pasó, quién lo pidió, qué herramienta se invocó y qué cambió. Linaje es saber de dónde viene un dato y cómo se transformó antes de llegar a un reporte o modelo.
Sin esas bases, el agente se vuelve un practicante con acceso a sala de cirugía. Puede parecer útil porque se mueve rápido, pero nadie serio confunde movimiento con control. La mano sigue siendo responsable.
La escena se ve con facilidad en datos. Un equipo quiere que un agente corrija automáticamente tablas de clientes antes de cargar un reporte ejecutivo. La versión apresurada le entrega una función que escribe directo sobre la base. La versión con criterio separa lectura, propuesta, validación y aprobación.
# Sin gobierno
def corregir_cliente(db, cliente_id, nuevo_email):
db.execute(
"update clientes set email = ? where id = ?",
[nuevo_email, cliente_id]
)
# Con gobierno
def proponer_correccion(db, usuario, cliente_id, nuevo_email):
actual = db.query("select email from clientes where id = ?", [cliente_id])
cambio = {
"tabla": "clientes",
"campo": "email",
"antes": actual[0]["email"],
"despues": nuevo_email,
"solicitado_por": usuario,
"requiere_aprobacion": True
}
db.insert("cambios_pendientes", cambio)
return cambio
La primera función parece eficiente, pero mezcla recomendación y ejecución. Si el agente interpreta mal una instrucción, recibe un dato contaminado o actúa sobre el cliente equivocado, el error entra directo a producción. La segunda no frena la productividad. La encauza. El agente prepara una propuesta auditable, deja evidencia del antes y el después, identifica al solicitante y exige aprobación antes de tocar el dato maestro.
Ese patrón aplica igual en código, infraestructura y BI. Un agente puede abrir un pull request, pero no debería desplegar a producción sin pruebas. Puede sugerir cambios en un pipeline, pero no debería borrar históricos sin respaldo. Puede generar un indicador, pero no debería publicar un tablero sin validar la regla del negocio. La mano sigue siendo responsable.
El antecedente histórico más útil no viene de IA, sino de trading algorítmico. En 2013, la SEC sancionó a Knight Capital por fallas asociadas a un incidente de agosto de 2012. La investigación encontró salvaguardas insuficientes, controles inadecuados de despliegue y pruebas, y millones de órdenes erróneas enviadas al mercado. El sistema actuó rápido. Justamente por eso el daño también fue rápido.
La lección para agentes es directa. Cuando una automatización tiene acceso real a sistemas críticos, no basta preguntar si la lógica parece inteligente. Hay que saber qué pasa cuando falla, quién la detiene, qué límite tenía, qué bitácora deja y cómo se recupera el estado anterior.
Recursos recomendados
- NIST AI Risk Management Framework Generative AI Profile tipo informe
- OWASP Agentic Skills Top 10 tipo guía de seguridad
- AWS Security for agentic AI tipo guía técnica
- OpenAI Agents SDK Guardrails tipo documentación técnica
En Colombia y LATAM el riesgo se vuelve muy concreto. Hay equipos pequeños con presión por reducir tiempos, automatizar reportes, acelerar migraciones o atender usuarios internos sin crecer nómina. El agente promete aliviar esa presión. Pero si se conecta a una base productiva con un usuario administrador compartido, si nadie registra sus llamadas, si no hay ambiente de pruebas y si las aprobaciones quedan por chat, el supuesto ahorro se convierte en deuda operativa.
En BI, el riesgo no siempre es borrar una tabla. A veces es más sutil. Un agente puede cambiar una métrica de ventas, mezclar estados contables, duplicar clientes o publicar una lectura ejecutiva sin explicar supuestos. En ingeniería de datos puede reintentar un pipeline hasta duplicar cargas. En cloud puede crear recursos sin etiquetas ni límites. En arquitectura puede integrar servicios sin revisar identidad, red o costo.
La capacidad humana que marca la diferencia no es escribir el prompt más bonito. Es saber diseñar límites. Un buen profesional pregunta qué acciones son reversibles, cuáles requieren aprobación, qué datos son sensibles, qué logs se guardan, qué pruebas bloquean el cambio, qué permisos mínimos necesita el agente y qué alerta indica que algo salió mal.
La evaluación de talento también cambia. Preguntar si alguien ha usado agentes dice poco. Mejor pedirle que diseñe uno para una tarea real y que explique permisos, pruebas, observabilidad, recuperación y responsabilidad. Observabilidad significa poder ver el comportamiento del sistema mediante registros, métricas y eventos. Si la persona solo habla de velocidad y no de control, todavía está pensando en demo, no en operación.
Los agentes ya empiezan a entrar a datos, desarrollo, soporte, seguridad, finanzas y operaciones. Evitarlos no es una estrategia técnica. Impedir que un flujo experimental actúe como autoridad sí lo es. En un quirófano bien gobernado, cada instrumento tiene propósito, esterilización, responsable y protocolo. En una plataforma bien gobernada, cada agente debe tener alcance, permisos, bitácora, pruebas y botón de parada.
Primero clasifica tus agentes por nivel de daño posible, luego separa propuesta de ejecución en los procesos críticos, después revisa los controles de NIST, OWASP y AWS para convertirlos en checklist técnico, por último practica con un caso pequeño donde el agente solo proponga cambios y una persona apruebe antes de tocar producción. El bisturí puede estar listo sobre la mesa. La firma sigue siendo humana.
¿Qué control mínimo exigirías antes de permitir que un agente toque datos, código o infraestructura productiva en tu empresa? 🧠