Para negocios Para empresas Soluciones Aplicaciones Precios Desarrolladores Blog Documentación Iniciar un espacio de trabajo
Blog / Perspectiva

El próximo usuario de ERP puede no ser humano

Un argumento, para el emprendedor que construye una empresa en torno a agentes y el desarrollador que construirá el software que usarán. El software empresarial siempre ha sido diseñado para un usuario con ojos y manos. Ese usuario está a punto de ser acompañado por uno que no tiene ninguno, y el software tendrá que cambiar más de lo que a sus proveedores les gustaría.

Lectura de 8 minActualizado 4 de septiembre de 2026Ingeniería de Sois, el equipo que construye la plataforma

Una sala de reuniones después del horario laboral: una larga mesa de roble, sillas metidas, un solo cuaderno cerrado, una ventana hacia una ciudad oscura.
Respuesta corta

El software empresarial tiene en mente a un solo usuario, y siempre ha sido el mismo: una persona con ojos para leer una pantalla y manos para llenarla. Cada formulario, pestaña, asistente y panel de control es una concesión a la memoria de trabajo y atención de esa persona. El modelo de datos subyacente suele ser sólido. La interfaz es una representación de ello para un tipo de lector.

Ha llegado un segundo tipo de lector. Un agente de IA no mira una pantalla; lee una lista de herramientas con nombres, descripciones y esquemas, y las llama. El software que quiere ser operado por ese usuario tiene que exponer sus acciones como herramientas, hacer cumplir permisos en cada llamada, preguntar por diseño y mantener el registro como un subproducto. Eso es lo que significa el software nativo de agente, y es un cambio más grande que agregar una ventana de chat a las viejas pantallas.

Cada pantalla es una suposición sobre quién está mirando

Considera lo que es un ERP desde el lado de su usuario. Detrás de la marca hay un conjunto de tablas y reglas: clientes, artículos, pedidos, facturas, movimientos de stock y las restricciones que los mantienen consistentes. Delante de eso está la parte en la que se gastó la mayor parte del dinero: varios miles de pantallas que presentan esas tablas a una persona unos pocos campos a la vez, en un orden que una persona puede seguir, con etiquetas que una persona puede leer y botones que una persona puede encontrar.

Cada una de esas pantallas codifica una suposición sobre quién está al otro lado. La suposición es una persona con una memoria de trabajo limitada, por lo que el formulario se divide en pestañas. Una persona que lee de izquierda a derecha, por lo que el campo importante va en la parte superior izquierda. Una persona que puede retener aproximadamente siete cosas en mente, por lo que el panel de control tiene seis mosaicos. Una persona que cometerá errores de escritura, por lo que hay validación al enviar. Una persona que se cansa, por lo que el camino común tiene menos clics. Todo esto es un buen diseño para el usuario que tenía el diseñador, y durante cuatro décadas ese usuario fue el único que existió.

La consecuencia es que la interfaz es una representación con pérdida del modelo de datos para un tipo de lector. El modelo sabe que una factura tiene líneas, un cliente, una fecha de vencimiento y un estado; la pantalla muestra las líneas en una pestaña, el cliente en otra y el estado como un color. El trabajo que toca cinco registros significa cinco pantallas, y la persona lleva el hilo entre ellas en su cabeza. Ese hilo es la mayor parte de lo que una empresa paga a su personal administrativo para sostener.

El nuevo usuario tiene herramientas, no manos

Un agente de IA que opera un sistema empresarial no recibe nada de eso. Lo que recibe, cuando se conecta a través del Model Context Protocol, es el resultado de una solicitud para listar herramientas: para cada una, un nombre, una descripción escrita para que un modelo la lea, un esquema para sus entradas y, opcionalmente, una anotación que indique si la herramienta solo lee, si puede destruir algo y si llamarla dos veces es seguro. El agente elige una herramienta, la llama con argumentos escritos, lee el resultado y elige de nuevo. El resumen del protocolo es que es una forma estandarizada de conectar aplicaciones de IA a sistemas externos, de la misma manera que un puerto común conecta dispositivos, y los principales clientes ahora lo hablan: Claude, ChatGPT, Cursor y VS Code entre ellos.

