Qué cambia para quien tiene una app o un sistema
La respuesta corta: tu sistema va a ser usado por quien no es una persona. Un agente de IA no hace clic en botones como lo haría alguien. Llama a funciones, lee datos y dispara acciones, y solo puede hacerlo si tu sistema le ofrece un camino ordenado para ello.
En la práctica, los sistemas con reglas claras, una API bien diseñada y permisos separados por perfil están listos para recibir agentes. Los sistemas en los que la regla de negocio está dispersa en la pantalla, en hojas de cálculo paralelas y en la cabeza de un empleado, no lo están. El agente va a fallar justamente donde la regla nunca se escribió.
No necesitas construir un agente mañana. Necesitas evitar hoy decisiones que lo hagan imposible o peligroso más adelante.
Por qué el tema se ha calentado ahora
En las últimas semanas, Google anunció que está convirtiendo a Gemini en un agente capaz de planificar, ejecutar tareas y trabajar entre aplicaciones y sistemas de empresas, empezando por el público corporativo. La propuesta incluye delegar trabajo en subagentes e incluso darle al agente una identidad propia en el entorno de trabajo, con dirección de correo electrónico.
Casi al mismo tiempo, Microsoft lanzó nuevos recursos de seguridad orientados a agentes, entre ellos uno que monitorea los agentes que usa la empresa. Su discurso trata a los agentes de IA como algo parecido a una amenaza interna, porque tienen acceso y autonomía y no siempre se comportan como se espera.
Lee los dos movimientos juntos. Las grandes empresas están empujando agentes hacia el trabajo cotidiano y, en el mismo aliento, vendiendo control sobre ellos. Es un mensaje para quien desarrolla sistemas: lo difícil no es hacer que el agente actúe, sino lograr limitar y auditar lo que hace.
Cinco cosas para dejar listas en tu sistema
Ninguna de estas es una novedad en ingeniería de software. La diferencia es que, con agentes, el costo de no haberlas hecho aumenta mucho.
Si vas a contratar un sistema nuevo, pide cada punto dentro del alcance. Si ya tienes un sistema, usa esta lista como diagnóstico.
- API con operaciones claras: crear pedido, cancelar, consultar saldo. Cada operación con nombre, entrada y salida definidos, y no solo pantallas que alguien aprendió a usar.
- Reglas de negocio en el servidor, no en la pantalla: el límite de descuento, el plazo de cancelación y el valor máximo de reembolso deben validarse en el back-end, porque el agente no pasa por la pantalla.
- Permisos por perfil, con granularidad: lectura separada de escritura, y escritura separada de acciones sensibles como pagar, eliminar y enviar mensajes a clientes.
- Log de auditoría que diga quién hizo qué: usuario, agente, hora, dato antes y después. Sin eso, te enteras del error cuando el cliente se queja.
- Punto de confirmación humana: las acciones irreversibles o de valor alto van a una cola de aprobación y no se ejecutan directamente.
Trata al agente como a un empleado nuevo, no como a un superusuario
El error más común que se ve es darle al agente la llave maestra porque es más rápido. Una única credencial, con acceso a todo, pegada en un archivo de configuración. Funciona en la demostración y es un riesgo en la primera semana de uso real.
El camino más sano es crear una identidad propia para el agente, con permisos mínimos, como si fuera un practicante en su primer día. Lee pedidos, pero no modifica precios. Sugiere un reembolso, pero no lo aprueba. Cuando necesite más acceso, lo habilitas de manera consciente.
Esto coincide con lo que está señalando el mercado: si hasta los fabricantes de agentes hablan de identidad y monitoreo, es porque el modelo se equivoca lo suficiente como para que nadie confíe a ciegas. Los modelos de lenguaje pueden interpretar mal una instrucción o ser engañados por un texto malicioso dentro de un correo o documento que leen. Por eso la regla debe valer en el servidor, y no en el prompt.
Errores comunes al poner a trabajar a un agente
El primero es empezar por el proceso más crítico. Empieza por algo de bajo riesgo y alto volumen: triaje de tickets, borrador de respuestas, verificación de registros. Si se equivoca, el costo es pequeño y aprendes cómo se comporta.
El segundo es no medir. Antes de encender el agente, define qué es un buen resultado: tiempo por tarea, tasa de corrección humana, tareas que volvieron. Sin eso, la opinión se convierte en el clima del equipo.
El tercero es creer que el agente reemplaza el diseño del proceso. Si el flujo manual ya es confuso, el agente automatiza la confusión a mayor velocidad. Mapea el proceso primero, simplifícalo y solo entonces automatiza.
El cuarto es ignorar el costo recurrente. Cada tarea del agente consume llamadas a un modelo, y los agentes que hacen varios pasos consumen más. Pide una estimación por tarea, y no solo el precio de montar la solución.
Cuándo un agente no vale la pena
Mi posición: buena parte de los casos en que alguien pide un agente se resuelve mejor con una automatización común. Si el flujo es siempre igual (llegó el pedido, genera la factura, avisa al cliente), un código determinista es más barato, más rápido y predecible. Un agente tiene sentido cuando hay variación real: textos libres, excepciones, decisiones que dependen del contexto.
Otra señal de que aún no es el momento: no tienes los datos organizados. Un agente sobre registros duplicados e historial incompleto solo entrega respuestas equivocadas con mucha confianza.
Y si tu problema es validar si las personas usarían la app, los agentes no son el primer paso. Primero pruebas el flujo central con usuarios reales.
Cómo probar la idea antes de gastar en ella
Antes de contratar una integración con IA, diseña el flujo en un prototipo navegable y observa dónde entraría el agente: en qué pantalla, con qué permiso, con qué confirmación. Ese ejercicio ya revela la mitad de los problemas de reglas y de permisos, sin escribir el back-end.
En SKAD, el prototipo generado por IA cuesta R$ 99 y viene con un presupuesto aproximado. Sirve para ver la app funcionando y discutir estos puntos con el equipo antes de decidir qué vale la pena desarrollar.
Preguntas frecuentes
¿Qué es un agente de IA en una aplicación?
Es un programa de IA que recibe un objetivo, decide los pasos y ejecuta acciones en el sistema, como consultar datos, crear registros o enviar mensajes. Un chatbot solo responde; el agente también actúa.
¿Necesito rehacer mi sistema para usar agentes de IA?
No siempre. Si ya tiene una API ordenada, reglas en el servidor, permisos por perfil y log de auditoría, se puede integrar un agente poco a poco. Si no los tiene, esos ajustes van primero.
¿Son seguros los agentes de IA?
Depende de cómo limites el acceso. El riesgo baja cuando el agente tiene identidad propia, permisos mínimos, acciones sensibles con aprobación humana y todo registrado en logs.
¿Agente de IA o automatización común: cuál elegir?
Si el proceso es siempre igual, una automatización común lo resuelve mejor y cuesta menos. El agente vale la pena cuando hay texto libre, excepciones y decisiones que cambian según el contexto.
Conclusión
Antes de hablar con cualquier proveedor de agentes, haz un ejercicio de una hora: enumera cinco acciones que alguien realiza hoy en tu sistema y, para cada una, escribe quién puede ejecutarla, qué límite existe y dónde queda registrado. Donde falte respuesta, ahí está el trabajo que hay que hacer primero. Después elige una única tarea de bajo riesgo para el primer agente y mide el resultado durante algunas semanas antes de ampliar.