هل يمكن لوكيل ذكاء اصطناعي امتلاك نطاق؟ WHOIS والحفظ والرموز

يتكرر سؤال: "هل يمكن لوكيل الذكاء الاصطناعي الخاص بي امتلاك نطاق؟" بمجرد أن يبدأ وكيل الذكاء الاصطناعي في تسجيل النطاقات وتجديدها وإدارتها نيابةً عن شخص ما. راجع كيف يشتري وكلاء الذكاء الاصطناعي النطاقات من دون إنسان لتعرف مدى شيوع ذلك في 2026. الإجابة المختصرة في البداية؛ أما بقية الصفحة فتشرح السبب عبر الأسئلة المحددة التي يطرحها الناس فعلًا، بحيث يمكن فهم كل إجابة بمفردها.

هل يمكن لوكيل ذكاء اصطناعي امتلاك نطاق قانونيًا؟

ليس باسمه هو. تنص اتفاقية اعتماد المسجِّلين لعام 2013 الصادرة عن ICANN — وهو العقد الذي يوقّعه ويعمل بموجبه كل مسجِّل معتمد من ICANN — بوضوح على أن "حامل الاسم المسجَّل الذي يبرم معه المسجِّل اتفاقية تسجيل يجب أن يكون شخصًا أو كيانًا قانونيًا غير المسجِّل". يجب أن يكون المسجَّل شخصًا طبيعيًا أو كيانًا قانونيًا مسجَّلًا: فردًا أو شركة أو منظمة غير ربحية أو جهة حكومية. وكيل الذكاء الاصطناعي، بصفته برمجية، ليس أيًّا من ذلك. لذلك لا يمكن أن يظهر الوكيل نفسه باسمه في التسجيل.

لكن ما لا تمنعه القاعدة هو التفويض. فلا يوجد في RAA ما يمنع إنسانًا أو مؤسسة من تفويض وكيل للبحث أو التسجيل أو التجديد أو إدارة DNS نيابةً عنها، تمامًا كما قد يفوّض شخص موظفًا أو أداة أتمتة اليوم. يبقى المسجَّل شخصًا قانونيًا، بينما يمكن إسناد عمل تشغيل النطاق إلى الوكيل. والتمييز بين من اسمه في السجل ومن ينقر (أو يستدعي API) هو محور هذه الصفحة بالكامل.

من هو المسجَّل عندما يسجل وكيل ذكاء اصطناعي نطاقًا؟

هو صاحب الحساب الذي موّل الشراء ووافق على شروط المسجِّل، وليس الوكيل أبدًا. عندما يستدعي وكيل API لمسجِّل كي يسجل اسمًا، فإنه يعمل كأداة بتفويض من شخص ما؛ وهو الشكل القانوني نفسه لاستخدام شخص نموذج ويب، لكنه مؤتمت. وإرشادات ICANN للمسجَّلين صريحة في تحديد موضع هذه المسؤولية: "ستتحمل المسؤولية المنفردة عن تسجيل اسم نطاقك واستخدامه"، وفق صفحة مزايا ومسؤوليات المسجَّلين لدى ICANN. تقع هذه المسؤولية على صاحب الحساب الذي أطلق الوكيل، لا على البرمجية التي نفذت الاستدعاء.

ولهذا يمر كل مسار موثوق لتسجيل وكيل — بما في ذلك Namefi — عبر بيانات اعتماد يتحكم فيها إنسان أو كيان: مفتاح API مرتبط بحساب ممول، أو محفظة يتحكم شخص ما في المفتاح الخاص بها. راجع كيفية تسجيل نطاق باستخدام وكيل الذكاء الاصطناعي على Namefi لمعرفة كيف تعمل خطوة بيانات الاعتماد عمليًا.

ماذا يعرض سجل WHOIS أو RDAP فعليًا لنطاق سجله وكيل؟

