AI-BOM: كيف تبني سجلًا فعليًا لمكونات نظام الذكاء الاصطناعي؟

ما هو AI-BOM؟

AI-BOM هو اختصار لـ Artificial Intelligence Bill of Materials، ويشير إلى سجل منظم لمكونات نظام الذكاء الاصطناعي.

الفكرة الأساسية بسيطة:

لا يمكن للمؤسسة إدارة مخاطر نظام ذكاء اصطناعي لا تعرف ممَّ يتكون فعليًا.

بحسب PCI Security Standards Council، يجب أن يساعد الجرد المؤسسي على فهم عناصر مثل نوع نظام الذكاء الاصطناعي، والنماذج وإصداراتها، والبيانات والأنظمة التي يستطيع الوصول إليها، ومكان الاستضافة، والجهة التي تديره، وسياسات استخدام البيانات والاحتفاظ بها، والمستخدمين وحالات الاستخدام، وأنظمة التكامل والأوركسترا المرتبطة به.

AI-BOM ينقل المؤسسة من معرفة اسم النظام إلى معرفة بنيته واعتماداته.

الفرق بين AI Inventory وAI-BOM

AI Inventory يجيب عادة عن السؤال:

ما أنظمة الذكاء الاصطناعي الموجودة أو المعتمدة داخل المؤسسة؟

أما AI-BOM فيجيب عن سؤال أعمق:

ممَّ يتكون كل نظام من هذه الأنظمة؟

يمكن تصور العلاقة كالتالي:

AI Inventory → قائمة أنظمة الذكاء الاصطناعي

AI-BOM → مكونات وتبعيات كل نظام

قد يحتوي AI Inventory مثلًا على سجل باسم:

Customer Service AI Assistant

لكن AI-BOM لهذا النظام قد يتضمن:

• External LLM.
• Embedding Model.
• Vector Database.
• Retrieval Pipeline.
• CRM API.
• Email Integration.
• MCP Server.
• Prompt Templates.
• Orchestration Framework.
• Logging Service.
• Cloud Runtime.
• Third-party Moderation API.

وهنا يبدأ الفرق بين مجرد الجرد وبين القدرة الفعلية على الحوكمة.

لماذا لا تكفي قائمة الأدوات؟

أحد الأخطاء الشائعة أن يكون سجل المؤسسة مجرد قائمة أسماء مثل:

ChatGPT Copilot Gemini Internal AI

هذه ليست AI-BOM.

هي في أفضل الحالات قائمة منتجات أو خدمات.

المنتج الواحد قد يتضمن عدة طبقات وتبعيات:

Business Application → Embedded AI Feature → External Model Provider → Cloud Runtime → Data Connector → New Data Flow

إذا سجلت المؤسسة اسم التطبيق فقط، فقد لا ترى سلسلة الاعتماد الحقيقية التي تقف خلفه.

المكوّن الأول: النظام نفسه

يجب أن يبدأ AI-BOM بهوية واضحة للنظام.

سجل على الأقل:

• System ID.
• System Name.
• Business Owner.
• Technical Owner.
• Purpose.
• Business Function.
• Criticality.
• Environment.
• Lifecycle Status.

السؤال ليس فقط:

ما اسم النظام؟

بل أيضًا:

من يملكه؟ ولماذا يوجد؟ وما أثر توقفه أو إخفاقه أو إساءة استخدامه؟

المكوّن الثاني: النموذج

النموذج عنصر أساسي، لكنه ليس النظام كله.

سجل قدر الإمكان:

• Provider.
• Model Name.
• Model Version.
• Model Family.
• Hosting Model.
• Internal or External.
• Fine-tuning Status.
• Adaptation Method.
• Update Policy.
• Version Pinning.

وجود اسم النموذج دون الإصدار قد لا يكون كافيًا.

قد يؤدي تغيير الإصدار إلى تغير في:

• السلوك.
• Tool Use.
• Safety Characteristics.
• Output Structure.
• Context Handling.
• Reliability.

