¿Puede un agente de IA poseer un dominio? WHOIS, custodia y tokens

La pregunta «¿puede mi agente de IA poseer un dominio?» aparece constantemente cuando un agente de IA registra, renueva y administra dominios en nombre de otra persona; consulta Cómo compran dominios los agentes de IA sin intervención humana para entender lo habitual que se ha vuelto en 2026. La respuesta breve aparece al principio; el resto de esta página explica el porqué mediante las preguntas concretas que la gente realmente plantea, cada una respondible por sí sola.

¿Puede un agente de IA ser propietario legal de un dominio?

No en su propio nombre. El Acuerdo de Acreditación de Registradores de 2013 de ICANN —el contrato que suscriben y bajo el que operan todos los registradores acreditados por ICANN— establece directamente que «el titular de un nombre registrado con quien el registrador celebra un acuerdo de registro debe ser una persona o entidad jurídica distinta del registrador». Un registrante debe ser una persona física o una entidad jurídica registrada: un particular, una empresa, una organización sin fines de lucro o un organismo gubernamental. Un agente de IA, como software, no es ninguna de esas cosas. Por ello, el propio agente no puede figurar nunca como titular del registro.

Lo que la regla no excluye es la delegación. Nada en el RAA impide que una persona u organización autorice a un agente a buscar, registrar, renovar o administrar DNS en su nombre, igual que hoy puede autorizar a un empleado o a una automatización. El registrante sigue siendo una persona o entidad jurídica; el trabajo de gestionar el dominio puede delegarse a un agente. Esa distinción —quién aparece en el registro frente a quién hace clic (o llama a la API)— es el tema central de esta página.

¿Quién es el registrante cuando un agente de IA registra un dominio?

Quien tenga la cuenta, haya financiado la compra y haya aceptado los términos del registrador; nunca el agente. Cuando un agente llama a la API de un registrador para registrar un nombre, actúa como herramienta bajo la autorización de alguien, con la misma forma jurídica que una persona que usa un formulario web, solo que automatizada. La propia guía de ICANN para registrantes deja claro dónde recae esa responsabilidad: «asumirá la responsabilidad exclusiva del registro y uso de su nombre de dominio», según la página de Beneficios y responsabilidades de los registrantes de ICANN. Esa responsabilidad corresponde al titular de la cuenta que puso al agente en funcionamiento, no al software que ejecutó la llamada.

Por eso todo flujo de registro mediante agentes que sea creíble —incluido el de Namefi— se apoya en una credencial controlada por una persona o entidad: una clave de API vinculada a una cuenta con fondos o una billetera cuya clave privada controla alguien. Consulta Cómo registrar un dominio con tu agente de IA en Namefi para ver cómo funciona en la práctica ese paso de credenciales.

¿Qué muestra realmente el registro WHOIS o RDAP de un dominio registrado por un agente?

Los mismos campos que mostraría para cualquier registro: el registrador inscrito, las fechas de registro y vencimiento y, salvo que estén ocultos por la privacidad de WHOIS, que la mayoría de los registradores aplica hoy de forma predeterminada, el nombre, la organización y los datos de contacto del registrante. No existe un campo para «registrado por un agente de IA», ni ninguna política de ICANN que lo defina. La herramienta de consulta de ICANN basada en RDAP es el lugar autorizado para comprobar el registro actual de un dominio concreto, y devuelve el mismo esquema tanto si una persona escribió el formulario de registro como si un agente llamó a una API para enviar los mismos datos.

En la práctica, esto significa que un observador externo —un titular de marca, un investigador de seguridad o un posible comprador— no puede saber solo mediante WHOIS/RDAP que un dominio fue registrado por un agente. El registro identifica al registrante legal. Lo que produjo la llamada a la API que lo creó no forma parte del modelo de datos.

¿Cuál es la diferencia entre que un agente opere un dominio y que un agente lo posea?

Operar significa que el agente puede actuar sobre el dominio —renovarlo, editar registros DNS o iniciar una transferencia— porque posee una credencial con el alcance necesario. Poseer, en el único sentido que tiene peso jurídico, significa ser el registrante inscrito conforme a la definición del RAA anterior: una persona o entidad jurídica responsable ante el registrador y ante las políticas de ICANN. Un agente puede operar un dominio de forma extensa —el servidor MCP de Namefi ofrece precisamente ese tipo de herramientas— sin llegar a ser su propietario, del mismo modo que un administrador de inmuebles puede tener llaves y hacer llamadas de mantenimiento sin tener el título de propiedad del edificio.

La diferencia entre esas dos funciones concentra la mayoría de las preguntas prácticas que la gente plantea; por eso las siguientes secciones la recorren como un espectro y no como una única respuesta de sí o no.

¿Cuál es el espectro de custodia de un dominio que administra un agente?

