← Todos los artículos

Los agentes de IA no matarán tu sistema de registro. Tus límites de uso sí.

En esta página

Zain Hoda, cofundador de Vanna AI, escribió hace poco un hilo con mucho filo en el que sostiene que los agentes de IA van a vaciar los sistemas de registro.1 Su tesis: en cuanto un agente pueda clonar todo tu CRM en segundos, el foso de los datos se evapora. El sistema de registro pasa a ser un simple punto de escritura y el agente se convierte en la interfaz de verdad.

Tiene razón con el problema. Creo que se equivoca con el desenlace.

Los sistemas de registro no se van a hundir. Pero los que peleen contra este cambio serán sustituidos, sin duda, por los que no lo hagan.

El paralelismo con la ciberseguridad que nadie hace

En ciberseguridad hay un principio fundacional: autoriza lo más cerca posible del recurso. No pongas toda la confianza en el perímetro y reces. Baja el control de acceso hasta donde viven los datos.

Los sistemas de registro ya hacen esto, y llevan décadas haciéndolo. Combinan dos cosas que son realmente difíciles de separar: los datos de la empresa y las reglas de acceso que dicen quién puede verlos y cambiarlos. ¿Quién puede ver este registro de cliente? ¿Quién puede aprobar este gasto? ¿Quién cambió este campo y cuándo?

No son funciones accesorias. Son la razón entera por la que los sectores regulados no pueden volcarlo todo en la ventana de contexto de un agente y dar el asunto por zanjado.2

Hoda lo reconoce de pasada (gobernanza, permisos, sincronización multiusuario), pero lo despacha como “un negocio mucho más pequeño”. Creo que eso lo infravalora una barbaridad.

Los límites de uso son la batalla equivocada

Donde estoy muy de acuerdo: los sistemas de registro que responden a la IA cerrando el acceso a su API juegan una partida perdida. Una partida absurda, incluso.

Los límites de uso no protegen tu foso. Solo empeoran tu producto. Un agente con motivación suficiente cacheará en local, sincronizará cada cierto tiempo y te esquivará por completo. Enhorabuena: acabas de enseñar a tus clientes a tratarte como una dependencia poco fiable en vez de como el centro de su flujo de trabajo.

Es el equivalente en software empresarial a la industria discográfica demandando a Napster. No te equivocas con la propiedad. Te equivocas de forma catastrófica con la estrategia.

MCP es la adaptación que importa

Aquí es donde se pone interesante.

El Model Context Protocol es un estándar abierto que permite a los agentes de IA hablar con el software empresarial de forma estructurada.3 No es una capa de integración más. Es una forma de que los sistemas de registro sigan siendo competitivos precisamente porque les deja mantener el control donde importa.

Un servidor MCP se coloca delante de tus datos y los expone a los agentes de IA de forma estructurada y gobernada. Piensa en el mostrador de conserjería de un hotel. El agente no recibe la llave maestra de todas las habitaciones. Hace una petición, el conserje comprueba si está permitida y entrega solo lo que corresponde. Cada interacción está acotada, autenticada y registrada.

Es el principio de “autorizar en el recurso”, aplicado a la IA. En vez de pelear contra el acceso de los agentes, lo canalizas por una capa que controlas.

El sistema de registro que adopta MCP dice: “Sí, los agentes pueden interactuar con nuestros datos. Este es el protocolo. Estos son los permisos. Esta es la pista de auditoría.” El que lo combate dice: “No, no puedes pasar de diez llamadas a la API por minuto.” ¿Sobre cuál prefieres construir?

Por supuesto, MCP no es magia. Si publicas un endpoint MCP sin autenticación ni control de acceso, acabas de dejar la puerta abierta a todos los agentes de internet.4 El incidente de Clawdbot en enero lo demostró: más de mil despliegues expuestos, casi todos con la configuración por defecto y sin autenticación. El mostrador de conserjería solo funciona si alguien comprueba las credenciales de verdad.