لذلك يجب التعامل مع الإصدار بوصفه جزءًا من Baseline النظام عندما يكون تحديده متاحًا.

المكوّن الثالث: Harness وOrchestration

نظام الذكاء الاصطناعي قد يشمل أكثر من النموذج نفسه.

قد يعتمد على:

• Agent Framework.
• Workflow Engine.
• Prompt Router.
• Memory Layer.
• Context Manager.
• Retrieval Pipeline.
• Tool Dispatcher.
• Approval Workflow.
• Multi-agent Orchestrator.

وهذا مهم لأن المخاطر لا تأتي من النموذج وحده.

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

Model unchanged لا يعني System unchanged

المكوّن الرابع: البيانات

من أهم أجزاء AI-BOM معرفة البيانات التي يستطيع النظام الوصول إليها.

سجل:

• Data Source.
• Data Owner.
• Classification.
• Location.
• Purpose.
• Read or Write Access.
• Retention.
• Training Allowed or Prohibited.
• Logging Allowed or Prohibited.
• Masking.
• Tokenization.
• Encryption.
• Retrieval Scope.

السؤال الأهم ليس فقط:

ما البيانات التي يفترض أن يستخدمها النظام؟

بل:

ما البيانات التي يستطيع الوصول إليها فعليًا؟

المكوّن الخامس: الأنظمة التي يمكن الوصول إليها

قد يصل نظام الذكاء الاصطناعي إلى أنظمة مثل:

• CRM.
• ERP.
• HR Systems.
• Email.
• Document Management.
• Source-code Repositories.
• Ticketing Systems.
• Cloud Consoles.
• Databases.
• File Systems.
• Payment Systems.

يجب أن يظهر كل Target System في AI-BOM مع طبيعة الوصول المتاحة:

• Read.
• Write.
• Execute.
• Approve.
• Delete.
• Admin.

المكوّن السادس: الأدوات Tools

في Agentic AI، الأدوات ليست مجرد تفاصيل تقنية.

Tool واحدة قد تمنح النظام قدرة على:

• إرسال بريد إلكتروني.
• تنفيذ Database Query.
• رفع ملف.
• تشغيل أمر.
• تعديل سجل.
• إنشاء مستخدم.
• تغيير إعداد.
• استدعاء خدمة خارجية.
• نشر محتوى.
• تنفيذ Transaction.

لذلك يجب أن يسجل AI-BOM لكل Tool على الأقل:

• Tool Name.
• Purpose.
• Owner.
• Target System.
• Authentication Method.
• Allowed Actions.
• Permission Scope.
• Read or Write Capability.
• Restrictions.
• Logging Status.

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

المكوّن السابع: MCP Servers

قد يضيف MCP Server مجموعة كاملة من الأدوات والموارد إلى Agent.

ولهذا يجب أن يظهر في AI-BOM كاعتماد مستقل.

سجل:

• MCP Server Name.
• Owner.
• Source.
• Version.
• Hosting Location.
• Tools Exposed.
• Resources Exposed.
• Systems Accessible.
• Credentials Used.
• Data Classes Reachable.
• Network Access.
• Change History.
• Approval Status.

إضافة MCP Server جديد قد توسع Effective Access للنظام حتى لو لم يتغير النموذج نفسه.

وهذا يعني أن:

New MCP Server قد يعني New Governance Boundary

المكوّن الثامن: APIs والتكاملات

يجب تسجيل التكاملات التي يعتمد عليها النظام أو يستخدمها.

مثل:

• Internal APIs.
• External APIs.
• Webhooks.
• SaaS Integrations.
• Plugins.
• Connectors.
• Event Streams.
• Automation Platforms.
• Message Queues.
• External Search Services.

كل Integration قد ينشئ:

• Data Flow جديدًا.
• Processing Party جديدة.
• Permission جديدة.
• External Egress Path.
• Operational Dependency.
• Security Boundary جديدة.

وجود API في خلفية النظام ليس مجرد قرار هندسي؛ قد يغير نطاق البيانات والصلاحيات والمسؤوليات.