Tres niveles, cada uno con un control progresivamente más directo para el agente, mientras el registrante legal se mantiene igual:

Acceso a la cuenta del registrador. El agente —o el script que llama a la API del registrador en nombre del agente— usa credenciales vinculadas a la propia cuenta de registrador de la persona u organización. El campo de registrante nunca cambia; el agente simplemente actúa dentro de una cuenta que alguien ya posee, como en un acuerdo actual de compartir un inicio de sesión.
Clave de API. Una credencial limitada a la API del registrador, facturada contra un saldo con fondos, sin que sea necesario compartir todo el acceso al panel de la cuenta. Namefi las emite para que un agente pueda buscar, consultar precios y registrar sin tocar una sesión del navegador; se explica en Cómo registrar un dominio con tu agente de IA en Namefi. El registrante sigue siendo la persona o entidad a cuya cuenta está limitada la clave.
Dominio tokenizado en una billetera. El registro se acuña como un token on-chain y quien tenga en su billetera ese token —mediante la compra firmada con billetera x402 o una dirección receptora designada— controla directamente la vía de transferencia on-chain del dominio, sin pasar por un panel del registrador. Consulta Paga dominios con una billetera de criptomonedas: sin necesidad de cuenta para conocer cómo un dominio llega así a una billetera.

Cada nivel es más directo que el anterior, pero la cuestión del registrante legal planteada antes no cambia: se responde de la misma manera independientemente del nivel en el que opere el agente.

¿Qué cambia cuando un dominio se tokeniza?

Tokenizar un dominio acuña un NFT que funciona como una capa de control paralela y on-chain sobre un registro DNS real; se describe con más detalle en ¿Qué son los dominios tokenizados?. Namefi, un registrador acreditado por ICANN, lo hace manteniendo el registro subyacente real y reconocido por ICANN, mientras acuña el token de propiedad en la billetera que indique el comprador. La propia documentación de Namefi describe el registro de un dominio con el token resultante enviado directamente a una dirección nftReceivingWallet que controla el comprador. El dominio sigue teniendo un registro WHOIS/RDAP y un registrador inscrito; el token añade una vía para transferir el control de ese registro entre pares y on-chain, sin una solicitud de transferencia intermediada por el registrador.

Lo que la tokenización no hace es redefinir quién puede ser registrante. El estándar ERC-721 en el que se basan los dominios tokenizados no establece ninguna restricción sobre el tipo de dirección que puede tener un token: cualquier dirección de billetera puede poseer un NFT, y el estándar contempla explícitamente que los contratos también puedan tener tokens. Esa es una afirmación sobre el token, no sobre las reglas de registrante de ICANN, que se sitúan en la capa superior del registrador y siguen exigiendo que el registro subyacente pueda rastrearse hasta una persona o entidad jurídica.

¿Puede la billetera de un agente de IA conservar realmente un dominio tokenizado?

Técnicamente sí, en el sentido estricto de que una billetera no es más que un par de claves y de que nada en el estándar ERC-721 ni en una transacción de acuñación comprueba si quien controla la clave privada es una persona, un script o un proceso autónomo. Si un agente tiene autoridad de firma sobre una billetera —su propia clave o autoridad delegada sobre la de otra persona—, esa billetera puede recibir y conservar el NFT de un dominio tokenizado exactamente igual que cualquier otra.

Que ese acuerdo convierta al agente en propietario en un sentido jurídicamente relevante es una cuestión realmente abierta que no podemos resolver aquí: ninguna política de ICANN, ninguna sentencia judicial ni ninguna fuente que hayamos encontrado aborda que un agente de IA —a diferencia de la persona o entidad que controla su billetera— posea el título legal de algo. Interpreta «la billetera del agente conserva el token» como una descripción de custodia técnica, no como una conclusión legal establecida. El enfoque más prudente, y el que respaldan todas las fuentes anteriores, es este: quien controla la billetera —quien tiene o puede dirigir la clave privada— es la parte con una pretensión real, y se espera que siga siendo una persona o entidad, no el propio software.

¿Qué ocurre si el agente se comporta mal? ¿Se puede bloquear o recuperar el dominio?

Se aplican dos mecanismos de protección distintos según el nivel de custodia, y no ofrecen el mismo tipo de recurso. En el nivel del registrador, las reglas de transferencia de ICANN introducen fricción: por lo general, un dominio no puede transferirse a un nuevo registrador durante los 60 días posteriores al registro inicial, y se aplica un bloqueo de cambio de registrante de 60 días después de cambiar el nombre, la organización o la dirección de correo electrónico del registrante; ambos están documentados en las preguntas frecuentes de ICANN para registrantes. Esos plazos dan al registrante tiempo para detectar e impugnar un cambio no autorizado antes de que sea definitivo: una protección real, aunque limitada, frente a un agente que se descontrola en una cuenta de registrador estándar o con una clave de API.

