5 أسئلة حول بنية الذكاء الاصطناعي ستطرحها فرق المشتريات (وكيفية الإجابة عليها)

(في هذا المقال، تشير "بنية الذكاء الاصطناعي" تحديدًا إلى بوابة الذكاء الاصطناعي / طبقة التحكم التي تقع بين التطبيقات ومقدمي النماذج - حيث تتم عمليات التوجيه، والحوكمة، والمراقبة، والتحكم في التكاليف.)

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

1. إذا غيرنا الموردين، فما مدى صعوبة إعادة الكتابة؟
2. هل يمكننا إثبات أين ذهبت البيانات، وليس مجرد الادعاء بذلك؟
3. ما هي الوحدة التي ندفع مقابلها بالضبط، وهل يمكننا تحديد سقف لها؟
4. إذا تعطل هذا النظام، فما هو الحل البديل؟
5. ماذا يحدث إذا لم يعد هذا المورد موجودًا بعد ثلاث سنوات؟

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

ماذا تقصد فرق المشتريات حقًا بـ "بنية الذكاء الاصطناعي"؟

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

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

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

لهذا السبب نادرًا ما تركز فرق المشتريات على جودة النموذج فقط بعد الآن. السؤال الأكثر أهمية عادة ما يكون تشغيليًا:

"ما مدى صعوبة حوكمة هذا النظام ومراجعته وتوسيع نطاقه واستبداله على مدى السنوات القليلة القادمة؟"

غالبًا ما تحدد الإجابة على هذا السؤال ما إذا كانت مبادرة الذكاء الاصطناعي ستتجاوز مرحلة التجريب لتصل إلى التبني على مستوى المؤسسة.

إليك كيف تصمم المؤسسات التي تنجح بالفعل في عملية الشراء مكدس الذكاء الاصطناعي الخاص بها.

سؤال بنية الذكاء الاصطناعي رقم 1: هل يمكننا تغيير الموردين دون إعادة كتابة التطبيقات؟

تتكرر جملة واحدة أثناء تقييم بنية الذكاء الاصطناعي للمؤسسات:

"الجميع يقولون إنهم متوافقون مع OpenAI. ماذا يعني ذلك حقًا بالنسبة لـ Bedrock أو Gemini؟"

المسألة هي: تقول العديد من الفرق "نحن متوافقون مع OpenAI"، ولكن فقط لنماذج محدودة للغاية. بمجرد إدخال AWS Bedrock أو Gemini أو النماذج المحلية (Cloudera، وحدات معالجة الرسوميات الداخلية)، تتسلل عدم تطابق التنسيقات إلى كود التطبيق.

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

قاعدة معمارية عملية:

• يجب أن تستخدم التطبيقات تنسيق طلب واحد مستقر.
• تتم الترجمة إلى Bedrock أو Gemini أو Azure أو النماذج المستضافة ذاتيًا خارج كود التطبيق.

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

هذا المنطق لا يبدو مكلفًا في السنة الأولى. ولكنه يصبح مكلفًا للغاية في السنة الثالثة. وإليك السبب:

• تظهر نماذج جديدة كل ربع سنة.
• تتغير سلوكيات واجهة برمجة التطبيقات (API) (حساب الرموز، استدعاء الأدوات، معلمات الأمان).
• تتغير الفرق الداخلية، وتصبح المحولات المخصصة معرفة خاصة بالفرق.

اختبار مناسب للمشتريات:

"إذا بدلنا مزودي النماذج العام القادم، فكم عدد المستودعات التي ستتغير؟"

إذا لم تكن الإجابة "لا شيء تقريبًا"، فليس لديك بنية آمنة للمشتريات.

أين تضيف TrueFoundry قيمة:

توفر TrueFoundry طبقة واجهة برمجة تطبيقات (API) مستقلة عن المزودين توحد نماذج OpenAI وBedrock وGemini وAnthropic والنماذج المستضافة ذاتيًا ضمن عقد واحد - بحيث لا تدمج التطبيقات أبدًا منطق المزود.

سؤال هندسة الذكاء الاصطناعي رقم 2: هل يمكننا تدقيق كل مسار قرار للذكاء الاصطناعي؟

سؤال رئيسي آخر حول هندسة الذكاء الاصطناعي تطرحه فرق المشتريات أثناء تقييم هندسة الذكاء الاصطناعي هو:

"عندما يشتكي عميل، هل يمكننا إعادة بناء مسار قرار الذكاء الاصطناعي الكامل؟"

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

الشركات التي تنجح أثناء تقييم بنية الذكاء الاصطناعي تفصل بوضوح بين طبقتين تشغيليتين.

• مستوى البيانات: حركة المرور الحية، حساسة لزمن الاستجابة، وتبقى داخل شبكة المؤسسة.
• مستوى التحكم/التحليلات: السجلات، التتبعات، المقاييس، تُستخدم للمراجعات وتصحيح الأخطاء.

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

• المطالبات
• النموذج المختار
• عدد الرموز
• قرارات السياسة
• متغيرات الاستجابة

قاعدة معمارية قابلة للتطبيق:

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

اختبار مناسب للمشتريات:

"إذا اختفى البائع غدًا، هل ما زال لدينا بيانات تدقيق قابلة للاستخدام؟"

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

أين تضيف TrueFoundry قيمة:

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

