Durante años, la interfaz principal del software online fue una pantalla: una persona iniciaba sesión, abría un menú y presionaba botones. En 2026 está ganando terreno otra forma de interacción. Un agente de inteligencia artificial puede interpretar un pedido, consultar varias fuentes y utilizar herramientas para completar parte de un proceso.
Eso no significa que las interfaces gráficas vayan a desaparecer ni que todo sistema necesite un agente. Significa que las empresas deben empezar a evaluar si su software está preparado para recibir acciones provenientes de un usuario que opera mediante una capa automatizada.
El cambio parece pequeño, pero afecta la arquitectura, los permisos y la responsabilidad. Ya no alcanza con preguntar si la IA puede conectarse. La pregunta útil es: ¿qué puede consultar, qué puede modificar, bajo qué identidad y cómo podremos reconstruir lo ocurrido?
Del software usado por personas al software operado por agentes
Un chatbot tradicional responde preguntas. Un agente, en cambio, puede seleccionar herramientas y ejecutar pasos para alcanzar un objetivo. Por ejemplo, podría consultar el estado de un pedido, verificar inventario, preparar una respuesta y crear una tarea para un responsable.
La tendencia hacia esa interoperabilidad se hizo más visible con protocolos como Model Context Protocol. En diciembre de 2025, MCP pasó a formar parte de los proyectos fundadores de la Agentic AI Foundation, impulsada por la Linux Foundation. Esto no garantiza que se convierta en la única opción técnica, pero muestra que la conexión entre agentes, datos y herramientas está evolucionando hacia mecanismos más estandarizados. La comunicación oficial de la Linux Foundation explica ese cambio de gobernanza.
Nuestra interpretación editorial es que el valor no estará simplemente en agregar un chat al sistema. Estará en convertir funciones existentes en capacidades seguras, comprensibles y reutilizables por personas, automatizaciones y agentes.
Preparar software para agentes no consiste en entregarles las llaves del sistema, sino en diseñar puertas específicas y decidir quién puede abrir cada una.
Cinco capacidades que el software debería preparar
1. Herramientas pequeñas y bien definidas
Una función genérica como administrar clientes es demasiado amplia. Es preferible separar operaciones: buscar un cliente, consultar su estado, agregar una nota o solicitar una actualización. Cada herramienta debe declarar qué datos recibe, qué devuelve, qué errores puede producir y si modifica información.
Esta separación permite probar cada capacidad y asignarle un nivel de riesgo. La guía práctica de OpenAI sobre agentes distingue entre herramientas que recuperan datos y herramientas que ejecutan acciones, y recomienda aplicar controles más estrictos cuando una operación es sensible o difícil de revertir.
2. Identidad y permisos mínimos
El agente no debería heredar automáticamente todos los permisos de una cuenta administrativa. Conviene identificar al usuario, al agente, a la aplicación que lo ejecuta y al recurso solicitado. También es necesario limitar el alcance por empresa, sucursal, proyecto, tipo de registro o acción.
La especificación de autorización de MCP incorpora principios como tokens dirigidos al recurso correspondiente, validación de audiencia y prohibición del traspaso indiscriminado de tokens. Más allá del protocolo elegido, el criterio es aplicable a cualquier integración: una credencial no debería transformarse en un pase universal.
3. Aprobaciones antes de acciones críticas
Consultar stock y cancelar una venta no representan el mismo riesgo. El sistema debería clasificar las acciones y exigir confirmación cuando exista impacto financiero, legal, operativo o reputacional.
- Bajo riesgo: leer información autorizada o preparar un borrador.
- Riesgo medio: crear una tarea, modificar un dato reversible o enviar una notificación interna.
- Alto riesgo: realizar pagos, eliminar registros, cambiar permisos, cancelar operaciones o comunicarse externamente en nombre de la empresa.
La aprobación no debe ser un mensaje ambiguo. Tiene que mostrar qué acción se ejecutará, sobre qué registro, con qué datos y cuáles serán sus consecuencias previsibles.
4. Reglas de negocio fuera del modelo
Los límites importantes no deberían depender únicamente de una instrucción escrita en lenguaje natural. Si una devolución no puede superar cierto monto, una persona no puede acceder a otra sucursal o un pedido cerrado no admite modificaciones, esas condiciones deben validarse en el software.
El agente puede proponer una acción. El sistema debe decidir si esa acción es válida. Esta separación reduce la dependencia del comportamiento probabilístico del modelo y conserva una fuente verificable para las reglas críticas.
5. Trazabilidad completa
Cada ejecución debería registrar como mínimo la identidad involucrada, la herramienta solicitada, los parámetros relevantes, el resultado, las aprobaciones y los errores. Cuando corresponda, también conviene guardar la versión de la herramienta y de las reglas aplicadas.
No se trata de almacenar conversaciones sin límite. Se trata de conservar evidencia suficiente para responder preguntas operativas: quién inició la tarea, por qué se autorizó, qué cambió y cómo puede corregirse.
El problema no es solo conectar: también hay que contener
Un agente combina instrucciones, datos externos y capacidad de actuar. Esa mezcla crea riesgos que no aparecen de la misma manera en una integración convencional. Un correo, documento o página consultada podría contener instrucciones maliciosas destinadas a desviar al agente. Una herramienta demasiado amplia podría convertir un error de interpretación en una modificación masiva.
En mayo de 2026, un análisis publicado por el NIST sobre seguridad de agentes señaló que los participantes consultados coincidieron ampliamente en que estos sistemas presentan amenazas novedosas y que las prácticas fundamentales de ciberseguridad siguen siendo necesarias, aunque deben adaptarse.
El OWASP Top 10 para aplicaciones con agentes de 2026 también organiza riesgos vinculados con autonomía, herramientas, identidad, memoria e interacción entre componentes. La consecuencia práctica es clara: un filtro de contenido aislado no reemplaza los permisos, las validaciones, el aislamiento ni el monitoreo.
Hoja de ruta para preparar un sistema existente
- Elegir un proceso acotado. Empezar por una tarea frecuente, medible y reversible, no por la administración completa de la empresa.
- Mapear datos y acciones. Separar lo que el agente necesita leer de lo que podría modificar.
- Crear herramientas específicas. Diseñar funciones pequeñas con entradas estructuradas, validaciones y respuestas previsibles.
- Asignar riesgo y permisos. Definir alcance, límites, aprobaciones y condiciones de rechazo para cada herramienta.
- Probar casos adversos. Incluir instrucciones contradictorias, datos incompletos, intentos de acceder a otros registros y repeticiones inesperadas.
- Observar antes de ampliar. Medir errores, intervenciones humanas, tiempo ahorrado, acciones rechazadas y correcciones necesarias.
Durante la primera etapa puede ser conveniente que el agente prepare propuestas sin ejecutarlas. Por ejemplo, redactar una respuesta, seleccionar los registros que actualizaría o generar una orden pendiente de aprobación. Así se valida su criterio sin conceder autonomía completa.
Qué conviene construir primero
La prioridad no debería ser un agente capaz de hacer muchas cosas, sino una base de software que permita agregar capacidades sin perder control. En la práctica, suele ser más valioso construir primero:
- una API o capa de servicios consistente;
- un modelo de permisos granular;
- reglas de negocio centralizadas;
- registros de auditoría consultables;
- mecanismos de aprobación y reversión;
- un entorno de pruebas separado de los datos reales.
Estas mejoras no benefician solamente a la IA. También facilitan integraciones tradicionales, aplicaciones móviles, automatizaciones y mantenimiento. Por eso, incluso si el agente cambia de proveedor o modelo, la inversión puede conservar valor.
Conclusión: diseñar autonomía gradual, no acceso total
Los agentes están convirtiendo al software online en algo que puede ser operado mediante objetivos y no solo mediante pantallas. Sin embargo, la capacidad de actuar no equivale a la autorización para hacerlo.
El paso concreto para una empresa es seleccionar un proceso, enumerar sus acciones y clasificar cada una según su impacto. A partir de allí puede decidir cuáles serán de lectura, cuáles generarán borradores y cuáles exigirán aprobación humana.
Si el sistema actual no ofrece APIs delimitadas, permisos granulares o registros suficientes, conviene resolver esa base antes de aumentar la autonomía. Ideasweb puede ayudar a evaluar y desarrollar software y sistemas a medida preparados para integrar herramientas y agentes con controles ajustados a la operación real.
