الخلاصة

  • توصي draft-fengfar-led-01 بأن يكوّن مشارك IETF موقفه قبل استخدام الذكاء الاصطناعي، وأن يراجع وفاء المخرجات لذلك الموقف، وأن يكون شفافاً دائماً. لكنها ما زالت Internet-Draft فردية نشطة وليست سياسة لـIETF.
  • تشمل المسودة البريد الإلكتروني وشرائح الاجتماعات ونقاشات المستودعات وربما الرسائل الفورية، وتستبعد صراحة نصوص Internet-Draft وRFC لأن BCP 78 وBCP 79 ينظمان أيضاً المساهمات والملكية الفكرية فيها.
  • يحتاج الإفصاح المفيد إلى سجل مرتبط بالمساهمة يحدد الإنسان المسؤول، ووظيفة الأداة ونطاقها، وحدود المواد، والتحقق البشري، والموافقة النهائية، وإمكان الإرسال الذاتي، ومسار التصحيح.

القارئ يدفع الكلفة أولاً

يمكن للأداة أن تنتج رسالة طويلة ومهذبة في وقت قصير. أما المجتمع فعليه أن يقرأ ببطء: يفحص المصادر، ويستعيد سياق النقاش، ويميّز الاعتراض الحقيقي، ويسأل إن كان المرسل يفهم ما ينسبه إلى اسمه.

لهذا لا تكفي عبارة «استخدمت الذكاء الاصطناعي». فهي لا تقول إن كانت الأداة قد ترجمت موقفاً مكتملاً، أو استرجعت رسالة قديمة، أو لخّصت اتفاقاً سابقاً، أو ولّدت حجة، أو كتبت الرسالة كلها، أو أرسلتها من دون اعتماد نهائي من إنسان. ولا تحدد الفقرة أو الادعاء الذي تأثر.

تحمل المسودة عبارة قوية ومختصرة: “Always be transparent”. لكنها تصف توصياتها العملية بأنها مؤقتة إلى حد بعيد، وتقول في الخاتمة إن الوقت ما زال مبكراً للحسم. حجتها الأوضح هي أن على IETF تطوير إرشادات قبل أن تتآكل الثقة في نقاشات البريد.

الوضع المؤسسي لا يقل أهمية عن النص. يسجل Datatracker draft-fengfar-led-01 بوصفها Internet-Draft فردية نشطة، وحالتها I-D Exists، من دون RFC stream أو Area Director مسؤول أو موعد telechat. وقد وصفها منشور 31 يوليو بأنها أولية وغير إلزامية ولا تتمتع بسلطة. أضاف إصدار 6 أغسطس نقاطاً من القائمة العامة، لكنه لا يمثل تبنياً من Working Group أو rough consensus أو موافقة IESG أو قاعدة لـIETF.

في 26 أغسطس وسّع مقال لـGeorge Michaelson على APNIC Blog الانتباه إلى المسألة، وربط مساعدة الذكاء الاصطناعي بعبء المشاركة باللغة الإنجليزية في وضع المعايير وسياسات RIR. وتوضح الصفحة أن آراء الكاتب لا تمثل بالضرورة APNIC. الجديد هو اتساع النقاش، لا صدور سياسة من APNIC أو IETF.

للمسودة حد مقصود

تتناول المسودة النص المستخدم في نقاشات IETF: رسائل القوائم، وشرائح الاجتماعات، وGitHub issues وpull requests، وربما المراسلة الفورية. ولا تشمل النص داخل Internet-Draft وRFC. فتلك المساهمات تقع أيضاً ضمن ترتيبات الحقوق والملكية الفكرية في BCP 78 وBCP 79.

يعني ذلك أن إرشاداً مستقبلياً للبريد لن يحسم تلقائياً مسائل التأليف والإفصاح داخل وثيقة معيارية. كما أن إقراراً في قسم الشكر داخل مسودة لن يصف بالضرورة كيفية ترجمة عشرات الرسائل المحيطة بها أو تلخيصها أو توليدها أو إرسالها ذاتياً.

بدأت الوثيقة من اختلاف ملموس. استخدم مشارك الذكاء الاصطناعي لتحسين التعبير عن أفكار كوّنها بنفسه. ورأى قارئ أسلوباً يشبه LLM فتوقف عن القراءة لأنه لم يعرف مقدار العمل البشري. يعرض المؤلفان المنظورين من دون إصدار حكم على أحدهما. المشكلة المشتركة هي غياب معيار مفهوم.

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

الإدماج وعبء المراجعة وجهان لقدرة واحدة

قد تخفض الترجمة والتحرير حاجزاً حقيقياً. فامتلاك فكرة تقنية دقيقة لا يساوي القدرة على صياغتها بإنجليزية اصطلاحية. ويمكن للمشارك أن يخصص جهده للهندسة بدلاً من الصياغة.

لكن القدرة نفسها تنقل العمل إلى الآخرين. إذا أنتج مرسل واحد رسائل كثيرة، فقد ينفق عشرات القراء وقتهم في التحقق. وإذا تبادلت الوكلاء الردود، قد يبدو الحجم وكأنه اهتمام من المجتمع من دون إضافة أحكام مستقلة. الأدب في النبرة لا يلغي عبء الكمية.

