Abogados ante la inteligencia artificial: los agentes ya llaman a tu despacho, y Nearius les abre la puerta con tu cuenta

Hasta ahora el cliente llamaba al despacho. Lo que viene es distinto: las empresas están poniendo agentes de inteligencia artificial a comprar, vender y gestionar proveedores, y cuando uno de esos agentes tropieza con una cláusula que no entiende, no espera a la mañana siguiente: pregunta al despacho en ese momento, desde su propio flujo de trabajo, y espera una respuesta inmediata. «¿Puedo firmar esto?», «¿puedo compartir esto?», «¿puedo aprobar esto?». Quien no tenga una forma de contestar a esa velocidad, con criterio propio y con fuentes, verá cómo la consulta se va a otro sitio.

Responder exige dos cosas. La primera es del despacho: un agente propio, con sus criterios, sus límites y la decisión de qué consultas se contestan solas y cuáles pasan a un abogado. La segunda es de infraestructura: ese agente tiene que apoyarse en jurisprudencia, normas y datos registrales verificados, y tiene que poder conectarse a esas fuentes sin que un humano intervenga en cada conexión. De la segunda va este artículo. Nearius es un servidor MCP, el protocolo que hablan los asistentes y los agentes, y desde hoy admite el mecanismo de identificación de clientes que la especificación ha hecho preferente, los Client ID Metadata Documents, amplía la lista de plataformas que pueden conectarse y recuerda la vía para agentes sin navegador, la API key.

Conviene dejarlo claro desde el principio: lo que cambia es cómo se identifica el programa (el asistente, el agente o la cartera de identidad), no cómo entra el usuario. El usuario sigue entrando con su cuenta de Nearius y el agente recibe exactamente los permisos de esa cuenta y de su plan, gratuito o Pro. Sin cuenta no hay acceso por ninguna vía.

Lo que viene: el vídeo

Para ver hacia dónde va todo esto, recomendamos la conversación «Abogados ante la Inteligencia Artificial» (YouTube, 30 de octubre de 2026). Describe un escenario que ya existe: las empresas usan agentes para comprar, vender y gestionar proveedores, y cuando uno de esos agentes se encuentra una duda jurídica —una cláusula de datos en un contrato, de madrugada— se la manda directamente al despacho sin salir de su flujo de trabajo. Las tres preguntas que llegan una y otra vez son «¿puedo firmar esto?», «¿puedo compartir esto?» y «¿puedo aprobar esto?».

La respuesta que plantea el vídeo es que el despacho tenga su propio agente, configurado con sus criterios, sus límites y sus fuentes, que conteste al instante las consultas estandarizadas y derive a un abogado las que se salen del perímetro; la responsabilidad del consejo sigue siendo del despacho. Eso empuja a empaquetar el conocimiento jurídico en productos con alcance e inputs definidos y precio cerrado por volumen, a escribir el criterio del despacho para sus diez o quince preguntas más repetidas, y a pensar el papel del abogado como supervisor de agentes que actúan solos y pueden saltarse normas. También reclama perímetro normativo claro, registros de auditoría y conectores y skills que acerquen la tecnología a juristas sin perfil técnico.

El resto de este artículo es la parte técnica de ese escenario: cómo se conecta un agente a Nearius, qué plataformas pueden hacerlo, qué puede hacer una vez dentro y qué no cambia en seguridad ni en el plan.

Qué cambia para quien se conecta

Si usas Nearius desde Claude, ChatGPT, Perplexity, Cursor o Grok, nada: tu conexión sigue igual y no tienes que hacer nada. El cambio importa a quien quiere usar Nearius desde un agente propio, desde una plataforma de agentes o desde una cartera de identidad de agentes, que hasta ahora recibían un rechazo al intentar entrar.

Cómo se presenta un cliente ante Nearius

Antes de que un usuario pueda autorizar a un asistente, el asistente tiene que decirle a Nearius quién es: un nombre, y la dirección a la que Nearius devolverá al usuario una vez autorizado. Hay dos formas de hacerlo.

La primera es el registro dinámico: el cliente envía sus datos a Nearius, Nearius los guarda y le asigna un identificador. Es lo que hacen hoy la mayoría de asistentes de escritorio y sigue funcionando exactamente igual.

La segunda es el Client ID Metadata Document: el cliente no se registra en ningún sitio. Publica en su propio dominio un pequeño documento con sus datos y usa la dirección de ese documento como identificador. Cuando pide autorización, Nearius descarga el documento, comprueba que dice ser quien dice ser y que la dirección de retorno es una de las que el documento declara, y solo entonces muestra la pantalla de autorización. Es un borrador del grupo de trabajo OAuth del IETF que la especificación MCP ha hecho suyo: quien controla el dominio controla la identidad del cliente, y ningún servidor tiene que mantener una base de registros para miles de agentes que nunca ha visto.