بالنسبة للمؤسسات التي لديها متطلبات مركزية للمراقبة، توفر TrueFoundry بيانات قياس عن بعد منظمة ومملوكة للمؤسسة تكمل أدوات مثل Arize، بدلاً من استبدالها.

سؤال حول بنية الذكاء الاصطناعي رقم 3: هل يمكن إجراء تغييرات على المطالبات دون إعادة نشر؟

يبدو هذا الأمر هيناً حتى يغدو عظيماً.

في العديد من المؤسسات اليوم:

• المطالبات موجودة في الكود البرمجي
• تغييرات المطالبات ← إعادة نشر ← ضمان الجودة ← الموافقات
• لا يستطيع خبراء المجال تغيير المطالبات دون مساعدة هندسية

لا تعترض إدارة المشتريات على هذا لأنه "هندسة سيئة".
بل تعترض لأنه يخلق تكلفة تشغيلية خفية.

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

هذا السؤال مهم للغاية أثناء تقييم بنية الذكاء الاصطناعي للمؤسسات.

قاعدة معمارية قابلة للتطبيق:

• يجب أن تمرر التطبيقات معرف المطالبة (prompt_id)، وليس المطالبة نفسها.
• المطالبات موجودة في سجل مركزي، ومُصَدَّرة، وقابلة للتدقيق، وقابلة للتغيير دون إعادة نشر.

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

اختبار مناسب لإدارة المشتريات:

"كم عدد إصدارات الإنتاج التي يتطلبها تغيير مطالبة واحدة؟"

إذا كانت الإجابة أكثر من صفر، فإن حسابات إجمالي تكلفة الملكية لديك خاطئة.

حيث تضيف TrueFoundry قيمة:

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

سؤال حول بنية الذكاء الاصطناعي رقم 4: هل يتم تطبيق الحوكمة داخل بنية الذكاء الاصطناعي؟

أحد أسرع مجالات تقييم بنية الذكاء الاصطناعي نموًا يتعلق بالحوكمة.

لقد رأينا العديد من الشركات الكبرى تفكر: "البوابات تمنحنا توحيد النماذج الآن، لكن MCP والوصول إلى الأدوات وحوكمة الوكلاء ستكون مشكلتنا لاحقًا."

العديد من الفرق تقلل من تقدير مدى سرعة نمو تعقيد الحوكمة:

• المطورون الداخليون
• البائعون الخارجيون
• وكلاء متعددون يتفاعلون مع الأدوات
• أذونات مختلفة لكل حالة استخدام

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

قاعدة معمارية عملية:

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

اختبار مناسب للمشتريات:

"إذا ضاعفنا عدد التطبيقات العام المقبل، هل تتضاعف تكاليف الحوكمة؟"

إذا كانت الإجابة نعم، سيعتبر قسم المشتريات هذا خطرًا مستقبليًا.

أين تضيف TrueFoundry قيمة:

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

سؤال حول بنية الذكاء الاصطناعي رقم 5: هل يمكننا التحكم في إنفاق الذكاء الاصطناعي وتحديد مصدره؟

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

• لكل مستخدم؟
• لكل حساب خدمة؟
• لكل استدعاء API؟
• لكل تطبيق؟

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

قاعدة معمارية عملية:

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

اختبار مناسب للمشتريات:

«هل يمكننا تحديد سقف للإنفاق لتطبيق واحد دون التأثير على التطبيقات الأخرى؟»

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

أين تضيف TrueFoundry قيمة:

تحديد المسؤولية لكل تطبيق / لكل عبء عمل ممكن لأن التطبيقات يمكن إعدادها كهويات أساسية (بدلاً من تشجيع حسابات الخدمة المشتركة).

يمكن فرض ضوابط التكلفة مركزيًا (حصص، توجيه، قيود) حتى لا تتسبب الفرق عن طريق الخطأ في زيادة الفاتورة ثم تقول «عفوًا».

لماذا أصبح تقييم بنية الذكاء الاصطناعي وظيفة للمشتريات؟

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

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

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

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

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

كيف تتناسب TrueFoundry مع بنية GenAI شاملة ومناسبة للمشتريات

مناسب للمشتريات بنية الذكاء الاصطناعي التوليدي لها ثلاث طبقات غير قابلة للتفاوض:

الطبقة 1: تجريد المزود (مسار الخروج)

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

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

الطبقة 2: التحكم في التكلفة والجودة (الدفاع عن الميزانية)

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

لماذا هذا مهم: يصبح إجمالي تكلفة الملكية لخمس سنوات قابلاً للتنبؤ. يمكن للمديرين الماليين نمذجة منحنيات التكلفة. يمكن للمشتريات تبرير التزامات الميزانية لأنك صممت النظام ليتحمل تقلبات التكلفة.

الطبقة 3: قابلية المراقبة والأصل (إثبات الامتثال)

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

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

الخلاصة الحقيقية

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

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

قائمة مرجعية لبنية الذكاء الاصطناعي الملائمة للمشتريات:

‍

وهنا الجزء المهم: هذه البنية تفيد الهندسة أيضًا.
مراجعات أقل. تصعيدات غير متوقعة أقل. تجريدات أوضح.

إن أسرع طريقة لتوسيع نطاق الذكاء الاصطناعي التوليدي (GenAI) في المؤسسات ليست عروضًا توضيحية أفضل، بل هي جعل النظام آمنًا بما يكفي للاقتناء.

اكتشف كيف تعمل بنية الذكاء الاصطناعي الملائمة للمشتريات على أرض الواقع

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