تسجل المسودة مخاوف من الجدران النصية والثقة المصطنعة وتغير الصوت. هذه مؤشرات وليست منشأ مثبتاً. فالإنجليزية المصقولة أو سرعة النشر أو نتيجة كاشف لا تثبت استخدام الأداة، وقد تضع غير الناطقين أصلاً باللغة ومستخدمي تقنيات الإتاحة موضع شك دائم.

والإفصاح الصحيح لا يثبت صحة الحجة أيضاً. المنشأ يحدد المسؤولية، أما المراجعة التقنية فتحدد قوة الادعاء. الخلط بينهما يحول الوسم إلى ترخيص للكلام وغيابه إلى قرينة خداع.

قواعد مجاورة بسلطات مختلفة

يقدم RFC 9775 مثالاً قريباً داخل IRTF. وهو يمثل إجماع IRSG، ويصرح بأنه ليس منتجاً لـIETF ولا معياراً. في نطاقه لا يجوز تسمية أداة ذكاء اصطناعي توليدي مؤلفاً، ويجب الإفصاح عن الكميات الكبيرة من النص أو المحتوى المولد، مثلاً بذكر النظام وكيف أسهم. ولا يلزم الإفصاح عن تحسين الإملاء أو القواعد أو الترجمة أو العرض.

تضع Group Note صادرة عن W3C Advisory Board في مارس 2026 عتبة مختلفة. توصي بوسم واضح عندما يكون المحتوى في معظمه من مخرجات LLM، وتطلب من الفرد التحقق وتحمل المسؤولية وحماية السرية وعدم استبدال المداولة بردود آلية. وقد أيدها Advisory Board، لا W3C كله ولا أعضاؤه.

«كميات كبيرة» و«في معظمه» و«دائماً شفاف» ليست ثلاث صيغ لقاعدة عالمية. إنها اختيارات صادرة — أو مقترحة — تحت سلطات مختلفة. ولا يجوز استيراد إحداها إلى IETF من دون قرار منسوب إلى الجهة المختصة.

سجل المسؤولية الذي يقترحه Daniel Kade

أصغر وحدة نافعة هي سجل يرافق مساهمة محددة.

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

يسجل أيضاً حدود المادة: هل تعاملت الأداة مع مصادر عامة فقط، أم ملاحظات محلية، أم معلومات سرية؟ يكفي تصنيف الحد من دون نشر المادة. ولا ينبغي أن تطلب الشفافية prompts كاملة أو كلمات اعتماد أو ملاحظات خاصة أو مسودات سرية أو سياقاً مملوكاً أو سلسلة التفكير؛ وإلا أصبحت وسيلة لتسريب جديد.

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

اسم النموذج سياق ثانوي لا برهان. يستطيع المورد تغيير السلوك مع بقاء اسم المنتج، والاسم لا يثبت فهم بروتوكول أو تدقيق مرجع أو قبول المسؤولية.

هذا تصميم يقترحه Daniel Kade، وليس متطلباً في المسودة الحالية. وغايته إبقاء القرار عند الإنسان مع جعل تنفيذ الأداة قابلاً للتدقيق بالقدر اللازم.

التعريف يسبق الإشراف

يحدد RFC 9245 القائمة العامة ويضع فيها مسائل اتجاه IETF وسياساته وعملية المعايير عندما لا يوجد مكان أفضل. ويوزع RFC 9945 المسؤوليات بين المشاركين ومديري المنتديات والمشرفين وArea Directors وIESG. ويحصر إجراءات الإشراف في التواصل المخل، مع إجراءات علنية وإعادة نظر واستئناف.

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

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

ما لا تثبته الأدلة

لم تتبن IETF المشاركة المدعومة بالذكاء الاصطناعي ولم ترفضها. ولا توجد في هذا الملف بينة على أن نصاً مولداً غيّر نتيجة إجماع فعلية. ولا تفرض المسودة اليوم إفصاحاً عن كل رسالة تمت مساعدتها.

لا يحكم RFC 9775 نقاش IETF العادي لمجرد نشره في RFC Series. ولا تمثل W3C Group Note إجماع أعضاء W3C. ومقال APNIC Blog ليس سياسة لـAPNIC. ولا توجد بينة على أن مشاركاً بعينه حرّف التأليف أو سمح بإرسال ذاتي.

الخلاصة المحدودة أن النقاش حدد الإنسان المسؤول على نحو صحيح، لكنه لم يحدد بعد السجل الذي يسمح بفحص تلك المسؤولية. تتحول الشفافية إلى حوكمة عندما يصبح الموضوع والسلطة والتحقق والتصحيح محددة.

المصادر

  1. https://datatracker.ietf.org/doc/draft-fengfar-led/
  2. https://www.ietf.org/archive/id/draft-fengfar-led-01.html
  3. https://mailarchive.ietf.org/arch/msg/ietf/3VaBJ6pEdhtkpOtnZYA_HcVHejU/
  4. https://mailarchive.ietf.org/arch/msg/i-d-announce/_nalEUgYdyn7LdNfwQghXW9dPRc/
  5. https://blog.apnic.net/2026/08/26/the-emerging-role-of-ai-in-governance-discussion/
  6. https://www.ietf.org/rfc/rfc9775.html
  7. https://www.w3.org/TR/2026/NOTE-llms-standards-20260324/
  8. https://datatracker.ietf.org/doc/html/rfc9245
  9. https://datatracker.ietf.org/doc/html/rfc9945
  10. https://datatracker.ietf.org/doc/html/rfc5378
  11. https://datatracker.ietf.org/doc/html/rfc8179