Por qué importa a los agentes

Un asistente de escritorio se registra una vez y listo. Un agente que corre en un servidor, sin persona delante, y que se conecta a decenas de servicios distintos no puede ir registrándose uno por uno. Las plataformas de agentes y las carteras de identidad, que guardan por cuenta del usuario las conexiones que ha autorizado, se presentan por esta segunda vía. Hasta hoy, ese intento chocaba en Nearius y el agente se quedaba fuera. Ya no.

De dónde viene el cambio

El mecanismo no es una ocurrencia de Nearius. El Client ID Metadata Document es un borrador del grupo de trabajo OAuth del IETF, y la especificación MCP lo incorporó en su revisión del 25 de noviembre de 2025 (propuesta SEP-991) como vía recomendada de registro: los clientes y los servidores de autorización deberían soportarlo, y el registro dinámico pasó a ser opcional, mantenido por compatibilidad. La revisión del 28 de julio de 2026 fue más lejos: fija el orden de preferencia (cliente preregistrado, después CIMD, y solo en último lugar registro dinámico), anuncia la retirada futura del registro dinámico, obliga al servidor de autorización a devolver su identificador de emisor para que el cliente lo valide antes de canjear el código, y formaliza la autorización por pasos cuando una herramienta exige un permiso que el cliente aún no tiene. Nearius sigue admitiendo las dos vías, de modo que un cliente antiguo no se queda fuera.

Quién ya entra así en Nearius

Los grandes asistentes ya se presentan por esta vía: en las últimas semanas, la mayor parte de las autorizaciones que recibe Nearius llegan con un identificador en forma de URL desde Claude, ChatGPT (incluido Codex) y Perplexity, y también desde el directorio Smithery. Esas plataformas estaban en la lista de destinos admitidos y por eso nunca se notó el cambio. Lo que faltaba era abrir la puerta a las plataformas de agentes y a las carteras de identidad, que se presentan igual pero desde dominios que la lista no conocía.

Aplicaciones: qué puede hacer un agente conectado a Nearius

Un asistente de chat responde cuando se le pregunta. Un agente trabaja sin que nadie le pregunte, dentro de un flujo que alguien ha definido una vez. Con Nearius como herramienta, algunos de esos flujos se vuelven inmediatos:

• Vigilancia de jurisprudencia. Un agente que cada mañana busca resoluciones nuevas sobre las materias de cada asunto abierto del despacho, comprueba que lo que cita sigue vigente y deja un resumen con el ECLI y el enlace oficial en la carpeta del expediente o en el documento de trabajo del equipo.
• Revisión de escritos antes de presentar. El agente toma el borrador, verifica cada artículo citado contra la fuente oficial y cada resolución contra su texto, y devuelve la lista de citas que no cuadran o que han cambiado de redacción, para que el letrado decida.
• Comprobación previa de una contraparte o de un cliente. Con los datos mercantiles del BORME, las sociedades vinculadas, los concursos y el historial de cargos, el agente prepara la ficha antes de la primera reunión y la actualiza cuando hay un cambio.
• Operaciones inmobiliarias. Desde una referencia catastral o una nota simple, el agente reúne la información catastral, el régimen urbanístico aplicable, el planeamiento y el riesgo de inundabilidad de la finca y los deja ordenados en el informe de la operación.
• Plazos y calendario. El agente calcula plazos procesales y vencimientos fiscales a partir de las fechas de cada asunto y los anota en la agenda del equipo, con el periodo y el modelo a los que corresponde cada uno.
• Agentes en las herramientas de trabajo del despacho. Las plataformas de documentos y tablas que permiten definir agentes propios pueden usar Nearius desde dentro de la tabla de asuntos: una columna con la materia, otra con la última resolución relevante, otra con el estado de la norma.

En todos los casos el agente actúa con la cuenta de un usuario de Nearius y dentro de su plan, y cada respuesta llega con su ECLI, su referencia o su enlace a la fuente oficial, para que lo que entra en un expediente se pueda comprobar.

Qué ventajas tiene