المكوّن التاسع: الاستضافة والتشغيل

من المهم معرفة أين يعمل كل جزء من النظام ومن المسؤول عن تشغيله.

سجل:

• Hosting Location.
• Cloud Provider.
• Cloud Region.
• Internal or External Hosting.
• Runtime Environment.
• Container or Serverless Layer.
• Managed Service Provider.
• Operational Owner.
• Maintenance Owner.
• Production Environment.
• Development Environment.
• Data Residency Considerations.

قد يكون النموذج مستضافًا لدى مزود خارجي بينما تعمل طبقة الأوركسترا داخليًا وتوجد قاعدة المتجهات لدى مزود ثالث.

AI-BOM يجب أن يجعل هذه الصورة مرئية.

المكوّن العاشر: الجهات الخارجية

قد يحتوي نظام واحد على عدة أطراف خارجية.

منها:

• Model Provider.
• Cloud Provider.
• Data Provider.
• API Provider.
• SaaS Provider.
• Vector Database Provider.
• Integration Provider.
• Managed Service Provider.
• Subprocessor.

لذلك السؤال ليس فقط:

من المورد الرئيسي؟

بل أيضًا:

ما الأطراف التي يعتمد عليها المورد؟ ومن يعالج البيانات؟ ومن يملك القدرة التشغيلية على جزء من النظام؟

هذه التبعيات مهمة للأمن وإدارة الموردين والاستمرارية والحوادث.

المكوّن الحادي عشر: استخدام البيانات والاحتفاظ بها

بالنسبة لكل خدمة أو مكوّن يتعامل مع البيانات، سجل قدر الإمكان:

• Purpose of Processing.
• Data Categories.
• Storage Location.
• Retention Period.
• Training Use.
• Fine-tuning Use.
• Logging Use.
• Human Review.
• Deletion Capability.
• Export Capability.
• Subprocessor Access.
• Contractual Restrictions.

يجب أن تعرف المؤسسة خصوصًا:

هل تستخدم بياناتها في تدريب نموذج خارجي؟ كم تبقى البيانات لدى المزود؟ هل يمكن حذفها؟ هل تنتقل إلى أطراف أخرى؟

وجود AI-BOM يجعل هذه الأسئلة مرتبطة بالمكوّن نفسه بدل بقائها موزعة بين عقود ووثائق منفصلة.

المكوّن الثاني عشر: المستخدمون وحالات الاستخدام

النظام نفسه قد يكون مقبولًا لحالة استخدام وغير مقبول لحالة أخرى.

لذلك سجل:

• User Group.
• Business Use Case.
• Allowed Use.
• Prohibited Use.
• Data Classes Permitted.
• Autonomy Level.
• Human Approval Requirement.
• Output Destination.
• Decision Impact.

مثال:

اعتماد أداة لإنشاء مسودة تسويقية لا يعني اعتمادها تلقائيًا لمعالجة بيانات العملاء أو المعلومات المالية.

AI-BOM يجب أن يربط المكوّن بالسياق الذي يسمح باستخدامه فيه.

المكوّن الثالث عشر: الذاكرة والسياق

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

مثل:

• Session Memory.
• Long-term Memory.
• Conversation History.
• Retrieved Context.
• Cached Content.
• Vector Embeddings.
• Tool Results.
• Agent State.
• Orchestration State.
• Prompt and Response Logs.

هذه العناصر قد تتحول عمليًا إلى Data Stores.

لذلك يجب تحديد:

• أين تخزن؟
• ما الذي تحتويه؟
• من يستطيع الوصول إليها؟
• كم مدة الاحتفاظ بها؟
• هل تحتوي بيانات حساسة؟
• هل يمكن حذفها؟
• هل تنتقل إلى خدمة خارجية؟

AI-BOM وإدارة التغيير

القيمة الحقيقية لـAI-BOM تظهر عندما يتغير النظام.

قد يتغير:

• Model Version.
• Prompt.
• System Instruction.
• Data Source.
• Tool.
• MCP Server.
• API.
• Provider.
• Integration.
• IAM Role.
• Network Access.
• Retention Policy.
• Hosting Location.
• Autonomy Level.

إذا لم يكن لدى المؤسسة Baseline للمكونات، يصبح السؤال التالي صعبًا:

ما الذي تغير منذ آخر مراجعة؟

وهذا يضعف:

• Revalidation.
• Change Management.
• Incident Investigation.
• Auditability.
• Root Cause Analysis.

قراءة سيادة: Component Change as a Governance Event

من منظور سيادة، ليس كل تغيير في مكونات AI مجرد تحديث تقني.

قد يكون التغيير Governance Event إذا أدى إلى تغيير:

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

مثلًا:

إضافة Tool جديدة قد تكون أهم حوكميًا من تغيير النموذج نفسه.

AI-BOM وShadow AI

AI-BOM يساعد المؤسسة على تعريف ما هو معروف ومعتمد.

وهذا يوفر Baseline لاكتشاف ما هو غير معروف.

يمكن مقارنة البيئة الفعلية بالسجل للكشف عن:

• AI Service غير مسجلة.
• Browser Extension.
• IDE Plugin.
• Local Model.
• Unapproved API.
• Unknown MCP Server.
• New AI Feature داخل SaaS قائم.
• Personal AI Account مستخدم للعمل.
• Automation تستخدم نموذجًا غير معتمد.

AI-BOM لا يحل Shadow AI وحده، لكنه يعطي المؤسسة نقطة مرجعية واضحة لما يفترض أن يكون موجودًا.

AI-BOM وسلسلة التوريد

نظام الذكاء الاصطناعي قد يعتمد على سلسلة توريد متعددة الطبقات.

يمكن تصور مثال:

Enterprise Application → AI Feature → Model Provider → Cloud Infrastructure → External API → Subprocessor

قد يتغير أحد هذه المكونات دون أن يتغير التطبيق الذي يراه المستخدم.

ولهذا يجب أن يسمح AI-BOM بتتبع Dependencies وليس المنتجات فقط.

Dependency Criticality

ليس كل Dependency متساويًا.

يمكن للمؤسسة تصنيف كل اعتماد بحسب عوامل مثل:

• Data Sensitivity.
• Operational Criticality.
• Replaceability.
• External Exposure.
• Privilege Level.
• Concentration Risk.
• Vendor Dependency.
• Failure Impact.

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

AI-BOM والأمن

من منظور الأمن، يمكن ربط كل مكوّن بأسئلة مثل:

• هل يصل إلى بيانات حساسة؟
• ما الصلاحيات التي يملكها؟
• هل يملك Network Egress؟
• ما Credential التي يستخدمها؟
• هل يمكن إيقافه؟
• هل يتم Logging؟
• هل يخضع لـDLP؟
• هل يمكن Rollback؟
• هل هو داخلي أم خارجي؟
• هل يقبل Untrusted Input؟
• هل يستطيع تنفيذ Actions؟

وهنا يصبح AI-BOM مدخلًا مباشرًا لتحليل المخاطر وليس مجرد سجل إداري.

AI-BOM وLethal Trifecta

يمكن استخدام AI-BOM أيضًا للكشف عن تراكيب خطرة بين المكونات.

مثلًا، إذا كشف السجل أن Agent:

• يستطيع قراءة بيانات حساسة.
• يستقبل محتوى خارجيًا.
• يملك Tool للاتصال بخدمة خارجية.

فإن AI-BOM أصبح مصدرًا يساعد على اكتشاف Lethal Trifecta على مستوى المعمارية.

بهذا يصبح الجرد مرتبطًا مباشرة بقرارات التصميم الأمني.

قراءة سيادة: من AI-BOM إلى Governance BOM

AI-BOM يجيب عن سؤال جوهري:

ممَّ يتكون نظام الذكاء الاصطناعي؟