Tratar los cambios como transferencias bancarias

Hay otro ángulo que recibe poca atención: la reversibilidad.

Los agentes de IA cometerán errores. Actualizarán el registro equivocado, fusionarán duplicados que no debían fusionarse, crearán entradas a partir de un contexto alucinado. No es una hipótesis. Es el coste inevitable de la acción autónoma a escala.

Los sistemas de registro están en una posición única para manejarlo, pero solo si tratan cada cambio iniciado por una IA como una transferencia bancaria. Cuando tu banco procesa un pago, no se limita a restar de una cuenta y sumar a otra. Crea un registro de la transferencia: qué cambió, cuándo, quién y cuáles eran los saldos antes y después. Si algo sale mal, el banco puede revertir la transferencia limpiamente sin descuadrar todo lo demás.

Cada cambio que haga un agente de IA debería funcionar igual. Discreto, registrado, con un estado anterior y posterior claros. Si el agente actualiza mal un registro de cliente, deberías poder deshacerlo sin preocuparte de qué más se rompe aguas abajo.

Haz fácil el rollback. Haz visible el radio de la explosión. Dale a las personas un deshacer de un clic que no se convierta en caos en cascada.

Aquí es donde el argumento de que “la gobernanza es solo una función” se desmorona del todo. Construir este seguimiento de cambios y esta reversión segura dentro de una plataforma de datos no es un añadido de última hora. Es ingeniería difícil de verdad, en el corazón del sistema. Y es justo lo que una caché de agente independiente no puede hacer bien, porque no es dueña del estado canónico.

La división real

Lo que está pasando de verdad no es que “los sistemas de registro colapsen”. Es una bifurcación.

Los sistemas de registro que se adapten expondrán interfaces MCP ricas, mantendrán un control de acceso con autoridad, ofrecerán auditoría a nivel de cambio y harán de la IA un ciudadano de primera de su plataforma.5 Valdrán más, no menos, porque serán la capa de confianza en un stack cada vez más autónomo.

Los sistemas de registro que no se adapten limitarán, restringirán y litigarán hasta la irrelevancia. Sus clientes migrarán a plataformas que trabajan con el paradigma de los agentes y no contra él.

El foso nunca fue “guardamos tus datos”. Fue “somos el sistema al que confías tus datos”. La confianza exige gobernanza, auditabilidad y control. Eso no va a desaparecer. Va a importar mucho más.

TL;DR

Los sistemas de registro no se están muriendo. Pero los que traten el acceso de la IA como una amenaza y no como una restricción de diseño perderán frente a los que no. MCP les da a estas plataformas una forma de seguir siendo la autoridad mientras se abren a los agentes. Ganarán las plataformas que hagan la interacción con la IA rastreable, reversible y auditable por defecto.

Perderán las que sigan discutiendo por los límites de uso.


Footnotes

  1. Zain Hoda (co-founder, Vanna AI), “The Agent Will Eat Your System of Record” (X/Twitter, 2025). Link ↩

  2. Cerbos, “MCP Permissions: Securing AI Agent Access to Tools” (September 2025). Tratamiento detallado de cómo imponer el control de acceso mediante servidores MCP. Link ↩

  3. Anthropic, “Model Context Protocol” (November 2024). El protocolo se donó a la Agentic AI Foundation, dentro de la Linux Foundation, en diciembre de 2025. Wikipedia ↩

  4. PointGuard AI, “Clawdbot MCP Vulnerability Exposes AI Agents” (January 2026). Más de mil despliegues MCP expuestos y sin autenticación, un ejemplo real de lo que pasa cuando el mostrador de conserjería no tiene a nadie detrás. Link ↩

  5. Microsoft, “Dynamics 365 ERP Model Context Protocol” (November 2025). El planteamiento de Microsoft del paso “de sistemas de registro a sistemas de acción”. Link ↩