الحقول نفسها التي يعرضها لأي تسجيل آخر: المسجِّل المُدوَّن في السجل، وتاريخا التسجيل والانتهاء، واسم المسجَّل ومؤسسته وبيانات الاتصال به، ما لم تُخفَ بموجب خصوصية WHOIS (و RDAP) التي يطبقها معظم المسجِّلين افتراضيًا الآن. لا يوجد حقل باسم "سجله وكيل ذكاء اصطناعي"، ولا تعرف أي سياسة لـ ICANN مثل هذا الحقل. أداة البحث الرسمية لـ ICANN المعتمدة على RDAP، وهي ICANN Lookup، هي المكان المرجعي للتحقق من السجل الحالي لأي نطاق محدد؛ وهي تعيد المخطط نفسه سواء كتب إنسان نموذج التسجيل أم استدعى وكيل API لإرسال البيانات ذاتها.

عمليًا، يعني ذلك أن المراقب الخارجي — صاحب علامة تجارية أو باحث أمني أو مشترٍ محتمل — لا يمكنه أن يعرف من WHOIS/RDAP وحده أن النطاق سُجِّل بواسطة وكيل. فالسجل يحدد المسجَّل القانوني، أما ما أنتج استدعاء API الذي أنشأه فليس جزءًا من نموذج البيانات.

ما الفرق بين أن يشغّل وكيل النطاق وأن يمتلكه؟

التشغيل يعني أن الوكيل يستطيع التصرف في النطاق — تجديده أو تعديل سجلات DNS أو بدء نقله — لأنه يحمل بيانات اعتماد محددة الصلاحية تتيح له ذلك. أما الملكية، بالمعنى الوحيد ذي الأثر القانوني، فتعني أن يكون الشخص هو المسجَّل في السجل وفق تعريف RAA المذكور أعلاه: شخص أو كيان قانوني مسؤول أمام المسجِّل وسياسات ICANN. يمكن لوكيل أن يشغّل نطاقًا على نطاق واسع — إذ يوفّر خادم MCP الخاص بـ Namefi هذا النوع من الأدوات تحديدًا — من دون أن يصبح المالك في أي وقت، مثل مدير العقار الذي يملك المفاتيح ويجري اتصالات الصيانة من دون أن يحمل سند ملكية المبنى.

وتقع معظم الأسئلة العملية التي يطرحها الناس في الفجوة بين هذين الدورين؛ لذلك تعالجها الأقسام التالية كطيف بدلًا من جواب بسيط بنعم أو لا.

ما طيف الحفظ للنطاق الذي يديره وكيل؟

ثلاثة مستويات، يمنح كل منها الوكيل تحكمًا مباشرًا أكثر تدريجيًا بينما يبقى المسجَّل القانوني ثابتًا:

• الوصول إلى حساب المسجِّل. يستخدم الوكيل (أو البرنامج النصي الذي يستدعي API للمسجِّل نيابةً عنه) بيانات اعتماد مرتبطة بحساب المسجِّل الخاص بالإنسان أو المؤسسة. لا يتغير حقل المسجَّل أبدًا؛ فالوكيل يتصرف ببساطة داخل حساب يملكه شخص بالفعل، على غرار ترتيب مشاركة تسجيل الدخول المتبع اليوم.
• مفتاح API. بيانات اعتماد محددة النطاق لـ API الخاص بالمسجِّل، تُحمّل تكلفتها على رصيد ممول، من دون ضرورة مشاركة الوصول الكامل إلى لوحة تحكم الحساب. تُصدر Namefi هذه المفاتيح حتى يستطيع الوكيل البحث والتسعير والتسجيل من دون لمس جلسة متصفح — كما هو مشروح في كيفية تسجيل نطاق باستخدام وكيل الذكاء الاصطناعي على Namefi. ويبقى المسجَّل هو صاحب الحساب الذي يقتصر المفتاح على نطاقه.
• دومين مُرمَّز محفوظ في محفظة. يُسكّ التسجيل كرمز على السلسلة، ومن يحمل هذا الرمز في محفظته — عبر إتمام دفع x402 بتوقيع المحفظة أو عبر عنوان استلام محدد — يتحكم مباشرة في مسار نقل النطاق على السلسلة، من دون المرور عبر لوحة تحكم المسجِّل أصلًا. راجع الدفع مقابل النطاقات بمحفظة عملات مشفرة: من دون حساب للتعرف على آلية وضع نطاق في محفظة بهذه الطريقة.

