Google מוסיפה שכבת ממשל חדשה ל־BigQuery: ב־6 בנובמבר 2026 הודיעה החברה כי אפשר להשתמש ב־Custom Organization Policy כדי לאפשר או לחסום פעולות מסוימות על מודלים ב־BigQuery. היכולת נמצאת ב־Preview ומיועדת לארגונים שרוצים להחיל כללי בקרה עקביים מעל פרויקטים, תיקיות ויחידות ארגוניות.
מה היכולת החדשה מאפשרת?
Organization Policy Service מאפשר להגדיר Custom Constraints — מגבלות מותאמות שנבדקות בעת יצירה או עדכון של משאב. עבור מודלים ב־BigQuery, סוג המשאב הוא bigquery.googleapis.com/Model, והמדיניות יכולה להתייחס למזהה הפרויקט, מערך הנתונים ושם המודל.
הכללים נכתבים כתנאים ב־Common Expression Language (CEL) ומוגדרים כ־ALLOW או DENY. לדוגמה, אפשר לחסום יצירה ועדכון של מודלים ששמם אינו עומד בתקן ארגוני, או להגביל מודלים לפרויקטים ול־Datasets בעלי דפוס שמות מאושר.
למה IAM לבדו אינו מספיק?
IAM עונה בעיקר על השאלה מי רשאי לבצע פעולה. Custom Organization Policy מוסיפה תשובה לשאלה באילו תנאים הפעולה מותרת. משתמש עשוי להחזיק בהרשאה ליצור מודל, אך המדיניות הארגונית עדיין יכולה לדחות את הפעולה אם שם המודל, הפרויקט או ה־Dataset אינם עומדים בכלל.
- IAM: קובע זהות והרשאה.
- Organization Policy: קובעת גבולות ותנאים על המשאב.
- Audit Logs: מספקים תיעוד של פעולות וניסיונות.
- Data governance: מחבר בין כללים, בעלות ותהליכי אישור.
דוגמה מעשית
התיעוד של Google מציג Constraint מסוג DENY עבור מודלים, עם CREATE ו־UPDATE כפעולות נבדקות. התנאי בוחן את resource.modelReference.modelId. ארגון יכול, למשל, לדחות שמות שמכילים מחרוזת אסורה, או לבנות כלל ALLOW שמאפשר רק תבנית שמות מוסכמת.
חשוב לנסח את התנאי בזהירות. כלל רחב מדי עלול לחסום Pipelines תקינים, ואילו כלל צר מדי יאפשר עקיפה באמצעות שם או Dataset אחר. לפני אכיפה חיה מומלץ להשתמש ב־dry-run, לבדוק את ההשפעה על תהליכי CI/CD ולוודא שיש בעל תפקיד שמסוגל לשחזר פעולה שנחסמה.
איפה זה מועיל במיוחד?
- BigQuery ML: אכיפת Naming convention ובעלות על מודלים.
- סביבות Production: מניעת יצירת מודלי ניסוי במערכי נתונים רגישים.
- ארגונים מרובי פרויקטים: החלת כלל אחד בירושה על תיקייה או ארגון.
- AI Governance: הפרדה בין מודלים מאושרים, ניסיוניים ומיובאים.
- רגולציה: צמצום Drift בין מדיניות כתובה להתנהגות בפועל.
מגבלות שחשוב להכיר
היכולת נמצאת ב־Preview וכפופה לתנאי Pre‑GA של Google Cloud. התמיכה עשויה להשתנות, ואינה מבטיחה שכל מאפיין של מודל זמין כתנאי. לפי רשימת השדות הנוכחית, עבור משאב Model ניתן לבדוק את projectId, datasetId ו־modelId. לכן אי אפשר להסיק שהמדיניות יכולה לסנן לפי כל פרמטר של אלגוריתם, מקור מודל או Endpoint.
מדיניות גם עוברת בירושה. כלל שמוחל ברמת Folder או Organization עשוי להשפיע על פרויקטים רבים, כולל סביבות שלא נכללו בכוונה המקורית. שימוש בתגים ותנאים, בדיקה מדורגת ותיעוד חריגים חיוניים לפני פריסה רחבה.
תהליך הטמעה מומלץ
- למפות מודלים קיימים: שמות, Datasets, בעלים ו־Pipelines שיוצרים אותם.
- להגדיר כלל פשוט: להתחיל ב־Naming convention אחד שקל לבדוק.
- להפעיל dry-run: לאסוף הפרות בלי לחסום פעילות.
- לתקן אוטומציה: לעדכן Terraform, CI/CD ופקודות
bq. - לאכוף בהדרגה: פרויקט ניסוי, תיקייה מוגבלת ורק אחר כך Organization.
השורה התחתונה
Custom Organization Policy על מודלי BigQuery מקרבת את ממשל ה־AI למדיניות שניתנת לאכיפה. במקום להסתמך על מסמך Naming convention או ביקורת ידנית, אפשר לחסום פעולה שאינה עומדת בכלל כבר בזמן היצירה או העדכון. אך מאחר שמדובר ב־Preview ובמדיניות שיורשת מטה, נכון להתחיל ב־dry-run ולהרחיב בזהירות.
מקורות: BigQuery Release Notes, 6.11.2026; Google Cloud — Custom constraints for BigQuery resources.
תמונה: Kingsley Mkpandiok / Unsplash. מנעול מואר משמש כהמחשה למדיניות אבטחה ואינו צילום של מוצר Google. רישיון Unsplash מאפשר שימוש באתר, בסושיאל ובשיווק מסחרי; המקור והקרדיט נשמרו.