لكن المؤسسة تحتاج إلى أسئلة إضافية:

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

لهذا نقترح في سيادة توسيع AI-BOM إلى ما يمكن تسميته:

Governance BOM

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

ما الذي يضيفه Governance BOM؟

Governance BOM لا يستبدل AI-BOM.

بل يضيف فوقه طبقات حوكمة مثل:

• Ownership.
• Accountability.
• Approval.
• Risk Tier.
• Authority Boundary.
• Evidence.
• Change History.
• Review Status.
• Human Oversight.
• Revalidation Status.
• Incident Relevance.
• Dependency Criticality.

الفكرة هي أن المكوّن لا يكون مجرد اسم في قائمة.

يجب أن يكون له سياق حوكمي واضح.

Ownership

لكل مكوّن مهم، حدد:

• Business Owner.
• Technical Owner.
• Data Owner.
• Security Owner.
• Vendor Owner.
• Approval Authority.

قد تختلف هذه الأدوار حسب نوع المكوّن.

مثلًا:

Model Provider قد يكون مسؤولًا عنه فريق تقني أو Procurement.

Data Source قد يكون له Data Owner مختلف.

MCP Server قد يكون له Owner تشغيلي وأمني مختلف.

الهدف هو منع المكونات التي لا يملك أحد مسؤولية واضحة عنها.

Accountability

وجود Owner ليس كافيًا إذا لم يكن معلومًا:

من يتحمل مسؤولية القرار؟

يمكن توثيق:

• Decision Owner.
• Approval Role.
• Review Role.
• Exception Owner.
• Incident Escalation Owner.

هذا مهم خصوصًا في الأنظمة الوكيلة التي يمكن أن تنفذ أفعالًا دون تدخل بشري مباشر.

Risk Tier

يمكن ربط كل مكوّن أو Dependency بمستوى مخاطرة.

مثلًا:

• Low.
• Moderate.
• High.
• Critical.

لكن يجب ألا يكون التصنيف عشوائيًا.

يمكن أن يعتمد على عوامل مثل:

• Data Sensitivity.
• Privilege Level.
• External Exposure.
• Replaceability.
• Criticality.
• Autonomy.
• Write Capability.
• Network Access.
• Vendor Dependence.
• Failure Impact.

المكوّن الذي يملك وصولًا إداريًا إلى نظام حساس ليس مساويًا لمكتبة عرض واجهة.

Authority Boundary

من المفيد أن يحدد Governance BOM ما السلطة الفعلية التي يمنحها كل مكوّن.

يمكن توثيق:

• Read Scope.
• Write Scope.
• Execute Scope.
• Approval Scope.
• Delete Scope.
• Network Scope.
• External Communication.
• Secret Access.
• Human Approval Required.

بهذا يصبح AI-BOM أداة لفهم Effective Access وليس فقط Architecture Components.

Evidence

لكل مكوّن مهم، سجل الأدلة المتاحة عليه.

مثل:

• Vendor Documentation.
• Contract.
• Security Assessment.
• Penetration Test.
• Configuration Export.
• Architecture Diagram.
• Data Flow Diagram.
• Approval Record.
• Risk Assessment.
• Audit Log.
• Change Ticket.
• Test Result.
• Incident Record.

الهدف هو الانتقال من:

"لدينا هذا المكوّن"

إلى:

"لدينا دليل على حالته وضوابطه وموافقاته"

Evidence Freshness

الأدلة القديمة قد لا تعكس الحالة الحالية.

لذلك يمكن تسجيل:

• Evidence Date.
• Validity Period.
• Last Reviewed.
• Reviewer.
• Next Review.
• Superseded Status.

إذا تغير Model Version أو Tool أو Provider، فقد تصبح بعض الأدلة السابقة غير كافية.

Change History

يجب أن يسمح AI-BOM بتتبع التغييرات.

لكل تغيير، سجل:

• Change ID.
• Date.
• Component.
• Previous State.
• New State.
• Reason.
• Requestor.
• Approver.
• Risk Review Required.
• Revalidation Required.
• Evidence Updated.
• Rollback Available.