كل مستوى أكثر مباشرة من سابقه، لكن سؤال المسجَّل القانوني الذي طُرح سابقًا لا يتغير؛ فالإجابة واحدة مهما كان المستوى الذي يعمل فيه الوكيل.

ماذا يتغير عند ترميز نطاق؟

يؤدي ترميز نطاق إلى سكّ NFT (رمز غير قابل للاستبدال) يعمل كطبقة تحكم موازية على السلسلة فوق تسجيل DNS حقيقي، وهو ما يشرحه بتفصيل أكبر مقال ما النطاقات المرمَّزة؟. تفعل Namefi ذلك، بصفتها مسجِّلًا معتمدًا من ICANN، بالإبقاء على التسجيل الأساسي حقيقيًا ومعترفًا به من ICANN مع سكّ رمز الملكية في محفظة يحددها المشتري. وتصف وثائق Namefi نفسها تسجيل نطاق مع إرسال الرمز الناتج مباشرة إلى عنوان nftReceivingWallet يتحكم فيه المشتري. يظل للنطاق سجل WHOIS/RDAP ومسجِّل مُدوَّن في السجل؛ ويضيف الرمز طريقة لنقل التحكم في ذلك السجل من نظير إلى نظير وعلى السلسلة، من دون طلب نقل بوساطة المسجِّل.

لكن الترميز لا يعيد تعريف من يحق له أن يكون مسجَّلًا. إذ لا يفرض معيار ERC-721 (معيار NFT) الذي تُبنى عليه النطاقات المرمَّزة أي قيد على نوع العنوان الذي يمكنه الاحتفاظ برمز؛ فبإمكان أي عنوان محفظة امتلاك NFT، ويتصور المعيار صراحةً العقود التي تحتفظ بالرموز أيضًا. هذا وصف للرمز، لا لقواعد ICANN الخاصة بالمسجَّل، التي تقع في طبقة المسجِّل الأعلى وما زالت تتطلب أن يعود التسجيل الأساسي إلى شخص أو كيان قانوني.

هل يمكن لمحفظة وكيل ذكاء اصطناعي أن تحتفظ بالفعل بنطاق مُرمَّز؟

تقنيًا، نعم، بالمعنى الضيق الذي تكون فيه المحفظة مجرد زوج مفاتيح، ولا يتحقق أي شيء في معيار ERC-721 أو في معاملة سكّ مما إذا كان الطرف المسيطر على المفتاح الخاص إنسانًا أو برنامجًا نصيًا أو عملية ذاتية التشغيل. إذا كانت لدى الوكيل صلاحية توقيع على محفظة — بمفتاحه الخاص أو بصلاحية مفوضة على مفتاح شخص آخر — فيمكن لتلك المحفظة استقبال NFT لنطاق مُرمَّز والاحتفاظ به، تمامًا كأي محفظة أخرى.

أما ما إذا كان هذا الترتيب يجعل الوكيل مالكًا بأي معنى قانوني جوهري، فهو سؤال مفتوح فعلًا لا يمكننا حسمه هنا. فلا توجد سياسة من ICANN ولا حكم قضائي ولا مصدر وجدناه يتناول وكيل ذكاء اصطناعي (بدلًا من الشخص أو الكيان الذي يتحكم في محفظته) يحمل سندَ ملكيةٍ قانونيًا لأي شيء. تعامل مع عبارة "محفظة الوكيل تحتفظ بالرمز" بوصفها وصفًا للحفظ التقني، لا نتيجة قانونية مستقرة. والتأطير الأكثر أمانًا، والذي تدعمه جميع المصادر أعلاه، هو أن المتحكم في المحفظة — من يحمل المفتاح الخاص أو يستطيع توجيهه — هو الطرف صاحب الادعاء الحقيقي، وما زال متوقعًا أن يكون شخصًا أو كيانًا، لا البرمجية نفسها.