Mira lo que este usuario no necesita. No necesita que la factura esté dividida en pestañas, porque puede sostener todo el registro a la vez. No necesita que el campo importante esté en la parte superior izquierda, porque no hay izquierda. No necesita seis mosaicos, porque puede pedir el número que quiere. No se cansa, y no hay clics. Cada concesión que hizo que la pantalla fuera buena para una persona es, para este usuario, irrelevante o un obstáculo.

Y mira lo que necesita en su lugar, que la pantalla nunca proporcionó. Necesita que la descripción de cada acción sea precisa, porque la descripción es la totalidad de su comprensión. Necesita que el esquema esté completo, porque no puede ver un ejemplo. Necesita saber qué acciones son seguras para reintentar. Necesita que el resultado diga qué sucedió y qué puede hacer a continuación. Para este usuario, la documentación es la interfaz, y nombrar es diseño: una herramienta amplia con una descripción de dos líneas es un producto peor que la misma capacidad como tres herramientas con nombres claros y descripciones honestas, sin importar cómo se vean las pantallas sobre ellas.

El desvío a través de la pantalla no durará

La primera respuesta a un nuevo usuario siempre es vestirlo como el anterior. La automatización de procesos robóticos hizo esto durante una década: un bot inicia sesión con una cuenta de servicio y controla las pantallas como si tuviera manos, encontrando el botón por su selector o sus coordenadas. La versión actual le da a un modelo de lenguaje una captura de pantalla y un cursor. El uso de la computadora de Anthropic hace exactamente eso, y su documentación es cuidadosa al decir dónde pertenece: existe para los casos donde no hay una interfaz más ajustada disponible, te dirige a una herramienta de navegador cuando el trabajo permanece dentro de una página, y pide a una persona que confirme cualquier cosa con consecuencias reales significativas, incluidas las transacciones financieras.

El disfraz es caro de llevar. Una pantalla no le hace promesas a una máquina, así que cada cambio realizado para la persona rompe la automatización que finge ser una. Cada capa entre el agente y la acción, la captura de pantalla, la suposición de cuál píxel es el botón, el texto escrito que puede o no haber caído en el campo correcto, es un lugar para equivocarse, y un modelo ya es un lugar para equivocarse. La conducción por pantalla es el puente que construyes mientras el sistema subyacente no tiene nada mejor, y los proveedores de los bots lo dicen ellos mismos: ahora describen al robot como una capa de ejecución que un agente invoca para los sistemas que aún la necesitan.

Lo que el software tiene que convertirse

Si el argumento hasta ahora es válido, la forma del software nativo de agente se deriva de ello, y es más que una API adicional. Cinco propiedades deben ser verdaderas al mismo tiempo.

  • Cada acción es una herramienta. No la docena que el proveedor pensaba que era segura, sino toda la superficie que una persona puede alcanzar a través de las pantallas: crear, leer, mover, aprobar, enviar, conciliar. Cualquier cosa menos, y el agente tiene que recurrir a la pantalla por el resto.
  • Cada llamada lleva una identidad. El agente actúa como una persona específica, a través de un inicio de sesión normal, y las herramientas que se le ofrecen son filtradas por el rol de esa persona antes de que las vea y se revisan nuevamente cuando se ejecutan. Un agente con acceso total al sistema es un fallo de diseño, no una característica.
  • Pregunta por diseño. Algunas acciones se ejecutan; algunas esperan por una persona; algunas son rechazadas de plano. El protocolo mismo establece que siempre debe haber un humano en el proceso capaz de negar una llamada a la herramienta, y los principales clientes preguntan antes de una escritura por defecto. El software debe hacer las categorías explícitas en lugar de esperar que el modelo sea cortés.
  • El gasto tiene un límite. Donde el razonamiento del sistema cuesta dinero, o donde una herramienta compromete dinero, hay un límite por conexión que el sistema impone y el modelo no puede eludir.
  • El registro es el producto. Cada llamada, sus entradas y su resultado, bajo la identidad que la realizó, es revisable de la misma manera que las acciones de una persona. Para un agente, la auditoría es cómo se construye la confianza, una semana a la vez.

