Durante mucho tiempo hablamos con la inteligencia artificial como si fuera una caja de texto inteligente: le escribíamos algo, nos respondía, copiábamos una parte, corregíamos otra, volvíamos a preguntar y seguíamos trabajando nosotros. Eso ya era potente, y de hecho lo sigue siendo. Pero en este último tiempo empieza a aparecer una pregunta más incómoda y bastante más interesante: ¿qué pasa cuando la IA no solo responde, sino que también puede hacer cosas? No hablo de magia ni de robots reemplazando personas de un día para el otro, sino de algo más concreto: modelos capaces de usar herramientas, leer pantallas, navegar, escribir código, planificar pasos y conectarse con sistemas reales. Y cuando una tecnología pasa de responder a actuar, la conversación cambia de naturaleza. Porque una respuesta equivocada puede ser molesta, pero una acción equivocada puede tener impacto.
De la conversación a la acción#
Hasta hace poco, gran parte de la experiencia con IA generativa pasaba por una interfaz muy simple: una caja de texto. Uno escribía una pregunta y recibía una respuesta. Eso abrió un montón de posibilidades —explicaciones, ejemplos, ideas, resúmenes, código, correcciones— pero mantenía una frontera bastante clara: la IA sugería y nosotros ejecutábamos. La IA escribía una función y nosotros la revisábamos, la pegábamos, la probábamos y, si tenía sentido, la llevábamos a producción. La IA explicaba un comando y nosotros decidíamos si correrlo. Ese límite la mantenía en un lugar de asistencia: muy potente, sí, pero todavía contenido.
Ahora empieza a aparecer otra etapa, una en la que la IA puede interactuar con herramientas, entornos de desarrollo, navegadores, APIs, archivos, terminales e incluso interfaces gráficas. Eso ya no es solamente conversar; se acerca bastante a delegar una parte del trabajo.
¿Qué estamos llamando agentes?#
La palabra “agente” se escucha cada vez más, así que conviene bajarla a tierra. Un agente de IA no debería imaginarse como una entidad mágica que entiende todo, decide todo y resuelve todo sola, al menos no en la realidad práctica de hoy. Una forma simple de pensarlo es esta: un agente es una IA que no solo genera una respuesta, sino que puede seguir un objetivo, dividirlo en pasos, usar herramientas y ejecutar acciones para intentar completarlo.
La diferencia parece pequeña, pero no lo es. Un chatbot responde; un agente intenta avanzar. Un chatbot te explica cómo revisar una web; un agente podría abrirla, leer la información, completar una planilla y devolverte un resultado. Un chatbot te sugiere cómo resolver un bug; un agente podría revisar el repositorio, proponer cambios, editar archivos, correr tests y dejarte una rama lista para mirar. El cambio no está solo en la inteligencia del modelo, sino en su conexión con el entorno. Y cuando conectamos IA con herramientas reales, aparecen oportunidades enormes y también riesgos mucho más concretos.
Lo que está pasando en 2024#
Durante este año vimos varias señales de que la industria se mueve desde la IA conversacional hacia experiencias más orientadas a tareas. GitHub presentó Copilot Workspace en abril, proponiendo un flujo donde una tarea arranca en lenguaje natural y avanza hacia un plan, cambios de código, pruebas y una posible implementación dentro del propio entorno. Cognition mostró Devin como una propuesta de “ingeniero de software de IA”, con capacidad de planificar y ejecutar tareas de desarrollo usando editor, navegador y terminal. OpenAI presentó o1-preview en septiembre, una serie de modelos pensados para razonar más tiempo antes de responder en problemas complejos. Y en octubre, Anthropic mostró una capacidad experimental muy interesante en Claude: el uso de computadora, es decir, la posibilidad de que el modelo mire una pantalla, mueva el cursor, haga clic y opere una interfaz de manera más parecida a como lo haría una persona.
Nada de esto está maduro ni listo para usarse sin cuidado, y menos para llevarlo directo a procesos críticos. Pero marca una dirección clara: la IA empieza a salir del chat y a acercarse al escritorio, al navegador, al editor, al repositorio, a la terminal y a las APIs que usamos todos los días. Y cuando eso pasa, la pregunta deja de ser solamente qué tan buena es la respuesta para incluir otra igual de importante: qué tan segura, controlada y reversible es la acción.
La diferencia entre ayudar y actuar#
Hay una distancia enorme entre que una IA nos diga qué hacer y que lo haga. Si le preguntamos cómo borrar archivos temporales y responde mal, podemos revisar antes de ejecutar; pero si le damos permiso para operar sobre un entorno y corre el comando equivocado, el problema deja de ser teórico. Si le pedimos que redacte un correo, lo leemos antes de enviarlo; si le damos acceso para enviarlo directamente, necesitamos otros controles. Si propone un cambio en una base de datos, lo discutimos; si le damos acceso para correr scripts, la validación previa deja de ser opcional.
Por eso, cuando hablamos de agentes, no alcanza con hablar de inteligencia. Hay que hablar de permisos, de límites, de trazabilidad, de entornos seguros, de revisión humana, de reversibilidad, de arquitectura y de responsabilidad. La IA puede ayudarnos mucho más cuando puede actuar, pero también puede equivocarse con mucho más impacto.
El entusiasmo es razonable#
No quiero escribir esto desde el miedo, porque sería un error mirar esta evolución solo como una amenaza. Un agente bien diseñado puede cambiar bastante la forma en que trabajamos. En desarrollo de software podría revisar un issue, buscar archivos relacionados, proponer un plan, generar una primera versión de código, correr tests, preparar documentación, resumir un pull request o revisar logs. En operaciones podría consultar métricas, revisar alertas, cruzar información entre sistemas, preparar reportes de incidentes o sugerir acciones de recuperación. En áreas de negocio podría consultar datos, preparar análisis, completar tareas administrativas o conectar herramientas que hoy viven separadas.
Bien usado, todo eso reduce fricción, y reducir fricción es una de las mejores maneras de generar valor real con tecnología. No porque la IA haga todo sola, sino porque puede encargarse de partes repetitivas, mecánicas o exploratorias y dejarnos más tiempo humano para decidir, revisar, priorizar y pensar.
Pero el agente no entiende tu empresa por defecto#
Este punto me parece central. Un agente puede ser capaz de usar herramientas sin que eso signifique que entiende el contexto de una organización. No sabe qué cliente es crítico, qué proceso tiene excepciones históricas, qué tabla no debería tocarse sin avisar a datos, qué integración falla fuera de horario, qué parte del sistema está en migración o qué deuda técnica el equipo decidió tolerar a propósito. Puede saberlo si se lo damos, puede respetarlo si lo definimos y puede operar mejor si lo guiamos, pero no lo adivina por arte de magia.
Y esto conecta con algo que ya veníamos viendo en programación asistida: cuanto más grande es el sistema, más importante se vuelve el contexto. Un agente sin contexto puede actuar rápido, pero actuar rápido no siempre es actuar bien.
La ilusión del piloto automático#
Cada vez que aparece una tecnología que automatiza algo, aparece también la tentación de dejarla trabajar sola. Es lógico: si una herramienta resuelve tareas, queremos sacarnos trabajo de encima. Pero en sistemas reales, el piloto automático absoluto suele ser peligroso, no porque la IA sea inútil, sino porque el mundo donde opera es ambiguo, cambiante, lleno de excepciones y muchas veces mal documentado.
Un agente puede interpretar mal una instrucción, elegir la herramienta equivocada, completar un formulario con datos incorrectos, tomar una decisión razonable en apariencia pero mala para el negocio, ejecutar pasos en un orden que no corresponde o insistir cuando debería detenerse y preguntar. Incluso puede lograr el objetivo rompiendo una regla que no estaba escrita en ningún lado. Y ahí está uno de los grandes desafíos: muchas reglas importantes de una organización viven en conversaciones, experiencia, memoria del equipo, incidentes pasados y conocimiento tribal. Si queremos que una IA actúe dentro de nuestros sistemas, tenemos que empezar a convertir parte de ese conocimiento en instrucciones, reglas y límites claros.
Los agentes necesitan barandas#
Me gusta pensar que los agentes necesitan barandas. No para impedirles trabajar, sino para evitar que se salgan del camino. Una baranda puede ser una regla de arquitectura, un permiso limitado, un entorno sandbox, una lista de acciones prohibidas, una revisión humana obligatoria antes de algo irreversible, un conjunto de tests, un registro de auditoría o un criterio de escalamiento para cuando el agente no está seguro. Cuando un agente solo responde texto, esas barandas son importantes; cuando puede actuar, se vuelven indispensables.
Un agente que consulta información necesita permisos; uno que la modifica necesita controles; uno que despliega código necesita revisión; uno que opera sobre clientes necesita trazabilidad; uno que ejecuta comandos necesita límites muy claros. Por eso la pregunta no debería ser solamente qué puede hacer este agente, sino también qué no debería poder hacer nunca.
La seguridad cambia de lugar#
Cuando conectamos IA con herramientas, la seguridad deja de ser un tema externo al modelo. Ya no se trata solo de si responde algo incorrecto, sino de qué accesos tiene, qué datos ve, qué acciones puede ejecutar y cómo se controla su comportamiento. Empiezan a ser inevitables preguntas como si el agente puede acceder a datos sensibles, enviar información a terceros, ejecutar comandos, modificar archivos, tocar producción, crear usuarios o borrar datos; si queda registro de lo que hizo, si podemos reconstruir por qué tomó una decisión y —tal vez la más interesante— si alguien podría engañarlo desde una página web, un documento o un texto malicioso.
Ese último punto es especialmente delicado. Si un agente navega, lee documentos o interpreta instrucciones externas, también puede quedar expuesto a instrucciones escondidas dentro del contenido que consume. Dicho de otro modo: cuando la IA empieza a usar herramientas, aparece una nueva superficie de ataque. No alcanza con decir “el modelo es bueno”; hay que diseñar el sistema completo pensando en seguridad.
Automatizar no es delegar responsabilidad#
Este punto vale la pena repetirlo: automatizar una tarea no significa delegar la responsabilidad. Si un agente ejecuta una acción dentro de una empresa, alguien diseñó ese flujo, alguien le dio permisos, alguien definió los límites y alguien decidió ponerlo a trabajar. La responsabilidad sigue siendo humana y organizacional. Esto vale para la IA, pero también para cualquier automatización: un script mal hecho puede borrar datos, un job mal configurado puede saturar un servicio, un pipeline mal armado puede desplegar algo roto. La diferencia con la IA es que aparece una capa adicional de interpretación, y donde hay interpretación, hay ambigüedad. Por eso los agentes tienen que diseñarse como parte de una arquitectura, no como juguetes sueltos conectados a sistemas importantes.
El problema no es que la IA actúe, sino dónde y cómo#
No todos los usos tienen el mismo riesgo. Un agente que ordena archivos en una carpeta de pruebas no es lo mismo que uno que modifica datos de clientes; uno que resume logs no es lo mismo que uno que reinicia servicios; uno que propone código no es lo mismo que uno que hace merge automático a main. Me resulta útil pensarlo en niveles de autonomía crecientes, desde la pura asistencia —donde la IA responde, explica o propone y el humano ejecuta— hacia la preparación, donde la IA arma cambios, borradores o planes y el humano revisa y aprueba.
Un paso más allá está la ejecución controlada: la IA actúa en entornos limitados, con permisos acotados, registro y posibilidad de revertir, mientras el humano supervisa. Después aparece una autonomía parcial, donde la IA completa tareas repetitivas dentro de reglas muy claras y el humano audita y ajusta límites. Y en el extremo está la autonomía crítica, con la IA operando sobre procesos importantes con poco o ningún control humano inmediato. Para muchos sistemas empresariales actuales, ese último escalón conviene tratarlo con muchísimo cuidado; no porque sea imposible para siempre, sino porque todavía estamos aprendiendo cómo hacerlo bien.
Los agentes en desarrollo de software#
En software esta evolución se siente con fuerza. Primero tuvimos autocompletado, después asistentes que explicaban código, luego generación de funciones, tests y documentación; ahora empezamos a ver herramientas que intentan tomar una tarea más completa: entender un issue, armar un plan, tocar archivos, ejecutar pruebas y acercarse a una solución. Puede ser muy valioso, pero también amplifica los mismos problemas que ya vimos al programar con IA. Si el agente no entiende la arquitectura, ubica código donde no corresponde; si no conoce las convenciones, inventa patrones nuevos; si le falta contexto, duplica lógica; si los tests son pobres, cree que todo está bien; si el repositorio es caótico, copia el caos; si las instrucciones son vagas, completa los huecos con supuestos. La diferencia es que ahora no solo genera una respuesta: puede avanzar varios pasos en una dirección equivocada.
Por eso, para desarrollo, los agentes necesitan algo más que acceso al repositorio. Necesitan reglas, documentación, criterios de aceptación, límites de arquitectura, pruebas reales, revisión humana y, sobre todo, que el equipo tenga claro qué está intentando construir.
La documentación vuelve a ser importante#
Hay algo casi irónico en todo esto. Durante años muchos equipos trataron la documentación como una molestia: algo que se escribe cuando sobra tiempo, que se desactualiza y que nadie lee. Pero cuanto más queremos que la IA nos ayude, más importante se vuelve tener contexto escrito, porque un agente no puede adivinar la intención del negocio, ni reconstruir la historia de una arquitectura que nadie documentó, ni respetar reglas que nunca fueron explicitadas, ni distinguir una excepción válida de una mala práctica heredada si todo está mezclado.
Así, paradójicamente, la IA vuelve a poner valor sobre prácticas que nunca debieron perderlo: buenas especificaciones, criterios de aceptación, documentación de arquitectura, decisiones técnicas registradas, guías de desarrollo, runbooks, postmortems, contratos de APIs y tests que expresen comportamiento real. No como burocracia, sino como contexto operativo, memoria del sistema y barandas que sirven para humanos y también para máquinas.
No todo tiene que ser agente#
Conviene decir algo que parece obvio pero que se pierde con el entusiasmo: no todo problema necesita un agente. A veces alcanza con un script, con una automatización simple, con una integración bien hecha, con mejorar un proceso, con documentar o con eliminar un paso innecesario. La IA es muy poderosa, pero no debería ser la excusa para complicar soluciones simples. Si una tarea es determinística, repetitiva y con reglas claras, tal vez un proceso clásico sea mejor que un agente interpretando instrucciones; si una acción es crítica y sensible, tal vez convenga mantener aprobación humana; si un flujo necesita trazabilidad fuerte, tal vez haya que diseñarlo como sistema antes de conectarlo a un modelo. La pregunta no es dónde podemos meter IA, sino qué problema real queremos resolver y qué nivel de autonomía tiene sentido permitir.
Empezar por lo interno, no por lo crítico#
Si una organización quiere experimentar con agentes, yo lo haría primero en lugares de bajo riesgo: asistentes internos para documentación, análisis de logs sin capacidad de modificar nada, generación de borradores y reportes, clasificación de tickets, revisión de pull requests sin merge automático, búsqueda en bases de conocimiento o automatizaciones en sandbox. Ese tipo de casos permite aprender sin poner en juego procesos críticos desde el primer día; después, con experiencia, métricas, errores conocidos y mejores controles, se puede avanzar. Empezar conectando un agente a producción, datos sensibles o acciones irreversibles solo porque la demo se ve impresionante me parece una mala idea. La madurez no está en automatizar todo rápido, sino en saber dónde conviene automatizar, con qué límites y bajo qué responsabilidad.
El rol del liderazgo técnico#
Los agentes de IA no son solo una decisión de herramienta; son también una decisión de liderazgo técnico, porque alguien tiene que definir qué se permite, qué no, dónde se prueba, cómo se mide, cómo se audita y cómo se protege la organización. Un equipo puede entusiasmarse con una herramienta nueva y empezar a usarla de forma desordenada —eso ya pasa con muchas tecnologías— pero cuando la herramienta puede actuar, el desorden pesa más. El liderazgo técnico ayuda a convertir el entusiasmo en método, no para frenar la innovación sino para hacerla sostenible.
Hay conversaciones que empiezan a ser necesarias: qué tareas queremos delegar parcialmente, qué permisos y qué datos puede tener un agente, qué acciones requieren aprobación humana, qué entornos son seguros para experimentar, cómo registramos lo que hizo, cómo evaluamos si realmente mejora el trabajo, qué hacemos cuando se equivoca y quién es responsable del resultado. Si esas preguntas no aparecen, la herramienta puede avanzar más rápido que la organización, y cuando eso ocurre rara vez termina bien.
La productividad también necesita medición#
Otro punto importante: no todo lo que parece más rápido es realmente más productivo. Un agente puede completar una tarea en minutos, pero si después el equipo necesita horas para revisar, corregir y limpiar lo que hizo, tal vez no hubo mejora real. La productividad no debería medirse solo por cantidad de acciones ejecutadas; también importan la calidad del resultado, el tiempo de revisión, los errores, el impacto en deuda técnica, la facilidad de mantenimiento, la seguridad y la confianza del equipo. Pasa lo mismo que con el código: más código no siempre es mejor software, y más acciones no significan mejor automatización. La buena automatización reduce ruido; la mala genera trabajo invisible.
Humanos en el circuito#
Durante mucho tiempo vamos a necesitar humanos en el circuito, y no como una frase para quedarnos tranquilos, sino como diseño real del sistema: humanos para aprobar cambios importantes, para revisar decisiones ambiguas, para interpretar contexto de negocio, para definir prioridades, para detectar que algo “técnicamente correcto” no tiene sentido en la práctica y para asumir responsabilidad. La IA puede ayudarnos a hacer más cosas, pero eso no significa apagar el criterio. De hecho, cuanto más capaz se vuelve la herramienta, más importante se vuelve el criterio de quien la usa.
Si tuviera que pensar una forma razonable de empezar con agentes, la haría gradual: identificar tareas repetitivas, frecuentes y de bajo riesgo; separar claramente asistencia, preparación y ejecución; empezar en entornos internos o sandbox; definir permisos mínimos; registrar todas las acciones; exigir aprobación humana para lo sensible; crear documentación y reglas que el agente pueda seguir; medir resultados reales y no demos lindas; revisar errores y ajustar límites; y escalar solo cuando haya confianza suficiente. No se trata de tenerle miedo a la IA, sino de no confundir capacidad con madurez. Un agente puede ser capaz de hacer muchas cosas; una organización madura decide cuáles de esas cosas conviene permitir.
Estamos entrando en una etapa muy interesante. La IA ya no es solamente una herramienta para escribir mejor, resumir más rápido o generar código: empieza a convertirse en una capa que puede operar sobre otras herramientas, y eso cambia la discusión, porque cuando se conecta con los sistemas deja de ser una ayuda individual y pasa a formar parte de la arquitectura de trabajo. Puede mejorar procesos, reducir tareas repetitivas, ayudar a equipos chicos a hacer más, ordenar información dispersa y acelerar análisis; pero también puede actuar con poco contexto, ejecutar mal, tocar datos que no debería, amplificar errores y generar una falsa sensación de autonomía segura.
Por eso la pregunta de fondo no es si los agentes van a llegar —ya están empezando a llegar— sino cómo vamos a integrarlos sin perder control, seguridad, criterio y responsabilidad. Una cosa es tener una IA que responde; otra muy distinta es tener una IA que hace. Y cuando una herramienta empieza a hacer cosas dentro de nuestros sistemas, ya no alcanza con mirar la demo: hay que mirar la arquitectura, los permisos, los límites, la trazabilidad, los datos, la seguridad, el proceso y, sobre todo, la responsabilidad humana detrás de cada automatización. La IA puede dejar de ser una caja de texto y convertirse en una compañera de trabajo mucho más activa; pero si va a operar sobre nuestros sistemas, tenemos que dejar de pensarla como una herramienta simpática y empezar a diseñarla como parte real de nuestra tecnología. Porque cuando la IA deja de responder y empieza a hacer cosas, también nosotros tenemos que empezar a hacernos mejores preguntas.
Fuentes consultadas#
- GitHub, “GitHub Copilot Workspace: Welcome to the Copilot-native developer environment”, 29 de abril de 2024.
- Cognition, “Introducing Devin, the first AI software engineer”, 12 de marzo de 2024.
- OpenAI, “Introducing OpenAI o1-preview”, 12 de septiembre de 2024.
- Anthropic, “Introducing computer use, a new Claude 3.5 Sonnet, and Claude 3.5 Haiku”, 22 de octubre de 2024.
- Anthropic, “Developing a computer use model”, 22 de octubre de 2024.