بهذا يصبح السجل ذا قيمة في:

• Audit.
• Incident Response.
• Root Cause Analysis.
• Revalidation.
• Governance Review.

Revalidation Trigger

ليس كل تغيير يحتاج نفس مستوى المراجعة.

لكن بعض التغييرات يجب أن تكون Trigger لإعادة التقييم.

مثل:

• New Model.
• New Model Version.
• New Data Source.
• New Tool.
• New MCP Server.
• New External API.
• New Vendor.
• IAM Scope Expansion.
• Internet Access Enabled.
• New Write Permission.
• Autonomy Increased.
• Human Approval Removed.
• Retention Policy Changed.
• Hosting Region Changed.

Governance BOM يمكن أن يحتوي حقلًا مثل:

Revalidation Required Yes / No

مع سبب واضح.

النموذج الأدنى المقترح لـAI-BOM

يمكن للمؤسسة أن تبدأ بـMinimum Viable AI-BOM بدل انتظار نموذج معقد.

الحد الأدنى لكل نظام:

• System ID.
• System Name.
• Owner.
• Purpose.
• Criticality.
• Model Provider.
• Model Name.
• Model Version.
• Hosting.
• Data Sources.
• Target Systems.
• Tools.
• APIs.
• MCP Servers.
• External Providers.
• Credentials.
• Read/Write Scope.
• Network Access.
• Data Retention.
• Approval Requirements.
• Change Date.
• Last Review.
• Evidence Links.

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

نموذج Record عملي

يمكن أن يحتوي Record لمكوّن واحد على شكل قريب من التالي:

Component ID: AIBOM-CRM-API-001 Component Type: API Name: CRM Customer Data API Owner: Customer Systems Team Data Classification: Confidential Access Mode: Read Credential Type: Service Identity External Exposure: No Used By: Customer Service AI Agent Risk Tier: High Last Change: 2026-09-10 Last Review: 2026-09-12 Revalidation Required: Yes Evidence: IAM export, API specification, approval record

هذا مثال تطبيقي من سيادة، وليس Schema رسميًا من PCI SSC.

العلاقات بين المكونات

القائمة المسطحة لا تكفي دائمًا.

من المفيد أن يسجل AI-BOM العلاقات مثل:

Agent uses Tool

Tool calls API

API reads Database

Agent uses Model

Model hosted by Provider

MCP Server exposes Tool

Tool writes to Target System

بهذا يمكن لاحقًا بناء Dependency Graph.

لماذا Dependency Graph مهم؟

عند وقوع حادث أو تغيير، يمكن للمؤسسة أن تسأل:

ما الأنظمة التي تعتمد على هذا المكوّن؟

إذا تغير:

Model Provider أو MCP Server أو API أو Vector Database

يمكن تحديد الأنظمة المتأثرة.

هذا يساعد في:

• Blast Radius Analysis.
• Incident Response.
• Change Impact Analysis.
• Supplier Monitoring.
• Business Continuity.

AI-BOM والموردين

AI-BOM يجب أن يتكامل مع Vendor Risk Management.

لكل مورد، يمكن ربط:

• Services Used.
• Data Processed.
• Criticality.
• Contract Status.
• Security Review.
• Privacy Review.
• Subprocessors.
• Exit Plan.
• Replacement Difficulty.
• Incident Notification Requirement.

بهذا لا تبقى معلومات المورد منفصلة عن النظام الذي يعتمد عليه.

AI-BOM وEmbedded AI

أحد أكبر التحديات أن قدرات AI قد تظهر داخل منتجات موجودة أصلًا.

مثل:

• CRM يضيف Copilot Feature.
• Email Platform يضيف AI Assistant.
• Security Tool يضيف Generative AI.
• Office Suite يضيف Agentic Capability.
• SaaS يضيف Embedded Model.

قد لا تشتري المؤسسة "نظام AI جديدًا"، لكن النظام الموجود تغير فعليًا.