• Usas la plataforma que ya usas. Nearius no te pide cambiar de asistente ni instalar nada: se conecta al cliente que tengas, sea un asistente de escritorio, una plataforma de agentes o una cartera de identidad, con el mismo protocolo que todos ellos hablan.
• Sin registro previo para el programa. El cliente se identifica con su documento publicado y el usuario autoriza en el momento. Nadie tiene que dar de alta el cliente a mano ni esperar a que lo aprueben.
• Control del usuario en cada paso. La pantalla de autorización muestra el nombre del cliente que pide acceso; el token lleva solo los permisos de la cuenta y del plan; la conexión se revoca desde el panel cuando se quiera.
• Una identidad por dominio, no un registro por servidor. Para quien desarrolla un cliente, la misma identidad sirve ante cualquier servidor MCP que admita el mecanismo. Y para un servidor como Nearius, no hay base de registros que mantener ni caducidades que gestionar.
• Compatibilidad hacia atrás. El registro dinámico sigue funcionando, y la API key cubre a los agentes sin navegador. Ningún cliente que funcionara ayer deja de funcionar hoy.
• Alineado con la especificación. Es la vía que MCP recomienda desde noviembre de 2025 y la que fija como preferente desde julio de 2026, así que los clientes nuevos van a llegar por aquí.

Plataformas admitidas

Nearius no acepta cualquier dirección de retorno: solo las de plataformas que conoce, para que una autorización nunca acabe en un destino que el usuario no esperaba. La lista queda así:

• Asistentes: Claude (web, escritorio y Claude Code), ChatGPT, Perplexity, Grok y Cursor.
• Directorios y plataformas de agentes: Smithery y Coda.
• Carteras de identidad de agentes: Didit Wallet.
• Cualquier aplicación que corra en tu propio ordenador y reciba la autorización en localhost, como Claude Code o Codex.

Si desarrollas un cliente MCP o usas una plataforma que no está en la lista, escribe a [email protected] con el dominio desde el que se conecta. Añadirlo es cuestión de horas; lo que no vamos a hacer es abrir la lista a cualquiera, por la razón de la sección siguiente.

Lo que no cambia: la seguridad de la autorización

Admitir identificadores que son direcciones web obliga a descargar un documento de un dominio ajeno, y eso se hace con cuidado. Nearius solo descarga el documento si tanto el identificador como la dirección de retorno pertenecen a una plataforma admitida; comprueba que el documento declara exactamente el identificador con el que se presentó; exige que la dirección de retorno esté en la lista que el documento publica; no sigue redirecciones y limita el tamaño y el tiempo de descarga. Cada intento, aceptado o rechazado, queda anotado en el registro de auditoría de la autorización, el mismo que vigila el equipo cada hora.

Tampoco cambia lo demás: el usuario ve en la pantalla de autorización el nombre del cliente que pide acceso, los permisos son los de su cuenta y su plan, y puede revocar la conexión cuando quiera.

Para quien desarrolla un cliente

El documento de metadatos del servidor de autorización de Nearius anuncia client_id_metadata_document_supported: true junto al endpoint de registro dinámico, de modo que un cliente que siga la especificación elegirá por sí solo la vía adecuada. El documento de cliente debe estar en una URL https con ruta, declarar client_id, client_name y redirect_uris, y el client_id tiene que coincidir con la URL exacta del documento. El flujo de autorización es el de siempre: código de autorización con PKCE.

Un registro dinámico sin direcciones de retorno sigue rechazándose: un agente que no puede recibir la autorización en ningún sitio no tiene forma de completar el flujo OAuth.

Si tu agente no tiene navegador: la API key

Hay un caso que ni el registro dinámico ni el Client ID Metadata Document resuelven: el agente que corre en un servidor, sin nadie delante que pueda pulsar «autorizar». Para ese caso Nearius no necesita OAuth. Desde tu panel puedes generar una API key y enviarla en cada petición como cabecera Authorization: Bearer …; la conexión lleva los permisos de tu cuenta y de tu plan, y la clave se puede regenerar o revocar desde el mismo panel. Las instrucciones están en la página Conectar, en el apartado de API key.

Esta vía funciona en cualquier plataforma que permita añadir cabeceras a la configuración de un servidor MCP remoto. Zapier MCP y la API de OpenAI (Agents y Responses) lo documentan expresamente; en otras plataformas de agentes depende de que su configuración de servidores MCP admita cabeceras o un token estático, así que conviene mirar su documentación antes de descartar la conexión. Si tu plataforma solo sabe hacer OAuth interactivo y no está en la lista de destinos admitidos, escríbenos.

Cómo empezar

En la página Conectar está la dirección del servidor y las instrucciones para cada asistente. Si tu plataforma se presenta por Client ID Metadata Document, basta con darle la dirección de Nearius: el resto lo negocian entre ellas.

Fuentes

• OAuth Client ID Metadata Document, borrador del grupo de trabajo OAuth del IETF.
• Especificación MCP 2025-11-25, cambios y nota de la revisión.
• Especificación MCP 2026-07-28, registro de clientes y nota de la revisión.
• Aaron Parecki, Client Registration and Enterprise Management in the MCP authorization spec, 25/11/2025.
• Zapier MCP: conexión con cabecera Authorization Bearer, documentación de Zapier.

Preguntas frecuentes

