البنية الأساسية للبيانات للذكاء الاصطناعي العاملي (Agentic AI)

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

ما الخطأ الذي حدث؟ ليست المشكلة في النموذج. وليست في كيفية اتصال الوكيل بالأنظمة. المشكلة تكمن في البيانات التي تُغذي الوكيل نفسه.

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

إذا كانت بنية الوكيل (agentic architecture) هي محرك التنفيذ الجديد، فإن البنية الأساسية للبيانات (data foundation) هي الوقود ونظام الملاحة في آن واحد. بدون أساس بيانات قوي، قد يبدو الوكيل مقنعًا ولكنه خاطئ من الناحية التشغيلية. قد يقدم إجابات تبدو معقولة، لكنها تختار المورد الخطأ، أو تقرأ حالة الطلب بشكل خاطئ، أو تفسر السياسة بشكل غير صحيح.

الفرق بين وكيل في مرحلة العرض التجريبي ووكيل يصلح للاستخدام في العمليات اليومية لا يكمن عادةً في جودة المحادثة. الفرق يكمن في جاهزية البيانات (data readiness).

لماذا البيانات أهم من النموذج

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

يمكن شراء النماذج، لكن سياق المؤسسة لا يُشترى

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

الوكيل الذي لا يفهم هذا السياق سيفشل في النقطة الأكثر أهمية: التنفيذ التشغيلي.

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

مثال آخر في عمليات خدمة العملاء. يمكن للوكيل تلخيص تاريخ العميل بشكل جيد. ولكن إذا كانت حالة الاستحقاق (entitlement)، واتفاقيات مستوى الخدمة (SLA)، واستثناءات العقود غير متوفرة أو غير متزامنة، فقد يقدم الوكيل وعود خدمة لا تتوافق مع العقد. هذا ليس مجرد خطأ تقني؛ بل يمكن أن يصبح مشكلة تجارية ومتعلقة بالسمعة.

الوكيل بدون بيانات دقيقة ينتج هلوسة تشغيلية (Operational Hallucination)

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

على سبيل المثال، وكيل مالي يستنتج أن الفاتورة لم تُدفع بينما حالتها في نظام تخطيط الموارد (ERP) قد تغيرت بالفعل. أو وكيل موارد بشرية يجيب على سياسة الإجازات بناءً على مستند قديم لم يتم تحديثه. أو وكيل عمليات تقنية المعلومات يوصي بدليل تشغيل (runbook) غير ذي صلة لأن قاعدة بيانات إدارة التكوين (CMDB) غير دقيقة. أو وكيل سلسلة التوريد يقترح إعادة توجيه دون فهم قيود المخزون الفعلية.

المشكلة ليست فقط في دقة الإجابات. المشكلة هي أن الوكيل يبدأ في التأثير على الإجراءات والأولويات والقرارات.

جاهزية البيانات هي الفارق بين المرحلة التجريبية والإنتاج

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

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

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

البيانات المنظمة (Structured Data): الأساس للوكيل الفاعل (Action Agent)

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

ليست مجرد جداول، بل كائنات أعمال يجب أن تكون متسقة

من الأخطاء الشائعة افتراض أن البيانات المنظمة متوفرة بشكل كافٍ لمجرد أن الشركة لديها نظام تخطيط موارد (ERP) أو نظام إدارة علاقات العملاء (CRM). في الواقع، وجود النظام لا يعني تلقائيًا أن البيانات جاهزة للوكيل.

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

تعريفات أعمال متسقة. ما معنى "عميل نشط"؟ متى يعتبر الطلب "مُنجزًا"؟ ما الفرق بين "مورد معتمد" و"مورد مُفعّل"؟ إذا كانت هذه التعريفات تختلف عبر الوظائف أو البلدان، سيواجه الوكيل صعوبة في اتخاذ قرارات متسقة. في عملية التسجيل حتى إعداد التقارير (record-to-report)، على سبيل المثال، يجب أن تكون تعريفات الحسابات الحساسة، والأهمية النسبية، أو حالة التسوية واضحة. إذا لم تكن كذلك، فإن وكيل تنسيق الإقفال سيعطي أولوية خاطئة للعناصر.

ملكية واضحة. يجب أن يكون لكل مجال بيانات مالك من جهة الأعمال، وليس مجرد مسؤول تقني. يجب أن يكون واضحًا من المسؤول عن جودة البيانات الرئيسية للعملاء، أو الموردين، أو بيانات الموظفين، أو هيكل المنتجات. بدون ملكية، ستستمر مشاكل البيانات في اعتبارها "مشكلات نظام"، بينما تأثيرها المباشر يكون على عمليات الوكيل.

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

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

دلالات قوية بما فيه الكفاية. البيانات المنظمة للوكيل لا يكفي أن تكون "مخزنة". يجب أن يكون لها معنى يمكن فهمه عبر الأنظمة. هنا تصبح نماذج بيانات المؤسسة، والنموذج الأساسي (canonical model)، أو إدارة البيانات الرئيسية (master data management) ذات صلة. بعض المؤسسات الأكثر نضجًا بدأت أيضًا في التأكيد على نموذج بيانات مؤسسي متسق حتى لا تتغير قرارات الوكيل اعتمادًا على النظام المصدر.

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

