من يقرر ماذا: رسم حقوق القرار بين فريقك ووكلاء الذكاء الاصطناعي

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

ذلك توقيت سيئ لاختراع سياسة. الأجدى أن تقرر مسبقًا، قبل أن يحمل الوكيل مفتاحًا، من يقرر ماذا. هذا هو سؤال الحوكمة، وله إجابة أنظف مما يتوقع أغلب الناس.

القاعدة: قابلية التراجع وحجم الرهان

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

هل يمكن التراجع عنها بسهولة؟ وإن أخطأت، كم يكون الضرر؟

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

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

حجم الرهان مهم لأن بعض الأفعال القابلة للتراجع تبقى باهظة: إرسال رسالة خاطئة إلى عميل قابل للسحب تقنيًا، لكنه يُحدث ضررًا رغم ذلك. حين يقع أحد السؤالين على الجانب الخطأ، يقرر إنسان.

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

وعلى هيئة شجرة قرار، تتسع السياسة كلها في أربعة صناديق:

flowchart TD
    M["A move the agent could make"] --> Q1{"Can it be undone easily?"}
    Q1 -->|no| HU["A human makes the call"]
    Q1 -->|yes| Q2{"Does it hurt much if it goes wrong?"}
    Q2 -->|yes| HU
    Q2 -->|no| AG["The agent makes it"]

كيف يبدو هذا في أداة إدارة مشاريع

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

خطوات من حق الوكيل اتخاذها، لأنها رخيصة التراجع وقليلة الرهان:

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

خطوات تحتاج إلى إنسان، لأنها صعبة التراجع أو ذات وزن حقيقي:

• إغلاق ملحمة أو اعتبار إصدار منجزًا.
• تغيير تاريخ استحقاق إصدار ملتزَم به.
• حذف عمل، أو أرشفة مشروع.
• أي شيء يراه عميل أو يغيّر وعدًا قطعته.
• تعديل إعدادات المشروع أو الصلاحيات أو أعضاء الفريق.

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

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

كيف يتيح لك Taskfolk رسم الخطوط

الإطار لا ينفع إلا إذا استطاعت الأداة فرضه. في Taskfolk تُرسم الخطوط في أربعة مواضع، وهي تتراكب.

الأدوار والصلاحيات هي الأساس. الوكيل في Taskfolk عضو حقيقي في مساحة العمل له دور، ومصفوفة الصلاحيات نفسها التي تحكم البشر تحكم الوكلاء. وكيل بدور عضو يستطيع الإنشاء والتعليق والتصنيف؛ ولا يستطيع لمس إعدادات المشروع، لأن الأعضاء لا يستطيعون. أنت تضع السقف باختيار الدور.

المفاتيح المقيدة بالنطاقات ترسم الخط التالي. لكل وكيل مفتاح API خاص به، والمفتاح يحمل نطاقات. المبدأ: اقرأ بسخاء واكتب بشحّ؛ مفتاح يرى اللوحة كاملة ولا يكتب إلا حيث سمحت له.

نطاقا الكتابة مفصولان عن قصد. نطاق write العادي يمنح كتابات بمستوى عضو، الأمور رخيصة التراجع. أما admin فيمنح كل شيء، وهو مُبقى خارج write عمدًا، حتى لا يسلّم منحُ وكيلٍ قدرةَ إنشاء المهام قدرةَ حذف مشروع في الخفاء. إن كانت المهمة لا تحتاج سوى التصنيف والتعليق، فلا يحمل مفتاحها admin أبدًا، وتبقى الخطوات عالية الرهان خارج متناول الخطأ.

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

sequenceDiagram
    participant A as Agent
    participant U as Taskfolk
    participant H as Human
    A->>U: Draft the ticket, fill the fields
    A->>U: Move card to the review column
    H->>U: Read the work
    H->>U: Move it forward or send it back

عبر API، نقلة الإيقاف تلك استدعاء واحد لنقطة نهاية الانتقال. هذا وكيل ينقل WEB-12 إلى المراجعة:

curl -X POST \
  "https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/issues/WEB-12/transition" \
  -H "Authorization: Bearer tfk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"status": "in_review"}'

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/issues/WEB-12/transition",
  {
    method: "POST",
    headers: {
      Authorization: "Bearer tfk_live_...",
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ status: "in_review" }),
  },
);

import requests

res = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/issues/WEB-12/transition",
    headers={"Authorization": "Bearer tfk_live_..."},
    json={"status": "in_review"},
)

شرحنا آلية تلك البوابة في اعتماد بشري في الحلقة لوكلاء الذكاء الاصطناعي؛ المقصود هنا هو موضع البوابة فقط، وهو الخطوات التي وسمتها قاعدتك بأنها عالية الرهان.

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

{
  "error": {
    "code": "validation",
    "message": "Workflow blocks this transition: \"In progress\" cannot move to \"Done\".",
    "details": {
      "code": "workflow_transition_blocked",
      "from": "In progress",
      "to": "Done"
    }
  }
}

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

أين تكون الخطوط أخشن مما تريد

الصراحة هنا مهمة، لأن إطارًا يبالغ في دقة نفسه أسوأ من لا إطار.

النطاقات في Taskfolk على مستوى المورد، لا على مستوى الحقل. مفتاح write يستطيع تحديث المهام، و"تحديث مهمة" صلاحية واحدة. لا تستطيع اليوم منح وكيل حق تغيير تصنيفات مهمة مع منعه من تغيير تاريخ استحقاق المهمة نفسها. كلاهما كتابة على مهمة.

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

هذا ليس سببًا لإهمال الإطار. بل سبب لمعرفة أي أداة ترسم أي خط. الأدوار والنطاقات تتكفل بالخطوط العريضة: القراءة مقابل الكتابة، والعضو مقابل المدير. وخطوة الاعتماد وقواعد الانتقال تتكفلان بالخطوط الدقيقة داخل سير العمل.

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

ابدأ ضيّقًا

حقوق القرار ليست شيئًا تضبطه على الورق من أول مرة. تضبطه تقريبًا، ثم تشدّه. والمدخل الآمن هو نفسه مع أي موظف جديد:

• ابدأ الوكيل على الخطوات القابلة للتراجع قليلة الرهان.
• أعطه مفتاح write بلا admin.
• ضع بوابة مراجعة على كل ما يبدو أثقل.
• راقب سجل النشاط أسبوعين.

ولا توسّع الخطوط إلا حيث استحق التوسيع.

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