Cuando un dominio se tokeniza y el NFT reside en una billetera, esa red de seguridad es diferente. Una transferencia on-chain, una vez confirmada, por lo general es definitiva: no hay un bloqueo del lado del registrador para revertir un token enviado a la dirección equivocada. Esto desplaza la defensa práctica a un momento anterior, a cuánta autoridad tiene la billetera del agente: un acuerdo de multifirma que requiera un segundo firmante, o simplemente no dar a un agente autoridad permanente sobre una billetera que guarda dominios tokenizados valiosos. Es el mismo principio de salvaguarda que se explica para los pagos en Paga dominios con una billetera de criptomonedas.

¿Tokenizar un dominio elimina la exposición a la UDRP?

No, y ninguna fuente que hayamos consultado sugiere lo contrario. Las obligaciones de la UDRP se vinculan al registro DNS subyacente reconocido por ICANN, que un dominio tokenizado sigue teniendo: la tokenización cambia quién puede mover el dominio y cómo, no si se aplican la ley de marcas o la política de resolución de disputas de ICANN. Un artículo de opinión sobre dominios controlados por agentes expresó claramente esa exposición: «si un agente registra un dominio que resulta entrar en conflicto con una marca, no hay ningún humano que responda a una demanda UDRP» si nadie vigila los dominios que un agente registra con sus credenciales, como se explica con más detalle en Cómo compran dominios los agentes de IA sin intervención humana. Una demanda UDRP se presenta contra el registrante inscrito —quienquiera que sea esa persona o entidad jurídica—, no contra el agente que envió el registro.

Entonces, ¿quién responde realmente si el dominio de un agente causa un problema legal?

El registrante inscrito: la persona o entidad jurídica cuya cuenta, clave de API o billetera autorizó el registro; nunca el propio modelo de IA. Ese es el hilo conductor de todas las preguntas anteriores: WHOIS/RDAP identifica a una persona o entidad jurídica, el RAA exige una, las protecciones de bloqueo de transferencias de ICANN y la exposición a la UDRP recaen sobre ese mismo nombre, y la tokenización cambia la mecánica del control sin modificar quién responde en última instancia. «El agente posee el dominio» es una abreviatura útil de «se ha delegado al agente el control del dominio»; trátala como una abreviatura, no como un hecho jurídico establecido, pues sigue sin probarse hasta dónde puede llegar esa delegación y si alguna jurisdicción tratará a un agente autónomo como algo más que una herramienta de cuyo uso responde su operador. Antes de otorgar a un agente autoridad de compra o custodia en cualquier nivel, decide explícitamente quién es el registrante legal.

Registra y tokeniza con un registrante real en el registro

Namefi está diseñado precisamente para este tipo de situación: un registro real acreditado por ICANN, con el campo de registrante tratado como exige ICANN y una capa opcional tokenizada que coloca el control on-chain en la billetera que elijas, incluida una que un agente opera bajo las salvaguardas que establezcas. Empieza por Cómo registrar un dominio con tu agente de IA en Namefi o pasa directamente a la compra firmada con billetera en Paga dominios con una billetera de criptomonedas.

Busca y registra un dominio en Namefi.

Fuentes y lecturas adicionales

ICANN — Acuerdo de Acreditación de Registradores de 2013, §3.7.7 («debe ser una persona o entidad jurídica distinta del registrador»: la regla central sobre elegibilidad del registrante)
ICANN — Beneficios y responsabilidades de los registrantes («asumirá la responsabilidad exclusiva del registro y uso de su nombre de dominio»)
ICANN — Preguntas frecuentes para registrantes: transferencia de su nombre de dominio (bloqueos de transferencia de 60 días para registros nuevos y cambios de registrante)
ICANN — Búsqueda de ICANN (lookup.icann.org) (la consulta oficial de WHOIS/RDAP basada en RDAP para el registro actual de cualquier dominio)
Ethereum — EIP-721: estándar de tokens no fungibles (sin restricción sobre qué dirección, incluido un contrato, puede tener un token)
Namefi — namefi.io/llms.txt (referencia sobre tokenización y acuñación mediante nftReceivingWallet: fuente de las afirmaciones de producto de Namefi en este artículo)
dev.to — Cómo los agentes de IA pueden comprar sus propios nombres de dominio y por qué importa (exposición a la UDRP cuando nadie supervisa los registros de un agente)
Namefi — Cómo compran dominios los agentes de IA sin intervención humana (2026) (las salvaguardas y el planteamiento sobre reventa en los que se basa este artículo)
Namefi — Paga dominios con una billetera de criptomonedas: sin necesidad de cuenta (mecánica de custodia con billetera firmada y salvaguardas de política de gasto)