أمثلة مؤسسية: المالية، المشتريات، والخدمات المشتركة

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

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

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

متى لا تكون البيانات المنظمة كافية

البيانات المنظمة مهمة جدًا للفعل. لكن الكثير من سياق المؤسسة لا يعيش في جداول المعاملات. السياسات، والعقود، والبريد الإلكتروني، ونصوص المكالمات، وإجراءات التشغيل القياسية (SOP)، وملاحظات الحالات غالبًا ما تكون هي المحددات للقرارات. هنا يأتي دور البيانات غير المنظمة.

البيانات غير المنظمة (Unstructured Data): حيث يختبئ السياق الحقيقي غالبًا

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

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

في عمليات خدمة العملاء، قد تكون حالة التذكرة موجودة في نظام إدارة علاقات العملاء (CRM)، لكن سياق مشاعر العميل، والوعود التي قُطعت، أو السبب الجذري للمشكلة غالبًا ما تكون موجودة في نصوص المكالمات وتاريخ المحادثات. في المشتريات، البيانات الرئيسية للموردين موجودة في النظام، لكن الشروط التجارية واستثناءات العقود موجودة في المستندات. في الموارد البشرية، بيانات الموظفين موجودة في نظام معلومات الموارد البشرية (HRIS)، لكن السياسات المحلية والأسئلة الشائعة واستثناءات البرامج غالبًا ما تعيش في البوابة الإلكترونية، أو ملفات PDF، أو البريد الإلكتروني. في عمليات تقنية المعلومات، التنبيهات موجودة في منصة المراقبة (observability platform)، لكن أدلة التشغيل، وتحليلات ما بعد الحادث (postmortem)، والحلول البديلة التاريخية غالبًا ما تكون موزعة في الويكي، وملاحظات التذاكر، وقنوات الدردشة.

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

البيانات غير المنظمة تحتاج إلى خط أنابيب (Pipeline)، وليس مجرد رفع مستندات

تتوقف العديد من التطبيقات الأولية عند "رفع المستندات إلى مخزن المتجهات (vector store)". بالنسبة للمؤسسات، هذا سطحي للغاية. تحتاج البيانات غير المنظمة إلى الإدارة من خلال خط أنابيب منضبط.

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

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

التقطيع والإثراء (Chunking and Enrichment). تحتاج المستندات الطويلة إلى تقسيمها إلى وحدات يمكن استرجاعها بشكل ملائم. لكن التقطيع لا يجب أن يكون أعمى. البيانات الوصفية مثل مالك المستند، وتاريخ السريان، والإصدار، والمنطقة، والوظيفة، ومستوى السرية، والحالة (نشط أو غير نشط) غالبًا ما تكون أكثر أهمية من التضمين (embedding) نفسه.

التضمينات والاسترجاع (Embeddings and Retrieval). تساعد التضمينات في البحث الدلالي، لكن استرجاع المؤسسات يجب أن يكون أكثر من مجرد بحث بالتشابه. يجب أن يأخذ في الاعتبار البيانات الوصفية، والأذونات، وسياق سير العمل. سياسة الموارد البشرية الخاصة بإندونيسيا لا يجب أن تظهر لحالة موظف في دولة أخرى فقط لأن اللغة متشابهة.

الاحتفاظ ودورة الحياة (Retention and Lifecycle). للبيانات غير المنظمة عمر أيضًا. لا ينبغي ترك رسائل البريد الإلكتروني القديمة، أو النصوص الحساسة، أو العقود المنتهية لتستمر كسياق نشط دون قواعد. يجب تطبيق سياسات الاحتفاظ حتى لا يبني الوكيل قراراته من ذاكرة كان يجب أن تصبح غير ذات صلة.

مفاضلة مهمة في البيانات غير المنظمة

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

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

حوكمة البيانات للوكلاء: من السياسة إلى وقت التشغيل (Runtime)

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

السؤال الرئيسي ليس فقط "من يمكنه الوصول إلى هذه البيانات؟" بل من يمكنه الوصول إلى هذه البيانات عبر الوكيل، ولأي غرض، وفي أي سير عمل، وبأي مستوى من الاستقلالية، وهل يؤدي هذا الوصول إلى إجراء أم مجرد رؤية؟

يجب تطبيق الأذونات أثناء الاسترجاع واستدعاء الأداة (Tool Call)

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

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

وينطبق الشيء نفسه على استدعاء الأداة. حق قراءة حالة الطلب يختلف عن حق تعديل الطلب. حق رؤية المورد يختلف عن حق تعديل البيانات الرئيسية للمورد.

حوكمة الوكلاء تتطلب سياق الغرض

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

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

يجب أن يشرح سجل التدقيق (Audit Trail) سياق القرار

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

إشارات تدل على أن حوكمة البيانات غير جاهزة للوكلاء

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

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

تعزيز البنية الأساسية للبيانات قبل التوسع

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

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

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

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