ماذا يحدث إن أساء الوكيل التصرف؟ هل يمكن قفل النطاق أو استرداده؟

تنطبق آليتان مختلفتان للحماية بحسب مستوى الحفظ، ولا تقدمان النوع نفسه من الرجوع. على مستوى المسجِّل، تفرض قواعد نقل ICANN احتكاكًا متعمدًا: فعادة لا يمكن نقل النطاق إلى مسجِّل جديد خلال 60 يومًا من التسجيل الأولي، كما ينطبق قفل تغيير المسجَّل لمدة 60 يومًا بعد تغيير اسم المسجَّل أو مؤسسته أو عنوان بريده الإلكتروني. وكلاهما موثقان في الأسئلة الشائعة للمسجَّلين لدى ICANN. تمنح هذه الفترات المسجَّل وقتًا لملاحظة تغيير غير مصرح به والاعتراض عليه قبل أن يصبح نهائيًا، وهي حماية حقيقية وإن كانت محدودة من وكيل يخرج عن السيطرة في حساب مسجِّل عادي أو مفتاح API.

وبمجرد ترميز النطاق واستقرار NFT في محفظة، تبدو شبكة الأمان هذه مختلفة. فعادة ما يكون التحويل على السلسلة نهائيًا بعد تأكيده؛ ولا يوجد قفل من جانب المسجِّل لعكس رمز أُرسل إلى عنوان خاطئ. لذلك ينتقل الدفاع العملي إلى مرحلة أسبق: مقدار الصلاحية التي تملكها محفظة الوكيل، كترتيب توقيع متعدد (Multi-sig) يتطلب موقّعًا ثانيًا، أو ببساطة عدم منح وكيل صلاحية دائمة على محفظة تحتفظ بنطاقات مرمَّزة عالية القيمة. وهو مبدأ الحاجز الوقائي نفسه المشروح للمدفوعات في الدفع مقابل النطاقات بمحفظة عملات مشفرة.

هل يزيل ترميز نطاق التعرض لـ UDRP؟

لا، ولا يشير أي مصدر راجعناه إلى خلاف ذلك. تلتصق التزامات UDRP (السياسة الموحدة لتسوية منازعات أسماء النطاقات) بتسجيل DNS الأساسي المعترف به من ICANN، وهو تسجيل ما زال موجودًا للنطاق المرمَّز. فالترميز يغير من يستطيع نقل النطاق وكيف، لا ما إذا كان قانون العلامات التجارية أو سياسة ICANN لتسوية المنازعات ينطبقان عليه. وتوضح مقالة رأي عن نطاقات يملكها وكلاء هذا التعرض: "إذا سجّل وكيل نطاقًا اتضح أنه يتعارض مع علامة تجارية، فلن يوجد إنسان للرد على شكوى UDRP" إذا لم يكن أحد يراقب ما يسجله الوكيل ببيانات اعتماده، كما فُصّل أكثر في كيف يشتري وكلاء الذكاء الاصطناعي النطاقات من دون إنسان. تُرفع شكوى UDRP على المسجَّل في السجل، أيًا كان ذلك الشخص أو الكيان القانوني، لا على الوكيل الذي قدّم التسجيل فحسب.

من المسؤول فعليًا إذا تسبب نطاق وكيل في مشكلة قانونية؟