لذلك يجب أن يكون هناك Trigger مثل:

New Embedded AI Feature Detected → Review Required → AI-BOM Update Required

AI-BOM وDrift

Drift لا يعني فقط Model Drift.

قد يحدث ما يمكن تسميته Component Drift.

مثل:

• تغير Model Version.
• تغير API Behavior.
• تغير Permissions.
• تغير Provider.
• تغير Subprocessor.
• تغير Data Source.
• تغير MCP Tools.
• تغير Prompt.
• تغير Retention Policy.

إذا تغيرت هذه العناصر دون تحديث AI-BOM، يصبح السجل غير مطابق للواقع.

قراءة سيادة: Configuration Drift vs Governance Drift

Configuration Drift يعني أن الحالة التقنية تغيرت عن Baseline.

Governance Drift يعني أن النظام الفعلي لم يعد مطابقًا لما تم تقييمه أو اعتماده حوكميًا.

مثلًا:

تم اعتماد Agent بصلاحية Read Only.

لاحقًا تغيرت Integration وأصبح يملك Write.

تقنيًا قد يعمل النظام طبيعيًا.

لكن حوكميًا حدث Drift مهم.

AI-BOM والتدقيق

يمكن للمدقق استخدام AI-BOM كنقطة بداية بدل طلب وثائق متفرقة.

يمكن أن يسأل:

1. هل السجل يغطي جميع الأنظمة المعتمدة؟
2. هل المكونات الرئيسية لكل نظام مسجلة؟
3. هل الإصدارات محدثة؟
4. هل المالك واضح؟
5. هل الوصول الفعلي موثق؟
6. هل الجهات الخارجية معروفة؟
7. هل التغييرات مسجلة؟
8. هل الأدلة حديثة؟
9. هل توجد مكونات غير معتمدة؟
10. هل توجد فروقات بين السجل والواقع؟

AI-BOM الجيد لا يلغي الاختبار الفني، لكنه يعطي نقطة مرجعية يمكن اختبارها.

أسئلة تدقيق متقدمة

يمكن أيضًا طرح:

• هل يوجد Component في Production غير موجود في AI-BOM؟
• هل يوجد AI-BOM Component لا يمكن إثبات وجوده فعليًا؟
• هل Model Version الفعلية تطابق المسجلة؟
• هل IAM Scope يطابق السجل؟
• هل MCP Tools الفعلية تطابق القائمة المعتمدة؟
• هل External Endpoints الفعلية مسجلة؟
• هل Retention الفعلية تطابق السياسة؟
• هل هناك Subprocessor لم يتم تسجيله؟
• هل حدث Change دون Revalidation؟
• هل انتهت صلاحية Evidence المستخدمة في الموافقة؟

AI-BOM والحوادث

عند وقوع Incident، يمكن أن يساعد AI-BOM في الإجابة بسرعة عن:

• ما المكونات المتأثرة؟
• ما البيانات التي كانت في متناول النظام؟
• ما Credentials المستخدمة؟
• ما External Connections المتاحة؟
• ما الأنظمة الأخرى التي تعتمد على نفس المكوّن؟
• ما Version المستخدمة وقت الحادث؟
• متى تغير المكوّن آخر مرة؟
• من وافق على التغيير؟

هذه المعلومات تقلل وقت التحقيق.

AI-BOM كأصل حي

AI-BOM ليس وثيقة تبنى مرة واحدة ثم تحفظ.

يجب أن يكون Living Record.

يحدث عند:

• Deployment.
• Model Update.
• Integration Change.
• Data Source Change.
• Permission Change.
• Vendor Change.
• Architecture Change.
• Incident.
• Periodic Review.

كلما اقترب السجل من الحالة الفعلية، ارتفعت قيمته.

من المسؤول عن تحديث AI-BOM؟

لا يجب أن يقع العبء على فريق واحد فقط.

قد تشترك أدوار مثل:

• AI Product Owner.
• Security.
• Architecture.
• Data Governance.
• Procurement.
• Vendor Management.
• Privacy.
• Platform Engineering.
• Risk.
• Audit.

لكن يجب أن يكون هناك Owner نهائي مسؤول عن اكتمال السجل.

Automation

يمكن أتمتة أجزاء من AI-BOM.

مثل:

• اكتشاف Model Endpoints.
• استخراج Package Versions.
• رصد MCP Servers.
• قراءة IAM Roles.
• رصد Network Destinations.
• Inventory of APIs.
• Cloud Resource Discovery.
• Repository Dependency Scanning.

لكن الأتمتة لا تستطيع دائمًا تحديد:

• Purpose.
• Business Owner.
• Approval.
• Risk Acceptance.
• Human Oversight.
• Allowed Use.

لذلك AI-BOM يحتاج مزيجًا من:

Technical Discovery + Governance Context

ما الذي لا يجب فعله؟

تجنب أن يتحول AI-BOM إلى جدول ضخم لا يستخدمه أحد.

من الأخطاء:

• تسجيل كل مكتبة صغيرة بلا سياق.
• عدم تحديد Critical Components.
• عدم ربط المكونات بالأنظمة.
• عدم تسجيل الإصدارات.
• تجاهل Embedded AI.
• تجاهل MCP.
• تجاهل Data Flows.
• عدم تعيين Owner.
• عدم تحديث السجل بعد التغيير.
• عدم ربط السجل بالأدلة.
• عدم استخدام السجل في المراجعات والحوادث.

الهدف ليس زيادة عدد الحقول.

الهدف هو زيادة قدرة المؤسسة على معرفة ما لديها، وما تغير، وما الخطر المرتبط به.

أسئلة يجب أن تجيب عنها المؤسسة

إذا كان AI-BOM فعالًا، يجب أن تستطيع المؤسسة الإجابة عن أسئلة مثل:

1. ما أنظمة AI الموجودة؟
2. ممَّ يتكون كل نظام؟
3. ما النموذج والإصدار المستخدم؟
4. ما البيانات التي يصل إليها؟
5. ما الأدوات التي يستطيع استخدامها؟
6. ما الأنظمة التي يستطيع التأثير فيها؟
7. ما الجهات الخارجية المعتمدة؟
8. ما MCP Servers المرتبطة؟
9. ما Credentials المستخدمة؟
10. ما Network Access المتاح؟
11. من يملك كل مكوّن؟
12. ما مستوى الخطورة؟
13. ما الذي تغير مؤخرًا؟
14. هل التغيير تمت مراجعته؟
15. ما الأدلة التي تثبت الحالة الحالية؟

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

الخلاصة

AI-BOM ليس مجرد قائمة تقنية.

هو Baseline يوضح ممَّ يتكون نظام الذكاء الاصطناعي وكيف يعتمد على النماذج والبيانات والأدوات والخدمات والجهات الخارجية.

قيمته الحقيقية تظهر عندما يستخدم في:

• Governance.
• Security.
• Risk Management.
• Audit.
• Vendor Management.
• Change Management.
• Incident Response.
• Revalidation.

ومن منظور سيادة، الخطوة الأكثر نضجًا هي تحويله من Bill of Materials فقط إلى Governance BOM يربط كل مكوّن بالملكية والسلطة والخطر والأدلة والتغيير.

السؤال النهائي ليس:

هل لدينا قائمة بالأنظمة؟

بل:

هل نعرف بدقة ما الذي يتكون منه كل نظام، وما الذي تغير فيه، ومن يملك مسؤوليته، وما الأدلة التي تثبت حالته الحالية؟

المرجع

المفهوم مستند إلى:

PCI Security Standards Council Security Considerations for AI Systems — Information Supplement Version 1.0 — September 2026.

هذه المادة قراءة عربية تطبيقية من سيادة AI.

توسيع AI-BOM إلى Governance BOM هو نموذج تطبيقي من سيادة، وليس تعريفًا أو متطلبًا رسميًا صادرًا عن PCI SSC.