¿Qué es un Client ID Metadata Document?

Un documento JSON que un cliente OAuth publica en su propio dominio con su nombre y sus direcciones de retorno, y cuya URL se usa como identificador del cliente. El servidor lo descarga cuando el cliente pide autorización, en lugar de guardar un registro previo. Es un borrador del grupo de trabajo OAuth del IETF y la vía de registro preferente en la especificación MCP.

¿Tengo que hacer algo si ya uso Nearius desde Claude, ChatGPT o Perplexity?

No. Esas conexiones usan el registro dinámico y siguen funcionando igual. El cambio afecta a agentes y plataformas que se presentan con un identificador en forma de URL, que hasta ahora eran rechazados.

¿Puedo conectar un agente propio alojado en un servidor?

Sí. Si la plataforma recibe la autorización del usuario en una dirección admitida o en localhost, por OAuth; si el agente no tiene navegador, con la API key de tu panel enviada como cabecera Authorization: Bearer.

¿Por qué Nearius no acepta cualquier dominio?

Porque la dirección de retorno es donde acaba el usuario con su autorización concedida. Limitarla a plataformas conocidas evita que una autorización termine en un destino que el usuario no esperaba, y evita que el servidor descargue documentos de dominios arbitrarios. Añadir una plataforma nueva es cuestión de horas: basta con pedirlo.

¿Puedo usar Nearius desde un agente que corre en un servidor, sin navegador?

Sí, con una API key generada en tu panel de Nearius, enviada como cabecera Authorization: Bearer en cada petición. No necesita OAuth ni direcciones de retorno. Funciona en cualquier plataforma cuya configuración de servidores MCP admita cabeceras, como Zapier MCP o la API de OpenAI; en otras, comprueba antes su documentación.

¿Puede alguien usar Nearius sin cuenta por esta vía?

No. El Client ID Metadata Document identifica al programa que pide acceso, no al usuario. Tras identificarse el programa, Nearius muestra su pantalla de entrada y el usuario tiene que autorizar con su cuenta de Nearius; el token que recibe el agente lleva los permisos y el plan de esa cuenta. Sin cuenta no se emite ningún token.

¿Qué diferencia hay entre conectar Nearius a un asistente y a un agente?

El asistente responde cuando le preguntas; el agente ejecuta un flujo definido de antemano, sin que nadie le pregunte cada vez: vigilar jurisprudencia nueva, revisar las citas de un escrito, preparar la ficha mercantil de una contraparte. Para Nearius son el mismo tipo de cliente: ambos se autorizan con la cuenta de un usuario y usan las mismas herramientas.

¿Un agente puede hacer en Nearius más cosas que yo desde el chat?

No. Usa las mismas herramientas y con los mismos límites del plan de la cuenta que lo autorizó. Lo que cambia es que trabaja sin intervención y puede encadenar pasos: buscar, verificar y dejar el resultado donde el equipo lo necesita.

¿Cómo sé qué agentes tienen acceso a mi cuenta y cómo se lo quito?

En el panel Mis búsquedas de Nearius (plan Pro) ves cada conexión autorizada con el nombre de la aplicación, desde dónde se autorizó y cuándo se usó por última vez, y puedes revocar una sin tocar las demás: el token deja de valer en la siguiente petición. Si usas una API key, regenerarla desde el panel invalida la anterior.

¿Es seguro que un servidor descargue un documento de un dominio ajeno?

Nearius solo lo hace para dominios admitidos, comprueba que el documento declara el mismo identificador con el que se presentó el cliente, exige que la dirección de retorno esté en la lista publicada, no sigue redirecciones y limita el tamaño y el tiempo de descarga. Cada intento queda en el registro de auditoría de la autorización.

¿Las respuestas de un agente vienen con fuentes?

Sí, igual que en el chat: cada resolución con su ECLI y su enlace oficial, cada artículo con su referencia en la fuente consolidada, cada dato mercantil o catastral con su origen. Es lo que permite comprobar lo que el agente deja en un expediente.

¿Puede el agente de mi despacho responder al agente de un cliente usando Nearius?

Sí. El agente del despacho se conecta a Nearius con la cuenta del despacho (por OAuth o con API key) y usa sus herramientas para fundamentar la respuesta: la resolución con su ECLI, el artículo con su texto vigente, el dato mercantil o catastral con su origen. Los criterios, los límites y qué consultas pasan a un abogado los fija el despacho en su agente; la responsabilidad del consejo sigue siendo suya.

¿Cambia algo en los permisos o en el plan?

No. La forma de identificar al cliente no cambia lo que puede hacer: los permisos son los de la cuenta y el plan del usuario que autoriza, en la cuenta gratuita y en el plan Pro, y la conexión se puede revocar en cualquier momento.