المسجَّل في السجل: الإنسان أو الكيان القانوني الذي أذن حسابه أو مفتاح API الخاص به أو محفظته بالتسجيل، وليس نموذج الذكاء الاصطناعي نفسه. هذا هو الخيط الجامع لكل الأسئلة أعلاه: يسمّي WHOIS/RDAP شخصًا قانونيًا، ويتطلبه RAA، وتلتصق باسم الشخص ذاته حماية أقفال النقل لدى ICANN والتعرض لـ UDRP، فيما يغير الترميز آليات التحكم من دون المساس بمن تقع عليه المسؤولية في الأساس. عبارة "الوكيل يملك النطاق" اختصار مفيد لعبارة "فُوِّض الوكيل بالتحكم في النطاق"؛ تعامل معها كاختصار لا كحقيقة قانونية مستقرة، لأن مدى هذا التفويض وما إذا كانت أي ولاية قضائية ستعامل وكيلًا ذاتي التشغيل على أنه أكثر من أداة يتحمل مشغّلها مسؤوليتها ما زال أمرًا لم يُختبر. قبل منح وكيل سلطة شراء أو حفظ عند أي مستوى أعلى، حدّد بوضوح من هو المسجَّل القانوني.

سجّل ورمّز مع وجود مسجَّل حقيقي في السجل

Namefi مصممة لهذا الشكل تحديدًا من الأسئلة: تسجيل حقيقي لدى مسجِّل معتمد من ICANN، مع التعامل مع خانة المسجَّل بالطريقة التي تتطلبها ICANN، وطبقة دومين مُرمَّز اختيارية تضع التحكم على السلسلة في أي محفظة تختارها، بما فيها محفظة يشغلها وكيل ضمن الحواجز الوقائية التي تضعها. ابدأ بمقال كيفية تسجيل نطاق باستخدام وكيل الذكاء الاصطناعي على Namefi، أو انتقل مباشرة إلى إتمام الدفع بتوقيع المحفظة في الدفع مقابل النطاقات بمحفظة عملات مشفرة.

ابحث عن نطاق وسجّله عبر Namefi.

المصادر وقراءات إضافية

• ICANN — اتفاقية اعتماد المسجِّلين لعام 2013، §3.7.7 ("يجب أن يكون شخصًا أو كيانًا قانونيًا غير المسجِّل" — القاعدة الجوهرية لأهلية المسجَّل)
• ICANN — مزايا ومسؤوليات المسجَّلين ("ستتحمل المسؤولية المنفردة عن تسجيل اسم نطاقك واستخدامه")
• ICANN — الأسئلة الشائعة للمسجَّلين: نقل اسم نطاقك (أقفال النقل لمدة 60 يومًا للتسجيل الجديد وتغيير المسجَّل)
• ICANN — بحث ICANN (lookup.icann.org) (أداة البحث الرسمية المعتمدة على RDAP في WHOIS/RDAP لسجل المسجَّل الحالي لأي نطاق)
• Ethereum — EIP-721: معيار الرموز غير القابلة للاستبدال (لا يفرض قيودًا على نوع العنوان، بما في ذلك العقد، الذي يمكنه الاحتفاظ برمز)
• Namefi — namefi.io/llms.txt (مرجع لترميز النطاقات وسكّها إلى nftReceivingWallet — مصدر الادعاءات المتعلقة بمنتج Namefi في هذا المقال)
• dev.to — كيف يمكن لوكلاء الذكاء الاصطناعي شراء أسماء نطاقاتهم ولماذا يهم ذلك (التعرض لـ UDRP عند غياب من يراقب تسجيلات الوكيل)
• Namefi — كيف يشتري وكلاء الذكاء الاصطناعي النطاقات من دون إنسان (2026) (ضوابط الحماية وإطار الموزع الذي يبني عليه هذا المقال)
• Namefi — الدفع مقابل النطاقات بمحفظة عملات مشفرة: من دون حساب (آليات الحفظ بتوقيع المحفظة وضوابط سياسة الإنفاق)