Una sexta propiedad es menos un requisito que una consecuencia. Cuando el trabajo se realiza a través de herramientas, el registro se mantiene como un subproducto: el agente que factura, persigue y concilia deja exactamente la factura, el seguimiento y la conciliación que una persona habría escrito, sin la escritura. Las pantallas sobreviven, para mirar, revisar y decidir. Dejan de ser el único lugar donde puede ocurrir el trabajo.

La objeción que vale la pena tomar en serio

La objeción más fuerte concede que los agentes pueden hacer el trabajo y señala que a veces lo hacen mal, con confianza, en una escritura. Esto es cierto, y la documentación honesta lo dice: ChatGPT trata cualquier herramienta sin una anotación de solo lectura como una escritura y requiere confirmación por defecto; Claude pide aprobación antes de invocar una herramienta de un conector personalizado y advierte que un servidor malicioso puede llevar instrucciones ocultas. Los clientes tienen razón al ser cautelosos, y un negocio también debería serlo.

Pero observa dónde debe residir la cautela. No puede residir en el modelo, que es la parte que podría estar equivocada. Debe residir en el software, que es exactamente donde el buen software ya lo colocó para los usuarios humanos. Validación, permisos, umbrales de aprobación, deshacer, auditoría: cada uno de esos existe porque el usuario anterior también cometió errores, con confianza, en una escritura. El software nativo de agentes toma esa antigua disciplina en serio en cada acción en lugar de en las pocas que el diseñador de la pantalla recordó, y la aplica a un usuario que llamará a cien herramientas antes del almuerzo.

Una segunda objeción es el determinismo. Algunos trabajos deben producir la misma salida para la misma entrada, de manera comprobable, cada vez. Ese trabajo debe permanecer como un flujo de trabajo fijo, y el agente debe llamar al flujo de trabajo como una herramienta en lugar de improvisarlo. El juicio no reemplaza las reglas aquí; el sistema necesita ambos, expuestos a un usuario que pueda diferenciarlos.

Quién lo construye, y para quién

La última consecuencia es la que el emprendedor debería notar. Si el usuario del software puede ser un agente, el constructor también puede serlo. Un desarrollador describe la aplicación que quiere a un agente que ya tiene, el agente la construye utilizando un conjunto de herramientas de construcción, el desarrollador la valida localmente y la publica, y desde el primer día cada herramienta que la aplicación envía está disponible para cada otro agente en la plataforma. El negocio que la instala no aprende sus pantallas; su personal trae el agente que ya usa y describe el resultado. Esa es la disposición en la que se basa Sois, ofrecida aquí como una implementación del argumento en lugar de como su conclusión.

La conclusión es más simple. Durante cuarenta años, la pregunta que un diseñador de software hizo fue qué necesita ver la persona al otro lado. El siguiente usuario no ve. Lee un contrato y llama a lo que se le permite llamar, y lo hará en nombre de las mismas personas para las que se construyeron las pantallas. El software que trata a ese usuario como un ciudadano de primera clase será operado con fluidez. El software que mantiene la pantalla como su única puerta seguirá siendo operado, a través de una mirilla, por un agente que lleva un disfraz, hasta que sus propietarios se cansen del disfraz y se muevan.

Fuentes
  1. Protocolo de Contexto del Modelo: introducción qué es el protocolo, la analogía del puerto y los clientes que lo apoyan.
  2. Especificación del Protocolo de Contexto del Modelo: seguridad y confianza consentimiento y control del usuario, seguridad de las herramientas y el principio de humano en el ciclo
  3. Anthropic: herramienta de uso de computadora control de pantalla para Claude, donde corresponde, y la guía para confirmar acciones consecuentes
  4. Sois: ¿qué es Sois? la plataforma descrita en la última sección, como una implementación

Este artículo se revisa cuando cambian los productos que describe. Próxima revisión programada: 4 de diciembre de 2026.